Game Dev Part 3: Starting the Game Framework
In our last post on creating the game architecture for our high level classes, we discussed a number of design decisions about our game. While the details will be important, almost all games have the same basic structure, so I thought we’d get started on creating that in parallel with our creative process.
Usually, I build out the skeletal structure as I’m doing the creative process details. As a reminder, here is our structure:
Main.lua in Corona SDK
In Lua, everything starts in your main.lua file. Most people will probably put a lot of logic and variables in this. We use the main.lua file strictly to launch our application and leave the rest of the logic up to the Game Controller, which we’ll create a file for called GameController.lua.
This is all we have in the main.lua file. It simply declares a function, and then adds an event listener that gets system messages for when the application starts, exits, suspends and resumes. For each of these states, we either save or load the data. For example, if we were in the middle of a battle and our game gets sent to the background, we’ll need to save the current state of the application to a file so that we can resume in the same place, even if the app quits completely. These might be things like current health, time, which enemies are still active, etc. When the application resumes again, we reload this data and we’ll check it later in the code to see what our state was, so we can handle the loading of that screen, just as if we never left.
If the application starts up, and there is no data, that means it is the first time we’ve launched our application. We call a special function in GameController.lua called firstLaunch() to handle this. You could put this logic in the GameController’s main function to make main.lua even simpler if you wanted but by testing for nil, we can handle it differently if your game had different needs.
First Launch
This first launch function might include a quick tutorial overlay to introduce the player to our game. Always after that, we save the data so the next time the app starts, data will be loaded in and firstLaunch() won’t be called. First launch may do other things like setting up and writing settings files, but we’ll want to separate out the logic for overlays and other things into other functions so that we can reuse them later, if the user wishes to go back through the beginning tutorial. In other words, if the user wants to revisit the tutorial via a menu item, we don’t want to run through all the first launch logic like creating settings files, user names, etc. We’ll simply want to call something like showTutorial() in order to bring that feature up. It’s important we separate out these steps for later use in the app. You never know what you’ll end up reusing or accessing from another execution path.
System Events
Finally, we print out the event.type variable if it is not nil, in case you’re interested in handling additional system events that Corona sends your way. In our case, I’ve simply commented out the print statement but keeping the handling of system events in one place is a good idea. In our case, we’re forwarding the handlers to our GameController since that’s acting as our master controller.
Game Stats
You may have also noticed we made a call to getGameStats() to serialize and deserialize our data. This returns the Game Stats controller that holds all the information about our game including character stats, level stats, scores, and everything else we want to keep. This will talk to our storage controller to read the file information and then put it into a format. We’ll also have a level loader, so we can load things such as those one at a time from storage.
Game Dev Part 2: Beginning Architecture
Now that we have the basic game play of our mobile game, as we discussed in part one of our game development series, we can begin to architect the game. We’ll start at a very high level and work our way down to the details. The way we do that is take the biggest chunks of the game and separate them out into their own classes that will perform specific tasks.
Overview
As we mentioned in our last installment, our game will be a turn-based combat system. I first thought about having the main character’s home be a sort of base to defend, in a tower defense-like sub-game with additional element such as exploring the surrounding area, along with our combat system. While some great ideas came out on paper, I could see it quickly got out of hand to begin to program that. However, I continued to create the “ultimate” game and didn’t let myself be too worried about the programming. After I had exhausted ideas and creativity (sometimes that happens pretty quickly), I pared down the offerings and got rid of the tower defense idea (maybe in the sequel) and the other fluff. If we had the budget and the manpower, we might accomplish that, but given the budget and the time constraint, we’ll make this simple and hopefully still fun. The exploring a map part came back to a game like The Adventures of Link or Final Fantasy, where the character walks around a 2D map encountering enemies. I’m ok with that and drawing inspiration from games that work is what started this whole thing. Our game won’t win any awards for originality but that’s ok too.
High Level View of Our Game Classes
So we have two main parts to our game: a part where the player explores the city and the combat system. As the foundation to our game, we have the following base on which to build our game:
Game Class Diagram
- A Game Controller, the main controller of it all. This class will controller the main aspects of the game such as starting the game, which screens to present, and handling other organizational tasks. This is a singleton class that we can access from any other class to interface with it’s public methods. This is different from a global class in a number of ways. We’ll go into this in more detail later.
- A Storage Controller will control loading and storing various aspects of the game. We’ll tell the Storage Controller to get us things and we’ll tell it to save things. We don’t really care how the Storage controller does these things, just that it does and does them well. Likely, it’ll be to a custom file that we write that’s stored on the mobile device’s memory but it could just as easily be to a database, a network or external storage. By abstracting this system, we can plug it into our future games.
- The Display Controller will handle things like displaying items to the screen and removing them. We can build in some utility functions like fading in and out views. We’ll go through the Display Controller whenever we want to display our items. That way, everything that has to be displayed will be in one place. If your familiar with Corona SDK, under the hood, this controller will manage our Display Groups, animations and other display properties and organize them into screens.
- The Combat Controller will handle our combat scenarios. This has to be stand alone so that during testing, we can simply pass in a bunch of inputs and begin our battle. The way this will work is, we’ll launch the app, and instead of going through the usual paths, we’ll construct the data (enemies, player stats, level, etc) and then pass that all into the combat controller, straight to the fight. Then we can test the combat system and tweaking inputs without having to go looking for a fight every time.
- The City Controller will allow us to place our player in a city to explore. Again, this will need to be stand alone so that we can use different inputs to put our player into different scenarios. We can also manually change the files that the Storage Controller uses to advance the player through the game without having to play through it every time.
Of course, we won’t build everything into these controllers as they would become huge and unmaintainable, let alone buggy, but those details will be built out later. This is a good start and will allow us to start work on the individual pieces.
Our player will be either be in combat or exploring the map. Other interactions, like scavenging (this is a post-apocalyptic game after all), interacting with items and people or reading some part of the storyline are all secondary screens that will be shown on top of the combat or map. Menus and other things will work in a similar manner. These are sometimes referred to as modal windows since they will go on top our main display and capture all the interactions. These modal windows will likely have their own controllers or be grouped into controllers that make sense. These will all be organized by the Display Controller, so we’ll always know what’s on the screen and we don’t have to figure out if some lonely class somewhere deep in our game, is displaying something we don’t know about.
As we’re still in the planning stage, we’ll hold off on starting the code just yet until we build out some more diagrams. However, we won’t build out a diagram for every single class we need as things will likely change and will be better changed in code. Think of this as outlining a school report. These are just the main things we want to talk about and we’ll include some of the sub-items, but we don’t include every detail. Soon, when we start the coding, we can look back and see the general blueprints of how we build everything out.
Game Dev Part 1: Starting Out
Welcome to the first part of our series on developing a game for iOS and Android. We’ll go through the process of starting from scratch: developing the concept, planning, architecture, graphics, testing, deploying the game and more. This is a full featured game, not a simple demo game. While the series will touch upon a bit of code, it’s not going to be code intensive. We’ll use code snippets to simply illustrate concepts and functionality as we build it out. Hopefully, everyone can follow along and see how we develop games.
The beauty is, we don’t already have everything planned out, so you’ll get to see us come up with solutions, change direction, refactor code, and maybe make a few mistakes along the way.
Be sure to subscribe to the blog or like us on Facebook to follow along. I’m also on Twitter.
Start Early, Start Often
The decision to start a game shouldn’t be taken lightly. If it’s your first game, start small. Potential game developers tend to be overly ambitious and get quickly overwhelmed when the reality of the creation hits them. While we’re not necessarily veteran game developers, this is not our first game. Even so, we’ll start off small and iterate to show how we approach development of this scale. This is our approach but certainly not the only one.
Coming Up with the Game’s Theme or Story
It’s extremely difficult to sit down and come up with a game in one sitting. For me, the process involved looking at a lot of games out there and picking my favorite elements of each, and thinking about how that would be built out. Whenever I see apps or games, I always think how it’s built and try to dissect it to see how someone might have built it out. I also couldn’t get it out of my head for the longest time, so I knew the motivation was there.
I’m a fan of post apocalyptic movies and other media (George Romero movies, The Walking Dead, etc). I find it extremely interesting, as a programmer, that if the world as we know it ever ended, what would a guy with computer skills do? I’d be one of the least useful people with that skill set. This is something I’ve been thinking about for years and have a real interest in.
I also love the Final Fantasy type games. The XCom series of games are still my all time favorite. Both of these games are role playing games (RPG) with turn based fighting, albeit very different approaches. This breaks down into having characters that all have characteristics and a fighting system that uses those characteristics, mixed with some randomization and probabilities and enemy intelligence (we’ll cover the topics of combinatorics and computer AI in later posts).
So, I want to build a post apocalyptic role playing game with some turn based combat. That’s a great beginning and it’s all we need to get started. Story is important, as well as depth of game play, replayability and ultimately monitization, but that’ll come later. We might even decide on a different combat system as we flesh out some of those details. We haven’t started coding yet, so changing our mind is as simple as crossing something out and writing down something new.
Requirements
We want to build the app for iOS and Android. While we could do this in OpenGL ES, we’re looking for a little bit of a faster build time and 3D graphics might be over kill for what we’re building, especially if we don’t have a 3D artist to help. In our case, we actually do have a 3D artist, but that gets expensive very quickly. Instead we can stick with a 2D game, and fake the 3D by scaling objects down that are far away and scale them up as they approach the screen.
Again, we don’t want to spend forever building this out, so let’s use an SDK that allows us to code once, and build natively for both. In this case, we can use Corona SDK which allows us to code in the programming language Lua (usually used as a scripting language for gaming engines) but compile to native Java and Objective-C for the Android and iOS platforms respectively.
We’ve used other SDKs in the past, but Corona SDK allows us the fastest build time while still leveraging hardware features of the two platforms. This is something HTML5 can’t do yet and the experience is always subpar.
We’ve been using Corona SDK for years for our previous games, but I’m not using it because I’m familiar with it. I invested a lot of time in learning Libgdx and figured I’d be alright deploying just to Android since its iOS capabilities are brand new and not mature, and require an additional $350 license for a 3rd party to make it work. I don’t like having to jump through hoops with my tools. So it wasn’t the right tool for the job for that, as well as other reasons. Corona SDK, while it doesn’t have the 3D capabilities that Libgdx has, we don’t need it for this particular game.
Budget
We have designers, but they cost money. We have 3D capabilities, but that costs money. We need an SDK to build fast 2D games, which costs money for the license. We need sound and music, which costs money.
To get started however is free. It doesn’t cost us anything to write down our ideas, architect the app and build the story. Even then, to use Corona SDK, is free until you want to deploy and test on a device (something that’s only needed right away if your app uses the accelerometer or other hardware specific features like that, that the simulator can’t simulate).
SDK
For the Corona SDK, we’ll eventually need a license, which is $349 (cheaper if you’re a student). But since we don’t need this until the end, this won’t stop someone from building a game.
Music
For past games, we’ve budgeted about $250 for quality, royalty-free music and sounds. Of course you can always find free music and sounds, and this may be more within your own budget.
Graphics
Most games require custom graphics so this is going to be the biggest hit to our budget. Since we don’t know what we need yet, we’ll pull from past experience and try to limit our graphic needs to about $1,500 for now. That may be unrealistic, but we can work within that limitation and work smart to keep that price down. If you don’t set boundaries early, you’ll find things tend to balloon quickly.
Programming
In reality, this would be the biggest expense. Since I’m doing all the coding myself, it’s technically free, but I do hope to get paid and feed my family. I’ll keep track of my hours for development (something we do for every project), so I’ll know the theoretical cost of development. It’ll also give you an idea of how long each thing takes to build out.
Financial Projections
If we sell the app for $0.99, we’ll have to sell 3,030 copies to make $3,000. If we sell the app for $1.99, we only have to sell about half of that (1,508).
I’ve created a spreadsheet to illustrate this for more combinations of prices. I also included time, to show how many months it’ll take to recoup that cost, based on average app sales per day. For example, if we only had 5 app purchases a day, on average, it would take a year to recoup that cost at $1.99.
If we do decently and we can get 50 downloads a day, we won’t need to worry about the cost as we’ll recoup that in our first month. After that, we’re still only making $25,000 in a year. It’s not hard to get 50 downloads a day, but it does take a lot of work.
As I like to say, it takes a lot of one dollar downloads to make a living. In the above case, we’re simply talking about costs, not profit. After costs, comes the profit of course. You’ll have to determine how much money you want to make, or how many downloads you think you’ll get and see if it makes sense for your budget. If not, lower the budget. But it’s a good tool to firmly plant you in reality.
Game Revenue
As I said, I’d love to make some money instead of spending it (we are a business after all), so how do we monetize it? I’m a little sick of companies offering games for free and then nickel and diming you for every little thing. Does it work? Oh heck yes. Does it make for a good gaming experience? Not really. People will pay for good content, so let’s focus on that first.
As we build out the game in more detail, opportunities may present themselves that make sense. Otherwise we’re not going to shoehorn something that doesn’t match the game model.
Market Research
Does a game like this exist? Simple answer: yes. So what makes ours different? We’ll have to figure that out. In the mobile world, everyone has short attention spans, so games tend to be quick arcade-like games. You get in, you get out. You play then while you’re in line at the DMV, you play then in between your connections at the airport. I do believe the platform can support games that people want to play as they do with regular console games. The problem is, there’s not a lot of games that have deep story lines. Everyone is trying to make a quick buck, appeal to the casual gamer and move on to the next project. Well I’m not a casual gamer and I believe there are a ton of people out there like me who want a more involved game. Plus, with a low budget, we don’t necessarily need to make that quick buck.
Conclusion
So we’re going to build a post apocalyptic role playing game, with turn-based combat, in Corona SDK, for about $2,100.
Will we make the top 100 list? Probably not. Do I care? Not if it affects the fun of building a game and the enjoyment I’ll get when people play it. Luckily, I’m not a starving mobile developer and do quite well with my mobile development company here in Idaho.
In the next post, we’ll talk about brainstorming ideas and requirements and concepting the game to bring it out of the fog my brain and into something more tangible. You see the process, rationale, and decisions made to create the overview of the game as well as the scaling back and limitations we’ll place on the game to stay within budget and release the app in a reasonable timeframe. So let’s start building a game that we’ll enjoy building and see where we’ll end up.
Please leave FEEDBACK!
I’m doing this to help others, since others have helped me. Please leave comments below so I know how I best help tailor the series to your needs and interests. Even if it’s just to say hi, I’d love to hear from you.
Don’t forget to subscribe to the blog or like us on Facebook to follow along. I’m also on Twitter.
NetRef
BarNinja for iPhone
