Project Setup and Build
This post takes a look at our project setup for building Much Dungeon and some back story on how we got to where we are now. We think our setup is probably a little odd and our story a little entertaining, but we can do some cool things.
Backstory
Much Dungeon started like all the best projects do, as a ‘hey we should make a game’ in a bar. The original version was just a PC game using Java2D for rendering. We stayed PC only until enough rough gameplay was prototyped to prove we really could make a game.
After the prototype was far enough along, we started looking into what would need to change to be a more “proper” game. We decided we should release on Android since we were Java based, switch rendering to OpenGL for speed and deployment, and avoid a PC release to keep things simpler.
Goals
We didn’t quite nail the ‘avoid PC to keep things simpler’ part though. During the prototyping phase, we built and used an editor for managing our game config. As long as we were running on PC, we could make config changes and immediately try them without having to make an Android build or in some cases even restart the running game.
So, our “real version” goals were:
Switch to OpenGL from Java2D
Target Android for release
Keep using an editor for all config
Keep an internal only PC version working for dev
At first, this meant we were basically maintaining 3 semi-related projects that had a lot of copy/pasted code that was slightly modified for where it was running.
Project Setup
Since the PC version of the game was written in Java, that meant most of the code would work as-is on Android. We just had to work around platform specific pieces for rendering, config loading, user input, and audio. Some fairly major components of any game.
Our base project, “Core”, has all the game code. This is the engine and everything that is the game. Any code that would end up making a platform specific call is calling a wrapper instead and platform specific pieces are in separate projects. This means we also have a PC and Android project.
The PC project depends on Core and has all of the config editor code as well as the wrapper class implementations for running on PC. We switched from Java2D to JOGL for the PC graphics. This lets us use the same OpenGL rendering routines but make the platform specific calls through generic wrapper classes.
The Android project also depends on Core and contains the Android specific wrapper class implementations. There isn’t an Android editor so this project is actually really small. After getting user input, sound, and graphics working on Android, any new game feature is almost entirely done in the Core project. (Side note - it did take quite a while and multiple passes to get the Android project as small as it is now.)
We have another generic project that contains all config for Much Dungeon. No code lives in this project. It’s only used as a container for config and a place to run the editor in.
Per project class counts:
Core: 1174
PC (with editor): 343
Android: 24
The Cool Things
Since the majority of code used on both platforms lives in Core, we can confidently develop new features and test config without ever having to push to Android. This saves us a ton of time and makes experimentation quick and easy (ish).
To release on Android, we do the following:
Build Core
Export config, audio files, and texture maps from our editor to the Android project.
Build Android
Done
The editor itself is really where the cool stuff comes in. Since it’s built into the PC project, we can hot reload config changes and immediately test things. This makes things like boss fight creation or npc behavior tuning much faster than if we had to push to a device to test.
Things That Sucked
Our initial plan was to just write our own engine because it would be fun to make and faster than learning another game engine. After all, we’d be done and released within just a few months. Now, a few years in, the custom engine will hopefully pay off by releasing multiple games on it.
The config editor has been both a blessing and a curse. Custom editors are way easier to use than hand editing config files or hard coding game behavior. However, we could have saved months of development by not creating it. This is another - hopefully pays off with multiple games.
Not requiring the PC version to be release quality has helped a bit, but getting driver classes setup properly to work on both platforms was tough. This is especially true with the audio system which is basically tailored to work on Android and then hacked up so PC can plug into it in a similar way.
There’s also a big difference in performance between the 2 platforms. Garbage collection on Android is slower than PC and there were some minor OpenGL tweaks that made no difference on PC but had orders of magnitude speed ups on Android. We’re planning a future post about performance, so I won’t go into this too much now. Luckily, we’re just a top down tile based roguelike - so we don’t require any record setting performance.
Almost Done - Promise
All in all, this has been a really fun experience. If you’re on the fence about making a game - find some friends to be involved and keep you motivated - and then go do it.
Just maybe don’t shoot for a custom multi-platform engine with a hand built editor for all your config from day 1 - but if you do end up with one - go with it.
Comments