The Math Behind Vision Cones in Unity 3D

Lately, I've been tinkering with with an early Unity 3D prototype of a top-down action game and I figured I should implement vision cones to add a stealth element to dealing with the enemies. My initial solution was to stick a cube collider in front of enemies to represent their vision.

C# Delegates, Destructors, and Garbage Collection

Just this past week, I've encountered a very specific memory leak in Unity 3D that could happen just generally coding in C# as well. Basically the leak involves subscribing to a delegate in a class' Constructor and then unsubscribing to that delegate in the class's Deconstructor. Here's the gist of what I was trying to do.

public SNController() { FacebookManager.OnLogin += loggedIn; FacebookManager.OnLoginFailed += loginFailed; } ~SNController() { FacebookManager.OnLogin -= loggedIn; FacebookManager.OnLoginFailed -= loginFailed; }

I thought this class -- which did not derive from MonoBehaviour -- would act like MonoBehaviours and call its destructor when a scene was changed. That was not the case at all. When I ran the program, the SNController objects would stick around and the loggedIn and loginFailed functions would be called multiple times as I exited and entered scenes.

It turns out that -- because C# is a managed language -- destructors for objects are called when the objects are cleaned up by the Garbage Collector(GC).

So why didn't the GC destroy the SNController object? The problem was that the GC saw that this object was still subscribed to delegates from the FacebookManager class and would not destroy the object. Therefore, the Destructor would never be called, creating a Catch 22 situation.

I needed to unsubscribe from these delegates explicitly when I was done with the SNController object. To do that, I wrote a Dispose method.

public Dispose() { FacebookManager.OnLogin -= loggedIn; FacebookManager.OnLoginFailed -= loginFailed; }

Since SNController was instantiated as a member of a MonoBehaviour object, I would call SNController's Dispose method in the MonoBehaviour's OnDestroy method. This eliminated any extraneous references from the SNController object at the end of the scene and GC would destroy the object.

Global Game Jam 2011 Post Mortem

Ah, my second Global Game Jam in a row. You can play our game Shadowless here. The theme this year was Extinction and my team decided to make a game about light struggling to fend off darkness. At the end of the day Sunday, we ended up with a half done game that only slightly resembled the original design ambitions. Global Game Jam is about experimentation, and what's experimentation without failure? Sure, half the team was also trying to run the our GGJ location while making the game, but we also made some mistakes in the game's development. Here are a few things I learned this year:

1. Design discussions should only go as far as what you can build now.

During the first night of brainstorming, we discussed too many fancy game ideas. At one point the game involved a traveling beam of light, wading its way through an ever encroaching darkness. When it came time to building these grand ideas we found ourselves empty-handed. We hadn't come up with any basic gameplay to hold any of our original ideas up. Questions like, "What is the player doing from second to second?" and "How is this light beam interacting with this light crystal?" were not answered. In the end, all that time spent talking went to waste and most of the original ideas were thrown out.

On Saturday afternoon we hastily reworked the premise into what the game is now. Inspired by endless survival games like Tilt-to-Live, our game would incorporate the core gameplay of frantically navigating through swarms of enemies while giving the player a primary goal of keeping a light crystal alive at the center of the screen.

2. Remote team members won't get the full experience.

My artist friend Mike wanted to participate in our jam remotely from California. While we were able to give him work, he missed out on all the bleary-eyed fun and final presentations. I could have streamed him in over Skype, but bandwidth was at a premium. Besides, he would've spent most of the time staring at my sleep deprived face.

3. We neglected sound.

I've done this during a smaller Game Jam before. In the thick of programming our heads off, we just couldn't be bothered to take a listen to the sound effects that were just submitted. As a result, we couldn't get revisions to the artist in time. Maybe having a dedicated project manager there to organize everything would have helped but -- in the fast paced Game Jam environment -- I imagine that person would end up sitting around bored a lot.

Gaming is Play. Play is Learning.

At a recent game dev beer night here in Austin, a conversation I was having with my animator friend Jesse stumbled into educational games. Well, it didn't so much stumble itself as much as I steered it. We were talking about our ultimate goals in this industry and I said I wanted to have a positive effect on people beyond entertainment.

I've peeked into the world of productive gaming recently and the potential inspires me. There is movement in education toward virtual classrooms. Game development can be a "gateway-drug" for children to learn complex job skills.

Yet these examples don't involve game design for learning. In terms of games designed to educate the player, my friend countered that educational games just don't work. Exhibit #1: Our shared history in elementary school computer labs solving math problems to cartoon graphics. They didn't work.

I was then reminded of Bing Gordon's interview about founding Electronic Arts in Bill Moggridge's Designing Interactions.

"One of the first precepts of Electronic Arts, that interactive entertainment was going to be as big as traditional music and video entertainment, was driven by our belief that 'play' is a core human value; even a core mammalian value. We used this analogy that lion cubs learn to hung and fight by playing together. We asserted that interactive virtual world gaming would be a way that people could train in a bunch of different ways, socialize, and get same kind of richness that one can get in many aspects of real life, but without the risks."

When we play games, we are learning. Just look at how this concept can be applied to Microsoft Word.

I'd like to think my ultimate goal is to harness the power of interactive games to make the world a better place.

Flixel Jam 2 Post Mortem

Last week's Flixel Game Jam came and went successfully. I have to admit, we didn't get as far at this Jam as we did in the last Flixel Jam. You can check out the fruits of our labor here. The idea was to create an RTS/Strategy game where the player casts miracles to convert dinosaurs to the player's faith. Along the way, the minions of L. Ron Hubbard seek to thwart you. It seemed like everyone had fun and learned something, but a few factors contributed to delays.

Transitioning to Box2D 2.1: b2Fixtures

My game development team got a bit of a shot a few weeks ago when found that our ActionScript 3.0 physics engine, Box2D had released the Alpha version for their 2.1 update called 2.1a. Strangely, the C++ version of Box2D has yet to release this update.

I actually stumbled into downloading the new version while looking for a way to create multi-shape bodies. I figured the examples that come with the Box2D source would show me how. Boy was I in for a surprise: what were all these b2Fixtures doing in the code?

Global Game Jam 2010: Post Mortem

I had a great time at last weekend's Global Game Jam 2010. Team Mound of Awesome managed to pump out a Flash stealth game in the 32 hours we had UT. The final build can be found here. For more games from the Austin location, check out the GGJ site.

This year's theme at our location was Deception involving a Man, a Plan, and/or a Canal.