Crucial notofications

[Pak40]

I did see your previous post, but I'm looking at it in the opposite direction. Instead of getting an alert each time a new unit is spotted (because how do you know if it is really a new unit or not), you should get an alert each time one of your units makes its first spot. This essentially differentiates the unit from a condition of having made no contacts vs. a condition of having made a contact. This is at least what I envision.

After thinking about this a bit more I have another thing to add...It's basically not going to work well the way you envision it for a lot of scenarios. Basically what will happen is that a majority of your units will see one or two enemy scout units, probably at an extreme distance where there is little or no threat, thereby ruining their alert system for when you really need it.

Of course, this depends on the map geography and your unit setup etc... But, by and large it's just going to lead to mostly useless information and it will let you down just as often if not more than when it actually helps you.

For example, it will be next to useless on more open maps especially if you're on defense. Your units will see the enemy coming from a long way before you even need to be alerted. Even if you're on the attack, the majority of your units will likely see the same few outpost units, blowing their "load", so to speak, way too early against relatively nonthreatening units.

I can see it working sometimes in a heavily segmented maps such hedgerow country, but it's only really useful in real time games where you can actually react to the newly discovered threat.

[pord]

@Pak40

Concerning first contact notifications, I think I'd change my stance and agree with you based on your last argument. Notifications of even first enemy contact would largely NOT be considered "crucial" information. As you said, it would mostly trigger at the beginning of the game when first contact is being made, and first contact is quite often not meaningful contact.

But, perhaps this discussion is all for naught if it can't be programmed as was suggested.

[Guest]

Okay. The first time I need to say I'm disappointed with you guys

Why?

You're probably not going to answer, but I wonder what's the point of distributing Qt binaries along with CMFI and CMBN 2.0 if it's not related to the new features (and look & feel) in them, then. If it's not the engine, then it needs to be something else. Let me remind you this bit in the terms and conditions of Qt (open source) license:

[...]

For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.

[...]

so the logical conclusion is that either BFC or someone else is distributing the binaries under Digia's commercial license, because certainly I haven't received any object files to relink at my leisure

I've already answered. We haven't moved to Qt, and we aren't in the process of it. Because Qt is licensed the way it is, you can draw your own conclusions, right or wrong, about why those files would be included. There's no need to remind me of Qt's license, because I've never looked at it, which should tell you something. I've been a professional software developer for a long time, open source licenses are something I pay close attention to when necessary.

I think I've answered this line of questioning to about the point where someone with an NDA that looks like mine can answer. So, to reiterate - no, we're not re-doing our UI with Qt, we have other far more pressing priorities.

[ForwardObserver]

Why?

Seemed to me a fairly good solution to the problem of reducing the complexity of cross-platform development and opening up a path to make an stand-alone application for map and scenario making.

Especially after Qt 4.5, where you can render all widgets with OpenGL and you have a clear way of extending the class hierarchy in the framework to override existing drawing routines by tapping into hardware accelerated routines. Here I'm assuming that BFC developed all the widgets (buttons, tabs, etc.) from scratch, using OpenGL primitives. They work fine, but they're a lot of work to get done from scratch, especially when it comes to writing event handling routines, and trying to avoid coupling between the model and the view.

It wouldn't be crazy of moving on top of a framework like Qt in an staged, incremental way. As I said, it's a HUGE work, but not a work that needs to get done in one single go.

For such a small outfit as BFC, avoiding duplication of effort in coding and maintenance is quite important, I reckon. One would like to be using as the foundation a well-established framework, whose interface remains stable yet the implementation keeps up with new developments at reasonable pace. Just think of the GDI, GDI+, Direct2D saga in Windows. Or how big was the leap from Quartz to Cocoa. Using flashy new stuff like XNA can end very badly: there was quite a disturbance when Microsoft decided to pull the plug out of that.

The question is: what is going to be the effect on your business of the decisions OS and Desktop make in the future? A likely answer is: something you won't necessarily like much.

What I find disappointing is that you don't plan ahead to make sure your games will have a decent chance of running well in ten years time (and I'm pretty sure you didn't like having to grok the legacy CMx1 code base to get CMBB and CMAK running on Windows Vista).

I think I've answered this line of questioning to about the point where someone with an NDA that looks like mine can answer. So, to reiterate - no, we're not re-doing our UI with Qt, we have other far more pressing priorities.

Fair enough, Phil. I just figured that out myself by elimination.

[Guest]

Seemed to me a fairly good solution to the problem of reducing the complexity of cross-platform development and opening up a path to make an stand-alone application for map and scenario making.

Especially after Qt 4.5, where you can render all widgets with OpenGL and you have a clear way of extending the class hierarchy in the framework to override existing drawing routines by tapping into hardware accelerated routines. Here I'm assuming that BFC developed all the widgets (buttons, tabs, etc.) from scratch, using OpenGL primitives. They work fine, but they're a lot of work to get done from scratch, especially when it comes to writing event handling routines, and trying to avoid coupling between the model and the view.

It wouldn't be crazy of moving on top of a framework like Qt in an staged, incremental way. As I said, it's a HUGE work, but not a work that needs to get done in one single go.

For such a small outfit as BFC, avoiding duplication of effort in coding and maintenance is quite important, I reckon. One would like to be using as the foundation a well-established framework, whose interface remains stable yet the implementation keeps up with new developments at reasonable pace. Just think of the GDI, GDI+, Direct2D saga in Windows. Or how big was the leap from Quartz to Cocoa. Using flashy new stuff like XNA can end very badly: there was quite a disturbance when Microsoft decided to pull the plug out of that.

Oh, agreed on all points.

The question is: what are going to do to your business OS and Desktop vendors to you in the future? A likely answer is: something you won't necessarily like much.

What I find disappointing is that you don't plan ahead to make sure your games will have a decent chance of running well in ten years time (and I'm pretty sure you didn't like having to grok the legacy CMx1 code base to get CMBB and CMAK running on Windows Vista).

Hmm. I'm kind of astounded that you would assume that we haven't planned ahead, based on basically zero information apart from the fact that we're not migrating our UI to Qt. Are you really drawing this conclusion from that? Isn't that just a *little* unduly negative?

I'll say this: if in ten years we're doing terribly about making sure our games are running well on the OSes of the time, I'll be disappointed too, for a number of reasons. Until then, a little faith in our abilities wouldn't be misplaced.

Fair enough, Phil. I just figured that out myself by elimination.

Despite your edit ( )I'm kind of confused by this figure of speech. By elimination of what?

[Pak40]

@Pak40

Concerning first contact notifications, I think I'd change my stance and agree with you based on your last argument. Notifications of even first enemy contact would largely NOT be considered "crucial" information. As you said, it would mostly trigger at the beginning of the game when first contact is being made, and first contact is quite often not meaningful contact.

But, perhaps this discussion is all for naught if it can't be programmed as was suggested.

Just a side note: audible contact alerts are already in the game. I haven't really investigated how often they occur but they do seem to generally occur when *some* units are newly discovered. The contacts are sometimes hard to hear and it seems you need to be closer to the ground and actual units that spot the new threat. I don't really regard it as useful because I usually see the enemy unit right before or at the time the audible alert is said, but still, there are cases where it has alerted me before I noticed the enemy. Since I pretty much play Wego, it doesn't do much good.

[ForwardObserver]

Hmm. I'm kind of astounded that you would assume that we haven't planned ahead, based on basically zero information apart from the fact that we're not migrating our UI to Qt. Are you really drawing this conclusion from that? Isn't that just a *little* unduly negative?

There aren't many well-maintained, cross-platform frameworks with Qt-like capabilities out there, Phil.

I'll say this: if in ten years we're doing terribly about making sure our games are running well on the OSes of the time, I'll be disappointed too, for a number of reasons. Until then, a little faith in our abilities wouldn't be misplaced.

I just took a screenshot of the post and uploaded it to Google Drive, Phil. Unless there's a global thermonuclear war or a massive earthquake sends Northern California to the bottom of the Pacific - if Google has its data servers there - in the next ten years, I should be able to wield it

Meanwhile, yes, I can keep faith.

Despite your edit ( )I'm kind of confused by this figure of speech. By elimination of what?

I edited the bit about OS and desktop vendors, not that line. I just eliminated hypothesis, that is, components bundled with CMBN. And the logical conclusion - assuming you're not trying to mislead me - doesn't make much sense - the presence of the phonon backend leaves me a bit flummoxed (http://userbase.kde.org/Phonon) - yet it's the last one standing.

[sfhand]

Icons flashing are easy to miss: the 'HIT: Penetration' messages aren't, or the columns of smoke that occasionally rise. Of course, you can replay at your leisure, but hey, I don't think it's a good design that to get an idea of what's going on during the last minute, one needs to replay the turn movie for a significant proportion of the units in the map (and I do that a lot). For a reinforced company, where you have split squads for maneuver (and work around TacAI limitations) you can have as much as 3 teams per squad, for a total of 27 units just for the line infantry. I've find myself adjusting my tactics, so I don't get as many units engaged as I can in order to be able to spend a reasonable amount of time figuring out what has been happening to my units.

That's micro-management of information gathering, and it gets tedious quickly.

Wow, we have really different experiences playing the game. I have no problem noticing when icons are flashing. Also, it seems pretty clear to me that the more units I have the more micromanagement will be involved. The thing is, the vast majority of turns (large battles) I'm not replaying more than twice and even then I don't watch the full minute the second time, just the parts I find interesting. And since I find it interesting it isn't tedious...

[ForwardObserver]

Wow, we have really different experiences playing the game. I have no problem noticing when icons are flashing. Also, it seems pretty clear to me that the more units I have the more micromanagement will be involved.

Good on you. My eyesight has degraded quite a bit over the years, unfortunately. Too much time spent looking into too bright screens I'm afraid.

The thing is, the vast majority of turns (large battles) I'm not replaying more than twice and even then I don't watch the full minute the second time, just the parts I find interesting. And since I find it interesting it isn't tedious...

Nice, I just wonder how much you miss from the action, your opponents will appreciate that.

[The Steppenwulf]

For a reinforced company, where you have split squads for maneuver (and work around TacAI limitations) you can have as much as 3 teams per squad, for a total of 27 units just for the line infantry. I've find myself adjusting my tactics, so I don't get as many units engaged as I can in order to be able to spend a reasonable amount of time figuring out what has been happening to my units.

That's micro-management of information gathering, and it gets tedious quickly.

This takes us to the kernel of this entire issue: Essentially task-overload for the CM player. This is a relative experience; overload affects individuals at different rates and RT play exacerbates the problem because the RT player cannot possibly perform more or monitor more events than the WeGo player can. This is not an experience that is limited to CM2; the scale of task management the brain can handle in any game is finite. However, it is something that is more apparent in CM2 because of the extension of the game to increasingly larger battlefields and ever larger formations. The splitting of squads only further increases the cognitive demands.

The answer however is not necessarily to provide additional information gathering or alerts. The answer is to accept that a company size force is about the maximium that the average player can cope with - certainly in an RT battle. Thus BF should ensure that CM supports multiplayer coop modes in V3.0. This long overdue feature would allow the high cognitive demands of commanding larger formations over larger areas to be naturally dampened by dividing those forces up amongst several players. Personally I don't play RT because this feature isn't currently accomodated, but nevertheless WeGo would benefit from the feature in equal measure for exactly the same reasons.

I don't even need to mention the whole new tactical dimension that such a feature would add to the game in any case. If one accepts this premise then my point earlier about the devs using their valuable dev time to enhance the game in other more interesting ways (than the OP suggestion) still stands. :cool:

[ForwardObserver]

This takes us to the kernel of this entire issue: Essentially task-overload for the CM player. This is a relative experience; overload affects individuals at different rates and RT play exacerbates the problem because the RT player cannot possibly perform more or monitor more events than the WeGo player can. This is not an experience that is limited to CM2; the scale of task management the brain can handle in any game is finite. However, it is something that is more apparent in CM2 because of the extension of the game to increasingly larger battlefields and ever larger formations. The splitting of squads only further increases the cognitive demands.

I agree with your assessment. I shouldn't have said 'tedious' but rather 'tiring'. I usually find the more a wargame appeals to 'thinking people' the better it is. But there's sort of a limit on the level of effort one can put on a hobby: for me, it's just about 2 simultaneous PBEM games.

The answer however is not necessarily to provide additional information gathering or alerts. The answer is to accept that a company size force is about the maximium that the average player can cope with - certainly in an RT battle. Thus BF should ensure that CM supports multiplayer coop modes in V3.0. This long overdue feature would allow the high cognitive demands of commanding larger formations over larger areas to be naturally dampened by dividing those forces up amongst several players. Personally I don't play RT because this feature isn't currently accomodated, but nevertheless WeGo would benefit from the feature in equal measure for exactly the same reasons.

I don't even need to mention the whole new tactical dimension that such a feature would add to the game in any case. If one accepts this premise then my point earlier about the devs using their valuable dev time to enhance the game in other more interesting ways (than the OP suggestion) still stands. :cool:

You made there a really good point, mate. Actually, going coop might be more cost-effective for BFC in the short and mid term, given what they've already accomplished, rather than enhancing the AI - say, by providing more complex commands like 'Quick' with a 'Bounded' modifier or sorts, that would break down a squad into teams, very much like the 'Assault' command allows - or the UI - to provide more tools to integrate battlefield information.

After all, well before Fritz or Deep Blue, we had the Mechanical Turk

[Vinnart]

Check out the "Roster" concept. It is like a visual radio for the player that links the player to the force giving the most important notifications in an easy to read way, and gives overall info one would only get if each unit was selected individually. It also allows the player to be zoomed in with the camera in one area while not missing what it is out of camera view. The final designs are toward the end of the thread. http://www.battlefront.com/community/showthread.php?t=104982

[pord]

I like the "Roster" idea as well. The visual aid for keeping track of units would indeed be a nice tool to have. Whether it be visual aids or text aids, anything to help information processing are must have's IMO. As others have said, nothing is being given to the player that isn't already available, but digging through the "menus" (i.e. clicking player units and tabs) is very time consuming and not my favorite part of the game.

[Ithikial_AU]

[*] A simplistic way of linking order waypoints, so one movement orders don't get triggered (i.e. a Pause command is inserted) until another unit has achieved a waypoint.

No idea about all the talk regarding programing changes, straight over my head. This feature would be worth an upgrade patch cost alone in my opinion. Only risk here is it may take away a bit of the 'skill' expected of CM players to micromanage units to get timed orders just right - like knowing to enter a building after the grenades go off.

[Vinnart]

[*] A simplistic way of linking order waypoints, so one movement orders don't get triggered (i.e. a Pause command is inserted) until another unit has achieved a waypoint.

This sounds how I imagine a "Follow" command working. Unit B is told to follow unit A, and is 10m away from unit A when the order is given. Unit A is then given a move order with several waypoints. Unit B will move to where A started, as it's first waypoint, and will follow the path plotted for unit A. When unit A stops unit B will stop 10m behind unit A maintaining the initial interval of 10m when the "follow" order was given. In this way a player could move the entire force in column along the path of the point unit while maintaining a desired interval between units. One would simply give the following units the “follow” order to the unit in front, and would only have to plot orders for the point unit instead of having to plot move orders for each individual unit as it is now.

[Vinnart]

Interesting also that many of the concerns described in this thread such as getting too many notifications I have troubleshot already with the “Roster” design. In the way I show it changing events with units are done in a subtle manner for events that change rapidly back and forth such as “contact”, or C2 status. Other events like “Casualties” that do not change rapidly back and forth are given more emphasis in the notification with the unit on the “Roster” temporarily highlighted. Even though one gets the flickering icon now in the game to show a casualty is taken, which is great, this can only be seen if that unit is in camera view. Also, remember that there is NO replay in RT play so events like this can be missed. The “Roster” addresses all these needs in an unobtrusive, easy to follow way.

[ForwardObserver]

This is an awesome concept, Vinnart

[Pak40]

Heck yea, I'd love that roster! BF, hire this guy!

[Battlefront.com]

Good ideas, but not new ones I actually remember the original Vinnart thread. One of the better proposals I've seen.

Fact is I've had an Order of Battle window and 2 other related features on the drawing board since 2005. Yet we haven't found time to put them in as they are quite time consuming to code. On a positive note, the Order of Battle was one of the last features cut from v2.0 Upgrade. So it was cloooooooose to getting in for that one.

Steve

[Battlefront.com]

BTW, I just looked back at my old design files. The first version of CMx2's UI that I can find is dated 12/02. Anybody that doesn't think we plan long term isn't paying attention. Anybody who thinks we can't come up with 10 years worth of ideas to implement and STILL have tons of stuff left over is just being stupid

Steve

[sburke]

So what are some of the ideas you thought of this week that you might get around to in 2028? Besides the beer next to your retirement rocker?

CM holographic brain implant?

[Vinnart]

Good ideas, but not new ones I actually remember the original Vinnart thread. One of the better proposals I've seen. Steve

Thanks Steve. As I told you once before great minds think a like. If only the imagination did not have to contend with the reality of a budget to add all the features everyone would like. If there is anything there in how I imagined such a tool as the “Roster” to work that you would want to incorporate in your design you have been working on please feel free to use any of my feedback if it helps.

[Vinnart]

So what are some of the ideas you thought of this week that you might get around to in 2028? Besides the beer next to your retirement rocker?

CM holographic brain implant?

Besides the M46 containment, beverage, Guinness concept my thoughts these days have been on two other concepts/ features for the game that are not new, but have feedback in how I could see them working.

1. “Follow” command. Surely I am not inventing the wheel with proposing such a command, but I do see it working a certain way for CM as opposed to how I seen in work in other games. I can think of no other command that would streamline logistics in moving columns, which I found I do much of especially in CMBN.

2. Multi-multiplayer for RT. I feel this is key for widely successful RTS games, and one of the reasons RT play is not as popular as WEGO is here. WEGO is a 1v1 sport, and RT is best played as a TEAM sport. My thoughts for such play are that each player controls either one of the platoons or companies in battalion size battles. Emphasis is on teamwork, and the units would act as they do for single player in that good C2 would be important. I would love to see this also contain some observer slots for each side so people could watch the game RT. Being that AAR’s are so popular here I think many would enjoy watching live battles. Lots of potential here in many ways.

[Endymion]

2. Multi-multiplayer for RT. I feel this is key for widely successful RTS games, and one of the reasons RT play is not as popular as WEGO is here. WEGO is a 1v1 sport, and RT is best played as a TEAM sport. My thoughts for such play are that each player controls either one of the platoons or companies in battalion size battles. Emphasis is on teamwork, and the units would act as they do for single player in that good C2 would be important. I would love to see this also contain some observer slots for each side so people could watch the game RT. Being that AAR’s are so popular here I think many would enjoy watching live battles. Lots of potential here in many ways.

Hmm, that would actually be nice. The reason I never play RT is because that would simply be a waste of time in battalion sized battles which I like playing with other people. Heck, you'll probably not be very effective controlling anything above a company and even then it'd be a struggle with lots of randomness and "forgotten" units left on their own for extended periods of time.

But if one player only controlled something platoon sized then it'd be manageable. And "Iron" difficulty mode would actually make sense if you could only see clearly the units you control and not be sure even of the rest of the company/battalion positions unless you got line of sight etc.

Also, not sure how difficult such mode would be to code though.

[A Canadian Cat]

But if one player only controlled something platoon sized then it'd be manageable. And "Iron" difficulty mode would actually make sense if you could only see clearly the units you control and not be sure even of the rest of the company/battalion positions unless you got line of sight etc.

Oh that would be absolutely amazing. I would love that.