Sign in to follow this  

Game planning/design document/checklist?

This topic is 3937 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I've decided to make my first 3d game. And I'm doing it all myself. I'm wondering if anybody could either direct me to or give suggestions for a plan so that I don't miss anything in the whole process. Something like a generic checklist to make sure everything is done right the first time around. I'm using Blender to draw my graphics. I'm a noob with it, but learning fairly quickly (practice makes perfect). When the latest Blender quirk makes me want to pull my hair out, I take a break from it and work on game music and sfx. I'm also currently trying to determine what I want to use to write my game with. A long time ago, I programmed BASIC on a C64 and a TRS-80 COCO. My most recent programming is scripting modules for Neverwinter Nights (no, I don't use the scripting wizard). I checked out a few engines and languages and at this stage I think I'm better off going with a rapid application development tool. Right now I'm really leaning towards the A6 engine ( http://www.3dgamestudio.com ). The scripting I did in the demo was fairly simple and I should be able to pick it up quickly enough to write a game or two with it. If I choose to continue writing games, I'll probably learn an actual language. But back to the issue at hand, when working alone instead of with a team, is there a resource that I could be using to best utilize my time/energy to reach my goals. Right now I feel like I'm just drifting from one aspect of game creation to another.

Share this post


Link to post
Share on other sites
How many project have you finished before? A 3d game is a massive undertaking from scratch. You have some programming under your belt so that helps tremendously. How original will your game really be? Do you want top-notch state-of-the-art graphics? Is the game content heavy or is it mostly about gameplay?

Seeing as you have some experience I'll come right out and suggest learning C# and then move onto graphics with XNA. Just, make a 3d game a long-term goal and have smaller projects as goals along the way. Like a text-based tic-tac-toe game first :) Get some other small text projects done. Then your first graphical game should probably be pong, then Tetris. Then you'll probably be able to tackle a 3d game.

Hope this is what you're looking for.

Share this post


Link to post
Share on other sites
I'm also curious if there are any templates for writing design documents for a videogame.

Good luck with 3d game studio. It looks pretty cool for making videogames.

Share this post


Link to post
Share on other sites
Well, different methods work for each person and project, so there really isn't a straight-forward A,B,C checklist that will lead you from having your hands empty to having a nice, polished, finished project resting in your palms.

The general path that I take, though, is roughly this :

A: Think about what game you want to make, get the over-view of the mechanics out of your brain and in to some sort of recorded form. Write down ideas, draw stuff out on paper, lay out the high-level description of what you are wanting your end product to look like.

B: Break it down into large chunks, such as 'sound' and 'user interface', write out what you want each part to consist of. Do you want your sounds to be of lower volume if heard from a distance? Then you'll need a position associated with your sounds. Do you want 3d graphics, 2d, skeletal animation or vertex blended animation. These are a bunch of high-level tech requirements. List attributes and abilities you want each of these large sub systems to have [do you want a console? Do you want your user interface to be windows-like? do you want your game to run in a window, etc.]

C: Break it down into actual individual sub systems, individual tasks, and be thorough. If you want animation in 3d, then you'll need some way to store the meshes, some way to store textures, and some way to load them. You'll also need something to keep track of everything. You don't need EVERY detail nailed down, but you want much of the tech-stuff out on paper at this stage. Draw out a mock game-loop, include things like 'check for collision' [and be sure that you've included what kind of collision detection you intend to use in each case], and 'render', 'check for incoming network packets'. For network transmission, include the order that you expect to transmit your data for logging in and requesting resources, or anything more complicated than the simplest packets.

Consider how you intend to approach each of these sections, even if it's not crystal clear at the time. Make sure you have a plan of attack layed out. If things start getting out of hand, and things start spiralling out of control, it means you bit off more than you can chew. In that case, go back to step A and revise your initial plan until you have an idea of how you're going to be approaching everything.

D: You've got your plan ready, you know what you want to do, and you know how to attack your problems [or at the very least, enough about the problems to learn how to attack them as you go. You won't know everything when you start, likely, but you'll at least know enough to be able to find your way through things]. Look over your design, and mark chunks of it you don't intend to code yourself [for example, you don't need to code animation systems in great detail, or mesh file format support, if you're using a graphics engine that does it all for you.] Reduce your plan down to what you need to actually do.

E: Break up your project, and follow your plans closely. Work on your game. Shoot for getting a really basic version of your game up and running as quickly as possible. If you're trying to make an FPS, get a person in a square room with a pistol, able to walk around, before you worry about all the effort that goes into expanding your character's arsenal or giving your character super pretty armor and fancy explosions. If you're making an RPG, get a character running around in an empty field first, then go for all the neat things your character can do later. Shoot for basics first. It's easier to stay motivated if you have a means of actually experiencing the changes you're making, instead of just knowing that the huge pile of code you just wrote will some day make things pretty neat. It doesn't have to be pretty, it just has to be something you can see and get immediate feedback from.

F: Expand from there. Stick to your plans. Expand, expand, expand, until you reach your goal.

Share this post


Link to post
Share on other sites
Quote:
Original post by nobodynews
1. How many project have you finished before? A 3d game is a massive undertaking from scratch. You have some programming under your belt so that helps tremendously. 2. How original will your game really be? 3. Do you want top-notch state-of-the-art graphics? 4. Is the game content heavy or is it mostly about gameplay?

5. Seeing as you have some experience I'll come right out and suggest learning C# and then move onto graphics with XNA. Just, make a 3d game a long-term goal and have smaller projects as goals along the way. Like a text-based tic-tac-toe game first :) Get some other small text projects done. Then your first graphical game should probably be pong, then Tetris. Then you'll probably be able to tackle a 3d game.

Hope this is what you're looking for.

1. This one is hard to answer. I made a lot of text adventures and a few seizure inducing, screen flashing games in my youth. More recently I've completed three decent sized modules for Neverwinter (two to four hours of game play each).

2. The first project is a very simple one. I'm not going to spill the beans yet on subject matter, but the game logic is understandable by five year olds everywhere. Tt is not "The Game" that I want to write. Mainly just a learning tool, I suppose.

3. I'm doing the bulk of my graphics in Blender. Subsurf & Smooth will suffice for how good they need to look.

4. There's not a lot of graphics in it. At least nothing that won't be re-used several times over. I guess that leaves gameplay, which is what it's all about. That thought in mind, the gameplay itself is very simple.

5. Right now I'm spending my "learning brain power" on Blender. That's why I'm considering a RAD tool like A6. After I get the modeling side down, I'll probably want to start writing my own engine/tweaking theirs. Until then, it will just be too much to learn and I'll hate ever wanting to write a game.

I haven't purchased A6 yet though. So I'm still open to suggestions at the moment. So far it's at the top of my list.

Quote:
Original post by Drigovas
.
.
.
Thanks for the advice. My next question (which I'm asking myself just as much as anybody else reading this) is "How do I know if I am forgetting to plan something?"

Your post brought up several things that I didn't think of. All of them because of the simple reason that I didn't know I needed to think about them.

Share this post


Link to post
Share on other sites
Well of course something is going to slip your mind. Nobody ever considers everything everything everything right from the get-go. But with experience, you learn what to consider, and what is out there to trip you up. Personally I go from the top down. Consider something like, for example, tetris [a decent example because everyone has played it, and knows what it looks like.]

So you decide you want to make tetris, that means you need a few things. Tetris has blocks, and these blocks fall.. in real time. Right there we have a few things.

The blocks are going to have to be graphical, so you'll need a means of loading your graphics. Do you need flexability with regard to your graphics? do you need to be able to load different kinds of blocks in real time?.... not likely. Tetris relies on a couple block colors that make up the block shapes, and all the block shapes are known, so you can rest assured that you'll be able to know every bit of block-related graphics you'll need for a given level up-front [not the case in some games, such as an RGP with a billion jillion little kinds of items, that you need to be able to load and unload of on-the-fly].

The blocks fall, so they need collision checks against other blocks. The collisions aren't that tough to deal with. They also fall along a grid, so you don't need to worry about collision tests between meshes, just collision on a grid [WAY easier]. They also only fall one at a time, so you only need to consider a 1 block to 1 static grid collision test per-movement. They also don't move any more once they hit the object [once they land], so you need to be able to edit the static grid against which the blocks are checked. Side-to-side collisions are handled differently than downward collisions, and a block cannot move up, so you don't need to consider that direction of movement.

The blocks move in real time, so you'll need a timer of some sort too. They don't move every frame either, so if you want your game to run on a fixed frame rate, you need to run a game-state timer seperately [one timer to run the rendering, one to tell when the block should be forced to drop down a peg]. The game-state timer also shouldn't run at a hard-coded interval, since the speed the blocks drop is dependant on the difficulty.

You also intend to have the player control these blocks. Do you want to use the keyboard? If so, you have to consider that too. Want two players to use a single keyboard for 2 player mode? You need to consider what keys you want to do what. Want two players to compete over a network? Thats a whole additional problem.

Want to display a score board? That means you're going to need a method to output text, load fonts, keep track of a score [perhaps two scores, for 2 players, if you want two players], and save the scores if you want a high score board. LOTS is involved in fonts if you write your own, everything from writing a font loader, font managers, how you intend to store fonts, ect. If you decide you want to use GDI for fonts, or a preexisting font-library, this part of your project is covered easy as pie.

How do you intend to load the block shapes? hard coded or file loaded? [not many block types, unless you want custom ones. Hardcoding should be considered]
How do you intend to set difficulty? load timer intervales from a file? hard code that? [not that many difficulty levels in tetris in most cases, so hard coding is a good choice]

If you load these things from files, you need to know what sort of information your files need to hold.

How do you want the game to start and stop, do you want a splash screen that says 'tetris', do you want a credits screen? How do you intend to deal with game state transitions [such as from splash to the actual game].

And what about block generation. Do you want them to be random, or somehow predefined. Do you want an AI to generate the blocks to try to give the player something they can actually use, or attempt to starve them?

How about a backgroud while your playing. And where do you want everything to be displayed on your screen.

Even something simple like tetris can look complicated if you consdider everything. But once you have this degree of planning done, the actual coding part becomes managable, and you reduce the chances of coding yourself into a corner, or writing code one day that blocks off features you'd like to have the next day. You re-write less, and your productivity goes up.

Just make sure you stick to the plan. If you decided that you want blocks randomly generated, then you can safely write a bit of code that makes it impossible to generate the blocks with an AI. If you're not sure how you want the blocks to be generated, then make sure you write code that can be used with any of the methods you consider at the time of your planning.

Share this post


Link to post
Share on other sites
@Drigovas:

After reading the above, it makes more sense (for me at least) to go with a RAD tool. My current place on the learning curve is in the graphic creation area. Using somebody else's engine will take care of a decent amount mentioned above. However, that also limits me to what I can do. I can only do what their engine will allow me to do. I think I can live with that for the time being. Get my graphics down, and go from there.

I'm not going to say that my questions have been 100% answered, because I would still like to hear how others organize things. But you have given me a new perspective of how to look at this puzzle though. At this point, I think I'm going to envision each screen/area of game play (start game screen/game play/options/etc) and determine what elements exist within each and what I ned to do to create those elements. If there's anything else you can think of, I'm all ears (or eyes as the case may be). Thanks.

Share this post


Link to post
Share on other sites

This topic is 3937 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this