🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Planning your game
Author
Is it good to make a uge design document, and start making a uge game at startup? Teamwork will improve, and all is clear.
Or is it better to set a low standard at first and get quick results. If it works, you can always add new stuff.
It''s hard to set a low standard, because imagination sometimes runs wild.
If I look at myself in the past few years - The more I program, the more ideas I drop, just to get to the base of the program, only to get some (quick) result.
The idea of a good design document is to put it all on paper, and to take the "big approach" programming. Or not?
What''s your opinion on this?
What do you think is the best way to plan your game?
Did the way you plan programming change the past few years?
Is it smart to plan multiple "stages" of your game?
I think the whole flurry of "Game Design Documents" recently is a little misguided. In software engineering, there are a whole bunch of different documents that make up the "design".
Some of these, related to just the design:
I personally believe that the third is very important to get right. This specification doesn''t have to be detailed, but it has to be VERY robust and VERY accurate, because if it isn''t, you will run into problems implementing your ideas. If you do this part right, the implementation can start with something small ( that still uses that system architecture ), and build on it from there, with the architecture supporting you all the way.
Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.
Some of these, related to just the design:
- User Profile
- Software Requirements
- System Architecture
I personally believe that the third is very important to get right. This specification doesn''t have to be detailed, but it has to be VERY robust and VERY accurate, because if it isn''t, you will run into problems implementing your ideas. If you do this part right, the implementation can start with something small ( that still uses that system architecture ), and build on it from there, with the architecture supporting you all the way.
Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.
I think the most important thing when it comes to designing a game is to know what your team is capable of doing. Then secondly, know what they could learn and pickup within the time span of the game being made. The reasons for this a rather obvious so i wont go into in any more detail.
But when it come to design documents this is how i go about it.
Presuming you know what type of game your making aready. I like to work on the hardest bits first like game logic so i can create a bone structure for my game. Once i'm happy with this (which takes a long time btw) i then work out what i mentioned above (team) and use this as a foundation for:
1. setting up and laying out my ideas and
2. using this as a way of keeping other people who are helping out "On Track".
I do sincerly hope this helps
but if your a little confused about what i said please ask.
I love Game Design and it loves me back.
Our Goal is "Fun"!
Edited by - Paul Cunningham on July 27, 2000 7:44:24 AM
But when it come to design documents this is how i go about it.
Presuming you know what type of game your making aready. I like to work on the hardest bits first like game logic so i can create a bone structure for my game. Once i'm happy with this (which takes a long time btw) i then work out what i mentioned above (team) and use this as a foundation for:
1. setting up and laying out my ideas and
2. using this as a way of keeping other people who are helping out "On Track".
I do sincerly hope this helps
but if your a little confused about what i said please ask. I love Game Design and it loves me back.
Our Goal is "Fun"!
Edited by - Paul Cunningham on July 27, 2000 7:44:24 AM
design documents tend to be more usefull with a team of programmers to keep everybody working on the same thing. with independant game develpoers, I don''t see it as being that inportant.
JoeMont001@aol.com
www.polarisoft.n3.net
JoeMont001@aol.com
www.polarisoft.n3.net
I also use a design document just to keep a record of a game that i''ve come up with. Which usually just gets filed away 
I love Game Design and it loves me back.
Our Goal is "Fun"!
I love Game Design and it loves me back.
Our Goal is "Fun"!
quote: Original post by baskuenen
Is it good to make a uge design document, and start making a uge game at startup? Teamwork will improve, and all is clear.
Or is it better to set a low standard at first and get quick results. If it works, you can always add new stuff.
It''s hard to set a low standard, because imagination sometimes runs wild.
If I look at myself in the past few years - The more I program, the more ideas I drop, just to get to the base of the program, only to get some (quick) result.
The idea of a good design document is to put it all on paper, and to take the "big approach" programming. Or not?
What''s your opinion on this?
What do you think is the best way to plan your game?
Did the way you plan programming change the past few years?
Is it smart to plan multiple "stages" of your game?
quote: Original post by MadKeithV
I think the whole flurry of "Game Design Documents" recently is a little misguided. In software engineering, there are a whole bunch of different documents that make up the "design".
I agree with MadKeithV on this. The design document is one doc out of a larger set of docs. The design doc is used by the programming team and for that reason, I suspect that it has gained fame and notoriety among developers and designers alike.
As to your initial question:
Is it good to make a huge design document...
Yes, and no. You have to go about it in the right way. With the requirements and system architecture defined (possibly a business plan and cost benefit analysis), the designer can construct a design document (DD).
The way we are approaching this feat, I will describe.
While we are seeking funding for our game, we have met weekly to discuss all aspects of the game. Minutes are written and sent to all attendees. We are about a month away from wrapping up our design meetings, at which time were going to meet to start the design document. There are three of us that will be involved in writing this document, we are going to take our meeting minutes and split all of our minutes up… go out write our sections of the DD and come back when finished and read each others sections. After some maintenance to the document (and funding becoming available) we’re all set to code.
This approach may not work for everyone and your mileage may vary but this is a system that I feel works best when more than one person is involved with the design of a game. Especially for a MMORPG
Dave "Dak Lozar" Loeser
I think some type of documentation is ideal for every project. I''m not saying that everyone should (or can) layout every single aspect of a game on paper first. But you should have a document stating what your goals are for the game. If not, you could find yourself coding yourself into a big black hole. Even if you get the game done, it may not flow quite right (because of concept changes mid-stream) and the game won''t be any fun to play.
I also like to write down all new ideas as I have them. Once in a while, I go back to my idea list and see which ideas still "fit" into my game concept. After all, you may come up with a new idea that totally trashes some old ideas you had (and may want to keep in your game).
Also, I find that I have a new game idea at least once a week. While I am planning a specific game, it is still great to jot down notes about these new concepts, so that when I am ready to work on my next project, I won''t be saying to myself..."Now what was that cool idea I had 6 months ago?".
I hope this helps someone out there.
borngamer
Man was born to game, we only work to pay for our toys!
I also like to write down all new ideas as I have them. Once in a while, I go back to my idea list and see which ideas still "fit" into my game concept. After all, you may come up with a new idea that totally trashes some old ideas you had (and may want to keep in your game).
Also, I find that I have a new game idea at least once a week. While I am planning a specific game, it is still great to jot down notes about these new concepts, so that when I am ready to work on my next project, I won''t be saying to myself..."Now what was that cool idea I had 6 months ago?".
I hope this helps someone out there.
borngamer
Man was born to game, we only work to pay for our toys!
Apart from just design documents and more concerning the topic of this forum "planning a game.." I''d like to add a few things.
Prepare to keep many documents. The design doc is a backbone, and hopefully a thourough description of your game. But your time in MS Word isn''t over yet. You''re going to need a couple logs, one more like a journal "I did this today.." and one more like a technical manual "I used a linked-list here...". And if you''ve desinged a really strong OO skeleton, you''ll probably have ideas come up during development, sparked by your program architecture, that''ll make you say "Hey, this would fit right in here with no sinigicant code changes and would be really cool.."
So I''ve always got several docs floating around that accompany the design doc and help organize the game development. Recording your work one day, is a wonderful way to plan what needs to be done the next.
ape
Prepare to keep many documents. The design doc is a backbone, and hopefully a thourough description of your game. But your time in MS Word isn''t over yet. You''re going to need a couple logs, one more like a journal "I did this today.." and one more like a technical manual "I used a linked-list here...". And if you''ve desinged a really strong OO skeleton, you''ll probably have ideas come up during development, sparked by your program architecture, that''ll make you say "Hey, this would fit right in here with no sinigicant code changes and would be really cool.."
So I''ve always got several docs floating around that accompany the design doc and help organize the game development. Recording your work one day, is a wonderful way to plan what needs to be done the next.
ape
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
