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.