Nerd Girls The Game
Lazy Foo' Productions (which in reality is just me) was contracted by Milk Mug Publishing to develop a game to promote their latest book. You can download it for free in the AppStore (Well at least you could before the company went belly up. The vast majority of game companies go out of business within the first 5 years).
While the game wasn't nearly as complex as some of the graphics or physics demos I've done in the past, but it was one hell of a lesson in project management. There is a difference between what it takes to get a Computer Science / Software Engineering degree and what it takes to put a piece of software into consumers' hands. I wrote an article to go along with the game for you beginning game programmers that are looking to put out a full game.
Ten Things About Game Development They Didn't Teach Me in School
In summer 2010, I got offered to make an iPhone App to promote a book geared for tween crowd. Considering how notoriously hard it is to get into the game industry, I jumped at the chance to have a published game on my resume. Best of all I was given near full control over the design and implementation of the game.Now, I haven't always been the best student but I have managed to turn things around to the point that I managed to get into the Tau Beta Pi honor society (which means I have to be in the top 5th of my class). I've taken courses in AI, graphics, and game development and I've always done well in them.
But there's school and then there's The Real World. What I'd like to share with all you budding code monkeys out there is some of the differences I found from my experience in getting an iOS game published.
10) The gap from almost finished to finished is a lot bigger than you think
If you haven't checked out the game, it's based on the classic style memory game where you flip over one card then have to flip the card that matches it. The twist is that in order to match the card they have to be directly above/below/left/right of each other. This meant you had to swipe around the cards facedown to get them next to each other. This added a bit of extra challenge in trying to keep track of where all the cards are as you're mixing them around.Now I managed to cook up a prototype in a few afternoons, which wasn't easy with finals breathing down my neck. Granted the game looked like this:
But all of the mechanics were there. Surely this just needed a few more days to polish the graphics.
In terms of hours, the game was only about 5-10% done at this point. While the game mechanics and fundamental architecture of the software were pretty much done, the texturing, animation, save system, achievements, audio, scoring system, web integration, and tons of other seemingly miniscule things were still sitting around waiting to be coded. Most of the projects you do in school are tech demos for the most part and a tech demo is not a complete product.
09) Just because it's simple doesn't mean it isn't time consuming
So at one point during development, I had an entire weekend scheduled of things I wanted to finish on the app and I was going to spend an hour or so coming up with a high score system. That ended up taking all day.See all high score system is taking various measurement of game play, assigning a value to each measurement, and adding them up at the end. However, first you got to decide what you're going to measure, calibrate the measurements so it doesn't produce obscene scores, make sure the scores save and replace lower scores when a new high score is achieved. Oh and you also have to test it all.
While the core mechanics didn't take more than a tenth of the total hours, do you know what did? Menus. Over 50% of the time spend on the application was spent on things you didn't even see while you were playing the actual game. Rolling GUIs isn't hard. I was doing that when I first started playing with graphics, but man does it take forever.
I've done far more complex things. This spring I was working on a physics engine which is several orders of magnitude more complex than this game. It's just that if you get enough short pieces put together, it becomes a long project.
08) It's the tiny things that'll trip you up
Think back to your early programming days when your code compiled but the damn thing just didn't work. You look over the source over and over and then you finally notice this:
if( var = THAT )
{
}
Small but irritating bugs do not go away when you start developing bigger projects. They actually pop more frequently in the form of API quirks that are causing your program to bug out over a single line of
code.So if you're one of the people that wants to go an RPG as your first project, remember how much of a pain it is to get those single line bugs in class. Multiply that pain by several dozen times and you're not even close to how annoying these types of bugs are in a full sized project.
07) There's a difference between knowing something and knowing something well
During the early phases of the project I was going to make a music player using OpenAL for the iOS. I've done something similar on windows and it wasn't that hard. All you have to do is read in some audio samples from the file, put them on the audio queue, play them, and when a sample finished playing you just grab more samples from the file.Sure enough, the iOS SDK had a decoder ready to go with all the functions I needed, but for some bizarre reason the music wouldn't loop. After running it through the debugger, it turned out after the music finished playing it would read in 0 samples even though I was explicitly telling it to read 44100 samples. Several recompiles and Google searches later, it turns out that the struct I was passing into the function that reads the sample also has a sample size variable. When the music is finished playing, it reads in zero samples and sending that same struct back in causes the function to read in 0 samples.
When going into a project, you may think "I know how to do this". Unless you've done it before, you only have an idea on how to do it. The difference between "I know this" and "I have an idea how to do this" can be a combination of several hours and several headaches.
06) Theory is not a substitute for experience
There's this notion that's infected computer science academia that really needs to rubbed out with some alcohol swabs. You take a data structures class in java and they have the audacity to spout "it's the same no matter what language you're doing it in". No. It. Bloody. Isn't.Remember, you're dealing with computers here. These are the same devices that will refuse to compile code over a typo. The most insignificant thing can stop a program from working, including quirks specific to the language or operating system your working on.
I've done GUI, graphics, multithreading, audio, C++, and game programming before this project and yes it was all conceptually similar to stuff I've done before using other tools. The thing is, a compiler doesn't accept theory to make programs, it accepts code and it will throw a fit over the most trivial mistake. This is why software engineers aren't afraid of the robot apocalypse. There's no reason to be scared of something that can be taken down with a misplaced semicolon.
Theory is important without a doubt but unlike a professor my goal isn't to teach theory (or earn tenure so I can half-ass my way to retirement). I have to get software out the door and the difference between a theoretical understanding and a practical one is many sleepless nights in front of a computer.
05) Making software takes more than the sum of its parts
Ok, so even if you know to do know how to graphics, audio, and GUI programming that doesn't necessarily mean you know how to put an application together. Not only do you have to make the parts, you have to put them together and make them play nicely. That is much easier said than done.You can design/implement/test part A and then you can design/implement/test part B and everything will seem perfect until you realize they need to be refactored to work together. You then come up with a hack to try to squish them together because you're short on time (and you will always be short on time), and then you have create another hack to make with something else, and then it just snowballs. With every person added to your development team is another chance for there to be a design conflict.
Design is one of the things that legitimately can't be taught to any meaningful degree in lecture. You develop a knack for design through experience, trial and error, and having to go through several plates of spaghetti code.
04) There's much more to game development than programming
If you haven't caught on by the design of the site, I'm about as artistic as an amoeba. So for the game I coded I had to come up with an art specification. I knew it's important to be specific because for every miscommunication is another time the artist literally has to go to the drawing board which means more money lost and the company will not like that. You can't just say "I need a button" because there will be a huge gap between what you're thinking at the artist thinks you're thinking.Another thing you have to remember is that when you're working for a game company, you're working for a game company. They're here to make money and you're going to have to deal with business people. One branch you'll have to deal with is marketing and the voodoo that they do. They get a bad rap which is understandable after fiascos like New Coke, but they also brought us Betty Crocker Cake Mix (stay with me here). In the 1950s, Betty Crocker Cake Mix was well reviewed but it was just sitting on the shelves. A marketing firm was hired to find out how to get the cake mix to move. What they found out is that housewives felt guilty about not putting effort into their meals. The marketing firm remedied this problem by instructing consumers to add an egg and the cake mix is still being sold today. You can only hope they can work that sort of magic on your game because there isn't much demand for a game developer who makes games that don't sell.
The point is you're going to have to deal with people in the game development industry who don't know what a for loop is. All these people speak different languages and it's important that you know how to speak their languages.
03) It's important to have dedicated testers
As the game was approaching completion, it needed its tires kicked in preparation for the AppStore approval process. Yes, everything you heard about game testing being mind numbingly tedious is true. Once you actually develop and publish a game you find out why.If you're a programmer and you're reading this, then you know how precise coding is. The most trivial thing could go haywire in the strangest of circumstances. Having a team of people to pick at every nook and cranny will save you hours of time you could have been spending programming.
As the programmer, you have an inherent bias to say "I'm done". By having a separate team dedicated to finding and documenting bugs, you start a competition between those trying to break the game and those fixing the game. The end result of this game will be a far more bug resistant application.
02) Deadlines are enemy number one
All these issues all seem like petty annoyances. On their own, they probably are. However, when putting together a full polished app, these problems add up and quick. Time is finite resource and knowing how to accurately gauge time is going to be very valuable.Learning to measure and estimate the amount of time it takes to get software finished is a skill that is not emphasized enough in software engineering curricula. I've seen fellow students start projects all the time and I've lost track of how many times project teams have thought that they could roll out a full RPG in a single summer.
There's a saying in business "That which gets measured, gets done". When working on projects keep track of how long it takes to get things done, even if it's only a simple spread sheet:
These will help you hone your ability to manage your most valuable resource: time.
01) School is the bare minimum
Yes, we've all heard the story of how Bill Gates was a drop out. What pretty much always gets left out of that story is that he was one of the few 13 year olds with access to a computer and that he was programming day and night since he was 13. The entire appeal of the Bill Gates never graduated story is that people like hearing about people becoming successful without having to work at anything.That sort of thinking isn't going to fly, even if you're that kid that never shows up to class and gets As on everything. The purpose of college (other than to drown you in debt) is to give you a foundation. Foundations are important but not enough. Not even close. Many of the skills that got me through publishing an app I learned through augmenting what I learned in class with independent study.
But you can't just study hard, you've got to study smart. Tech demos alone aren't going be enough. You want put out a polished piece of software that's 100% finished and is being used by real world users. It doesn't have to be big (it's probably better if it isn't), but it should be complete. Only then will you get the knowledge of the subtle nuances of real world software development. If all you're doing in your game development education is going to school, then you're depriving yourself knowledge you're going to need in the real world. With the game industry as competitive as it is, you're going to need every edge you can get.
