Laying the Foundation For a New Game Project
<>I'm starting dev on a new side-scroller but need help in getting organized. This will be my first game. I and another person will be producing it.
-How does one go about determining if whether or not it's truly feasible?
-Surely there's a sequence of steps the big companies follow when starting a new game. I've heard 'Design Documents' referred to here as something you should compose before going very far, a 'game plan' of sorts.
What exactly is a design document, and how is it laid out??
Could I just suggest maybe you try a smaller game such as Tennis / Pacman or space invaders first?
Creating any game always has more complications than you can anticipate, and a side scroller has many hidden complications you will be unaware of if you have never created a game.
It may sound boring, but beleive me any of the three above games will be more than challenging enough for a first game
James
Creating any game always has more complications than you can anticipate, and a side scroller has many hidden complications you will be unaware of if you have never created a game.
It may sound boring, but beleive me any of the three above games will be more than challenging enough for a first game
James
Quote:-How does one go about determining if whether or not it's truly feasible?
By prototyping.
Quote:What exactly is a design document, and how is it laid out??
A design document is the output of one or more of your company/team's initial procedures when starting a project. Generally, a design document comes somewhere after you have the initial idea and before you begin constructing the various parts of the product. Think of it as a prototype on paper. The exact layout depends on the project. Ideally, it would be laid out in a way that allows yourself and anybody reading it to quickly locate whatever section they are interested in. I'm sure you can search around and find some good examples.
If you want to know more about Design documents i suggets you should
read "Swords & Circuitry: A designers guide to computer role - playing games"
It has a chapter around 50 pages about Design Decuments
read "Swords & Circuitry: A designers guide to computer role - playing games"
It has a chapter around 50 pages about Design Decuments
Quote:
Could I just suggest maybe you try a smaller game such as Tennis / Pacman or space invaders first?
I second the motion for an easier game. Its always better to finish an easier game than to start a harder one and never finish. If you think it will be too easy, then humor us anyway and finish it off in a few hours. You will be much better prepared for your sidescroller.
<>Well thanks for the feedback guys. I found the EmberScribe ( http://www.okita.com/ES/EmberScribe_CompleteDesign_2005-06-03-1955.pdf ) design document by digging around on indiegamer.com as suggested to me by someone here.
-Talked to my coder today about starting out with a small game, with a basic gameplay concept like Tetris or Pacman, or the like. We both see the logic of making a small game first, but we've decided to go against the grain and start by beginning our efforts with making multiple 'mini-prototypes' that'll move us closer to completing the game, rather than writing code and creating graphics we'll just toss aside once done. Each 'mini-prototype' will allow us to master certain aspects of the game, which we have no experience with, yet.
For instance, user keyboard controls and collision detection, here is a small image of the *.PDF I'll be sending my coder, detailing how to lay out this particular 'mini-prototype' : http://www.sharpshade.com/lettuce/omega1/OMEGA1_prototype2.gif General physics like gravity and momentum, and maybe even particle generating may be the next 'mini-prototype'.
-What's the general concensus on that? It's not following your guys' advice exactly, but it still is in a way. I'm much more 'don't bite off more than you chew' conscious now, after this thread, and others that I've read now.
-Talked to my coder today about starting out with a small game, with a basic gameplay concept like Tetris or Pacman, or the like. We both see the logic of making a small game first, but we've decided to go against the grain and start by beginning our efforts with making multiple 'mini-prototypes' that'll move us closer to completing the game, rather than writing code and creating graphics we'll just toss aside once done. Each 'mini-prototype' will allow us to master certain aspects of the game, which we have no experience with, yet.
For instance, user keyboard controls and collision detection, here is a small image of the *.PDF I'll be sending my coder, detailing how to lay out this particular 'mini-prototype' : http://www.sharpshade.com/lettuce/omega1/OMEGA1_prototype2.gif General physics like gravity and momentum, and maybe even particle generating may be the next 'mini-prototype'.
-What's the general concensus on that? It's not following your guys' advice exactly, but it still is in a way. I'm much more 'don't bite off more than you chew' conscious now, after this thread, and others that I've read now.
Seems pretty solid to me, the idea is very simple and should ease you in nicely. There is a minor movement bug on the play but it is irrelevent at this point.
GDNet's Design category in the Reference section has some things that may help you, including a sample design doc for a commercial game (Monolith Software's Claw) and an example doc template.
As for your approach of prototyping individual systems before trying to bring them all together, that's a very good idea and as such quite a common approach. Good job for figuring it out yourself [smile]
As for your approach of prototyping individual systems before trying to bring them all together, that's a very good idea and as such quite a common approach. Good job for figuring it out yourself [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement