Hi, this is The Kid here at Red Gaming Tech!
I don’t often write articles for the main site, something I hope to change over the coming months, but here I am today to discuss my newly released Android game, Gumball Tumble. Some of you may remember a very early alpha of the game that I showed to Amata in an interview, back then the game was called Splooj, but I decided against that, it was a terribly silly name.
So obviously, the game is awesome, that goes without saying. It’s also free, so why haven’t you downloaded it yet? Go on, download it, I’ll wait…
Back? OK, good.
So I don’t really want this to be a shameless plug for the game, I wanted to make this article more of a retelling of my experience as a solo developer using Unity’s 2D features. The engine is something I’ve played with for a few years now, most of it being work on The 13th Doll which I have also previously spoken about. I like to think I’m pretty well versed in the 3D aspects of Unity, but when I began work on Gumball Tumble, I was a Unity 2D virgin.
So how does it measure up as an engine?
Very well actually. Most of the skills people who have used Unity 3D have developed are easily transferable to the engine’s 2D features. You can even specify when creating the project that you want to use the 2D features, and the UI will adjust to better suit 2D development. Starting with a blank slate can be daunting, but you can rapidly drag and drop art assets into the scene in almost any image format. Adding collision and physics to objects is almost a one click process and can be adjusted intricately with very little effort.
Constructing a scene literally couldn’t be easier in my opinion, it has the feel of almost being able to just build the scene as if you were using paper cut outs on a table. Animation is very code-light and uses a built in tool allowing you to create a visual state machine for animations, as well as being able to manage sprites and sprite sheets right from within the same UI. Motion for objects will require some coding knowledge, but the engine allows you to mix and match C# and JavaScript to your heart’s content, which is welcome as some things I am stronger with in one language than in the other. Gravity and external forces are largely automated with the ability to adjust them, but input and controls will require coding to implement. The other option is to use the in-built character controller assets that come pre-coded with a simple set of controls.
Touch input was something of a challenge for me as it was something I had never worked with before. Luckily Unity is well equipped to handle touches via the input library that comes with the engine. Touches are stored in an array, each having a state such as currently being touched and recently touched, this means that you can handle several touches at once and detect whether the user has just touched the screen or just taken their finger off of it with relative ease. Detecting a touch on an object is handled as a collision between a vector describing where the screen has been touched and the object’s collision box, which makes things like being able to bounce an object when you touch it very simple and fun to play around with. Particle effects are also enabled in 2D mode and are just as easy to implement as in 3D mode.
Gumball Tumble isn’t the most technologically taxing game in the world, but there were still times where I had to take shortcuts that I would have preferred not to. For example, it’s not easy to instantiate an object into a scene that doesn’t already exist in said scene. This meant I had to hide a lot of assets off screen that are using up unnecessary resources. The system for saving data is also not the most intuitive, so I eventually had to take a short cut and use the playerPrefs memory attached to each project to save data into. This memory consists of 1MB of data intended for storing user preferences and such, but it can be used for storing other data in a pinch, as well as being non-volatile.
The engine handles scripts in a very simple manner. You simply create your script file using your preferred IDE and then drag and drop it onto the object you want to attach that script to. You also have the option of assigning variables within the UI rather than in code, which saves some time. This modularity means that you can easily write one script and slap it onto multiple objects with a few clicks, as well as change variables from outside of the code.
When it comes to deploying the game to an Android device, the process is thankfully simple. You need to set a few build settings such as the app name, supported Android versions and bundle identifier etc. From there it’s pretty much one click, and the engine spits out an APK file. You can then copy this file to an Android device and install it there and then, which makes debugging and prototyping very fast and efficient.
Overall, I was pleased at how intuitive the 2D features of the engine were to a newcomer, even though I am already familiar with the 3D side of things. I can see myself going on to incorporate more and more of the features available in more complex projects down the line, but Gumball Tumble has been a pleasure to work on as an introduction to some of the features on offer.
Now if I could just come up with a sweet idea… Well, not literally a “sweet” idea, I hear that’s copyrighted these days…
I would also like to thank artist Olga Filipova, musician Dean Ward, and David Ratcliffe, formerly of SCI and EA (who will totally deny his involvement with Carmageddon 64) for their input and help with the project.
You can (and should) download Gumball Tumble right now from the Google Play Store here:
https://play.google.com/store/apps/details?id=com.atticdoor.splooj
