Unity 2.1!

Ok, this news is pretty stale at this point, but it's worth posting anyway. Unity Technologies released Unity 2.1 on Friday. This update was a long time coming (about nine months I think), but it's a doosy. The message around this update is that it finally makes Unity MMO-enabled. How? Well...

• Endless streaming terrains. Yes, that's right, Unity now supports as large a world as you want to create. You can build multiple terrain tiles and stream them in to create truly massive worlds. Anyone following TGNM the last month or so knows I've been working toward a home-grown version of the same thing. I had a feeling the Unity folks would throw something like this, but I couldn't be happier. Ok, I could be happier: I haven't figured out how to make these nifty new features work yet. The documentation is noticeably lacking so far.
• More realistic terrain lighting. Terrains in Unity 2.0 would only work with directional lights and lightmaps, which severely limited things. You couldn't, for example, light a road with torches in any realistic way. Terrains also now work with projectors, which means better shadow effects (for poor indie owners like me--terrains support real-time shadows for pro licenses) and the possibility for projected spell effects or selectors.
• Procedural control over characters and animation. Unity always had a really flexible animation scripting system, but now it's possible to create even more advanced effects like on-the-fly creation of skinned meshes. This stuff is pretty advanced, but it seems to open the door for really flexible MMO-style character creation. You can also sync scripted events with animations, making it easy to spawn things like footprints, footfall sounds, impact effects, etc.
  
• Streaming assets. This feature, alas, is reserved for pro licenses, but you can now pack up any group of assets in Unity into a bundle and stream it in as the player approaches.

All in all it's a pretty amazing release. There are still plenty of things huge things that would be required to build an MMO with Unity, like all the back-end databases and server configurations, but this is a major step.

Sure, I suppose I could feel annoyed that I spent so much time doing things the hard way with terrain, but who am I kidding? I always do things the hard way.

Shout out(s) and shaders

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.

SPUDZOOKA on the iPhone?

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.

New Unity resources

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.

An introduction to lightmapping

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.

Defending epic towers

Despite Unity's power as a game engine, not too many finished games have been created with it. Could have something to do with the "you have to have a Mac to develop games in Unity" thing. A new, very casual one was just released on shockwave.com: Epic Tower Defense. (Are we defending epic towers, or using towers to mount an epic defense? Hard to tell.)

The game doesn't really show off Unity's graphical chops, but it does have some nice user interface elements and a variety of different game modes. I found it while looking for something to write about and promptly spent half an hour playing. I think I might have blinked once or twice. Sometimes I wonder if I should shelve my epic story-based game and just create a casual one with "epic" in the title.

Anyway, aside from the easy bake oven ad that I had to watch before playing, it was pretty fun. Seriously, how many 8-year-old girls are going to play a game that involves zapping armies of orcs with lightning bolts?

First the trees, then the forest

I started working yesterday on my first serious tree. I've tried modeling trees before and found them to be quite tricky. Something about the thousands of tiny branches makes them a pain.

Nevertheless, nice trees are yet another a requirement for convincing game worlds, and the first area of my game is going to feature several lovely copses. Unity has some nice tools for creating the forest (there's literally a "make forest" button), but before you can have a forest, you need some trees.

After some brief research I went with a pine tree. One of those tall ones shaped like a cone. For one thing, it will fit well with the atmosphere of the game world. For another, it's shaped like a cone. How hard could it be?

The modeling process went something like this:

• I started with a cone and manipulated it around until it looked like a decent pine tree trunk.
  
• Then I created some smaller cones to use as branches and distributed them along the length of the trunk, making them smaller as I got higher on the tree.
• Then I was ready to texture the trunk and primary branches. I found a nice, free pine bark texture here and loaded it into the GIMP, the open source graphics editing program. One "make seamless" filter, some rubber stamping, and about 20 minutes later, I had a passable, tiling bark texture. Very exciting.

Unfortunately, this is where it got hard. Foliage, it turns out, is even more detailed a thing than branches. Following Unity's advice for creating trees, I tried to create a simple group of polygons that could serve as small branches and needles. The idea is to duplicate these polygons, tilt them, and scale them until they fill out the entire tree.

As you can see from the picture, I barely got started. First I had to find a suitable texture (the one I found could still use work). Then I had to figure out how to work with alpha channels in GIMP and transfer them to Unity, which is a little tricky (I'm still not sure I could do it again).

Despite the complications, I feel that progress is being made. If I'm happy with the result, maybe I'll post a more detailed tutorial about modeling a cone-shaped pine tree.

The world isn't flat, it's square

I spent most of the afternoon today testing the limits of Unity's new terrain system. Partly I'm learning how to use it, but mostly I'm trying to decide how to set up my game world.

Most terrain systems (Unity's included) work best with square terrains created from a heightmap (essentially a grayscale image whose pixels determine how high each point on the terrain mesh should be). The trouble with square terrains is, as you might guess, that the world is not square. You cannot fall off the edge. Unity terrains seem fairly flexible in that they don't have to be exactly square, and they can be adjusted to be quite large. Any really large terrain, however, would come with serious performance hits, since all its heightmap information would have to be stored in memory at the same time.

Because of this problem, most world-based games have chosen to divide things into sections and make the player look at realism-killing load screens when moving from one zone to the next. The notable exception is World of Warcraft, for which the good folks at Blizzard developed some way of streaming terrain information to minimize the number of load screens (this is one of WoW's most important innovations, in my opinion, because it allows a more enduring sense of immersion, and air travel).

So what are my options for piecing together a coherent world? Load screens are a necessity, I'm afraid, since Unity can currently handle only one active terrain at a time. Nevertheless, I would like to divide my world into squares that actually fit together. I may end up scrapping the idea, but I'm hoping that by planning ahead, I will be able to devise a way of making the game world feel coherent with some tricky, on-the-fly switching of higher- and lower-detail terrains. We'll see.

In the meantime, I have to work in squares. I take heart, though, that this is a time-honored gaming tradition. Think of the original Final Fantasy, where sailing your ship westward past the Earth Cave will spit you out on the eastern edge of the map near Crescent Lake. Sailing north will transport you to the world's southern reaches, where you will continue sailing north. It feels perfectly natural at first, until you realize that in a real, round world like ours, one cannot sail north forever.

Unity 2.0 has arrived -- check it out!

Unity 2.0 was released today. I downloaded the trial version and should be getting my licensed copy soon. This means I will have the ability to create terrains and brilliantly elegant GUIs. The terrain engine is really powerful -- not only can you sculpt and paint the terrain, you can paint objects onto the terrain. Trees, grass, rocks...anything really. Trees and vegetation even sway in the wind.

Here's a screenshot of a scene I created in just a few minutes. You can see the GUI I was testing in the upper left corner.

Everyone should go download the new version of the Unity Web player and then check out the demos here. They really are amazing.

A sneak peek

One of the coolest things about Unity is its Web player plugin. It's the same idea as the Flash Player, but it renders amazing 3D graphics instead. Pretty cool.

As a way to test out how well I will be able to embed builds of my game into this blog, I'm posting here some of the progress on my battle system. It's not much at first glance, but there really is quite a lot of depth to it. Here are some nuances to look out for:

• The way blue box man's left leg twitches when he runs.
• The fireworks that go off when he lands a Super Attack (press "2" to execute one--you'll love it).
• The way he runs forward while moving backward.
• The glorious piece of weaponry that blue box man and red box man are both carrying.
• The way the camera gets stuck above blue box man's head when you zoom in too far (using the scroll wheel).

Here are the controls. (You need to download the Unity Web player to play the game.)

• Right mouse to enter full screen mode (highly recommended--some of the controls don't work too well otherwise).
• Click on an object to target it.
• Left mouse: look around
• Right mouse (in full screen mode): turn
• Scroll wheel: zoom in and out
• w, s: forward and backward
• a, d: turn left and right
• q, e: strafe left and right
• 1: attack
• 2: super attack
• 3: cure
• 4: spell

Technical difficulties

Phase 1
As I mentioned in my last post, I have been working on this game for about two years. The first year was spent hashing out details of the story while a programmer friend worked to build a game engine from scratch.

Difficulties arose when it became apparent that this approach was, well, insane, so we (along with my brother and another friend) raided our piggy banks and pooled together $25 each for an indie license of the Torque Game Engine. Thus ended phase 1.

Phase 2
With an impressive list of features that seemed to promise everything we could want (weather and particle effects, blended animations, a terrain editor and GUI editor), Torque promised to kick our game into a new gear. Despite Torque's quirkiness and steep learning curve, I slogged away, implementing many of our gameplay ideas on the little blue box man included with the engine.

Difficulties arose, again, when it became apparent that Torque's long list of features had some rather large holes, and filling them would require major changes to the source code (also included with the engine as a "feature").

Then I remembered reading about a Mac-based game engine called Unity. Having passed over it a year ago because it lacked some things needed for an RPG like ours (a terrain editor, a GUI editor, and a Windows client for my programmer friend), I gave it another look and discovered that the imminent release of Unity 2.0 will include both terrains and a GUI editor, not to mention a host of capabilities (and flat-out better design) that Torque only pretended to offer. Being a Mac owner, I took the plunge. Thus ended phase 2.

Phase 3
This blog officially marks the beginning of phase 3. I'm rolling along with Unity, awaiting my free upgrade to 2.0. I have created my very own blue box man for testing and am quickly catching up to where I left off with Torque. No doubt there are more technical difficulties ahead, but for now, things are good.