Boo Urns Source Code

Hello again! I’ve released the source code to Boo Urns, the game I worked on for the Global Game Jam. The game is a multiplayer game made in Unity and I’ve gone through and commented every class. You can get a sense for how I structure my scenes/prefabs to be able to re-use code. You can download the source code here.

Boo Urns! Made in Just Over 48 Hours

Play it here!

I’m REALLY late with posting my Global Game Jam 2013 game. The reason is, we didn’t finish it on time! After being so disappointed with not having anything to show, Doug and I decided to take some time and finish the product to playable form. The results are actually quite good and I’m quite happy with it. The game is called “Boo Urns”. It is a four person multiplayer game where you play as either Enrico or a Ghost. Enrico tries to find a key and escape the house. The ghosts attempt to kill Enrico by touching him. The twist is that when Enrico looks at a ghost, they must cover their eyes and cannot move like the iconic “Boo” characters in Super Mario Bros 3. You can simulate this by pressing ‘space’ when playing on a computer, but the real draw was using experimental “eye tracking” software to enforce this rule on iOS. This idea was ambitious… too ambitious and what follows is a post-mortem of our game.

What Went Right

1. The Idea

This idea was my first idea for the game jam and my group fell in love with it. We were initially going to just work together (the five of us), but I was the sole programmer and knew it was beyond my capabilities in 48 hours. I went up and pitched the idea in front of the attendees to try and recruit more programmers. It turns out people loved this idea, and we ended up with the largest team at the jam, 12 people all-told.

2. All-Star Artists

I went into the game jam with Doug Insley (my tech artist at Coding Jar Studios), Ahram Lee (who helped us on Angry Atoms), and another friend. Craig Slagel from Leaping Coyote Interactive and Jesse from Blatant Studios joined our group early. After the pitch, we were able to attract more talented artists and programmers. Even though the product was not done in 48 hours, the majority of the art was (but not optimized — Doug has spent this week optimizing it and texturing his own art). Around 80% of the art you see in the final product was made within the 48 hours by the artists.

Craig enforced the idea of creating the gray-box in Maya, splitting up the rooms to the artists, and filling it in. This allowed us to simply copy + paste the final art into the level, because all of the initial sizing and gray-boxing was completed in the first few hours.

Throughout this week, Doug was able to get our game, initially at 180 draw calls, down to under 60 — perfectly reasonable for any mobile device. The optimizations were mostly ensuring meshes would draw in batches. You can achieve this by utilizing the same materials for as many objects in your scene as possible. The trick to doing this is to combine all of the art’s textures into a single texture (called an atlas), then you re-assign the UVs of the unique objects to use the atlas.

3. Unity

Without Unity, there is no way we would have had a 3d game at the end of 48 hours. The amount of features that went into this game are so complex it would be impossible to write from scratch. The idea also hinged on a third party native iOS library, with which I don’t think any other off-the-shelf engine could support so elegantly.

4. Asset Server

Usually the Unity Asset Server is a source of headaches and widely avoided. However, we installed it and used it to avoid teaching everyone Subversion or another Version Control System. It turns out, Unity Asset Server has improved significantly and we ran into only one issue our entire time. We’ve continued using it the whole week without issue. This saved us at least 30-60 minutes of training time and dealing with .meta file issues.

What Went Wrong

1. Experimental Eye Tracking SDK

Kimberly Voll, the organizer of the Vancouver Global Game Jam had been contacted about supplying an experimental eye tracking SDK to use at our location. Craig and I had initially met at a previous game jam where we used OpenCV to create an augmented reality game in Unity. The allure of doing something this novel and crazy again was too much, and we really wanted to top that effort. Unfortunately this ended up being our downfall.

We had high hopes for the experimental eye tracking SDK. Initially we envisioned the game being playable by following your gaze, allowing almost anyone to play the game and qualifying us for the accessibility diversifier. Unfortunately, the eye tracking SDK just gave us the position of the player’s eyes in screen-space, a far cry from what we had hoped. Also disappointing was the fact that the eye tracking was for iOS-only, locking us into a specific platform for the jam. The problem with releasing on iOS for a game jam is someone must be set-up and know how to do provisioning. Since I had experience with this, I took on the task of getting the SDK to work, integrating it in our project, and building to iOS, and distributing via TestFlight (link).

The eye-tracking SDK is still in development and not quite ready for prime time. Having it compile & link properly with Unity was quite an ordeal and took at least twice as long as I had anticipated. Since I was doing this task, we fell too far behind in the game play and multiplayer features, and never quite recovered in time to release the game within the 48 hours. I had been primarily testing it with my face (makes sense, right?) where it works around 90% of the time, and having your movement stop is more an annoyance that you might be willing to put up with for the novelty of the experience. However, once we got it working, and had others test it out, we realized it doesn’t work for people with glasses. Unfortunately, it seems like a lot of people wear glasses… I never really noticed how many people wear glasses until they’re swearing at my game :) .

Lesson learned: never try untested, experimental software in a game jam.

2. Unity Multiplayer

Jason made a great effort getting the game working with Unity’s multiplayer. One of the biggest issues we had was the network at Vancouver GGJ location would decide to block certain UDP traffic at different times. This had given us some false hope that multiplayer would work, but it soon failed when we tried to connect more than two computers together. After hours of debugging, Jason finally determined it was the network itself, not the code. We verified this by creating our own ad-hoc network which magically solved our connectivity issues.

Unfortunately, that was not the only issue. The movement code did it not quite work when we switched the input method from keyboard to virtual iOS joystick. It was this error that ultimately did us in; without working multiplayer we had nothing to demo.

When the game jam was over, I started re-writing the game from scratch “properly”. I should note now that I’ve done a lot of multiplayer code, so this should have been a cakewalk. Unfortunately, it was note and I had a terrible time getting multiplayer to work. It turns out, Unity has no such support for server-authoritative multiplayer. Any client can spawn or destroy objects at any time and the server cannot disallow such actions! This makes doing any server-authority movement code purely academic, the Unity networking base is inherently insecure. The final solution was to give up on attempting any sort of security and assuming the client was playing nicely. Throughout my research on the topic, it appears there is only one viable solution for Unity developers who want to implement multiplayer without rewriting Unity’s physics functionality; it is called uLink. It is quite expensive to use in a commercial product and screams the need for either improved networking support from Unity, or competition in the Unity multiplayer middleware space.

I should also note that this would have been a breeze to do in UDK which has exceptional support for writing custom multiplayer code. It’s not EASY to write it, but you can do everything that is needed in a game like this.

Lesson learned: Stay away from multiplayer code in Unity. If you need to write multiplayer code, use a third party plug-in.

3. Team Size

While I really enjoyed people joining our team and showing their support for my pitched idea, our team ended up being too large. Dividing up the tasks proved to be very difficult and in a small game like this where everything takes place in a single scene, it’s really hard not to interfere with each others’ work. Worse, there were a couple of teammates that felt they could not contribute as much as they wanted to, so they ended up leaving the team. A team of this size needed someone to lead, guide, and manage the project but I was spending my time solving technical issues so was unable to be that person. I really need to think about my role in the next game jam, or scope down so I can cover a lead role as well as technical.

Lesson learned: Team size can be a detriment to your project. Five or under seems to be the magic number.

Conclusion

While we didn’t finish with the 48 hours, I was really happy about how this project turned out. This is the one game I’ve made at a game jam where I could keep playing it and still enjoy it. I challenged myself and learned some new things, and really there’s not much more you can hope for at a game jam. I hope you learned something as well!

The source code for this game will be made available at the end of this week. This means if you’re looking for some freely available multiplayer example, you’re in luck! Check back here or like us on facebook to keep up to date.

Leave a Comment