Prototypes
1. What are the minimum requirements for a prototype?
Most new and aspiring game developers' concept of the prototype is too much. Get your cubes shooting cubes and cubes dying first. Better to finish a game about cube on cube violence, than not finish a game about Spec Ops robots shooting zombies.
The prototype is the minimum viable product (MVP) for your game idea. Your prototype should display the core gameplay mechanics that make your game special. It should not inlcude lots of options. Whatever the player is going to do, they should be able to do that activity, but generally with only 1 option. If your game is about buying things, there should be 1 thing to buy. If you are shooting things, there is 1 weapon and 1 enemy. If the characters are class-based, then there is 1 class. Think of the prototype as a technology demo.
For example, imagine a convenience store. The prototype would allow players to enter and exit the store, move around the aisles, pick up 1 item from the shelf, put the item back on the shelf, see the item in their inventory, see whether the item is owned or not, and pay for the item at the register. This demonstrates all the actions the player can take in the store.
When working with your prototype, a general guideline to keep in mind, is that if your basic concept is giving you trouble, start simplifying the concept until you get it to where you can do it. Then finish it. Then build another, adding in 1 thing you removed from your original idea. Finish it. Repeat.
The specific requirements for a prototype depend entirely on the game, however the following is a good general guideline, and one that I tend to follow as my basic "starting point" for any prototype.
- Title screen with play and quit button
- Game screen with player and enemies that spawn whenever there is less than 2 on screen
- Player can shoot bullets that self-destroy when the leave the screen
- Enemies move around and try to touch the player
- Bullets hit enemies and do n damage
- Enemies die after receiving k cumulative damage
- Player character dies after receiving m cumulative damage
- Player has p "lives"
- Game over screen shows after player loses p times
- Add enemy-kill counter for score
I also want to mention that prototypes can be built for other reasons as well. The above response is focussed around prototypes as pertain specifically to the aspiring game developer. However, sometimes prototypes are built to test / demonstrate lighting and illumination models, or physics engines, or rendering engines, or even just for models and textures.
Now that you have something that is up and running and has all the basics on that first list, it seems relevant to mention the MUST / SHOULD / COULD framework.
When you decide to add stuff (such as preventing the player character from falling off the edge of a platform), you should track all those items in a list. Then periodically review the list and assign each on a classification like MUST, SHOULD, COULD.
Generally you want to address all your MUST issues first. Then your SHOULD issues, and then, if there's time, you start on your COULD issues.
MUST items are things your game needs to be complete. "Not falling off the board" is a must. "Player dies when shot," and "game ends when player dies 3 times" are MUSTs.
SHOULD is stuff that a "good" game would have, like input sanitization. These items improve how the game works, but don't necessarily add anything new. They add error-checking, address edge-cases and boundary conditions, and generally improve the robustness of the game, as well as resilliance to malicious player input (players will try to break the game).
COULD is all the stuff you want to add because you think it'd be cool, but aren't critical to the game. Additional character classes, ships or weapons, or particle effects are this type of item.
3. What is this the level of detail I put into every prototype? Once I'm done a prototype is it okay to work on other stuff or should I just stay on a product until release?
A prototype is just that: a prototype. Technically, it doesn't go to release. When you stop working on it depends on what you want to use it for.
Was it educational, to learn some things and lay the ground work for your next game or prototype? Then stop when you finish all the tasks you said you were going to do on it, or you learn all the things you wanted to learn from it.
Is this something you want to put on your resume? Then stop when you think it's a good representation of your current skill level and you think it is good enough to impress a recruiter.
Is this something you want to put on a game site somewhere? Then stop when you have everything you think it needs to make it a "complete" game, as well as all the things it must have to prevent player abuse / exploits and every bug you know of has been fixed (all the MUSTS and most of the SHOULDS).
Ultimately its your work. You can stop working on it whenever you like. Just be clear with yourself about what you are doing. If you just want to try a game mechanic, or figure out how to use a part of Unity, then its not really a "prototype" and you don't need that level of detail. Beyond that, it is up to you and it all comes down to making sure it meets your requirements -- whatever they are.