Next Revision – Developer's Log

I must say, after quite a few years working in the industry I’ve picked up several interesting… beliefs, for lack of a better word. Here is an example: I firmly believe that the vast majority of Masters graduates in Computer Science know pretty much nothing when it comes to actual development. In fact, some of the worst grades I’ve seen from applicants completing an entry test came from them. College graduates, on the other hand, tend to do very well on those. Ironically the former also usually get higher salaries than the latter, but that’s a different problem altogether.

What I’m saying is, there are certain qualities I look for in job candidates — certain shortcuts my mind takes — that judges them without me realizing it. Take applicants fresh out of highschool for example — would any serious company consider one? Doubtful. I certainly wouldn’t… or at least wouldn’t have until this past weekend.

A few days ago I got a chance to be a speaker for something called ProtoLaunch — a monthly event run by Dwayne Hammond out in Sault St. Marie — a small city of about 75,000 people. This event reaches out to various senior game dev industry professionals — developers, producers, managers — bringing them over for a weekend to meet a class of 24 highschool students aspiring to work in the industry. The purpose of the workshop is two-fold: the students get to learn from the speaker’s experience, and the speaker gets an insightful view into the City’s talent pool as well as lucrative government incentives for local businesses. While all 3 reasons are quite interesting, but it’s the former that surprised me the most.

As I mentioned I am used to a certain way of thinking — no experience and no education? Meh. Nothing to see here, move along. Well, that may have been true “back in my day”, but with tools like Unity readily accessible to everyone, it certainly doesn’t seem to be the case now. In the span of mere two days, the students formed teams and created several 3D platformer games using Mario 64 as an example — and some of them were impressive enough to be considered for actual funding. It really makes me wonder what they could accomplish given a full time job, an experienced project manager, and a clear directive.

In the end, my feelings were somewhat bittersweet. On one hand I was proud and happy for the students who managed to create their game prototypes so quickly. On the other hand I was brought back 10 years down the memory lane when I was graduating highschool myself — back when nothing like this was even remotely possible. Back then, creating pong was a notable achievement. 2D space-shooter game? Impressive feat. 3D physics-based platformer? Dream on. And as far as meeting industry professionals go? Not a chance.

And now? *wistful sigh*

You lucky, lucky students.

Both starter kits (ship and space) have been accepted by Unity and are now available on the Asset Store.

Space: http://forum.unity3d.com/threads/107768-Space-Game-Starter-Kit-Released

Ship: http://forum.unity3d.com/threads/107751-Ship-Game-Starter-Kit

Well, crunch time at work is leaving little time for anything else. Seeing as I have quite a few unfinished projects sitting in the backlog, I decided to do something with at least one of them: the space game I started has been cleaned up, improved a bit, and submitted to the Unity Asset Store. I figured its mix of control mechanics, shaders, multiplayer, and other nifty things can let someone hit the ground running with their own sci-fi project.

Me? I’ll keep working on it (on a separate SVN branch of course) when I have the time. I spent almost half an hour earlier just flying around aimlessly wondering what can be done with the game, and I’m thinking adding heat-seeking missiles will be a good start.

You can play it here: http://www.tasharen.com/sg/

It has been over 6 months since I started working at Gameloft, and I sadly can’t say that I have any more free time now than I did back then. To remedy this problem, I celebrated by taking a week off to sit at home and do what I enjoy most — work on my own stuff.

I started a brand-new Unity project that week, and set forth a goal — not to complete it, but to explore things I haven’t tried before. XBox 360 controller usage, real-time reflections, networking/multiplayer — stuff like that. I couldn’t complete all of it in that week, although I did accomplish a lot.

At the end of my vacation I had a spaceship flying around, controllable both with the keyboard/mouse as well as the 360 controller. It was fully physics-driven, with no shortcuts taken. There was a space station with localized gravity that would pull the ship down if it was in range. The ship had particle emitters and lights on all sides that would activate based on what force the player is applying. When the ship collides with something, the screen should shake and the camera would become semi-detatched from the ship, and when the ship had a near miss, a message would animate from the top of the screen. In the background there was a large planet with a visible atmosphere on the sun-lit side (fully dynamic, of course). The asteroids were textured procedurally by projecting a texture on 3 sides (along with a normal map), the shader taking care of flipping the normal on 3 of the 6 sides as well as choosing the most appropriate side for each pixel. Last but not least, the ship (made out of high-quality programmer art — boxes) was reflecting the environment around it.

All in all, a fair amount of work for just a week’s worth. There was no game, but that wasn’t the point — I learned a lot, and that made me extremely happy.

That was a week ago. Since then I haven’t had much time yet again, but this weekend I did manage to implement the last missing feature — fully functional multiplayer functionality. It took me a while to wrap my head around how Unity does it, but in the end I figured it out and managed to optimize it to boot (reduced bandwidth usage from 2 kb/sec per user with Unity’s standard approach to 50-600 bytes per second). It seems to be working well — I hadn’t noticed any glitches while playing with a friend of mine from Europe.

Now if only I had added the ability to shoot…

http://www.nextrevision.com/sg/

The cat is out of the bag it seems. I’ve been working on another game since the beginning of January, but decided to keep it a secret for some reason. Not from my co-workers though! They’ve spent quite a bit of time enjoying the game (and dying repeatedly). Quite a lot of good suggestions came out of it, and two people actually joined the project as well — Mike Lambert (artist), and Phil Cosgrave (dev).

You can have a sneak peek at it here:

http://www.nextrevision.com/tanks/

I figured I’d put this here in case it might be useful for others using Unity.

Instead of using OnGUI on your game objects, have only one game object receive OnGUI events. Other scripts should register delegates with that one script. This gives an incredible benefit to performance.

While we’re on the topic of Unity’s GUI, exit out of functions early if you don’t need to process non-drawing events by checking (Event.current.type == EventType.Repaint). Unity’s OnGUI is called more than once per frame: layout, events, drawing. If you’re only drawing, why go through the extra steps?

Don’t be afraid of referencing game objects in your scripts or prefabs. Your reference will be automatically set to null if the game object gets destroyed. Additionally, don’t be afraid of referencing child game objects in your prefabs — when your prefab gets instantiated, all game object and transform references inside get automatically updated to the clone’s values.

Make liberal use of your own custom data classes for data storage. Just place [System.Serializable] above your class’s name, and any usage of your custom class will be visible in the inspector. For example:

[System.Serializable]
public class CustomData
{
    public GameObject go;
    public float someValue;
}

Speaking of special tags, organize your scripts using [AddComponentMenu("Scripts/YourPath/Script Name")] tags above your class declaration. This makes finding scripts in larger projects a lot easier.

Cache your GetComponent results. Don’t do GetComponent<> on every single frame unless you really have to. It’s best to get them in Start().

When creating singleton components, set the static reference in OnEnable, and remove it in OnDisable.

Don’t attach renderable children to scaled objects. Create a common non-scaled parent instead. Unity doesn’t handle rotation and scaling mixing very well.

Back to GUI, don’t switch GUI.skin — it’s a very slow operation (although this gets improved in Unity 3.2). Instead try specifying styles for your widgets directly.

Use fixed-size arrays as your class members. Mix them with your own custom [System.Serializable] marked data classes for optimal results. Declare your array to be null initially, then use the inspector on a game object to set it up by changing its size and filling in your array’s values. For example, a list of weapons can be declared as a “public Weapon[] weapons = null;” in your MonoBehaviour-derived component, but then filled out by using the Inspector.

When using lights that affect a small area, consider changing them so that they only affect the object they’re on by playing with layers.

Limit the number of raycasts to a minimum. If you need to do a raycast into the screen under the mouse’s position every frame, consider having a globally-accessible script that does that once per frame, and other scripts simply reference the saved (prefferably static) value.

If the code can get away with not being real-time, consider executing it infrequently by making liberal use of timestamps (float nextTime = Time.time + 0.5f;). Better yet, randomize the delay a bit so that if you have many scripts of this type in the scene they won’t all be executed at the same time: (float nextTime = Time.time + 0.25f + 0.5f * Random.value;). An example of logic that would be perfect for this is something that checks the distance between the gameObject it’s on and the player’s position. No need to do it every frame or fixed update.

Add smooth interpolation to your transitions by using Mathf.Lerp (or Color.Lerp, Vector3.Lerp, Quaternion.Slerp). Just pass the Time.deltaTime multiplied by a “whatever feels right” value (I commonly use 3 for slow transitions, 5 for faster ones). For example:

mColor = Color.Lerp(mColor, desiredColor, Time.deltaTime * 5f);

I hope this helps someone.