“Your Game is Way Too Hard!”

June 24, 2011 by Devin Reimer

“Your Game is Way Too Hard!” This was something I found myself saying quite a bit during the So Many Rooms Game Jam.

To start, this post is not a knock against anyone that submitted rooms to So Many Rooms. I was very impressed with the quality and variety of games submitted. This just alerted me to a widespread trap new game developers often fall into. Making their games way too hard.

So why do game developers make their games too hard/too difficult? I believe it is a bunch of different factors:

  1. Looking more at games of the past than games of the present (older games were harder).
  2. The thought that difficultly is what makes a good game.
  3. Try to extend the length of a game by making it harder.
  4. Thinking you can tell how hard/difficult your own game is.

The problems with those points:

  1. Games of the past were generally harder because of tech limitations, monetization and fewer good examples not because they were magically better. Also we sometimes look at those games with rose-colored glasses.
  2. Difficultly in general has little to do with being a good game. I will argue in most cases making your game easier will make it better.
  3. This is partly true, the harder you make your game the longer it would take a ‘person’ to beat it. The problem is in reality people rarely beat games and making a game longer doesn’t make it better.
  4. Game developers NEVER know how hard their own games are without first watching someone else play it. You built the game and have played it thousands of times. You are a master, not an average player.

So Many Rooms was an interesting project because the goal of each room was to be short so that the player could move on to the next room. Unfortunately I didn’t drive this point home hard enough, which caused most people to make rooms that were long and hard to beat.

Some stats from So Many Rooms:

Number of Unique Players: 14,353
Rooms Started: 103,308 (take with a grain of salt as users might have seen but not played the room)
Rooms Completed: 8,868

The most important take away from these stats is that the maximum percentage of people that could have beat a single room is 62%. That is the maximum as there are lots of players (myself included) that beat a lot more than one room.

Breakdown Per Room of Number of Times Completed (each room was played roughly same amount of times)

Back From a Cleaning 788
the BeBop Room 525
How The World Ends 453
Fly and Shoot 424
Are you satisfied? 388
Brownian Motion 365
Golden Man 2 363
Roomtroid 338
Golden Boy vs Lasers 337
You are not dreaming, messenger 335
Find the Wheat to Leave 292
Enigma of a Night 290
Strike! – The Bonus Round 287
Golden Space Opera 233
Heliphant Flight 232
Creepy Complex 222
Weather Breaker 212
Brocken 205
Ditto Lake 192
The Italian Room 188
Anything but Zombie LOLcats 187
Mercury’s Hell 177
In the Streets 173
Lava Temple 171
Hall of Contradictions 153
My Deer Golfy 146
Briciola Rooom 134
Crawl Of Shame 131
Bovine Climb 126
Pixel Flight 117
Parasite 97
Gem Of Flying Wonders 96
Ghost Golden Boy 84
Gauntletkaruga 81
Box of God 73
Space Shooter Room 71
The Ascent 63
A Walk In The Park 54
Black Out 38
Sunless 8

So while I’m not saying beating a game is a requirement for a game being good (it’s not). What I want to explain is making a hard game good is more challenging that making an easy game good. On top of that the harder your game is the less accessible it will be. So if you are new to game development make it easier on yourself, make an “easy” game.

Two of my favorite hard indie games of recent memory are Trials HD and Super Meat Boy. Both games are insanely difficult. The difference between the two is that I think Trial HD was too hard. Game reviews agree with me. So I would argue the worst thing about that game was its difficult. Which means if they would have made it a bit easier it would have been a better game.

Now Super Meat Boy was hard….very hard. The difference came down to tuning, making it just challenging enough to keep you moving on without having you rage quit. This is a very rare quality and very hard to do.  Team Meat wrote a great article on how they did this.

Even in the case of Super Meat Boy I’m certain I wouldn’t have liked the game less had the difficulty been dialed back a little bit. I did beat the Dark World, which I feel is an accomplishment, but had it been a bit easier, I’m certain I would not feel less accomplished.

In the Super Meat Boy article above they give a simple formula for determining what the difficultly of a game is:

(% chance the player will die) X (Penalty for dying) = Difficulty?

This is a great formula. The problem with it, is that while the penalty for dying is easy for a game developer to see, the % chance the player will die is not easily determined.

The problem with judging games difficult from the game developer’s perspective is during the process of building a game you end up playing it a lot. This makes you way better than anyone playing your game for the first time.

A quick rule of thumb as a new game developer if you are playing your own game and find it challenging your game is already way, way too hard. The best way to test this is to give the game to someone that hasn’t seen it before and is part of your target demographic. Just watch them play it and don’t speak. It is very important that you don’t speak, as the moment you do you have invalidated the test. In the real world you won’t be next to each player playing the game. If you become uncomfortable watching some struggle with your game you have something you need to fix. Once you made some fixes do not give the game back to the same person. You must find a new person(s) and test again. You are doing a great disservice to yourself and users if you do not go through this process before you release a game.

A must read presentation by Jason Kapalka(Popcap Games) titled: “10 ways to make a bad casual game” – The number one item is about making your game too hard. An important quote: “No casual game has ever failed for being too easy.” I think you could remove the word ‘casual’ and minus a few exceptions it would hold true.

It is easier to make a good game that is easy, than it is to make a good game that is hard game. Being a new game developer, people will be playing your games for entertainment and there is nothing entertaining about quitting a game out of frustration over difficulty.

Going forward I’m going to try to do a better job conveying this message to people new to game development.

Making a game not ‘Too Hard’ is sometimes not easy to do. I’m currently struggling with this very problem on my current game, which means I have a lot of user playtesting and tuning left to do.

I would love to see people’s opinions on this article, please leave some comments below.

So Many Rooms – Idea Through Execution

February 11, 2011 by Devin Reimer

I thought it might be interesting to talk about ‘So Many Rooms’ and how it moved from idea to final product. If you don’t yet know about ‘So Many Rooms’, please read my previous post and visit

The idea for ‘So Many Rooms’ started in an interesting place. I was doing some prototyping for a first person puzzle game based on time travel. It was based on trying to solve a puzzle by playing different characters at the same time in different rooms. To make it work there was the ability to scrub back and forth through time.

I built a very simple 3D room in Unity with a red button that when pressed opened the next door.

Pre-‘So Many Rooms’ Unity Prototype
(With every failure, success could be around the corner)

It didn’t take much prototyping before I realized the idea was just too complicated and the final product wouldn’t be much fun. So like most ideas that fail, my next step was to see if there was anyway to evolve this idea into something that could be good.

My thoughts move to an idea of having a first person puzzle game where each room had a puzzle to solve before moving to the next. The twist would be a different indie game developers would build each room. I figured this idea had potential but trying to convince a bunch of indie game developers to part with their precious time for an unproven idea would be almost impossible. So the idea moved to the back of my mind where it sat and waited.

A few months later I was at the Winnitron Jam when the idea moved back to the front of my mind. What if instead of trying to convince each indie game developer to build a room, there was game jam based on the idea. That way people know it’s a serious idea and it only takes 2 days of one’s time.

Winnitron Jam
Look closely and you can almost see the idea in my mind(top left) taking shape.
via – Winnipeg Free Press –

After the jam I got to work building a system that would allow different game developers to build rooms independently, but still allow for them to be seamlessly strung together. I completed a very basic prototype but still thought it would be hard to convince people to do. So once again to the back of my mind the idea went.

About a month and a half later I was attending the New Media Manitoba and GDC Anniversary Party and was having a conversation with Alec Holowka. I decided to bounce the idea off of him. His response was a lot more positive than I was expecting. After our talk he was grabbing people, bring them over to me and saying, “tell them what you just told me”. After repeating myself a lot, I realized this might actually be able to turn into something. The wheels were finally in motion and it once again proved the coolest stuff starts over a couple of drinks.

Immediately following this conversation we began brainstorming on how this was going to work. I then started work on a more robust system for loading and displaying each room.

The First Version of the Room Jam Banner

At this time I convinced my friend Kevin Evans to build a back-end system to support this crazy idea. The back-end would be able to add new developers and rooms, record user’s actions and select random and new rooms for each user.

I originally thought the hard part would be convincing people to do this. As it turned out the hard part was actually building a system to support this idea in the short period of time we had.

My original prototype used Javascript to load swf and unity files dynamically. This ended up being problematic. It had three major issues (setting focus, performance and load times). For the sake of simplicity we opted to make it this a Flash only game. My goal was to build a Flash piece that would load in each random room dynamically. While this on the surface sounded like the easiest and most logical course of action, it ended up being a very bad idea.

Prior to this I was fully aware that the garbage collector in Flash was less than…perfect. I had fought with it in the past, but at the end of the day I had always won. I thought as long as I set out guidelines on how to clear up your room when it was done, everything would work well. To help with this I also wrote custom version of Flixel and FlashPunk.

While the loader itself took some time to build I got it done with two weeks to spare. Everything looked good, but then I put it through a more ‘real world’ stress test. I loaded two almost completed rooms in a continuous loop. Even with my optimizations I watched as the RAM and CPU usage climbed, until everything locked up.

For those that don’t know, in Flash when you load an external SWF, it becomes a part of the Flash piece that loaded it. It is not run in a new instance of the Flash Player or in isolated player sandbox. From a memory standpoint there is no way isolate what is loaded. That means if the loaded piece has problems everything has problems.

I then came to the harsh realization that, if a skilled Flash developer like myself was having trouble optimizing a room for the garbage collector. A novice developer didn’t stand a chance. So I made the decision to scrap this version and go back to the drawing board.

I ended up taking the best ideas from both world and built a hybrid Flash/Javascript loader. A Flash piece would be used to load an individual room and deal with communication, GUI, etc. Javascript would be used to load a new Flash piece for each room.

Around the same time Noel Berry and myself prepared a Flash in the Peg (Winnipeg’s Adobe User Group) meeting tailored specifically for the jam. It’s focused was on game development using Flixel and FlashPunk. The meeting was very successful and drew a bunch of new people.

With the Flash in the Peg meeting behind me, I started back into working on the new room loading system. I ended up not really sleeping for the week leading up to the jam as was I frantically working to get everything done. Luckily there was a lot of people helping out. Kert Gartner organized the jam space, Alec Holowka with planning the jam, Noel Berry built the site, etc. A full list of credits can be seen here.

While everything was close to working before the jam, I had never had it all working together. The first day of the jam was very stressful for me as here was all these people (at the jam and around the world) working on rooms for a system that didn’t yet work.

Room Jam In Progress - via Kert Gartner -

Finally the moment came near the end of the first day where the system came to life.

I was expecting a bunch of rooms to be build at the jam and maybe a couple from different places in the world. What I was not prepared for was the shear number of people from all over the world building rooms. While a lot of people had signed up, there is a big difference between signing up and actually putting in all the work required to build a room.

The realization came at around 7:00pm on the last day of the jam. My inbox started to fill up with room submissions from different people all around the world. I was working as fast as I could to get rooms tested and up on the site. I worked all night with only a little nap and was only able finished the initial batch of rooms for our 1:00pm launch.

Currently we have 40 rooms on the site built by 60+ people. For a brand new idea I think this is very cool.

The response has been very positive and the traffic has been pretty good with over 50,000 games being played as of writing this.

Here’s short list of So Many Rooms writeups and videos from around the world: [2:55 min mark]

It was so cool to see my idea move so rapidly to becoming reality.

What’s next for So Many Rooms? Building a custom version for the Winnitron 1000 is currently on my to do list, but other than that I haven’t decided. I do have some interesting ideas, so we will see. That said don’t expect anything in the near term as I do have to wait long enough to forget about how much work this actually was to pull off.

Thanks to everyone that participated.

Now go play some rooms!

So Many Rooms – Room Jam

January 28, 2011 by Devin Reimer

Update: So Many Rooms is now live. 30 rooms and counting. Go play some rooms.

Tomorrow (Jan 29,2010) is the first day of “Room Jam“, Winnipeg’s next game development jam.

What is a “game jam”? It’s an event were game developers get together and build games over the course of a couple of days.

So what is “Room Jam“? It’s an idea I came up with a few months ago. Everyone builds their own ‘room’ containing its own gameplay, art style, etc. We then put them all together into one large seamless crazy awesome game. Players would then progress from one random room to the next. We call it: “So Many Rooms“.

So you have some idea, here are some of Winnipeg’s previous jams:

The great part is that you don’t have to live here to participate, people will be working and submitting room from all over the world. There is still time to signup and build your own room, visit for details.

Update: New blog post available: So Many Rooms – Idea Through Execution