Apr 2, 2021
Prototyping without Assets
I think one of the main benefits to prototyping without assets is that it encourages you not to get bogged down with the audio and visual polish of your game, and instead encourages you to focus on what’s absolutely essential. In particular, it tends to place the emphasis on the core mechanics and interactions of your player:
- Is this game functional?
- Is this game’s core game loop enjoyable or achieving the desired effect/play experience?
- Is the layout of this level and my use of, say, powerups and enemies doing me favours or is it detracting from what I want the game to be about?
Fundamentally, is the game’s core experience strong enough that all it should really need is some refining and fleshing out in order to reach the desired end product and end experience for the user? Using placeholder assets, or event just using primitives (squares, cubes, cylinders, etc.) allow us to prototype often and rapidly.
This can save independent developers a lot of time, and on larger-scale teams they can also save money that could’ve been wasted if an art team developed a lot of good-looking assets for a game or level that ultimately needed to be abandoned or heavily revised.
Doing this tends to be critical in achieving an agile and more iterative development process. I’m also reminded of the distinction a teacher of mine brought my attention to — between ‘visual fidelity’ and ‘functional fidelity’ in prototypes:
- Visual fidelity. A prototype might have high visual fidelity if you spend a lot of time developing the aesthetics to it, but might have fairly low functional fidelity. It might not be interactive at this stage, and might be more of a tech demo of sorts to give a suggestion of what the end product might, literally, look like.
- Functional fidelity. A prototype might have incredibly high functional fidelity if you’ve programmed in the core mechanics and behaviors, but have low visual fidelity. It might look nothing like the end product, but it gives the user a strong idea of what the game will play like, what the interactions will be, and what it should ultimately be about.
Ultimately it’s generally going to be a lot more feasible and a lot less time consuming to aim at functional fidelity over visual fidelity, but I can appreciate that in some cases the visuals/aesthetics are really going to be what make the experience come alive. For instance, the mechanics and interactions of Gris might not win you over or even define the game, but its art direction most likely will. I do think it’s important to note possible exceptions like these, but at the same time when it comes to the work we primarily do as game developers and programmers our emphasis will most likely fall onto interactions, behaviours, and mechanics.
