Wednesday, May 23, 2012


So, this last Saturday (the 19th) was one of the bigger playtests of World in recent memory. I took the excuse of a Diablo 3 LAN and made some peeps play the game.

For this purpose, I decided to make a new type of scenario to hopefully make the game a bit more dynamic. Actually I wrote a whole bunch of new stuff, so it was perhaps good for inspiration to work if nothing else. I think this post will be a combination mini-postmortem and World Update.

New stuff written for LAN:
  Territory Control scenario type:
     Team score / Team score boosting actions / Team score winning conditions
     Auto-join smallest team.
     Mid-scenario respawn for dead commander groups / players.
  Database functions:
     Can make interactions from GDocs.
     Interactions can channel.
     Added 'SoloGrant' effects, which grant an ability to the target, but when granting to subsequent targets will remove the grant from the first (so that only 1 has the grant at a time).
     Units can join the commander now via interaction (territory control points use this).
     Built two new types of enemies with some new tech needed: Earth and air elementals, they use a different rig and have some different abilities (which were too strong)
     Added per-enemy grant state that stacks for every hostile player in the game. This scales up enemies for multiple players.
     Updated logic that connects gridcells together; it can now span empty area for knockback/projectile paths, so non-infinite slopes can still have knockbacks/projectile fired over them.
     Did a lot of cleanup work to allow building a fairly large scenario map.

Stuff written that I probably haven't mentioned:
   Primary units can now res unconscious commanders by using a long channeled action. The commanders' action bar is replaced by a button that grabs any available primary to do the res. This channel is 'weak', and is interruptable by any damage, in addition to normal interrupts.
   Maneuvers update; no longer transition between formations.
   Out-of-combat idle animation switch.

How'd it go:
  The scenario was too big and the client chokes. The ray intersections needed to run locomotion for all the entities, even just the ones in close proximity, brought it to a painfully low frame rate. I think I'll get rid of loco. For the LAN I just had to remove a pile of units, making it boring-er. On top of that, the scenario map was probably a good 3 times too big; it's really easy to mis-estimate size when building maps. Traversing the map would've probably taken a good 2 minutes at normal walk pace, withOUT enemies killing you en route.
   The navigation and pathing code for formations broke pretty bad too; that system may need a fundamental readdressing, rather than tweaks. Occasionally groups just stopped behaving reasonably.
   And, the scaling was WAY WAY off. Each single enemy was massively massively overpowered with the per-player buff in place. As in, a single kobold being nigh-unkillable, rather than dead on arrival. The elementals in particular were extremely unforgiving. A higher level group (10ish) with some game knowledge, can fight them and its hard. Level 1 groups (since the kobolds were too hard and I removed most of them, noone levelled), with introductory players? They died. A lot. At least they have respawn :p
   BUT. Aside from one server bug that I patched up really realy quick, the server managed running the scenario with 4 players without too much trouble. The combats worked, even if they were unbalanced. The new mechanics written for the scenario worked, even if they weren't terribly relevant.

And hopefully people had at least a little fun.
The final score was 200 to 198. Of the 6 control points, 3 of them were actually reached by players. There were '0' PvP combats in a PvP scenario, but there was plenty of death caused by the random assortment of PvE mobs on the map.

air elementals are fun :)


Tuesday, May 22, 2012

AAgggh Movement is complicated

(I think I wrote this a night or two before the LAN at 4:30 and forgot to publish. Given how the LAN combat went, it may be amusing)

Moving in formation is complicated!

Turns out we have 4 conflicting criteria we need to reconcile in order to determine where a unit is moving. The user's specified target location, the current formation estimate location, the class-specific ideal distance (from their target, for attacking), and the class-and-mode-specific leeway, which gives units a range to roam in around their formation centerpoint.

The latest bug was that leeway was never usable, because the importance of following the user target location was guaranteed to be greater in all cases. There's more, but now I sleep.............

Tuesday, May 8, 2012


It's been awhile since I wrote a design thoughts essay post. I've been intending on writing this one since before it implemented and sequentially changed. So, without further boilerplate:


A maneuver, in the context of a World skirmish of course, is an action invoked by the commander, used to change between formations and locations in a specified manner. The intent was that a maneuver would be used to quickly change between formations in combat situations. The end result and implementation were a bit more complicated.

Let us define the exact details of the maneuver in the Skirmish context. A maneuver consists of 4 stages, a windup (channeling, which can be broken, and an associated buff state), initiation (which triggers class specific actions), advancement (moving to the target location, which can also trigger class specific actions), and finalization (reaching the target location, also triggers class actions). Notice an awful amount of detail hooks there. Each class specifies how it behaves for each maneuver. A shieldman may conclude a maneuver with a shield slam. An archer may lead a maneuver with a volley of covering fire. The commander may provide a group buff while advancing. Furthermore, the commander will have multiple maneuvers, so each differing kind can have different per-class hooks.

Except, that's rather massively complicated. The first maneuver we made is a simple 'Charge' maneuver; run at the enemy and engage rapidly. If we make a second maneuver that is similar, should it have entirely different class actions? Nah, let's categorize maneuvers. Now, all 'Charge' maneuvers share the same actions. This lets the commander upgrade the maneuver without forcing us to re-implement all the maneuver-actions. We could make a 'Charge 2' (for lack of a better name atm) that winds up faster and provides a speed increase while running, but now it otherwise acts exactly like 'Charge 1'.

So now we can run at things and have new class differentiation points. Yay! What about other kinds of maneuvers? A coordinated retreat is kind of like a Charge, except away instead of toward, so the implementation there is easy. We make a new maneuver category to change class actions and it works without problem. A slow pressure advancement works similarly. After that we created a 'Hold' or 'Stand your ground' maneuver command. This one was different, in that there's no movement phase, and the ending triggers are different, but it still works. The same logic can be used to make a maneuver that just tries to get the formation back in order quickly.

So 5 maneuver types; Charge, Advance, Retreat, Hold, Reform. They almost perfectly correspond to the 5 formation movement modes (Charge, Advance, Defend, Retreat, Hold), which is cause for thought. Should maneuvers replace formation movement entirely? We concluded that no; maneuvers are a specific command with costs and benefits associated with. It would be silly to run with a charging sprint as your default move command. Sometimes you just move.

Implementation took a bit of effort but there was nothing terribly interesting to report about it. We've had the maneuvers in place and working for a few weeks now, so they've been used enough to know that Charging is Fun, Advancing is useful, Hold has potential but the current scenarios do not require it, retreat is occasionally necessary and the only reasonable way to extricate a group from combat, and reform is... well, a little less interesting, but it COULD be with more maneuver-actions by class.

A success? Well, sort of. Remember that part above where I said that a maneuver is a method of transiting between formations? Turns out we never did that, but we always have to specify the target formation anyway. So, why is this part ignored?

My opinion now is that the original concept was flawed, because it was based on a different pace of combat than the game actually exhibits. If you imagine a combat where units stay rigidly in formation, there is very little motion, and slight positioning different matter tremendously, then special methods to adjust inside a formation are relevant. This was in part the original concept. What we have now, however, is a massively more fluid, dynamic, and mostly chaotic combat engine. Is this good? The chaos is kind of enjoyable when you're the cause of it (which may be why Charge-ing is Fun :) ). With retreat/reform you can manage the chaos inside your group enough to not be bogged down. Advancing does a reasonable job of slowly pushing forward with a more organized wall. I think it works! Let's keep it. But what do we do about the maneuver definition?

Meh. Delete it.

We'll see how it plays without formation swapping; I bet it'll work fine.

Next essay I'll talk about Consciousness, or more specifically, lack thereof, as a game mechanic.