Before you code...
Author
How do you prepare for a new project? What processes, tools if any do you use? I have the bad habit of jumping into a new project head first. As soon as I have a new Idea I code it up immediately, and as you can imagine the final product is a mess. Even though it works as desired, the code is messy and not very reusable. What can I do to break my self of this habit? Should I look in to UML? What do you guys do in the way of planning?
I often find myself doing this and the most dreaded "ooh, it would be cool if it did this... oh and this... maybe this?! I'll add it just incase." It usually turns out more bloated than an M$ product.
To break myself of it:
If I come upon something that can be modulized (self-containing code) I decide what it MUST do first:
I then decide what it NEEDS to do:
Finally, my ideas that will be used alot (not maybes)
My ideas should not be added to the library. If it is not a MUST or a NEED, then its not module material.
To break myself of it:
If I come upon something that can be modulized (self-containing code) I decide what it MUST do first:
- create/destroy image data
- allow access to it
I then decide what it NEEDS to do:
- Load image data from a file
- Draw basic shapes (square, circle, and line)
- Copy image data
Finally, my ideas that will be used alot (not maybes)
My ideas should not be added to the library. If it is not a MUST or a NEED, then its not module material.
First I ask myself, can I do this project by myself in a week or less? If yes, then I just jump in. A project of that magnitude can be done without extensive planning. At least for me. Other people may have a different threshold.
If no, then the first step is to write up a design document. It doesn't have to be extensive, but I need to get down on paper (err, electrons) a) what the goal(s) for the project are and b) what the minimum feature set is. Then any other ideas I have about the project get poured on, so I don't forget them. Forgetfulness is one of the wonderful things you get to look forward to when you get older.
So then I get coding. The process goes like this: what can I do next that's in the doc that can be done with the least amount of effort? Then I do that. If I have other ideas, it goes in the document to be considered later. Then I ask myself do I like the way the code looks? If no, then I refactor. Then, check for bugs. Unit tests help here, though they are hard to write for game projects. Then fix the bugs before doing anything else. Then back to what I can do next that can be done in the least amount of effort. And sometimes the least amount of effort item is to split an existing doc item into multiple parts that are more digestible.
This process has the nice side benefit of creating documentation as I go along.
Actually there are tiers of items in the design document. As new items get added they get stuck in one of the tiers. Everything in the primary tier needs to get done before anything in the secondary or tertiary tiers. So when choosing the next minimum effort thing, only one tier is considered at a time.
Oh, and I don't worry about code reuse. Most of the time modelling a problem domain properly involves making code that doesn't lend itself to reuse. You can force it, but between doing the job right and making things harder to satsify some hypothetical future use, I choose doing the job right.
If no, then the first step is to write up a design document. It doesn't have to be extensive, but I need to get down on paper (err, electrons) a) what the goal(s) for the project are and b) what the minimum feature set is. Then any other ideas I have about the project get poured on, so I don't forget them. Forgetfulness is one of the wonderful things you get to look forward to when you get older.
So then I get coding. The process goes like this: what can I do next that's in the doc that can be done with the least amount of effort? Then I do that. If I have other ideas, it goes in the document to be considered later. Then I ask myself do I like the way the code looks? If no, then I refactor. Then, check for bugs. Unit tests help here, though they are hard to write for game projects. Then fix the bugs before doing anything else. Then back to what I can do next that can be done in the least amount of effort. And sometimes the least amount of effort item is to split an existing doc item into multiple parts that are more digestible.
This process has the nice side benefit of creating documentation as I go along.
Actually there are tiers of items in the design document. As new items get added they get stuck in one of the tiers. Everything in the primary tier needs to get done before anything in the secondary or tertiary tiers. So when choosing the next minimum effort thing, only one tier is considered at a time.
Oh, and I don't worry about code reuse. Most of the time modelling a problem domain properly involves making code that doesn't lend itself to reuse. You can force it, but between doing the job right and making things harder to satsify some hypothetical future use, I choose doing the job right.
Author
What exactly is the design document? Just a text file or something more complicated? If it wouldn’t be too much trouble I would like to see what one looks like. Also What about UML, would that help me?
I'll spend a very long time thinking about the project before I code anything. I'll split every thing up into layers. Then I'll breakk my entire project down into different object classes. For example my 3d engine is a collection of object classes with public functions. The entire engine compiled as a library. So then I can link it against any application and have instant access to my high level 3d functions. Very reusable. My gui library also compiles a library and is just collection of object classes which is also compiled as a lib and linked against the application. The best advice is to really just break down your project into different workable sections. I hope this gives you some insight. :)
Currently I've tried three approaches to my projects:
1. Jump in to the code as quickly as possible, do the most cursory design (most likely in my head). Usually the code ends up a total disaster area. Moderate risk of total failure, good chance of nothing being reusable. Although these days my code architecture is a lot better than it used to be...
2. Design the thing first as thoroughly as possible, then start coding. However I usually find so many faults with both the game design and the code architecture on paper that it never gets past this stage before I get too frustrated to continue.
3. The same as 2, but regularly post on GameDev.Net to keep up enthusiasm and to ask for ideas when stuck. This is a new strategy that I'm trying this year, which is why I'm on these forums [smile]. Wish me luck this time round...
1. Jump in to the code as quickly as possible, do the most cursory design (most likely in my head). Usually the code ends up a total disaster area. Moderate risk of total failure, good chance of nothing being reusable. Although these days my code architecture is a lot better than it used to be...
2. Design the thing first as thoroughly as possible, then start coding. However I usually find so many faults with both the game design and the code architecture on paper that it never gets past this stage before I get too frustrated to continue.
3. The same as 2, but regularly post on GameDev.Net to keep up enthusiasm and to ask for ideas when stuck. This is a new strategy that I'm trying this year, which is why I'm on these forums [smile]. Wish me luck this time round...
Design document articles
Pre-coding phase:
1. Research. If anyone has made a application like the one I'm about to do, and the application is qually good and making the application is my only goal, then I abort.
2. I write a design document, but nothing standard just basic ideas on the layout and the ideas I got ao I can understand them. Mostly UI and design notes.
3. Do a basic UML class diag(I probably would benefit from doing more diagrams) so I get a design that I want.
Coding phase
4. Code a small part.
5. Test it and make sure it works.
6. Go back to #4 until the project is complete.
Pre-coding phase:
1. Research. If anyone has made a application like the one I'm about to do, and the application is qually good and making the application is my only goal, then I abort.
2. I write a design document, but nothing standard just basic ideas on the layout and the ideas I got ao I can understand them. Mostly UI and design notes.
3. Do a basic UML class diag(I probably would benefit from doing more diagrams) so I get a design that I want.
Coding phase
4. Code a small part.
5. Test it and make sure it works.
6. Go back to #4 until the project is complete.
Tools: pen, paper, brain. Never use something that can be erased, because if you need to erase things on a document, it's a clear sign of your ideas being unclear (or evolving as you're finalizing them) and that you should throw the document away once you're finished working on it (to start anew on a blank page).
Methodology: write down use cases, as well as suggested implementation ideas (if someone else is asking you to do the work a certain way) so you have it documented for later.
From the use cases, I distinguish the objects that are made to interact in these use cases (do X to Y, apply Y to Z, transform Y into Y') and determine the interfaces required (and nothing more) for the various objects to interact as expected. Factor common parts. Redistribute the objects into a pattern that is adated to the kind of work being done: pipelines (aka sinks), collectors, adapters...
Once the modules and their interfaces are defined (down to the naming of functions), their interaction written down clearly, test procedures have been prepared and written, and everything is clear at this level of abstraction, move down a level and start thinking about the implementation of each module, just as before.
In the end, you will have, on paper, a code dependency graph: what objects must be coded before others can be coded. Start with the bottom of the graph (modules with no dependencies), implement these modules and run the prewritten tests on them. If tests pass, move up one level in the graph and implement, then test. If they don't, start debugging the fauly module and don't write a single line of code until it's done.
Every time you finish writing a module, create a new, internal graph that describes your implementation. Check this new graph against the one you wrote previously during design. Correct inefficiencies and potential bugs, and check that the module interface (pre and postcondition contracts, assertions, invariants) are respected (although this is mainly the job of tests).
For team work, the design part is hard to do (since it might involve a large part of the team) but once the toplevel design is done, each team can start working on an independent module (since modules were made independent by the design process).
Methodology: write down use cases, as well as suggested implementation ideas (if someone else is asking you to do the work a certain way) so you have it documented for later.
From the use cases, I distinguish the objects that are made to interact in these use cases (do X to Y, apply Y to Z, transform Y into Y') and determine the interfaces required (and nothing more) for the various objects to interact as expected. Factor common parts. Redistribute the objects into a pattern that is adated to the kind of work being done: pipelines (aka sinks), collectors, adapters...
Once the modules and their interfaces are defined (down to the naming of functions), their interaction written down clearly, test procedures have been prepared and written, and everything is clear at this level of abstraction, move down a level and start thinking about the implementation of each module, just as before.
In the end, you will have, on paper, a code dependency graph: what objects must be coded before others can be coded. Start with the bottom of the graph (modules with no dependencies), implement these modules and run the prewritten tests on them. If tests pass, move up one level in the graph and implement, then test. If they don't, start debugging the fauly module and don't write a single line of code until it's done.
Every time you finish writing a module, create a new, internal graph that describes your implementation. Check this new graph against the one you wrote previously during design. Correct inefficiencies and potential bugs, and check that the module interface (pre and postcondition contracts, assertions, invariants) are respected (although this is mainly the job of tests).
For team work, the design part is hard to do (since it might involve a large part of the team) but once the toplevel design is done, each team can start working on an independent module (since modules were made independent by the design process).
first of all before you start a project think about it and see(like sicare said) if you really can do it on your own, or if your knowledge covers most of what you are planing to implement and maybe read some resources to get an impression of the complexity the implementation requires
if you still feel like you could do it
start a little design document where you setup a step by step guide to implement the primiary features and maybe take care about code reuse, it s a hassel to rewrite basic code everytime you start a new project
i personally prefer long term projects and invest a lot of time in planing and writing reuseable code which will be use in the final product
as for UML, its useful if you work in teams but for personal use a simple text file that lays out the class hierarchy and its dependencies should do the job
sometimes to get stuck somewhere and see you code design is crap, so you refactor a major part of the project without redesigning the UML graph for sole man projects its a little bit overkill
the primiary problem i have is staying motivated on the long run, you work day and night on your project and the next day you have a new idea and think you should give it a try
so setup a time table til when you want to have these and that things finished and stay realistic otherwise you can t hold the final date
if you still feel like you could do it
start a little design document where you setup a step by step guide to implement the primiary features and maybe take care about code reuse, it s a hassel to rewrite basic code everytime you start a new project
i personally prefer long term projects and invest a lot of time in planing and writing reuseable code which will be use in the final product
as for UML, its useful if you work in teams but for personal use a simple text file that lays out the class hierarchy and its dependencies should do the job
sometimes to get stuck somewhere and see you code design is crap, so you refactor a major part of the project without redesigning the UML graph for sole man projects its a little bit overkill
the primiary problem i have is staying motivated on the long run, you work day and night on your project and the next day you have a new idea and think you should give it a try
so setup a time table til when you want to have these and that things finished and stay realistic otherwise you can t hold the final date
Quote:Original post by Grain
What exactly is the design document? Just a text file or something more complicated? If it wouldn’t be too much trouble I would like to see what one looks like. Also What about UML, would that help me?
An example of one of my design docs is here. This is a project that I haven't actually started coding yet. And yes, it's my 4E4 entry (provided I take the time to actually code the darn thing). Also, while I usually write up the first draft in Word, I usually transfer it to a personal Wiki during actual production, so things look quite a bit different from one of these starter docs compared to one in production.
Personally I find UML to be useful in large teams that do top-down design, but on personal projects I prefer to work bottom-up so UML is less useful.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
