Blog

Office Zombie Simulator on Kongregate

February 20, 2011 by Devin Reimer

I’m happy to announce the release of our new game Office Zombie Simulator. This game was created by Calin Reimer and myself for Kongregate’s Unity Game Contest.

While it is still a work-in-progress I am very happy with how it turned out considering how swamped I was this last month (So Many Rooms and client work).

When I heard the announcement for Kongregate’s Unity Game Contest I was very excited and knew I needed to create something for it. I love game development contests because they have a great feature; a fixed deadline.

The premise of “Office Zombie Simulator” is pretty simple, imagine a few zombie loving nerds are stuck in an office for the weekend. Instead of working they decide to setup the ultimate zombie apocalypse simulator.

The idea for “Office Zombie Simulator” came to me out of necessity.

One problem that we keep running into with developing 3D content is the amount of time and effort required to build all the necessary 3D models. So the idea was if we could reuse more models between projects we would save development time. Since another project we were working on required office equipment I thought if this game could be set in an office, we could hit two birds with one stone.

Other than that the game shouldn’t have any complex 3D models or animations (too time consuming) and needed to be easy to pick up and play.

After a few days of brainstorming, the concept for “Office Zombie Simulator” was born. It turned out to be a very cool concept and is more proof that creativity works best under constraints.

So give it a try, leave feedback and please rate.

http://www.kongregate.com/games/AlmostLogical/office-zombie-simulator

We are hoping enough people will enjoy the game to warrant us building a fully realized version. We have a lot of cool ideas that we would love to implement.

Posted in Announcements, Unity3D | Tagged , | 5 Comments

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 somanyrooms.com.

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 – http://t.co/7h2lo78

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 - http://twitpic.com/3ukloi

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:
http://www.3min.de/video/comedy/ehrensenf/03-02-2011/11/103/5213 [2:55 min mark]
http://www.bytejacker.com/blog/so-many-rooms-a-flash-game-made-out-of-flash-games
http://gamin.ru/blog/selects/5317
http://www.superlevel.de/spiele/so-many-rooms
http://www.stabalarash.com/m2m/index.php?post/2011/01/30/test
http://oujevipo.fr/20-minutes/so-many-rooms
http://chronosign.com/rant/yadurajiv/2011/02/711

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!

Posted in So Many Rooms | Tagged | 3 Comments

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 somanyrooms.com for details.

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

Posted in Announcements, So Many Rooms | Tagged | 3 Comments

PlayModePersist – Unity Asset Store

January 11, 2011 by Devin Reimer

Have you ever wanted to make changes to a component in Unity while in Play mode and have them persist after you click stop? Have you ever accidentally made changes to a component while your game was playing and wish they could be saved?

After a lot of hard work I’m happy to announce ‘PlayModePersist’ is now available in the Unity Asset Store.

This Unity extension allows you to select which components on individual GameObjects you wish to persist and they will save automatically the moment you hit stop. No needed to copy and reapply your changes, no worrying about a “clipboard” being full. You are not limited to saving one component or one GameObject, you can persist as many component from as many GameObject as you would like.
Works with all component with script access including, Transform, Rigidbody, Physics Colliders and Joints, etc. Also supports custom built components. Complete list of supported components.

This feature is currently the #3 most requested editor feature and #10 most requested overall on feedback.unity3d.com.

Best of all it is easy to use, while in Play mode just click the ‘PlayModePersist’ dropdown below the Transform title in the inspector and click the checkboxes for the component you wish to persist. Once you click stop their current state will be persisted.

Please use the comment section below to let me know what you think. Also giving it a rating in the Unity Asset Store would be greatly appreciated.

Note: If you don’t know how to use/access the Unity Asset Store, simply open up Unity, click Window->Unity Asset Store. You can find this item under ‘Extensions’.

Update: New link to PlayModePersist: http://u3d.as/content/almost-logical-software/play-mode-persist/1tS

Special thanks goes out to Kevin Evans for his work that went into this extension.

Posted in Announcements, Unity3D | Tagged , , | 25 Comments

Rigidbody Sleep Toggle – Unity Asset Store

January 6, 2011 by Devin Reimer

I’m happy to announce ‘Rigidbody Sleep Toggle’ is now available in the Unity Asset Store. What is ‘Rigidbody Sleep Toggle’ you ask? It’s an additional toggle (checkbox) called ‘Sleep On Awake’ that is placed at the bottom of the Rigidbody inspector. Clicking this checkbox automatically adds a custom component that makes that Rigidbody sleep at the start of the scene. This is sometimes very important to increase start up performance of your game. If your scene has lots of Rigidbodies they will all be in motion at the start of the game so preventing this can crucial.

While you could add a custom script yourself, this script not only saves time (just selecting/unselecting a checkbox), you can easily tell from within the Rigidbody component if it will be asleep at the start of the scene.

I have also added a menu option under ‘Edit’ that will allow you to in bulk make all Rigidbodies in your scene sleep on awake.

Now onto the best part, it’s now available in the Unity Asset Store for the low, low price of FREE.

Happy New Year Everyone! Please use the comment section below to let me know if you find it useful.

Note: If you don’t know how to use the Unity Asset Store, simply open up Unity, click Window->Unity Asset Store. You can find this item under ‘Extensions’.

Update: New link to Rigidbody Sleep Toggle: http://u3d.as/content/almost-logical-software/rigidbody-sleep-toggle/1tj.
Also I have now launched a new extension called PlayModePersist read about it here.

Posted in Unity3D | Tagged , , | 1 Comment

Unity3D Parachute – Cloth, Joints and Physics

November 2, 2010 by Devin Reimer

When I first received the Unity 3.0 Beta one of the first things I played around with was the new cloth physics. What better way to learn something than to make a tech demo. After some thought I decided on creating a parachute.

One thing I quickly discovered about the new cloth physics within Unity was that it is very heavy (requiring a lot of computing power). That means for the most part cloth physics are slow. So before you go off and try to create a game with lots of physics based cloths you have been warned, it will probably end up being too slow. While cloth does have its uses, they are a little more limited than I had hoped.

My original plan for this demo was to build a parachute using only cloth physics. I ended up having to tweak this a bit for performance reasons. Since in real life a parachute moving downward is fairly rigid so I instead opted to only swap in a physics based cloth once the parachute’s payload touches the ground. The rest of the time I would use a normal mesh renderer. This way I can get the parachute to collapse nicely over the payload but only use the physics aspect for a short period of time.

The parachute’s movement is completely driven by the physic system. A configurable joint is used to attach the Rigidbody of the parachute to the payload (in this case a crate). A physics force is then applied to the parachute based on the maximum amount of lift that parachute is capable of. This way if you increase the mass of the payload the parachute will fall faster and on the flip side a payload of less mass will fall slower.

I ended up leaving the Interactive Cloth’s options pretty much unchanged as changing some of them ended up impacting performance too much. The parachute’s cable are dynamically generated using LineRenderers.

This example is built is such a way that you should easily be able to attach whatever you would like as the parachute’s payload.

To check out the demo click here.

To get the source (unitypackage) click here.

Source Requirements: Unity 3.0

Thanks again to Calin for creating the models.

Posted in Unity3D | Tagged , , | 9 Comments