General question about project planning

#1 Depends, how big is the project? I'm a novice and I've created a few simple point-and-click games and, working with 3 others, I've learned a couple of things about planning. Create a design doc and split the tasks. If necessary, use Excel or something to jot the tasks and then check 'em once completed. Projects most certainly need to be cut up into portions from large categories to sub-cats to lesser known. But, for me now, I don't care for design docs. Just like the good ol' days of Doom (that every bloody developer says are gone) who needs 'em. "Create as you go," is a motto of mine...one of the many I suppose.

#2 Well I want my two projects to turn into full fledged games but since it is only me right now i just want to make a working prototype.

So when you are planning tasks connor do you put a time frame and due date to them?

(IE this gun will take 5 hours to model and is due on 6/29/05)


lol i've got mottos too... my favorite being 'please just not in the groin' but i digress. I don't know it seems like i've tried everything. My biggest problem is that when i divide the project into milestones the time frames i create aren't realistic. Which leads to work being unfinished and my morale dipping lower. I read a lot of postmortems in Game Developer the project producers mention that when planning a project theres alwasy a lot of unknown and things change.

So at what point do you update the design doc and schedule to accomadate for the changes?

#3

Quote:I was wondering what would be the best way to plan a project?

I submit that there is no "best" way. If you talk to professional developers, answers range from "having a design document is crucial" to "our project plan was written on a napkin." The best way is whatever way works for you; unfortunately you just have to discover that for yourself.

Quote:How does everyone out there plan/document what tasks need to be done?

I use a humble spreadsheet to keep it simple. My games are small so I don' t need to engage in sprawling PM. Each line item contains the category of the task (3d art, 2d art, programming...), task description, who will be completing the task, the amount budgeted for the task, and the amount paid for the task. My plan revolves around my budget; my budget is the nucleus of my plan.

I break this spreadsheet into three main parts -- what's been done, what needs to be done next, and fuzzy future events. I focus myself on the middle of those three, with a "next" time period of about 4-6 weeks. As items get completed, I decide when to bring things from the 3rd category into the 2nd one. Until then I don't worry too much about them, save for making sure that my budget matches my income.

Quote:How do you guys track it to measure progress?

Pretty much answered above. I have three main indicators of progress. One, how much money I've spent on the project versus how much money is required remaining to complete it. Two, how many tasks are completed, in progress, or pending (my three main categories). Three, how playable, fun, good looking, and bug free the software is.

I take a pretty relaxed, middle-road approach to dates. I never say "items to be completed this week", but I also never say "items to be completed by 4 months from now." I focus on a middle-range of what's coming up in about the next 4-6 weeks. In part, because you don't know what you don't know (i.e. I never expected to re-work all models for one game with a second pass on the art, or for simple tank functionality in another game to take so long and be so involved). The other reason is because my budget is limited to my paycheck and personal expenses, and I can't plan that out further than 4-6 weeks (because a sick dog or car can mean a delay in scheduling, and I'm a temp employee so I never know when my job is going to end).

Hope this helps!

#4 Okay, so Joshua has some aspects you should take into. But still, a one man team shouldn't really account for too much documentation. When you set a date, and you are trying to be realistic and you are but a novice, than don't sweat it cause you are already destined to jump the date and have to set another one. It is mandatory.

I love prototypes. Depending on how good the prototype is it gives a good account for how the game will turn out. And are these full-fledged projects of yours going to be done just by yourself? Shooters? RPG's? (RPG's suck in my book with all the dialogue planning and such). For me, I'm starting off with a simple shooter with the T2D that I'll start just after the summer. Then a game a lot like the Legend of Zelda Classic NES Series you see on the GBA. Top-down. And with that, I just have to document the story, characters, art, and etc. That's going to be simple because it will be 2D. But with the Torque, in making a 3D game, I've only made a first-person shooter for fun and I can definently say I'm a novice at that.

#5 Thanks Joshua, That definately helps. One thing though, how do you determine how much each task will cost? I already have most of the software..... Do you measure your costs in terms of how much time you spent working on that particular item?

In other words do you say your time is worth x amount of dollars an hour and then calculate how much you could have made for those hours?


Connor, right now I'm just planning on making the prototypes for 2 reasons. 1) I think it will be easier to attract potential teamates to help complete the game if you have something fun to show. 2) the prototype can test the fun of the game, like you were saying.

I do want to eventually make them both full fledged titles. one is an FPS/vehicle combat game done with 3d game studio. another is an RTS i'm doing in torque.

#6 I'm in agreement with Joshua on pretty much every point.

There are better project planning tools out there, especially if you have projects with lots of dependencies that need to have the "critical path" solved. But in general, a "hit list" of tasks works for me. I don't tend to calculate costs too much, because my budget is so small, but especially near the end of the project I do have to prioritize HEAVILY based on the benefit of the feature, the 'expense' of the feature (meaning how much time and effort it would take to not only develop the feature, but to integrate it and debug it), and the "risk level". A "freaking cool" feature that would take very little time to develop, require little extra effort to integrate it into the game, and would have minimal impact on other systems (thus being low-risk) would be a pretty high priority item. A fundamental change to how models get rendered to enable users with higher-end machines the chance to see some neat shader effects would be a lot lower priority.

Another thing I do is create a list of "key features" and a high-level statement of what the game should be. This I communicate with others I work with, but I also keep it in mind as I'm working on the game so I don't lose the forest for the trees. In Void War, for example, I knew the focus was on multiplayer space dogfighting with pseudo-Newtonian physics to make the flying aspect fun (too many space combat games felt like there was little purpose to flying other than to get into range - it was all about shooting accurately). So as I evaluated tasks, I was able to prioritize them based on how well they fit into that high-level description. It can all change, of course, so long as it's a conscious evolution of the game.

#7 If you dont know the technology (ie: torque for instance) then that should be your first priority, before any other project planning.

Give yourself X weeks of tech exploration and then get back to a project planning drawing board.

But i have to say, it's a VERY good thing you are thinking about this problem. That's how you get things done.. by planning out what's needed.

#8

Quote:Thanks Joshua, That definately helps. One thing though, how do you determine how much each task will cost? I already have most of the software..... Do you measure your costs in terms of how much time you spent working on that particular item?

It was assuming that you are not doing the work yourself and have some kind of budget. If you're doing the work yourself the cost is zero, though I suppose you could estimate a "time cost."

I determine not what each task will cost, but how much I am able to budget for it, which is a fraction of what it should cost. For example, if I can only spend $x on ground textures, then no matter the quality (low or high), that's the most I can spend, and I try to find the best artist willing to work for that price. Otherwise I'm over budget, and over budget means it will never get done and just snowball in time and expense.

#9 @ Jay

I read a good postmortem for Oasis on Gamasutra the author talked about how he decided on his features by making core principles of what the game would play like. He used this to determine if further design decisions fit into that scheme or not. is that something similar to what you're talking about?

#10 @ Jay

I read a good postmortem for Oasis on Gamasutra the author talked about how he decided on his features by making core principles of what the game would play like. He used this to determine if further design decisions fit into that scheme or not. is that something similar to what you're talking about?

#11 I actually do a good bit of project planning both as a technology consultant, an automation engineer (my current profession) and I do the project planning for Working Name Games (Our current game studio).

Project planning is the absolute key to success to any project. I say that with 100% confidence. The only thing that changes is different people and teams like to plan things differently. If you're a 1-man shop then you only have to plan as much as you want to and are comfortable with. There is not set methodology to it.

If you are dealing with a large team or even a small one, planning can get even more crucial. Again though it all depends on how the group works. If you are dealing with people who are all deeply involved, knowledgeable and proactive, then broad guidelines are generally ok. That's because everyone will make sure that any loose ends from their work is tracked down and finished nice and tidy like. If your working with very specific people who are very talented in certain areas but not on the whole scope of the project then detail planning can save huge amounts of time and effort. That way no one can say, "That was not my job", or " How was I supposed to know that?"

Overall I generally go through a broad brainstorming session with everyone on the team to get the broad scope of the project. Then I further break everything down into the smallest deliverable components. (Again that is something that can be defined differently for every team). Then I get together with each team lead (or individual responsible for a given area) to ensure I have everything broken down in that area appropriately.

Once I have all the tasks determined, I further specify which tasks depend on others. If A must be done before B or can C, D and E all be worked on at the same time as A. For a single man project that doesn't matter unless you like to switch from task to task to keep yourself from getting board and letting the project grow stale.

When you know all the precursor tasks and what order things must be completed you can prioritize and line up all of your tasks. For each task I generally have a name, description, required tasks, department or area, person responsible, and estimated start time and estimated duration.

If you're new to project planning, here is a hint, Double all your estimates. Once you get a better feel for time estimates you can be more reasonable. A project goes by more smoothly if you hit all your milestones early than if your missing all of them...

My style of planning is a lot heavier than most, but this way I can evaluate where each person is in the project. I can calculate project percent completes for each person as well as the team overall. It also lets me reprioritize tasks if certain key tasks are delayed by seeing all the task dependencies. Again it can be way more than a single person team needs unless that person like to know exactly where everything is in the schedule at all times. It is definitely more geared towards full teams.

But you can never tell if you're off track if you don't have a plan. A plan is just your guideline and your measuring stick. If you don't like it you can always change it, but without a measuring stick you cannot tell how far you have gone.

There is a ton of specifics we can talk about when it comes to project and task planning and tracking. If you want more info let me know and I will help you with any other questions you may have.

#12 I've been on a few group projects for school, including one with Torque. When dealing with a group it is easy to run into integration problems. We ended up with many different versions of our project and wasted lots of time trying to figure out which one was the newest working release. So, version control is a must for a group. We could have used a CVS tool to keep things sorted out, but with only 3 team members, this seemed like overkill. We overcame this obstacle by making sure to duplicate the newest version and only modify the copy. One team member was then responsible for combining the other members work into a newer 'final' version.

#13 Before coding think very hard about all the little details of implementation, don't cut corners on this step. Its ok too spend lots of time in the planning phase.

#14 But how? There are so many little intagibles when it comes to coding. how do you plan out your code needs?

#15 @Marvin - Go to the Torque General Documentation and read the write up about the creation of Marble Blast. That should give you some insight.