FEATURE: Making Your First Video Game - Part 2
So, following up on Paul’s first post, he is back with the final part in his series on how to make your first video game and his experiences in building his own – Zombles (Google Play – Free). Over to you Paul! While Part 1 focused on learning the basics of game development, Part 2 takes an in-depth look at making the small puzzle game Zombles. There are plenty of articles about the design successes of AAA titles, so as an alternative I thought I’d cover more about developing on a very small budget (under €150), as well as a warts-and-all look at the learnings involved in a first-time project.
The game concept (like Lemmings, but with smaller, non-destructible environments and player choice of abilities), and theme (a bit of a no-brainer *bah-dum-tsh* as there were plenty of pre-made zombie assets, and zombies walking to their death fitted nicely with gameplay) were chosen at the outset. The design had originally spoofed The Walking Dead, with the tagline “Ideal for when your favourite TV show goes on too long and you start rooting for the zombies”. Levels would progress through the various settings of the show and (non-trademark infringing) nods to the main characters or events. This idea was soon ditched once the amount of work involved in customising assets and varying level textures became apparent.
Early development progressed quickly and a basic prototype was up and running within a few weeks. With an affinity for programming functionality progressed steadily, however another major element of game development was completely alien – art. Unity Asset Store to the rescue. Pre-made assets can seriously reduce costs, as well as saving a lot of time. All kinds of assets are available for purchase (or some for free), including a selection of animated zombies and human characters. One element that’s easy to overlook is the interface – menus, buttons, score sheets, etc, however these also require a lot of artwork. Again, the asset store has a number of mobile-friendly user interface packages (some of which also have basic functionality integrated) to choose from.
The disadvantage of purchasing existing assets is that they can set a predefined look for the game. Rather than invest in editing them to create a unique look for Zombles, I instead decided to embrace the existing style and commission one piece of custom artwork inspired by the pre-made characters (for use in menus, app promotional banners, etc). Perhaps not viable for a AAA game, but a cheap and easy way to get a small indie title out there.
Budget tip #4 – Fiverr.com is a very useful website hosting a huge range of freelance artists with various styles. Matching the style of the pre-made characters with a few artists’ portfolios, quotes ranged from €30 to €200 for the custom artwork. The final cost worked out at €50.
There’s also https://www.airtasker.com/ which is a trusted community platform that connects people who need to outsource tasks and find local services. From simple to complicated tasks, Airtasker can help with marketing, writing, video editing, graphic design or even build a website.
Early versions of level designs, gameplay controls, zombie abilities, etc were implemented, however the amount of work involved in non-gameplay elements came as something of a surprise. For example, the “Level Select” screen unlocks levels as the player progresses, storing their score for each and only enabling them to play unlocked levels. A relatively simple scene not featuring actual gameplay, but still requiring a multitude of scripts; calculating scores to display on each level, storing progress in a file on the user’s device, unlocking levels sequentially, handling user scrolling input, changing buttons based on the level’s state, displaying ads at certain intervals, in-app purchase options to disable ads, and many more.
With so many functions, it’s easy for game-breaking bugs to crop up if a possible action is overlooked. Just a few real-life examples from the Level Select screen:
- What does the unlocking function do when the player completes the last level and there are no more to unlock?
- What score is displayed if a player re-plays a level and gets a lower score than their previous attempt?
- What happens when the player completes a level then quits the game before reaching the Level Select screen?
- What should the “Turn off ads” button do (or look like) if the user has already disabled ads?
Many of these can be identified, isolated, and fixed during development. Others don’t become apparent until people actually play the game. As a first-time developer I had family and friends who could playtest the game, however it’s also very useful to have a network of contacts familiar with the industry. Having learnt exclusively through online courses, this was one aspect I was sorely lacking.
Irish Developer Community
As a first step I participated in one of Dublin’s annual Global Game Jam events (Meet some people, form a team, and build a game in 48 hours. You can play our team’s entry here). Speaking to other programmers about a challenge with a game is hugely beneficial (“You could use a temp variable in a while loop to cycle through an array of bools on collision enter” is a great bit of feedback unlikely to come from a general playtester), and I would recommend Game Jam to anyone interested in getting into game development.
The experience also introduced me to some of Dublin’s wider developer community, for example the IrishGameDev Facebook Group which features a stream of discussion and monthly meetup events. The group is also closely intertwined with Imirt (Irish game developer association) and GameDevelopers.ie, which are great resources for discovering the budding community of passionate people in Ireland.
In January 2018 everything was coming together – most levels were complete, all art assets were in place, most bugs had been ironed out, and it was actually looking like a game. I had one main remaining task and then it was complete – playtesting.
With the prescription 20/20 aviator goggles of hindsight on, I can now see I was an idiot. I thought playtesting might mean I had to re-order some of the levels based on difficulty, tweak win criteria or level design, or change the layout of buttons based on feedback. Roping in a variety of friends and family to give the game a try, it immediately became clear that that wasn’t even close. A painful lesson to learn the hard way.
As a simple example – if the player chose to restart the level there was a 3 second on-screen countdown to confirm that they hadn’t pressed the button by mistake. By the time the counter had hit 2 seconds, every player had lost patience and hammered the button twenty times, stopping and starting the countdown until it crashed. There were also a myriad of issues when players pressed multiple buttons at once, and the tutorial had failed to teach the basics of the game (no-one reads tooltips – who knew?!).
The first level / tutorial would eventually go through four complete overhauls before reaching the final version. Playtesters had quickly revealed a poor design choice within the game. The first ability available to the player is the Blocker – freezing a zombie in place to redirect other zombies. This was chosen as it seemed the most simple of the available abilities, however does cause some issues in the tutorial. The ability freezes the chosen zombie right away, but the impact on the game doesn’t become apparent until a few seconds later when a second zombie interacts with the blocker (and turns around). Spamming the button can result in lots of zombies being frozen and the level having to be restarted. The first level of Lemmings, by comparison, lets the player use the dig ability, where the effect of a player’s click is immediately apparent and the level can be completed no matter how many times it is used.
Changing the first ability would mean a significant redesign and huge time investment, so instead the tutorial was adjusted to minimise the impact of the design flaw. An inelegant but passable workaround.
While 90% of the game’s code had been completed by the time playtesting commenced, tweaking that last 10% took another two months. Zombie abilities were adjusted, errors in design were patched (some players had quickly found ways to brute-force certain levels rather than find the solution), and a whole host of previously undiscovered bugs were fixed. As an Android game testing on multiple devices was also critical. One tester installed the game on their three year old phone and it did… nothing. I’d forgotten to compress texture files within the game, and any level with animated characters would overload an old phone’s memory and crash the game.
Monetisation & Publishing
It’s tempting to keep making little changes indefinitely, but even if the game was never really “finished” I was determined to release something. After the playtesting tweaks the only remaining element was monetisation – implementing in-game ads and an option for players to pay a nominal fee to play without ads. The revenue from the app would be negligible – Zombles is just a small puzzle game unlikely to receive many downloads – but it would allow me to test monetisation systems and make any mistakes before creating a game I’d hope to be profitable.
Google’s AdMob has a Unity plugin making integration of interstitial (full-screen between levels) ads relatively straightforward, and Unity’s in-build IAP (in-app purchases) system is very easy to set up. Implementing Facebook integration (to track installs from Facebook ads), on the other hand, broke everything. Finding and fixing bugs in your own code can be quite rewarding, but the complexity of these 3rd party plugins means rooting out the issue leads to having to trawl through endless internet forums of people experiencing similar errors. After two straight days of trying every possible solution on the internet, a fix was still elusive. The decision was made – no Facebook tracking for Zombles.
By mid-March 2018, the game was complete. After 4.5 months of part-time learning, followed by another 4.5 months of part-time development, everything was finally in place. The Zombles Google Play Store listing was put together with a few screenshots from the game, and on March 18th it was released to the world. In total, the game’s budget (excluding time spent – breakdown below) was approximately €145.
|Unity||Building the game||Free|
|Udemy courses x3||Learning how to use Unity and code in C#||€35|
|Unity 2D Game Kit||Level decorations and platform tilesets (from Unity Asset Store)||Free|
|Arrow Mobile UI||User interface sprites, menu images, and game canvas (from Unity Asset Store)||€15|
|Fonts||In-game text (including Zombles logo) from Dafont.com or websiteplanet.com/blog/best-free-fonts/||Free|
|Audio||SFX and music from Freesound.org||Free|
|Zombies Shooter Game Assets||All in-game animated characters and zombies (from Unity Asset Store)||€25|
|Custom Art||Background image for Main Menu, also used as promotional image (by demonicbrute on Fiverr.com)||€50|
|Google Play Developer Registration||Accessing and publishing to the Google Play Store||€20|
Zombles’ final budget breakdown.
Once the game has been live for a few weeks it may be worth considering porting to iOS – Unity makes this relatively easy to do, however Apple charge $99 a year for the privilege of developing apps on their platform. Again, with the game being so small it’s likely to be more of a learning decision than a financial one.
Having been through the process of releasing a game, I’ll now be going back and completing some of the more advanced online tutorials before embarking on my next game project. What form that’ll take I don’t know, but if I never see another zombie it’ll be too soon!
Questions, feedback, thoughts? Let us know in the comments below! You can also download Zombles for free via its Google Play Store page.