Red Brick Games

Archive for February, 2008

Back to natural dumbness

Friday, February 29th, 2008

I’m back on the task of making the A.I. reason from a personal, imperfect view of the world. Like I mentioned earlier, there’s lots of work involved there. Ugh. But, I’m well underway on the task, and it’s going reasonably well, all things considered.

This task also kind of dovetails with cleaning up the pathfinding API, which will possibly help me package up and sell the pathfinding code in the future. I’m seeing though that there’s considerable work to do there, so that won’t happen in the immediate future.

And along those lines, I’ve also been thinking more about how to recoup my investment in Orcs vs. Martians. There may be other parts of the code I could also sell, like maybe the fog-of-war implementation.

Anyhow, I’m feeling pretty good about the project as a whole right now. The A.I.-personal-view-of-the-world task is probably the biggest, hairiest task left on my list. Once that’s done, it kind of looks downhill from there.

Remaining work generally involves the A.I., squad handling, ease-of-use features, gameplay tweaks, graphics improvements, optimization, optimization, did I mention optimization?, 2-D art, 3-D art, and bug fixes. Lots of work, but not exactly what I’d call rocket science.

I hope OVM ends up being a game that people like and that sells. After two years of working on it, I still find myself playing it. For fun, not for testing. That’s a good sign.

I think probably that people who like the strategy aspect of RTS’s, will like Orcs vs. Martians. I’ve really worked hard to fight the micromanagement “issue” in the RTS genre, to free up the OVM player so he can enjoy directing high-level strategy. On the other hand, I’m not sure whether people who like the RTT (Real-Time Tactics) aspect of RTS gameplay will like OVM too much. OVM has few unit types and doesn’t really emphasize tactics.

I guess I could try to make it please both crowds. But I think that’d take significantly more work. And doing that might also dilute OVM’s focus.

I’d rather make a game that does its core gameplay well — and make its core gameplay be what I enjoy, because that’s what I know.

Posted in Pathfinding, A.I. | No Comments »

Mystery, part 2

Saturday, February 23rd, 2008

Mystery solved - the problem wasn’t network overflow or dropped notifications, it was my own code not handling variable network latency! A few details are below. The bug should be fixed now - “remote control” harvesting / paving should no longer happen.

And with this fix came two bonuses -

it fixed another problem where workers occasionally skipped action animations, like missing an axe swing while chopping a tree! That problem was in the Beta, too. Turns out, the fixed bug was directly responsible for that problem as well.
it revealed some code that was wasting network bandwidth, sending unnecessary notifications

I’m still ironing out the solution, but two long-standing mysteries have been cleared up, and OVM’s network utilization has been lowered, to boot! To quote Wallace and Gromit,

That went as well as could be expected, didn’t it?

Technicals

There are always slight variations in network latency, and I had some code that presumed that worker actions were uniformly spaced apart in time. That’s an ok assumption on the server side, but after action notifications traveled across the network, it was no longer true on the client side (pretty close, but not quite!). Consequently, my code ignored the notifications, making it look as though they were dropped. Without the notifications, the units moved differently on the client.

The fix was simply not to require time uniformity on the client side — it’s only really necessary on the server anyway, where it’s done to enforce game rules.

Posted in Networking | No Comments »

A mystery

Friday, February 22nd, 2008

For a while now, Orcs vs. Martians has had a weird problem where a unit’s (RTSUnit) position can become out-of-sync between the client & server. The position becomes wrong on the client, and can be off by as much as several game tiles. People who tested the beta may have noticed this, e.g. when a worker goes to pave a road. The worker sometimes does his shoveling animation while standing several tiles away from the tile he’s supposed to be actually paving. On the server, the worker is (correctly) standing adjacent to the tile, but on the client he’s in the wrong place. Since the client does the rendering, you see the worker paving via “remote control”.

I’ve also seen this bug when workers construct buildings.

What the heck is going on??

Technicals

Maybe OVM is overflowing some network bandwidth limit in Torque for sending notifications to the client? So the server tells the client, “hey, this unit has just changed direction, and is now walking in a different direction.” But an overflow occurs and that notification gets dropped. So, on the client the unit keeps walking in the (now incorrect) original direction, causing him to appear in the wrong place…?

An overflow would explain why the problem is sporadic, and relatively infrequent. But, it’s just a guess at this point…

Posted in Torque, Networking | No Comments »

Dos Años

Sunday, February 17th, 2008

Red Brick Games turned 2 yesterday. Happy birthday, RBG.

(”Dos años” = Spanish for “two years”. Or is it…”two old ladies”? Not sure. yeah, language isn’t my strong suite)

I’ve implemented all the gameplay features I mentioned in the prior post. w00t! The gameplay is basically all defined now. There are still other possible gameplay elements I’m considering (e.g., walls - suggested by several ppl), but they’re not core essentials, so I’ll mull them over as playtesting motivates / time allows.

With that done, I’ve moved over to working on pathfinding for a bit. Which is getting to be more interesting than I anticipated…

Technicals

I’m pretty excited about the pathfinding in Orcs vs. Martians. It’s gotten powerful. OVM’s pathfinding code can now collect multiple metrics on the paths it finds, not just the traditional single floating-point number (usually representing distance). Right now I’ve got it collecting (1) distance, (2) travel time, and (3) damage incurred by enemy fire. The path metrics are then converted to a cost, by a parameterized costing function.

How’s that useful?

Since the costing function is a parameter, different costing functions can achieve different behavior for different unit types. For example, worker units use one costing function, that makes them avoid enemy fire like the plague. Makes sense; workers are delicate and don’t like to get shot. Military units use a different costing function, one that ignores all but the most intense enemy fire, since mililitary units are tougher, and are meant for combat.

The result: pathing behavior that is specialized and appropriate for each unit type, but is all handled by the same pathfinding code. w00t!

If I were to add new unit types, each would need only a new costing function, which takes only one line of code to write.

I could see this system being easily extendable to handle, e.g., air units! (they’d ignore ground obstacles, but avoid enemy AA fire)

I also use the same pathfinding code to lay out road plans; they use yet another costing function (one based solely on distance).

I said I was excited; in fact my head is kind of swimming as I think of the possibilities of this level of flexibility. I can even see pathfinding being used to answer high-level A.I. questions. Now that has me really excited!

For example, say there’s an A.I. base and it’s “thinking” about attacking an enemy fortification. But does it have sufficient troops to win an attack? It can answer that question by pathfinding to the enemy base and summing up all the damage its troops would receive, en route, plus damage they’d receive at the final battle.

If the received damage is more than the total hit points of the troops, then the A.I. base should probably wait and build additional troop strength, before sallying forth.

Or, better yet, the A.I. base could search for different enemy fortifications, ones that it could successfully beat. Even if they are farther away than the first choice, it might prefer to take on those instead.

That could probably all be done with yet another costing function, one specialized for a squad of mixed-type troops.

Seriously, wow.

Ahh. I feel grateful to be at this stage of development in OVM. This kind of work (A.I., etc.), more than any other kind of work, is what I’ve been looking forward to getting to for the last two years!

One other thought, once I’ve gotten the pathfinding code ironed out (and parameterized, and templat-ized, etc.), I’m thinking seriously about packaging it, and seeing if I can sell it as a code resource.

I think it has sufficient value-add, beyond what’s already available out there, to be sellable.

Posted in Pathfinding, A.I. | No Comments »

Run away, run away!

Tuesday, February 12th, 2008

(a reference to Monty Python’s The Holy Grail)

Ok, I flinch. That task about making the A.I. reason based on its personal view of the world, is a little too big to do right now. I still want to do it, but I’m also still debating how, and I hesitate to bite off a task that big at this particular moment.

One reason for my hesitation is, I feel like Orcs vs. Martians is still suffering from a few not-fully-defined gameplay rules. There are still several unanswered questions. Things such as:

if you go to build a building, and there are trees in the way, what happens?
or similarly, if some of your own units are standing in the way of the building site, what happens?
what if those units instead belong to an allied player?
should there be a distinction between raw resources, and finished resources? (where only finished resources, produced at bases, may be used to build with)
should immature trees be harvest-able? if they are, should harvesting them (i.e. saplings) produce fewer resources?

I’d like to nail down questions like those so that the gameplay is fully defined, before tackling the big A.I. personal-view-of-the-world task.

My tentative answers to the above:

trees that get built on, simply disappear. The only problem is, this rule could be somewhat abused. A player could go around, starting new bases and then canceling them, thereby wiping out whole groves of trees. Hmm…
your units automatically move out of the way
allied units similarly move out of the way. An odd side effect of this is, it effectively allows you to move another player’s units. But I don’t think there’ll be any terribly negative consequences from this, and from my gaming experience, it’ll be very convenient. (enemy units, of course, won’t move)
yes. Workers will be required to go pick up “building materials” at a base; they won’t be able to harvest resources from trees or ore and then go directly to build a building. The game already works this way more or less. This rule is a little confusing though, as one tester pointed out, so I need to figure out how to make it clearer to the player…
to keep things simple, no. The easiest answer is to simply prohibit harvesting trees that haven’t yet grown to full-size.

- - -

Posted in RTS maps, A.I. | No Comments »

Artificial intelligence, Natural dumbness

Saturday, February 9th, 2008

Work continues on changing the computer A.I. to use a limited, imperfect view of the world.

Technicals

Not surprisingly, this is turing out to be a pretty big programming task. In all of OVM, there are about 120 places in the source code that examine “the world” (i.e the game map).

For example:

finding enemies to attack
evaluating enemy strength
evaluating locations for new bases
road planning
pathfinding
exploration

Most of those places need to changed to instead examine a player-specific view of the map (while some need to continue to examine the real map).

Ugh.

I kind of cringe at big tasks like these. I hate tearing up the code for an extended period of time, and having the game be unrun-able in the interim.

And the irony is, all of this work is to make the A.I. be dumber.

And once the work is done, the A.I. will be definitely be dumber. So dumb, it’ll be nearly unable to play. The reason for that is, once the A.I.’s God-eyes are removed, it’s going to need to explore a lot better than it currently does, in order to play. Currently, the A.I. just sends out an occasional explorer at random intervals, which won’t help it much. Until that gets remedied, the A.I. will play like a near-idiot.

So a follow-on task will be to make the A.I. figure out when to explore more, and by how much, and then make it do so.

I sure hope this effort will be worth it in the end. I’m banking on a belief that a more “natural” A.I. will be more fun to play against, rather than something artificially all-knowing.

Posted in A.I. | No Comments »

I’m sorry Dave, I’m afraid I can’t do that.

Tuesday, February 5th, 2008

- HAL 9000, 2001: A Space Odyssey

Good news on the A.I. front!

Workers now avoid danger!

When an enemy builds fortifications, your workers will no longer harvest in that area. They don’t want to get killed! Instead, your workers harvest elsewhere, even if “elsewhere” is farther away.

And, if you send your army to take out the enemy fortifications, your workers will resume working in the original area!

w00t! Workers that are smart! What a concept! :)

The A.I. is starting to reason based on only what it can see

I’ve started to remove the A.I. cheat mentioned in this post. Double-w00t! :) This is really exciting, because it makes the A.I. fairer, and much more human-like.

So far, I’ve got the pathfinding working without the cheat. So, if you build fortifications, the first time the A.I. ventures out, he’ll blunder right into them. But after that, he’ll pathfind around your fortifications if possible, because he now knows where they are.

This means if you build defenses on a single side of your base, the first time the A.I. comes at you, he may impale himself on your defenses. But on later attacks, the A.I. will intelligently try an alternate route, perhaps coming at your base from behind.

There’s other code (besides pathfinding) that needs to be modified to fully implement this feature, so it’ll be in-work for a while.

The exploration algorithm is working!

The exploration algorithm I mentioned a while back now fully works - it can both explore never-explored terrain, and re-explore already-explored terrain.

- - - - -
I hope to make the A.I. in Orcs vs. Martians be some of the most enjoyable A.I. to play against, of any RTS out there. Your units will try hard to avoid being stupid, and the enemy A.I. won’t cheat (*cough* Starcraft *cough*).

Leaving you, the player, to have fun focusing on the “Strategy” part of “Real Time Strategy”!

In other news, the first pre-pre-preview of Orcs vs. Martians has appeared on the web! Courtesy of Wolf_Dreamer, head on over here to read it!

Posted in Pathfinding, A.I. | No Comments »

Archive for February, 2008

Back to natural dumbness

Mystery, part 2

A mystery

Dos Años

Run away, run away!

Artificial intelligence, Natural dumbness

I’m sorry Dave, I’m afraid I can’t do that.

Visitors

Archives

Categories