2022: A Retrospective(godotengine.org)
godotengine.org
2022: A Retrospective
https://godotengine.org/article/2022-retrospective
23 comments
> The code is usually just glue, and you aren’t hiring software engineers at crazy tech salaries to do that.
And the result is that there is no other software category that ships so extremely buggy code.
The code quality of games is the lowest I've ever seen.
Dynamic scripting languages only add to this overall mess…
The other problem is: Building a proper language and runtime is a full time job already. Adding this as a "side project" to a game engine (which is a very complex piece of code by itself!) is a big error imho.
I hope we see soon some strongly typed static language with very good type inference and a nice, clean, and simple syntax in Godot.
Would be than nice if Godot would concentrate on the game engine (and the editor) instead of trying to invent a language on the side also, as Godot as such is really great! One of the nicest programs I've ever used. (Especially compared with the incredibly buggy and terribly "documented" shit show that Unity is).
And the result is that there is no other software category that ships so extremely buggy code.
The code quality of games is the lowest I've ever seen.
Dynamic scripting languages only add to this overall mess…
The other problem is: Building a proper language and runtime is a full time job already. Adding this as a "side project" to a game engine (which is a very complex piece of code by itself!) is a big error imho.
I hope we see soon some strongly typed static language with very good type inference and a nice, clean, and simple syntax in Godot.
Would be than nice if Godot would concentrate on the game engine (and the editor) instead of trying to invent a language on the side also, as Godot as such is really great! One of the nicest programs I've ever used. (Especially compared with the incredibly buggy and terribly "documented" shit show that Unity is).
Games are also frequently going to be some of the most complex software you'll ever install. Bugs are just inevitable no matter what you do, short of writing games in Haskell (maybe), which sounds like a nightmare to me.
That said I've only ever used C# in Godot. Hasn't let me down yet.
That said I've only ever used C# in Godot. Hasn't let me down yet.
> Bugs are just inevitable no matter what you do, short of writing games in Haskell (maybe), which sounds like a nightmare to me.
Bugs are evitable. That's just a question of money. But yes, for games the cost would be to high usually.
Also I don't think Haskell would help much. (And it would be unusable most likely, imho).
But proper abstractions and strong types can help a lot!
On the abstraction side Godot seems great. But the scripting language (even nice in isolation) is not a good idea, imho.
Refactorings in dynamic code-bases are almost not manageable without introducing bugs. (Especially as you don't have proper tooling support without static types).
C# as such isn't bad. But it's syntactically unpleasant. Way to much overhead for game logic "scripting tasks". Still I would use it instead of GDScript. One needs proper tooling support when writing code.
Let's see what else will come up in Godot. They have some interface layer for other languages (even not fully supported with alternative languages).
Bugs are evitable. That's just a question of money. But yes, for games the cost would be to high usually.
Also I don't think Haskell would help much. (And it would be unusable most likely, imho).
But proper abstractions and strong types can help a lot!
On the abstraction side Godot seems great. But the scripting language (even nice in isolation) is not a good idea, imho.
Refactorings in dynamic code-bases are almost not manageable without introducing bugs. (Especially as you don't have proper tooling support without static types).
C# as such isn't bad. But it's syntactically unpleasant. Way to much overhead for game logic "scripting tasks". Still I would use it instead of GDScript. One needs proper tooling support when writing code.
Let's see what else will come up in Godot. They have some interface layer for other languages (even not fully supported with alternative languages).
Agree with this. I'm a huge proponent of static typing systems and good languages, so seeing Godot create their own language was a huge sticking point for me - I even created a typescript to gdscript compiler! But after a while, I realized that GDScript was remarkably productive, even though it lacks a lot of the bells and whistles that I'm accustomed to.
For a dynamic DSL GDScript is OK-ish.
But dynamic languages are a big horror when it comes to bigger projects. Especially when things get "reworked" heavily the whole time (as not uncommon with especially games).
But dynamic languages are a big horror when it comes to bigger projects. Especially when things get "reworked" heavily the whole time (as not uncommon with especially games).
GDScript seems very similar to a simple Python syntax. I really had no problem picking it up when working through some Godot tutorials. The syntax is so simple that if you ever needed to port it to another language it should be quite trivial to do so. I would be interested to hear the experiences and opinions of anyone who’s written a considerable amount of GDScript though.
GDScript is quite a bit better than Python in many ways. But to be fair Python would be a terrible choice.
Also the scripting language is tightly integrated with the C++ object model without a lot of binding code because they can rely on conventions in defining C++ classes and native facilities built into the scripting language. You don’t really need to develop native C++ extensions anymore but it’s a really neat system to work with when you do.
The goal is usually to have a scripting language for quick iteration to go along with something with better perf but needs a longer compile.
As you said, it's about empowering the devs, artists and designers, not about perfect code.
As you said, it's about empowering the devs, artists and designers, not about perfect code.
So you exclusively used GDScript? I find myself kind of on the edge of trying it out. I have experience with C#, so just wondering if it would be worth it.
I use it for 95% of the code I write. But then I have the occasional CPU intensive code and I drop into (attempting at the moment) Rust.
Note that I make toy games for myself. I can’t speak to games targeted for release.
Note that I make toy games for myself. I can’t speak to games targeted for release.
The code is not the value.
If the code is treated like that the result it that there is no value at all. Because nobody wants to buy buggy crap.
People don’t buy code.
But software products are made out of code. I hope this is no news.
Really glad to see successful games made using Godot like Dome Keeper. This helps signal to others that Godot is viable for gamedev and will probably have an added effect in its adoption.
I however still prefer to use Love2D as I found the code first approach works well with how I like to code games. The cool thing with Love2D is that there are a lot of libraries that you can use that help you save time.
It's analogus to Django VS Flask where Django is Godot and Flask is Love2d where you have to hand pick libs you want to use.
I however still prefer to use Love2D as I found the code first approach works well with how I like to code games. The cool thing with Love2D is that there are a lot of libraries that you can use that help you save time.
It's analogus to Django VS Flask where Django is Godot and Flask is Love2d where you have to hand pick libs you want to use.
Very much an aside and downvote if too much of a tangent - if I wanted to create a command and conquer like game (ideally like generals where it is 3d) - how would I go about doing that? Is Godot an appropriate engine for that?
Any engine is fine; the hard part is getting familiar enough with the framework to execute you vision on it. And developing the ancillary skills (broadly artistic talent/vision, and familiarity with art tooling) to do so. Or having someone else to outsource that to.
Unity has a much larger community and will have much more in the way of intro tutorials, so I started there.
But regardless of the engine you choose, you'll probably spend the better part of a year building tiny games (like tic-tac-toe -> pong -> breakout -> Tetris -> etc) before you can execute on anything more complicated (like a 3d RTS).
Unity has a much larger community and will have much more in the way of intro tutorials, so I started there.
But regardless of the engine you choose, you'll probably spend the better part of a year building tiny games (like tic-tac-toe -> pong -> breakout -> Tetris -> etc) before you can execute on anything more complicated (like a 3d RTS).
Any engine can work, there are advantages with choosing engines that people build similar games with. I spent ~6mo "adding" core engine features(LoD streaming, etc) to a UE3 open-world title because most of the games on UE3 at the time were very on-rails shooters.
That said I agree 100% with building tiny games in an iterative fashion to understand the engine you're using, or taking a very narrow "vertical slice" to help flush out where the technical or game mechanic issues will be.
There's a wealth of good engines out there today where you're building on in some cases literally decades worth of development that can accelerate a lot of the work involved in building a game(and there is a lot of work there).
That said I agree 100% with building tiny games in an iterative fashion to understand the engine you're using, or taking a very narrow "vertical slice" to help flush out where the technical or game mechanic issues will be.
There's a wealth of good engines out there today where you're building on in some cases literally decades worth of development that can accelerate a lot of the work involved in building a game(and there is a lot of work there).
Very possible! I'm in the process of building a C&C-like prototype, except 2D. I'm hoping to post a tutorial + code in a couple of weeks on our site (link in profile). If you want some assets to get started, you can use a free asset pack we released and the one I'm prototyping with: https://quiver.dev/assets/art-assets/outpost-assault-tower-d.... You'll definitely want to read up on the navigation system in the Godot and I imagine fine-tuning that will be a bulk of the work. If you have any questions, feel free to send an email (in my profile).
If you are looking for a 3D tutorial, this one seems pretty good: https://www.godotrts.com/courses/rts-game-development-course... (but I haven't used it myself).
If you are looking for a 3D tutorial, this one seems pretty good: https://www.godotrts.com/courses/rts-game-development-course... (but I haven't used it myself).
love generals, would also want to play it
I want to give some kudos to the author at being classy and not mentioning Unity's missteps and focusing on the good stuff they did internally. I've been impressed by how relatively coherent Godot has been and fostering the community around it.
But after spending time making some games for fun and learning, I realised: 90% of making a game isn’t coding. The code is usually just glue, and you aren’t hiring software engineers at crazy tech salaries to do that. You’re empowering your game devs to do it.
(Of course there’s a lot of more complex coding in many games, and there’s bindings for other languages when you need that).