So, we decided to make a game. Simple, right?
When we started out, we had planned to create the game using the popular Unity3D (unity3d.com). This was around 2013, when the latest version of Unity was 3.5. It was especially attractive to be able to port between PC, Mac, Android, and iOS with the push of a button. At the time, not a whole lot of engines could do such quick and easy ports, which traditionally was very time intensive.
Unity is a primarily a 3D engine, which means it is capable of doing 2D, but at the time it didn’t support the design of a 2D game very well. For example, in many traditional RPGs, they use tile based maps (e.g., Dragon Warrior’s tile sheet – http://www.spriters-resource.com/nes/dw/sheet/10199/). That is, the whole map is divided up into a grid and the game designer chooses an image from a ‘tile sheet’ to ‘paint’ onto the map. Unity didn’t let you use tile maps, at least not in the way they were intended. However, Unity is a very extensible engine and has a huge community that develops plugins for it. So to make up for this lack of 2D game support, we decided to use the popular 2D Toolkit plugin.
Unlike vanilla Unity, 2D toolkit effectively supports tile maps and sprite animations – a traditional method of animating characters in a 2D video game (e.g., Dragon Warrior characters – http://www.spriters-resource.com/nes/dw/sheet/10197/). Sprites are 2D images that are quickly changed to give the illusion of animation, such as a character moving his feet while he walks, or in the case of Dragon Warrior, while he stands idle there looking like some d-bag on a Stairmaster. Ahh, those were the days.
We actually did a lot of work to generally make it look like and act like Dragon Warrior. I started first with character control, which was rather simple. Although, at the time, the character control was quite fluid in that it was not grid based, like traditional RPGs. Ironically, creating a true grid based system would have been more work, even though a grid based movement system could be considered ‘obsolete’ by today’s standards. We really wanted a grid based system but in the interest of time and functional prototypes, I decided to put that on the backburner.
After we had a basic character moving around our maps, I decided to create a dialog system including the cute little retro dialog boxes that print out the text like a typewriter. As simple as that seems, I really felt like I had to wrestle with Unity to get it to work. At the time, Unity had very minimal support for graphical user interfaces, and even the plugins we found, such as Daikon Forge, did not by default support the traditional menu system of an 80s RPG. So, I spent WAY too much time trying to get that to work. It finally worked, but it was a real pain in the ass. From there, I fleshed out the backend of the dialog system by basing it on XML, which is a markup language that could be used to model the tree like nature of dialog. So then, when you walked up to an NPC, you could talk, buy things, sell things, etc. Great. Oh yeah, I guess at some point I made an inventory system. So a character could have a sword, a shield, or a stat boost item that rhymes with barujana. Yay.
Since we had a functional dialog system with cute retro menus and an inventory system, the next task was to create a battle system. This was relatively simple to do actually, once we had the menus working. Again, I designed this similar to Dragon Warrior as a placeholder. But, I knew what we actually wanted was a side view party battle system, similar to the Final Fantasy series. Since the battle system basically worked, we decided to put the side view battles on the backburner. C’est la vie.
From there I went on to create a save/load system and the ability to move between maps. Again, I found it kind of annoying to work with Unity for this, since every time you load a new scene in Unity, it erases everything in the previous scene, including your character’s XP! So we had to do some software tricks to save data between scene changes. It worked fine, but it was kind of annoying to do initially.
At some point, I decided that continuing with Unity for this was going to be an uphill battle. It felt like a traditional 2D RPG was a square peg that we were trying to fit into Unity’s round hole. Then I got distracted by other things and development came to a halt. DUN DUN DUN! Oh no! What is going to happen to our lovely game? Is it fated to become vaporware? If only there was another way!
About 2 years later, Unity still didn’t support cute retro menus without a lot of butt hurt. Luckily, we did find another way… but it turned out that it wasn’t the right way either…
Stay tuned for our next installment of Adventures in Game Development!
-John