Archives For prototyping

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.

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.

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.

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.