Time for a new devlog entry. As I expected, I’m late and my proposal to write an-entry-a-week has failed from the very beginning… but with a ten-days-later entry, I’m close enough.
Somewhat.
During the #1GAM gamejam months I adopted LOVE2D, and I’ve been pretty much pleased with it1. Moreover, Lua is a powerful and nice scripting language that I really like to use.
Nonetheless, I wasn’t very at ease in developing the whole game with a scripting language. In fact, LOVE2D is more a framework rather than a game-engine. It would be more or less the same to switch to Python and use PyGame, or adopt C# and use MonoGame, or embrace Java (yikes!) and exploit libGDX.
Besides language and/or virtualization-engine choice, it seems just plain wrong to me to write critical game-logic parts (e.g. collision detection, path-finding, scene switching… just to mention some of them) in plain script language. Rapid script tweaking (excluding the initial developing phase) it’s not something useful in this case. These game-logic bricks are to be implemented in the fastest and more robust way possible, ready to be used when needed (e.g. developed in C++ and exposed to the script-side of the engine with a suitable API).
For a while, I considered starting yet another custom engine of mine, but I knew how it would have ended. Even using a state-of-the-art multimedia framework (SFML) and a rock-solid scripting language (Lua), the time spent integrating them and, more generally, working on the engine itself would easily overtake the amount spent on the actual game.
Stripping the engine to its bare minimum, by keeping the strictly necessary parts that handle the core game mechanics, is a valid option. In fact, reducing it to a custom game-engine tailored with the actual game itself has been done for quite a while (games in the eighties and early nineties were special-purpose single-use game engine). Anyhow this would render other aspects difficult to handle, such as the porting the game to other platforms. I’m mostly a Windows user, but I’d like my game to run on other platforms. While I could port the engine for Linux, MacOS is definitely out of the league (I don’t own a personal development Apple computer, and I don’t intend to explore more the Hackintosh side of the computing world). Not to mention, mobile platforms.
I really do like coding game engines. In a couple of months, I would probably end with working engine prototype. However, my primary aim is to develop and (most importantly) complete a game, in the scarce time I can distil.
Despite not being a fan of third-party engines (and libraries), preferring to write and exploit mine as much as possible for a number of factors, I began to consider using one of them. I should be something with a reasonable learning curve, and that might come handy as a prototyping tool in the future2.
Point is, there are really too many of them to choose from.
Unity and Unreal Engine can be dumped a-priori. They are indeed great pieces of software, but just way too overpowered for my needs. I would probably spend way too much time in learning on how to use them rather than working on the game itself. Yoyo Games’ GameMaker Studio 2 appears nice, with a complete IDE that covers almost every aspect of the game-development. Initially, I liked it and I was almost ready to buy it. But, after some experimentation, I found it cumbersome to use (it’s UI is convoluted, dispersive, and unintuitive… and the scripting language just doesn’t cut my mustard).
After quite a long research2, I found Godot. It’s still not very famous, but it’s quite promising. It’s a very light tool with a decently structured UI, features a Python-like script language (with C# support in the making), can be extended with C++ developed modules, supports both 2D and 3D, can export projects to all the major platforms… and it’s completely open. On the bad side, the documentation is a bit sparse… but it is very actively developed and it’s has a fast growing community of users and supporters.
At the moment being no commercial games have been developed with Godot, but that’s going definitely to change.
( We’ll be back after a short break )
1 Although I think that it would definitely benefit from switching from SDL to SFML. Also, updating Lua to 5.3 is something I would consider, even if Luajit is not available for it.
2 That means I could end up writing my own engine for the game if it’s worth the effort.
3 Other valid alternatives I found were Xenko, Defold, and Atomic Game Engine.