As game developers, our main goal is to make games, and fun games. And by fun we mean games we want to play and games that will be dowloaded and played by others consistently. For the purposes of this article we are not going to dwell on all aspects of game development – from coding to play-testing all the way to marketing. We will only focus on development aspects because these are the areas we as game developers can control and cannot be affected my external factors or luck. After all whether your game gets 1000+ downloads on its release date is due to many factors. These factors will generate their own set of headaches so it would be best not to focus on them at this time.
However, you can control gameplay mechanics – if you want the game character to move left or right depending on the intensity of the swipe of the screen (for a mobile game) you just open Xcode (or Android Studio or any other IDE) and code the damn thing. Whether you succeed in this attempt might also depend on the number of brain cells you have but we assume your brain is perfectly equipped with these otherwise you wouldn’t be reading this article.
The game development landscape has changed quite a bit. We now have countless of avenues that can be used to release our games for instance Steam, Google Play, and App Store to name a few. Literally thousands of games are released every day and there is no such exclusivity and scarcity of games like there was in the past. In the early-to-mid 90s if you wanted a free PC game you had to scavenge your way through shareware sites and you were lucky if any of the titles available tickled your fancy. We now have an irresponsible overload of games and the result of this folly is that Google Play and App Store have become graveyards for the majority of games that are released every day. There are just too many games out there. Sometimes I ponder why we haven’t faced a mobile game industry crash like we did with video games back in 1983 (thanks Atari!).
Even if you (as an independent developer) think your game is solid and “fun”, there is no guarantee that your precious little addictive game will not be at the bottom of the App Store rankings and fall into oblivion together with thousands of other orphaned titles. The basic lesson is that game development is hard not because coding is hard but because game development is an intractable medium with success factors that cannot be easily controlled. And we have to learn to live with it. For many aspiring developers months of sweat and blood during development hells amount to nothing. Titles are released by countless of established companies or independent teams with the uncertainty of Julius Caesar crossing the Rubicon. You push the Archive button in Xcode with high hopes to release your title to the App Store and literally alea iacta est, the die is cast – leaving almost everything to chance and leaving your hundreds of hours of development at the mercy of App Store ranking algorithms.
My wish is not to alarm readers – I am just basing the above observations on previous experience. In a nutshell the main lesson is that game development as a whole is hard albeit fun and rewarding and we should be prepared to navigate the harshness of the terrain ahead throughout our game development journey. This demands a different kind of mentality. Understanding the uncertainties ahead we have to cherrypick our battles wisely and know what to focus on when we sit down and open Xcode to start developing.
As a game developer it is very easy and quite tempting to get bogged down on unnecessary details such as the technical intricacies of developing a new “font rendering library” or a “special effects/particle rendering system” for our little game even if it sounds fun to write and perhaps because I could potentially learn something useful from writing it. We sometimes face Developer’s FOMO (Fear of Missing Out). If we don’t know something inside out, or if we don’t develop it ourselves we don’t feel in control. Using someone else’s library or SDK equates to surrendering control to a 3rd party who is a subject matter expert in a specific area, and this thought hurts our ego. We are even prepared to think: “That random guy in Ukraine created this beautiful PNG compression library for hardware accelerated games which I probably need for my game. He built this library with his bare hands, so I can too! I will probably learn something cool and useful along the way!”. These internal monologues pigeonhole us into unrealistic and inefficient paths – further detracting us from our goal to focus on more value-add game development activities for example pure gameplay mechanics.
We even make ourselves believe that some 3rd party developer’s highly acclaimed font rendering library could become obsolete or deprecated in the future and create a potential external dependency. An asteroid could also fall on the 3rd party developer’s head and kill him and that would be a frustrating inconvenience – who will support that library in the future? Better to write it ourselves right? We dread having to deal with these external dependencies and factors so we have the temptation to avoid them at all costs. The worst thought of all is thinking we need to write something ourselves because we could potentially modularize it, package it and use it in the future for another game. Maybe even sell it! The possibilities are boundless! Chances are your nice little font rendering library works fine for a subset of use cases isolated to your game and cannot be used a second time because your next game might have different font rendering requirements. Chances are that perhaps you are never going to build a second game because you wasted all of your energies writing foundational engine code, recreating graphics, physics and all other core libraries yourself and no longer have the stamina to focus on gameplay code for your hypothetical second game.
Our optimism and wishful thinking clouds our judgement and we easily lose interest or get burnt out along the way. We end up with games made up of 70% foundational engine code and 30% half-baked game play mechanics because we didn’t have the discipline to focus on gameplay code – we have no gas left in the tank because we focused all our energies on library and game engine development and nothing else. We end up with half-finished prototypes or nifty technical demos that only we can admire in silence as we secretly pat ourselves in the back on a job well done. We are delusional to a certain degree. We admire the intricacies and the complex moving puzzles of our custom-made particle rendering system even though users are not playing (or reviewing) our games over and over again due our special effects library’s ability to render 50K particles in a single frame with ease. It’s how gameplay mechanics interact with other technical subsystems to provide players with an overarching experience that is fun, challenging, rewarding, immersive and stimulating. As game developers this should be our sole focus.
At Helldorado Team we’ve fallen prey to all of the above fallacies during the past several years and we would like to share our experiences answering the to build or not to build question in our past game projects whenever we’ve faced a decision to build core engine code. Stay tuned for more.