Prototypes

[Teq]

How many of you guys prototype your games before undertaking heavy development? I think this is aimed more towards the simpler indie games. I've thus far written 3 proof of concepts (all written in C++ using OpenGL), the amount of time saved is subject to debate though (two of the prototypes being for the the same project and said project isn't currently in development), but certainly helped to tweak areas of the game I had questions about...

[PoV]

Lets put it this way. I like to be sure my gameplay doesn't suck before I really get in to doing other assets (unless I need a break from the code). I'd love to do more random prototypes (A LD compo every weekend), but it's not practical for me yet.

[Christian]

Diablo was prototyped, and it was not a simple indie game.
You need to prototype when you want to make sure that a new concept works as intended, if it is an old concept, you dont need to prototype nothing because you allready know how it works out.
Since there is no other way to try interactive things like games, i think that you should prototype everything.
Imagine you work on a game you havent protyped for 6 months, and then you say "this game sucks! ooh the months i have wasted on this game that will never sale!!", so, if you had spend 2 months making a prototype of that game, you would save much money and time, you could even correct game play problems to make it work in the end.

[jetro]

I think doing small protos is both fun and they may uncover nice upsides which anybody wouldn't have thought about. Or you may figure out way of doing something like you thought out isn't good. Teq, if you did two protos for some project and it's not in production, that may still count as time savings, at least if those protos proved that the concept doesn't work that well after all (versus putting the thing in actual production and notice only halfway the project that it wasn't a good idea).

Speaking of prototypes - is there any cool tools / techniques you people have found useful at prototyping code or games?

Here's my two tips about prototyping dev tools:

* EVALDRAW (http://advsys.net/ken/download.htm) by Ken Silverman. I have used this to prototype small algorithms, although the thing itself is limited enough so you'll start hitting a wall quite soon if you try to expand. It has this funky feature of being able to constantly compile/evaluate your code as you type it in, so you can get immediate results.
* Processing (http://www.processing.org/). I recently made a small gameplay proto with this, in just a few hours, to check out if certain game idea's controls would seem to be fun. I think it was a successful test. The Processing is in fact just Java put in dedicated IDE with certain kind of default (optional) code framework and a simple & straightforward API of doing things (drawing etc). "It's as easy as you'd be programming in BASIC again, but not with the ugly syntax..."

[PoV]

Prototyping to me has basically been use/learn something you can get an app up and running with in minutes. In the past that's been Allegro for me. Using it's simple geometric shapes to represent entities. Circles, rectangles, lines, and such. Especially that circle. ;)

[Coyote]

I am a fan of the "Evolutionary Prototype" development methodology - meaning I start with a prototype and rather than throwing it away to create the "real" game, I keep "growing" the prototype until it becomes the final release. It allows you to iteratively refine the game as you go, and to find out what doesn't work BEFORE you devote 2 months to that feature. It also can give you a heads-up on what DOES work, and what should be accentuated and improved upon in your initial design.

Little-known-fact (well, at least it was a surprise to ME): Diablo started life as a prototype with turn-based combat.

Recently (this last weekend, in fact) I started a throw-away prototype for a game concept that was just so... um, let's call it "innovative" shall we (instead of just "Freaking weird")... that I really don't know how to represent it. Having something on screen to play with - IF I could sketch it out quickly into a prototype - seemed like the right step in "incubating" the idea and seeing if it works.

[Desktop Gaming]

Agree with what Coyote said - all my games start off as prototypes. There's no point re-writing something that already works.

[Ryan Clark]

We make prototypes for our games, too, but we scrap them and start again when it's time for the "real" thing.

Aren't your prototypes really poorly/hackishly coded? I just code them as fast as possible, and I end up with unmaintainable code. Sure, some portions are reusable, but the majority of it is a mess.

[JoKa]

I agree with Coyote and Gfk :)

It doesn't take much longer to produce clean code that can grow if the prototype has potential. I would really hate to re-code stuff I already created. Often, even major modifications are done quickly, when the code is clean and well documented.

[delsydsoftware]

With our latest game, we've split the game into 2 parts:

1. A text-based prototype, for testing ai(it's a turn-based game, so it doesn't need anything fancy)
2. The 3d code for menus, game graphics, etc.

From this point on, we'll always prototype our games. It only took about 2 weeks to get the prototype up and running, and now we can focus on getting the game engine polished up and working around the prototype code. This is working out much better than Brickout did, which was a mix of back-burner coding projects thrown into a blender on puree. There were so many unplanned "features" in that game that it was a nightmare to work on at points. The development process is much more fun this time around, and it feel like we're getting much more accomplished in a shorter amount of time. So, i'm all for the prototyping process.

[kay.altos]

We are always doing that. Just simpliest version of gameplay before gone to hard development. 75% of greate ideas dies after that as weak ideas.

[Teq]

We make prototypes for our games, too, but we scrap them and start again when it's time for the "real" thing.

Aren't your prototypes really poorly/hackishly coded? I just code them as fast as possible, and I end up with unmaintainable code. Sure, some portions are reusable, but the majority of it is a mess.

Same here Ryan, wouldn't use my prototypes as a basis for a final product, completely hacked (tho sometimes a bug creeps in that makes the concept more enjoyable, have to debug it just so you can replicate it! ;))

[Coyote]

That's the difference between the "Throwaway Prototyping" development methodology, and the "Evolutionary Prototyping" model. BOTH WORK.

Borrowing from the book Rapid Development, By Steve McConnell (which ought to be required reading for ANYONE involved in software development):

Evolutionary Protoyping:
Efficiacy:
Potential reduction from nominal schedule: Excellent
Improvement in progress visibility: Excellent
Effect on schedule risk: Increased Risk
Chance of first-time success: Very Good
Chance of long-term success: Excellent

Major Risks:
Unrealistic schedule and budget expectations
Inefficient use of prototyping time
Unrealistic performance expectations
Poor design
Poor maintainability


Throwaway Prototyping:
Efficiacy:
Potential reduction from nominal schedule: Fair
Improvement in progress visibility: None
Effect on schedule risk: Decreased Risk
Chance of first-time success: Excellent
Chance of long-term success: Excellent

Major Risks:
Keeping a throwaway prototype
Inefficient use of prototyping time
Unrealistic schedule and budget expectations


Both techniques work, and can work very well. For more information on what all that means, check out Rapid Development.
I did some time as an "XP" developer (eXtreme Programming). That kinda followed the Evolutionary Prototyping model, with the concept of re-factoring built in.

The biggest problem I face is a hesitancy to rip-out (or "refactor") "insufficient but functional" prototype code and replace it with better code. This is mainly because it feels like you are losing progress.

[Teq]

We run an XP development team at work and I really should carry home test based development, but I'm very visually focused, I like to see what I'm getting into, which lends itself to procedural code more than OO (but don't worry, I'm kicking that habit :P)

[Coyote]

I have used test-based development for certain parts of game development, but I've not applied it across the board. It came in EXTREMELY handy when I was working on some really hairy visual-geometry-based collision detection and optimization I was using in Void War.

So it CAN be used in games.

[PrefixEx]

We run an XP development team at work and I really should carry home test based development, but I'm very visually focused, I like to see what I'm getting into, which lends itself to procedural code more than OO (but don't worry, I'm kicking that habit :P)


I think sometimes too much is made of OO, if the complexity is low, procedural code is quicker to write and prototype.

[Fabio]

I think sometimes too much is made of OO, if the complexity is low, procedural code is quicker to write and prototype.
Indeed, but some may say "that happens because procedural code is a subset of OOP". :D

[dmikesell]

Indeed, but some may say "that happens because procedural code is a subset of OOP". :D

But others would reply "No, they're orthogonal concepts".

[jankoM]

hey jetro, thanks for that processing link. It is nice minimal and quick. I just made a small prototype of idea I had too (and discovered its crap... or at least needs much work :) )

thanks,
Janko M.

[dislekcia]

I prototype all the time, although that's probably a big reason I don't have many finished games...

Recently one of my prototypes caught the eye of a friend of mine at a game development company. Long story short, the company director took a dolled up version of my prototype to a couple of meetings at E3, now a publisher wants a DS-oriented design document for it.

This leaves me in a bit of pickle, seeing as it was just a prototype of an idea to see if it was fun and not a project I started with a solid design. Still, it's a nice problem to have :)

I find that after a bit of practise with Game Maker, I can turn out functional gameplay prototypes in an evening's worth of work. It's a pretty sweet rapid 2D development tool.

[vjvj]

I prototype and grow into the final version.

Generally speaking though, I'm a good boy and will rewrite chunks of code that were hastily/poorly written.

[Sharpfish]

Someone mentioned the DS just above, and if you have the facilities (either an official dev kit or "homebrew" capabilties) the DS is actually a cool little platform for knocking out simpler gameplay prototypes. Take 'em with you and try them out for a while, pass it around friends etc. I have a couple of 2D ideas up and running on the ds now and I find myself thinking more about the gameplay rather than technical issues as I do when I dive straight in to PC stuff.

Of course it's hardly a widespread solution or ideal for most people but it's an option that keeps the ongoing proto-scrap-proto routine a bit fresher (especially as it abstracts the gameplay from the actual PC C++ code and the constraints allow a clarity of design).