This is a lot like an open source Unity. It is trying to be pretty comprehensive, and while a little thin in areas, they are doing a great job-- a lot of value for the "cost" (which is namely, learning the new platform.)
The 2.x series is current, but 3.0 which is in the final stages is a big upgrade, with physically based rendering, a lot better shadow system, support for multiple programming/scripting languages and a visual programming language (for designers and artists to use, though its fully capable large scripts are harder to do visually.)
Very excited about this project and can't wait for 3.0.
I'm having a hard time finding much about the visual language, but does it happen to convert into a proper text-based scripting language? I love the idea of my designer being able to piece some stuff together with next to no programming knowledge, and me coming in later and editing it in a text form.
I'm not sure if it "converts" in the sense it can be exported, but it is a literal 1 to 1 mapping of the GDScript language (or a subset of it), so such a conversion should be possible.
I come from phaser and am currently working as a game designer. Godot was just what I needed since I wanted a visual editor(it makes lots things quicker) but still be able to code(unlike construct, for example). I also needed to test my stuff on mobile and Godot can export to android in seconds.
The scripting language took me a week to learn and two to feel confortable with, though I think people coming from c#/java have a harder time getting used to its simplicity. 3.0 will support c# and potentially anything that compiles to a dynamic library thanks to GDNative.
I contrast, Unity to me always felt like this huge Rube Goldberg machine I have to set in motion to do anything so if you want something that starts up in seconds and has fewer dependencies I really recommend it.
I've used Godot a few times and found it pretty promising. The visual editing is a cool added value that wasn't there the last time I used it. It's not something I would personally use, but I've worked with artists/designers who have made use of similar tools with Construct and GameMaker.
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.
Agreed, I can't consider any engine that lacks support for the modern consoles. Given how brutal the industry is in general, you can't afford to leave money on the table by giving up potential console ports.
That said, I understand why it's not supported currently. The process to get anything done on Xbox or PS4 is laborious to say the least, and I am unsure how an open source project would accomplish it without being a standalone entity like Unity, Epic, or GameMaker.
Monogame is not so much a game engine as it is an I/O framework. It's got primitives to get input, to draw on screen and output sound and really barely more than that.It's much more fair to compare it to SDL than to a full-fledged engine like Unity. It has some of the elements you need to build an engine, like asset management and stuff, but it's really bare-bones and expects you to design all the higher level logic yourself.
And honestly, that's fine. It's 2D only (afaik) and designing your own main loop is a piece of cake anyway.
The only real problem I have with Monogame is that it's cross-platform only really in theory. In order to build your games for multiple platforms you need to use different forks of the codebase, or at least that's how it was when I tried it.
From what I see, it's a complete IDE and one can make a game without any other dependencies, which is really cool. It would make an awesome tool for Ludum Dare.
Does anyone know how it compares with other OSS game IDE/engine?
Another "unity-style" one to watch is Atomic Engine (https://atomicgameengine.com/), which is from Josh Engebretson, who came out of the GarageGames scene and is one of the most prolific and talented developers I've ever seen.
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.
Good. There's no reason for a game engine to use its own proprietary scripting language when other, more widely supported and optimal options exist. I should to be able to link any scripting language I want. If I want to script in Brainfuck, the engine should let me.
Their documentation goes into detail on why they dropped Lua, Squirrel and Python in the first place. It's interesting that they'd then bring Python back.
I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming. I may well be in a minority on this one, but surely time spent on this would better be spent in other areas like improving C# interoperability etc?
I know the intention does not appear to be to replace actual programming, but I think their use-case is weak and put in because it was someone's pet project. Not trying to be ultra-critical, but just think this is wasted resources, which could be better spent elsewhere.
Interested to see what people think about this.
EDIT: Should have phrased this better. So to be clear, I am asking what people think about the relative merits of Visual Scripting and not what part of the project has a higher priority.
Visual languages have been very successful in other tools (material/shader languages in 3D tools, Blueprints in Unreal Engine has been very successfully used by game designers). I assume that Godot was influenced by this.
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.
> Not trying to be ultra-critical, but just think this is wasted resources, which could be better spent elsewhere.
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).
This really was not the main thrust of my question. It is completely obvious that the developers, or anyone else contributing can work on any aspect they choose. I am far more interested in a discussion about the merits of a Visual Scripting approach.
I should probably have worded my comment better and have added a small addendum.
> 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.
Do you have a link to the C/FFI interface you mentioned?
There are visual languages that basically do "functions as boxes", lines as calls". These are useless.
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.
That's an interesting observation, in that games are often real-time systems. Makes sense to me as I work in audio DSP where you've got to have your buffer processed in time or you wreck the hapless user's mix.
Where do you see Godot relative to this? I know I was interested in Unreal Engine's blueprints, but unconvinced (also, I was working with my coder brother, who hated blueprints on sight). I've also been exploring the open synth hardware Axoloti, which likewise uses a node-based system for its design.
Regarding visual editing, those tools are of direct interest to any signal processing work(which for games means audio, visual effects, and in some cases asset dependency resolution). They don't work well once your task is too fine-grained. Graphs of finite state are also extremely useful for game AI and concurrently scripted logic, so tools that formalize those concepts and give them visual UI are also commonplace.
In audio work, a FSM is a good starting place to conceptualize processes like key state tracking and envelope triggers. Games have more shifting requirements so the design process of the FSM is given much more emphasis.
Welp, now I'll HAVE to choose MIT when my own opensourcing gets underway. They say they didn't have much audio DSP code under MIT license they could use. I was leaning to MIT anyhow, but if they need specifically that…
> 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...
I've only had a brief (few months) experience with Max/MSP, although I've played around with other visual languages too (SynthMaker and others) and have been interested in the topic of both visual and dataflow languages for a long time. So, with that bit of context, I completely agree with your observation!
Since you are still in beta, I figure you could use some feedback, so here are a couple of things I noticed that were unexpected. (I'm using Firefox 55 on Linux so some problems may be related to that.)
* After loading the editor, I got a dialog that says "A new version of Construct 3 is available! You are using r58, and r58 is ready to use." which is quite confusing. Also, the text in the dialog can't be selected, so I had to use the dev tools to copy the text. At least clicking "Update" didn't send me into an infinite loop.
* When opening one of the featured projects (I tried Glokar), there is no way to cancel the download. (I was getting very low download speeds, maybe because I'm in China. The GFW throttles a lot of random traffic.)
* In a box that says "Add action... Add..." I would expect the whole box to be clickable, not just the text.
* When clicking on an action like "Go to Mission Objective" I would expect a link that lets you look at "Mission Objective". Yes, it's in the project panel, but maybe I didn't see it and I don't know where it is because I'm looking at someone else's project. Same for all other kinds of cross-referenced objects.
* I found the Beginner's Guide much too late, because it was below the fold for me and the list of demos captured my scrolling.
* Double-clicking empty space to add an object is absolutely undiscoverable. I guess it's fine if you are reading a guide anyway, but I just wanted to jump in and try out things.
* The tiled background editor should show the tile as it actually tiles, otherwise you won't know how it will look. Also, there is no obvious "I'm done" button.
* When you have multiple identical sprites but decide that one of them should be different, there is no obvious way to turn it into its own type so that it can be modified independently. (Short of deleting and recreating it from a clone of the original sprite.)
* None of the preview options seemed to do anything.
That's about when I lost interest.
The concept of your visual editor seems overall quite good, although I'd want keybindings for everything.
Cool project. I think what they were talking about is demonstrated here. For example, in Construct when you want to add an action to an event you click the add button then a wizard pops up to help you assign it. If you know how to program that is annoying because you know how to express yourself faster with text. If you don't know how to express yourself it provides the scaffolding to help you succeed. I think they are lamenting that for experts they haven't seen a visual language that is faster / more expressive. I don't think they would argue that this isn't easier for beginners.
Visual scripting are a really powerful tool. I have never used Godot, but in UE4 you have 3 different styles of visual scripting, and each is a powerful tool in its own style
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.
> I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming. I may well be in a minority on this one, but surely time spent on this would better be spent in other areas like improving C# interoperability etc?
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.
IMO visual scripting languages are less about efficiency, more about accessibility. Given a few simple rules and easy to discover widgets, just about anyone can make stuff happen. If anyone can make stuff happen, your going to increase your potential userbase significantly.
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.
Visual scripting as an aid to designers has been a thing for a long time in commercial game engines. For example Unreal Engine has had visual scripting to aid level design and shader creation for quite a long time.
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.
>I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming.
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)
I would have to argue though that something like Unreal Engines blueprints really is like programming with a "lego block twist". The learning curve was steep for a few days but really after that, it's not all that much different then programming by hand. I will say it is a bit easier and it's amazing how fast you can get things done in it.
I'm not sure of a total "non-programmer" being super successful learning blueprints if they can't learn basic programming, but I would say it's a bit easier.
It doesn't have to be easier, it has to be more approachable. The most important part of programming is problem solving no matter how you're doing it, visual, imperative, functional, etc. Some interfaces are much more friendly to different people than others. Text programming often puts off non-programmers instantly, and they are able to reason about visual programming languages much easier than they would text-based ones without putting more time into them.
People here got the idea totally wrong so far. You can see from "WHY VISUAL SCRIPTING?" section in https://godotengine.org/article/godot-getting-more-languages that it's mainly a tool for programmers to let artists in their teams do simple programming stuff, such as homegrown editor plugins.
I think there's merit to visual scripting, some people are more comfortable with it than code. The nice thing about Godot's visual language is that it's basically just a visual representation of functions already in GDScript.
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).
I have tried to use it something like 2 years ago and just gave up in front of the poorly documented custom scripting language they used.
Has this changed? I think they were pondering switching to python or lua?
One of the main strength of its main competitor Unity is that it uses C# and the .Net framework. It comes with many usable tools from the whole C# ecosystem.
Is 3.0 available in a pre-release state to any degree? I would like to try it out but don't really want to invest into a platform specific scripting language.
Edit: Appears your link is essentially what I asked for above.
The documentation for GDscript is pretty thin, it's true. However, I think it has been improving, and that coupled with the tutorials created by other parties has helped me a lot in figuring out how to make things work.
Great to see Godot on the front page of HN. I have used Godot, and it's a great piece of software. I have not used any other open source game engine that is so feature rich, and you can build very complex games in it. And deploy them on all the popular platforms (mobile and desktop). Okam studios (Juan's company again) uses it for all their work.
I personally know the founder/owner of Godot, Juan Linietsky. He is a great and a very down to earth guy. It was amazing to be in his company.
Here's a shout out to Juan, for your and your team's great work! Keep.it up and thank you for giving Godot to us!
It is remarkable what this team achieved in terms of how lightweight it feels, the shape and portability of the code-base and how high quality and full featured it is, given the complexity of the domain.
IMHO, it deserves to be in the http://aosabook.org series as open-source code-bases you would read and learn from.
With 3.0, Godot officially supports C, C++, C#, GDScript and D, with unofficial bindings for Python, Nim, and probably others (those are only the ones I know about).
Godot 3.0 has been one year in development (since the release of Godot 2.1 in August 2016), and I wouldn't say it's in a "very early stage".
It's almost feature-complete, tons of bugs have been eradicated already, and the stable release is should be 2-3 months away.
As for slow developments... I don't know where you're taking that? Godot has dozens of commits every day, and the pace at which 3.0 features were implemented is honestly impressive (I'm obviously biased as a Godot dev, but check the GitHub repo [0] and the monthly progress reports on the devblog [1]).
Godot has been in development since 2007, open sourced in 2014, and has had 400+ contributors [0] over 3 years vs 32 [2] for Atomic over 2 years. On the other hand, young Atomic is an overlay on the mature Urho3D project with 100+ contributors [3] and over 6 years of development.
Both Godot and Atomic have their strengths and weaknesses, and are IMO two great open source game engines - but as far as maturity goes, I think the sheer size of Godot (both in terms of community and git/issues/PRs activity) compared to Atomic says a lot.
I see. It is interesting to see the comparison of these two engines besides languages support. So far the main advantage for me for Atomic is its stable support of C++ and C# languages compared to Godot's dynamically typed scripting language.
Looks interesting, from the page (for those just browsing comments here):
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!
Is there any reason why AtomicEditor is distributed only as a source code, and not as binary? Atomic requires the user to download and build from the source, which is easy for advanced users, but for beginner game coder, it might be a big obstacle. (MY guess is that it is due to licensing issue, or perhaps it is designed to keep the newbies out)
A little late to the party on this one, but does anyone have experience using Godot to build a multiplayer game? I'm thinking more along the lines of 4 player coop, not MMO.
I've been playing with a few different libs, mainly trying to stay in the JS space, and as far as I can tell the only real way this is achievable is via websockets. I have no illusion of this game ever making even beer money, it's really just for fun and to see if I can, but I'd still rather not blow a bunch of time running down the wrong roads.
I was just about to start playing with Love2D, since they have some UDP socket libs, but I'd be starting completely new in Lua, so if Godot had similar capabilities and people have seen success there I'd be open to that instead.
I recently got into Panda3d[1]. The Blender3D[2] (an excellent general purpose computer graphics tool) exporter is amazing. I don't even have to change the materials really. The "autoshader" uses blenders normal, emit, spec, and diffuse maps, along with the alpha from PNG's right out of the box.
Amazingly easy to use if you like python as well. If you're tired of GUI based game engines, I highly recomend taking a look.
EDIT: There is also a physically based shading set-up. But my laptop isn't good enough to play around with it.
Bonus points for making this work in Haiku[1]! While I doubt that this has any real value in itself, it's always nice to see that the Haiku project is alive.
I got curious to see how much effort was spent on this task.
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.
They scan the entire open list and recompute the heuristic value for every node all so they can find the min. Yikes! Seriously guys, implement a binary heap. It's easy and your pathfinder will be much faster for it!
I could indeed and thank you for the suggestion. However I'd need to be motivated enough to spend time submitting tickets (good tickets!) to a project I'm not currently invested in. Which I am not.
I guess the point of submission is to draw attention to the library and garner community comments. I feel I've made my contribution to that discussion.
This was pretty much my experience with getting a project posted in HN. A bunch of bugs reported in the HN comments, and not a single issue opened on GitHub.
Since I wasn't the one who posted it, the only reason I found the bug reports is because a friend recognized my username on GitHub, and sent me a message about it. I would have preferred bad tickets to total silence...
Replace file a bug on GitHub with sign in using Facebook Connect. Is the amount of effort it takes really the only conceivable reason someone could have for opting out? (And regardless, threshold of effort isn't even a bad reason for not doing something.)
> I feel I've made my contribution to that discussion.
Well, I didn't like the tone of your comment. People building such an engine obviously aren't incompetent, just because one part of the code you looked at wasn't as optimized as possible.
Thank you for the interesting video. The problem I refer to in the Godot pathfinder is not a case of premature optimisation; it's not (as discussed at 16:10 in your video) code whose performance is negligible in the overall scheme of things. It's the exact opposite.
A bad pathfinder will make it near impossible to develop certain types of games -- RTS games or any other kind of game where the map is of a non trivial size and there are agents making their way between changing pairs of locations. In addition, pathfinding is usually a fundamental operation in most of what passes for AI in games and it's not uncommon to see developers calling the pathfinder constantly, for example to reason about distances between things.
For most use cases someone doesn't need to run pathfinding operations every frame and someone isn't making an RTS, so from the perspective of the engine developer the best thing they can do is just a good enough solution that works well enough for most people. In the case where the pathfinder really does become a bottleneck the developer has the option to develop his own more efficient solution.
> In the case where the pathfinder really does become a bottleneck the developer has the option to develop his own more efficient solution.
Well, yes, but with respect you can make the same argument for any other subsystem. If simplicity is the only criteria I see no reason to bother with A* at all. Just implement a bug algorithm or even blind search and let "the developer" sort it out. But that argument isn't very compelling, especially as Godot is an engine whose main selling point is making game development easier.
Still not convinced? How about this: A* is supposed to run in O(n*log(n)). By implementing the open list as an unsorted flat array, instead of a binary heap, its runtime changes to O(n^2).
>Still not convinced? How about this: A* is supposed to run in O(n*log(n)). By implementing the open list as an unsorted flat array, instead of a binary heap, its runtime changes to O(n^2).
gradstudent, I understand the implications of making the algorithm more efficient. You're still not getting the point that the video I linked points towards, though. An inefficient solution works if it works well enough for enough people.
When you're building an engine that contains many moving parts you don't want to spend too much time optimizing each part to the best of your abilities because if you do that you'll never have a product that people can actually do something with. That's not even to get into the main point, which is that you don't need to run the pathfinding algorithm every frame and that most of the time it actually isn't an issue. So if you spend time optimizing it you spend time doing unnecessary work. The developer of the engine agrees with this notion: https://github.com/godotengine/godot/issues/11492.
Take the advice on the video to heart, gradstudent, you'll benefit from it immensely as a programmer.
> That's not even to get into the main point, which is that you don't need to run the pathfinding algorithm every frame and that most of the time it actually isn't an issue.
Irrespective of any other criteria, the algorithm implemented here is wrong. It's not A* but an inferior best-first derivative with much worse complexity. Anyone using this code and making face-value assumptions about its performance is in for a rude shock. The difference between O(nlog(n)) and O(n^2) is huge in practice. At the very least they should rename the class to avoid misleading potential users.
isn't just suffering from a poorly implemented A but employing
Had a quick look through the showcase, looks like mosty small indie titles or developers personal projects - which is cool, but have any larger games shipped with Godot? Any titles we might have heard of?
There are several big games published with Godot. The author used this program with his team to develop video games for his studio. Still not AAA but big enough to know it is worth it. Game maker suffered from the same criticism up until a big wave of popular games came out of it. You shouldn't judge an engine by the games made with it.
It's hard not to judge an engine by the games made with it... To me that's like not judging a racecar by how fast it goes, sure there is other criteria but that's the meat.
I think a better way to phrase it is that judging an engine by the games they've been made with it will give you an incomplete picture: you can only see what is possible, not what is impossible (and even with the possible, you only see what the people use it can do which is affected by their resources and their skills).
It is better to evaluate the engine yourself for the project you are planning to do with the requirements it has (not making the entire project, of course, but if you - say - want to create a huge detailed world you can procedurally place entities in the world and see how the engine copes with that and if it provides tools to address any issues).
GameMaker has been around since 1999 - if the engine is capable producing a hit game is simply a matter of time. The more time the engine has been around the more likely there will be hit games made in it.
>The more time the engine has been around the more likely there will be hit games made in it.
Really? What's the killer app for Dark Basic? I've never hated an environment more than that one. I would be shocked if anyone could put up with it long enough to make something good.
>You shouldn't judge an engine by the games made with it.
Most game engines have no games made with them - including my own garbage engine that I'm hacking on right now. I think you absolutely should and must judge an engine by, at the very least, whether or not games can be made with it.
And seeing what kind of games are made with it can show you what the engine is capable of, how well it performs, what sort of games it's optimized for, what the structure of its output is and how restrictive it is in terms of proprietary formats, what the development workflow looks like, etc. All of that requires example implementations to study.
I'm not sure Game Maker is - historically - a good example for this. (Not talking about current GMS 2 though, from what I've read it seems to be hugely improved in that regard!)
Its workflow is impressive, but epecially with the popular games it became apparent that lots of small annoyances people complained about/design decisions the developers were forced to make were tied to limitations of the engine (with a big one e.g. being a rather tight coupling of central game parameters like game speed, fps, internal resolution etc.).
How's Deponia? I picked it up cheap for PS4 but it's been in the middle of my ever growing backlog of games for awhile. Cool that it was developed using this engine.
How's the performance of the resulting games? With unity I've found that it's a mixed bag, but it's hard to know if that's the fault of developers or the engine.
Performance is fine in most cases. While GDSCript is quite slow it's rare to be the bottleneck. You can always port perfrormance critical code to C++ (or to basically any language in 3.0). You can try to optimize game without other languages as well. I'v got two examples:
- 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.
The problem with generic engines, is that the type of game has a diffrent performance requirement. RTS can live with physic-sim updates every 0,25 seconds, which is not usefull for a jump & run or fps game. Thus the highest requirement defines the engine, which is a complete waste for some games and limits performance.
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.
I think it really depends these days. You can make a lot of games in a general case engine up to and including those that you might think need a specific set of tradeoffs they might not provide adequately. At the same time it can be easier to not have all the unwanted cruft. It's about where you want to put the time and effort and I'm not sure that's very easily generalizable right now.
I do think Unity is beginning to jump the shark a bit with what seems like a stronger focus on ancillary services rather than their core offering.
I'm using this right now to write a game. I've never developed a game before, so I don't have any comparison with other engines. So far I like it. I'm not a huge fan of the IDE, but the gdscript language isn't hard to pick up at all, so I just avoid it and use vim. I'm excited to see where it goes as it feels like a great starting point for people like me who want to make a hobby game, but also feels polished enough that I could see a professional using it.
I recently bought construct 2 after trying many open source alternatives. The issue I have with some of the open source stuff is when you want to use pixel art - it insists on re scaling either the camera (in a 2d scene) or the pixel art itself. It's a turn off that stops me from going any further with the product.
I follow Godot since it got open sourced some years ago - great project.
What scripting language beside visual scripting does it support? Lua? Squirrel? or only C++? (I saw some screenshots there: https://godotengine.org/features )
Their stances haven't really changed, they introduced GDNative which is a system that loads shared libraries using a C API, which has made it easy to add and use any language (I'm guessing the original idea was to make using C++ in your game easier). Some guy made C# bindings with GDNative, so they're making it optional with the release. There's other languages you can use as well. GDScript is still the 'main' scripting language.
That's plain wrong. C# bindings have nothing to do with GDNative, it's a module on it's own, integrated pretty well and unlike things that can be bound through GDNative, Mono module will be a part of Godot itself.
My bad, there was a bit about C# in their article about GDScript on their website, read it wrong. You're right, took a peek at the code, it's a regular module.
> In fact, Godot was just a code-name for what would be something else, a more general purpose engine with a proper UI instead of a set of assorted tools. We knew it would take a long time, so we used a name based on a play by Samuel Becket to represent that feeling. Eventually the name would change to something with a connection to our home country, Argentina.
The 2.x series is current, but 3.0 which is in the final stages is a big upgrade, with physically based rendering, a lot better shadow system, support for multiple programming/scripting languages and a visual programming language (for designers and artists to use, though its fully capable large scripts are harder to do visually.)
Very excited about this project and can't wait for 3.0.