After three days of wrangling with my code and muttering to myself, I have managed to get my camera system to a place where it mostly behaves. Having accomplished this, I feel a new sense of admiration for games with cameras that gracefully avoid passing through floors and walls. It’s still possible to make it pop through a wall occasionally or to find just the right spot where it will completely freak out, but it’ll do for now.

Here’s the gist of how it works:

• Just before every frame is drawn on screen, the camera casts a series of rays to detect objects around it. The primary ray starts at the camera’s target (the player) and casts back toward the camera, ending a short distance behind the camera. A group of secondary rays are also cast pointing outward from the camera itself, like spines sticking out in several directions.
• In normal circumstances (when no offending objects are near the camera), the camera can be moved around by clicking and dragging the left mouse button.
• If an object interrupts the primary ray (i.e., passes between the camera and its target), the camera jumps to a point in front of the object. Once the object is clear, the camera slides back to its preferred distance from the player.
• If the camera detects an object below it (like the ground), it will begin sliding toward its target. In this mode, the camera’s distance to the target is proportional to its own distance from the ground.
• If an object gets too close on the left or right side of the camera, the camera will slide along this object toward the target until it slides clear and can move along unobstructed.

So why was I having so much trouble? My camera didn’t have enough feelers sticking out of it. My initial setup only cast rays backward, left, right, and down. With so few, it was easy to make the camera think it should be moving forward and backward at the same time. Once I added a few more feelers–essentially increasing the resolution of my collision detection–the camera started behaving more like I planned.

Then the muttering diminished, and I cracked open a beer.

The other day I stumbled on an intriguing new project called Metaplace that’s aiming to provide an easy-to-use, web-standards-based way to create virtual worlds. The possibilities for creating games are obvious, but this seems an interesting step for the Internet in general.

If Metaplace works like they say it will, it would be possible to turn your web site into a virtual world–meaning that your site wouldn’t just deliver content, it would provide a place where people could gather and discuss that content. Imagine being able to chat in real time with anyone else who’s currently visiting a site. It could be an incredibly powerful way to make connections. This is a big step beyond our current social networking setup, where people just leave messages amounting to little more than, “I wuz here.”

——————–

On a game-related note, I spent most of my time today working on camera collisions. There’s nothing worse than a game with bad camera controls. I’m trying to build a camera that’s smart enough to keep the player always in sight. This means recognizing when it can’t see the player and moving to a place where it can.

I’ve gotten to the point where my camera can handle direct obstacles well enough. Things get tricky when it needs to avoid objects like the ground. It doesn’t make much sense to look at the player-character through the ground, so the camera needs to recognize when its getting too close to the ground (or something like a wall) and move to a safe spot along the vector between the camera and the player. This involves a lot of math for an English major, so I’ll just have to take it slow.

Ok, so my last post wasn’t exactly about real-time battle systems like I said it would be. This one is.

As I mentioned previously, there are advantages to a real-time battle system (like World of Warcraft or most other MMOs). For one, you don’t need to whisk the player off to a “battle mode” that exists in some parallel universe. Another big advantage is that battles can be more realistic. Enemies and party members can attack and be attacked at any time, and there doesn’t need to be any god-of-the-battle AI that dictates when each character or enemy is allowed to execute a move.

As you might expect, these advantages come with their share of tricky design decisions. This is the first in a series of posts that will discuss some of the common ones. Where to start?

Timing

Attack speed — At first glance, timing seems easy. Each character or enemy has an attack speed, probably determined by some stat or the awesomeness of your weapon.

Cooldown — Ok, that might be enough if all you do is flail about, but what if you want to give your player a special “extended flail” skill? You wouldn’t want him to be able to string these together endlessly (it just wouldn’t be fair), so you need a cooldown time for each ability or skill.

Charge time — So now you can’t eliminate your target with an endless string of “extened flail,” but couldn’t you just string together every skill in your arsenal and gank your unsuspecting target that way? (Indeed, this is the method used by every god-forsaken rogue in World of Warcraft.) This wouldn’t be too challenging, either (yes, I played a mage), so you also need to implement some system where abilities require time to execute. Then you need to decide whether the charging process can be slowed or interrupted.

Down time — This is similar to cooldown, but instead of affecting a single ability, down time affects your ability to do anything at all. After executing your supremely powerful “nuclear meltdown” ability, there might be a period of time when you can’t execute any new moves, which leaves you vulnerable to the giant cockroach monster that survived the meltdown. Final Fantasy XII used down time instead of cooldown; WoW imposes a uniform down time of about a second after each move, in addition to skill-specific cooldown.

Easy enough, right? Part 2 will cover the intricacies of enemy AI.

Hello, my name is Ben. It has been one year, five months since I last played World of Warcraft. I am proud of my resistance to the temptations that keep tugging at me, like The Burning Crusade, the fact that all my friends and family still play, and the peer pressure brought on by the Scroll of Resurrection.

Despite my resilience heretofore, I find it hard to escape the shadow of WoW that looms over my game. This is particularly obvious in my control scheme. Left click to look around your character. Right click to turn him. Scroll wheel to zoom in and out. Some of these are standard features of PC RPG controls, but I find that as I refine the controls, almost all my decisions are made by furrowing my brow and trying to conjure memories of how they did it in WoW.

As you might imagine, this is cause for concern. The easy thing would be to grab The Burning Crusade free trial from my bookshelf and fire up my old account. (I stood over the trash can for a minute after receiving said free trial but could not bring myself to toss it. Now it just watches me work.)

No, the right thing to do is mimic the intuitive parts of the WoW control scheme then try to improve on the frustrating bits. I don’t want my game to look or feel like WoW, but genre is a useful thing and must be acknowledged, even as it relates to keyboard input.

Now if I could just remember those frustrating bits…

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).

• 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