A few thoughts on Game Development

For those of you who follow my blog, you'll notice that I talk about building games, but I never really release anything useful or fully playable. I'm more interested in studying the individual parts of game development, without really caring about building a game as a whole. Well, for the most part this is perfectly acceptable, as I'm not a game developer by trade, and my bread and butter comes from being a utility developer. I've defined utility developer as someone who codes a variety of things without specializing in any specific discipline. As a self-taught developer, it's been hard for me to pivot into a role where I'm classed as a game developer by trade. This is all good and well, but I still want to talk about game development as a whole - specifically how to get a game off the ground. If you've been following any blog about game development, or any programming course which walks you through the process, you've most likely heard of all the jargon - the game-loop, the culling phase, rasterization etc. But what you've been deprived of is the most important aspect of developing the actual game - the Bible of game development, the be-all and end-all which can make or break your project. What could this all-important thing be which nobody seems to mention? Well, simply put - it's the spec document for the game. The game design document. I've seen many sites teach you how to make a game, but fail to mention that they're working from a spec (specification) - which tells them how each feature is going to work, how everything ties together. The spec document ties together which bits of the game interact, and also - and most importantly - defines the scope of the project. Without a spec document, many teams end up in a death march - adding features which won't really benefit anyone, without having a definite project scope to allow them to cull the fluff. This causes deadlines to be missed and projects to be abandoned. While one may argue that this is an archaic way of developing software, I'd like to argue that the spec document is very much alive - in Agile it's the "user story" and all associated notes which go with it. In more traditional projects, it's defined on some system - like Redmine or some other such software . . either way, there's always a definite set of features, a plan on how they will interact, and a deadline for when they should be ready. It's easy to suffer from featuritis (feature-creep or feature bloat) without a definite spec for a game, adding in features because they might look cool. I've done this myself - to some extent - just for fun. But if I were to attempt anything resembling a real game, I'd spend a definite amount of time building up a spec document - including storyboards for how I envision the end product. You see, with a standing spec (one that's not expected to change, and one that's to be adhered to) the developer can filter out all the noise and focus on simply building the features which have been clearly defined in their game bible. With a valid spec document, the developer doesn't have to think about which features to add or remove - the set is well-defined and should be fairly fixed for the duration of the project. And because all the features are mapped out, there's a clear interaction model which helps the developer understand how all the features work together. For example - I've recently started working on a spec document for a game I'm designing. Without a spec document I would've still been stuck trying to build it for multiple platforms, or trying to decide how to implement useless features. With a standing spec, I can clearly understand what the game should look like when I'm done, and how the features tie together. With my standing spec document I can make certain choices about how I'm going to implement the game - because I know a bunch of things in advance about the game. Let's take a short walk through one aspect - which platforms will the game support? Well, based on my spec, I expect the user to interact with the game using only 6 buttons [up, down, left, right; a, b] which can be represented using a joypad or joystick as well as 2 individual buttons. This layout is reminiscent of the old NES game controllers if you exclude the 'start' and 'select' buttons. Based on this information, I can make decisions on how to minimize my Time-To-Product, which is essentially how much time is left before your planned release date. Given my sparse input requirements, I can safely say that I *could* realistically support many different controllers, but each controller type requires a bit of code to tie the button mappings to the game. I will be working on the game on my own, and can't really lay money on the table to invest in different controller sets, so supporting controllers will have to go into the next release cycle. With the current requirements I'd wager that it would be a good bet to reuse a joystick component that I've already written . .but my joystick component is written in Java - easy enough to port, but why port it? If I have a reusable component, that gives me a visual joystick - developed for touch-screen games, you can see where this is going. Based on the game style, and gameplay mechanics - it would be beneficial to not have to worry about controllers and input devices, perfect the game would work nicely on touch screen devices. So, just based on having a high level overview of the game I can decide on the game platform. With the platform decided, I can focus on building an interaction that's tailored to that platform, instead of trying to write something so generic as to not be playable anymore. I know there are great success stories of platform-agnostic games, but they have teams, and I have me. With the platform out of the way, we can also start to revisit some of the user interactions - for instance, I've left a space open for 'special inputs' which could mean gestures - Android is great for this, and it's perfect for interacting with a game world since the user can gesture on in-game objects to get some kind of feedback. Non-android touchscreen platforms are also viable, but I'd like to keep my costs low, and since I don't want to pay $99 per year to be enrolled in the Apple Developer Program, I think I'll exclude that market demographic from my potential client base. This is not a stab at the demographic - it's a stab at Apple, if they open their platform a bit to be more inclusive, I'd be less angry with them - some of us are living in Third-World countries, and $99 could feed our families for a month. So, with this in mind, it stands to reason that I'd like to explore some game engines to simplify the process - instead of rebuilding the wheel, I could worry about the contents of the cart instead. I've found a few options that look very promising - oxygine (C++) and Gideros (Lua) seem to do the job quite nicely. With the time investment (minimal available time) I'd like to leverage some of my existing knowledge, but if the chosen language is less productive than required, then it might be beneficial to learn a more concise language to get the job done - that's why Lua is in the running. I hope this little thought-exercise has opened your eyes as to the kinds of high-level decisions that can be made when one has a spec document from which to draw information. Not only have we managed to pinpoint our exact platform - we've also managed to narrow down the list of potential game engines down to only 2 candidates, this is not usually an easy choice since there are literally a ton og engines out there - maybe I'll write a post on it next week - stay tuned to find out.