Hello, nerds! Today we’re kicking off the first in a series of Development posts about porting my first Android title, Dungeon Ho!, to Unity.
Dungeon Ho! was a Roguelike written for Android API level 10 and released in the summer of 2013. It did… respectably for a first solo attempt in a niche with basically zero marketing, but ultimately a bunch of design decisions that I’d made during development came back to bite me in the ass to the point where the planned ongoing addition of new content and features never came to be.
Here’s a screenshot of the game running in either Android Studio, Eclipse, or on my test device. I forget.
I’ve had a plan to do a sequel ever since I realized there were a number of ways I could have made the game better, both feature-wise and code-wise. After all, it was my first Android title and I’d learned so much since (mostly by leveraging the fact that I’d published an app to actually get a string of jobs as a professional Android developer, but I digress. Even so, Lesson #1: publish something! It looks great on your resume!)… but one snag came in the form of Unity, which I’d learned during a stint of downtime between jobs. Unity offered so much stuff in it that I could leverage to make great games, but the tilemap support was still in development and, at the time, didn’t seem that great. I revisited it recently, though, and that cinched it; rather than re-use my custom Roguelike engine (…which needed refactoring anyway), I would merely port the game to Unity.
Why. though? After all, refactoring aside, I already had an engine, right?
Well, yes. But here’s the thing; Roguelikes have a big audience, especially on Steam. If I could make a stellar sequel, and I did it in Unity, I could leverage the cross-platform building capabilities of Unity to spread it far and wide. I mean, I did already have one or two people ask me if there was an iOS version, so there you go.
Ok, now what? Well, the first thing I had to do in terms of tech (I already know my feature list) was to analyze the Android build and see where I went wrong, and what exactly needed to be re-done as opposed to just ported to C# from Java.
Here’s my initial list;
- UI – When I first moved to Android, I didn’t feel like it would be productive to spend a huge amount of time absorbing all of the new platform’s features. After all, by this time I had a large amount of J2ME experience and felt that I would be able to leverage my hard-won optimization skills to keep the game small and light. So, all I learned how to do initially was start a thread that would paint to a canvas, scale it to the size of the device’s display, and that would be enough. My main concern was that I had no hard data on whether mixing blitted bitmaps with Android’s XML/Layout-based UI would cause performance issues that I wouldn’t start seeing until riiiiight before release, because I was already developing on the Android emulator (I didn’t have a device yet) and figured I’d play it safe. In the long run? I wasted a ton of time rolling my own UI components when I could have totally just used Android’s dialogs, buttons, lists, text boxes, and other handy widgets. For the Unity port, I will definitely be leveraging Unity’s UI canvases.
- More robust Command system – To keep the amount of Java classes in the app fairly small, I chose to do a number of things with switch statements rather than polymorphism. This was fine when the switch statements only had a few branches, but the game essentially takes a different switch branch for every possible command in the game. This… got ugly. The Unity version will definitely provide child classes for the TurnCommand class, cutting down on the game loop complexity immensely.
- No class-based conditionals – “if (variable instanceof Class)”? Blargh! The fact that I kept checking the types of my objects told me that I’d blundered my inheritance chain somewhere.
- Better object spawning – For some reason, I chose to do the most basic of object initialization within the SpawnFactory classes, but setting other aspects of the items and mobs was done wherever said item/mob was spawned, leading to me copy-pasting various spawning boilerplate all over the place, so that when a bad spawn initialization occurred I would have to hunt down which spawn chunk-o-code was responsible. Making the spawn factory more robust, to allow specific kinds of object spawning as well as randomly-generated, is definitely going to be a must.
- String formatting, not concatenation – Ugh. With the amount of text in a Roguelike, you’d think I’d have been smart enough to use formatted strings, but no; I concatenated everything. The amount of time I spent tweaking my string cleanup routines to remove rogue spaces and such was… a lot more than it needed to be.
That’d do for a start. My next step was to decide on the overall application architecture within Unity. After a lot of pondering over things like persistent objects and scene loading, I eventually decided to just keep it simple and use a single Unity scene with a number of switchable canvases for the menus and information screens, both in and out of the game.
And, that’s basically where I am now. Tune in next time where I’ll go over the initial Unity coding, and how the various game objects (as well as GameObjects) are arranged.