In this three part post, I recount my experiences with the recent Unity Game Jam Manila held last Oct. 11, 2012.
I got a rather surprising email last Oct. 2. A notification for a Unity Game Jam here in Manila, Philippines. Amid the looming deadlines I have for both work and personal projects, I thought that more stuff to do was the last thing I wanted to see.
Then I thought, what if the prize is a Unity Pro license?
I read the email more and what I got from it was this was meant more to be for learning Unity, other than it being a game jam (i.e. the whole "learn how to make a game in 48 hours!"). Also it turns out, De La Salle-College of St. Benilde is one of the sponsors of the event, so I take it students will be joining.
So, for the most part, I just ignored it.
The week that game jam is gonna take place, I see the usual announcements on our little IGDA Manila Facebook group, and silly me, I neglected to announce it on our Unity Philippines Users Group too. Though pretty much the people in Unity PUG are in IGDA Manila too. Nevertheless, I probably should have made some announcement too. I was hoping Mars Balisacan would do it; I'm only the guy who answers newbie programming questions in the group!
Then I got a private message, "Hey Ferdi, would it be ok if you come in the game jam as one of the mentors to the participants?" And having gotten that message while I was in the office in the middle of work, it was like a nice little distraction to go on some event for a while.
I also convinced myself that it would look good for the company if we participated in official Unity events. So I decided I would go.
So come the starting day of the event, straight from Quezon City (where our office was) I took the railway transit back to Manila.
When I got to the event's location (i.e. College of St. Benilde) I got stopped by some pretty strict security and it turns out the guards didn't even know the game jam is about to take place in their school.
Fortunately things cleared out amidst many phone calls and forms to sign.
Brett Bibby of Unity Technologies was coming in as the facilitator and the first thing to do was a briefing of us mentors. Apparently his flight got delayed so I was able to take some time to rest and chat with the people there.
When Brett arrived, we set up our things in the game jam's venue, the school's "Alienware Lab". Pretty much a big open space with a bunch of Alienware PC's. Unfortunately those things weren't set up yet so I couldn't get to try them.
So the briefing? It was this: Brett wanted to see how good we are with Unity so he asked us to come up with a game from scratch in 1 hour. Understandably it only needed to use cubes, and spheres, and whatnot.
My throat dried and my heart pounded fast. Being something of a perfectionist, I didn't want to settle for making a game that can't be completed in one hour. You could say I'm a completionist.
Ah, I know which game to make.
The simplest thing I could do: a side-scrolling shooter.
I did one before when Mars and I conducted the seminar about making a game using Unity. But I can easily recreate it from memory, more or less.
The challenge was doing so in under one hour.
So off I went.
I kept on checking for the time, glancing back at Brett. He was eventually getting into small talk with the other facilitators of the event; the faculty staff from College of St. Benilde (CSB).
Oh, good, good, looks like Brett is getting distracted from checking the time. More time for me!
Brett Bibby (left), and Patrick Williamson (right) of Unity Technologies |
So I had my player ship moving and shooting, some enemies continually spawning, some particle effects, and I was about to finish some simple powerup feature when Brett called time.
Mine got looked at first, and pretty much the mistakes I did were:
If you are continually moving something (via code) that has a collider, you always, always will want to put a kinematic rigidbody on it. Failing to do so will cause Unity to be forced to recompute the whole world's static collision data.
Do not instantiate while in the middle of the game. Allocate everything you'll ever need at the loading screen or startup only. i.e. use a resource pool. Regardless if this is a mobile or desktop game you will want a resource pool. The enemy here is Mono's garbage collector. Unity is still in the process of updating the version of Mono that they use. In the meantime we're stuck with the old version (Mono 2.6) which reportedly has a slow garbage collector. [1] [2] [3]
The red line shows how bad Mono 2.6's garbage collector is.The blue line shows the new garbage collector since Mono 2.8. |
Point number 2 was understandable because I can't divide my attention at making a resource pool and the game's code and still complete in one hour.
And so point number 1 was really my mistake there. And Brett said, "Don't worry, even I forget sometimes." The problem also was that you'd only notice this if you have the Profiler, which only comes in Pro.
The effect then, is that people using the free version don't know why their framerate gets so low at times, and in effect they may get the wrong impression that Unity is slow.
Brett was actually wanting that some form of warning be made when the user makes this mistake (a message in the console, some explanation on the user manual perhaps, etc.). They're still arguing about how to go about it, it seems.
NCarter in the Unity IRC chat recommends people read up on the Nvidia PhysX User Manual. Since PhysX is what Unity uses, it will clear up a lot of mysteries for the common user if they read how PhysX works.
The only other mentor who I was with, Charles Cue, did a cool job too. It was about feeding food to a dragon, all in cubes and spheres, yes, but that was the idea. It reminds me of Papo & Yo.
Charles Cue, one of the faculty staff and mentors of the game jam. |
The marshalls did an ok job too with the one hour hackaton, some were understandably struggling but they all got somewhere at the very least.
Brett gave some final tips for us:
These students who are entering the game jam? They will almost always want to use physics. The problem is that they will likely misuse it and you will end up with something that you might as well throw away. You need to explain the gotchas of combining physics with user-input and animation.
Sometimes they will ask how to do some particular thing which sounds rather strange. The proper thing to do is to ask "Wait, what are you trying to achieve in the first place with doing this?". And they go something like "Oh it's because I want to build a bridge that breaks." And then you realize "Ok, what you were asking for? That is totally not what you need to do to make a breakable bridge. You can forget about that. You need to do this instead..." and they realize they were needlessly doing things the hard way.
He then explained some intricacies with the Unity engine.
When Unity gets memory to use, even when garbage collected in Mono, Unity NEVER releases that memory back to the OS. Naturally when the Unity game closes, only then will it get released.
Apparently, this is actually a feature of any professional game engine: you will always want to allocate everything you'll ever need in a loading screen first, and never do any memory allocation while in the middle of the game proper. This is to ensure a reliable framerate for the game.
Second, things you know about .NET do not necessarily apply with Unity. For the simple fact that Unity uses Mono, and not .NET. Structs always get allocated in the stack? Not in Mono (ergo, not in Unity).
Thing is, in Mono, whenever you use the new keyword, that will always make use of the heap (memory allocation). If you're in Update(), you will not want to initialize aVector3 with new Vector3(0,0,0) because that will make use of the heap.
Instead, use the handy Vector3.zero, or, if you need to give some specific values, do this for example:
Vector3 myPos;
myPos.x = 345;
myPos.y = 0;
myPos.z = 23;
Don't worry, a struct (like Vector3) can never be null, so this is fine. While it is admittedly a little more wordy (what used to be one line is now four lines of code), it will actually be faster this way. The point is, just don't bother with using new if you're in a tight loop (i.e. Update).
I'd like to clarify that this issue with new is because of the way Mono works, not necessarily something Unity Technologies directly chose to do.
They argue about this in length in this Unity forum thread, and here's some tips on the user manual.
That's it for now, I think this blog post is long enough as it is. In part 2 of this post I'll explain what happened in the game jam itself and share some more photos I took. Part 3 explains how the jam ended.
Read more about:
BlogsYou May Also Like
