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!

3 Responses to "So Many Rooms – Idea Through Execution"

Leave a response