Requirements and Project Scope of a Torque Game

#1 Eric,

For starters, planning a game in Torque is, or at least should be no different than planning any game for any engine, on any platform, at a basic level anyway.

Now, obviously, the more intimately familiar one is with a given engine and the technologies and capabilities it possesses, the more specific one can be during the design and planning phases with regards to features and game-play issues.

The fact is though, even if you knew Torque intimately, you are going to wind up changing your design as you move forward. Some features you planned aren't going to pan out the way you originally envisioned they would - when that happens, you cut your losses or experiment with alternatives until you arrive at something that "works", or drop the feature alltogether if it proves unecessary.

Other times, you're going to find that your game needs a feature you'd not previously thought of. When this happens, you take a quick sidestep and prototype said feature quickly to make sure it is indeed what the game seems to be lacking.

The key word here is Prototype.

Game design docs should NOT be "set in stone" IMO. Ever.

The fact is that you don't know what is going to work, or what will add or detract from your game until you actually start building it and implementing those features.

Because of this, you should always consider your design doc to be a "living" document. If you allow your design to be flexible in order to accomodate the needs of the game, rather than forcing the game to fullfill the requirements of the document, you're going to end up with a much better product in the end.

The key here, and you're going to run into statements like this all over this site, is: Prototype rapidly, prototype often, and prototype everything.

When you prototype, you just quickly "rough out" the feature in question. You disregard specific points of polish for the sake of quickly being able to see the effects of the feature on the game. If it works, start polishing it up. If not, cut it and move on.

If you're just beginning, the best thing you can do (in my opinion) is lay down a general idea of what your game is supposed to be. Don't concern yourself with the specifics of what GUI elements must be present, how they'll operate, etc. That stuff will make itself apparent as you move forward anyway - for now, just focus on the what the game is actually supposed to be.

What is the point of the game? What activities will the player be required to engage in? Is there a story? what actors will you need? Keep it high level so you don't document yourself into a corner.

Once you have your idea roughed out, you can then start looking at how best to attack the issue. My personal preference in this regard is outlining. I sit down and think through a logical progression of how to get from point 'A' to point 'B'.

As an example, my project is vehicular combat. To that end, my "design" started like so:

Quote:
1) Get a working player vehicle
2) Mount weapons to vehicle
3) Get a working vehicle bot

Once I have what I consider to be a reasonable progression, I look at the first task and start getting more specific:

Quote:
1) Get a working player vehicle
a) Create vehicle mesh & skin
b) Create vehicle Datablock
c) etc...

2) Mount weapons to vehicle
3) Get a working vehicle bot

Notice that at the point I've got a working vehicle, I haven't begun to even worry about weapons or bos yet. One step at a time. I know I'll need weapons mounted to the vehicle, and that's enough for the doc for now. It doesn't have to be concerned with the how, just the why.

Now, this is only what I find works for me. You should document in whatever way works for you, just remember to leave room for flexibility in your design.

~ Hope that helps

#2 Just one (personal) one addition.

You said "The key word here is Prototype."

To me it should be "The key word is GAMEPLAY prototype".

You can't make an unfun game fun, no matter how good the graphics or sound or storyline or engine. Besides, you can always buy those afterwards, gameplay you gotta make yourself. I've seen people working and working to improve an engine in hopes that the crappy game suddenly became awesome....but it pretty much became an awesome screensaver at best.

A fun game pretty much stays fun even if it's less technically advanced or graphically lush.
So make sure your core gameplay is fun.

#3 Prototyping is definitely key. Not only because it will help you determine if your game will be fun but whether or not you will find it entertaining enough to continue developing. An example from my own experience. I love top-down shooters/beat 'em ups like Enclave, Hunter, Smash-TV, etc. So I thought "I would like to make one". Well, the concept was pretty typical (demons taking over the earth), the concept designs interesting (as most demonic things are), but when it came to prototyping it, I learned that I love playing such shooters, but I was really hating developing such a game.

So I killed it, horribly, more than a year ago and have been playing around with a number of ideas old and new to see the direction I want to move. I've found that direction in a T2D game that combines the polarity of Ikaruga/Silhouette Mirage and the platformer-puzzle elements of Mario vs. Donkey Kong. But it is one that I've been enjoying working on, even in the base concept stages.

If I hadn't prototyped, I would have cornered myself into a gametype that I did not enjoy creating, and you can bet it would have trickled down.

#4

Quote:
To me it should be "The key word is GAMEPLAY prototype".

Point taken, although in my personal view, this is implicit. Basiclly, if something doesn't affect the gameplay, it isn't a "feature" really. If it isn't fun, I'm through with it alltogether. (C;

Same idea, I just wasn't as explicit in my delivery. =)

~Cheers

#5 Thank you all for your comments.

I'm well aware of everyone's stance about prototyping and I believe it is a great method of development a lot of games. However there are still a few problems with prototyping including some design issues stated in my original post.

Quote:If you don't really plan how your game will turn out, how do you know when to stop? How will you know whether you can reasonably manage to get a game out in 6 months, or 2 years?

The other difficulty about prototyping is it's ad hoc nature. The development of a single system without taking into account the dependencies or requirements from or for other systems doesn't seem like a great idea. And then there's the cleanup/refactoring afterwards.

I don't know really. It almost seems like prototyping seems to almost completely throw out any planning in terms of design and project scope right out of the window.

Has anyone taken a different approach?

#6 Eric, I'm going to relate to you the story of my first experience with Torque as I think it applies here.

I first worked with Torque for my Associate's Final Project at Full Sail in 2004. We had a team of five guys whose strengths all lay within gameplay logic and not so much tech, which is why we chose Torque. We had 3 months to make a game, 1 month pre-pro, 2 months production, and we made a Mario Party-esque party game complete with 8 mini-games (2 more than our proposed 6).

Planning, researching, prototyping, and researching were all the main factors that helped pull it off. I know I said researching twice because its that important. Researching is the key to knowing this engine. In most cases something you want to do has already been done and the answer is out there. You can become frighteningly proficient with search engines after working heavily with Torque. All three, or four, of these things are at all equally important and at the same time more important than one or the other.

Let me give you an example of the way tasks were broken down for us.

When we scheduled our tasks we would break them down into research, design, and implementation of pieces that were needed for it to be complete. One of my tasks was the AI, we wanted to use the same instance of the avatars on the Main Game Board as we did in the mini-games. So when the avatars were on the MGB they had to be controlled by the AI and follow a path unlike in the mini-games they were controlled by the players.

So I started by researching AI and paths, which then lead into playing with path tutorials, which lead to some more research and coming with a more detailed plan for the system, then a prototype, then some more research and experimentation, next came the eureka moment, a couple more prototypes and experiments and the system was complete. Yes I know, I think I did just write the world's longest sentence. Anyway, the point is through the use of planning, researching and prototyping the work was finished in about a week, as opposed to the inflated 2-3 weeks I gave it on the schedule.

If I hadn't done those prototypes I could very well have been heading in the wrong direction for far too long. I've taken the same approach in my non-Torque games as well. Early prototypes of a system will either prove that it works, or tell you to go back to the drawing board.

During the project we actually always referred to our game as an evloving prototype. We had enough art assets with the stock engine to build a prototype of the game, this way we always knew if the game was any fun.

Now, as far as coming up with a time frame. What you should do is come up a complete list of what the game needs. Plan out what the interactions of the differenct systems are, then figure out how many hours a day you have to spend on your project. Once you've done that you can break up your tasks give them all an amount of time that you think it will take you. Some things don't have to be prototyped as much other things do. The more complicated a task the more you'll want to test it.

Anyway, I hope that helps some.

#7 @Scott: Thanks for your story

I think I have a much better idea on how to go about planning, developing, and prototyping. It seems it's probably best to have a good idea (written or in your head) about what exactly you need in order to make the game.
I think I'll personally try to generate requirements for the specific little systems I know I need to code, but not taking into any game design decisions into account right away. Research, design, code, prototype/test... etc.

Thanks all for your input.

Anyone else who would care to share their development methodologies I'd be more than happy to hear ;).

- Eric