Now that you have a project, you can start putting together the assets that will create the game. In this book, we have worked through how we are going to build this game out so that way, we can section off each major chunk into chapters. Prototyping can happen in a multitude of ways. We can’t go over every way in which every studio will prototype as each business has its own manner of creation. We will talk about major progression patterns that are common within the industry as a whole. Breaking down the life cycle of any task that is built upon iteration, there needs to be a cycle to pull out the impurities. This is commonly regarded as analyze, design, implement, and test, and then iterate again until complete. The prototyping phase goes through all of these steps as well. Take a look at them all and work through each portion that makes sense to you or the group building your game.
Wireframing or paper creation
In this form of prototyping, the creator breaks the video game down into phases in a physical or digital system to go through each game loop or experience the player will feel throughout your game. Sometimes, this could be creating a paper board game to run through the rules. Sometimes, this may involve digitally drawing game wireframes through the user interface to intuition for the gameplay experience.
This name is what you think it means! A bunch of untextured shapes, generally gray boxes, that line out your environment to ensure that the storytelling of the environment through its silhouette can be defined. This version of prototyping is particularly useful if you need a very direct camera angle you need to display, and do not have assets to set up the environment. This can also be useful in the development of concept art as you can push the composition to the concept artists for quicker turnarounds.
Figure 2.5 a, b: Greyboxing examples in project
From Figure 2.5 above, you can see how a concept artist could take these and draw over them to get a rendered concept in order to provide more design ideas for the space, even if this means changing the environment, since this was a quick mock-up of the space to get things started.
These can provide enough detail to start working on a proof of concept, which we go over next.
Proof of Concept (PoC)
The naming is fairly accurate. This is where you are getting very specific about your testing. Maybe you need to tune a camera to get a very specific feel for the gameplay. This might take several iterations in itself and multiple people taking a crack at it if you have a team.
Figure 2.6 a, b: An example of iterating on a game asset
Figures 2.6 a and b above show the iteration of some architecture. We started with a simple archway that had a feeling of fantasy just to start. After we put it in the level, we had more time to think about the styling and add more appealing parts to the archway. This is a helpful concept to understand that your assets can be perfect in the beginning. To get to an MVP, you have to start somewhere and work toward greatness!
Minimum Viable Product (MVP)
This is as the name implies: a pared-down version of the game. In a platformer, there must be jumping. Perhaps you have swinging as your game demands that as a mechanic, this will not get cut no matter how much funding you have? You do not need polished art assets or even animations. The purpose of an MVP is to demonstrate the gameplay’s features are within an acceptable range to ensure that anything built on top has the foundation of the MVP’s mechanics working properly.
Sometimes you have a good idea of the art direction, the primary mechanics, and narrative, but need to gather some feedback or possibly funding. A vertical slice is when you take a very thin slice of the game and polish it to generate hype and a sense of the end product. Demos are a similar concept to a vertical slice. This is more complex than the MVP as there is a level of polish to the art, animations, mechanics, lighting, and so on that MVPs aren’t expected to have, which can take a significant amount of time as well as an understanding of the final product, which may not have been available when the MVP was made.
This style of prototyping is the best use case for our project needs within this book. We are developing a small portion of the game to get a strong understanding of what the entire game could be. This is our best option.
While making prototypes, your game may need to go through all of these to get to proper gameplay that feels good to play. You may also not need all of them. This varies greatly within each development group.