Godot Engine – Free and open-source 2D and 3D game engine

The last time I started work on a new game I checked out Godot again, but ultimately I went back to GameMaker Studio.

I really think Godot has some real potential, but having the console exports for PS4 and Xbox One are pretty critical.

Atomic is structured very similar to unity, has a C++ core and C# and Javascript bindings, but unlike unity the C++ core (as well as the editor) is open source so you can modify and customize it if needed.

Have you ever used a visual language in ernest? I've used Max/MSP and Max4live, which are successfully used by many non-programmer musicians and artist. I don't think many of these people would be successful with (or even bother to use) a textual programming language and I think many designers who love Unreal Engine's Blueprints would similarly not fare so well with textual languages. My experience using Max was that it was a breath of fresh air, in many ways superior to my day-to-day experiences with "real" programming languages (eg for exploratory problem solving, it was amazing, and for games where you likely need to make many little tweaks until it feels right, I can see this being a major advantage). Sadly, Max is rather limited in terms of data structures (can't even have nested lists!), but that's a shortcoming in Max and not in visual programming tools.

So, in summary, I disagree: I don't think its wasted resources at all and think its a great idea, especially to get more non-programmer users[1] and welcome more stuff like this.

[1] From what I've been reading, lots of non-programmer designer/artists are making games with Game Maker and Blueprints and such tools. The more you can do without "real" programming, the better, IMHO.

This is an open-source project. Priorities are defined by what the developers need for their own projects, and if there's any time left by what they want to spend their spare time on.

I for one am glad that someone decided to contribute a C interface that is friendly to most languages with C/FFI capabilities to allow people to more easily integrate whatever language they want, rather than providing tighter integration with a single language that is a second class citizen on all the platforms I care about.

If you think C# integration is more important, go ahead and contribute to it.

They have just recently managed to get enough money through Patreon to pay for their main developer to work full-time on the engine, and they are planning to let patrons vote on which features get worked on for the next release. So if you don't have the time or drive to contribute good C# integration, you could donate and vote for C# integration to be picked up by the core developer(s).

There are visual languages that look the same as above, but lines are actually dataflow instead of function calls / control flow and the boxes are not opaque functions but introspectable data flow descriptions themselves. These offer some unique benefits, like transitive optimization and code elimination, that operate at a higher level than even full program optimization can achieve. (The latter being Simulink, for example.)

Then there are state charts (which are the big cousin of cumbersome non-hierarchical state diagrams as most people know them). These are, to me, practically a silver bullet regarding real-time systems. I went into automotive software development being very skeptical of Stateflow (coming from a classic C and Java background), but it has transformed the way I work with real time systems (even if not using it). It requires a huge upfront investment in analysis and thinking things through very thoroughly, which is why it is not particularly suited for systems with very volatile requirements, but it leaves you basically at state "done" after the design phase.

You can load it in your browser to try at: https://editor.construct.net

Tens of thousands of active users and feedback over the years has been extremely positive on this aspect of our product.

I'd be curious on your thoughts on it coming from a slightly pessimistic starting point :)

there are blueprints, that are really easy to use, and are really powerful. just decorate any function in c++ with UFUNCTION() and bam! you have a blueprint callable function. besides, there are things that just work better in blueprint, like latent actions (in c++ you would have to code timers and stuff, in BP is just action1()->delay(0.5)->action2() ) and curve driven stuff is easier in blueprints

there are animation blueprints: in these you get 'animation data' and you have nodes that help you mix different sources of animation, transform, blend, or simulate rigidbody on certain bones, is like a functional programming where you have this `animationstate` type that you operate with in every node. It also has a graphic state machine where you can describe the animation output in each state, and the rules of transition (for example, transition from idle to run if velocity>5.

also you have materials, is also like another functional programmming, where you grab inputs and put it in material outputs, again like functional programming, you sample textures, pan the samples, mix with colors and do a lot of stuff.

These uses (mostly animation and shaders) are mostly for people without technical inclinations, I would recommend you to try UE4 or godot and see how well visual scripting fits the project.

Visual programming languages are not designed for experienced programmers, who would rather type it out. It's designed for those who don't have a programming background, but still might need to wire up some logic on occasion. It's not necessarily meant to be efficient, just user-friendly to someone with no programming experience. If this language makes it easier to write tutorials or get into making games for people coming from an art or design background instead of a programming background, I'm all for it.

It always amazes me when I see people (who would otherwise be freaked out about learning a programming language) having great fun making stuff out of what a seasoned developer might consider archaic gui-driven logic editors. And in comparison to more "pro" development systems with "proper" programming languages, they can churn stuff out by the bucketload with relative ease.

It's definitely less efficient than text if you're already an experienced programmer but its also more discoverable and intuitive to understand for a lot of people that aren't. It's also nice to play with in a way that pedantic text syntax isn't. They're also really nice for processes where you can inspect the results so far at each stage (shaders, procedural texture generation, solid modelling).

It's not really about raw programming efficiency but efficiency to get the job done, it empowers people other than dedicated programmers to do their jobs without having to sit around waiting for a programmer to do something for them which is very important in terms of iterating on concepts.

There are more than just programmers on modern game projects. I imagine visual scripting is an enormous boon to teams because a designer or someone who makes rules isn't blocked on a programmer implementing those rules. The non-programmer can get the basics down in the visual scripting tool, then the programmer can finish it and tighten it up. I'd love a tool like this in web development that let PM/BAs get started writing test cases they could hand off to me, for example. (I'm aware that tools like this do exist, was trying to be illustrative)

Also, with the GDNative thing, you can plug in any programming language you want (it's a C API, and there's already bindings for C++, D, C#, Python, Nim, and it's trivial to add more languages).

https://godotengine.org/article/beta-release-python-support

https://www.youtube.com/watch?v=h6MsqsJqnao&t=2h35m09s (Emmanuel Leblond at EuroPython 2017)

https://godotengine.org/article/godot-getting-more-languages

https://github.com/neikeq/GodotSharp

THUNDERBEAST GAMES began developing the Atomic Game Engine on November 12th, 2014 by forking Urho3D. It was released under the permissive MIT license during GDC 2016. Atomic is now being used in production environments, has 30 contributors, and runs on Windows, macOS, Linux, Android, iOS, and WebGL!

Following the commit log of the coder who ported to Haiku, it was a matter of mostly adjusting the build process/includes to point to the right lib and fixing some method signatures.

https://github.com/godotengine/godot/commits?author=Max-Migh...

It's open source. You could even go ahead and submit a PR with your improvements.

- My bro had written RTS prototype using built-in tilemap. When zoomed out, game was working pretty slow (12-20 fps) because drawing a lot of tiles at once was bottleneck. He was able to optimize his prototype using GDScript to work with stable 60 fps (he cached rendered tilemap as texture). - I wrote simple "terminal emulator" control for Godot. It was quite slow - rendering 125x32 characters terminal was 120 ms per change. With few simple tricks I reduced it to 40 ms for full redraw and 1 ms for small change like drawing few characters.

I dont know if you can configure the framerates and engine internals here.

Next problem is that you need to write a lot of partially performance intensive game logic code (pathfinding etc.).. which again makes sense to write in the engine native language.

There is a reason why game specific engine exist- and if i would dev a new game today, i would choose- the one os-game that is allready as close as possible to the idea port that to a dedicated engine.

Its way too much work to fork a generic engine to a high-performance specialisation.

Edit: it’s worth noting some of the hard stances they have in that faq have changed since then. 3.0 (coming soon) has C# support.