I've been looking for a game engine for an upcoming project and I'm exploring using Atomic Game Engine.
The biggest hurdle will be the fact that Atomic Game Engine development has stalled, and very few people are actually using it. It also has some bit rot, primarily due to the fork of Urho3d not being kept up to date.
Note: We went ahead and published this blog entry in the hopes that it could possibly help someone, but it's incomplete in its current state and I'm not planning on finishing it. The toxic culture in the Atomic Game Engine community ultimately pushed me away, and so I eventually abandoned this project.
Although I enjoy writing new code, I believe I'll come out ahead if I use an existing game engine. Weighing the time it will take to learn an existing code base versus writing all the code from scratch, plus adding the time spent on all of the research that has gone into certain features, this is one of those instances of build vs buy where I'm inclined to buy. Especially since in this case, buying is free.
Even if I end up not using Atomic Game Engine, the process of learning the code base in order to get it to work for my project will teach me a few things that I need to learn. I need to be able to deploy a game as a web app (in both Electron as well as in a browser), and I'd like to learn how the Atomic Game Engine editors work.
Building on Windows
Building on Windows is pretty straightforward. You just follow the build instructions, which for the most part is nothing more than:
git clone --recursive https://github.com/AtomicGameEngine/AtomicGameEngine Build_AtomicEditor.bat --vs2017 --nonet
Add support for Visual Studio Build Tools
Except, I'm trying to build with Visual Studio Build Tools 2017, and not Visual Studio, and the build scripts currently assume you're using a full
Visual Studio installation.
I'm primarily a
Linux developer, so forgive me if I go about this the long / wrong way, but my first step was to add some debugging code to the build scripts.
The error message I initially got was related to build tool paths.
That error message occurred in several places, so I modified the build scripts to include some additional details, pointing me to the correct code path that was encountering the error.
Next, since cmake isn't included as part of Visual Studio Build tools since I didn't install it, I believe we shouldn't assume that it exists in the default directory, so if we can't find it lets just assume it's on the path already.
So, now that I've got everything building on Windows, my next step is to upgrade Urho3d.
I really want make this task more automated using git diff + patch, but so far I've not come up with a decent solution.
Normally you would create a
vendor drop branch, drop in the vendor code, and then merge it into your development branch, which is where you would make all of your custom changes. With this workflow, the next time you want to take an updated drop from the vendor, you would switch back to the
vendor drop branch, copy all of the updated files and commit them, and then switch to your development branch and merge in the
vendor drop branch.
This essentially allows the
vendor drop branch to retain diffs of vendor supplied code, and then you can apply those diffs to your custom modifications. You might get some merge conflicts here and there, but mostly it just works.
But, sadly, as far as I can tell, nothing like this was done with Atomic Game Engine.
My ugly solution went like this.
First step was to figure out the latest version of Urho3d that was incorporated into Atomic Game Engine. From the commit logs I could determine a relatively narrow time frame of the most recent Urho3d drop, and then inspecting commits from Urho3d I was able to narrow it down to exactly which commit.
Next, I removed all of the Urho3d source code from Atomic Game Engine (and moved those files to a different directory) and committed it. Then I created a
vendor drop branch, and after switching to that branch I copied in all of the original Urho3d code from the previous drop determined in step 1 and committed it.
For step 3 I merged the
vendor drop branch into my development branch and manually copied in all of the modified files that I had removed from step 1.
At this point I did a diff between the state of the source before step 1 (the original source code), and the current working directory. I fixed whatever showed up as differences and then committed into my development branch.
Now that I have my
vendor drop branch created, upgrading
Urho3d is as simple as typical vendor drops.
- Switch to the
- copy in the most recent version of Urho3d,
- switch to the development branch
- merge in the
- fix any merge conflicts
- commit the development branch
From now on, any time you need to update
Urho3d, just follow these simple steps and voila, you've got a fairly painless update.
After all of that, between the toxic culture of the
Atomic Game Engine chat channel, and ultimately being given other opportunities, it was a great learning exercise, but otherwise not worth the effort.