Archive for the ‘Unity’ Category

SPUDZOOKA on the iPhone?

Monday, March 31st, 2008

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

Wednesday, February 6th, 2008

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

Thursday, December 6th, 2007

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

Thursday, November 8th, 2007

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

Thursday, October 25th, 2007

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.