Game Development Community

dev|Pro Game Development Curriculum

GarageGames Game Development Handbook

by Eric Preisz · 08/21/2013 (11:09 am) · 28 comments





My first game development project had very little project management structure. As a result, we were late, over-budget, and below our quality target. This pattern is all to familiar to most game developers; if it has not happened to you, it does not mean you are good –it means you are inexperienced ;) I think people react those experiences in one of two ways: they become more reactive or they become more structured. I believe there are errors in both paths at the extremes. Like most things in life, looking forward and reacting to change should be balanced.

My reaction was to become more structured. I gathered estimates, refined methods, and aimed for more accuracy. I have outlined a lot of those methods in this article if you are interested.

Structure is great, but game development is not like building a spec home. With a spec home, builders follow a well-designed plan built by people who have experience builing many homes. The builder will often build the same exact home many times. The methods, techniques, and materials are well understood. Comparatively, there are a lot more variances and unknowns in game development –this is multiplied if you are doing something no one has ever done before.

Without the foreshadowing of the former paragraph regarding change, the methods we endorse may make you believe that we don’t believe in Agile methods -that’s not really the case. What I would say is that we tend to do more horizon planning than a lot of game developers. For me, the horizon plans defines what you think you will build and how you think you will build it; agile development is how you actually execute that plan.

Being a manger who needs to manage budget, hiring, and revenue has strengthened my desire to plan ahead; now that we are working for other companies, who may have never developed a game, we need to plan with people outside our company and experiences. If you have never made a game before, there’s a lot to experience. Our reaction was to build an orientation guide for new customers that walks them through the pre-production process we use. I thought that the same information might be useful for you and your colleagues, so we decided to write this blog and share the document with you.

There are two parts. The first part is the GG Orientation Handbook, which is designed like a car manual that walks you through our methods. The second part was inspired by a cognitive psychologist who we hired to consult us on an education project. He told us that testing someone forces them to recall information which helps to move memories from working memory to long term memory (RAM to mass storage???). The second part is a test we built on Smarterer.com.

I hope you get a chance to look at both. Feedback and comments are welcome.









About the author

Manager, Programmer, Author, Professor, Small Business Owner, and Marketer.

Page«First 1 2 Next»
#21
10/20/2013 (12:47 pm)
Okay, as a rookie, I am jumping broom and ordering up! Whew, both feet in and wide-eyed. :)
#22
10/21/2013 (3:43 am)
hi, looks very useful
There is mention in the book for database connections, as SQL or mySQL?
#23
10/21/2013 (7:22 am)
Dimitris,

The purpose of this document doesn't focus so much on implementation (how we get thing done)as it does the process for defining what you are going build. Until you define what you are going to build, you may not know if a database is even the correct tool to use.
#24
10/21/2013 (3:57 pm)
Think of it as a guide to drawing blueprints. If you start building a skyscraper without a blueprint you are inviting disaster. Learning how to correctly assess the needs of your software project also helps you to avoid disaster.
#25
10/21/2013 (9:15 pm)
Wow!!! Un excelente material!!!
#26
11/01/2013 (2:33 pm)
Seems eerily quiet here from the GG, guys. Hope its just everyone is busy.
#27
11/04/2013 (9:34 pm)
Eric ! Similar Handbook need for QA testers of T3D_MIT, with detail overview a procedures testing the new code.OR which information need for developer , and which not.(Or is it them for Dave Wyand?)
#28
11/05/2013 (8:30 am)
@Michael - Yes, busy is an understatement. Thanks for checking in.
Page«First 1 2 Next»