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.

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.

Flixel Jam Postmortem

Phil's second Flixel Jam has come to a close. It was a lot of fun and I hope to see everyone again for another Jam. In the six hours, we managed to pull together a simple game about falling from the sky. Dubbed Terminal Velocity, the game is far from perfect: it's too hard and it needs about a weeks worth of polish. However, that wasn't the point. In six hours we organized a team of ten developers- many of whom had never met before- and created a proof of concept for a simple mechanic. The result of those six hours can be seen here. For those interested, here are links to our source code as well as our current build of the game.

Here are some things we've learned:

Getting started with Git Part 2: Branching and Tracking

Part 1 of Getting started with Git can be found here.

Now that we've pulled and pushed code with a remote repository it's time get more advanced. One of the more elegant features of Git or any source control is the ability to branch code and work without fear of breaking the original source. With Git's local and remote repositories, the options become even more robust.

Getting started with Git

One of the toughest things to learn during this game project was actually our source control Git. Phil(our most experienced member) insisted we use Git because of its superiority to SVN and the like. Git allows you to create both a remote and local repository of your code. This means you can branch and merge code all you like on your local repository and only interact with the remote repository when you need to.

I've used SVN before so I didn't think much about learning Git. Ironically, after a week of trying to share code between the four programmers in our group, Phil was probably the least Git literate in our group. Git's cryptic interface can be pretty unforgiving, especially if you don't know Git's recommended workflow.

So I decided to write a guide to getting started with Git on Windows.