2 Month Demo: Project Milestones?

Hi I've got a project coming up that is to produce a demo of a proposed Unity game in 2 months for investor presentation. The current budget can only pay for developing the demo, to which purpose is to gain further funding to complete to project to given specification. The game may or may not completely disregard the code or design of the demo.

Knowing the ultimate purpose of the demo is to pursue funding, I would like to know your various suggestions as to what type of milestones I should organize this demo project into as it is a short time span. My macro goal is to iterate the development at least twice, once per month, but probably three times. The first by the end of the 4th week, and the second and third in the last 4 weeks. This is a one programmer, one artist deal.

I don't suppose there is enough time to have more than 3 milestones, other than micro goals within each milestone.

Currently as I'm writing a design doc, I'm considering using pre-alpha, alpha, and beta milestones, knowing the final demo will likely have minor bugs that won't be noticeable during presentation. I know that fixing bugs after beta can be overly time consuming considering the prototype nature of this product, so I will end the project upon beta.

And one thing that rattles the cage a little is the fact that I'm working after the artists finishes for the most part, so I have to follow his form more or less as communication is difficult as he's in another city. The levels are nearly finished, but I'll have to touch up some errors in them. He's currently working on the character assets for the character customization system, but I'm curiously not allowed to work until he finishes the first basic set of character assets.


Does this milestone structure sound reasonable to you?

I need all the tips I can get , so let me know if something comes to mind

 

Naming three milestones doesn't really mean anything unless you set expectations of what is in those milestones. A beta typically has close to 100% functionality, are you really going to be at that point in two months?

Why are you working on character customisation? Unless that is a vital part of the gameplay experience and offers something special I can't see it being something that will attract further investment. Polish the core mechanics and the things that make the game special/different/worth investing in. If you somehow have time after that then make nice cutscenes

In the end there's not enough information to answer so specific a question. Focus on the end result; ask yourself what the investors will be looking for; work out what you need to do to provide that.

 

Focus on core gameplay and graphics.. pretty graphics.

From my experience most investors/managers etc are usually wowed by pretty graphics and things looking good.

Give them core gameplay with cubes and capsules, they'll usually laugh it off, but make it look really good with lots of eye candy, and the core mechanics in place, and you should be ok.

Don't worry about the fluff. Focus on just those two, and do them well, and do them, properly.

And don't forget, even a few sound effects can go a long way. Get at least a couple of those in.

 

Agree with Meltdown. Additional suggestions

* Have MORE than 2 milestones. One every week.
* Be agile - always functioning code.
* Focus on mechanics
* Decide early if UI is important for the demo. UI eats LOTS of time
* Content is king. Even for pursuing moneys.
* Stop reading forums and get TO WORK!

Gigi.

 

Nice tips thanks.

Gigi, UI is actually important since it's a menu based strategy game and take it easy, I haven't signed the dotted line yet

Meltdown, I hear you on graphics, luckilly we've got a pretty city and rural level already done, but what do you mean specifically about avoiding fluff? I guess particles effects and cool menu's aren't fluff since it's graphical, right?

Johnny, beta will be 100% demo functionality (limited scope), not the whole game. But I hear you, weekly milestones sounds like a good choice. And character customization is also imporant since it will be used as a tool to create all the npcs, which are many. Then again, for demo sake, I could rethink this.

 

That could get very complicated. That is why I always recommend the agile methodology. It works in iteration and has a proper process to it.