23
\$\begingroup\$

We, as in my 4 person indie group, have an entire whiteboard that looks like graffiti for prototyping our game ideas. We look at it every day and choose which idea draws us in the most when we near time to start a new project. We also randomly draw characters that seem interesting even if they have no gameplay associated with them. This works but doesn't always seem to give us the best understanding of our ideas. We tried a rule that if you come up with a game idea, build a very basic prototype and show us, but that also wastes time.

So, my question is "what is a good way to prototype game ideas". We need a balance between getting the idea across and not skipping it because we don't understand it, but also not wasting time building up a ton of ideas that will never be touched. What is an efficient way to describe the major aspects like gameplay, art feel, special features, audience, etc.

|improve this question
\$\endgroup\$

closed as primarily opinion-based by Alexandre Vaillancourt♦, Josh♦ Feb 22 '17 at 14:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

5
\$\begingroup\$

It sounds like you also need some pre-prototyping organization, too. Make a list of all your current ideas. To generate a rough ranking, each team member assigns each idea a score from 0 to 3 that indicates how badly they want to move the idea to the next stage. Everyone should try to have an even number of ideas at each ranking level (with 30 ideas, each person should have 6 or 7 0-ranked ideas, 6 or 7 1-ranked ideas, etc.). Next, for each idea add everyone's scores to get a total that will be from 0 to 12. With luck you will have from 1 to 3 top-scoring ideas to move forward with. After that, follow Tetrad's advice. Personally I love paper prototyping. With things on cards or slips of paper, it is incredibly easy to do things like reorganize a tech tree or explore variations on puzzles. I find a camera very handy for recording the good stuff you find as people are moving things around.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ +1 also, that's closer to a standardized prototyping plan. Talking to the guys, we may take aspects of what we do and mix in a scoring system like you suggest. also we may use storyboards as tetrad suggested. I'll see what they think today about these suggestions. great ideas \$\endgroup\$ – brandon May 6 '11 at 21:35
  • 3
    \$\begingroup\$ Personally I would suggest maybe going with a thumbs up/thumbs down voting pattern. It's less decision making for the team members ("is this a 2 or a 3"), and most voting is either "I like this idea" or "I don't like this idea" or "I'm ambivalent". Approval/disapproval captures that better, and if you need to pare it down, you can do another runoff vote with the top ideas. \$\endgroup\$ – Tetrad May 6 '11 at 22:23
  • \$\begingroup\$ Good idea tetrad \$\endgroup\$ – brandon May 6 '11 at 23:36
  • \$\begingroup\$ That's right, there's lots of ways to customize this step by adjusting the range of scores and number of rounds of assessment. \$\endgroup\$ – Jason Pineo May 7 '11 at 1:23
13
\$\begingroup\$

The only thing that's important is getting game playable as quickly as possible, and being able to iterate on the game as quickly as possible.

So with that in mind, there are a lot of things you can do.

1) Pen/paper play it. If it's a level, draw it out on the white board and storyboard the major beats. If it's an RPG style game you can pen and paper it DnD style. If you're trying to prototype an art style, paint it up. You don't have to get everything to 100% in some 3D engine just to test something.

2) Try out ideas in a rapid prototype environment. For example, using Unity. If you have to write code, you should be doing it with the highest level programming language you are comfortable with. There are related questions for this, like Recommended 2D Game Engine for prototyping and When creating quick prototypes, is it better to use the language you are going to use in the end?

3) If you must do it in your own engine, be sure to employ practices that allow you malleability of code and content. Make sure your tools are good so you can drop in content quickly. Try to write code in such a way that you can modify it easily. Employ a source control solution that allows really easy branching like git or mercurial so you can try things with impunity.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ +1 for the good answer. I did want to note that part of the problem is the amount of ideas we have. Probably pieces of about 30 ideas on our board. A big part is, we're trying to figure out how to standardize our prototyping process so we don't go and build a functional prototype for every idea. \$\endgroup\$ – brandon May 6 '11 at 19:28
  • 1
    \$\begingroup\$ Is the problem that you have too many or too few? Or is the problem that the ideas are going off in too many different directions? Part of the soft art of managing the project is figuring out how big your canvas is, and deciding to ignore things that aren't part of the core promise to the player you want to make. \$\endgroup\$ – Tetrad May 6 '11 at 20:13
  • \$\begingroup\$ Sorry I didn't clarify well. We do small casual games for iOS and shockwave. These games take about 2 or 3 months so we have a ton of new game ideas that we constantly have floating around. We pick the best one when we get ready to start a new one. We have too many ideas. We're trying to pick which ones are the best and which we should do functional prototypes. So we need a standard way to prototype so we explore the good ideas and find out which ones are bad as quick as we can. Our definition of prototype includes drawing a character with nothing else. Visual prototypes vs functional. \$\endgroup\$ – brandon May 6 '11 at 21:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.