Nuts and bolts, reaching your toes.

So you’re wondering where the TOEs update has been, right? Well tough turnips. What do you think this is, an official blog or something?

I’ve been working on a bunch of things that have been choke-points for others on the team, such as work to support Ramp, work to get this and that into testing (hulks, per e.g), some GM tools, a couple of long-standing bug fixes, and etc.

TOEs, as a project, is still work in progress, and possibly it will be a 1.24.x project because we’re nearing a sort of critical mass for some of the other work in 1.24 so far. We’re also spending a lot of think time on Brigade Spawning and trying to make sure that we are as prepared as possible for introducing it.

As many players have pointed out, if spawn lists come to depend on HCs as well as everything else, then the pooch is going to be having many, many, many babies.

Which really means that getting the OIC system going. The OIC system is about creating a role between that of HC and ‘regular’, into which either the assigned HC-OIC for a brigade can step or HC officers can appoint players into. The plan had been to make this a major feature set over an entire patch, but right now we’re looking at a minimal implementation of this to companion TOEs or possibly preceed it by a point version (1.24.x vs 1.2x).

Frankly, if we don’t, I suspect we will be dragged around in headless chicken mode trying to fix all the symptoms of problems that TOEs without OIC create. Kinda like the way we’ve done everything but TOEs since we introduced “AOs-as-a-temporary-solution-for-underpopulation-until-we-get-TOEs-implemented-in-the-next-release”.

My concept for OIC is fairly simple but involves adding a link between at least one brigade and any given attack; any number of brigades can join the attack, but one brigade has to be in-charge so that you can tell who is in charge of the attack.

Thus if you mouse-over antwerp it should tell you

Antwerp. BIC: 1st Guards Brigade. OIC: KFS1

We do then later have to revisit this and provide OICs with various additional tools for exchanging information with the mission leaders in his brigade. My thinking is to create a “/brig” command for communicating with OIC, HC and mission leaders in your brigade who have the brigade channel tuned. (A sort of sub-channel). Possibly giving access to non-leaders too but with a throttle on the rate they can send, and making it a one-way deal (they can send but not see), and, of course, allowing the OIC to block a player from using it.

Unfortunately when we’re in this sort of testing phase, we Rats are generally doing impressions of spinning tops, with about 15 minutes to work on any given task before someone/something else tries to cross your desk :)

19 Comments

My toes are very warm in my socks!!!

TOEs without revamped OIC presence and functionality has been my biggest worry (that, and the well-being of Dr. House…I live a simple life). It would be great if we saw the OIC stuff just before the TOE stuff.

Just once I would love to see one of the junior docs say “I have a cunning plan…”

lol, yeah I think that would go over well with his longtime fans, and it wouldn’t have to be done in a cheesy way.

Personally I think the OIC deal should be done before the TOE. From what I gather, the TOE system basically requires OICs in order to function as designed, meaning that you can’t impliment it (or at least impliment it well) without having the OICs. OICs don’t require the TOE to work and can be adapted to the current situation if need be, allowing for a more gradual transition (provided they aren’t both ready at the same time, that is, which is obviousally a best case scenario).
Then again, the TOE have been mentioned to the public at large, so I’m guessing there’s some pressure to deliver just because of that. I guess no developer should ever talk about the future in an MMO…

I’m glad to hear that brigade OIC’s will also consider non-HC players. I think this will become the most common case, where HC players worry about top level things and non-HC players worry about a particular attack or more commonly a particular defense, which fits right in with Brigade OICs.

Hmmm…you guys seem to really be investing in leadership and command type tools and features. I hope it pays off.

I would take a different approach and try to make the game more “reliably fun” without human (subscriber) intervention. What good are all these proposed features when people STILL cant reliably find good action? It seems you are trying to make battles better, and create more good battles, rather than better connect people to the many already good battles that exist.

Trout

Sorry, Trout, but those good battles exist because of human intervention. Before we had human intervention (AOs) there were countless crappy battles with the occasional, accidental, worthwhile fight. The current battles flop from the lack of visibility of the chain of command that exists even outside of the game’s structures. Reality: Each attack usually has an OIC, but people flop around asking ‘whos in charge of this?’

And we’re not trying to do anything other than get TOEs into place so that we can finally ameliorate/remove the stop-gap implementation of AOs.

The idea of a named OIC is a good one. There are those who take part in battles who are looking for direction toward cooperation. Cooperation in battle does make for a better fight.

Along with a named OIC comes algorithms for selection and succession. The same problems we have with an absent mission leader now could recur. I look forward to an OIC but hope it does not further delay TOE.

We know that the game is designed for mission leadership, players are objectively more effective in coordinated mission teams, and in the opinion of many, fights between coordinated mission teams are the best available from any such game. We also know that many players–at least a large minority–apparently do not know this and continue to play the game in an independant manner. Thus gameplay very often consists of fights between (Killer’s terms) untrained rabble, not fighting forces.

This might be seen as a shortcoming of the already-existing mission leader system.

Perhaps this occurs for three reasons: because the Rats don’t continually educate and convince the playerbase that they must play in teams for the game to work at its best, and particularly that even a small amount of independant gameplay has an anti-synergistic effect on the whole game combat environment; because the game mechanics continue to cause players to think of the game’s key actions and rewards for those actions as individual, not team; and because the game doesn’t incorporate sufficient physical, as opposed to psychological, reasons for individual tactical gameplay to be as coordinated platoons with close physical cohesion, such as enhanced needs for ammo pack exchange and proximity-dependent UI/communications/intelligence-information-sharing functionality.

Some of us hope that the OIC system will be supported by game-mechanics changes along these lines, to strengthen the mission leader system and thereby provide a stronger foundation for positive OIC impact.

The game has improved in the ability to grasp the situation on the battlefield. I remember when the only way to tell which depot was held by the enemy was to look at the online map viewer on the website. Then that information was made available through a text command and now visually on the map.

The ability to display enemy contacts on the map was also a great improvement to the commanders view of the development of the battle.

What I would like to be able to see is the location of a mobile spawn on a mission before spawning in. I can see who is on the mission and if on the mission can see where the mobile spawn is located. With mission leadership changing frequently and often more than one mobile spawn available from a brigade it is very difficult as a commander to know where mobile spawns are located both to direct troops toward them and to see where additional mobile spawns are needed.

Egbert, isn’t keeping tactically secret the location of MSPs a key to their current design? As such, putting them on the map seen by fighters would be a fundamental design change, in that there would be an increased tactical advantage to a side that had a tactical spy on the other side, able to report on the contents of the tactical map.

It might be possible to put them on a map version seen only by MLs, and certainly they could go on the map seen by OICs…but at that level the info would be useless for the inform-the-players purpose you suggest.

Some time ago Gophur talked about a possible design future in which all major ground weapons usage would be by fighting ranks, say below junior lieutenant, who would have minimal access to tactical command info and would basically be pointed at what they were to capture, destroy or defend. Next would be a tactical command layer that would know more locally, but would participate in battles using light weapons. Next would be an operational command layer that wouldn’t fight in tactical battles at all, and then of course a strategic command layer that would function in staff modes and operate independently of tactical maps.

Is the level of information becoming available on tactical maps getting us into that future of player-role-specific information access?

I would not want to see every MS on everyones map who has the same target. The MS is now on the map of the mission spawned in map but not on the mission map before spawn in.

It is possible to see everyone spawned in on the mission and what equipment they have before spawning in. I would like to be able to see where the MS is on that mission before spawning into it from the mission screen.

Hmm…What I think is best about AOs is that they signal to the playerbase WHERE there the good battles are to be found.

I think for quite some time now the QUALITY of our battles (battles=all the missions for a given operation) has been good enough. What is lacking though is the mechanism that easily connects people to them.

THis is the difference between building an outstanding product and marketing it. If people cannot reliably find your best products, they will only be of use to a narrow margin of your customer base who already know it is there.

I’m less impressed with fancy command tools and other “advanced” features than I am with any features that would better “flag” certain types of popular missions, or otherwise stream people into them (eg: instant action button )

Trout

———
KFS said,

“Sorry, Trout, but those good battles exist because of human intervention. Before we had human intervention (AOs) there were countless crappy battles with the occasional, accidental, worthwhile fight. The current battles flop from the lack of visibility of the chain of command that exists even outside of the game’s structures. Reality: Each attack usually has an OIC, but people flop around asking ‘whos in charge of this?’”

“Some time ago Gophur talked about a possible design future in which all major ground weapons usage would be by fighting ranks, say below junior lieutenant, who would have minimal access to tactical command info and would basically be pointed at what they were to capture, destroy or defend. Next would be a tactical command layer that would know more locally, but would participate in battles using light weapons. Next would be an operational command layer that wouldn’t fight in tactical battles at all, and then of course a strategic command layer that would function in staff modes and operate independently of tactical maps.”

I think the game already suffers too much from spy paranoia. I think the player radar should show all units that are on you side. Why not? reason=spies

Kfsone,

Have you ever considered having an “AO Page” in the UI that could be managed by the OIC? I don’t mean as a replacement to the current system but an addition.

Here the OIC could manage the missions and provide info about the battle to players.

On the left would be the mission management section with a list of missions at the top with a box in the bottom half. The OIC should be able to name each mission in the list (“FB AAA defence”, W CP Defence”, “CP attack”, etc) so that new people coming in can see what the missions are for easily to decide where best to help. When the OIC clicks on a mission the box is filled with information about the mission. Below that box would be a chat box the OIC could use to communicate with that mission’s leader, which would show up in the ML’s chat in some way that makes it stand out (maybe Brigade chat should be only for mission leaders and OICs). For the grunt coming in to help, the chatbox would be used to talk with the OIC to get info about the battle and ask where help is most needed.

On the right side of the page would be the map centered on the AO that the OIC could use to put markers, comments, waypoints with orders, etc. On this map the OIC should be able to see all active spawnpoints including the MS’s and should be able to see who’s mission each MS is.

Any thoughts?

Actually, player radar doesn’t show all units on your side because that would crimp on showing everyone on your mission. That’s really a bandwidth thing. We wanted the list to be defacto.

Yes, Drkpatch, I’ve considered it oft and deeply. Now all I need is a UI *I* can make pages in ;)

Ok, you got me. That was worded as a question but was really me trying to solicit my idea.

When Ramp/Rick were building the UI, I kept trying to explain to them the subtle distinction between Component and Widget. Components are something you use to make something else, a widget is mutable and is usually intended as a component of other components.

If you use a red brick as a component of a wall, you’ll get a red brick wall. A widget brick would be able to adapt its size and shape to conform to the other bricks its surrounded by, might inherit its color attributes down from the wall itself or specify constraints on the other bricks around it based on its place in the wall. And if you give the widget to a child, it might adapt itself to be rubber rather than brick.

Widgets can have no visible appearance or function, except to mutate the widgets above, below or around them. Most HTML tags are components, but some of them – e.g. the table tags like and are actually ‘widgets’.

Think of the Guiness “widget”. The can that contains the Guiness is a component of the product, but the widget is a widget. It’s simply a gas exchange, but when placed into a can of beer it has a very specific function – as a result of context.

You can turn a widget into a component by severing the inputs to its properties. If you have a “widget” that displays the map, you can create a “map in a box” widget from it if this second object can adapt to the map and can pass its properties down to the map. But if you display a fixed instance of a widget with strict properties (e.g. ) then it is a component.

When you start from scratch with this in mind, whenever you need to add something, you make a widget for it, and then instance that widget into your final components.

Example: Town labels. On our map we display town labels with color coding and etc. The colors are hard coded, so when Ramp was making 1.24 changes to color code missions and brigades, he didn’t think to go find those same colors to color the brigades. He had missions under-attack (defense towns) marked red for danger, missions that were attack objectives marked blue, and resupply/etc missions marked green. And not the same red/blue/green either.

To my model of thinking, the colors should be property widgets or widget-properties; and the decoration of town names should be made into a widget that puts a border around the town to indicate the AO type and colors the town name according to enemy/friendly, so that everywhere a town name is displayed, it is marked up the same way.

Doing that now means copying & pasting 4-8 lines of markup, where it should be

The other thing I’d asked them to incorporate was a ground-up concept of drag and drop. Neither of them was convinced it would be difficult later, same for context menus and … well, apparently I’m not wrong :)

I’m telling you this because from the very start I had a design for a Strategic Management page that had left-side buttons like Ramp now uses on the map. It had a legend which doubled as live information, from which you could drag icons representing free AOs to place them, icons for tactical objectives and to indicate mission leaders in the field and where you wanted them to go or what you wanted them to do, all operable by simple drag and drop.

For the mission creation page, the paradigm would have been equally simple. A legend on the left, and drag the target and objective icon (or both) to the town in question.

There’s much less ambiguity with drag and drop, and what there is can be resolved with context menus.

Leave a Reply

Name and email address are required. Your email address will not be published.

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 )

Google photo

You are commenting using your Google 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

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: