Archives For Prototyping

GBJAM Post-Mortem: Void-Dogs

October 17, 2016 — Leave a comment

void-dogs-ss

Last week I took part in the fifth GBJAM. A popular game jam that pays homage to Game Boy games but allows for modern sensibilities to creep in. Initially I had no plans to take part but a developer on the newly formed Icelandic Gaming Industry Slack mentioned it. Soon I and a handful of others decided to join in. The basic format gives you ten days to make a game. There are two significant constraints, a four color palette and a ‘pixel resolution’ restriction of 160×144. After the ten days are up competitors then rate one another’s games.

In the end I spent around 16 hours making Void-Dogs and finished in 82nd place out of 402 entries which I’m pretty pleased with!

Motivation

I’ve been working pretty much continuously for 12 years making games and playful things. My emotional makeup is such that I really invest in the thing I’m making at any one time so I find it hard to juggle multiple creative projects at once. I don’t have the headspace for it. As such I’ve found it hard to work on sideprojects. I’ve made things during both my recent paternity leaves as good contiguous blocks of “free” time. Development time was “luckily provided” thanks to Autodesk laying a bunch of us off in August. Since then I’ve been working for two hours a day on a small game called What Now Earthman?. But that is still a big project I won’t complete for the foreseeable future. So I was already motivated to make something smaller in scope. The GBJAM popped up as a good enough answer.

Development

Void-Dogs took sixteen hours in total to finish. I started a day late but I don’t think that made any real difference. I started off working two hours per day but eventually did a little more from Wednesday onwards. In general it was quite a relaxed affair tucked around child care. Void-Dogs was made in Unity which is probably my favourite engine for making a myriad of games and prototypes quickly. I task tracked with lists on graph paper. I wrote all the code and made all the art and SFX by myself but found some Creative Commons music to use as a soundtrack. My main source of inspiration was the game Space Harrier but I wanted something that involved a little less spraying bullets directly forward. After a bit of brainstorming I came up with the concept of “skydiving in space” and went off to work! You can download and play the result here.

The most interesting technical challenge was creating the sense of depth and motion with a limited resolution. In the end I actually opted to use a perspective camera and Unity’s particle system to create some ‘dust’ that gives the impression of hurtling through space. Another important addition was the use of a ‘sine wave’ shake script I wrote some time ago. I initially intended it for cameras but it works just as well applied to other objects and captures that never still motion of a skydiver falling at terminal velocity, not realistic but it feels good.

spaaaaace

All the asteroids and players are positioned in 3D space with one unit equal to one pixel. This let me simply calculate the depth into the camera where I would get pixel perfect rendering. I initially tried rendering the sprites moving through space directly but the resolution makes for ugly pixel artifacts as sprite pixels pop in and out across real pixel boundaries. This wasn’t an unexpected problem, it’s part of the reason you see games like Space Harrier do 3D by changing sprite sizes (also hardware optimised sprite rendering). Moving to this approach required a bunch of labor to make art assets but is much better visually and thematically. In the end all the sprites sit on the ‘focal plane’ and are represented by colliders and transforms moving through 3D space. I then switch sprite depending on depth and reposition the sprite correctly on the focal plane to simulate the perspective of the camera. Everything is then snapped to the nearest pixel to allow for fluid motion without pixel artifacts.

behindthescenes

Unlike the above image the colliders actually ended up being boxes and pushed back behind the sprite. It seems obvious in hindsight but it felt all sorts of wrong with the collision as it was above. The inner collider is for the asteroid itself and the outer collider is the zone for the proximity bonus.

spaaaaaced-day2

What went well?

Art

My art drew a lot of positive comment and was a reasonably highly scored feature of the game placing 54th in that category. As someone who only started making game art again when I went on paternity leave this felt pretty good. Even more so as I hadn’t made any pixel art or pixel art animations for games before. A lot of this I credit to time spent sitting down cranking out bad vector art for What Now Earthman? it’s getting better but I learnt a lot in the three months I’ve been drawing semi-regularly. I’ve got a much stronger understanding of color theory, shading and other basics than I ever did before. On top of which I learnt that good art takes time (duh!) and not to try to rush through making something. Even a game as simple as Void-Dogs contains a surprising amount of art and it took perhaps half my development time to make it all. Including remaking art for the Itch.io page.

Gameplay

I ended up with my highest placement ranked 48th for the gameplay. I’m pretty pleased with the gameplay mechanics I added and how they work together. There are three essential layers. First the asteroids arriving in patterns forcing the player to dodge through waves of obstacles. Second the player scores more points for flying in proximity to the asteroids adding a risk-reward mechanic for people that find the dodging gameplay simple adding a layer of mastery. Third other divers will arrive next to you and fight for a short amount of time, the only means of killing them is to hit them with a laser bolt that stuns them and have the splat into an asteroid. This sets up a complex timing problem for the player to solve whilst dodging asteroids and incoming laser fire. These were strong fundamentals to build a fun game on and the feedback I’ve received seems to agree.

spaaaaace-day4

The AI itself is a simple steering behavior that has a target, avoids the player and asteroids then occasionally fires towards the player. It’s surprisingly good at hitting you!

Scope

I carefully managed my scope throughout the project. Mostly in the classic manner of frontloading the risky items I hadn’t done before. I also kept a Kanbanish working list also meant I could rearrange and remove tasks easily as I went along. I pretty comfortably worked through to the weekend when the days are taken up by looking after a boisterous three year old and two month old! Then I managed to snatch enough time to pull things together and enter my submission with quite a bit of time to spare even if it wasn’t time I couldn’t use on my entry!

Architecture

Architecture in a jam game? I saved a whole heap of time by doing simple things like separating the component implementing the actions of the diver from the component that controls how those actions are used. Both the player and the AI use the same actions. Similarly the components for sprite scaling and screen positioning were written to be easily shared and meant it was trivial to add in scaling for the enemy entering the game. I have a simple Events system I wrote for WNE that drives a lot of the UI update and game flow between objects that should be decoupled as much as possible. All my bullets and asteroids live in object pools local to where they are used and are drawn from them as needed. Finally the stage design is done within a coroutine and a library of helper functions so it looks a little like this:

Bullseye();
Grid();
yield return new WaitForSeconds(2.0f);
Cross();
yield return new WaitForSeconds(2.0f);
Bullseye();
XThru();
yield return new WaitForSeconds(2.0f);
Grid();
yield return new WaitForSeconds(4.0f);

//fight
AIEnter();
yield return new WaitForSeconds(2.0f);
BigSpiral();
yield return new WaitForSeconds(16.0f);

I’d attribute finishing this game at all to keeping on top of the code design as I went. Then hacking madly at the end! But keeping things neat made the hacks easier to implement.

What went badly?

Audio

I’ve done precious little audio work and it really shows in Void-Dogs. My two lowest ratings were for Sound (#100) and Gameboy Feel (#177). My music selection was a big contributor to the latter, it was the best Creative Commons licensed track I could find which didn’t really suit the Game Boy era and slightly bends the rules on Audio as it wasn’t an asset made for the jam. SFX were made using BFXR and whilst I think they are serviceable as placeholders they don’t really hold together or excite. I think rather than taking on yet another task were I to do this again I’d try to pair up with someone that knows what they are doing. Although I’m trying to get a basic handle on how to make better SFX and where to even start with music just to understand the processes.

Stage Design

I was pretty sure at the start of the jam that I wanted to have hand crafted stages rather than trying to create a procedural generation algorithm in such a short space of time. In the end I only had time to make one stage and iterate on it a little bit after some playtest feedback. Finding fun sequences and building them out whilst also trying to deal with the problems with perspective and the screen getting messy was really challenging! To be frank the result is a mish-mash of ideas in a steady progression punctuated with ‘clone’ fights. One of my biggest missed opportunities was not front loading a clone fight. I think many people probably played the game without reaching the first one! My goal was to have a series of escalating stages that lead the player in but this wasn’t really realised.

Scope

Could I have done better in the time I had? Perhaps? I look back through my notes trying to find places I wasted time and it’s really hard to say. I think I could have picked either the obstacle dodging or the clone fighting as the focus and doing both was perhaps unnecessary for a jam. Though I do think they compliment one another and was keen to push outside of the shooter norms. Mostly I think I wish I had more free time to put into it or had planned on taking part and done some prep work.

The single biggest thing I didn’t budget time for was setting up the Itch.io page which took a lot longer than I thought. Presentation matters in terms of first impressions and to get eyes on your game. Annoyingly the Jam entry page misses most of the instructions and theming which was an issue as I’d included the instructions on the site proper. Hopefully most people clicked through to give it a read but players didn’t have too.

Lessons for future Jams?

This was fun and I’d like to do it again when I have some free time, in particular I think the constraints made for a really fun jam format. The biggest takeaway I have is to team up with other people to cover the bits I’m rubbish at. I’d also like to try my hand at just working on the art and design whilst leaving the lion’s share of the programming to someone else. I like the art process, it’s not what I do in my day job and jams feel like a good venue to practice. Then the usual things for game development in general were really validated for me; have a small scope, make something you know how to do, get the game up and running quickly, playtest and iterate.

In Game Design, Game Development, Game Jam, Prototyping , , , , ,
permalink

“The best thing we did was let people try out ideas, and when we saw [good ideas], grab onto them and hold onto them.”

Drew Murray, Game Director ‘Sunset Overdrive’

Posted on September 4, 2014 In Agile, Game Design, Game Development, Great Quotes, Prototyping
permalink Leave a comment

Art in Prototypes

July 14, 2014 — Leave a comment

There is a persistent myth circulating in the videogames development community that you don’t want good art in a prototype. To me this is like saying you don’t want spaces, punctuation and paragraphs in a draft piece of writing. It’s simply not true and removing good art from a prototype hurts a games readability as much as removing punctuation does with good writing. What a prototype actually needs is the minimum amount of art for the game to be visual and aurally readable, and aesthetically pleasing. If your prototype doesn’t have these qualities you are actively making it harder for anyone playing or watching your game to understand and appreciate the design underneath.

Your Art does not have to be Complex!

This persistent myth seems to spring from AAA development where content has become increasingly complex and laborious to create so “no art” is a hyperbolic description of how much simpler things need to be. Prototyping is supposed to be a quick process of getting a minimal version of the core game to a decent quality. In this situation simplicity is king. If we look towards Indie games there are plenty of art styles that are extremely simple yet easy to understand and aesthetically pleasing. Thomas Was Alone is a clear example of a very straightforward art style which is supremely readable but still aesthetically pleasing.

thomas_was_alone_1

Thomas Was Alone

 

Obviously Thomas Was Alone is a reasonably simple platformer but this is the final production quality art and it’s simpler than most prototypes! There is a lot you can learn from looking at games with minimalist art styles that translates into more complex styles, for example the way in which the characters are highlighted against the background to improve readability. This walk-through of an update to the Summoner’s Rift map in League of Legends demonstrates this really well.

More complex games are going to require more complex art to retain readability. One way to ensure readability is to make sure silhouettes are distinct. Low-poly, flat-shaded models create silhouettes as well as high-poly models with huge detail in their texture maps. Levels can be “grey-boxed” and minimally dressed to keep visual hints in place. In many ways we’re trying to boil down the art to the essentials required to explain and sell the game.

It also might be the case that you need nearer production quality assets (to give a good indication of final visual design) for example if you want to show the prototype off to investors or the general public. In this case it’s often worthwhile keeping simple assets for as long as possible so you can target the time-consuming art work to the parts of the game that will provide the most benefit.

Re-use Existing Assets

Re-use existing assets to get you going. For example Left 4 Dead was initially prototyped with the Counterstrike models and skins. I’m not certain exactly what they did but simple animations for attacks and zombie walk cycles are the sort of thing I would think about adding immediately. When I was prototyping new avatar gameplay for EVE Online we reused all sorts of assets from EVE and even some that had been created specifically for cinematic trailers. Similarly some of the assets used in the EVR prototype came from EVE.

There are also lots of digital asset stores that will sell ready made assets for games. Jump on them.

It’s important when buying or re-using assets to make sure that you’re keeping the visuals as coherent and readable as possible. Otherwise the assets are probably detracting rather than adding to the prototype.

Juice It

Art isn’t just assets, it’s the whole gamut of feedback and your prototype should feel as good to play as you hope the final version will. Simple programmatic techniques can breathe life into static assets. A bit of scaling and tweening can turn a sprite into a character.

But Keep Focus

Art in games needs to be complementary to the gameplay. The focus of a prototype is experimenting with and proving out the gameplay of what will hopefully become a full game. Art can make a game with mediocre mechanics into a good game but at this stage we want the art to play a support role in enabling the player to be able to understand and appreciate the game.

In Game Design, Game Development, Prototyping , , , , , , , , , , , , ,
permalink

A Simple Agile Game Design/Development Process

July 2, 2014 — 3 Comments

Usually when Agile is introduced to people it’s done so with Scrum which is seemingly filled with arcane terms and voodoo ritual. Very often the context behind those rituals and terms is lost and the general advice is to, “do it by the book,” until you understand, before you adapt it. There are a couple of problems with this. Firstly that the context Scrum was developed for might not fit the context you are making games in so rather than enabling you to move faster and make better games you are standing in a corner with your wizard hat on. Secondly Scrum as an introduction obscures some of the elegance behind the Agile Principles, concerned as it is with day-to-day process in service to that elegance.

So let’s cut back to the elegance. In yesterdays post I made a simple re-drafting of the Agile Manifesto to make sense of it for games design/development. Today I’m going to take those re-drafted principles and show how they fit into a simple Agile process.

First a diagram:

simple agile

That’s it. That’s the beating heart of Agile. So simple you can describe it in one sentence. Come up with an idea, make it and try it out to see what it’s like, then use your learning to refactor your idea and processes. So simple it gets repeatedly invented in an intuitive fashion. So simple I can retire this blog forever! Done!

Well not quite, we’ve only managed to deal with a few of the Agile Principles in this loop the rest involve what happens during each stage. Currently we’re hitting:

  • Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • A playable game is the primary measure of progress.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ideate

We want to keep our ideas lightweight. Over-complicating our ideas too early means wasting a bunch of time both coming up with them and also implementing them. We’ll be refining our ideas over the course of many iterations so starting with a ‘perfect design’ is not going to help particularly as we have not yet managed to evaluate how perfect the design really is! The watch phrase some canny individual coined was “Just Barely Good Enough”.

Ideally we’re keeping these principles in mind:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.

Create

Creation is in many ways the ‘easy bit’ where we turn the idea into something playable. The main point to be aware of is that almost every task is going to require some Just-In-Time design. Having whiteboards (or a pad if you’re by yourself) handy is incredibly useful to quickly solve design problems. If you’re creating a videogame then this is also the time to make sure you’re refactoring the code your are working on to keep it simple, elegant and easy to work with. There are lots of ways to make this less painful but that’s outside of the scope of this post.

The principles to keep in mind are the same:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.

Evaluate

Evaluation means putting real people in front of your game and have them play it. Ideally you want the audience you intend to release the game to playing it as early as possible (or a close facsimile). At the very least you want some people that aren’t you playing the game to give criticism and feedback. Other developers can be good as they can excuse some of the rough edges of a product in development as well as being able to understand the ruleset and provide critique of the design. If you’re in a company then you’re probably going to have a list of stakeholders responsible for your project who should be playing every iteration and providing feedback. Other excellent although more time consuming methods include using Usability testing methods. For example doing some User Testing, a technique where you watch a players game session and take notes on friction points in the experience.

Schemes like alpha and beta testing, attending games shows, plus funding methods like Early Access also provide a host of willing playtesters. A caveat here is that the quality of the game experience does matter when showing something externally to large groups of people in a manner where there are quality expectations. First impressions count, word of mouth is important and it can be hard to dig a games name out of the toilet if every comment on articles about your game references how rubbish an early version was.

The end result should be a collated list of feedback and some action points to take into the next Ideation phase.

The principles being hit here are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The remainder of the principles deal with things like team composition, team management and day-to-day practices that are effective rather than process. They should be kept in mind at all times.

So why is Scrum so complicated?

Well it turns out as you start to use the above process a whole bunch of questions will routinely come up that need to be answered. Some can be answered by reading the Agile principles but others need a bit of cogitating on the best way to handle them.

For example how long should it take to move through the whole loop? According to the Agile Principles:

Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.

So we want to move through the loop pretty quickly, what if our idea is complicated? Well we’re going to have to cut the idea up into chunks we can implement and we’re going to need to work out roughly what order to do them in. But that means we won’t have the “full game” playable for some time? Well we should build a prototype first so we can get early feedback on our complete game design or we won’t worry too much and let the final design fall out in the wash as we receive feedback. Scrum basically provides a ready made solution to a lot of common problems that come up when trying to implement this elegant feedback loop.

Whether you pick an off-the-shelf solution or grow your own from simple beginnings the important thing to remember is that the entire process fails if you don’t keep up the virtuous feedback loop for both the game being made and the processes you use to make it.

In Agile, Game Design, Game Development, Prototyping , , , , , , , , , , , ,
permalink

“The basic idea is to get the game up and running as soon as possible in its crudest possible form.” – Phil Robb, Turtle Rock Creative Director

The basic idea…

Posted on June 16, 2014 In Agile, Game Development, Great Quotes, Prototyping
permalink Leave a comment

Go Wide, But Love Constraints!

April 16, 2014 — Leave a comment

Concepting and prototyping allows developers to cheaply explore a design space in order to find the nuggets of gameplay that can be polished to a high sheen. The single biggest issues are the size of this design space and the efficiency with which you can explore it. Roughly speaking we want to explore as much of the design space as possible as quickly as possible. There are two good routes to this; defining good constraints and working in parallel.

Good Constraints

Limiting the size of the design space is something you want to do for a whole variety of reasons:

  • To match company vision and goals.
  • To tackle specific problems.
  • To meet the abilities of the staff you have.

The single most important reason for defining clear constraints is to aid creativity. It’s simply easier to think through choices when they are limited. Constraints don’t need to be externally imposed nor do they need to be shared between teams working on new concepts. They do however, need to be good constraints. So what is a good constraint at this stage in the production lifecycle? It’s a constraint that can act as a quick razor to dismiss ideas. For example:

  • Genre.
  • Functionality requirements.
  • Team size and experience.

Bad constraints are not invalid constraints but ones that are more complex questions where the answers are unclear this early in the project. A good example would be setting a deadline, for example this product must ship within 18 months. There is almost certainly a constraint on the amount of time a project can take to make it to market in a business but estimates of this at an early stage in a project are going to be completely wrong. People deal with unpredictable things that need to fit into a fixed timescale by being extremely conservative, which is probably not something you want at this stage in a project where there should be maximum creative scope.

Go Wide

It’s a truism that it’s quicker to explore a space by splitting up and taking different sections. Double Fine’s Amnesia Fortnight is a good example of how this might work in practice within a small/medium sized company. Likewise Vlambeer  demonstrate that even as a tiny studio by severely limiting the amount of time you spend on a prototype you can hit many different ideas including some that become successes. In an ideal reality concepts should be something that are being developed all the time. Who doesn’t have a book of design ideas juggling around in their head or transferred to paper? Creating a prototype is more time consuming but critically allows a better understanding of how well the proposed idea meets the constraints and how feasible it is for a given team to develop. The more prototypes you can create the better you have explored the space and the more likely you’ll have come across the true maxima in that space. For larger companies it makes sense to have many small teams prototyping at once and as one or more ideas become more concretely ‘the best’ begin to structure those teams around moving them into pre-production. Sadly what you’ll mostly see are a lot of companies that have one small team working on one particular idea without really bothering to more fully explore the design space. This usually results in companies paying lip service to the production lifecycle without really buying into it because there are no real alternatives to the one project in flight.

Ideally what a developer is looking for is for the lifecycle stages to act as a funnel. As the stages are progressed you gain more information about how well the idea meets the constraints and the teams ability to implement it. So as you move through the stages ideas are discarded as they are found wanting.

In Agile, Game Development, Prototyping , , ,
permalink

How to Choose a Medium for Prototyping

April 10, 2014 — Leave a comment

When you start to make a prototype one of the first decisions you have to make is which medium to use. This might seem like an easy decision to make, just pick your preference and roll with it but I think there are a few more subtleties to it born our from my experiences of the various mediums. I want a prototype to demonstrate that the game idea I’ve had is good, that I and my team are capable of building it and that there aren’t a bunch of crazy unknown issues lurking to catch us out down the line. It also shouldn’t take too long to build, otherwise we’re just making the game. Ideally I want the lowest cost solution that gets me sufficient information and that differs per project.

Digital

Digital prototypes are ideal for video games, right? After all we’re trying to make a digital game?

Well yes and no. Certainly making a real videogame as a prototype will get you the most accurate information about the game you intend to make. The largest issue for developing a digital prototype is cost. It’s by far the most expensive option. Firstly because it’s much more complicated to make a digital game. Secondly because the expectations in terms of acceptable production values are higher particularly if you want to test the prototype with real people.

As such we only really want to use digital prototyping when the other methods wouldn’t work. In reality this boils down to interactivity and how close the prototype will resemble the final game. The more realtime interaction the game or feature requires the more you would have to abstract that interaction for it to work as a paper or whiteboard prototype. That abstraction comes at the cost of real knowledge about the game since we’re no longer dealing with the game as it is going to be played.

Another danger with digital prototypes is disappearing down the rabbit hole and not limiting your development. It’s extremely tempting to keep working on an idea for a video game once it exists despite things not really working. “If only I had <feature d> then it’ll be good… *three months later*… if only I add <feature x> then it’ll be good.” To avoid this feature creep you need regular evaluation of the prototype with decision makers. You also need to accept failure. It’s a good thing to find out your idea is not viable quickly. This can be a problem with the other mediums as well but in my experience videogame developers understandably get caught up much more easily in their chosen medium.

For example a team of five of us worked for three months at CCP to make a multiplayer prototype of some potential avatar based gameplay for EVE Online. In essence you explored an extremely dangerous environment as a group in order to salvage ‘awesome stuff’. We could have prototyped this quite easily on paper as a boardgame in much less time but you would lose quite a lot of the feeling we were attempting to create in being confined and exposed to danger as a group. Plus we wouldn’t have come across some of the technical challenges we faced when implementing it. This all fed into the final proposals we made to the Executive Producer of EVE who canned our project because we didn’t have the man power to produce it. A good decision and a good result for the prototype.

Paper

Paper is awesome, nearly aprototypingnyone can make a game just using their imagination, paper, scissors and a pen.

Paper works best for prototyping game systems that work at a slightly slower rate than most twitch games. However there are often system in games that actually work in a way that’s easy to translate into the turn-based mechanics of card and board games. The problem then becomes abstracting the twitch elements from the game in such a way as you can be confident that you are modeling the rest of the game correctly. The more integral the twitch gameplay is to the game the less this is acceptable and the more attractive a digital prototype will look. Even if the game works at a pace that is amenable to turning into a board or card game you still might need to simplify it to be fun as a game in that format. People are less capable at complex maths than computers, even a slight increase in complexity of a game system makes turns drag, the game hard to understand and hard to pick up. This can be a good revelation though as very often in games we want people to be able to intuitively understand their systems and those with too many hidden variables become increasingly hard to fathom. Further simple systems that still produce the required ‘simulation’ or feature are much easier to maintain and balance.

The image on the right is an example of a card prototype I made for a revamp to the hacking mechanics in EVE Online. The system as it stood involved a skill check on a timer and after a designer defined amount of successes you had hacked the item in question. Very simple and worked well but it was also deathly boring. In revamping the game system I reimagined it as a simple ‘procedural death labyrinth’ and as the system was turn based it was very easy to represent as a card game.

Actually making and iterating on a series of prototypes was done over a couple of weeks and involved my entire team plus a couple of game designers from other teams. We also playtested the game with a variety of other people in our office not only to get feedback on the game system but to spread understanding of what we were going to build. Once we were pretty happy with the gameplay we had prototyped we quickly moved on into actually making the system. There was a really short timescale to make this game system and I credit the vast majority of the success of the game system with players to the time we spent prototyping right at the beginning. It gave us the confidence to power into implementation with a strong, shared vision that we knew would work despite the full digital version only really coming together in the last week or two.

Whiteboard

To me Whiteboards are the place to design and prototype details in a Just In Time fashion. They are great for quick, collaborative sessions where you are trying to build a shared picture of what the intimate details of the immediate work are. Most of the time I’ve used them as a way of explaining an idea through a series of pictures or a diagram that can be changed to show the state of the game you are currently talking about. This can be particularly useful to work through several different ideas quickly in order to pick the most viable for a first attempt at implementation. They are also really good for collaboratively designing UI.

However using a whiteboard is also the most approximate form of prototyping. Very often you’re not exploring the game system itself but how it appears and works from the point of view of the end user. They should be used liberally but in support of other forms of prototyping rather than instead of them.

In Game Development, Prototyping
permalink

Posted on March 9, 2014 In Game Development, Prototyping , , , ,
permalink Leave a comment

The Value of Prototyping

March 8, 2014 — Leave a comment

I was speaking about prototyping at a conference in Finland and got asked a question that left me fumbling for an answer.

“How much of my budget should I spend on prototyping?”

I’m insulated from budgets at work and don’t consider them at home. My pretty lame answer to being put-on-the-spot was that I didn’t really know and that I personally consider prototyping an incredibly important part of making anything so I would earmark a lot of budget towards it. It’s a pretty bad answer in hindsight because the most expensive parts of game development by far are content creation and marketing. Trying to place a dollar value on something like prototyping is hard as the value added is mostly a reduction in project risk. Asking “how much time and therefore money did we save by not doing something?” is equivalent to “how long is a piece of string?”

To me the value of prototyping is two-fold.

Value to the Individual

In games we’re seeking a to produce experiences that elicit emotions, the most common being enjoyment of something fun. There is no real way of knowing in advance if a game idea is fun or not or if its something you really want to make. Making videogames is an act of creation and it is a craft. Other acts of creation follow a similar pattern. Writers need to write a lot to get good at writing. Painters need to paint a lot to get good at painting. You need to knit a lot to get good at knitting. To get good at making videogames you need to make a lot of videogames. The more you explore and make things the better refined your process and skills become. You also gain a great deal of knowledge and experience which you can use as future shortcuts. Prototyping is essentially the act of making the core game experience or a feature as quickly as possible to see if it’s good or not. It follows that prototyping lots of small games, systems and other ideas is a great way to get better at making games.

Having a large portfolio of prototypes is also a great way of demonstrating a variety of skills to potential employers.

Value to the Business

As I said above the main business value of prototyping is a reduction in project risk. Early post-Waterfall methodologies noticed this for example Boehm’s Spiral Model. It’s should be pretty clear to most people that the first version of pretty much anything is terrible in at least one aspect. In the Spiral Model development doesn’t move through a series of stages ala Waterfall but in a series of iterations that result in a series of prototypes before the product is finally put into production. It recognizes that we can’t effectively reason about an idea without a concrete implementation. Project risk can be mitigated with prototyping in a few ways:

  • “Fail fast” – Today’s trendy business phrase. But as above there is real value in realizing early that you shouldn’t do something and not wasting resources chasing it in a heavyweight fashion until your realize it is unworkable or rubbish.
  • Improving communication – Ever sat in a meeting room to discuss a design document and found you spent the entire meeting squaring away different interpretations of the doc? Text is a horrible way to communicate ideas about a game which is a complex, interactive, aural and visual experience. You can see this in the drift as a younger generation rely on Let’s Play videos more than traditional journalism to make purchasing decisions. Simply watching someone play the game tells you more about it than the reviewers opinion of the experience put into print. The same is true for prototypes, they give a concrete entity for demonstration, reasoning and discussion.
  • Expose unknowns – Upfront design has long been fraught if you only have a muddy picture of your requirements. Nothing can get much muddier than games where the game at the end can often bear little resemblance to the initial idea. Prototyping at least gives you some insight into what the unknowns will be.
  • Avoiding “Sunk Cost” – Avoiding the sunk cost fallacy is at its heart not “throwing good money, after bad” or better still knowing when to kill a project despite having a large amount of money invested in it. Developing concrete prototypes makes evaluating the project much easier.

There is also less tangible value added by keeping prototyping in mind. Businesses are beginning to realize that like a server a person can’t run at a hundred percent capacity without loosing overall efficiency over time. Google made the practice famous but a whole variety of companies are letting employees take charge of a percentage of their work time. For example here at CCP on the EVE project we have twenty percent of our working time available for our own projects. It’s the lowest priority work and entirely optional but it’s there and people use it. Beyond providing a buffer for work tasks that take longer than expected it also makes sure teams aren’t burning themselves out. Encouraging prototyping in this time has a couple of benefits. Firstly the business can discover new business opportunities. For CCP that paid off in a big way with EVE: Valkyrie, even if the initial prototype hadn’t been greenlit into development the visibility raised must of been worth many times more in equivalent marketing spend than it cost the company. Granted the core team that made the initial prototype eventually put way more of their own hours into the project but it’s an interesting example of these things “going wild” and surprising the executive staff. Secondly it helps keep people motivated, no one enjoys drudge work but it often has to be done and spending a few hours each week on something you find exciting is good compensation.

Whilst I wouldn’t expect prototyping efforts to spin off new products regularly they do also give the business a bunch of products with some ground work already done they could evaluate and invest in when it comes time to do so. Hopefully this sort of culture will experience less downtime between projects and less project risk by having to start all the investigation of multiple ideas from scratch.

Finally the value added by each individual getting better at their craft is not only a tangible benefit to that individual but to the company as a whole.

How much of my budget should I spend on prototyping?

Let’s revisit the initial question. Prototyping is a tool to investigate and conquer the unknown so the budget requirement comes down to how well you really know what you want to make. I guess the answer I’m shooting for now is make it a significant part of your process, especially at project conception and during pre-production.

In Game Development, Prototyping , , , , , , , ,
permalink

A talk I gave at Unite Nordic in 2013.

Basically an exposition of my thoughts on prototyping, how to do it right and what value it provides to game developers.

Posted on February 21, 2014 In Game Development, Prototyping , , , , , , , ,
permalink 1 Comment