Usally I plan for my next project while I''m writing the current one. I don''t write no Design Documentations or stuff like that - I just draw lots of pretty pictures.
~ There''s no substitute for failure ~
How long to you spend planning?
Here''s my way to go about it. First, get come paper and pencil. At the top I write the name of the program. Right after that, I describe in a one line sentence what the goal is and main point. Then some simple graphic scenes after that so I don''t forget my graphical ideas. Then after that is controls and menus. Then the gameplay and strategy. Then the levels.
After writing that out, usually about a page double sided, I type it up and make some graphics in a 3d modeler or 2d modeler so I can get a feel of the graphics. Then I just type it up and orgranize it. After that, print it out and you have a good design. It usually takes about an hour or two and then you have the basics. Everytime you need to implement something not in your design, add it to your typed design. At the end, mine are usually about 5-10 pages.
If you are in school, thats great because in those boring history lessons, write out your design while pretending to take notes. It makes the teacher think your paying attention. :-)
After writing that out, usually about a page double sided, I type it up and make some graphics in a 3d modeler or 2d modeler so I can get a feel of the graphics. Then I just type it up and orgranize it. After that, print it out and you have a good design. It usually takes about an hour or two and then you have the basics. Everytime you need to implement something not in your design, add it to your typed design. At the end, mine are usually about 5-10 pages.
If you are in school, thats great because in those boring history lessons, write out your design while pretending to take notes. It makes the teacher think your paying attention. :-)
Well, it really does depend on the project but i normally spend about 1 or 2 hours designing the acctual structure. Then i''ll write some main code on a section (graphics, main body, class, ect) then i''ll go and write some more design about the specific thing i''m working on now that i have a better idea how things are working. I''ve tried doing an entire project at once but have failed so far.
I began programming before I knew exactly what the words "design document" meant- I was 8 in the early 80''s, using a Commodore 64. Unfortunately, bad habits die hard and I still program like an 8-year-old. Since It''s always been for fun, I stuck to the two factors of programming I enjoyed the most: brainstorming and logic. I began with pencil and paper, laying out what kind of game I would like to make. No real "design document" structure there- just getting rough ideas out onto paper, and after a few pads worth I had a good "feel" for what I wanted to make. After defining the basic gameplay (knowing how I wanted it to turn out), I boiled it down to component parts: gamestates, data structures, control, graphics, sound. Then the programming, where I take the game step-by-step from the ground up, and work out the logic on how to implement all of the above. Usually along the way, I come up with "hey, this''ll be cool"... TONS of feature creep. Not really a bad thing, when all the fun to be had is in the creation.
-Tok.
~Feature Creep of the Family~
-Tok.
~Feature Creep of the Family~
A lot of good ideas on this post...
Personally I like to write up a design document first. It''s all about abstraction, start with the basics then dive into the details a layer at a time. Start with the GDD, then work out the Technical Design Doc. From those you have a clean plate for planning your classes, once that''s done, work on the code for those classes. Then get into the nitty gritty with the actual game code using those classes. The beautiful thing about this method is that it saves so much time and keeps that feature creep out. You will know from the start what is possible and what isn''t and you''ll have much more time to figure out how everything will work together.
And Capt. Jester has it right on the money... Make it work, then make it right (fix the bugs), then make it fast (optimize). Oh ya!
D
Personally I like to write up a design document first. It''s all about abstraction, start with the basics then dive into the details a layer at a time. Start with the GDD, then work out the Technical Design Doc. From those you have a clean plate for planning your classes, once that''s done, work on the code for those classes. Then get into the nitty gritty with the actual game code using those classes. The beautiful thing about this method is that it saves so much time and keeps that feature creep out. You will know from the start what is possible and what isn''t and you''ll have much more time to figure out how everything will work together.
And Capt. Jester has it right on the money... Make it work, then make it right (fix the bugs), then make it fast (optimize). Oh ya!
D
Well, my current method is something like this
It''s going to be different for each person you ask. Just go with what works, and, above all, finish what you start.
Later,
ZE
- Decide the type of game to make. This guides step 2.
- Research engine design
- Design engine
- Implement engine, use stock materials where necessary for visuals
- Design game to be used with engine
- Implement game using unique intellectual property.
It''s going to be different for each person you ask. Just go with what works, and, above all, finish what you start.
Later,
ZE
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement