Oodalooping the Trinity

I’m going of on a bit of a curve ball with today’s post – I’m not entirely sure how it’s going to work out but you know, bear with me.

Two (seemingly) separate posts caught my eye recently, the first is from the eve-online forums and a thread started by Charras Washington asking if the EVE Universe was going to get any bigger.  CCP Greyscale offers some interesting observations on this topic and the wider topic of ‘local chat’:

“Ok, the problem with local as it stands is that it’s a completely effort-free intel tool, which gives away too much information too freely, makes it harder to do some things that should be easier (like ambushes) and easier to do some things that should be harder (like finding targets or running away), and short-circuits a lot of opportunities for really good gameplay. Or, tl;dr, it’s just a bit lame.

The problem with just sticking it into delayed mode is that 1) it’s going to make it less likely that you just start chatting with people in space (this is kinda a fringe case, I know, but it pushes the universe a lot further into Greg Bear’s Anvil of Stars territory), and 2) (in my opinion) it will make roaming gangs suck completely. Everyone’s excited about the idea of ganking ratters, but if you tell them someone’s jumped in but not who they’re going to safe up in most cases anyway, and if you don’t show a local count, how exactly are you going to find targets? I can’t think of anything more tedious than going for a roam with a few friends and having to directional-scan around every single system to check for targets, particularly given how much crud is left hanging around at starbases.” – CCP Greyscale

The second comes from the KillTenRats blog which quotes a recent comment by Richard Bartle regarding the ‘Holy Trinity’ of gank, tank and “healer” (or logistics in EVE).  Here’s that quote in full:

” Now if, back in 1978, you’d told me that there were going to be three main character classes in future MMOs, I would probably have assumed some kind of rock/paper/scissors relationship among them for reasons of balance. Archers beat infantry, cavalry beat archers, infantry beat cavalry — that sort of thing. I don’t believe for a moment I’d have gone with what we have, which is the “trinity” of tank, heals and dps. The tank takes all the damage issued by the opponent, the healer reduces this damage, and the dps gives damage (dps is “damage per second”, non-players) to the opponent. This doesn’t make a great deal of sense in gameplay terms: the healer is redundant (they’re basically just armour for the tank), the premiss is unrealistic (“I’ll hit the guy in the metal suit who isn’t hurting me, rather than the ones in the cloth robes who are burning my skin off”), it doesn’t work for player versus player combat (because players don’t go for the guy in the metal suit) and it doesn’t scale (a battle with 1,000 fighters on either side — how many tanks do you need?). Don’t get me wrong, it can be a lot of fun, but it’s a dead end in design terms.” – Richard Bartle

Richard’s comments are interesting in that the MUD1 combat process was not unlike that of EVEs – there are no ‘body block’ or line of sight considerations which means that the tactic of concentrated fire (multiple ships firing upon a single target) is the norm.  Switching fire, or spreading fire across multiple targets sometimes occurs in order to over stress the availability of logistics ships (the ‘heal’ element) to repair or support a fleet but the ‘holy trinity’ is still predominantly in play.

So what have these two apparently disconnected themes have in common that’s worthy of comment? On the face of it, not much – one is looking at the ‘big picture’ of the intel a player has – his “situational awareness”.  The other is down at the nitty gritty of the fight itself – up close pew pew.  However Id argue that both of these are directly related.

During fleet fights we typically run through an OODAloop cycle which (if youve not heard of the term) runs as follows:

OBSERVE: We look around us, what’s there? “Ooh look blinky 4 Battleships”

ORIENTATE: We place ourselves in context.  “Eeek theyre 10km from me!”

DECIDE: We consider a range of options. “Can I beat them? Run Awaaaaay?! Fire all lazors!!!?”

ACT: We select a course of action. “PEWPEWPEWPEW!!!”

And then back to the top again.  Military strategists will tell you that in order to improve your odds of victory / success in any engagement they thing to do is beat / break your opponents OODAloop cycle, ideally to the point where they never get to the ACT part as their OBSERVATION tells them that something has changed requiring a new set of decisions (e.g in the example above another 70 Battleships jump in).

The key bit here is the OBSERVATION bit because that’s where the ‘local as an intel tool’ comes in.  To demonstrate where Im wandering with this let me pose a scenario to you, paint your situational awareness if you will:

“You jump your small gang of 5 crusiers into a system. Your scout was correct and there is 1 Battleship 20 clicks of the gate”.

Now in an ‘open local’ scenario (as EVE runs today) the presence of 5 other hostile corpies in local would effect your decision: engage, or not engage.  Now lets pose the same scenario only this time local is in delayed mode. Are there in fact 3 logistics cruisers and 2 falcons cloaked 30km from the battleship??

In my view here in lies an opportunity for EVEs developers – what if within a given frame of reference/range you had a 4th member of the ‘holy trinity’ which would contest the state of that ‘local intel’?

I would suggest that rather than go for a rather boring ‘local is on or local is off’ choice a more interesting option would be to have that state defined by the players themselves.  How would this be achieved??  I think there are two broad approaches which could work very well in tandem with each other:

First off is the ‘anchored structure’ – an Intel Beacon / Suppressor Beacon of some kind; fairly small and HP weak making it a nice ‘small gang objective’.

Secondly is the EWAR ‘Platform’ (possibly a new set of modules, or adaptation of the existing Ewar modules)  that contests the state of a small area of space and the ‘local channel’ attributes: possibly even the overview and targetable objects themselves.

I use the word ‘contest’ quite deliberately because what I envision is something of an E Warfare battle ongoing in, and around, the use of conventional ‘kinetic’ weapons like blasters or pulse lasers. A suitable UI layout (perhaps utilising the Solar System Map) would demonstrate to the player which areas had suppressant / boosted Local coverage.  The use of active ‘e warfare’ (like dropping Intel Beacons, advanced probes etc etc) would all combine to produce a secondary fight – over the electromagnetic spectrum.

Of course these wild ideas are unlikely to ever come to pass but Id hope that CCP looks beyond the argument of switching local ‘on’ or ‘off’ and considers there is at least some game design room there to manoeuvre in.


5 Responses to “Oodalooping the Trinity”

  1. Digital Ninja Says:

    VERY excellent post. I was worried you were going to go with an only skill/ship system to increase/decrease local delay. And that would just mean another skill that every player will train and max or another ship that every fleet has. But doing it with either ship or object gives it some neat tactics.

    • Thanks 🙂 I think there might be ‘some’ skill applied in the generic use of the examples I’ve given – rather like you need a basic level of character skill to use a mining laser or a scan probe launcher – if only to provide a degree of ‘profession’ and to define such a role a little more. Certainly I wouldn’t want to see ‘Ive trained nerfing local to V, I win!’ as that has no ‘player skill’ applicable to it. In essence the idea of ‘fighting over local’, either with physical force or on an alternative plane appeals to me and adds some interesting tactical twists to warfare ‘in space’ which, after all, is what EVEs PVP is all about.


  2. Very nice idea. It’s an obvious way to make things in 0.0 more interesting. I am living in W-space right now and the nicest thing is, that you don’t have any “local-channel” intel available.
    Being able to establish intel via special structures/enhancements of your system gives the concept of cultivating your 0.0 system a new spin, although I never would want this kind of feature to be implemented in W-space
    BR Qumar

  3. the idea of an anchored structure is very very nice.

    If you allow me i would like to expand your idea. An anchorable item that could be put around planet (and only around planets) will create a “bubble” of signal distortion rays so that everything is inside that bubble can’t be seen using the local or the directional scanner (and why not… even probes).

    The limit of anchoring it around a planet is because if you would be able to put it everywhere you want… you could lose the bookmark and then the local in that particular system would be ruin forever.

    Let’s say that there could be different kind of them so that some of the (the small ones) could be used to hide just ships… while the more advanced versions would be used to hide POS in lowsec / wormhole. The module itself shouldn’t be probable… and could appear only on the overview when you’re closer than 400km – aka be in the same grid.

  4. Good in depth post.

    I liked this idea about local:

    Basically (quote from thread): “0.0 Local Chats will have a delay of 45 seconds before your name appears in the local window regardless of any actions performed (unless you speak before this time is up, much like how you appear in WH space local if you chat)”

    It’s simple and elegant and solves a lot of the problems discussed imo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: