next »

[jechadwell99]

I'm working on a game at the moment which I expect will probably take a lot of time to finish (a lot depends on how fast I work as well).

However, I here a lot about prototyping games and how good that can be for generating great mechanics and fantastic ideas. The Ludum Dare and the Global Game Jam and other such projects are proof of this.

My question is this: Is it better to focus on one large project or to prototype several ideas quickly? Or a mixture of both?

Thanks.

[OccamsRazor]

A combination of both, really.

Prototypes are essential for testing the viability of your games. Whether your planned mechanics/style are actually going to be be fun, and whether anything needs changing. When you have a large project, prototype the smallest possible subset of that larger idea, and play it. Then have someone else play it and get feedback. It's going to give you a lot of insight into what parts of your ideas need to be refined, before you get too far into it.

You can even prototype several ideas in a short time, and decide which one you want to carry into a larger project.

But also be wary of prototyping new games while you're already engaged in a larger project. It can be extremely tempting to jump ship and start something 'new' and 'fun'.

I'd say don't be afraid to push forward with larger products, but prototype them first, always.

[s0]

if you're not very experienced, work on small projects and scale up later.

[Muz]

Have a vision. Identify risks. This is basically the innovative stuff - special combat system, NPC interaction, whatever you're not cloning from something that's tried and tested.

Prototype your risks. Play it until it's hella fun.

Make it beautiful but drop ALL optional features. Launch it, act like it's a proper launch, not a prototype or beta or pre alpha. Get it up to 100 players and make sure you get tons of complaints. Lock yourself up and cry.

Look again at how they're playing it (plug analytics if you can like Rimworld). Build your features around that. Your original vision WILL change somehow unless it's a clone of some genre.

[Kyle Preston]

if you're not very experienced, work on small projects and scale up later

This is good advice; it's very tempting to bite off more than one can chew.

[Ammypendent]

Prototype teaches you a lot where a large project wouldn't be able to in the same amount of time.

The best benefit of a prototype is that you can test it quickly and get useful feedback.

However it doesn't mean you shouldn't pursue larger projects. In fact you can prototype and focus on various parts of the game (ie: unique mechanics, controls & camera, etc) before trying to build other parts. Many large games have found success doing it this way, such as Mario 64's camera system.

[Aloys]

It also depends on your level of experience and how many games you've already completed. It's easier to commit to a 1 year project if you know what you are doing and how long it will take you. I am tempted to say that if you are asking, chances are you are better off doing prototypes.

Prototypes allow you to experiment and still tackle all aspects of game development. The most important part being that, beyond simply experimenting, you end with a complete thing that you can be proud of and show to other people to get valid feedback.

[KellyRay]

I tried big and burnt out as soon as I hit the first problem I couldn't solve. I'm still working on small. It's been a good good choice.

Big games are marathons from what I understand, and you don't complete a marathon by trying to sprint to the end. Gotta build that endurance with smaller runs first.

[TheChaoticGood]

Go small, then you can go big.

[Zamaroht]

Big games are marathons from what I understand, and you don't complete a marathon by trying to sprint to the end. Gotta build that endurance with smaller runs first.

Best analogy ever.

[guille]

is this a hobby or a business? Big projects are risky. A good prototype will let you know if there's interest from the market, if there is, you continue developing it, else, you ditch it. No point in working for a year in a game that nobody will play. It's better to find soon enough if this is something somebody would buy.

If this is just a hobby, then do whatever you feel like doing. Some people enjoy starting new things, so small projects are better, others like sticking to something for a while to try to expand and improve it.

[DanglinBob]

Well, ignoring the question on hobby vs. job, I still have to go with smaller first. I just think its better regardless of what you're trying to do to get a feel for what you want to make before you embark on a long and difficult task that was doomed from the start

[Carpetwurm]

Right now I'm building a prototype before actually getting to work on the main game. What I'm thinking will probably happen though is that the prototype will end up turning into the main game. 

[oahda]

Isn't that the point of the prototype tho?

[Carpetwurm]

Isn't that the point of the prototype tho?

I believe that prototypes are meant to be tiny projects testing the main mechanic of your game. I don't really think they should "evolve" into the actual game, though... If that makes any sense 

[oahda]

I mean, if the prototype is to test the basic concept of a full game (you did mention a "main game"), and if the prototype with its concept works, then... you proceed to make it that full game indeed?

Unless of course you want to play with more prototypes of other concepts first.

[jgrams]

I don't know about in game dev (where stuff is often implemented quickly and poorly anyway), but in normal software development (where you might be maintaining and supporting the software for a long period of time) there's a long tradition of thinking that prototypes should be strictly throwaway code, from Brooks's The Mythical Man-Month to Hunt and Thomas's The Pragmatic Programmer and so on.

You prototype to explore one very limited thing as quickly as possible to get feedback on how it actually works. Prototypes are supposed to be small enough that it's no big deal to start over once you have learned what you were trying to learn. The assumption is that the code is not designed well enough that it's something that you want to build on, so it's cheaper to start over with something well-designed rather than re-factoring your prototype into something usable as the base of a bigger project.

So in many circles, if you're building something that is worth turning into a full piece of software, what you have is not (technically) a prototype at all.

YMMV, of course.

[SeanNoonan]

I'll warn you about one thing - scaling a jam game/prototype up to a full release can be extremely messy. In a jam when time is a constraint, you won't be thinking about how to make something clean, tidy and future proof, just simply something that works.

If you want to continue a jam game to a full release, I'd suggest starting a new project file and use the jam as reference.

Take it from someone who spent a week on a jam game and then a year releasing it (it was an autorunner...).

[Sgt. Pepper]

I usually do small prototypes to test new features (scrolling, etc.) then I build a separate, bigger project around that small prototype.