Got a new computer over the weekend. I’ve been eyeballing the latest round of iMacs for a while, and they announced a hardware refresh a few weeks ago, so the time was right. This new one replaces my last iMac, which was nearly six years old.

The new one has a 24″ monitor — it’s hard to know what to do with all the space, but game development will be a completely different experience. I see a lot less window switching in my future. I might actually be able to have the debugging console and the main Unity window open at the same time. Or maybe even have a programming window up along-side Unity. Oh, goody.

But…I don’t have Unity loaded up quite yet. My license wouldn’t work on the new machine for some reason (though it is supposed to), but I expect the problem will be worked out in the next day or so. That’s really the last piece of the puzzle. Most of the other important software is in place and ready to go.

I’m working on a couple of concepts, trying to figure out what to develop next. Trying to find the right mix of interesting and possible. Stay tuned.

Wanted to give a quick shout out to a kindred spirit, Marraboy over at Unity 3D — Zero to Hero. He recently started a blog to chronicle his progress building a game with Unity and Cheetah 3D. He’s only written a handful posts so far, but I just want to say, “You can do it, Marraboy!”

It’s still by no means proven whether I can do it, but I did get some much-needed words of encouragement from a good friend over the weekend. This no-budget-game-development thing can get pretty daunting, particularly on days when I realize how much more there is to learn.

Case in point: Unity’s ShaderLab. It’s a programming interface for creating shaders in Unity (a shader describes how an object will look in the game — what textures it will use, how it will react to light, etc.). This mind-bogglingly powerful feature of Unity is, I’m beginning to discover, the difference between amateur work and real professional visual quality. Sure, modeling and texture art are essential, but custom shaders add the flair.

Of course, working with shaders requires some knowledge of OpenGL’s shader language, of which I have none, so I feel quite outmatched at the moment. As usual, though, I’m probably getting ahead of myself. SPUDZOOKA isn’t done yet, and I can’t get too caught up in the next thing.

No, I shouldn’t be worrying too much about shaders yet. They just remind me that I need to take things one step at a time. Visual polish is not my strong suit, since I never had any formal training. But that’s ok. I like to think that what I lack in skill, I make up in blind determination.

Unity Technologies announced today that Unity will support development for the iPhone. Probably this means that the ability to build games in iPhone native format will eventually be built right into Unity. Currently it’s possible to build games in a variety of formats (including Web player, Mac stand-alone, Mac Dashboard Widget, and PC stand-alone simply by choosing which one you want to build.

There’s a lot of hype now, with the iPhone SDK now on the market that mobile gaming is going to take off. It could very well happen, and the Unity game engine is likely to be at the forefront of 3D gaming on the iPhone.

Very cool. Someday you might even be able to play SPUDZOOKA on your phone.

Last week Unity Technologies announced Unity 2.0.2, which has a few new features and a bunch of fixes. More importantly, though, they posted a new resources section on their site, which I hope will eventually be home to tons of great materials to get people started with Unity.

Right off the bat, this little area contains a wonderful package of pre-made nature assets, from trees to rocks, grass, and textures. According to the license agreement (as far as I understand it), these assets are free to use in commercial projects without giving credit to Unity Technologies as long as they are used only in games created with Unity. I can handle that.

I continue to be blown away by Unity. Someone on the Unity support forums has said that Unity is so fun to use, it’s almost a game in itself. Every time I open it up, I have new ideas for features to add to my games or gameplay mechanics to try out. More than that, I rarely get frustrated when working in Unity. That’s not something I can say about many pieces of software. It’s all a testament to the brilliant design of this product, with it’s straightforward interface and powerful features. Great stuff.

Ok, my fanboy post is over now.

I’ve learned a lot in the last few days about lightmapping, the process of “baking” lighting effects into the texture on a 3D object. I’ve heard it described as a “poor man’s lighting effect.” For me, that’s a true statement. I can’t currently afford the pro version of Unity, which includes dynamic, real-time shadows, so the next best option is to map static shadows into my scenes.

Despite being less flashy, lightmapping is considerably less expensive in terms of processing. Ultimately, I think it’s a fantastic value. The effect is great, and the cost is minimal.

Lightmapping is a tough concept to get your head around. Wikipedia has a brief article on it, but it’s kind of technical. Here’s the gist:

• Generally the best way to control lighting is in your 3D modeling application (the image to the right was rendered in my 3D app). You can build a number of objects, texture them, and light them in whatever way you choose. The trouble is that rendering images with sophisticated lighting is much too slow for a real-time game engine.
• When applying textures to 3D objects for games, you have to “unwrap” the object onto a flat surface that then gets painted with a texture (a tedious process called UV mapping). The texture is then wrapped back around the object.
• Most 3D modeling applications now allow objects to have multiple UV sets. In other words, the main texture can use one set of UV coordinates, and another texture can be attached to the second set.
• The lightmapping process takes advantage of this second UV set by converting lighting information from the 3D application into a flat texture that can be applied to an object on top of the primary texture. The result is an object that looks like it’s being lit, even when no lights are present.
• Since lighting is one of the most processor-intensive tasks in real-time 3D processing, lightmapping is tremendously beneficial from a performance standpoint. The downside is that the “baked” lighting isn’t dynamic and won’t apply to any moving objects in the scene (well, you could do it, but it would look pretty strange).

These before and after images illustrate the point. The first one is a screenshot of a scene with no lighting and no lightmapping. The second image uses lightmapped textures, but still has no in-game lights. As you can see, the cube that should be lit by the light coming through the window (if this were the real world), is not receiving any light at all, since there are actually no lights in the scene.

Probably the best approach for me is to use some combination of lightmapping and in-game lighting. The result won’t be perfect, but it will be close enough until I can spring for the pro version of Unity.