While not on the level of Blender, Godot is definitely turning out to be another really successful open source project. I've used Godot on and off since the 2.0 days and I've really liked all the improvements that have been made.
I've always struggled to use Game Engines though. I just enjoy doing stuff more manually I guess. It helps me keep the scope down when it's a challenge (for me) to get something a simple as Duck Hunt working properly. My current workflow is Raylib and D and it's been a great learning experience.
I know Godot gets a lot of flack sometimes for it's missing features, esp when compared to other game engines. But man everytime I open up any game engine, I'm just so amazed at how much easier it makes getting something up and running.
Definitely agree with you're last point, it makes it so easy to just get something on the screen.
I had written an AI for the board game Khet, but wanted an easy way for people to actually have fun playing against it. Godot was the perfect tool for the job to create a nice little frontend. And it was quite a pleasant experience to boot.
> I've always struggled to use Game Engines though. I just enjoy doing stuff more manually I guess.
But wouldn't the reasonable workflow to start with Godot, then gradually remove pieces of it in favor of your custom code? Or is it too tightly integrated that you would have to rewrite from scratch?
I will be the first to admit that the way I'm doing things is not conducive to creating something robust, sustainable, or actually allow me to ship a game like using Godot or parts of Godot would. But my needs are different then most. There are two main things I'm trying to get out of my work right now.
1. My main priority is learning the D programming language. Making games just provides a useful project/goal for doing that
2. My target platform is a Raspberry Pi 3 running Freebsd with about 400mb of ram free after all background processes are loaded. I want to develop _and_ work on my game on the Raspberry Pi 3, which means it needs to be performant and light on resources.
From the ground up I need to work with the Raspberry Pi's hardware specs in mind, or I will easily create something unplayable on it. Opening the Godot Editor on the Pi and trying to do any work in it is a painful experience (I've tried), but my workflow allows me to do this.
It's a full engine not a library you invoke. It is not structured in a way to swap out pieces bit by bit. You can use GDNative to write your game logic in stuff like C++ or Rust but it is tied to being invoked by specific parts of the godot engine same way the scripts are, so not really a good way to work towards swappable code.
Modern game engines aren't like libraries you link with your own code. They are entire systems your code runs inside of. A modern game engine is a lot more like an IDE and an entire operating system combined.
Just like you can't start writing a program for Windows and then gradually remove pieces of Windows, you can't not use the game engine.
> Just like you can't start writing a program for Windows and then gradually remove pieces of Windows, you can't not use the game engine.
Actually, you can definitely write a program for Windows; gradually replace remove dependency on Windows with multi-platform libraries; and eventually drop Windows altogether in favor of another OS. (Or even OS-less:
Unity is great if you're a beginner in game development and software development in general. You don't yet know all of the various things you need to make a game. If you're a beginner programmer, you will also struggle to build those things, once you do figure out you need them. So with Unity, you can get some really cool looking results up and running very quickly. And you can then make those results run on a variety of platforms that you can then show off to your friends/potential employers.
But if you are an experienced developer, Unity is a gigantic bag of bad conventions, with very little in the way of configurability (and that little of which being very poorly documented).
Unity the Company seems to optimize Unity for getting people up and running very quickly. They get you into their ecosystem and constantly tease you with "everything will be fine, just wait for us to fix this one issue". And you wait. And wait. And wait. And then they fix the issue. And introduce two more. Trying to build a professional-grade project in Unity was a nightmare.
LTS versions are way behind on latest hardware support, so if you're doing things like working on VR or AR projects (and I've seen estimates that something like 80% of all XR projects are built in Unity), then you have to try to surf the wave of latest releases to even have a hope of making a usable product.
A lot of the built-in features are designed in such a way that they only really make sense for small, completely encapsulated projects. If your game does not need to connect to the network for anything, if it doesn't allow for user-editable content, if it just sits there and does its own thing, Unity works fine. But if you have any concept of dynamic content, you'll be fighting Unity for the rest of your life.
For example, network requests, file loading, and texture and audio decoding all take place on the render thread. If you can get away with showing a static loading screen during that time, ok, that's fine, I guess. But in VR, you must never drop frames. That's really hard to do in practice even on ideal systems, so we do tricks like fade-to-black when we can't avoid it entirely. But you can't just leave a user in a blank, black void for several minutes while you wait for textures and audio you're fetching over the net to load and decode.
You want to make your controls remappable? You want to let the user pick the rendering quality level to match their hardware? Unity has default UIs for that! Oh, except they only appear in an application pre-launcher UI, that only appears on desktop PCs, if you have that option selected. Mobiles and VR devices, or VR apps launched from within the VR view get nothing. So implement your own. Again.
Hell, there are issues like certain app store platforms having minimum quality specifications that you literally cannot achieve if you have built your project following Unity's documentation. For the Oculus Store, your application must be responsive to user head motion within 3 seconds of the user opening your app. If you've followed Unity's docs, all of your game is smashed into a single Scene, where anything but the most trivial scenes on the most powerful hardware will take much, much longer to load than 3 seconds. So now you have to dig into the wonderful world of split-Scene architectures and how they prevent using half of the editor's property inspectors for making references across objects. No guarantees any of your dependencies even exist at that point, so you're left doing tons of runtime checks to make sure you can even proceed with running your program.
In my project, we wanted to build new levels and deploy them on-the-fly. Unity's means for doing that is the "Asset Bundle", which is basically "take Unity's proprietary binary format and chunk it around as wholly contained blobs." It's extremely inefficient regarding resource usage (got multiple levels that reference the same video file? Yeah, that's getting copied into every level). It takes running the Unity Editor itself to generate the blobs, so either your content creators need to be running Unity directly or any content development tool you make needs to interface with Unity's extremely poorly documented command line interface. I know of projects with web-based management interfaces where they have installed Unity on the web server to be able to do this.
Before I switched away from Unity, I had implemented a whole parallel system of texture and audio loading and decoding to end-run around Unity for this reason. Now you run into the malarky that is cross-platform support in Unity. For as much as they tout their cross-platform capability, it really only works (for static content) if you either A) again, are doing very simple things, or B) keep a bespoke, per-platform project directory for each platform. You can do it if you are super careful about using simlinks for your common assets (all the while ignoring Unity's dire warnings that simlinks are dangerous, figuring out on your own where the dangers are to sidestep them). Needing dynamic content, I needed pure-managed implementations of JPG, PNG, and MP3 decoders to be able to do this. Well, maybe I didn't need them, maybe I could have figured out how to bundle the native libraries for doing this across the myriad of platforms I needed to support, but as far as I could tell, if anyone is doing something like that, they aren't sharing how.
The UI system in Unity has been garbage for so long it has become a meme. Same for the multiplayer networking. When I finally got around to wanting to implement voice chat, I realized I had reimplemented so many of Unity's built in subsystems that it would be easier to reimplement the project using a library-based approach and reimplement the few subsystems I hadn't yet already done. Once I did that, project velocity improved dramatically.
I think a lot of people think to themselves, "I want my game to look beautiful, therefor I need to use a cutting-edge game engine developed by people who are smarter than me." Then they start with Unity and wonder why their graphics still look amateurish. The games market has done a great job at selling the idea that good looking graphics are the result of heroic programmers. But it's a lie, one that they perpetuate to ensure brand loyalty. Good looking games that perform well require great art assets, authored specifically for games, in simple game engines that enforce a very strict data pipeline. A general purpose game engine gives you the illusion of control. They give you this GUI editor where you can dump a bunch of assets into a scene, and it looks great on your dev machine, and then runs like shit on your target device. Because that flexibility the editor gives you is anathema to what it takes for good performance. So you end up working around the editor to get that performance back. So why were we ever using the editor in the first place?
If I were to ever use a game engine again, I'd strictly use an open source one, like Godot, just because then there'd at least always be an escape hatch.
You will have a very hard time because it has its own script (though I guess you could use C#) and it's very opinionated about lots of things like the node graph, etc.
Godot has support for many programming languages [0] through 'GDNative' which generally lets you access the API through any programming language that can bind to C++. I see that there is D support [1] but I have no idea how robust it is.
I'm happy to see that Godot community and development is increasing so fast. I just completed a 2D simple mobile game[1] with Godot and I had a greet time making it even trough I ran into a lot of issues.
Most of my issues were related to bugs with 2D nodes such as Area2D. The engine as a quite a few non-breaking bugs related to differents aspects. It's still very usable and very high quality for an open source software. I'm looking for v4.0 to increase the stability.
I will probably write an article about my user experience with Godot compared to Unity or Game maker and others.
What made you settle on Godot instead of any other engines? I'm looking into making a mobile game and I'm looking at Defold, Solar2D (previously Corona, heh), and Phaser.js all as potential rivals.
Defold and Solar2D both use Lua instead of a custom scripting language (GDScript) which appeals to me. Defold seems very polished, and includes infrastructure for ads and for Facebook games, which is ripe for monetising, whereas Solar2D is much more barebones.
Phaser.js seems like way more of a hobbyist tool than either of them, but I'm tempted just so I learn js.
Did you consider any of these before choosing Godot? Curious to know if I should go with Godo despite using its own scripting language which isn't useful outside of Godot.
I wouldn't get to hung up on GDScript. It works well and is well integrated into Godot. If you already have experience programming it will be easy to pick up. Where Godot shines is the ability to create something without a lot of code. This is a good thing because IMO the real time suck is creating assets.
I suppose I'm coming at it from a different angle - I'm expecting my game to flop, but want to learn something from it. I'd rather that something learnt to include a "real" language rather than a script designed for one program. Of course, that's not to say I'll learn nothing while developing for Godot, but it is a factor for me.
Well, you can use C# with mono or use GDNative. Personally, I think most are better off just using GDScript and focusing on their game. I say that because in r/godot there is always a lot of handwringing from newcomers who are wondering if they should skip ahead to something more advanced/common, but ultimately they want to make a game. If that's the case, I think GDScript is great. I think the real learning experience for any independent game developer is how to scope a project so that it is achievable with the resource constraints they have available. That's useful in all programming domains.
There are forks of Godot that use other languages[0].
You might still be able to learn algorithms and methods using Godot, but to me the primary reason to use a framework like Godot is to finish a game. You learn the framework to use the framework - the player isn't going to know or care either way.
When I first started the game I had no target platforms in mind. So getting an engine which would make the transitions painless was a huge benefit.
Now, if you only want to export to mobile maybe Defold is superior? I honestly can't tell without trying it.
BTW, Godot can work with GDscript or C# if you prefer. Also GDscript share a lot of it's syntax with Python.
What lacks a bit on Godot is mobile vendor integration. For instance to access Android services such as game service you have to use community plugins.
I choose Godot because I wanted to try it on a small scale real project.
I'm also curious about game engines and I'm wondering why you didn't list Unity. It seems like the default for a lot of mobile game projects. I've heard for 2D it's a bit of a glutton, since it's ultimately a 3D pipeline. Is that why?
Yeah that's why I dismissed it - way overkill, both in terms of resources used and the development (at least from what I can tell). It seems like 2D is an afterthought, with it just locking the camera in a 3D space to a particular axis.
Exactly. When using Unity it feel like I get too much for what I want. For me Unity is in this weird spot were it's suited for AA mobile game and AA 3D games but not so much for AAA games or indies were Godot shine.
Ahah oops, fixed! I wasn't aware of its Swedish origins, I kind of assume everything is American on the internet until proven otherwise (coming from a Brit)
Same, I'm not too far from releasing an MVP mobile game built in Godot, and the "time to game" as well as the burgeoning plug-in scene make it quite fun to get something working.
Does Godot still use a fairly fixed render pipeline and reduced shader language?
One nice thing about Unity's (frankly very inconsistent) shader language is how flexible it is. You can use any shader stage and even add GLSL pragmas etc.
I couldn't figure out how to do that last time I went looking in Godot. This really helped when trying to get new VR hardware working. I think its important to support this kind of stuff.
I guess not, because the article says this guy started working in godot 3 years ago while studying at university and this other guy in google scholar has been publishing since the decade of the 2000s. Joan Fons is not an uncommon name.
It's interesting how intuition for the normalcy of names depends heavily on personal context. I've gotten a "it's obviously a Jewish name" from someone in NYC. I had never heard either the first or second name and had no clue, but it might seem like I was feigning ignorance to someone from a place with more people from that culture.
Only one of Joan and Fons is familiar to me, and I've never seen them together until now. Now I know of two instances and learned there's a whole experience I'm not privy to where these two occur together often.
At least in Spain (mostly the Eastern coast), Joan is "John" and Fons is "spring" (water spring) and both are common there, not like John Smith but somehow like John Brown or Peter Miller.
I've always struggled to use Game Engines though. I just enjoy doing stuff more manually I guess. It helps me keep the scope down when it's a challenge (for me) to get something a simple as Duck Hunt working properly. My current workflow is Raylib and D and it's been a great learning experience.
I know Godot gets a lot of flack sometimes for it's missing features, esp when compared to other game engines. But man everytime I open up any game engine, I'm just so amazed at how much easier it makes getting something up and running.