What questions should I look to answer when prototyping a game? Game Design and Programming
You're browsing the GameFAQs Message Boards as a guest. Sign Up for free (or Log In if you already have an account) to be able to post messages, change how messages are displayed, and view media in posts.
I've done a bit of reading about making game prototypes, but where I get stuck is what questions I should be able to objectively answer after finishing a prototype. For example, I have a game mechanic I'd like to test out. How do I know when I'm done with the prototype? What questions should I be able to answer about the game mechanic?
The only things I can come up with are very subjective, like, "Is this fun?" and "Does the UI feel good?" which are not useful. I've also thought, "Will implementing a final version of this be practical given my resources?" which I think is on the right track but is still speculative and not a direct result of the prototype.
If you have any reading material to supplement your answer, please link! I'm always looking for more original material regarding prototyping. You can assume I've probably read any results that come up from googling "game prototyping", but it's possible I've missed something.
Well I don't think there's any fixed purpose to prototyping unless you're showing it to a company or something . The most important question is: do the game mechanics work? Is it fun to play? And also removing or modifying any that don't work. When you're satisfied you know what the game will be like then I think you've gotten enough value out of a prototype.
I live in a big house and it's handy to have a pair of running shoes so that it doesn't take me forever to get from one area of the house to another.
Define the purpose of the prototype before you define those questions. For some examples, you could be looking for making a fun game, or how to effectively teach the player how to play, or implementing a new mechanic, or testing an idea you had.
You're done with a prototype once it's purpose has been fulfilled, or when you're not foreseeably going to get enough out of it towards its purpose.
The most constructive feedback I've gotten from play testers (who aren't experienced gamedevs) has been when I've not asked them direct questions about the game. I find it's better to be indirect, so testers aren't confronted with needing to talk about something that isn't their expertise. Eg, ask them to try restart the current level, rather than asking if the UI and button mapping are good.
The most useful feedback has been when I've done the following:
1) take some notes about their personal preferences for games, so you can later filter what feedback they've given you based on your target player's preferences. (Eg, I've had an RTS player with little FPS experience fail hard at combat in my FPS Zelda-esque, but FPS players who enjoy Zelda-esques had no trouble)
2) set the tester's expectations succinctly, and defer their feedback until after they're done playing. This is needed so they know what to expect in the game, what they should be paying attention to for feedback, and what personal preferences they should set aside based on your target player's genre preferences. (eg, "This is a game about X where you Y. It's a prototype, so please ignore any white box graphics and bad UI styling - I'm more looking at iterating the design of the game's core mechanics, and the flow of gameplay. I'm looking to make a game that would appeal to people who like Z. Feel free to stop any time, since that'll let me know to make the game more fun. When you're done, if you like, can I ask you some questions about what you think the core mechanic is, and where you feel the game should go when developing the mechanic and upping the ante?")
3) step back, and unintrusively watch them play while taking notes, only prompting if they're stuck (ie the game breaks, or they don't see how to progress, or they specifically ask what to do)
4) ask for their honest thoughts afterwards, again taking notes, but being careful to set them aside from my observation notes. Ask what they liked least, liked most, and other personal preferences that will let you know what to throw out and what to keep. Again, filter this based on how closely they match your target player's preferences.
I hope this helps :)
|__ I make indie games! Get them for free at http://nesis.itch.io __| |__ Let me know what you think! __________________________|
Appreciate the responses. That does help. I guess maybe there isn't a super rigid approach to prototyping. I suppose for my game mechanic prototypes, my goal will be to define the mechanic as accurately as possible, and then create a narrow list of requirements the prototype must implement in order to get the "core" of the mechanic working. Then I should be able to stop and ask myself if the mechanic is a good idea.
I like to use a prototype just for discovering and learning what kind of challenges lie ahead. You might have an idea that sounds super neat. Once you make it real, you'll learn a lot about its limitations and so on. Oh and yeah, I definitely agree with the playtesting advice. You get amazing feedback that way, supposing you find enough people.
Everything has an end, except for the sausage. It has two.