Documenting and Planning Development
Miscellaneous Forums/General Discussion/Documenting and Planning Development
Hi. I would really like to do a 'big' project over the summer (a complete full game) and was wondering what techniques or adice there are for planning and documenting the development.
I have only really done small projects and tests, so I have never botherd to plan and document stuff as I go, which often leads to messy and confusing code, which I know will become a problem in a full game.
So yea, does anyone do it?
Lots of different stuff.
Which one is suitable to your situation really depends on a lot of different things. What do you want to create, who is your target audience, who are you competeing against, how large is your market segment, what defines your customer. The answers to all these questions (and more) all help determine which process and documentation models best suit what you're trying to do.
Make a full plan, and update it as you go along. Commenting code is useful for you but unless you are planning to share it with other developers, don't bother with documentation (i.e. how it works, tricks etc). That's what I do.
Our design document is in the public domain, we use it extensivly in games development, it really does help. Grey can back that one up.
http://indiepath.com/public/DesignDocumentTemplate01.doc That's a neat way Indie... I'm going to give this to a friend, and get him to design a game, then see if I can implement his idea's into a actual game!
Probably a good test for your design document! :)
Dabz
If you're working on your own I wouldn't bother making a plan, because otherwise you're just wasting time, time spend better doing actual work. You should just make a quick list plan, should be a side of A4 at the very most, and shouldn't take you longer than an hour to think up.
Then just dive in there both feet first, like a WWF dropkick.
That's what I do every time.
If you're working on your own I wouldn't bother making a plan, because otherwise you're just wasting time, time spend better doing actual work. You should just make a quick list plan, should be a side of A4 at the very most, and shouldn't take you longer than an hour to think up.
I strongly advise against that. You'll never finish anything if you make it up as you go. Time spent planning is well invested.
Making it up as you go means you'll just keep enhancing an unfinished product. Where do you draw the finish line?
My racing engine would not have reached its "finished" state (I quote that because to Me and Evak, it was not finished.) if it wasn't for Evak teaming up with myself and having a set of goals to reach,it wouldnt have ever reached completion. Once the final goal is reached, the project is complete as far as what was required is concerned. Without a plan you dont know what your goals are.
I've finished 6 games without using a plan.
I've only ever planned one game, and consequently that game took the longest to finish.
Depends on how you work though really and what's best for you. Document by all means, but plan? Nah :)
I have to advise against ENAY's policy, and say Plan yes, document (maybe not), unless it really doesn't work for you. A plan/To Do List was ESSENTIAL for me finishing my BONUS games just to keep track of all the loose ends. Other games I jsut started and they were fine but they reach a certain point where they need a plan so you can make sure you do the important stuff next and don't miss out any little things/bugs etc.
Never done any planning in my life. At least not outside of my mind.
Well there seems to be two ways to skin a cat :) I think, as I have gotton into trouble from not planning in the past, I am one of the people who needs todo a plan to get stuff done.
I suppose it also depends on the project. I doubt anyone would expect to complete a full RPG without a plan of somekind. But a small puzzle game you could probably get away with not planning.
One of the best things about a plan is you know when you are finished.. Sounds daft, but it's true.
In my games I made the first one, on the fly.. It worked out OK, but I was tweaking things even after I'd finished.. Others I've planned out, in terms of features, but not in terms of time.. I never seem to get that right, for the feature list.
The other thing I find plans help with is getting the 'overall' structure right. If you can plan out most of the features, then sometimes, the old flash of light hits, and you find a new way of approaching the project.
Another 'sometimes', is that the planning part can actually be quite good fun, but I do know some people who get so involved in the planning that they never do the actual project.
In my games I made the first one, on the fly.. It worked out OK, but I was tweaking things even after I'd finished..
I done the same, ages ago I tried making a snake game... I wasnt bothered how it looked, I just wanted a snake game! Anyway, I finished making the basic snake engine, then the next thing I know, it had a plot! it was set in space, it had particle effects, it had aliens that shot at you, it had asteroids, bonuses... I couldnt stop! :)
God knows where it's at now
Anyway, I use a todo list, and maybe some sketchy flowcharts about the overall game design... But I'm going to give Indies plan document thing a go on my next 'I have a great idea for a game' project
Dabz
I doubt anyone would expect to complete a full RPG without a plan of somekind.
Hmm.. I'll let you know how that goes ;)
boomboom: open up any book about game design and read the first chapter :) I think your answear is there.
One of the best things about a plan is you know when you are finished.. Sounds daft, but it's true.
No you don't. It's called feature creep and it happens to everyone, amateur or professional, and whether you have a elaborate plan, or just a rough treatment.
There is such a thing as over-engineering.
Other than planning and documenting, which are both ways of procrastinating, actually making the thing a reality is the big challenge.
Daniel is part right, it's great to dream... and unless you are serious about it, that's all you are doing...
i'm a big believer in planning... OOP development almost requires that you plan ahead...
but...
don't overplan... whatever you think is that you are gonna do will change at least 2 times during the first stages of your development... have a plan, but make it flexible enough to accomodate modification...
comment your code... extensively... a big game is gonna take you months... you will forget stuff (i've already forgotten why my OO engine works, but that's one of the cool things about OOP), and if i need to mod it, i have my comments to rely on...
do regular backups... make that part of the plan... there's nothign worse than a sudden hd failure taking out months of work in a single flicker...
the most important thing though is to get started developing... basic functionality and scenery elements... the artwork can be refined at a later time... make sure that the key functionality of the game is solid, and that you can code it... then the rest will come naturally...
--Mike
Budgeting and Scheduling Your Game
By Luke Ahearn
http://www.gamasutra.com/features/20010504/ahearn_pfv.htmMight need a registration before you are able to see this, but registration is free and everyone should read Gamasutra anyway. :)
Here's a snippet:
Starting the Process
Start your schedule by breaking out the tasks to be done. If your programmers will be using an existing engine and set of editing tools, then that will decrease your development time and may even decrease your cost of development. Keep in mind that no matter what the tool set, there will still be a significant amount of programming to do if you are to develop a game that stands out. A game that is simply another game with assets swapped will have much against it in the publisher's "potential title" arena.
If your team does not have enough experience in developing projects, you may have to complete a running demo just so you and your team will be intimately familiar with the tools and code base used. Only this way can you know if there are any supplemental tools needed and what is involved in writing the additional code your game will require. Also, you need to be well aware of what the technology you licensed has been used for; it's amount of support, upgrades forthcoming, and the strengths and weaknesses of your technology.
There are four basic steps to scheduling your game development. They are:
What must be done? Having your game defined and experience with the technology to be used is imperative. You simply need to know how many levels you will have, sound effects, menu screens, code libraries, and every aspect of your game. What must be done also includes equipment purchases, office rental, hooking up phone lines, and so on.
Who will do it? You can decide who will do what based on what needs to be done. If your game is art-heavy, you need to have the right number of artists on hand.
What resources are needed to do the job? With every person you add to the team, you must add office space and furniture, computers and equipment, software and salaries. This may also include added legal expense for each contract that must be negotiated. Of course, this also includes game development software each team member will need such as programming technology and the 3D/2D tools the artist may need.
When must it be done? Each person needs detailed schedules for their work and an understanding of how their work affects the whole of the project. When deadlines are set, they must be met. The effects of one team member missing a deadline can have drastic effects team-wide.