Modeling a tree (the easy way)

Like so many things in life, I have discovered after days of work that there is an easier way to do something. That's right, my irritatingly complex description of how to model a tree has been rendered obsolete in 48 short hours. Ok, it was obsolete when I started -- I just didn't do my homework before I set to modeling.

What's the easier method, you ask? It's called Arbaro. It's an open source tree generation program based on a paper by Jason Weber and Joseph Penn outlining an algorithm for computer-generated trees. It's platform-independent. It's free.

Here are some images of trees created with the same algorithm.

I downloaded Arbaro and played around with it for about 30 minutes. Parts of it that are less than intuitive, but some helpful diagrams and more-or-less hidden documentation provide a little guidance. Regardless, this is the kind of program that invites exploration, so I don't mind some healthy trial and error.

Besides generating 3D meshes for trees, it also creates automatic UV maps, which are required for texturing. The UV maps aren't perfect, but they're a good starting point.

Lest you think this is turning into a blog solely about trees, I would like to declare an end to this brief series on vegetation. Next up: rocks and stones. Just kidding. Maybe.

The happiest marriage is one filled with rock

Picked up a copy of Guitar Hero 3 tonight. Haven't played it yet, but it's only a matter of moments until I crack open that bountiful trove of rock.

This latest installment includes a co-op career mode that is quite exciting. You see, after years of eye rolling and summary dismissal of video games as a waste of time, my wife finally agreed to play Guitar Hero 2 with me (she even bought a guitar controller for herself), and she was puzzled to discover how much she liked it.

So, it's with much anticipation that I prepare for a rare period of gaming bliss when the guilt vibes are replaced by those heavenly words, "Let's just play one more song." It will only last a few weeks, so I plan to enjoy it.

Modeling a tree, and (r)ambling through the woods

After some fairly tedious work on my pine tree, I have something that doesn't look half bad.

Unity's restrictions for in-game trees require that each tree include a single mesh (for my non-gamer readers, a mesh is just a 3D object composed of triangles) using two textures: one for the bark and one for the foliage. Unfortunately, I didn't know how to place two textures on a single mesh in Cheetah (my 3D modeling program). It is possible, and pretty easy to set up, but it took some time to figure it out.

Create the foliage
Armed with the requisite knowledge of Cheetah's features, I set out in earnest to fill in my tree. The process I settled on ended up being fractal-ish in a way, which seems a fitting way to create a tree:

• First, I created a small group of six polygons that would act as a small branch and a group of pine needles.
• Then I duplicated this small branch 10 or 12 times along the bottom-most big branch on the tree. I scaled and rotated each copy so the foliage would feel random.
  
• Rather than repeat this process for each of the 20 or so branches, I just did it for the first three. This gave me three distinct sets of small branches (anybody confused yet?).
• Then I used those three branch sets to fill out the rest of the large branches, copying each set several times and moving/scaling it into position.

Remove (some of) the foliage
Another one of Unity's guidelines for trees is to keep each one below 2,000 polygons. Alas, after my foliage frenzy, I was about 1K over the limit. Time to optimize. My first inclination was to remove some of the small branches that didn't add much to the density of the foliage and wouldn't be very visible from a distance. This activity, sad as it was to remove the pretty pine needles, didn't get me far enough. How could I remove more polygons without thinning out my lush tree?

Finally it occurred to me that the branches near the top of my tree would never be seen up close. What's more, the branch sets up there had been shrunk down to the point that the polygons wouldn't be visible even if you were up close.

The solution, while probably obvious to you (if you've made it this far), seems poetic somehow. At the very top of the tree, the sets of branches aren't much bigger than a single branch at the bottom of the tree, so I just removed four of the branch sets at the top and replaced them with single branches. The difference is nearly indistinguishable, and I eliminated several hundred polygons. Final polygon count: 1,970. Yeah, I'm kind of awesome.

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.

Sound effects for the rest of us

I was trolling around a Mac game development forum today and discovered a post linking to a remarkable site called SoundSnap that showcases free sounds. I only clicked around for a few minutes, but the number of quality clips is truly remarkable.

My game has a long way to go before sound effects become a necessity, but sound has been a nagging issue for me, since it is a highly specialized part of game development, and I lack the equipment, money, time, and talent to record sound effects myself. This one site should give me a big nudge in the right direction.

Considering how many sounds are there now, I'm excited to see how many there will be when I'm really ready to dive in. Just think, now I'll be able to create that group of happy sea lions I always wanted.

Stone wall textures, a mountain adventure

I went to the North Carolina mountains this weekend with some friends and hit the obligatory Asheville-area attractions: Chimney Rock and the Biltmore House.

Despite suffering much ridicule from my wife, I managed to take a series of texture photos for the game. It's not often that I stand next to massive walls, so I couldn't pass up the opportunity.

Some work will be required to turn these photos into useful, tileable textures. The GIMP has a "make seamless" filter, but I haven't tried it yet. In the event that it doesn't work very well, I will resort to the time-honored tradition of using online tutorials.

The world isn't flat, it's square, part 2

Well, I'm stumped. After what seems like days of pondering, I can't think of a way to create the illusion of a massive world using one square terrain. Sure, the terrain might look fantastic when you're near the middle of it; the problem arises when you approach the edge. What looks like a vast mountain range head-on just looks silly from the side.

I've considered several options, and none of them really satisfies me:

• Use a truly huge terrain. This option is quite attractive, but I pause because, while there seems to be no upper limit to the size of terrains Unity will let you try to create, there is certainly a limit to how large a terrain most computers will handle without choking (I've hung Unity more than once by trying to create too large a terrain). It is therefore a requirement to divide things up into sections.
• Hide the edges of the terrain. One obvious way to do this is with water. Indeed, islands are probably the ideal use of square terrains. But I'm not creating a group of islands Myst style, I'm creating continents. Another option is the inverse of islands: valleys. If each area of the world is surrounded by impassable cliffs, the player will never see the edges. That might work, but what if you discover some lofty perch that lets you see for miles? You would see the edge of the world, and beyond that, nothing. It would be very disconcerting.
• Build a backdrop. Hiding the edges might work, but a world full of squarish islands and valleys isn't very appealing to me. Besides, how can you let the player travel between areas without letting them approach some sort of boundary? Another option, then, is to acknowledge the edge of the map and just use a flat image that looks like it carries on into a new area. The illusion might be convincing enough for the player to go with it. Final Fantasy XII uses a technique like this to divide many of its zones. Unfortunately, I'm not confident in my ability to paint a backdrop that gives the necessary sense of depth.
  
• Something in between. Or I could use some mixture of the first two options. I could hide the edges by building a terrain that is considerably larger than what I need for an area but not so big that it would slow things down. Then I could focus the action of that area near the middle of the terrain, and the functional boundary between zones could exist some distance away from the terrain's actual edge. This could certainly work, but it seems like an inefficient use of the computer's memory and, frankly, like a waste of space.

That's a lot of words to say that I don't know what to do. If anyone has ideas, please let me know.

Part of the trouble, of course, is that I'm trying to force a tool to do something it wasn't really built to do. Probably I should take a step back and come up with a creative solution that will work within the boundaries I've got, instead of trying to explore the edges all the time.

Terrains are fun; UV mapping is not

Just a quick update this morning. Last night I spent my time on two things: UV mapping and terrain painting.

For those of you who don't know, UV mapping is the process of "unwrapping" all the polygons in a 3D object onto a flat image so it can be painted with a texture. This process has gotten much easier in the last few years, thanks to some more sophisticated algorithms having been built into most of the 3D programs. Nevertheless, it is still very time consuming (and tedious).

After getting tired of trying to map UVs for one of my buildings, I decided to spend a little time creating a terrain. I have a fairly good idea how the terrain should be laid out for the opening area of the game world, so I started creating the rough, square shape of it. After about 10 seconds, I realized that making a terrain is considerably more entertaining than UV mapping. I then proceeded to spend so much time on it that I wasn't able to write a blog post.

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 tricky concept

I'm sure all of you who regularly read my posts (thanks) are probably wondering when you'll actually get to see something other than a little blue man and a crate. In fact, how can you be sure that I'm really developing a game at all? I haven't mentioned its name, given any insight into characters or plot, or even shown any concept art. My blog's appearance is pretty bare; it's just a stock Blogger template. I haven't mentioned a web site. The list goes on.

So when can you expect me to deliver something real? I'm working as hard as I can (damn that day job) to create something reasonably professional for you. I don't want to embarrass myself, after all. The truth is I'm learning as I go, and that means a good deal of trial and error.

Beyond the tortoise-like pace of development, my real hesitation is a desire to promote this video game in a meaningful way. The blog is obviously a part of that strategy -- an experimental way to build an audience (tell your friends) and a game at the same time.

Now, one approach to the blog would be simply to post every asset I create one at a time. This would lead to a wonderfully long list of posts showing off disconnected, even random pictures of boxes, trees, buildings, people, animals. It would also leave no surprises for the game itself. If you've already seen all the locations and read about all the characters' inner-most secrets, why would you play? (If you are interested in random pictures, you will transfixed by this endless slide show.)

So I have to control myself. I will want to post pictures of everything, but, no, the trick is to write interesting (and I hope enjoyable) posts while establishing a controlled leak of information that will help build a grass-roots interest in this game I claim to be creating. I mean, how could it not work?

Real-time battles, part 3: party AI

My last post about real-time battle systems looked at requirements for enemy AI. This third (and final) installment will deal with party AI.

To me one of the most significant differences between a turn- or time-based battle system and a real-time system is how the other members of your party behave. Old-fashioned time-based systems like Final Fantasy VII usually have random battles that take place in a temporary battle area. The advantage here is that the player can easily give orders to every member of the party during the battle, since only one party member or enemy can execute a move at any given time.

In a real-time system, things happen too fast to give explicit orders to each party member throughout an entire encounter. One obvious solution to this problem is not to have a party. But if you don't take the easy way out, you have to prevent the rest of the party from being a liability.

The common approach to party AI is, first, to give the player a way to switch control between active party members at any time during a battle and, second, to provide a short list of general behaviors for AI-controlled party members. These often give you three choices along the lines of aggressive, defensive, and support (healing and ranged attacks).

Unfortunately, these limited options usually result in party members that seem to get themselves killed (but only after using up all your items), and there is no way to customize their behavior any further.

Final Fantasy XII's gambit system finally offered a better and more fun option for party AI. By giving the player access to the if-then structure (e.g., if an ally's health drops below 50%, cast cure on that ally) of the party AI system (and by making it a part of the character leveling scheme), party AI became not only useful, but fun. Creating just the right combination of gambits became almost a game in itself.

One criticism of FFXII's gambit system, of course, is that the more gambit combinations are available, the less you have to pay attention during battles. You can literally run up to a group of enemies and go get a snack while your party defeats them. In some ways this is quite nice, but could be quite annoying for players who like finer control. Turning gambits off is always an option, though.

I haven't yet designed the party AI system for my game, and I don't know how I'll approach it. Some amount of control over party members' decisions is essential, but a more robust system would need to be carefully integrated into the gameplay and could distract from the primary character leveling system (which is going to be very cool, but I don't want to give it away just yet).

But until it's time to program party AI, I will turn my attention back to modeling buildings and other inanimate objects.

The joy of texturing

As I mentioned in my last post, creating art assets is likely to be the most time consuming aspect of this project. Visuals are, however, quite important, as a fellow blogger points out. While I'm just starting the process of modeling objects, I would like to take a moment to discuss texturing. The reason is simple. Yesterday I turned the crate I had so expertly modeled into a living, textured game object, and I am pleased.

This is premature, of course, since we have yet to come up with a texturing method (more on that in a moment) or even a color scheme for the first area of our game world. Nevertheless, in an effort to see what might be involved in creating a vibrant wooden object, I set out to texture my crate.

Now, there are really two main approaches to texturing:

• Painting -- this is what the real artists do. Start with a base color in your favorite graphics program and gradually paint in details like highlights, shadows, texture (like wood grain or knots). If you're curious, check out this tutorial on painting, yes, a crate. Painting can yield fantastic results because the possibilities for stylized textures are endless. Case in point, World of Warcraft.
• Photo-based texturing -- It would be unfair to say this method is any less artistic than painting, but the desired effect is different. Photo texturing aims, as you might guess, at realism. Using this method, you would start with a photograph of your desired texture (a piece of wood or, better yet, the side of a crate) and manipulate it until it fits your desired style. My favorite example here is the Myst series.

Which method did I use? Well, neither. My 3D modeling program has a very nice procedural wood shader (which means it creates a texture from a program instead of an image file). So, instead of finding a crate to photograph or trying my off-hand at painting from scratch, I created a flat plane in Cheetah, added a wood shader, customized it by fiddling with some numbers, rendered it, and then used that rendered image as the starting point for my texture.

The result is certainly not going to change the world, but I was amazed how a couple hours of work could turn a drab gray cube into a crate just realistic enough not to be noticed -- and for a crate in a video game, there is no greater accomplishment.

The trouble with modeling

Having made faster-than-I-ever-dreamed progress on gameplay programming, the time has come to turn the bulk of my attention to modeling (that's 3D modeling--my career with Calvin Klein never really took off).

For the sake of completeness, here's a quick list of all the basic gameplay that's currently working:

• Basic movement
• Camera controls (complete with collision detection!)
• Battle mechanics (attacking, casting spells, applying status effects)
• Character, enemy, and weapon stats (attacks actually cause damage)
  
• Enemy death
• Basic enemy movement and AI (lots more work to be done here)
  

My brother, who has more experience with 3D modeling than me, will be handling the bulk of the character modeling and animation, while I will probably focus on inanimate objects (for example, this crate I modeled yesterday). The reason for this switch is simple: while there is plenty more programming to do, a story-based RPG like ours isn't worth much without a world in which the story can take place. It will also help me hold your interest, dear reader, if I can balance my dry ramblings with a few pretty pictures.

Speaking of dry ramblings, I feel compelled to point out that the creation of art assets will likely prove to be the hardest part of this project. Not only must every object in the world be designed and modeled, it must be textured, animated (if necessary), and placed. We're going to attempt a master spreadsheet containing the status of every object in our little world, and I'm genuinely frightened to see how big it will get.

This is the part of game development that separates the big studios from the little guys. Success in modeling depends as much on the number of people as the depth of talent. Our approach will be to take it one building, rock, or tree at a time until we have a world for you to play in.

Two unrelated notes

• My favorite band has cast a surprise announcement on the recording industry: they are selling their latest album on their own web site, with no record deal, and, this is big, for as much as or as little you care to pay. Seriously.
• Secondly, I have one song left to clear on hard in Guitar Hero II--yes, Free Bird. I must beat it before GHIII comes out. I have no choice.