Jump to content
Double Fine Action Forums
Sign in to follow this  
Jericu

At what point is a prototype "Done"?

Recommended Posts

So, I'm really amazed at what Double Fine can pump out with 2 weeks of concentrated work during Amnesia Fortnight. I only recently got the 2012 prototypes, and they're fantastic considering the amount of time they took (not much). The thing with Amnesia Fortnight is that obviously things can't get to their "final" state or be polished to the degree you'd like due to time constraints. So, besides the obvious answer of "12 o'clock midnight on the final day," at what point can you call your prototypes "finished"? Meaning, when are they in a position where you feel like you've done all you can with them?

Share this post


Link to post
Share on other sites
So, I'm really amazed at what Double Fine can pump out with 2 weeks of concentrated work during Amnesia Fortnight. I only recently got the 2012 prototypes, and they're fantastic considering the amount of time they took (not much). The thing with Amnesia Fortnight is that obviously things can't get to their "final" state or be polished to the degree you'd like due to time constraints. So, besides the obvious answer of "12 o'clock midnight on the final day," at what point can you call your prototypes "finished"? Meaning, when are they in a position where you feel like you've done all you can with them?

Unfortunately the obvious answer is the only true answer. There's no way they will get anywhere close to a point where they could even think of maybe considering the remote possibility that their project is anywhere even remotely close to being considered "finished" in just two weeks. They will probably keep working on them right up until the last moment, especially since the prototypes will be seen by their adoring fans.

Share this post


Link to post
Share on other sites

I will go as far as saying that a video game is never truly "done". There is always more that game makers want to do or add. They want to polish all the animations. They want to add a bunch of things and work on tighter controls/mechanics. A game has three states: an idea, in development, and released. They are never truly "done".

Share this post


Link to post
Share on other sites

One practical view is: A prototype is done when you can see, based on the prototype, whether or not it's worth turning into a full production.

Share this post


Link to post
Share on other sites
Another answer could be when they have been converted into full products, sold and the development budget fully spent.

I'd say no to this one, as the world is full of prototypes, which never go into production. Prototypes in general are used to see if something is feasible and if the original idea is good as it is or if there should be some major changes made to it. Though it is not unusual if some features from the proto are taken in use in other products. Car industry for an example does this all the time.

I'd say prottype is finished at the point where it has more or less the components you want to try out in one form or an another, i.e. they don't even have to be fully functional.

Share this post


Link to post
Share on other sites

In Amnesia Fortnight's case, the prototype needs to be playable for the community - it cannot be only a proof of concept.

In a non-open process (unlike this year's AF), there is more flexibility in regards to what is considered a prototype and when it is done.

If I recall correctly, there was a thread in 2012's AF discussing whether QA guys would participate in the process. In that case, again if memory does not fail me (it might), someone from DF said if the prototype was unplayable at the end of AF, the team would spend some (not much!) time in the following weeks to polish it a bit more, but that there would be no formal quality analysis.

Share this post


Link to post
Share on other sites
In Amnesia Fortnight's case, the prototype needs to be playable for the community - it cannot be only a proof of concept.

That's just not true - it can get much be a proof of concept, and it would be a terrible idea to put that sort of insane amount of pressure on the teams. It needs to be 'built' enough that they can build it and release on Steam, but it's still very much like their usual prototype process.

People buy into Amnesia Fortnight on the understanding that they get to influence what Double Fine makes next, and in return they get a peek into the dev process and at the end get something to play with that might be really fleshed out and flashy like Autonomous was, or kinda limited and proof-of-concepty like Spacebase-DF9 was.

If people are paying for these prototypes on the understanding that they're definitely going to get something more than a proof-of-concept, then they're mistaken.

Share this post


Link to post
Share on other sites

Yeah, I'd say "Proof of concept" is pretty much exactly what the (hopefully) realistic end goal is: A playable slice that ideally demonstrates some of the core gameplay mechanics that made the pitch interesting in the first place. And even then, likely just skimming the surface of even the elements that are presented.

And that's still pretty damn good, on a two week timescale.

Share this post


Link to post
Share on other sites
In Amnesia Fortnight's case, the prototype needs to be playable for the community - it cannot be only a proof of concept.

blablabla

I understand what you mean and I definitely do not expect much from the prototypes, but maybe it was not clear to you what I meant by playable. Spacebase definitely fits the description of playable to me. It is a game with gigantic scope and anyone expecting more than what the prototype provided clear had wrong expectations in regards to the process.

However, yes, the pressure on the teams is much much bigger when the jam is open to the public than when it is a closed process, that's just the way it is and it's DF's choice.

Check the Happy Song prototype, for example. It is playable and fun, more or less just a proof of concept, but I bet the amount of effort and content put into it would have been bigger if it was part of an open process like 2012's and this year's. I bet the size of the team working on it would have been bigger as well.

Share this post


Link to post
Share on other sites

Games are supposed to always be "Done." Considering that when it comes to a creative work, especially complex ones, the idea of "Done" in an artistic sense doesn't really ever come to fruition. However, from perspective of software project management there's a method for making sure you're *always* "Done."

Although I'm not a game developer, I'm a software developer. With a short timeline or even a long timeline with many short sprints, the big concept is iteration. The point is that every time you iterate you end up with usable software. That means, while it may not be complete as far as features go, it runs and is usable. Near to the end of the sprint, in this case two weeks, the features are frozen and testing and bug fixing take over. This is all regardless of whether or not all desired features made it into the software. Having fewer features that work is far better than having more features that don't work.

In this way, at the end of every sprint the software is in a technical sense is "Done" and shippable. Though really what that means is that the features that are in the software work.

If there's more sprints to follow, those features that didn't get into the software during the last sprint get re-prioritized. There's a thing called a "feature backlog", basically a huge list of features prioritized by necessity and sometimes even weighted by difficulty to estimate the amount of time it could take to do the work. At the end of every sprint the feature backlog is re-prioritized.

There's multiple goals for this iterative approach:

1) The software could be shipped at the end of any sprint, sold, and has a good chance of working well despite being incomplete.

2) Regular opportunities to re-prioritize features and even add new ones...

2a) which also includes responding to customer/market feedback, which makes the software more attractive to customers.

2a is most common when it comes to business/enterprise software as customer needs often drive what gets put into software. Traditionally this approach wasn't common with game development but as we've seen with Spacebase DF-9 and later on Massive Chalice, there's times when making use of customer feedback is critical to making a game fun and appealing-- plus it generates community good will. You may not see this as often with story based games, for systems based games it's super helpful.

Share this post


Link to post
Share on other sites

DF uses Scrum, so their process is pretty much that. The discussion in the thread is whether DF (or the teams) would be willing to do one more (short) sprint after the end of AF in case by that time the prototype is broken (or close to that).

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...