The new mystery box

[Michael Emrys]

Your example sounds to me like one of the reasons I always split my squads into teams.

Yep. Splitting squads is pretty much de rigueur in this game. I can understand your not being terribly happy over the extra micromanagement that this results in, but it's how to get the most out of the game at its present stage of development.

Michael

[womble]

Yep. Splitting squads is pretty much de rigueur in this game. I can understand your not being terribly happy over the extra micromanagement that this results in, but it's how to get the most out of the game at its present stage of development.

If that's addressed at me, you mistake my reactions. I'm neither happy nor unhappy about any "extra" micromanagement, since "extra" implies some comparison, and I'm clear that this game isn't CMx1, so no comparison needs to be drawn. I actively like the options that splitting squads gives me in tailoring my force to the way I'm going to use it (Assault/Fire support split or more even teams for versatility, and always with AT assets separated out). I consider the game to be a team-based game, rather than squad based, and that is different to CMx1, and appeals to ultra-micromanagey me more.

If more people realised that it's not the same game as x1, there'd be more complaining over the fact that it's "more difficult" (really only more time consuming per minute of gametime, in WeGo) to play large-scale (Reinforced Bttn-plus) games, and less over some numinous "extra" micro.

[Childress]

Yep. Splitting squads is pretty much de rigueur in this game. I can understand your not being terribly happy over the extra micromanagement that this results in, but it's how to get the most out of the game at its present stage of development.

We players need to get the concept of smaller battles into our heads. Some of the monster scenarios that shipped with the CW module stagger the mind. They play fluidly with the ram upgrade but I look on players who split every squad with, well, wild surmise.

I'm one who tends to approach splitting with a lazy eye with the result that I was a much stronger CMx1 player (most recently in 2005, I believe) and why I haven't ventured into PBEM with CM2. Not that all the team options aren't useful- they are. Though I find the ability of low experience squads to split without penalty (I think) to be questionable. Or they should generate team leaders with lower command ratings on a more consistent basis than they do currently.

[Steiner14]

Though I find the ability of low experience squads to split without penalty (I think) to be questionable. Or they should generate team leaders with lower command ratings on a more consistent basis than they do currently.

For me it doesn't feel right, that splitting squads results in positive effects only without any cons, too.

[Childress]

For me it doesn't feel right, that splitting squads results in positive effects only without any cons, too.

Agreed. But penalizing teams, to play the devil's advocate, one would create problems in setting up an extended defense. As I posted elsewhere, splitting squads when defending is practically mandatory. You end up with lots of isolated, out of C2 teams. And these require some resilience in resisting pressure from the attacker.

There may be no solution other than retaining the current dynamic. Ideally, you'd inflict penalties on teams in an attacking mode. But implementing such limitations no doubt imposes coding challenges. Alternatively, just play smaller scenarios and split to you heart's content.

[Battlefront.com]

I admit it would be nice sometimes, perhaps even with lines changing colour eg. voice to eye to distant.

It would also be real handy when setting up.

But it's probably a lot of work for minimal gain.

More direct C2 information in the 3D area is a long standing request. Command Lines, as they were in CMx1, are not our first choice for showing this information. But it does have some advantages and as an option we may yet allow this to happen.

Putting more functionality into the Floating Icons is a possibility as well. However, we have to be careful to not pack too much functionality into those little buggers. As stated earlier, color alone isn't viable. We'd have to change the physical look of the icons themselves. Which gets back to a design that's been sitting around since about 2007, maybe 2008, for a multifunctional icon system. I had hoped to get it into Version 2.0, but we cut it early on as it is quite involved and there were other things we wanted to focus our attention on first.

The sad thing about game design is that for every 100 good ideas that come up, it's only practical to implement a few of them. Sometimes because of internal conflicts, sometimes because the effort is simply not worth it. But usually, in our case, it's simply because there is only so much time and far too many things to do. Hiring more help only works if those features will increase sales to pay for the extra labor. The downside of being in a niche market is extra sales are unlikely.

Steve

[Michael Emrys]

If that's addressed at me, you mistake my reactions.

Nope. Actually it was addressed to John. Based on your posts, you seem to be pretty happy with the game and the way it plays.

Michael

[Rocky Balboa]

I know its probably already been mentioned in this thread but for me I would desperately like some way to better determine terrain relief / elevation. Currently its very time consuming for me using the LOS tool to get a feel for the relief in the game map. Grids help some but I would like to see a better solution.

Perhaps a single function that shows all the squares a certain unit has LOS to and shades out or greys out all the squares it doesnt have LOS to.

[Barleyman]

More direct C2 information in the 3D area is a long standing request. Command Lines, as they were in CMx1, are not our first choice for showing this information. But it does have some advantages and as an option we may yet allow this to happen.

Putting more functionality into the Floating Icons is a possibility as well. However, we have to be careful to not pack too much functionality into those little buggers. As stated earlier, color alone isn't viable. We'd have to change the physical look of the icons themselves. Which gets back to a design that's been sitting around since about 2007, maybe 2008, for a multifunctional icon system. I had hoped to get it into Version 2.0, but we cut it early on as it is quite involved and there were other things we wanted to focus our attention on first.

I have another idea that comes to mind in-between screen-cluttering lines and icon shapes. You could have an arrow/caret/line pointing towards the command unit. Going in that direction you could easily change the arrow shape to indicate level of contact if any.

As an anecdote, long time ago in eurofighter 2000 simulation the tactical display was uninformative for much the same reason as here. Someone suggested making the sperm (plane location + direction vector) colored according to the mission group. Devs loved the idea and fast-tracked it into the game. Small change technically but improved the situational awareness tremendously.

WRT ui improvements generating extra revenues, a case can definitely be made. You could make an another for getting the CM-franchise into steam.

Matrix games is a good bad example of limiting their userbase with stiffneckedness. They want to have 100% of revenues going through their website and they almost never have any kind of sale to raise interest. Some of their titles are actually pretty easily approachable like panzer command. You really have to go out of your way to hear of it or buy it, though.

[Steiner14]

I know its probably already been mentioned in this thread but for me I would desperately like some way to better determine terrain relief / elevation. Currently its very time consuming for me using the LOS tool to get a feel for the relief in the game map. Grids help some but I would like to see a better solution.

A classic for all tank-battle-fans.

But a long time ago sadly Steve mentioned a grid-overlay was a quite difficult task.

Idea for a solution:

Hotkey that switches off the sun and creates an artificial, but almost invisible low standing "sun", that can be moved by the player (it's last position is remembered).

Maybe two or three hotkeys, that can store an individual position, because if one part of the map is on a forward slope, while the other part is on reverse-slope, they would need different lighting conditions.

[Battlefront.com]

I can tell you guys that "gridlines" were explored in painful detail for Version 2.0. We gave up. You guys should know by know that we are pretty clever and that we don't give up easily. We wasted a couple of days on just trying to figure out a clever way to make it work and saw no hope. Investing more time would mean less features we knew could be done, which is why we threw in the towel on it.

The problem is there's only two basic methods for putting contour/grid lines on the map:

1. Pre-rendering them in with the map itself. In other words, make them part of the terrain graphics. A small hit up front when the map is loading, but after there is no speed hit or resource hit. The con is it can never be turned off during the game because the map is already rendered with it and there's no way even good computers can handle having two sets of terrain (one with line and one without) stored in VRAM. It's just too big for that and too time consuming to swap out from normal RAM or disk.

2. Have lines drawn on the fly. It can be toggled on and off at will because it's an overlay (of sorts). Since it's not baked into the map graphics then we neatly avoid the problems noted above. Unfortunately it KILLS framerate. Even on a really good system it's likely to have a very noticeable drag on framerate. Heck, we're not even sure if it would work even on a higher end computer.

Either method requires too much up-front work to even attempt to see what negatives come about after. Which is why you won't see me promising this feature for Version 3.0 or even later.

The only option available to people, right now, is to use terrain mods with the lines already baked in. Has all the pros and cons of #1 above, but requires no sacrifice of new game features because we didn't have to write code to do it dynamically.

Playing with lighting conditions is the only possible solution I can see, but it will likely be very ugly looking and might not be a good enough solution. Which is why we've not explored it yet.

Steve

[Steiner14]

Playing with lighting conditions is the only possible solution I can see, but it will likely be very ugly looking and might not be a good enough solution. Which is why we've not explored it yet.

I was more worried, that a lower "sun" might be looking better, then the "real" sun. So when switching back the player would notice somehow a degradation, because of the more flat looking terrain.

I think it would not be good psychologically, if the normal presentation of the game would be felt as less impressive or less informative, than the look with the tool.

Therefore if you think it would look ugly, i think it's positive: the player will be happy to return to the standard view (similar to gridded terrain - it looks less good, but offers great help).

And if something looks really ugly, then there is the trick to make it look like art. Maybe a certain color of the lighting would help doing so. Maybe a certain color will also bring out the undulations' contrast even more?

So the player would be glad to have this tool, but also be glad to go back to the beautiful normal view.

[Rocky Balboa]

I can tell you guys that "gridlines" were explored in painful detail for Version 2.0. We gave up. You guys should know by know that we are pretty clever and that we don't give up easily. We wasted a couple of days on just trying to figure out a clever way to make it work and saw no hope. Investing more time would mean less features we knew could be done, which is why we threw in the towel on it.

The problem is there's only two basic methods for putting contour/grid lines on the map:

..........

The only option available to people, right now, is to use terrain mods with the lines already baked in. Has all the pros and cons of #1 above, but requires no sacrifice of new game features because we didn't have to write code to do it dynamically.

Playing with lighting conditions is the only possible solution I can see, but it will likely be very ugly looking and might not be a good enough solution. Which is why we've not explored it yet.

Steve

Contour lines would be ideal but only if they could be toggled otherwise I think they would make the map too cluttered not to mention the performance hit the system would take.

This is why I mentioned an enhanced LOS tool that would essentially work like the current LOS tool but show me at a glance all the squares on the map that a unit can see from a certain location. This way I get the benefit of the LOS tool without having to manually check LOS in every direction just to get a feel for what the terrain is doing.

The benefits of enhancing the current LOS tool is that the base code for the tool is already in place. In addition to showing the relief and contour of the map or a portion of the map at a glance, I believe it could also speed up game play.

The downside of going this route of course would be the possible performance hit you would take to gather this much information all at once.

2. Have lines drawn on the fly. It can be toggled on and off at will because it's an overlay (of sorts). Since it's not baked into the map graphics then we neatly avoid the problems noted above. Unfortunately it KILLS framerate. Even on a really good system it's likely to have a very noticeable drag on framerate. Heck, we're not even sure if it would work even on a higher end computer.

If you guys feel that drawing contour lines on the fly is a possible solution but causes too big of a performance hit, have you considered only drawing the lines in a certain arc or distance from the currently selected unit? This might make it doable and cut down on the frame rate hit.

[Michael Emrys]

This is why I mentioned an enhanced LOS tool that would essentially work like the current LOS tool but show me at a glance all the squares on the map that a unit can see from a certain location.

As always though the problem with this is at what height is the assumed observer? A man lying on the ground? A man kneeling? A man standing? A man sitting in a vehicle? A man standing on the turret of a tank? Each of these will have potentially a very different view of the terrain and anything on it.

Michael

[Rocky Balboa]

As always though the problem with this is at what height is the assumed observer? A man lying on the ground? A man kneeling? A man standing? A man sitting in a vehicle? A man standing on the turret of a tank? Each of these will have potentially a very different view of the terrain and anything on it.

Michael

Yes, I would agree for targeting purposes this is the issue, sometimes you might be able to see the ground but not the target or you might be able to see the target but not the ground. However for the purpose of giving the player a better idea of how the terrain is rising or falling, where the possible depressions in the terrain might be. Wouldn't some variation of the current LOS/targeting tool work for this?

(Example ... One click or key-press shows all the squares that the selected unit can see... all the other squares are greyed out or subdued in some way.)

Something like this would allow me to see at a glance where those depressions are. I would also be able to tell if the ground was rising or falling in front of me because at some point I wouldn't be able to see past the crest of a hill.

Maybe I'm playing the game wrong but I use the current targeting/LOS tool a lot not just for targeting but also to see where those dead areas are. Of course this also becomes a problem in that I spend a lot of time with the current tool just trying to figure out the terrain.

I know it's perhaps not the optimal solution but based on Steve's post from above it sounds like even a suboptimal solution might be better than none at all or what we have.

[Battlefront.com]

The old Grigsby method of "show me the squares!!" system isn't viable for us. I don't know how bad of a performance hit the game would suffer for doing this, but it would be significant for sure. Then there is the whole "from what height do we measure from?" problem. The more dynamic we make the feedback, the more speed hit there is.

The problem for us is we have have to guess about speed hits. Spending days or week coding something only to find out it isn't viable is just not something we can afford to do.

Steve

[womble]

The old Grigsby method of "show me the squares!!" system isn't viable for us. I don't know how bad of a performance hit the game would suffer for doing this, but it would be significant for sure. Then there is the whole "from what height do we measure from?" problem. The more dynamic we make the feedback, the more speed hit there is.

The problem for us is we have have to guess about speed hits. Spending days or week coding something only to find out it isn't viable is just not something we can afford to do.

Steve

Something that you could tinker with, for my money, which might free up some cycles is the "polling rate" for icons. Sure it's nice that they move seamlessly across the screen, but for my money, if they got calculated less often, I wouldn't mind, especially if it meant they could convey more information. It looks from a semiconscious point of view, like they're sampled very often indeed, judging from the judder rate when something (not sure what - lighting flicker effects, maybe?) makes two icons swap places when the camera is still and the game paused. If the engine wasn't having to calculate "Icon here. No, here. No here!" as often, I don't think that'd be a bad thing.

[poesel]

Can someone name an other game where this works? Maybe theres a good idea to copy?

Btw another suboptimal solution would be to just show the height values from the map editor. Not very nice and probably unreadable when zoomed out very far but, as Rocky said, better than none.

[michael Dwyer]

Can someone name an other game where this works? Maybe theres a good idea to copy?

Btw another suboptimal solution would be to just show the height values from the map editor. Not very nice and probably unreadable when zoomed out very far but, as Rocky said, better than none.

What about doing a color contour map based on the height form the editor. http://en.wikipedia.org/wiki/File:Contour3D.jpg it would be ugly as home made sin and not a "period" looking solution but if you want to convey data about height nothing is better than color.

[JonS]

I kind of imagined it as a grid overlay automatically generated during the scenario editting process (perhaps whenever the scen is saved), which then becomes in integral - and permanent - part of the scenario that the player can turn on and off as desired. Sort of like landmarks, or terrain objectives ("like" in this sense referring to their permanence and player ability to turn on and off. Not the creation activity, which for landmarks and terrain objectives is fully manual).

This would work for QB maps too, since they are initially created and ultimately saved, in the scen editor.

It would mean that each save in the editor would take longer (*pfft*, big deal) and also that the grid wouldn't be able to cope with dynamic changes during play (like ... um craters and ... is there anything else?) but I think that any drift between the pre-configured grid and the actual map would be quite slight.

I suppose scen loading times would be larger (the overlay would be another thing to load), scen and PBEM file sizes would be larger (the grid would be another thing to store), and there'd still be a hit on RAM (I think?) because that grid would need to be stored, and some hit on performance because the grid perspective would have to be dynamically adjusted as the camera zooms about the place.

But at least the task of creating the grid in all it's 3D glory would be removed from runtime.

[Michael Emrys]

...dynamic changes during play (like ... um craters and ... is there anything else?)...

I think that now that we are in a land of tectonic activity, there should be the possibility of in-game changes to terrain, such as landslides due to earthquakes, lava flows and ash deposition that causes engines and other mechanical devices to fail as well as limiting visibility.

Michael

[womble]

I kind of imagined it as a grid overlay automatically generated during the scenario editting process (perhaps whenever the scen is saved), which then becomes in integral - and permanent - part of the scenario that the player can turn on and off as desired. Sort of like landmarks, or terrain objectives ("like" in this sense referring to their permanence and player ability to turn on and off. Not the creation activity, which for landmarks and terrain objectives is fully manual).

[lightbulb=over head] Or like trees! They require 3D rendering as you move across the battlefield and can be turned on and off at need.

I guess that does illustrate the problem though, since sometimes on large tree-heavy maps, with the trees visible, it can get a bit juddery moving the camera around.

[JonS]

I originally had trees in my "sort of like" list, for that reason, but I decided to delete them out. I don't recall why now ... probably because trees are terrain, whereas objectives and landmarks aren't. I also imagine the grid to be fully rigid, once created, whereas trees can be destroyed during a battle.

[womble]

I originally had trees in my "sort of like" list, for that reason, but I decided to delete them out. I don't recall why now ... probably because trees are terrain, whereas objectives and landmarks aren't. I also imagine the grid to be fully rigid, once created, whereas trees can be destroyed during a battle.

I see that; tree trunks aren't frangible though, are they? Just the foliage?