[gameprogrammer] Re: Current game projects...
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
- Date: Mon, 07 Mar 2005 11:41:51 -0600
On Sat, 2005-03-05 at 08:07 -0600, Chris Nystrom wrote:
> On Tue, 1 Mar 2005 23:04:33 -0000, Adrian Brown <enliten@xxxxxxxxxxxxxx>
> wrote:
> > I suppose the reason behind finishing the project is because most people can
> > start a project, few can actually finish one. 90% of the work takes 10% of
> > the time and few people can do that last 10% ;)
>
> I wonder if a good idea is in design to streamline what it would take
> to "finish" a project.
> Maybe you don''t need high score. Maybe you do not need sound. Maybe
> you do not even need graphics. Whatever, determine what the essense of
> the idea is, and complete that.
> For a game, what is the absolute minimum requirement to be playable?
> Goal #1 should be to get there.
>
> Once you have that, then basically you have a finished product, that
> you can then improve it. It is always more fun to tweak a working
> product, than working on a big blob of nothing.
>
> Also, once you have a working product, avoid tearing it apart as much
> as possible, and when you do break it, make goal number 1 to get it
> back into a working state as soon as possible.
>
> I am not sure if the idea of "finished" even applies to software. It
> seems like pretty much any software can be improved, extended, etc.
> Perhaps better questions are does it work, ir it releasable, would
> someone else enjoy this, would I die of embarassment if someone saw my
> code, etc, depending on your motivation for coding.
>
> Just some (maybe obvious) ideas,
> Chris
I like to break a project into three parts.
1) Required Functionality
2) Nice to have, but I can live without it
3) Bells and whistle
When the required functionality is complete, the project is complete. If
there is time and money left then you prioritize the nice to have
features and work on them until they are done or you run out of
time/money.
Bells and whistles only get done when someone realizes that they are
actually a 1 or a 2.
I like to think of it as being a road trip. Sometimes my wife and I take
a road trip and the only plan is to go in some general direction. We go
until we have used up half of the time/money allocated for the trip.
Then we come back using a different route. These trips are just for fun
and education. We stay off of the Interstate highways and drive back
roads. We stop whenever we see something interesting. We take our
camping gear because we don't know where we might spend a night. We are
just going to see what is out there.
Other times we have a specific purpose, we are going to visit our
families, or we are going to Disney World. Then we have a fixed
destination. We have a fixed schedule, we make reservations in advance.
we drive the Interstate so we can cover ground as fast as possible.
Software development is a lot like these two kinds of road trip.
Sometimes you are just trying to learn and have fun. Other times you
have a specific destination and a firm plan. The important part is to
know when you are done. That is easy with a road trip, you have only so
much time and money. But, with a home software project it is hard to
know when you are done. So, before you start a project, set some
measurable limits that you can use to know when you are done. And, if
you go past those limits, make sure you make that decision consciously.
Not that I have ever managed to do that perfectly on a home project...
But, being mindful of the time you want to spend and the goals of the
project will help you complete projects.
Bob Pendleton
>
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
