Parameter Time History on Tool Tip

[Ron L Wilson]

It would be neat to be able to see a time history on the tool tip of certain parameters such as fatigue.

It might look something like this. (see link below)

https://padlet.com/rlwbeachbum/8qqbngozkkl0

Since this would require saving more data it might be an option that can be turned on or off asa game option for those that do not want to have bigger data files.

That said the values can be thinned so that the the largest values over say an hour are saved.

With this one can see both history trend data at a glance.

You could add others trend indicators as well such as a max value tic (or max value over last N hours) that would be viewable even without using the tool tip (see link above).

 

[Dave 'Arjuna' O'Connor]

Interesting idea. Yes more data would need to be saved. I understand the peak value but I'm confused at the history graph. Am I right in thinking that the graph starts at the top left and as time advances it draws down. I would have thought most people would view time as proceeding upwards, but maybe that's just me.

 

[Ron L Wilson]

I made it so that the current value on the graph would match the existing bar graph that shows the current value. Since the current bar graph run left to right I made the time based graphs runs left to right as well, so that the time axis runs top to bottom so that the Value axis runs left to right just as the existing bar graph. Yes, that is different form how most time based graphs are drwn but my thinking is that once one got used to it being drawn that way the fact that the current value bar and the time based graph match would compensate for that and make that adjustment worth the effort. seem my drawing below

current item bar graph
................c ( value for current value only)

Time based graph
,,,,,,,,,,,,,,,,,,c (value for current time, t)
,,,,,,,,,,,,,,,,,,,,,x (past value for t -1 )
,,,,,,,,,,,,,,,,,,,,,,,,,,,x (past value for t-2)
,,,,,,,,,,,,,,,,,,,,,,x (past value for t -3)
..............x (etc)

One reason for this is that I read it is not so much the losses but rather the rate which those losses occur that affects battlefield decisions. The the slope of the curve on the graph shows the rate of changes.

And of course one can always add both formats and let the user choose the one they like the best.

 

[Ron L Wilson]

One other idea that would be cool is to be able to show historical /planning routes on the map. These would not be orders per se but rather just graphis (that could be turned on and off) that shows routes (either historical or planned) and other military graphics such as assembly areas objectives and such or just make notes to oneself to remind oneself just what the over all game plan is and to see how that plan is playing out. As such the routes could have waypoints with times so that one can see how well ones is actually executing the original plan.

All this would be just graphics and how no affect on either game play or the AI... or at least initial so, for one could add that later.

Another handy feature would be a way to overlay hex grids. This would be a handy way to make conversions from hex based wargames and/or compare the results with CO with the results of hex based games on the same battle. Even cooler if there was a way to add a few reference lat and longs for a few hexes and have the game compute the lat and longs for all the hexes in a form that could be copied and pasted into Goggle maps so on could then easily see that terrain (and even better if that hex could be shown on the Goggle maps as a KML artifact.. .

Also it would be cool if one can add historical information (one a unit or commander) on the fly in the game and not through the scenario generation tool. That way as one plays a game one could update additional historical information as one Googles the units and such and add that inoo to the game using it as an in game repository for that new information. That info then could be saved for the play of that scenario only or permanently (or even better semi permanently so that it could later be identified and deleted as player added info) added to the scenario at the players command. This way the player could add alternate histories (as the game creates them as it plays out) and then delete them later or expand on the real histories and keep them for future plays of the same scenario.

And last (but not least) an easier way top play solitaire than the current method would be great.! That is one of my biggest gripes with the current game. Why it is excellent I tend to play solitaire and find it cumbersome to do that in the way you do this in the current version of the game.

One more thought. These would add to the ability of the game to present complex (and precise) information and maybe be things your military customers might want as well and be willing top pay and not just benefit the the gaming community but make you game all the more of a valuable tool to them as well.

 

[Ron L Wilson]

I might add another thing that would be cool (and that would be mostly just presenting information in a different from that the game already would be an integrated log. The current unit logs are cool but would be also cool would be a display that would show all the unit logs for a formation (be it a corp down to a battalion) where the times would be integrated along a common time line much like an activity chart in a UML diagram. Thus there is not that much new information in that this integrated view just shows those existing unit logs but does so on one timeline for each of the selected units.

A variant of the display could be a phone chat display that shows the communications between any two units (be it of the same formation or not or even the same side). The phone chat then could show orders being sent form higher HQs down to lower level units or action reports from lower units back up the chain of command. These could be displayed as little phone chat dialog bubbles just as one sees on texting. Thus the log dopes not just show the events for one unit or even several units but the interactions (i.e messages between) different units (i.e. the phone chat bubbles. The messages could be a command, a report (a enemy sighting or reported losses, etc), or an action (i.e. bang I am firing at you). In doing this one could create a causality maps where action A cause effect B which causes event C that are all linked so that the effects of an action can be tracked downstream, a useful feature for many reasons one being ato support an undo function (see post below on how for an application of an undo function),

The phone chat format is familiar to most everyone now a days and thus might be something non wargaiminers could relat and has such be an aid to get into the wargaming hobby. And for more serious users this could be a form of capturing embedded after action reviews. For example on could view the phone chat messages between a corps commander and one of his divisions commanders, or that division commanders chat with one of his regiment commanders. .The chat messages could be time stamped and could be linkable to the unit logs (individual or the group logs). And I might restate here that this would not require all that much information than the game already produces just a repacking of it into new display formats .

 

[Ron L Wilson]

And while I am posting my wish list ideas here let me add another one, embed scenario creation. Say one adds the hex overlay function that I discussed above. Now say one wants to export a CO scenario to some other game, say a VASSAL version of Lock and Load. What this function owuld do is allow the CO2 player to identify the area/units that they wish to export to the other game and then (forma list of supported games) choose the game and the this function would create a map and units and an initial deployment ibn that game as a scenario. Since CO maps are vector graphics the game map for the exported game could be a scale up value of the CO graphics (with added detail, be it manually or automatically added as an option). The game converter would also need a way top convert units strengths form one game format to another.

One could also add a way top reverse this and use a higher order game to create scenario in CO but that would be probably harder to do.

One of the advantages of this is that CO2 can be used to support other games and thus maybe win over followers of those supported games in the process. Thus say the fan base of a supported game (e.g. Lock and Load) ight be so induced to purchase CO2 in that it would support scenario creation for Lock and Load. Lock and Load might be a good one to start in that bought games at the present share the same publisher and have adjacent level scales (that is the hexes in Lock and Load would not be too small in CO2 to use that as a source to create a Lock and Load map (or at least the basics where more details could be added (be that manually with a tool or automatically with algorithms to do such or a combination of the two).

Additional supported games could be added over time as the idea catches on. Also a reverse function could be added at some time to import back into CO2 the results from playing the exported game so that one could hop back and forth between to the two games as desired.

And for any military customers this external game could be a real time simulator (say a flight simulator) where the results are continuously passed back and forth between CO2 and the real time sim. This would require a way to keep the games in synch but that might be doable by time tagging the information and it shows up whenever between the two (albeit perhaps somewhat delayed).

Thus say the flight simulator drops a bomb and kill a tank, the tank in CO2 may not die immediately but after some elapsed time but that can be back adjusted so that anything it did while being dead during that time could be undone. That would require some work to do that well, but even a crude version might suffice for a starter.

Also unit actions such as location, movement, firing could be time tagged and exported to the external simulation to be used as truth inputs to their sensor models. To keep the data rate down velocity data could be sent as well so that the target location that the could be extrapolated and thus sent at a lower rate but still be fairly accurate by extrapolating the location to the current time in the external sim.

Thus a tank moving down a road might not have to sent units position every second but only every ten seconds or so giving that its velocity does not change too much or new updates can be sent as needed if the velocity data (either in direction or speed) changes over some threshold value. If say ten tanks in a formation are moving down a rood the a group location could be sent plus the formation spacing and orientation and the spacing information could be less dynamic and not have to be sent as often as the group location. Thus 10 tanks moving in a kline or column with 10 meters spacing may change ity group location much more rapidly vs its 100 meter spacing which would not change as much and thus would not have to be sent as often. And the game keeps track of this in that the unit deployment regions are currently shown on the map as boxes and similar those boxes could be passed to any external simulation and threat simulation could then place each tank its its own data base such as along a road or what not..

Thus there are ways to reduce the required update rate and still maintain acceptable accuracy without too much processing or extra data to do so. Also, there are standard interfaces such as DIS and HLA that support this kind of integration between distributed real time simulations that might be pertinent to do things like this in CO2. BTW, if in ever implementing something like this it might be worth being able to dump these messages between simulations to an Excel file (i.e. CSV format) for debugging purposes and and general FYI for any users who want to know what fat was passed between the simulations.

And all the above work here in that integrated log discussed above perhaps could help support this undo function in that those interactions and any follow on actions) would have been captured in the phone chat messages. The idea here is to build building blocks that support future functionality and to get government funding so you can hire more software programmers so that the general gaming community can so benefit as well. For such an alliance could be a win.win for all the above if done properly.

 

[Ron L Wilson]

One more comment on the above post. Should CO2 ever be so interested with external games (be they real time or not) and the combat results are imported back into CO2 the CO2 could correlate these results with their own losses estimates. Thus say an aircraft sim reports that it killed two tanks CP2 could compare that to what it would have calculated the losses to be and save both. Also CO2 could look at what the average loses would have been (by its own reckoning) and so calibrate whether the external sim is typically creating higher or lower losses than what CO2 would have produced. That way CO2 could score external sims and say flight sim X produces on the average 30% higher losses that would CO2 on its own for tanks in such and such a case. That would be useful information ion general and also a way to help calibrate the sims so as to either define the models (on either the CO2 side or the external sim side) are blend the results. Thus CO2 could serve as the defacto arbitrator and referee between different games that are thus supported.