How do you organize your project development process?
Author
well guys, if you're creating your very own game/engine, how do you keep your design and ideas organized?
I always had this problem - putting down more and more things into my project notebook, pages, which look more and more crammed with things being not readable two days later, project reorgniazation every 10th page, TODO lists every other, some random thoughts come next, then a desciption of some class or process, two pages later a nice drawing of a in-game HUD, lists here, objects there, somewhere a slip of paper put between the pages with some notes...ahh...
do you all really use UML for everything, even your homemade projects?
or do you keep several notebooks? maybe organizers with dates?
do you keep your daily work records in a separate book?
tell me, how your work looks like? :)
cheers!
[Edited by - rein on April 28, 2006 1:12:32 PM]
I keep a chaotic mess of scraps of paper and Notepad documents. The closest thing I have to an organized system is putting all of the scraps into a single pile [smile]
Generally, though, anything I jot down that's important I will immediately document either in a Word doc, or, better, the team's wiki. A wiki may seem like overkill for a solo project, but honestly if I started a solo project of my own I wouldn't do it without a wiki at this point.
My typed documents are kept in a massive folder hierarchy that covers pretty much every possible category of document that I would write. It isn't the best setup in the world, but it at least keeps me from losing important stuff.
Oh, I never touch UML. I draw a lot of diagrams, but not really with any hard rules of operation - just sketches to visually illustrate a point.
Generally, though, anything I jot down that's important I will immediately document either in a Word doc, or, better, the team's wiki. A wiki may seem like overkill for a solo project, but honestly if I started a solo project of my own I wouldn't do it without a wiki at this point.
My typed documents are kept in a massive folder hierarchy that covers pretty much every possible category of document that I would write. It isn't the best setup in the world, but it at least keeps me from losing important stuff.
Oh, I never touch UML. I draw a lot of diagrams, but not really with any hard rules of operation - just sketches to visually illustrate a point.
1.
Write down a vision of your software, engine, or game. The vision should not contain any details about features, code, or technology but more the essence of what you want to create. If you later change alot of your features, or requirements ... it should not change much of your vision. It's your basic guideline so to speak.
2.
Gathering requirements is a tedious process, and if you've never done much before, it takes repeatedly times before you get used to it, and get comfortable with the process.
Most important with gathering requirements is to not think about code, functions, database design, code design, standards, tools. Try keep details down in beginning, and add more later.
- If you make a game. Think about what the game should do. What rules does it have. When do you win or loose. How is it played. How many players. etc etc.
Ex: Quake clone - You move(forward, back, turn, go left, jump) around in a 3d world (got walls, floors, windows, crates). You use a weapon (rifle, grenade, rocket launcher) to kill(do a certain amount of damage) other characters( controlled by other ppl or machine).
Rules - Every characther has a certain amount of healt, like 100 points. Weapons do either direct damage like bullet from rifles, or does area of effect damage like grenade. To determine damage from aoe weapons you need to know the distance between grenade and victim to determine damage. Upon death, you are returned to a spawn point. A game last 10min, winner is the one who get most kills.
GUI - See health, ammo, minimap. Chat system. Be able to map keys. Save/load games?? Create a game and choose map. See statistics( kills, deaths, ammo spent).
More can be added. At this point i think you will have a job for next 2 years maybe. So it would be a good idea to narrow it down to "least amount needed" and put the rest in a "if we got time".
But if I was you, I would now try to create more details to various stuff. How to calculate damage. Figure out details about animation. Shall we see from the head, above head, or birds eye of your characther? 2D or 3D?
More you work at this, more subject needs to be learned. How and what is 3D models. Sound? Textures. Animation. Particle system? Character encoding? Multithreading? Networking? Implementing scripting?
When I say learn, it means to get enough knowledge to make decisions about what to make.
Making decisions about coding in c++, directx, win32 etc etc is something you do later on, and not in beginning. Remeber a basic 3D program can be done in both java, c++, c#. But if you figure out you wanna do 3D, and create models and animation in 3d studio, and the best export plugin is .x ... maybe directx will save you time when it comes to implement.
Goals:
Why you wanna do this? Is it to learn something? Is it to create something?
If you want to learn about how to animate a 3d model, then making a 3d engine is very much overkill. Just a simple code to display it will be enough.
Constraints:
How much time you've got? What software do you have? Licensing?
Make a list of "What not to make", to figure out boundaries to your development.
End:
It will also be a good idea to make pictures, diagrams, and even demoes of particular features. This helps visual what you need. Brainstorming with others is also a good thing to figure out stuff. But find someone who can disagree with you. Kinda useless if they agree to everything.
You should also think about if it is possible to use already made engines, libraries etc. They put more constraints on a development, but could reduce time in development.
Write down a vision of your software, engine, or game. The vision should not contain any details about features, code, or technology but more the essence of what you want to create. If you later change alot of your features, or requirements ... it should not change much of your vision. It's your basic guideline so to speak.
2.
Gathering requirements is a tedious process, and if you've never done much before, it takes repeatedly times before you get used to it, and get comfortable with the process.
Most important with gathering requirements is to not think about code, functions, database design, code design, standards, tools. Try keep details down in beginning, and add more later.
- If you make a game. Think about what the game should do. What rules does it have. When do you win or loose. How is it played. How many players. etc etc.
Ex: Quake clone - You move(forward, back, turn, go left, jump) around in a 3d world (got walls, floors, windows, crates). You use a weapon (rifle, grenade, rocket launcher) to kill(do a certain amount of damage) other characters( controlled by other ppl or machine).
Rules - Every characther has a certain amount of healt, like 100 points. Weapons do either direct damage like bullet from rifles, or does area of effect damage like grenade. To determine damage from aoe weapons you need to know the distance between grenade and victim to determine damage. Upon death, you are returned to a spawn point. A game last 10min, winner is the one who get most kills.
GUI - See health, ammo, minimap. Chat system. Be able to map keys. Save/load games?? Create a game and choose map. See statistics( kills, deaths, ammo spent).
More can be added. At this point i think you will have a job for next 2 years maybe. So it would be a good idea to narrow it down to "least amount needed" and put the rest in a "if we got time".
But if I was you, I would now try to create more details to various stuff. How to calculate damage. Figure out details about animation. Shall we see from the head, above head, or birds eye of your characther? 2D or 3D?
More you work at this, more subject needs to be learned. How and what is 3D models. Sound? Textures. Animation. Particle system? Character encoding? Multithreading? Networking? Implementing scripting?
When I say learn, it means to get enough knowledge to make decisions about what to make.
Making decisions about coding in c++, directx, win32 etc etc is something you do later on, and not in beginning. Remeber a basic 3D program can be done in both java, c++, c#. But if you figure out you wanna do 3D, and create models and animation in 3d studio, and the best export plugin is .x ... maybe directx will save you time when it comes to implement.
Goals:
Why you wanna do this? Is it to learn something? Is it to create something?
If you want to learn about how to animate a 3d model, then making a 3d engine is very much overkill. Just a simple code to display it will be enough.
Constraints:
How much time you've got? What software do you have? Licensing?
Make a list of "What not to make", to figure out boundaries to your development.
End:
It will also be a good idea to make pictures, diagrams, and even demoes of particular features. This helps visual what you need. Brainstorming with others is also a good thing to figure out stuff. But find someone who can disagree with you. Kinda useless if they agree to everything.
You should also think about if it is possible to use already made engines, libraries etc. They put more constraints on a development, but could reduce time in development.
Author
umm DarkSlayer, what you've described in your post is just a design doc.
I've read a a skyhigh pile of topics covering those.
but I'm curious how do you actually hold it, keep it and use it, the technical development after you know exactly what you are doing?
writing a whole document in Word just isn't at strike - it would take months to look up every single shred of information you need while writing your code, not mentioning constant changes... and what's more important, you cannot predict every single class and function before you actullay start mocking up your code
ApochPiQ:
hehe but are those scrap piles really the best possible way to keep the projects dev on track? :D
Right now, apart from design doc, my technical and development guidelines are split into dozens of A4's all over the place I work :( It's....awkward.....
I've read a a skyhigh pile of topics covering those.
but I'm curious how do you actually hold it, keep it and use it, the technical development after you know exactly what you are doing?
writing a whole document in Word just isn't at strike - it would take months to look up every single shred of information you need while writing your code, not mentioning constant changes... and what's more important, you cannot predict every single class and function before you actullay start mocking up your code
ApochPiQ:
hehe but are those scrap piles really the best possible way to keep the projects dev on track? :D
Right now, apart from design doc, my technical and development guidelines are split into dozens of A4's all over the place I work :( It's....awkward.....
The Pile of Doom only works well for the initial thinking process. It's important to fully flesh out your notes into document files - again a wiki is an invaluable tool here. Typing out the full details of a concept will force you to think it over carefully, and it also gives you a set of small, to-the-point documents for various topics.
Another good tool to use is a task tracking package; most bug managers can be pressed into service as TODO-list management, but a dedicated planning package is worth its (virtual) weight in gold. The combination of a good planning package and a good wiki gives you some amazing power in tracking what you're working on, measuring progress, and generally keeping your plans sorted out.
My general rule of thumb is "my brain can't fit that." Anything I need to remember gets recorded someplace - tasks go in the task management software, plans and documentation go in the wiki, and personal cruft goes on scraps of paper and PostIt notes all over my desk.
Another good tool to use is a task tracking package; most bug managers can be pressed into service as TODO-list management, but a dedicated planning package is worth its (virtual) weight in gold. The combination of a good planning package and a good wiki gives you some amazing power in tracking what you're working on, measuring progress, and generally keeping your plans sorted out.
My general rule of thumb is "my brain can't fit that." Anything I need to remember gets recorded someplace - tasks go in the task management software, plans and documentation go in the wiki, and personal cruft goes on scraps of paper and PostIt notes all over my desk.
Author
ApochPiQ, your words are invaluable for me :)
but can you point me out how I can gear wiki to suit my very own use?
I haven't investigated it's possibilities throughoutly yet.
also, what task management program could you recommend for personal use (not very sophisticated ones)? I'd be very glad to keep my TODOs in one single place, and not being spread over trillions of items (notepads,walls,hands,cellphones etc)
but can you point me out how I can gear wiki to suit my very own use?
I haven't investigated it's possibilities throughoutly yet.
also, what task management program could you recommend for personal use (not very sophisticated ones)? I'd be very glad to keep my TODOs in one single place, and not being spread over trillions of items (notepads,walls,hands,cellphones etc)
The easiest way to start making use of a wiki package is to install a webserver and the wiki software on your local development machine. (Of course, if you have a suitable network and a spare box, you can use that as a server for added convenience.) I believe WinXP Pro comes with a limited version of Microsoft's IIS webserver; all else failing, you can use the free Apache webserver as well.
I don't know any good personal-scale wiki packages off the top of my head, although I've heard good things about TWiki. Basically, using it for yourself is just like using it in a group - you add the pages you need, set up a hierarchy, and edit content as needed. It's pretty easy to play around with and get used to.
Task tracking is a bit of a sticky point. For personal use, Outlook works fine, and I'm sure there's a decent free alternative out there someplace.
Our team uses Atlassian's Confluence wiki package and JIRA task tracking system, both of which are superb tools - but they'll cost a fair bit of cash.
I don't know any good personal-scale wiki packages off the top of my head, although I've heard good things about TWiki. Basically, using it for yourself is just like using it in a group - you add the pages you need, set up a hierarchy, and edit content as needed. It's pretty easy to play around with and get used to.
Task tracking is a bit of a sticky point. For personal use, Outlook works fine, and I'm sure there's a decent free alternative out there someplace.
Our team uses Atlassian's Confluence wiki package and JIRA task tracking system, both of which are superb tools - but they'll cost a fair bit of cash.
My point is...
Everybody on this site ask this question: I wanna make a 3d engine like quake - how am i gonna do this?
Answear: You can't.
What I described was a vision and requirements document. Not design, I stoped shortly of that point cause it takes more explanation.
Finding requirements first is important. You pretty much want a list that say:
- THIS application SHALL be able to load images
- THIS application SHALL be able to load 3d models
- THIS application SHALL be able to load animation
- THIS application SHALL be able to ....
you get the point...
The design document should take this list and look into how to realise these requirements.
Design is alot more about code, standards and format to use, and how to acomplish features by the way.
- Use DirectX to load textures, 3d models and animation ... created in 3d studio ... exported in .x
create class diagrams (i've used rational rose for that, but try find something else). What objects do you want, what should they do, and what relationship is it between them.
On paper try use post-it(yellow small sticky paper) to quick make some classes and how you would connect them.
Prototyping:
Make an quick image loader in code, so you know how to do that part. Or load 3d models ... make some ... whatever.
Many use prototyping for research, and figure out how to do a particular task.
Estimate:
Every thing you want to make - estimate how long it gonna take you to make it. If you don't know how long it gonna take, try break the feature down into smaller pices and try estimate again. Still not sure? Try make a quick prototype of it, but don't spend too much time on it.
Todo list:
BEFORE you make a todo list. Make sure you know how long each ting takes, and have a gut feeling that you can finish the entire list. No point making a huge list, and quit after you get into trouble doing the third item.
This requirements/design process is not something you get quickly used to, or figure out fast. Takes time to get used to(one year for me). The point with it is to give you a todo list (if you want that) that you can complete within your timeframe and cost.
There is not any web-resources i've found so far that is close to helpful in helping out in this process. So just start and stick with word ,paint, paper, pencil and post-it.
What I learned: It takes a shitload of time to make any 3d at all. And it looks and feel crappy at best. Especially if you want to make everything from scratch. You get very dependant on alot of libraries to get anywere. You should also try find ppl to develop with, or try get into an open source project. Finding ppl who know how to do stuff is very rewarding
Everybody on this site ask this question: I wanna make a 3d engine like quake - how am i gonna do this?
Answear: You can't.
What I described was a vision and requirements document. Not design, I stoped shortly of that point cause it takes more explanation.
Finding requirements first is important. You pretty much want a list that say:
- THIS application SHALL be able to load images
- THIS application SHALL be able to load 3d models
- THIS application SHALL be able to load animation
- THIS application SHALL be able to ....
you get the point...
The design document should take this list and look into how to realise these requirements.
Design is alot more about code, standards and format to use, and how to acomplish features by the way.
- Use DirectX to load textures, 3d models and animation ... created in 3d studio ... exported in .x
create class diagrams (i've used rational rose for that, but try find something else). What objects do you want, what should they do, and what relationship is it between them.
On paper try use post-it(yellow small sticky paper) to quick make some classes and how you would connect them.
Prototyping:
Make an quick image loader in code, so you know how to do that part. Or load 3d models ... make some ... whatever.
Many use prototyping for research, and figure out how to do a particular task.
Estimate:
Every thing you want to make - estimate how long it gonna take you to make it. If you don't know how long it gonna take, try break the feature down into smaller pices and try estimate again. Still not sure? Try make a quick prototype of it, but don't spend too much time on it.
Todo list:
BEFORE you make a todo list. Make sure you know how long each ting takes, and have a gut feeling that you can finish the entire list. No point making a huge list, and quit after you get into trouble doing the third item.
This requirements/design process is not something you get quickly used to, or figure out fast. Takes time to get used to(one year for me). The point with it is to give you a todo list (if you want that) that you can complete within your timeframe and cost.
There is not any web-resources i've found so far that is close to helpful in helping out in this process. So just start and stick with word ,paint, paper, pencil and post-it.
What I learned: It takes a shitload of time to make any 3d at all. And it looks and feel crappy at best. Especially if you want to make everything from scratch. You get very dependant on alot of libraries to get anywere. You should also try find ppl to develop with, or try get into an open source project. Finding ppl who know how to do stuff is very rewarding
Author
DarkSlayer, I already know all that. to those people wanting to create a full game from scratch in notime I've been giving advices myself, and I have a few fairly advanced projects in my portfolio.
however, the point of my topic was to improve my code planning and training skills, not figuring out 'how to make a game from a misty idea'.
-> the problem is NOT what to do and in which ways to plan it, but how actually put those plans down to make them look clear after a week or so (avoiding the Pile of Doom effect)
not to sound unfounded, I'm currently on a completion stage of dynamic dll framework for further programs, which can be 'injected' into the core - sth similiar to valve's Steam.
but after all I found myself straying from the main threads and ruin myself among the documentations. So I ask here what is your way of keeping this doc in mind and not loosing control over it
cheers!
however, the point of my topic was to improve my code planning and training skills, not figuring out 'how to make a game from a misty idea'.
-> the problem is NOT what to do and in which ways to plan it, but how actually put those plans down to make them look clear after a week or so (avoiding the Pile of Doom effect)
not to sound unfounded, I'm currently on a completion stage of dynamic dll framework for further programs, which can be 'injected' into the core - sth similiar to valve's Steam.
but after all I found myself straying from the main threads and ruin myself among the documentations. So I ask here what is your way of keeping this doc in mind and not loosing control over it
cheers!
Quote:Original post by ApochPiQ
Task tracking is a bit of a sticky point. For personal use, Outlook works fine, and I'm sure there's a decent free alternative out there someplace.
There is an application called ToDoList.
I use it for my tasks all the time - it's free (open source) and it's very good.
ToDoList homepage:
http://www.abstractspoon.com/tdl_resources.html
ToDoList CodeProject article (with screenshots):
http://www.codeproject.com/tools/ToDoList2.asp
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
