Jack Lumber – Steam Launch

April 30, 2013 by Devin Reimer

Jack Lumber is now available on Steam!

Use the supernatural powers of Jack Lumber to massacre the forest and make Granny proud in this time-warping, line-drawing, log-slicing, pun-filled lumberjacking mashup.

Check out the awesome trailer:

Buy it today on Steam:
Also available on iOS:


Office Zombie Simulator in Flash via Unity

December 23, 2011 by Devin Reimer

With the Unity 3.5 developer preview being made available to the public yesterday, I set out to try the new Unity to Flash exporter. I’ve been looking forward to this feature since it was announced almost a year ago. The first project I decided to work on was Office Zombie Simulator, a small game Calin and I build back in February.

The major stumbling block with porting this project to Flash was that it uses iTween. As a lot of people have discovered iTween does not work with the Unity Flash exporter. Yesterday, I spent the day hacking iTween and got it to work with the Flash exporter. Get the modified version of iTween here.

With iTween working, I spent part of the day fixing up a few issues and now Office Zombie Simulator works in Flash. While it’s a little rough around the edges it is simply amazing that I’ve brought something of this complexity from Unity into Flash in just a couple of days.

Without further ado, here is the Flash version of Office Zombie Simulator.

I want to do a huge shout-out to the Unity team, what they have accomplished is incredible. I look forward to what the future brings.

Maze Mover Launch (iPad and PlayBook) – Developed with AIR

September 20, 2011 by Devin Reimer

I’m very excited to announced my first fully featured indie game, Maze Mover has finally launched. It is now available for both iPad and PlayBook.

I’ve been working on this game on and off since December with the help of Calin Reimer.

I developed the first and second prototype of Maze Mover using Flash. When both prototypes were successful I expected I would move onto something different to develop it (either Unity or Corona). But with the progress made with AIR (AIR 2.6 and then AIR 2.7), I decided to give AIR a try.

I couldn’t be happier with the final result. Maze Mover turned out to be the perfect game for AIR. I might do a more detailed article on the development of Maze Mover in the future.

If you  happen to be in the Winnipeg area on Thursday (Sept 22) swing by Demo Camp. Here I will be doing a talk on the development of Maze Mover.

What are you waiting for, get Maze Mover today!
iPad –
PlayBook –
Maze Mover Website and Trailer –

“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.

3D Ball Adventure (JigLibMotionSpringCamera3D) Part 3

February 22, 2009 by Devin Reimer

3D Ball Adventure Version 3 Screenshot

Over the passed week and an half, I went through almost every line of code in this project and rewrote and refactored it. After a bit of work, I discovered the cause of the major camera bug that would cause the camera to freak out when pointed north. This issue is now fixed. The springiness of the camera has also been loosened up a bit, so the camera motion is a lot smoother.

Since I got the new camera system to work, I decided to make it a nice and programmer friendly class called JigLibMotionStringCamera3D. I am aware that this name is terrible and long, but it describes the camera’s function perfectly. The camera uses a JigLibFlash RigidBody object as its target and moves based on its motion not the direction it is facing. Part of the camera’s smooth motion is achieved by extending the SpringCamera3D class. While this camera does have specific job, I know that there are a lot of uses for a camera like this. If you find a cool use for it, drop me a line.

The viewable area of this version has been increased and a little challenge has been added to the end of the level for those who played the last version.

If anyone has created any cool levels using the xml level creator send me an email. I would love to incorporate them in my next version.

To play the demo click here.

To get the source click here.

Note: You will need Papervision3D, JigLibFlash and Tweener to compile the source.

Update: The swf example has been updated to fix an issue when viewed on any page but the main page. Thanks to Chris Hill for pointing this out.

3D Ball Adventure (JigLibFlash, SpringCamera3D, Papervision3D) Mashup Part 2

February 9, 2009 by Devin Reimer

I have been busy over the past week improving the ‘3D Ball Adventure’ game. While the use of the SpringCamera3D in the last version was usable, it did have a problem, it was locked onto to two planes of motion and had no rotation. So I under took the challenge of creating an easy to use 3rd person camera view using SpringCamera3D. I greatly under estimated the challenge of creating a camera system that competently followed the motion of the ball but also gave the user the freedom to make camera corrections. While this version isn’t perfect, it is still pretty cool.

I also have updated the xml level generator with new features like object groups, player start position, standardized objects. Also instead of x,y,z being the center of a box, it is now the top, close, left corner (which is way easier to design for).

To play the demo click here.

To get the source click here.

Note: As before you must have Papervision3D and JibLibFlash to run the source.