Tuesday, December 27, 2011

Journey into Technical Game Requirements

Hello again fellow game enthusiasts!

So, over a nice glass of holiday eggnog, I've been thinking about my previous post and a comment that was made on that post. Basically that "a plan" is one thing, but how to go about executing the plan is another. I've decided to take this post from the perspective of aiding a person who does not have a great deal (or any) technical planning experience. In other words, how do you take your epic game idea from your head and translate it into it's digital form. Let's journey into technical game requirements.

From an IT industry standpoint, a technical requirements document is a big detailed document that can be handed to a programmer and then they can...well...program the system. It lists the recommended tools for programming the project, how the project's technical architecture will be laid out, the problems the system will solve by being built....all that good stuff. If you have no clue where to start programming, a technical requirements document is the place to start.

That being said, I know phrases like "technical architecture" can be pretty scary to a non-techie (or to a techie depending on who's writing the document...*ba-dum, tish!*). You don't need a huge fancy document with a cover page on your TPS report. Basically your document should answer the following questions:

What platform are you designing for? (iPhone, Android, PC. XBLA, PSN, all of the above?)

What tools will you use?

What programming language will you use?

How is your game laid out? (a.k.a. what are all of it's pieces)

Let's do a quick example. Let's say you played every Final Fantasy six times and you think the iPhone app store deserves an awesome JRPG-inspired game. And you have just the game for the job! If that's what you want to create then what would your technical requirements document look like? It would look a little like this:

If you know how to create and read Unified Modeling Language or UML document, that would be even better still for mapping out the relationship between all the parts of your game. While there are admittedly some pretty glaring gaps in the "game module" section, that's really all you need as a starting point. If there is any bit of advice I've heard from the local game dev community repeated over and over it's to not get caught up in planning forever. A plan is very, VERY important. However, when you have a good, solid idea of what you want to do, then just start!

For instance, in the above sample document, a great place to start would be to program the battle system. If you're doing traditional box battle style, it will have independent mechanics from all the other components. Start with simple text menus and basic geometric shapes to start. Then work your way up!

There was a lot I was going to say about learning how to program if you don't know how, but I decided to scrap it all and say one simple thing: just get started. The internet is flooded with great tutorials on programming in whatever language you want to.

I hope that was useful! Now if you'll excuse me, I need to refill my cup of eggnog. Have a game filled holiday!