Hey all, I have a bit of a catch-22 which I am about to get knee-deep into. A friend of mine (who heads a self-run business) is interested in getting funding to create an educational game. He came to me 2 weeks ago, and I'm very interested in the project. In the long run, it'll end up (visually) something of a graphical adventure, along the lines of Monkey Island... but targetted at providing educational text for youths, so they learn something along the way. Now, the only way that this project will be funded, is through my friend's contacts who are able to supply government-backed funding. However, they won't fund without a demo project, so they are able to see what they're getting into. Thus the responsibility falls to myself to provide a workable demo. The problem I have with this is, even if we have but one screen in which a demo-tester can move, it will take me a good chunk of time to get the demo to a usable state. Kinda like coding Monkey Island, but never providing more than one screen from which Threepwood could progress. I figure I could: A) Create a hard-coded demo, then start on the 'real' project, OR B) Spend the time now (weeks? months?) to save some time in the long run by coding the demo's engine to expose all the necessary features (most of which will appear in the final version), and flirt with the possibility that funding might fall through in any case, OR C) Utilize a graphical adventure game kit to produce the demo, and fudge the presentation to get funding earlier. 'B' seems the honorable choice, but I stand the chance to waste a lot of time AND money if I happen to take too long producing a demo, or the funders change their minds (as nothing is written in stone until the demo is on the table). 'C' is definitely out for me (if something messed up real bad, I could lose the funding AND a friend) but remains a possibility. 'A' also seems a possibility, and would mean getting the contract early, giving me breathing room to know that my time won't be wasted. Anyone ever face this sort of rock/hard place before? What did you do?

Personally I'd think of option C in a different way:

C) use an off the shelf package to produce a "prototype" to show the backers. Make sure the backers and your friend understand that what you've produced is only a prototype rather than final code.

The prototype (or prototypes) will be helpful for proving and exploring game design and artistic ideas as well as identifying areas of risk. Reducing the unknowns at the start of a project is beneficial (and cheaper) to you, your friend and the financiers.

As well as the prototype, provide a rough development schedule [and possibly costings] so that everyone knows how long real code would take to write once the "unknowns"/"risk" has been assessed.



There may even be an option D:

D) the average hardware and style tastes of the target market mean you could construct the whole game in an off the shelf package. There are a hell of a lot of commercially released products made with things like Macromedia Director for example.

There's a big possibility that the scope of the application you're making doesn't need highly tuned custom C++ code written from scratch.

It might be a classic case of "Build vs Buy" or "Not Invented Here"

All good suggestions. You could also sign a deal for the prototype first, which could be based on a no-cure-no-pay basis. What I mean is, you can propose to build a basic prototype in, say, a month. Then the deal will be that if the customer is satisfied (clearly write down beforehand what would satisfy him/her) you get the full project. In that case, the prototype manufacturing time could be factured in the whole end bill. In the case that what you had in mind is not what they wanted, they get nothing from you and you have wasted a month of time. But you also may have a small and stable platform to offer other projects.

Greetz,

Illco

Personally, i'd go with A, it wouldnt take too much time to set up, and the graphics wouldnt be a waste, and niether would part of the code.