Archives For ccp

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.

It’s time to wrap up the CCP Game Jam posts with a round-up of the remaining games that were made during the jam.

First up is the eminently beardy Team Clean Shaven who made two games, or three if you count that one of them was split into two separate executables! The first game H.E.A.R.T. was a schmup made in Unity divided into a general vertical scrolling kill all the things game with the second portion being a specific example of a boss battle. The second game they made One Heart to Make was a pattern matching board-game where up to three players as the club, diamond and spade suits battled to reassemble the heart.

Team Heartless very nearly missed out on the Player’s Choice Award with their take on dating in Heartbreak Date. The game consisted of a few minigames all bonded together to make a terrible dating experience. Players get the opportunity to try to attract a waiters attention, try to stay awake whilst your date is talking and a brutally hard game where you have to say the things that your date is thinking about to feign interest. Their game was also very well put together and a special shout-out has to go to Scott Rhodes’ excellent audio including some inspired voice acting.

Last but not least is Team Pheasant Preserve who quite possibly made the first game ever in Confluence. Ultimate Wingman Simulator: Heartbreaker Edition – Tragic Confluence was a piece of well written and illustrated interactive fiction. The game was initially intended to be a point-and-click adventure but time pressure forced them into a different format.


Ultimate Wingman by Pheasant Preserve

Ultimate Wingman by Pheasant Preserve


Heartbreak Date by Team Heartless

Heartbreak Date by Team Heartless


H.E.A.R.T. by Team Clean Shaven

H.E.A.R.T. by Team Clean Shaven



After the teams had finished their 36 hour marathon development effort we had a Showcase event in the office canteen. The rest of the Reykjavik office was invited along to try out the games people had made whilst enjoying a few beers. During the Showcase we ran some voting with each person able to vote for one project to be the Player’s Choice. Team Yellow Brick were the winners with their take on the Land of Oz. You play the Tinman desperate to get a heart in order to win over Glinda and have her accompany you to the Valentine’s Day Ball. Each stage of the game sees the Tinman attempting to steal the heart of one of the other famous characters from the Wizard of Oz as part of a bloody rampage. Between each stage the story unfolds via some rather lyrical poetry. The game was built in HTML5 using the Phaser framework.

The title screen.

The title screen.


A little bit of poetry.

A little bit of poetry.


Fighting the Scarecrow to rip out his heart.

Fighting the Scarecrow to rip out his heart.


Tomorrow I’ll wrap up with a quick look at the rest of the games.



Our Game Jam ran over Valentines day which was a rather obvious cue to take for the theme. The theme we chose was One Heart to Break which I think is pretty nice because it immediately suggests a whole host of mechanics, flavors and narratives. Team Maggi were the stand out winners though for taking the theme completely literally. You have one heart to break… your own, and you do so by eating yourself to death. The game was a card game themed around a dubious fast-food place that sits next door to the CCP office. Your aim is to lose your starting life points before anyone else and you do so by eating meals and their toppings. At the same time you have other cards you can play immediately on others to reduce the effects of their meals. Send another player to the gym and they lose some of the points value of their meal. Make them projectile vomit and one of the meals in their stomach is violently deposited into your own.

Team Maggi had a reasonably huge team as a lot of them couldn’t make both days. For the most part they are EVE developers with the additional talents of our CEO Hilmar, his daughter and Hinrik one of EVE’s game masters. Again it’s pretty hard to demo being a physical thing so here is a shot of the game in the final stages of production.

Team Maggi making the final preparations to demo their game.

Team Maggi making the final preparations to demo their game.

Our first award category is the “Saaaay Whaaat?” Award for Oddness. One of the nice things about Game Jam’s is it gives people a chance to experiment without fear of wasting a lot of time to get nowhere. Team Chickenheart who mostly comprised of EVE’s Security team definitely took that spirit to heart. Their game Achy Breaky Heart is controlled via a physical game board watched over by a webcam. The tech stack behind it comprised two networked PCs and a fearsome collection of code tools to represent the board as a web app. The game itself involved sliding a marker onto the board in order to hit a heart on the screen which is quite a tricky bit of spatial reasoning. It’s a bit hard to show in action so you’ll have to make do with a screenshot.


The physical game board in action.

About a year ago I floated the idea of running an internal game jam and got a lot of interest from not just the developers but from our business and support staff. Actually implementing that idea got waylaid by being too busy with development (we were on a very tight deadline revamping the hacking in EVE) and by my not really being senior enough to co-opt things like people and budget to help out. The idea was revived by my immediate manager Bjossi and along with a crack team of others interested in helping out we assembled what I think was the first Game Jam organized within CCP.

Eating pizza at the end of day one.

Eating pizza at the end of day one.

My part in things was to work with a few other people to come up with a format and generally sort out how we would run things. In the end I actually facilitated the whole thing as Bjossi was unexpectedly unavailable. I think our format was pretty good and the results really speak for themselves. I’ve reproduced the important details below so that others can use it as a template:

Organizing a Jam

Game Jam Rules

  • All game code and content must be made on the 14th and 15th of February.
  • All games must be based on the theme of the jam. The theme will be announced at the beginning of the jam.
  • There is no restriction on third party libraries or tools although you must only use software with a valid license (e.g. trial license).
  • There is no restriction on preparation for the event so long as no content or game code is written prior to the theme being announced.
  • Games may be digital or paper based.
  • All digital games must run on Windows.
  • We’re going to share source code internally as it can be a great learning tool.
  • All IP created is the property of CCP Games.

Forming Teams

Teams will be formed immediately after the jam theme has been announced. We’ll have a mic ready so people can make small pitches if they have an idea and want to get people on board. We’re going to try as far as possible to leave this as a self-organizing effort but please bear these things in mind:

  • Teams shouldn’t really be larger that 6 members.
  • Try to recruit of join up with people you don’t normally work with.
  • Attempt to spread people that work on games directly during the day out between teams.
  • If you have special requirements about when you can or can’t work just let your teams know. I hope most people will be glad of the extra pair of hands even for a short while.

CCP very kindly gave us permission to run the Game Jam using one day from the working week and the use of the office facilities over the weekend. We also got budget to feed the troops pizza and beer after day one, for some beers to available during a showcase afterwards and for some free drinks at a local bar as an after-party for the participants. We also block booked out some of the meetings rooms in the office for the exclusive use of the teams and allowed people to work offsite, although only one team actually did. For communication before and during the Jam we had a couple of mailing lists setup and a chat-room open for all the participants.

At the beginning of the work day on the Friday we announced the theme ‘One Heart to Break’ and after a bit of a false start everyone quickly formed up into teams and disappeared. I spent most of the day trying to make sure everyone had what they needed. There was a hard submission deadline of five PM on the Saturday evening which all the teams made, although some only just! After they submitted everyone rushed to get setup to demo their creation in a showcase open to the rest of the people from the office. Beer was consumed, fun was had and then each team gave a little presentation about their game before I announced the prize winners. After we’d packed up we all adjourned to the pub where the event was dissected in detail.

One of the teams looking a bit stressed out.

One of the teams looking a bit stressed out.

Lessons Learned

Game Jam’s are awesome, most people that have taken part in one will have enjoyed it. Ours was no exception and the event generated a tremendous amount of good will from the participants. At the beginning I was a little worried that teams wouldn’t end up making very much but every single team made at least one game. People did mix up who they worked with a little but most of the big organization boundaries weren’t crossed. I think that’s about all you can expect running this sort of event for the first time.

I would like to make more of a thing out of the showcase when we do this again. The organization was a bit last minute and we could have done more to make the event something people wanted to attend as well as easier for the teams to setup and be distinct from one another.

For those interested in technology choices by far the most prevalent choice was a variety of web platforms with most code written in JavaScript. The only big game engine used was Unity by one team. We had one team make a card game and another using a physical game board to control a videogame. By far the most unusual choice was the piece of interactive fiction a team created in Confluence our project wiki software!

Over the next few days I’ll post about each of the prize winners before summing up the remaining entries.