Ring Fling – Developer Diary 4 – Pub Testing

On the second day of development, I was feeling great about where Ring Fling had gotten and decided to see if anyone wanted to meet me down at the pub and have a go. My very kind friend, Mike Bithell, volunteered to play Ring Fling and give me some feedback. The boys from Makielab were also up for a laugh. Little did I know, that Ring Fling had gone Alpha.

Obviously, on and indie title, there are no publishers and no milestones. I was just coding along doing whatever I felt like. In the console game industry, there are 4 major milestones for a game: green light, alpha, beta, and gold. In theory, green light is when you have a “vertical slice” of the game to determine if the project is worth moving forward on or not, alpha is when the game is feature complete, beta is when all the critical bugs are fixed, and gold is when you have a party. In my experiences, though, it’s very different. Green light is when you’ve hacked together a demo that convinces that publisher that you might actually be able to finish a game. Alpha is when you’ve made the game you originally set out to make in your game design document. Beta is when you’ve changed the game you thought you were making into a game that you’d be happy to show to the public. Gold is when you send a build to your publisher and feel really awkward for a few weeks because you have no work to do, but you don’t know if you’re actually done yet.

Anyway, by my own definition, Alpha is when you’ve made the game you originally set out to make. The implication is obviously that the game you set out to make is generally not any good. There’s no real way to know that it wasn’t going to be any good, though, other than to make it and try it. Well, if you’ve had as much experience as me, it’s easy to know that it won’t be any good, but nearly impossible to know exactly what parts won’t be good and what kinds of solutions will address those problems.

So we sat down at the pub and started to play. One of the incredible things about having such talented friends is that within 10 seconds, people were demanding changes. Fully expecting this to happen, I had brought my laptop. I’d never done live coding like that before. Within about 20 minutes, we had done 10 iterations on the game. We tweaked the sizes of each of the zones. We added clearing of rings in between rounds. We limited to the number of rings you could fling. It was incredible how much better the game got after 20 minutes of tweaking.

However, it was clear that there was still a lot of work to be done. There were quite a few features that were requested that I couldn’t get done in a few minutes and I added all of those to a list. What really stood out, though, was that playing Ring Fling for 20 minutes was exhausting. There wasn’t a whole lot of strategy involved. It was just a game of speed and accuracy. While that wasn’t the end of the world, it wasn’t something I was remarkably happy with. In fact, one of my biggest regrets with the gameplay video I posted is that I didn’t show much strategy with charged shots. I was just in a rush to edit something together that I grabbed all the “exciting” parts rather than clearly demonstrating the full range of the game.

We spent the rest of the night just chatting about Ring Fling, Thomas, and Makies. I wrote down any ideas that I thought could make the game even the slightest bit more varied and strategic. Before that night, I naively thought I could have the app ready for App Store submission with another 6 hours or so, bringing the total up to 18 hours. However, after a 20 minute play session at the pub and a conversation for a few hours afterward, I knew I’d be investing a whole lot more time into Ring Fling. I had started on my path to Beta, turning this little game into something I’d be proud to release on the App Store.

Ring Fling – Developer Diary 3 – The Point

Once I had a working prototype, I knew my velocity was about to slow down. Making the transition from nothing to something can be a very fast process. It’s not always the case, but for Ring Fling, it definitely was. However, going from something to something good has never been a fast process. The next thing to figure out in Ring Fling was what the point was, specifically, how the scoring would work.

When I got started, I didn’t think much about scoring, but in the back of my mind, I had a really simple solution. In my head, every player would start with a certain number of points and when they hit zero points, they’d be knocked out of the game and the remaining players would continue until one player was left standing. It didn’t take long to get this implemented, but in about as much time as it took to program, it became clear that it was fundamentally flawed.

At the time, it was only a 4 player game. If the last two players left were on the same side, especially on the short side of the iPad, the game was effectively impossible. I wasn’t quite ready to give up on the structure quite yet so I tried a number of things. I tried removing the knocked out players from the board completely to give more space to bounce rings, but that didn’t help much. The jaggies (at the time a square) would constantly get stuck in the corner. I also implemented a mode where once it got down to 2 players, those players would shift to the opposite sides of the screen. While this solved the problem, it felt really strange. In theory, if there were 4 people sitting down and playing a game, suddenly one player would have to stand up and move. So while I didn’t move forward with that solution, the code I wrote for it made it pretty trivial to implement the 4 player board.

The next solution I tried was to have score count up. Instead of losing a point every time a jaggie is pushed into your zone, everyone else would gain a point. It definitely felt less clear than the losing point solution. It’s obviously much easier for people to associate one cause to one effect rather than one cause to three effects, but at the end of the day, it worked and the other one didn’t. One other nice upside of this solution was that nobody ever had to sit out and do nothing. I remember when I was in college, the big game was Counterstrike. One thing that prevented me from ever getting into it was that as a beginner, the majority of my time was spent sitting and waiting for a timer. Firstly, with the count up scoring, it’s not immediately obvious when it’s mathematically impossible for you to win. Especially with the frantic action, doing the math is generally not a high priority. Secondly, even if you can’t possibly win, you can still do your best to make sure your nemesis can’t either.

This is a great example of the fastest part of the iterative process. You start coding something up and you just know it isn’t going to work. Sometimes it’s simply obvious, sometimes your experience serves you well. Once you’ve worked out all the obvious stuff, though, it’s time to get some more eyes on it–or in my case, some more fingers. It was time for a play test.

Ring Fling – Developer Diary 2 – Prototyping

I had picked my game concept and I was ready to start prototyping. Well, I should have been ready to start prototyping, but mentally, I wasn’t. Starting a new project is always a little bit intimidating, but when you’ve started so many and finished none of them, there’s that much more weighing you down. I was considering just writing blog posts all day instead of starting the prototype, but Twitter shouted me down. I did end up stalling a little bit by sorting out some stuff with the NHS and taking a long walk to grab some lunch. When I got back from lunch, though, I was ready to go.

It was definitely the wrong attitude to have. It’s important with prototypes to know they might go no where. It’s just part of the process. Sometimes ideas just work out. Sometimes it’s not the right time for ideas. The most important thing, though, is to know when a prototype has failed. With my last project, there were too many variables. I had to implement a large number of things before I could even think about if the game was going to work. I wasn’t about to make the same mistake again.

Ring Fling was going to live or die by one thing–whether I could make swiping to fling feel like second nature. I’m a big fan of the physical manipulation approach for touch screen devices. I love the app Clear and have used it to track all my tasks on Ring Fling. It’s a perfect example of building a user interface that maps naturally onto physical actions we’re already accustomed to. From the get go, I decided that Ring Fling was going to be a game for everyone. I wasn’t going to make a game that only other game developers could appreciate or a game just for people who know a particular genre well. I wanted to make sure it was a game that absolutely anyone could play. I remember whenever Mark Healey was asked what the target audience for LittleBigPlanet was, he would say “people with thumbs.” I remember how many people who didn’t consider themselves gamers would perk up when I mentioned I had worked on LBP and it was something that really stuck with me.

So the first thing I prototyped was creating little squares when you swiped from the bottom left corner of the screen. I implemented the obvious version of it. It kept track of the speed of your finger and when you let go, it used that speed for the projectile. In some ways, it wasn’t far off, but in a thousand other ways, I knew I had a lot of work to do. Just as it took me many years to realize that there’s a big difference between what someone does with a control pad and what they think they’ve done on a control pad, the same holds for touch screens. For example, even when doing a steady swipe, you tend to slow down for the last few frames, even if you don’t realize it. Also, people vastly underestimate how fast they can swipe their fingers across a touch screen.

Even without rules or even an objective for the game, I was able to determine if I thought the core interaction would ever feel just right. While I did go back to the swipe code over and over throughout the project, it was absolutely key to getting it to a point where I was confident that it could be brought to shippable.

Once I felt confident that the core mechanic was going to work, I threw in all the other pieces: 3 other players, targets to shoot at, and playfield boundaries. I put in some really basic graphics and we were playing. I played a few rounds with Carly and things were feeling good. I’d put in 6 hours so far and I felt pretty confident that this was a game I’d actually ship. I had no idea exactly what the final product would look like, but I knew that at it’s core, it would feel simple and fun. That was enough to make me confident that this was going to end up being something I’d be happy to put my name to.

Ring Fling – Developer Diary 1 – Origins

Howdy everyone. As you’ve hopefully all heard, Ring Fling has been approved by Apple and will be coming out on May 31st. I’m so much more excited about it then I ever imagined I would be. On one hand, I recognize that it’s a modest little game, but on the other hand, I genuinely feel like it’s really polished, approachable, and most importantly, loads of fun. While I’m bursting with energy, I thought I’d wrote some blog posts about it’s creation.

This one will be an origin story. Disappointingly, this is an origin story without radioactive spiders and even without a cat named Mr. Chubbikins. The idea for Ring Fling was born out of a series of failures. I’ve wanted to make a touch-based game for ages. I’ve previously written about Mismatch, which was a push-pull puzzle game which started out on PC, but was going well enough to convince me to buy a Mac to port our FTG codebase to iOS. Shortly afterward, though, FTG was abandoned and I started working on Facebook games.

It wasn’t until a random week about six months ago that I decided I wanted to take another stab at iOS. In fact, I decided I wanted to go whole hog into iOS. I deleted a lot of code that week. Firstly, I deleted all the console style code from FTG. There was so much code for handling control pads and doing all the various cross platform bits that I just got sick of maintaining. The bigger change, though, was that I deleted every line of code that Luke had written. It’s not that any of the code was bad or that Luke would have sued me if I used it. It was just that it was such a small codebase at that point, that I wanted to understand every single bit of it. I couldn’t have something break and have to ask Luke what was going on or anything like that.

The luxury I had was that I had a lot of “spare” time. I was working for a company in San Mateo called A Bit Lucky and I was working California hours from London. My normal work day was from 4PM until 1AM, which meant I had every morning to do whatever I wanted. It’s a sad state of affairs, but “whatever I wanted” at the time meant diving in things like serialization, resource management, memory management, etc. It’s the kind of stuff I always took for granted in the rest of my programming life. I don’t think I’d ever recommend to other people to write any of these things for themselves in this day and age, but it was very enlightening to do it once.

At the beginning of 2012, I decided to go freelance. My primary goal was to eek out 1 day a week to build up my game design skills. I had been making games for 8 years at that point, yet my ability to design games was just laughable. Everyone thinks they would be a great game designer, but actually designing games with a coherent set of complementary mechanics is absurdly difficult. The problem for me, was that as a programmer, my job was just to type other people’s ideas into the computer. The problem wasn’t that I wasn’t getting recognition or nobody was listening to my brilliant ideas. It was more than I knew if none of my ideas ever got to the player, I wouldn’t know if they were any good and I’d never get better at game design. It was a cycle that would ensure I’d always just be an implementer of other people’s ideas.

So, I sold my 4 days a week and started prototyping ideas on my 1 day a week. I started prototyping a strategy game. The idea was to make a game on two levels. There would be a world map level that was turn based and played like Civilization and then a city level, which would play like an RTS. I made the single biggest mistake that everyone makes on their first project. It was too big–way way way too big. It’s not that I couldn’t have made good progress one day a week. It was that it had too many mechanics for my game design abilities. There was no chance that I could ever make all the mechanics work together at all, let alone to balance them for both simplicity and depth.

So I decided to simplify things. I removed all the RTS elements and tried to convert it to a simultaneous turn-based asynchronous game. To be honest, it was horrible. There were definitely some interesting ideas going on. I played through a few games with my girlfriend and there was definitely something there. What was lacking, though, was anything to make it feel like it belonged on iOS. Every touch interaction was just pressing a button. It could have been done just as easily in Flash and probably would have been way better. I decided to take a day off of it and try to do something that “felt good.”

One of the great things about only doing 1 day a week as an indie was that if I had an idea I was really excited about, it would probably be a few days before I actually got to work on it. I know that sounds like it would be a disadvantage, but I thought it was great. Because my coding skills aren’t bad, but my game design skills are pretty weak, it gave me plenty of time to think about things and think through the obvious versions that wouldn’t work before committing them to code. It also gives me 8 tube journeys to play and dissect games to think about what makes the work. This week in particular, was especially lucky for me. I was organizing and event called GDC Left Behind, which was a series of random drinks in the UK for game developers who didn’t get to go to GDC. I went to 4 out of 5 of the events and got to chat about some ideas I had with some serious game design minds.

By the end of the week, I knew exactly what I was going to prototype. It was a mashup between Hungry Hungry Hippos and Crossfire. I dubbed it Operation Hippo Vomit.

Ring Fling Coming May 31st

I’m super excited to announce the Ring Fling has been approved by Apple and will be available on iPad, iPhone, and iPod Touch on May 31st.

I’m absolutely overflowing with excitement and pride. Ring Fling is the first game that I’ve designed, programmed, and done the art for. It was an absolutely amazing experience to have so much control over the project and I’m so happy with how it’s turned out. It’s only now starting to hit me that I’m actually going to have my own game out in the world.

I’m so thankful for all the people who have helped me make this game a reality and all the people who have been so supportive and helped me get the word out about it.

Announcing Ring Fling

So, I’m finally ready to unveil the game I’ve been working on for the last month. I probably should have announced it a long time ago, but I was stuck in a perpetual state of “one more day and it’ll be ready.” Anyway, it’s called Ring Fling and it’s a simple single-device multiplayer game. You fling rings to try to knock the jaggies into your opponents’ zones–pretty straight forward.

I wanted to talk a little bit at a high level about why I made this game and how I made it and all that. I’m sure I’ll go into some of the topics in more detail in later blog posts, but I thought I’d just throw whatever came to mind out there.

So let’s start with why I’m doing an iOS game. The main reason is that I haven’t released an iOS game before and I’m always trying to learn new things. I’ve done console games and I’ve done social games. I thought that doing a mobile game, specifically one with intuitive touch controls would be the best opportunity to learn more. I’ve always had this fear, verging on terror, that I’ll hit the point in my career where I’ve memorized how to do a set of things, but have stopped learning new things and have no choice but to sit and watch the next generation run past me.

So I decided I was going to make an iOS game but why this one? Actually, I didn’t decide on this one first. At the beginning of the year, I was working freelance 4 days a week and left 1 day for me to do my indie thing. I started working on an asynchronous turn-based strategy game. It started out every RTS-like. Well, it started out with lots of real time fun but not so much strategy. The more strategic it got, the more I felt like I was programming menus and not learning anything about touch-based game controls.

So, I thought of a game that I loved playing when I was a kid. It was called Crossfire and you shot little ball bearings to knock these plastic pucks into the opposing goal. So I spent a day trying to do a quick prototype of a 4 player version. After about 5 or 6 hours, it was infinitely more fun to play than the other game I had been working on. So, I kept going at it.

I’ve since become full time on Mind Candy’s mobile team so it’s just been an hour here and an hour there. I’ve probably put somewhere around 100 hours into putting it together, but that doesn’t include the time I spent building the engine with Luke on the train to and from Molecule many years ago. For the most part, I’ve made this game alone, but I’ve had lots of help. The sound design was done by a friend. I’ll ask if I’m allowed to name him. I’ve gotten loads of great feedback from friends, especially @MikeBithell, @Rovient, @luke_duke, and the @makielab crew.

I’m pretty happy with it. It definitely did what I wanted it to do, which was to get me acquainted with touch controls and learn more about game design in general. I wanted to make something simple enough that you could get into it in a matter of seconds, but with enough twists and turns along the way that you just might play long enough that you’d tell a friend about it.

So, all-in-all, it’s been a great experience so far. I’m really excited to announce it today and see if I can get anyone interested in talking to me about it. If you’re a human or an adorable animal who would like to chat to me about this game or anything else, get in touch at press@mugathur.com.

GDC Left Behind

NOTE: Tuesday Venue Moved To Guildford
NOTE: Friday Venue Moved To The Book Club

GDC is almost here! Hordes of badge-donning game developers will arise from their caves and take over the streets of San Francisco. I, however, have not been let out of my cage and am stuck back here in London. There’s no reason that those of us who have been left behind can’t have a great time as well. I’d like to propose the second annual GDC Left Behind. This year, I’m choosing a venue for each night of the week where game developers can congregate and inspire each other in this crazy world of games we live in. Here’s a first pass of venues and themes. The themes are just random and feel free to come even if you have no interest in the theme of the night. I was thinking about 7ish each night, but show up when you want and just look for beards and pony tails.

Monday (March 5th)
The Crown in Angel
Let’s join #LondonIndies at the Crown in Angel. This is a monthly meetup on the first Monday of each month. Come talk games with some of the best and the brightest of the UK’s indie scene.

Tuesday (March 6th)
Upstairs at The Three Pigeons in Guildford
Come upstairs and join @wiggo and the rest of the Guildfordish games scene at the Three Pigeons. Jump into yet another argument about new versus old: whether the 3DS and the Vita have a place in a smart phone world, whether Next Gen is already dead in the water.

Wednesday (March 7th)
Old King’s Head in Hoxton
Come talk real world games at Old King’s Head in Hoxton. Just across the street in the Makielab offices, you might be able to get a glimpse of the 3d printing mayhem as well as some awesome board game madness as part of their monthly Wizard Wednesdays. Who knows what you might find–a overly aggressive game of Catan or a fully costumed LARPing session in progress.

Thursday (March 8th)
Tram Depot in Cambridge
@docky will be hosting this event. Meet up to talk experimental games, game jams, and making stuff just because it’s awesome. Bring a laptop along and get some competitive Hexagon action going. Or sit down and just start building something with a beer or two for inspiration.

Friday (March 9th)
The Book Club
Anything goes. It’s Friday and you’ve had a long week while everyone else has been off bathing in the beautiful California sun. Drop by and relax, reminiscing on the wonderful week we’ve had at GDC Left Behind.

If you have any recommendations for better venues, especially venues that’ll be less busy, let me know and we’ll see if we can swap some out. If you have better ideas for themes or think I should just shut up and drop the themes let me know. If you’d like to move any of the nights out of East London, that’d be pretty awesome too. Anyway, if you have any suggestions or ideas or anything like that, drop me a line.

See You, Space Cowboy

Bit of a Game Jam: Quadruple Town

This weekend, I participated in Bit of a Game Jam at London South Bank University. I’d never done a game jam before and I thought it’d be a good idea to get into the indie spirit. The theme that was drawn on the first day was “Clouds / Fractals / Vengeance.” I wasn’t entirely sure what that meant. Was it one theme of all three? Was it to pick one of those themes? We decided to go with fractals.

First and foremost, we had no artists. We had two options: try to make art by ourselves or steal from the internet. We decided to go with the second option. We downloaded all of Dan Cook’s art sets and just picked out what we could use. We immediately decided to do the game in flash. More precisely, Luke wanted to do HTML5, but I just wasn’t having any of it. Given the decision to go with Flash, we decided to use the Small World set since it was a Flash asset.

Initially, we tried to get something up and running quickly with Flex, embedding the swf using the [Embed] tag. Normally, we’d have asset loaders and libraries and all that kind of thing, but it was important to me that for the game jam, if we ended up making something decent, which we didn’t (SPOILER), that people could just download the swf and play it without having to worry about external dependencies and internet connectivity.

However, we quickly ran into an issue with [Embed] and getDefinitionByName. We wasted about 3 hours on this issue and eventually, I moved from having a single embedded swf as a library to lots of different swfs that I didn’t need to load symbols from. In the mean time, Luke implemented a working version with file loading and applicationDomain.getDefinition. As far as I was concerned, both solutions were terrible. At this point, I decided that we should just move from Flex to Flash.

So once we made that switch, half of the first day wasted, things were a lot more smooth sailing. I implemented a “fractal” zoom. What was going to be the centerpiece of our game would be the fact that inside the church at the middle of the screen was a smaller version of the whole island. So if you load up the game and click the church, you’ll see a small version of the island, Cloud Island. See what we did there? Two of three theme elements worked in! Also, if you click on the blue background, it’ll zoom the opposite way.

The math for this is pretty simple. The island is two layers, the background and the church. When a zoom occurs, I just add another instance of the island between the two layers, scale everything and fade the parts that are disappearing. At first, there was completely different code for zooming in versus zooming out, but after I got it working, it was pretty clear that it was just the same effect, but backwards, so I combined the code for the two.

The only hiccup we ran into with this was that these assets are relatively complex and scaling them up to be huge was causing havoc on performance. Specifically, when zooming in or out, we’d drop down to about 2 frames per second. We didn’t even have any of the tiles in at that point. It was just background and church. So I implemented a function that takes a movieclip and makes a bitmap version of it. This solved all the performance problems, but then we ran into collision issues. Bitmap collision is by the block, not pixel collision. Usually what I would do at this point is to use InteractivePNG, a library by MosesSupposes. This time, though, I decided against it. I had a hunch that I would need to rely on proper hit detection rather than event fiddling at some point, so I implemented something strange. For each movieclip, I’d generate a bitmap version. However, I’d also create a movieclip version and line them up. Then I’d add them both to a sprite and set the movieclip version to the sprite’s hitArea and hide it. This way, I got the rendering performance of the bitmap, but the hit detection of the vector version. It was a horrendous implementation due to overkill, but it got all the functionality I needed at the time.

This was about the end of the first day.

We didn’t know exactly what we were going to do for gameplay. We were thinking of doing something like Maquette where you needed to solve an issue on one level by doing something on another level. We never got there. Luke had the idea of doing a matching puzzle game. He told me at the end of day that he hadn’t realized that Dan Cook, from whom we borrowed the art, was the same person who made Triple Town. It just so happened that they used some of the same assets. Ha ha. Anyway, I gave it a little thought and I started coming up with a rule set for our game.

The thing that kept coming back to me was that I liked the idea of matching 4 pieces and it creating a piece that was the size of 4 pieces. It would add a bit to our fractal theme and create some gameplay that matched. The down side of creating a piece of equal size when matching pieces is that you never remove pieces from the board. So you can’t get the feel that you get with games like Tetris where you need to get rid of pieces before it all fills up. Given this constraint, I decided it would be a space management game. We would cram you in and force you to sort the map out with the limited spaces that you had. The extra catch was that if you wanted some more space, you could shrink pieces by picking up a piece and moving it into the church. So there ended up being 4 rules for what I ended up naming Quadruple Town.

1. Four matching objects in a square make a bigger object (Bush -> Tree -> House -> Gold)
2. Tiles can be shrunk, but not grown
3. Each tile can only be moved once
4. 1 point for each tile with Gold

I thought, although it was pretty broken as a game design and as a game implementation, it had some interesting ideas. I like the idea that shrinking pieces gives you more space, but drops the theoretical high score you can get. I like the idea that matching 4 tiles makes an object that cannot be matched with another of those tiles in either type or size. I like the idea that early mistakes can come back to haunt you terribly. VENGEANCE! THREE THEME ACHIEVEMENT!

So the second day we hacked things in bit by bit. I think we had implemented rule 1 by the time we had 1 hour left. It took us about 30 minutes to add rule 4. We took another 20 minutes to add rule 2 and I snuck rule 3 in at the very last second.

Other than the obvious bugs, there’s a lot that I would have done differently if I were to do it again. Firstly, I wouldn’t have wasted so much time trying to get Flex to work. I didn’t even have a working version of Flex anyway. I had Flex 3, but that broke when I installed Lion. We were using some ruby gem that compiled mxml files.

I definitely wouldn’t have made the island a cloud shape. It makes the gameplay unpredictable an infuriating. It also meant I had to write a goofy algorithm to determine what were valid tile positions. Oh yeah, I forgot to mention that. It was lucky that I decided to implement that bizarre version of bitmapping because it let me implement a raycast system to determine what were valid tiles and what weren’t.

All in all, though, I had a lot of fun and I’ve got this little swf to play around with. I think Luke and I have both committed bug fixes after the game jam. I think one commit each, but that’s more than I would have expected. Anyway. It was fun and I’d probably be interested in doing another game jam in the future.

Oh yeah, you can play the game here:http://quadruple-t.heroku.com/

And here’s the full source: https://github.com/lpetre/quadruple-t/

PS: Some snarky comment about how Quadruple Town is terrible, but still more original than Yeti Town. =)

RIP Mismatch – The Fear of Being Unoriginal

Back in 2009, when I was still at Media Molecule, I started putting an eye towards mobile games. Each day on my train ride to and from Guildford, I’d work on a codebase that Luke and I had thrown together. The codebase was called FTG which either stood for Free Time Games or Fuck That Guy depending our our mood towards the world at any given point in time. We were writing random code for random experiments–mostly poker related experiments. Somewhere in that code graveyards is probably still a ridiculously fast poker hand simulator. Anyway, at some point, I started working on a game I called Mismatch. At first it was for PC and Mac (since I used a PC and Luke used a Mac), but was soon primarily developed for my iOS.

I still have fond memories of the birth of Mismatch. I’d had moved to London a little over than 2 years before and was living in Lewisham. When I moved from LA, all anyone ever said to me was that I should prepare for the extreme cold, which I had yet to experience. However, this morning, when I woke stepped outside of my flat, there was a layer of snow a foot thick on the floor. Having lived in LA all my life, that was a lot of snow. Obviously by any reasonable standard, it was a light sprinkling. Anyway, by London transport standards, it was a catastrophe. All trains were heavily delayed or cancelled and I had an hour and a half journey on a good day. Being the workaholic that I was, though, I really couldn’t fathom what I would do if I didn’t go to work. So I set off on my journey and got stranded at Canary Wharf when my girlfriend called me to say Siobhan had emailed everyone to say stay home. I went back home and was at a loss for what to do. Without a PS3 devkit, I was pretty much useless to Media Molecule. I decided to play SET with my girlfriend and watch news about the snow–such an exciting live I lead. It wasn’t long before something struck me. SET (http://http://setgame.com/) would make an amazing rule set for a puzzle game. Match 3 games were all the rage at the time and I thought why not make a MIS-match 3 game. So that day, in about 4 hours, I coded up the first version of Mismatch.

It was a push-pull puzzle game inspired by SET and Money Puzzle Exchanger where you tried to rearrange the board such that 3 tiles in a row were either all the same or all different for each attribute (color and shape) like the rules in SET. In the end the SET rules were an interesting differentiator, but as I knew from playing SET with many different people, some people are just magic at it (Jake Sones) and some people constantly need it explained to them why something is not a set. The part that I got really obsessed with was the push-pull mechanic. I worked in an arcade called Nickel! Nickel! for the last two years of high school and my favorite game by far was Money Puzzle Exchanger on the Neo Geo machine. I was so used to the dropping tiles of Tetris or the swapping tiles of Bejeweled that push-pull felt like a magical balance between the two. Dropping tiles makes making major changes easy but leaves you at the whim of the random number generator while swapping tiles makes the board feel like a set of tools but makes it near difficult to make any substantial change. Push-pull is an amazing mechanic because it leverages the board as a tool set, but still enables fast and massive changes.

I kept plugging along on Mismatch for my 34 minute train journeys from Waterloo to Guildford and from Guildford to Waterloo every day and worked on polishing mechanics, adding combos, improving the touch controls, and so on and so forth, until one day, when I just stopped working on it to never touch the code again. This isn’t an uncommon occurrence. We didn’t finish any of our poker experiments. Side projects get dropped all the time. Something new and shiny comes up or live gets in the way. It’s just how it goes with doing things in your spare time (or even sometimes in your professional life). However, there was a very particular reason that I stopped working on Mismatch and I don’t know if this happens to everyone or if it just happens to me all the time. The reason was Critter Crunch by Capybara. I saw a trailer for Critter Crunch on PSN and my jaw dropped. It was absolutely gorgeous and playful and all sorts of other wonderful things. When I obsessively searched the internet for anything I could find about Biggs and friends, I discovered that there was an iOS version that had come out many moons ago. I download it immediately and was blown away. It played just as amazingly as it looked, if not better. I felt like I wasn’t ever going to make Mismatch anything that could ever compare to Critter Crunch. I’d be serving the world better if I just released what I had, but when you tapped the start button a message would pop up saying, “If you thought you were going to like this, you should go buy Critter Crunch.”

This happens to me all the time. I was really excited about making a reverse tower defense game until I played Anomaly. It even happens to me when I’m considering blogging something or even just tweeting something. I think to myself, “Do I know enough about the subject matter to produce something that would justify the amount of time it would take someone to read it?” And more often then not, I come back with the answer no. I often see people putting stuff out there and think “Really? Why did you bother?” And then I realize what an idiot I’m being. People bother because those who don’t try never win. Those who just stand on the sidelines and silently judge may be so lucky to earn themselves delusions of superiority, but at the end of the day, the world is changed by people who do things.

I started writing this blog post because I started playing Hero Academy today. It has a lot of similarities with the game I’m currently working on. I know it’s not the first and I know it won’t be the last, but it’s the one that that made me wonder if I could make something worthy of competing. I refuse to walk away from it this time, though. If you run into me and I’m no longer working on a multiplayer turn-based strategy game, it better be because I made it and it was terrible rather than I gave up because I played something I oughtn’t bother. That’s the whole point of working in a creative industry. We are here because we don’t want to be doing the same thing every day. We want to be constantly challenged and inspired.

Obviously, creative integrity is extremely important to me–too much so in fact. We live in a world where some people don’t think twice before brutally and shamelessly cloning the last big thing. And while it’s frustrating to operate along side such creatively and morally bankrupt people, we cannot throw the baby out with the bathwater. We can’t let our fear of being unoriginal prevent us from moving forward. We’ve got to point a keen eye forward without being ashamed of where we’ve come from. We cannot underestimate the power of iteration and incremental progress. We cannot ignore the value of something new no matter how much baggage it comes along with. If everyone was afraid of taking the smaller steps, we never would have made it from Pong to Pac-Man, Mario to Metroid, or Sam & Max to Sworcery.

How you would like to see the video game industry change?

I was messing around with Quora and answered the question in the title and thought I’d post it here as a different version of my previous post.

There are two ways that I wish the games industry from change, one from the perspective of an older consumer and another from the perspective of a frustrated developer.

As a consumer, I’ve found that as I’ve gotten older, I’ve begun to play less and less games.  I simply don’t have 20 hours to invest playing a single game if the experience at the twentieth hour doesn’t change dramatically from the experience of the first hour.  I still find myself completely enthralled by games like Mario Galaxy because they present perpetual cycles of clearly redefining the ruleset of the gameplay.  However, many new games that I purchase and try out define a single gameplay mechanic and simply add 20 hours of content to justify my $60 investment.  Even worse, because of the risk aversion brought on by high development costs, some games provide 20 hours of content without even introducing one single new game mechanic.

As much as I’d hope every game studio could create masterpieces like Mario Galaxy, I think it’s more realistic to hope that the economics will make sense for game developers to find a way to create an experience that matches the strength of the mechanics behind it.  Much like popcorn action films are usually an hour and a half while epics like Lord of the Rings span over eleven hours, I would hope that video game creators could find ways to find the right means and amount of expression for gameplay mechanics of various depths.

This leads directly into the change I’d like to see as a developer.  I am greatly encouraged by the massive growth of gaming lately through party games, mobile games, and social games.  My hope is that as all of these different platforms, interaction methods, and distribution channels allow for a much wider range of games to be viable to develop, but furthermore for the momentum of these types of advancements to accelerate.  I think we’re only at the infancy of the potential for games as a medium and I think it’s about time we see it starting to mature.  I hope that in my career as a game developer I’ll go from “making games for gamers” to “making games for people.”