Okay, I’ve got yet ANOTHER game for you to munch on. It’s a product of my 48 hours work in the latest Ludum Dare Competition.

The theme was “Enemies as weapons” and there were a bunch of interesting games that came out of it. Die alien die uses this concept in a pretty simplistic way: it’s a shoot em up where you don’t shoot, but instead use your gravitational pull to fling enemies into your Alien nemesis.

Defeat each of his five stages to beat the game!

Chaos Invaders is chaotic remake of Space Invaders. I’ve been working hard trying to make a version of Space Invaders that’s ready to take on the ADHD world of flash games.
The game introduces one more core mechanic: collecting fallen Invaders and then using them as ammunition to shoot the rest out of the sky. Each of the 17 waves is pretty unique, with four Boss Invaders, just to shake things up.

Keep in the loop! I’ll be posting the intense techno-rock sound track that’s been hand made with love and awesome by Paul Kopetko within the next few days, followed by a trailer.

Ps. Sam has a game under way as well. No clues just yet, but I am excite.

Game design isn’t something you do on your own.

I would divide the development time for each of us up into the following:

• 20% programming
• 30% testing
• 10% art (we get some help from some awesome friends)

But this only adds up to 60%, so whats the deal? This might not be true for everyone but about 40% of the time, which is the bulk of our development time, we spend discussing our games. Just talking about them, brainstorming, getting all of our ideas about each others games out – and it’s by far the most important step of the entire process.

Being able to bounce your ideas off someone else means you don’t get attached to them. The special someone can help your ideas grow and take directions you couldn’t dream of before. The collective conscious of two game designers is far more than the sum of the two thinking independently.

The lesson? Find someone to bounce your ideas off. Even if they don’t program, don’t do art, don’t test games or even if they don’t design games; they’ll help you out. While you might have awesome ideas, they can only ever be made better by sharing them.

For both our projects, we’ve helped each other think of some fantastic new ideas, helped put things in perspective and helped test each others work. Sure we’re not working on the same project, but we are still a valuable team.

While doing a bit of research, I came across a book which described this better than I ever could. I highly recommend you pick up Jesse Schell’s, “The Art of Game Design”.

Stop thinking about your game and start thinking about the experience of the player. Ask yourself these questions:

• What experience do I want the player to have?
• What is essential to that experience?
• How can my game capture that essence?

If there is a big difference between the experience you want to create and the one you are actually creating, your game needs to change: You need to clearly state the essential experience you desire, and find as many ways as possible to instill this essence into your game.

This article will cover just one of the ways of to instill the essence in your game; through its mechanics.

This means I’ll go into the nitty gritty detail of breaking down a game experience so that it can be successfully analyzed and implemented in your own games. And its not exactly an easy process, but I’m going to try tackle it. The way I plan to do this over two articles. The first is to outlining the process of deconstructing a game experience. The second is an example of this kind of deconstruction and how it can be used to refine ideas. While it seems fairly up in the clouds at the moment, hopefully by the end I’ll demonstrate that it can actually provides a solid framework for generating fun in your game.

The Alternative

Before we dive into this process, it’s important to identify what the alternative is. The lazy way to design a game is to think of one or two core mechanics, start implementing them and make decisions along the way about the ultimate direction of the game. Unfortunately, while the mechanics may be inherently fun, it takes exceptional talent to be able to make good low level decisions about gameplay before the gameplay has even begun to take shape. More often than not, these decision are crucial in the formation of the final experience. This kind of game design often results in an unfinished prototype.

The Problem

The thing to remember is that while the mechanic might work well in your imagination, game design is about more than just your imagination. It’s about creating a bridge between your imagination and your player’s experience. This bridge is your game. To create a successful bridge you must be able to understand, from the beginning, the way in which your game will be interpreted and the experience the user will have. To extend the metaphor, you have to design the bridge so when you build it the ends meet. If you don’t know exactly why your game will be fun for the player, it will just be coincidence if turns out that way. So being able to identify the experience your user will have is necessity.

The Solution: The Deconstruction Process

Okay finally, lets get into the meat of this thing. In any game, the core gameplay experience is defined by the users interaction with its mechanics. So in order to create a particular experience, we have to carefully choose the mechanics which will best produce this experience. One of the best ways of choosing these is by finding mechanics in other games which evoke the same experience.

Unfortunately, this is not an easy process to teach since at its core it involves introspection. What I can do is provide a primitive framework for finding these mechanics, but really the hard work has to be done by you.

1. Decide on an experience
2. Find a variety of games which evoke this experience
3. Find where this experience is most potent
4. Find the mechanics responsible for this

I should just note here that this process is designed to compliment your own creativity in design the experience, not replace it. At any stage of this process, augment this with your own mechanics.

1. Deciding on an Experience

The title is misleading, you can have already decided on core mechanics for your game. Deciding on an experience will just help give context to these mechanics, and an overall direction for the rest of your game. Essentially it will help the game develop into a more holistic experience.

The best way to decide on an experience is to find one which has resonated with you in the past. There is no point in trying to design a game around an experience that you haven’t had. You might already have an experience in mind, but if you don’t, try thinking about some of your favorite games and why they were so fun for you. What experience did you take away from the game?

The experience could be a range of things, for example in Yoshi’s Island I felt a great achievement in mastering the controls and progressing to the stage where I could skillfully and quickly guide Yoshi through the levels. In the flash game “Learn To Fly” I enjoyed the continual progress I was making, and the anticipation of the progress still to come.

The other option is to choose an experience that you think other people will enjoy. Essentially to design a game for the masses; a lowest common denominator experience which will “make you the most money”. However, I think the true talent of a game designer is only unveiled when they are developing games that they wish existed, games which they would drop everything to play. If you design a game that you’re not passionate about, you’ll be hard pressed to make the best decisions about the final direction of the game since you won’t know exactly where this direction is leading. And really, chances are that if you enjoy the end product, there will be millions of people in the world that are of like mind.

2. Find a variety of games which evoke this experience

Although you may have one particular game in mind, it is important to find others since they will all offer variations on the mechanics which produce this experience. Its also important to look into the communality and difference in these games when assessing what you think to be one of these mechanics. Basically, no one game is the best game and producing this experience, and there is something to be learned from all of them.

The best way to do this is to do your research, look through and play games in a similar genre. This is where a good general knowledge of games comes in handy. Having played through a lot of games will give you the edge here. This could be the only time in your life that you can pass of playing games as research!

3. Find where your experience is most potent

This part is easily the most fun, but also the most difficult. Just play the games! If you’re having fun, you’re doing it right. The point is to work out exactly when you are having the most fun, and why you are having fun. Introspection really comes into play here; you have to be able to dissect the experience you are having.

This experience is often surprisingly difficult to articulate, and not because we are unfamiliar with our experiences. In fact the opposite is true, we are too familiar with them, to the point where our mechanism for processing them is so deeply engrained in our subconscious that it is difficult to tap into with a higher level though process.

This being said, it is exactly what you need to do. Figure out what’s keeping you playing, and how you are feeling while you are playing it. Take a pen and just jot it down.

Often you’ll have to use your memory for this section. When you are analyzing small scale games (especially flash games) this process will be far more straight forward, since typically the gameplay will only last an hour or two. Larger games like console games and especially MMO’s cumulatively develop and experience over a longer period of time, so the core experience wont’ always have the same immediate pang of fun as with flash games. This makes it a bit more tricky to deconstruct.

4. Find mechanics responsible for this experience

The next step is really working out what mechanics in the game are responsible for this experience. Again, its hard to give advice here, since it’s different from game to game. But it is vitally important. Usually when you are having fun there is some immediate indicator as to why this is, which is exactly what you’re looking for. This indicator is the mechanic or collection of mechanics which define the experience. This is best described in a case study which I’ll post in my next article.

To Be Continued

Thats basically it! This might still seem a bit hand wavy, so I’ll be writing a part two. It won’t cover any more theoretical ground, but doing a case study and deconstructing a particular experience using this concept. I’ll actually be deconstructing the achievement experience of upgrade systems in games. Hold tight.

Sam Fisher. Professional Bad Ass.

So yesterday, we took some time off our tough and traumatic lives as Game Designers and Students in order to have a bit of fun. And by a bit of fun I mean a lot of fun. And by a lot of fun I mean Splinter Cell Conviction Co-op. Its worth sharing.

Sash:

I’m the kind of guy that always tries to play games stealthy. In MMO’s I choose thief, in strategy games I go out of my way to keep units alive and sneak up on the enemy. But I don’t think I have ever played a game where stealth really just works. It works in Splinter Cell Conviction, and it’s fun. The plan for this post is to discuss the fun we had, and work out how Splinter Cell makes it work.

Sam:

Stealth is rocking. I’m a huge fan of the Thief series; that game did stealth really really well. But Splinter Cell Conviction manages to make stealth more about being fun than about being realistic. Which leads to epic multi-hour long sessions of co-op.

Sash:

You know personally I think this is what all games should do, aim to create a particular experience that is awesome and do whatever it takes to get there. As opposed to getting caught up on being realistic, which might prohibit the intended experience from fully evolving. Some of the stuff in Splinter Cell is totally unrealistic, like the shadows and mark and execute, but it just refines its core experience.

Sam:

Not to say that Thief doesn’t do that and it rocks, it just has a different target experience. The goal of that game isn’t to be just about *fun*, but to be an interesting and holistic experience, even at the cost of immediate enjoyment. It’s a contrast to Splinter Cell, in which every single mechanic is designed around making the player feel like a futuristic ninja badass. And damn does Splinter Cell do it well.

Sash:

What does Thief do differently?

Sam:

Thief does risk/reward in a way so as to make the game incredibly tense. If you screw up it is a big deal. This tension is what the game is all about.

Sash:

Right, well that is completely different to Splinter Cell, which is more about planning and optimizing your kills vs stealth level, and it removes a bunch of the tension in order to really hone in on this experience. It really does stealth differently to anything I’ve seen done before.

Showing off Mark and Execute from the Shadows

Sam:

Thats what makes this game interesting. It’s a sneaky-type game, but the gameplay is relatively relaxed. And even if you screw up, the Last-Known-Position mechanic let’s you take another chance at being a ninja. For those who don’t know, the mechanic means you can see exactly where the enemies think you are, which allows you to fall back to a safe position knowing full well where the enemies will be heading.

Sash:

That mechanic really pushes the idea of more strategy-based game. In fact there are a bunch of other interesting mechanics which work to this end: like the shadow stealth meter, the Goal based controls, and the Mark and Execute system.

Sam:

Man I love the Mark and Execute mechanic. I was kind of worried it would make the game too easy, but there’s a really nice risk-reward process that goes a long with it. Basically it gives you the opportunity to get up to 4 guaranteed stealth kills after you have ninja’d someone in melee. What makes this really work though is that you can choose your targets before you get the melee kill.

Sash:

It really gives you the opportunity to plan out your kills. Again focusing on strategy, while you’re in the shadows you have the chance to work out exactly who you need to melee, who you will execute, what angle you should come at it from, how to get into position without being seen. This all happens in your head before you even need to touch the controls.

Sam:

Exactly. The fact that Shadow Stealth Meter tells you so cleanly when you’re hidden and when you’re not means that you can focus entirely on your planning without having to worry about not being seen.

Sash:

That thing is so useful, at first I thought it was a bit of a gimmick, but after about half an hour of gameplay I realized that I was really relying on it. It all links back into this core experience. Man, even the controls work in with this! They do some really interesting stuff, all the controls are goal based, and by that I mean they all help you achieve a goal instead of providing you the means to do so. It takes a bunch of skill out of where it isn’t needed which is cool, because it means you can just worry about planning stuff out.

Sam:

The way I would put it is that the controls manage to make the interface between the player’s hands and Sam Fisher as transparent as possible. The point is that in RL, people don’t think about individual actions, they just subconsciously do them in order to achieve whatever goal is in mind – and the controls reflect this. All of the mechanics we’ve discussed emphasize this idea of doing what you want to do, and making the challenge the strategy of the fight as opposed to the fight itself.

Sash:

That really is what is so fun about the game. It’s a strategy-like stealth game without you even knowing it. It makes you feel like you’re playing it like a third person shooter – which is bad ass given the stuff you pull off – but really you’re just not bogged down in the workings of the system. You can just DO IT. I love it. Play this game as soon as possible.

Wrapping Up

The game realizes what is so fun about stealth gameplay. It removes the stress of continually staying under cover and instead implements a system which was almost turn based in nature. The effect of this was profound; it changed the game from a twitch-based third person shooter into a game about planning, anticipation and strategy. It is in this experience that the core fun of stealth lies.

There is way more to the game than what we have discussed here, but the goal of this post was to talk about what we felt was interesting about the game. Specifically the way unique stealth experience is constructed through its mechanics. So don’t froth about how we glossed over the story line and graphics. Hope you enjoyed it even half as much as we did playing and arguing about it.

This conversation is a bit of an experiment for us. We would love to hear some feedback about it!

Bit Battalion out.

All in a days work

So the adventure with Mr Runner’s development is pretty much coming to a close. I’ve still got a bit of work to do with selling some more non-exclusive licenses, but it’s done. It’s time to sit back and look at what has come out of the chaos of my experience. I’ll be talking about the creation process, finding sponsorship using FGL, working in partnership with cool sites like GameShed, and my personal analysis of the game.

I’m hoping that this article will be useful for any developers that are planning on making flash games of their own and finding sponsorship using FGL. Feel free to send me off an email with any other questions you might have about the development process!

Creating the game

First off I would like to wham you with some statistics about the time I spent on Mr Runner.

6 months all up - Part time
4 months – Development of the game from idea to implementation
1 month – Find a sponsor over at Flash Game License
1 month – Releasing it to the public

This was all really part-time. For the most part I was at university studying full-time while it was in development. Working full-time on the project these numbers would have probably been halved! But that’s all just a big excuse, just a feeble attempt justify a profession as a flash game developer.

So lets start from the beginning.

The Initial Game Idea

I mentioned in my Experience Driven Game Design article, I approached Mr Runner from a slightly different angle than my previous games. Mr Runner doesn’t have any mechanics that are all that unique, it just plays off tried and true platforming mechanics. So why would I bother making it in the first place? This is something I had to answer for my self, and it turned out not to be that hard. I made it because it was a game I wanted to play.

Mr Runner emulates an experience that I absolutely adored having in the past. It’s heavily inspired by games such as Yoshi’s Island, Trials HD, Mirrors Edge and even Canabalt. When I decided to make Mr Runner, I decided I wanted to make a game which emulated the essential experience of these games, and focused its mechanics around fast, difficult, smooth-flowing platforming gameplay. This was my initial idea; an idea about an experience, not a mechanic.

My inspiration - spot the difference

What’s interesting is that while I had all these ideas in mind, I didn’t know exactly how the final gameplay would turn out. Initially I planned for Mr Runner to be a game filled with enemies whose death would be part of the speed running process. I wanted the player to be rewarded for doing things smoothly by having a “Fever Meter”, like in Peggle. I wanted to have collectables. I wanted everything. It didn’t take me long to realize that not only was this not feasible being one man, but it would have also distracted from the core platforming experience.

So as I started developing Mr Runner, the gameplay became more and more refined. I didn’t have an exact plan from the beginning, I had the goal of a particular experience, and the gameplay mechanics evolved through out the development to suit this experience. At every stage I would compare the latest feature to the overall experience, and adjust it accordingly.

Looking back on core gameplay mechanics, Mr Runner is almost exactly how I wanted it to end up. That’s not to say it’s perfect, but I’ll look into that in the Analysis section of this article.

Coding

Before I dive into specifics of the coding process, I’ll give you a bit of context. I developed the entire game from scratch. The tile engine, the rendering, the player controls, the editor, everything. I only used a few libraries, in fact just Tweener and Mochi leaderboards. The rest I coded my self using the classes I had designed for previous games and projects, and a whole lot of new code.

Looking back on it, the project would have lent itself quite nicely to Flixel project.

My Code - See if you can guess what that bit does

I managed to knock over most of the code pretty quickly, in fact the bulk of the engine and control coding was over within the first few weeks. I spent about 30% of the time making Tile Engine that it ran on. As always, looking back on it, it was pretty patched together, but it worked pretty solidly in the end. Another 20% or so I dedicated to the editor, which I finished before I even started making levels. Surprisingly, this left about 50% of my time dedicated to working on the player controls. I took longer than I expected to get the motion, wall jumps, sliding, etc. exactly how I wanted it.

The completion of the engine had been a significant milestone which was good and bad. The problem was that I hadn’t actually done too much game design yet. It is always a daunting prospect to have worked on a project solidly for two weeks having no tangible player experience. I think for many game designers, it becomes psychological barrier which catches them out and turns them off the project. It’s at this point in the development process that really drains the motivation of the developer.

Level Design

Surprisingly, I spent the next few months working on levels, which turned out to be the most time-consuming part of the project, but also easily the most fun. The level design in Mr Runner was tricky because it was the level design which really was to make or break the game. Looking at some of the user-generated levels, I found that the game’s Experience was almost entirely defined by the levels I had created – some of the user levels were an almost entirely different experience!

Keeping the levels cool. With ice. And bad puns.

When I was designing the levels, I was continually challenged to evoke the desired experience but at the same time create original content. I decided to theme each level, so they were identifiably unique. I wanted players to be able to easily verbally identify and differentiate between levels by their defining features, while still having loads of fun when playing it.

I found after this initial hurdle, the levels actually came quite naturally to me. The level design process would start off with a single idea or theme, and I would just make it up on the go, thinking of cool ideas that worked with the previous parts of the level. It was too much fun. Also, because didn’t require all of my concentration at once, I managed to devour the entire Avatar the Last Air Bender series while designing levels. I highly recommend it.

Art

I’m not much of an artist, and the game probably reflects this. Animation I can do, but art has always been a bit tricky. For me, this is where Mr Runner falls down. I enjoyed stylizing the graphics to a particular theme, but I worked to strictly in the confines on my engine. I had very few unique tiles sprites, so the level’s interest was something that was defined purely by their challenge and dynamics, which is a bad sign for flash games. Unfortunately, since I was so caught up in the experience of the mechanics, it was too easy for me to overlook this aspect of game design. I’ll look into this further in the analysis section.

Monetizing and Finding a Sponsor

I didn’t even begin to think about monetize my game until it was completely finished, exactly how I wanted it. In fact I think outside of my close friend group, nobody had heard of it. I’m not much of a businessman, so I didn’t exactly go overboard with marketing. But luckily there is a super easy way to get a game very quickly well known to sponsors; through Flash Game License.

Why Yes. Yes that is a piggy bank made of solid gold. You can have one too when you're awesome

You probably already know all about Flash Game License, but for those who don’t basically it’s a site where you can quickly and easily make your flash game known to all the major flash game sponsors and have them bid on sponsorship conditions for your game. It’s like an ebay for flash games, pretty much the ideal system for monetizing flash games.

I’ll outline my experience to give you a better idea of the system.

Selling Statistics and Stuff

Again before I get right into the details of Flash Game License, I’ll hit you up with a few statistics. On FGL in 2009:

Average Flash Game Sale was worth $1484.10
Number of Flash Game Sales was 4087

Don’t worry too much about the low averages on this, a good game won’t be subject to them as I’ll show you later on in the article. But you can check out the full article on these stats here . Mr Runner performed much better than the average game on this site. In comparison to my previous game:

Spacetacular Voyage received 2 bids all up.
Mr Runner received 24.

Spacetacular Voyage sold a primary license to Bubble Box for $2500.
Mr Runner sold a primary license to Kongregate for $8500.

Spacetacular Voyage sold a single non-exclusive license for $350.
Mr Runner sold four totaling $4250, and hasn’t finished selling.

So you get the idea.

Exclusive, Primary and Non-Exclusive Licenses

I think I had better cover some of the terminology I just threw at you. Basically when you sell a flash game, you can sell it with one of three condition attached:

Exclusive: There will only ever be one copy of the game out on the internet with the sponsors branding. You can’t sell any more licenses once you have sold one of these.
Primary: The default copy of the game on the internet will have the sponsor’s branding. You can, however, sell non-exclusive licenses to other sponsors.
Non-exclusive: A site-locked version of the game with the purchasing sponsor’s branding and API’s. It cannot be used anywhere but on their site.

So essentially you either accept a single exclusive license, or a single primary license with multiple non exclusive licenses. Generally a primary license is ideal, especially in high grossing games since a sponsor would have to make an especially large bid to encompass the cost of all potential non-exclusive bids. In the case of Mr Runner, the highest exclusive bid was $10000, which was a whole 30% less than the final amount including non-exclusive bids.

Don’t expect every flash game to do this well. I’ve had friends submit games that have earned less than $1000. It really all depends on much money the sponsor’s think your game will make them. To them it’s all business. That being said, if you make a good game, it will pretty much definitely do well.

Flash Game License - Where all the cool kids go

In summary I highly recommend FGL. I suggest banging a good game out quickly to test the water and get a feel for the place. Spend a bunch of time on the chat there talking to developers about their experience, and when you do put your game up for bidding, send out a few personal messages to let sponsor’s know what’s out there. Lastly, don’t be afraid to try out the FGL services and pay their commissions. Making a presence in the community there can be a pretty big deal, it will let you into places like the editors spotlight, and might even get your game recommended to sponsors in things like their news letters (which Mr Runner was). Basically, if you’re good to them they’ll return the favor for a good game. Adam and Chris are great guys.

Reflection on the Final Product

Awesome, here is where I get to do what I’m good at. Being an arrogant jerk. Okay I’ll try refrain and give you my honest opinion on what I though of the game.

The Gameplay

I really enjoyed Mr Runner! As I mentioned before, I decided from the beginning to design a game around and Experience that I personally loved. I felt like I achieved that experience in many respects, especially once you were good enough at the game to properly enjoy the fast paced smooth flowing gameplay. I might be the only person in the world to have unlocked all the platinum medals, which I guess is to be expected since I created the game.

That's the end second last level. Finished in just over 13 seconds. Now you try it.

The Learning Curve

I didn’t experience it. From the very beginning I was familiarized with the controls. But after a bunch of play testing, it became apparent that there was a super steep learning curve. The problem with this is that to fully appreciate the game you must have, to a degree, mastered the controls.

Looking back on it I should have tried harder to lessen the curve, ease up the first couple of levels so that people could more fully appreciate the game. Currently, the game has had half a million views and only 1000 of those have actually finished the game. The last level is pretty tough.

The Art and Feel of the Game

The art style I felt was where I let myself down the most. The art was stylized, sure, but it wasn’t engaging. There was very little about the art style which held interest past the first couple of levels: the tiles were the same for the most part, the colors were dull and muted, there were no extra bits of scenery, no animations etc. A bunch of feedback I got treated me with the “Awesome old school retro pixel graphics”, which is true, but they just aren’t all that engaging.

But now I have to qualify their suck. The reason I published a product I wasn’t content with was development time restrictions. Remember I was developing this on my own, so I had to do all the art. Adding in extra features would have meant extending the engine, and by the time I got around to it I was so burnt out that I wanted to get it out the door. I had hoped people would appreciate it for the gameplay and not “judge a book by its cover”.

The problem with this mentality is that players initially have very little investment in flash games; they would just as easily close the browser tab as play the game. They are expecting trash. For this reason, first impressions (which is for the most part the graphical style) is actually fundamental to creating this investment. I don’t think Mr Runner’s muted style was too successful in this regard.

Done and Dusted

So that’s it! That was more or less the last six months of my life compacted into a lengthy and grammar deprived article. I hope you learned even a sliver of what I have. Just pop me an email if you have any questions! I’ll be good and make sure to reply.

Bit Battalion Out.

The Paradigm

So what does “design for experience” mean? When I first started thinking about Mr Runner (my latest game), I realized I didn’t start thinking about the mechanics and dynamics of the game or the levels and bosses and upgrades like I usually do, I started off thinking about how I wanted people to feel when playing the game. When I was describing it to Sam, I didn’t describe it as “a game where you do X”, because I had no clue what “X” was yet, but I described it as “a game where the player feels X”. You dig?

I know it seems kinda backwards at first, but the whole point of the game is to deliver an experience to the user. Usually this experience is in the form of a particular kind of fun. Especially with small games. So it makes sense to decide on the kind of fun you want the user to experience, then work backwards by tuning the rest of your game around it.

So what’s the alternative? Mechanic driven design. In this paradigm, the first step in designing any game was to come up with some game mechanic or context. Avoiding high speed obstacles, shooting terrorists, rescuing a princess, you know – awesome stuff. Next is to think about things you’ll be able to do with mechanics, and then starting thinking of all the different ways to fill the rest of the game out. There have been plenty of good games made this way and I’m guessing almost all are, but there is a problem in this methodology; there is no way of telling how fun the combination of concept, mechanics and depth will be until all of those elements are in place. There is always the assumption that once all the elements are in place, the game will just click, and be fun. This doesn’t always happen, and when it doesn’t, how are you supposed to go about making it fun?

So what’s missing? In the experience driven model of game design there has to be a decision made about what the game will make the player feel. From here on out, the concept, mechanics and depth can all be judged against how effective it is a producing this experience in the player. Essentially, it provides an overarching goal and a way to analyze the rest of your game, which can be applied every step of the way.

I should clarify here, using this paradigm doesn’t mean that you can’t then go about and design games the way you usually do. You just have to make sure that you’ve really thought out and researched what experience it’s going to produce. So it’s not mutually exclusive with the mechanic driven design.

Deciding on and researching a user experience

There is a gaping whole in the paradigm I haven’t covered. How are you supposed to know what experience the game will invoke? How do you know what you want them to feel? On top of that, its often hard to articulate why something is actually fun. The easiest way to overcome these problems and decide on an experience is to work out what experiences you personally enjoy in a game. Even though is different from person to person, chances are if you rate it, there will be a bunch of other people in the same boat. So, play a whole lot of games, find the ones you enjoy, and seek to emulate the type of enjoyment. Use your own experience as a blueprint for the experience your game will invoke in others.

I’ll give you an example of how I did this in Mr Runner. I played Yoshi’s Island to death as a kid, if you haven’t played it do so immediately! One of the things that kept me playing long after I had defeated baby bowser was speed running through levels, jumping from enemy to enemy by timing your jumps perfectly. Like this.

There was something incredibly rewarding for me about conserving Yoshi’s momentum, even though the game wasn’t supposed to be played like that at all. I never got as good at it as the dude you just watched, but I still played it for hours and hours. I would sit under the covers with my GBA replaying levels I had played hundreds of times. Years later, I picked up Trials HD on XBLA. Since then I have spent far too much of my life on that game. Again, there was a certain enjoyment in surpassing every obstacle skillfully, and especially in finally achieving gold in each level. So when it came round to Mr Runner, I decided from the outset that it was these two kinds of fun I wanted the user to experience. I went back and replayed these games, along with another few, just before diving into development.

The point of doing this research is so that you know exactly how you want people to feel when they play your game. I should also point out, you don’t have to do this before you come up with a game idea. You can start off designing a game based around a mechanic just so long as you then decide what type of fun you want this mechanic to produce.

Choosing mechanics to work with your experience

Next up, you have to choose what mechanics your game is going to have; how the gameplay will actually turn out. Even if you have already decided on one main one, it’s good to follow this process just for some supplementary mechanics which add to the experience. There are a few ways of actually honing in on these:

Good old fashion way, make them up. Straight from your very own brain. However while they always seem good when there up in your brain, unless you are exceptionally talented they usually won’t recreate the experience exactly as you envisaged it. Here lies the key difference in mechanic vs experience driven design, in mechanic driven design, the rest of the game would be molded around this mechanic. In experience driven design, the mechanic would be moulded to suit the experience you are creating. In other words, don’t get strung up on a mechanic just because it sounds awesome. Keep the overarching goal of creating an experience in mind.

There is another way; Isolate mechanics in other games which produce the experience you are trying to emulate. When you are having heaps of fun with a game, it’s often a direct result of its mechanics, although there are always other things that add to this. Its not always obvious, but if you can isolate what mechanics in the game are contributing most to your experience, you can then use these as a basis for the mechanics in your own game. I’m not saying copy exactly, but at the very least use them as inspiration. I’ll give you an example.

You might have figured this out already, but Mr Runner doesn’t exactly go nuts with creative mechanics. When I was plotting out the mechanics for Mr Runner, I looked at what I enjoyed most about a bunch of games. Yoshi’s Island I loved in so many ways, but the longest lasting type of fun for me was in the mastery of the controls that I explained before. After playing for a bit, I was able to start predicting exactly Yoshi’s jumps, timing them perfectly to hop from enemy to enemy and finish the level super fluently. The mechanic that made this possible was in part his floating, which helped to time his jumps. Also that you could jump variable heights, depending on the duration of the button press (check this video out again to see what I mean). I used these mechanics in Runner to a similar effect, to produce the fun of skill and fluency in controls, amongst other things.

I should just mention that I’ve pretty much just been talking about mechanics, but this isn’t the only thing to consider in experience driven design. In fact it might not even be the most important, but it’s the most relevant to gameplay designers, which is why I put so much emphasis on it. The visual direction and sound might be more subtle, but they play just as important a part. They’ve got to integrate seamlessly with your mechanics to fully produce the experience you’re after. This article has already dug pretty deep, so I’ll save it for another time.

So to sum up, this paradigm encourages you to design your games with what the user is going to feel when they’re playing it. To get a feel for this, look into other games which have successfully created a similar experience so you know what to aim for, and look at what key mechanics so that you can be influenced by these in the design of your own game. Do this right and you shouldn’t feel limited at all, just inspired. Got it?

Bit Battalion out.