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.
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!
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.
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.
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:
- Art - Good in 2D, Beginner in 3D, Really Good with Textures/Materials
- Design - Good
- Animation - Meh
- 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.
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.
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.
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!
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.
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.
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.
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.
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.
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 email@example.com for questions, or alternatively you can hit me up at my twitter - (@emre_c_deniz)