Prototyping Games: Approaches, Tools and Techniques

Like most game devs, I normally use my twitter (@emre_c_deniz) to share little prototypes and ideas I've had over the years, but a lot of things get lost in the timeline. Enter my new dev blog, where I’ll be curating these ideas in one place for easier access. This first blog-post is range of tips on how I approach prototyping games with limited resources. I’ll go through some general advice from my own experience, as well as providing links to extra reading and tools with tutorials.

This is a precursor to a talk I'll be giving at NZGDC titled 'Nurturing Chaos' that explores rapid prototyping and general concepts around how simple/complex game ideas can be explored with very little resources.

The original Earthlight, a game that Norman Wang, Liam McGuire and myself designed in 2015 as part of a technology demonstration in VR, was prototyped first as a Photoshop GIF - and this has been a guiding star in how I approach any type of prototyping work. It was a very complex technical challenge that did something never attempted before - you, player, had hands (using the Kinect) in a Virtual Reality environment with locomotion derived from your physical actions and detection of gestures in real-time. Basically you could move and grab in Virtual Reality, before we saw 6DoF controllers or Vives. But all of this was built on basic prototyping techniques, tools and pricinples. 

Before any code was committed to Earthlight, I mocked up the entire scene from spawn to despawn in Blender and Photoshop. 

Before any code was committed to Earthlight, I mocked up the entire scene from spawn to despawn in Blender and Photoshop. 

There have been a number of fantastic pieces published by my favorite game franchises, and indie projects, that have explored their approach to prototyping - and this ranges from complex to simple ideas that focus on finding that fabled 'the fun' that people keep talking about. Generally speaking it is an exercise in de-risking a project as often and quickly as possible, as well as continuing to apply systematic pressure on each stage of a game to test and compartmentilize the likelihood that your investment (be it time, money or opportunity) is returned in the form of value (you can define what your perception of value is). 

Some great readings on the topics, I highly recommend, are the 'How to Prototype a Game in Under 7 Days' by the team behind World of Goo, and also 'The Making of Overland' by Adam Saltsman. Also please read the Lesson in Prototyping by Amar Singh!

 
The original 2D prototype of Overland should serve as a great example to designers about using the time, tools and resources available to mock up the necessary elements of a game.

The original 2D prototype of Overland should serve as a great example to designers about using the time, tools and resources available to mock up the necessary elements of a game.

 
In 2015 (or 14?) we built a total mess of a project called Undercity: Discotech. I didn't know how to model, so we made everything in 3D as 2D sprites. 

In 2015 (or 14?) we built a total mess of a project called Undercity: Discotech. I didn't know how to model, so we made everything in 3D as 2D sprites. 

My experiences in prototypes have been generally in small and individual teams, especially working as the indie duo 'Chalk in Rain' with Gerard Delaney; we produced a bunch of games, from multi-month unreleased projects to making a game every week. These games ranged from one-player pong to literally starting a slow clap - and our greatest (worst) accomplishment, a game about cardboard box dueling. Some of these games had zero fanfare, and others actually had a bunch of Let's Plays or streams - but none of it really mattered, we were just out to build tiny things within huge time/resource constraints without crunch.

This was important for me professionally to build a lot of throw-away games and rapidly developed concepts so that I could let go of the idea that I had 'Golden Ticket' ideas, which is a concept that is becoming more toxic as the marketplace is becoming more saturated. It has become critically important to be able to build disposable things that demonstrate value through validation even as independent/micro-indie developers (because, at least to me, indie as a term has really evolved past 1-2 person studios). 

But in a commercial capacity, prototyping helped us ship a range of things; from the original Earthlight tech-demo to the 6-player location VR based Lunar Mission, which was built with a bigger team over 6 months on the back of a pitch that secured funding based on pre-visualization of gameplay. The project was secured over Blender and Photoshop prototypes that clearly demonstrated key concepts, hooks and core loops.

There are differences in how prototyping for the generation of interesting ideas works versus one that is aiming to provide a pre-pre-pre-vertical slice of a client brief to secure funding or resources. For this post, I'm going to focus on how I approach individual, personal, prototyping.

Earthlight: Lunar Mission was pitched as a project using Blender, but went on to become a spectacular depiction of astronautical missions in VR. 

Earthlight: Lunar Mission was pitched as a project using Blender, but went on to become a spectacular depiction of astronautical missions in VR. 

Let's talk some shop

It is very important that you recognize that most prototyping tips for independent developers should contextualize the development environment as well as the financial privileges - that piece linked above on Overland is a perfect example of how it is important to frame and discuss the background enabling prototyping to occur so that you're able to understand that your time, money and energy are important resources alongside your skills and intellect. 

Why?

Because it's not easy to prototype when you are working 60-hours a week in shift work at a cafe instead of being surrounded by professionals that can turn an impossible problem into a 3 minute explanation of which button to press - and more importantly, being paid to continually develop your skills that compliment prototyping. Not impossible, but it is a factor. Go at your own pace and remember that the point of this is to make it fast, cheap and without pressure. 

My home life is that I work non-regular hours (sometimes from home), with a range of experts at our studio, and have access to both Unity and Unreal programmers to help with troubleshooting (providing it is done after-hours, or as a quick discussion). This gives me-

  • Access to experts/community
  • Income stability
  • Safety net in failure

My background is defined as a 'very bad unicorn', as I can half do/attempt basic scripting, 3D art, 2D art, animation and technical art. Most of this is based on a background in business and project management, where I need to pitch ideas/projects at people with money to try and get them to give me said money. This requires autonomous development of concepts or ideas, turned visual/accessible, so that the aforementioned money is exchanged for services. I'll link my Paypal below so you can throw money at me for projects.

If I was to rank my personal skills from competent to non-existent, they would go like this:

  1. Art - Good in 2D, Beginner in 3D, Really Good with Textures/Materials
  2. Design - Good
  3. Animation - Meh
  4. Programming - I was once instructed by someone to never attempt programming again.

This means I can draw, model and animate my ideas. Sometimes, I can make them do things in-engine, and other times they are static images. I can dedicate about 10 hours a week to any prototyping I work on in my own time, but number will/can fluctuate. There are outliers of game developers, working alone, managing to pump out 12 hour days - it is critical that you understand their financial, professional and even emotional background before you apply them as case studies to your specific plans to turn an idea into a game. Try to align your situation to a case study of development that suits you, because it will define your tool-sets.

This is my tool-set. Define your own tool-set.

Sometimes we can communicate a lot of ideas in art, design and production from a single Photoshop mock-up. 

Sometimes we can communicate a lot of ideas in art, design and production from a single Photoshop mock-up. 

The next thing I tend to look at, and this will be heavily touched on at the NZGDC talk 'Nurturing Chaos', is the idea of identifying subversion within a theme, idea or general concept. Prototyping within constrained themes, time and ideas is a good thing - and working to undermine existing games with new ideas is a great way to get started. We're not looking to clone existing titles, but to grab the things that work and change elements of them without losing the original hook behind the success.

For example - Night Pong is a game about 1 player pong. MegaChess is a game where every chess piece is randomized per turn. Slow Clap is a rhythm game that is a game about a slow clap (c'mon). Boxsumo is a cardboard sumo-wrestling game. They're fast, cheap - but ultimately they have a one-sentence pitch that is interesting (to me). Their investment of a week by two people on casual hours reflect our casual attitude to them and thus we define these prototypes as great adventures into nurturing our craft.

 
Spokesworm, a game about lying a lying alien worm (read: politician - pɒlɪˈtɪʃ(ə)n/ noun)  was mocked up in just this panel. I see the similarities to a human anus and it was intentional.

Spokesworm, a game about lying a lying alien worm (read: politician - pɒlɪˈtɪʃ(ə)n/noun) was mocked up in just this panel. I see the similarities to a human anus and it was intentional.

 

But they always start either on paper, or as a rough-as-guts prototype in-engine. The distinction is within the tools that you can deploy to get that idea into something, following that you can essentially identify what is missing from your tools to take your prototype into a game.

So, as a programmer, you might be able to do some really simple gameplay prototype with placeholder art. As an artist, you might do a simple mock-up in Photoshop of gameplay elements, setting and art direction. As an animator, you can create a non-interactive (or interactive if you're brave) game demonstration - ideally, if it resonates with people, it may have legs to continue work. Try to capture as much information in a single piece, be it an animation loop or a piece of key-art, as possible. This is also good professional practice for autonomous designers and developers, as communication is key and it starts at the most basic 'show don't tell' principle.

I learned how to animate in Unity (as best as I could in a week) and sought to do some quick gameplay demos of prototypes.

I learned how to animate in Unity (as best as I could in a week) and sought to do some quick gameplay demos of prototypes.

There are avenues in testing these prototypes out - you can float them on social media and see how they ping, or to your friends and observe how it plays. There are more than a few examples of games that found legs/fame post-jam or prototype, turning into fantastic games in their own right. However, remember this rule: seeking validation and needing validation are separate concepts. If you think your idea is good, great, but your confidence needs to make way for the validation of others- do they think it's good? Are they having fun? Are they engaged with the idea? Are they excited by the concept?

Kill your darlings early if they're flat and always seek feedback on ideas/art/concepts to find reasons to kill them. Get to the point where you can cock that hammer back on your idea as fast as possible and have people talk you out of it.

>>Disclaimer: If you're building games for you, do you!

Mazegame was prototyped on the back of a lot of interest on Twitter about floating a 'Survival Game' in a maze. It didn't play that well, I learned a lot.

Mazegame was prototyped on the back of a lot of interest on Twitter about floating a 'Survival Game' in a maze. It didn't play that well, I learned a lot.

Be Your Game's Greatest Enemy

The formula I've tended to follow is one that's based on my personal experience and based on how Eartlight was made: Norman Wang was mid-eating a dumpling at lunch and asked "Hey should we make a VR game about being an astronaut" and I thought it was cool. It was new, quirky and kind of made sense. Single sentence that resonated with the team, then became a massive thing. It moved onto being in over 30 publications and the original screenshots/videos had over 300 000 views. It evolved and changed with the market a lot since then, but the final iteration 'Earthlight: Spacewalk' went on to win a number of awards - including the Australian Game Developer Awards 'Game of the Year' and international awards in Serious Games. It fought for validation, even against me, every step of the way. I once petitioned hard (not hard enough) to kill that game and ended up building a studio on the IP and since then has defined my career as a game developer.

You need to make your prototype fight for survival every step of the way, or build it so that you can bring it to fruition and fail as quickly as possible.

This formula for me is as follows:

  • Float the idea verbally/text wise, see if you can grab a niche that resonates with people.
  • Mock up the idea in several ways - see if people can understand the vision, or are attracted to the concept.
  • Break up the mechanics or design into small pieces - can you prototype on paper? Photoshop? Blender? Is it playing at all? Is there a tight loop you can iterate on?
  • Seek to address missing skills - can my tools compliment someone else's tool-set? Ideally, finding people that like the concept that can help is great. 
  • Tighten the vision - rapid means brutally small scope and passion is the enemy of scope. Keep to mechanics, key art and core loop.
  • Placeholder ugly stuff - I believe that finding the fastest placeholders, from purchasing assets to using ugly-purple sprites, helps focus on getting that game interactive fast.

Every single step above should be a point where you tranche your idea into either killing it, or continuing onto the next gate - the ideal goal is to have it in front of as many eyes as possible as you go along. Have people talk you out of killing your game each step of the way, because you will hopefully work towards being able to talk someone into buying or funding the game / or why they shouldn't kill it. 

There are a few good reasons for this that tie into forward thinking for business development of your indie title, but I'll be brief, as you'll need to show:

  • Traction: interest, views, audience, community
  • Press: publications, interviews, general buzz around your idea
  • Market: that you're tapping into a market opportunity that resonates with your users

Tools For Me and You

I've compiled some resources that I use for prototyping that can help you fairly well:

Blender: It's free but you need to really do some tutorials to get the UI under control, but past that you can rapidly mock up assets and scenes. Blender can be deployed fairly quickly to help you take an idea into an animated concept - and you should aim to do this when possible. It's not just for your audience but also yourself, as visualizing a concept might enable you to immediately identify deficiencies in not just the game idea itself but also how it might function in a 3D space.

 
If I said 'it is SimCity meets Tamagotchi' you wouldn't have a clue until you saw this Blender prototype built in a day to illustrate the idea. 

If I said 'it is SimCity meets Tamagotchi' you wouldn't have a clue until you saw this Blender prototype built in a day to illustrate the idea. 

 

 

MagicaVoxel: It's free, and has a low barrier of entry that can help you mock up general concepts rapidly and with a good visual fidelity. The program has a simple set of asset management tools that I absolutely recommend you get a grasp on, as Magica is most powerful when used as an asset library that helps you build scenes quickly within a unified palette. Take extra care to get acquinted with the camera/rendering settings, as well as using the PBR components of materials to your advantage - but remember that Magica scenes are static, so you'll need to work with an engine or 3D authoring package to animate it.

MagicaVoxel alone can help you rapidly build interesting scenes that can communicate past art direction and onto setting or even general gameplay genre. 

MagicaVoxel alone can help you rapidly build interesting scenes that can communicate past art direction and onto setting or even general gameplay genre. 

 

Unreal Engine 4: Free and the blueprint system is easy to get into - but even if you cannot, it still features a lot of visual tools to help you present an art prototype of a prototype. I tend to use Unreal Engine to do two simple things: play really simple game mechanics in a test level -and- turn concept art into animated scenes/sequences to help myself visualize the scene in 3D space. I have not personally enjoyed the 2D pipeline and generally defer to Unity for sprite based game ideas.

Unreal Engine can help you build dynamic moving scenes/art visuals rapidly (this took about 2 hours)

Unreal Engine can help you build dynamic moving scenes/art visuals rapidly (this took about 2 hours)

 

GIMP: It is free Photoshop and has a lot of the tools necessary to get you across the line with visual presentation. I use Creative Cloud, but GIMP is pretty solid. Photoshop/GIMP is a great starting place for turning any random idea into one that has some visual presentation. Try to recycle common layers and components, like noise or camera filters, and try to replicate what you know will work within an engine in the visual prototype. I highly recommend prototyping UI elements where possible.

Photoshop/GIMP can enable you to visually mock-up a range of ideas rapidly and even find interesting things. Use references, placeholders, inspiration - but get that idea down quick.

Photoshop/GIMP can enable you to visually mock-up a range of ideas rapidly and even find interesting things. Use references, placeholders, inspiration - but get that idea down quick.

 

Unity: Free for the basic version and I'm not great with scripting the component system, so I mainly use the animations and 2D features to build rapid prototypes. Unity is quite flexible and has a range of custom scripts, shaders or assets that are either paid or free. These are hugely beneficial in getting a concept to a stage where it captures both gameplay and visual presenation, but ideally you're looking to capture something that has an inherent hook/interest without a lot of visual flair first. Simple assets, grey-boxing and using light/shape/composition can stretch a long way when paired with a simple game animation.

Isometric ship bridge game built in a couple of hours that communicates a range of ideas, absolutely disgusting animation/material setup - but done quick!

Isometric ship bridge game built in a couple of hours that communicates a range of ideas, absolutely disgusting animation/material setup - but done quick!

Extra bonus resources and links:
Open Game Art - Assets for use with varying licenses so you can populate your scenes/concepts quickly. Looking at you programmers.
Super Dev Resources - Board with a ton of entries that curate everything from font to game audio for use in projects, again make sure to check licenses.
Free Game Arts - Assets ranging from 2D to 3D on a quirky website, generally on open use licenses.
SpriteLib - by Ari Feldman, 2D static and animated sprites for use in game projects.
Blender Repository - Collection of 3D models for Blender with varying quality/licenses. Community and user driven, so give back when you can!
Textures.com - Premium website with a ton of scans/materials/textures. I tend to use MegaScans or photographic scans/references where possible but libraries like these are super useful.
Carnegie Mellon University - Free for use Mocap data

Awesome tutorial repositories (that I use):
Blender Nation - Great tutorials and resources for getting around Blender.
Blender Guru - From beginner to intermediate, this is a perfect start point for understanding Blender.
Unreal Engine Tutorial Videos - UE4 official tutorials repository that is an essential starting point for you.

 

That's all for this post! I'll be keeping my prototypes and random work in this blog, so feel free to shoot me emails at emre_deniz@live.com.au for questions, or alternatively you can hit me up at my twitter - (@emre_c_deniz)