Post Mortem: Drag – Part 1
Our game Drag was released on August 18th, 2017 on Google Play. That was a big milestone for us, because it was the first game we ever made publically avaliable.
After studying game development for three years, we decided to create our own indie company so we could release our own games without restrictions.
Of course we had some failures and some successes that we will now share with you. We hope you will not only learn from our humble beginnings, but also profit from the insights in starting your own business which we gladly share with you.
Starting the project
This was actually pretty straight forward.
We knew the most efficient way to create levels for this game would be a level editor with the same evaluation logic that will later be used to check if the player did everything right. I wrote this tool in WPF and added an embedded MonoGame window to show the level and make it interactive. Simple, clean, effective!
The handwritten level editor for Drag in its last iteration with loads of features
This editor got some more features later, but at this stage it knew how the game works without being the game itself.
App Development: First attempt
Because we knew we wanted platform independency in order to make sure we could basically publish the same project on iOS and Android without having to start all over codewise, we chose MonoGame for development. It’s very easy to get things done in MonoGame and since we used it before in other projects (and the editor), it was a smooth experience getting started this way.
MonoGame, an Open Source XNA implementation
After the first sessions working on the game were completed, we got the game running on Android using MonoGame and everything looked great. Well, almost everything that is. You see, we used two computers for development: A desktop PC and a laptop. Both run Visual Studio 2015 Enterprise for development and most of the time, it doesn’t make a huge difference on which computer the code is being written, but that suddenly changed.
I don’t own an Android device, I use an iPhone, so I can’t test the Android app on my own phone. Fortunately, Microsoft provides a great Android emulator, which is basically an upgrade from the Windows Mobile emulator. Unfortunately, it doesn’t work on the laptop for no given reason and at some point stopped working on the desktop PC aswell.
What really annoyed me is the fact that this dilemma stopped me from testing the code, without using the phone of someone else.
At this point we made one of the most crucial decisions for the development of the app: We scrapped the project ( keeping it as „DragLegacy“) and started from scratch in Unity.
App Development: Second attempt
So now we had to recreate everything in Unity. Quite a relief that Unity and MonoGame both use C#, so the whole logic could be copied over to Unity without requiring major changes.
Unity – The engine that powered Drag eventually
I created MonoBehaviour interfaces for the views and the scripts that required something visual going on. So after a rather short time, the project was completely rewritten in Unity. Unity had one very big advantage that speeded up our development tremenduously: We could create everything by drag and drop. Don’t get me wrong, I’m a professional coder, but even I prefer dragging buttons into a scene and clicking on „Add Event“ and drag a function from script A to script B.
Placing the button-logic and implementing it in MonoGame was a horribly tiring experience – lots and lots of methods simply stating things like „go to this screen“ or „set this setting“ had to be done. The code was filled to the brim with methods that did the same thing with small variations. All this stopped by giving the honor (or pain) to call and manage events to Unity.
Also: Placing a button on the screen is so much easier than writing coordinates by hand.
The screen transition
One of the signature things of Drag is its style. Every screen can follow another with a very simple transition that works in every occasion. To implement this, we had to create a single scene where these kinds of transitions were possible. This meant that we never used the scene transition feature in Unity at all.
| Fun fact: The app still uses only two scenes in total: One for the company logo and one for the whole game.
The structure within the app is very simple:
We have an omnipresent Leveltransition-Class that manages all the leveltransitions and has prefabs linked with names by using a dictionary.
Every screen has a root component called PhysicalView, which is used as a base component for screen transition and basially manages the features that all views have in common, like the color for the elements on display.
The transition between Loading and Main Menu in the Unity Editor. The PhysicalView-component handles the most basic stuff, while the SplashScreen- and MainMenuView-Component handle special stuff like the behaviour of the back-button on Android.
After this point it becomes mostly individual. There exist MonoBehaviours for every single view which control the inner workings and manage objects. These can range from being very simple, like the ones used in the shop, to those managing lots of ui, like the one in the settings and of course very specific interactive ones like the one used for the game screen.
Part 2 coming soon
In the next blog post, we will talk about the artstyle and how it developed, the rendering and the translation! Read it here: Post Mortem: Drag – Part 2
You have no idea what the article is about?
Check it out:
