Road Tile Tweak Request

[Bullethead]

I would like to see the terrain sloping routines handle road tiles the way they handle building tiles. That is, when you place a building tile on a hillside, the hillside is flattened out around the building. Thus, you have steep slopes above and below the building with a flat spot where the building is. This, IMHO, is how roads on hillsides should also be.

As it stands now, the terrain sloping routines treat road tiles the same as non-building tiles, so the hill keeps its constant, smooth slope across the road. This means the road surface isn't level but follows the slope of the hillside. To make a level road, you have to add a row of tiles of the same height as the road on the downhill side of the road, which at 20m per tile makes a 40m flat surface. This, IMHO, is WAY too wide.

------------------

-Bullethead

In wine there is wisdom, in beer there is strength, in water there is bacteria.

[Tris]

Agreed, Jim. After some false starts I have managed to adjust to this idiosyncratic behavior of the scenario designer, but as you correctly point out that does nothing to invest the map with the kind of geographical variation the designer might otherwise have been tempted to put into his work. I can tell you that my maps, though the roads all work right visually, are much flatter than need be in places, flatter than I wish them to be.

A similar effect is seen when, say, you place a row of road tiles at level 5 running past terrain which is at level 0 somewhere near to the side. This situation can occur when you want to place a pond tile near the road--perhaps alongside a house. Same same if you wish to place walls or hedges along roads, or for that matter fields. Unless you keep the wall/hedge tiles all on the same terrain, and for an extra tile width out from the object in question (the hedge or wall) then the picture becomes crooked and weird looking. So the designer naturally enough goes back in and corrects this by flattening out the offending terrain, only with unfortunate effect. At the least the scenario is crippled to the extent that more variation in elevation is either limited, or the price to be paid is high in terms of aesthetics.

It would also be nice if a general "rounding off" might be achieved for all tiles in terms of elevation, so that when, for example, you want to establish a cliff, you need not look at the spikes we're left with at present--without resort, again, to the use of a lot of extra land around the cliff in order to more or gradually scale the desired cliff upward without the resluting "point" at its top. But then points are achieveable just by placing a 5m tile alongside 0m tiles.

Someone asked BTS a couple of days ago to consider hiring a person outside the present team to take over a redesign of the scenario editor. I can't recall if BTS replied or not to this request, as there was another request and thread of similar nature re the overall "hiring" picture for the company near term.

Anyway, this struck me with interest as I can easily see, due to time constraints in development, the scenario editor receiving relatively minimal attention in the days ahead, and this can only negatively impact the input of willing and able scenario designers, something which itself must affect (in the wrong direction) the overall quality of the game system and thus the gaming experience for everyone. Better scenarios benefit all who play, and a more sophisticated scenario design tool would only seem a fitting implement for the serious designer.

[BIG DD]

....give bts a break i think they have more important things to do right now... your objections are noted and filed,......guess ya cant please every one

------------------

MAKE IT SHORT AND SWEET THEN GET THE F#$K OUT

[This message has been edited by BIG DD (edited 11-26-2000).]

[coralsaw]

I don't see any problem with "the input of willing and able scenario designers" or "the overall quality of the game system".

------------------

My squads are regular, must be the fibre in the musli...

[Holien]

*****

BIG DD ....give bts a break i think they have more important things to do right now... your objections are noted and filed,......guess ya cant please every one

*****

While I have not designed any maps yet I think it is only fair that these chaps ask for changes.

IMO BTS is successful because they encourage debate and discussion of there game. By telling people to give them a break you might limit the discussion and any good ideas people have.

The success of this game will be enhanced by the designs of people out side the BTS fold who give up their time to come up with some stonking new scenarios and operations.

Well just my 2p worth as I like seeing what other people want to change.

Cheers

H

[Guest Germanboy]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Holien:

While I have not designed any maps yet I think it is only fair that these chaps ask for changes.<HR></BLOCKQUOTE>

Holien, while I fully agree with Bullethead's request for a change, and also think that the scenario editor (apart from city fighting) is the one area where major improvements for CM2 ought to be made, I also agree with Coralsaw that Tris' comments are going a bit too far.

We are currently seeing excellent scenarios produced despite these limitations, and I find it hard to credit that there should really the most wonderful scenario designers in the woodwork, tearing at the leash, just waiting for this change. Looking at the custom scenarios I have seen, I tend to totally disagree with that idea.

Having said that, I think it would be a good idea to move to smaller tiles, if that was possible. That would remove a lot of the problems in one stroke (but would also be a coding nightmare, I would assume).

------------------

Andreas

<a href="http://www.geocities.com/greg_mudry/sturm.html">Der Kessel</a >

Home of „Die Sturmgruppe“; Scenario Design Group for Combat Mission.

[This message has been edited by Germanboy (edited 11-27-2000).]

[Guest Big Time Software]

<BLOCKQUOTE>quote:</font><HR>Bullethead wrote:

To make a level road, you have to add a row of tiles of the same height as the road on the downhill side of the road, which at 20m per tile makes a 40m flat surface.<HR></BLOCKQUOTE>

I am not sure I understand you here. CM's engine DOES flatten out slopes for roads. So I am not sure what situation you have encountered that is causing you problems. Send me a save file if you like.

However, with 20x20 tiles (and 2x2 subtiles) there is only so much fidelity that can be achieved. Flattening out stuff is OK if you have a limited agenda for what gets to flatten what. But when this is opened up to many different possibilities, problems start to crop up very quickly. The real solution is smaller tile sizes, but right now that is not possible.

<BLOCKQUOTE>quote:</font><HR>Tris wrote:

Anyway, this struck me with interest as I can easily see, due to time constraints in development, the scenario editor receiving relatively minimal attention in the days ahead, and this can only negatively impact the input of willing and able scenario designers, something which itself must affect (in the wrong direction) the overall quality of the game system and thus the gaming experience for everyone. <HR></BLOCKQUOTE>

What leads you to believe that we are going to slack off on Editor improvements in the future? I mean, I didn't know you were privy to our secret plans to ruin the gaming experience ("wrong direction") over time. Damn, and we thought we were being so clever publically lying about planned future enhancements to scenario creation (i.e. the Editor). I suppose it will all come back to haunt us, since we obviously aren't really planning on doing any of them "due to time constraints in development".

Some advice for you Tris. You are not even remotely qualified to pontificate about how CM will be developed in the future. Not only do you lack the first hand experience necessary to do this in a general sense, but you haven't even bothered to look at what we have said about future development plans. In other words, you just make stuff up in your head, type it, and try to sound as if you know a thing or three when in fact you haven't a clue about what you are commenting on (at least as it pertains to us). Sheesh, you could at least make SOME attempt to show why it is you think that we are going to get lazy based on our past track record.

Oh, and if you had bothered to read the thread you cited, you would see that we did respond. In detail, on the same day it was started up IIRC.

<BLOCKQUOTE>quote:</font><HR>Andreas wrote:

Having said that, I think it would be a good idea to move to smaller tiles, if that was possible.<HR></BLOCKQUOTE>

This is something we will do in the future (contrary to Tris' statements to the contrary).

<BLOCKQUOTE>quote:</font><HR> That would remove a lot of the problems in one stroke (but would also be a coding nightmare, I would assume).<HR></BLOCKQUOTE>

Coding Nightmare™ is part of the problem, technology is another. At the moment it would be very difficult to implement smaller tile sizes for hardware reasons, not to mention coding ones.

However, when we go to rewrite the game engine (whenever that is) we do intend on making the terrain resolution much finer than the current 20x20 tile structure. Not sure how much we can improve it, but I would think that 10x10 is probably doable in a year or two's time. Hopefully 2x2! It all depends on what the hardware can handle at the time we go to rewrite the engine.

Steve

[This message has been edited by Big Time Software (edited 11-27-2000).]

[Chupacabra]

Steve - if I'm looking too far ahead, please feel free to smack me down, but:

Have you and Charles thought about how the current infantry abstractions will work if CM moves to 2x2 tiles?

The current method of having the squad marker abstract out so that, in effect, the entire squad is spread out over the entire tile works because of the size of the tile.

However, with a 2x2 tile, it seems to me that the squad would have to spread out over several tiles. I'd think that as the maps become more granular, the infantry representation would have to become less abstract as well. Have you given any thought as to how this is going to work? I realize this is jumping the gun a bit, but I'm curious

------------------

Grand Poobah of the fresh fire of Heh.

[coralsaw]

Steve,

Why do you still get annoyed at the chap? One needs only look at the last 10 days to form an opinion. Ban him if you think he has an agenda, or somefink.

------

Tris,

I'm just a CM fan, no ties with BTS. Can I suggest you try to be just constructive from now on, instead of filtering all your posts throught the "BTS sucks" sieve. They don't, at least for me, no matter whatever you or anyone else says, that is until I decide to drop CM from my hard disk.

If you think you are constructive and not biased, reality check: Do a mini poll on the forum.

Regards

[This message has been edited by coralsaw (edited 11-27-2000).]

[Guest Big Time Software]

The fanged little devil asked:

<BLOCKQUOTE>quote:</font><HR>The current method of having the squad marker abstract out so that, in effect, the entire squad is spread out over the entire tile works because of the size of the tile. <HR></BLOCKQUOTE>

Actually, CM already uses the 2x2 underlying grid to determine unit placement for squads to some degree. If a unit is mostly in a field, but partially in woods, this is taken into consideration when determining things like shrapnel hits. i.e. a unit in the middle of a Open Ground will be treated differently than one in Open Ground but with part of its footprint in Woods.

But the point is well taken. When the overall terrain model is made more refined, we will most likely have to come up with some different interface to show the player that a particular squad is in this and that terrain to this and that degree. At least I suspect we will be compelled to do this

Coralsaw, I still don't like to let groundless crap become part of the public record without a response from us, but point well taken. If Tris goes off the deepend again (not like this thread's minor irritation) I might just have to do somefink

Steve

[This message has been edited by Big Time Software (edited 11-27-2000).]

[David Aitken]

I must interject!

What I regard as one of the biggest barriers to creating realistic (particularly European) towns is the inability to place row houses on slopes. If you put two buildings next to each other on a hill, one disappears.

I know it would be a Coding Nightmare™ to model buildings where the ground floor is in line with the ground on one side, and ten feet underground on the other, but towns would be far more convincing given this feature. Oh, and while you're at it, can we have curving roads? And iron railings? And staircases? And archways?

I'll go into Edinburgh and take pictures of some historic European architecture that'll reduce you to tears, and you'll abandon the Combat Mission series in favour of Hypothetical Mission: New York Under Siege or SimDesert™.

David

New map!

[Tris]

Tris wrote:

Anyway, this struck me with interest as I can easily see, due to time constraints in development, the scenario editor receiving relatively minimal attention in the days ahead, and this can only negatively impact the input of willing and able scenario designers, something which itself must affect (in the wrong direction) the overall quality of the game system and thus the gaming experience for everyone.

Steve replied:

What leads you to believe that we are going to slack off on Editor improvements in the future?

I did not write that. Or anything close to it. What I wrote is printed above. The pertinent passage is this:

"...due to time constraints in development, the scenario editor receiving relatively minimal attention in the days ahead...."

I wrote "relatively minimal attention." that means relative to the development time to be pored into other aspects of the project.

Why would I write this, why would I have this opinion?

Well, it all started with this question:

Jeff Heidman wrote:

I was wondering if BTS has any intention of adding additional programmers to the CM project, or whether it will continue to be just Charles?

I was thinking about the Operations/Scenario creator, and how it could use a lot of work. Currently it has some issues, and could really use a rather major re-write to add a *lot* more ability for a scenario designer to customize various things. Wouldn't it be great if you could designate dynamic victory locations, victory conditions, force pools, entry zones, etc., etc.?

The thing is, there is very little chance that it would get done to its full potential with just one primary programmer trying to do the game itself and this as somewhat of an afterthought. I am sure you could have a full time person doing nothing but designing and implementing the scenario/operations tool.

I know BTS has added MaddMatt and KwazyDog, but IIRC they are not coders. Is there any thought in the future to expanding the actual software team?

To which you replied:

Our medium term plan is to expand our programming capabilities. This probably won't be for at least 2 years though. In order for this to work, from our perspective, the Combat Mission engine needs to be rewritten. The only person to do that is Charles. So first we finish CM2, then we start to think about what comes next

Your reply above read (and still reads) to me as if CM2 were the major priority for BTS, not the scenario editor. Hence my observation that the scenario editor would likely receive relatively small attention.

Why would you want to take exception to that?

I mean, I didn't know you were privy to our secret plans to ruin the gaming experience...

Where did I write that BTS intended to "ruin the gaming experience" for its users? Please point that passage out to me, Steve, because I don't see it up there.

...("wrong direction") over time.

If you think that's the "passage," you are mistaken. All you're doing is assuming the worst possible motive on my part for an innocent remark. I spoke to the greater project of writing future scenarios for the game and how this effort to improve the game system would be negatively impacted unless the scenario designer were beefed up. To me that is just something obvious, must also be obvious to Jeff as he raised the original question. This must be obvious to anyone who designs scenarios and has to work around the limitations of the editor we have.

Damn, and we thought we were being so clever publically lying about planned future enhancements to scenario creation (i.e. the Editor). I suppose it will all come back to haunt us, since we obviously aren't really planning on doing any of them "due to time constraints in development".

This must be a bad dream you were having. Are you trying to put thoughts in my head, words in mouth, or do you just like sarcasm?

Some advice for you Tris. You are not even remotely qualified to pontificate about how CM will be developed in the future.

I am as "remotely qualified" as your remarks upon this subject in this forum allow me to be. That's how qualified I am.

Not only do you lack the first hand experience necessary to do this in a general sense, but you haven't even bothered to look at what we have said about future development plans.

I read everything, Steve. I seem to read it more closely than you.

In other words, you just make stuff up in your head...

Sorry, but the stuff I just quoted is still up over on p. 4 or 5, whatever it is.

...type it, and try to sound as if you know a thing or three when in fact you haven't a clue about what you are commenting on (at least as it pertains to us).

I know exactly what I'm commenting on as far as anyone in my shoes could be. In this case, should it be that I'm mistaken and BTS will indeed commit much of it resources into improving the scenario editor at the expense of getting its next game out then all you would need to have said to Jeff is as much. Instead you wrote something else, which prompted my remarks.

Sheesh, you could at least make SOME attempt to show why it is you think that we are going to get lazy based on our past track record.

You ascribe words to me which I did not write, you ascribe feelings which I do not have.

Oh, and if you had bothered to read the thread you cited, you would see that we did respond. In detail, on the same day it was started up IIRC.

I have read that thread, and there is nothing in there that makes any of my comments off topic, erroneous or bizarre. Neither are they attacks on your person or the integrity of the company. Just simple observations on the status of the scenario editor as I believe that to be, this based on your feedback to Jeff. (Your subsequent remarks in that thread hold little bearing on this.)

[This message has been edited by Tris (edited 11-28-2000).]

[Guest Madmatt]

Tris, The mistake that you make is your (and possibly Jeff's as well) assumption that somehow CM2 and the editor are seperate programs. They are not. In fact, they are inherintly linked together and progress in one will never be possible without progress in the other.

So if we say that our focus is to be CM2 then that should also equate to mean focus on improvements to the editor. If that was not clear in the past let this message set the record straight for the future.

Thank you.

Madmatt

[This message has been edited by Madmatt (edited 11-28-2000).]

[Tris]

Thank you, Matt . . for the quiet reply.

Of course it's good information. I had no idea as I've yet to explore the CMBO folders. I had just assumed, as you rightly guessed, that the editor was a discrete program. Jeff must have as well, judging by the gist of his post, and since he apparently is versed in programming that might not say a whole lot for my chances with "poking around" in mind.

[Guest Big Time Software]

Well, I am glad that is cleared up for you. However, I don't think Jeff misunderstood anything. Two, three, or a dozen programmers can work on the same application at the same time, although it is not always desirable. More cooks in the kitchen creates additional (and increasingly large) problems to solve. Separate applications are even less desirable as a general rule. Different cooks in different kitchens, trying to make a well coordinated and presented meal from scratch at the same time, will most likely botch the execution at the very least.

So what Jeff was asking was "are you planning on having more than one programmer working at one time on one project (i.e. CM2, CM3, etc.)". CM being one, two, or 10 separate applications is irrelevant. Neither Jeff's question, nor my answer, implied separate programs with clearly delineated coding responsibilities. Unfortunately, you didn't understand this.

And that is why I object so strongly to the average customer propagating their own opinions ("minimal attention" and "wrong direction") lacking the knowledge and experience necessary to do so. This is something which you just proved. However, another person saying the same thing as you did, but without recent outbursts of contempt for BTS in general and myself specifically, would have been corrected in an entirely different way. This is why one should care about causing offense to others, intentional or otherwise, since it leaves a lasting impression that carries over into the future.

Steve

[Dschugaschwili]

Regarding the tile concept: what's the advantage of giving a terrain tile a height instead of giving the height data to the vertices of the tiles? With the second option it should be easy to make a single tile completely flat (perhaps to place a house or a road on it) without getting side effects on the adjactent tiles that you can't easily see in the editor. And you would need only one row and one column of additional height data for the entire map. Overall it seems to me that having the height data stored at the vertices is the superior method. Or am I missing something important here?

Dschugaschwili

[Bullethead]

Steve said:

<BLOCKQUOTE>quote:</font><HR>I am not sure I understand you here. CM's engine DOES flatten out slopes for roads.<HR></BLOCKQUOTE>

My experience is that it does not, at least not to the same degree as it does with building tiles. What I see, unless I add a row of same-height tiles downhill of the road, is that the road tiles often get folded diagonally from the center point. Thus, the uphill 1/2 of the road surface in the center of the tile is on a flat, but the downhill 1/2 is canted at an angle.

With a building, the tile is always flat in the middle where the building is--building tiles are never folded diagonally. So what you have with building tiles is a 20m flat spot on the hillside, with abrupt slopes uphill and downhill to the levels above and below on the slope of the hill. This form of terrain is pretty much identical to a road cut into the side of a hill. That's why I want to see road tiles treated similarly to building tiles in this regard.

<BLOCKQUOTE>quote:</font><HR>Send me a save file if you like.<HR></BLOCKQUOTE>

Done.

<BLOCKQUOTE>quote:</font><HR>However, with 20x20 tiles (and 2x2 subtiles) there is only so much fidelity that can be achieved. Flattening out stuff is OK if you have a limited agenda for what gets to flatten what. But when this is opened up to many different possibilities, problems start to crop up very quickly. The real solution is smaller tile sizes, but right now that is not possible.<HR></BLOCKQUOTE>

I appreciate this. But I believe road tiles need different treatment than they havey at present because right now they do not conform to standard engineering practice. They do not appear as cuts and fills, but as normally sloped hillsides.

------------------

-Bullethead

In wine there is wisdom, in beer there is strength, in water there is bacteria.

[Guest Big Time Software]

Got it and looked at it. Unfortunately, it isn't as simple as you think it is. There is nothing we can do about this until we move to a smaller graphics grid.

This is a shot from the file you sent me:

The solid lines represent the "seams" between tiles. Notice that they are can only go from tile intersection to tile intersection. The dashed lines represeant different angles within an individual tile.

The problem here is that a house "flattens' the trerrain under it. For this to happen, the terrain downslope has to be raised. The road is on that downslope tile, connected to the "Problem Point". So when the "Problem Point" is raised to make the flattened terrain for the house, it makes the road warped like you see in this picture.

To further illustrate I placed a house instead of the road:

Now, where did the original house go? If you looked in the Editor you would see that it is still technically there. But since it is impossible to allow BOTH houses to have flattened terrain when adjacent like that, one wins out and the other loses. As you can see, the one downslope is therefore put into the map info and the upslope one is not.

The placement of the second house simulates the behavior you are asking us to put in. And if we did, it would have the same results (i.e. only one of the two adjacent tiles can be flat).

So... if you remove the houses from this area, the road will be perfectly flattened out. Houses take priority over roads, roads over normal terrain. This is how it has to be, and it is why I said that when you start having things flatten stuff you quickly run into complications. There is no room for compromise as the two things being asked for can not both exist in this particular situation.

So until we move to a finer mesh system, you can not have a house and a road, diagonal from each other and one elevation or more apart, without affecting the road. There is no work around for this.

Thanks,

Steve

[This message has been edited by Big Time Software (edited 11-30-2000).]

[John Hough]

Steve, that example is understandable enough, but I've noticed a few places where the road-flattening thing doesn't work right, even with no lakes or buldings around to mess things up. I think it mainly happens when the slope is diagonal to the map grid, though it seems to also happen, to a lesser extent, to a diagonal road on a straight slope. I'll send you a scenario in which I've created a few examples.

I still don't know how much you can do without making things look funny, with tiles the size they are now. But it's probably at least worth taking a look at.

-John

(I'm in an experimenting mood lately, can't you tell?

[Tris]

As it turns out there are quirks to the editor which allow the scenario designer to "cheat" here and there (these I only discovered through the process of design oversight) with changes of elevations from tile to tile in mind, but it seems to be the case that the maximum deviation can only be two tile elevation values viewed diagonally, and if both elevation value changes lie within the same tile than only that one contiguous tile may contain the difference.

The optimal approach for a designer coming in, should he wish to avoid the unhappiest realization, is to resolve to plan ahead for such elevation discrepancies, think instead from the start in terms of broad, shallow slopes whenever roads, housing and water tiles are considered for placement. That is to say, the designer is well advised to visualize, as far as this might be possible, where he wishes to place his towns and roads systems and river gullies before he actually begins work on the map.

Now, as I assume 0 elevation for these latter tiles with regard to rivers, per se (it is allright to use higher elevations for water tiles to represent highland lakes and ponds), and given one of the two extremes this elevation value represents, I nominate river gullies as likely the most critical map terrain feature--afterall, around and above these tiles everything else will be asked to revolve.

If a designer were to conceptualize a map with no rivers to worry about then roads/housing might well assume the next order of importance with planning in mind, but in that case I would suggest to the designer that he step back first and get in his mind a broad overview of the map, satisfy himself that his higher elevations are where he generally wants these to be with relationship to one another, all of this considered in relation to the tactical demands of the scenario at hand. After the designer is satisfied with the implications of this overview he can proceed to approach the intertwined problem which rivers, roads/housing, tile/elevation realities tend to pose with larger confidence that his method will probably minimize false starts, save time and frustration making the inevitable corrections along the way.

The above note re "cheating" the tile elevation system only wanted to reference the appearance of related problems as these bear in relation to the use of clear terrain tiles in juxtaposition to a road system, where everything sticks out like a sore thumb. Sometimes these and similar design issues can be masked through the use of certain coverage tiles--brush is a logical candidate here. This effort to "window dress" will not get around flat versus jagged road beds, however; road tiles need to be laid with care; a firm resolve to get this aspect of the map mainly correct before proceeding to other projects will save much grief.

Which brings us approximately back to that overview process the designer (hopefully) went to the pains to make coming in: an ideal result of this effort would be to have afforded the map enough breathing room at each quarter to ensure the space necessary to allow incorporation of all desired map terrain without causing eventual displacement of our river/road/housing network.

Finally, while we speak to a problem extant of the editor in terms of its design limitations, these same shortcomings might be employed to achieve spectacular results if the changes in elevation are rendered severely enough. Where it might cast a wholly undesirable result to place a couple of 7 woods tiles next to a few 5 clear terrain tiles all sandwiched around a combination of 4/5/6 road-bed tiles, it is quite possible to run that same road bed (I would advise in this case to make the road bed one elevation or another) directly past a monstrous cliff where the elevation change runs from, say, six to 19 in the run of 20 lateral meters, and with breathtaking effect. Furthermore, it is then possible to dress that new cliff overhanging your road with rough terrain (be careful with the mods you employ in this area--some work entirely better visually than others) or brush as your tasste dictates, and soon enough your map, at least in that particular area, will assume dramatic change, possibly with compelling appeal. You can go nuts with this, too, but as a "touch" here and there this technique often pays handsome dividends.

Bottom line: planning is essential to harmonious design, and this will not change no matter how finely BTS decides to one day finely tune the granularity of its terrain tile building blocks--any change along that line will only afford relative design relief unless the change affected reaches an order of magnitude, with issues of terrain elevation discrepancy always in play, albeit to a smaller degree. Improvement is still longed for here, as it must offer welcome aid to our scenario designer with road bed placement and housing dispersals in mind, but the main benefit realized will most likely be expressed in a decrease of time required to slap together a reasonably eye-pleasing and utilitarian map. An end result having anything to do with "art" will require greater investment of time and of effort, always.

[This message has been edited by Tris (edited 11-30-2000).]

[Guest Big Time Software]

Tris,

Good suggestions. Map design IS an art. In some ways that is good, in other ways it is limiting. Unfortunately, the major limiting aspects in CM are the result of CPU shortcomings (graphic chips come in second).

<BLOCKQUOTE>quote:</font><HR>Bottom line: planning is essential to harmonious design, and this will not change no matter how finely BTS decides to one day finely tune the granularity of its terrain tile building blocks--any change along that line will only afford relative design relief unless the change affected reaches an order of magnitude, with issues of terrain elevation discrepancy always in play, albeit to a smaller degree<HR></BLOCKQUOTE>

While I agree with this in general, I don't think we have to improve the resolution THAT much in order to solve most of the problems. If we used a 10x10 grid it would be possible to have fixed Bullethead's problems completely. That is only a 2 fold increase in terrain resolution, which is the minimal improvement allowable (well, from a sensible approach anyhoo). I personally would like to see a 5x5 or even a 2x2 system, but even 10x10 would be a HUGE improvement for map design.

Steve

[Tris]

While I agree with this in general, I don't think we have to improve the resolution THAT much in order to solve most of the problems. If we used a 10x10 grid it would be possible to have fixed Bullethead's problems completely. That is only a 2 fold increase in terrain resolution, which is the minimal improvement allowable (well, from a sensible approach anyhoo). I personally would like to see a 5x5 or even a 2x2 system, but even 10x10 would be a HUGE improvement for map design.

I haven't the necessary background to come up with the terminology (jargon) of computer graphical design, Steve. I meant to refer to greater resolution as it appears to the user on screen, not to the way the mathematical model works internally. I understand your example (I think--you've given it a couple of other places), but unless I'm mistaken the same humps and points would dot the map landscape once you examined it closely, though to a (much) lesser degree (assuming a 10x10 display). If there's a CAD program around that can accurately depict ground contours down to the smallest detail I haven't seen it at work (I've seen some CAD's which do depict ground contours, certainly, but not to depict each ebb and eddy of the landscape down to small stones and folds in the grass at one-foot intervals); even if such a program exists it's doubtless a standalone job, not something used to get a scenario editor for some piece of recreational software along its way.

Regardless of that, I wanted to mainly address the CMBO scenario editor as it actually exists, possibly to offer practical (and theoretical) considerations as to how users might improve scenarios through the creation of better (more aesthetically pleasing and functional) maps.

By the way, wouldn't a 10x10 approach represent precisely one order of magnitude improvement over what we have now? If not, where am I wrong? Keep in mind you speak to an old sportswriter with z-e-r-o experience in your field . . . but a still healthy curiosity . . . and ego

[Bullethead]

Steve said:

<BLOCKQUOTE>quote:</font><HR>The problem here is that a house "flattens' the trerrain under it. For this to happen, the terrain downslope has to be raised. The road is on that downslope tile, connected to the "Problem Point". So when the "Problem Point" is raised to make the flattened terrain for the house, it makes the road warped like you see in this picture.<HR></BLOCKQUOTE>

After considering your explanation and trying to come up with alternative methods of resolving this type of situation, it is apparent to me that no such alternatives will work without allowing tile sides to fold at their midpoints, which effectively divides the 20m tile into 10m tiles. Thus, different methods of folding and flattening tiles are out of the question at present.

However, this still leaves other possibilities. For example, why does a building tile have to be flat? It seems to me much more common engineering practice to only level the ground directly under a building's floor. Thus, many buildings are dug partially into hillsides, so that from the downhill side they appear as 2 stories but as only 1 story from the uphill side. OTOH, roadbeds have to be essentially flat throughout.

Therefore, it seems to me more in keeping with reality to give flattening priority to roads rather than buildings. If there is a building diagonally adjacent to such a road, let its tile slope normally, coming partway up the walls of the building graphic on all but the downhill side. Of course, this raises movement and LOS issues across the building walls partially overlapped by hillside, but there might be some way to deal with these satisfactorily.

<BLOCKQUOTE>quote:</font><HR>Now, where did the original house go?<HR></BLOCKQUOTE>

Yeah, I had a Hell of a time with this. The original building is only technically there during that one editing session. If you save, exit, and come back later, it's gone from the map and replaced by open terrain. So when making that map I sent you, I kept noticing buildings disappearing when I re-opened the file. I thought the file was corrupted until I noticed these disappearing buildings weren't there in the preview even when I'd added them back in the tile editor view. So I had to adjust elevations until they all remained, making these hillside hamlets much flatter than they are in real life.

<BLOCKQUOTE>quote:</font><HR>If we used a 10x10 grid it would be possible to have fixed Bullethead's problems completely. That is only a 2 fold increase in terrain resolution...<HR></BLOCKQUOTE>

Wouldn't switching from 20m to 10m tiles result in 4 times as many tiles as there are now, instead of 2 times as many?

------------------

-Bullethead

In wine there is wisdom, in beer there is strength, in water there is bacteria.

[Tris]

I was way off. I thought Steve meant to say that instead of one unit per tile side with a 10x10 scheme it would then amount to ten units per tile side--in other words, instead of one tile there would now be 100 within that same space! If he referred to meters as the game measures them per tile side, if he is only talking about a decrease (increase in granularity) by a factor of 50%, then while this would amount to an improvement it would in no way approach the sort of improvement I envisaged and had hoped for, as this must then still leave all sorts of problems for the scenario designer.

Oh well, back to bug eyes and lots of overview.

P.S. Yes, if he meant that 10m per tile side would be the new tile dimension then that would represent a four-fold increase in tiles to work with for the same area over what we have now.

[This message has been edited by Tris (edited 11-30-2000).]

[Guest Big Time Software]

Bullethead wrote:

<BLOCKQUOTE>quote:</font><HR>Therefore, it seems to me more in keeping with reality to give flattening priority to roads rather than buildings. If there is a building diagonally adjacent to such a road, let its tile slope normally, coming partway up the walls of the building graphic on all but the downhill side.<HR></BLOCKQUOTE>

In theory, this works for examples where the road is ABOVE the house. But in the example pictured above, it does not work because the house would be 1/2 floating on air

<BLOCKQUOTE>quote:</font><HR>Of course, this raises movement and LOS issues across the building walls partially overlapped by hillside, but there might be some way to deal with these satisfactorily.<HR></BLOCKQUOTE>

"Satisfactorily" meaning a Hell of a lot of programming, sure. But practically speaking... no. That is why it was not allowed to happen, and won't be. Better to spend the time on recoding the underlying terrain mechanism than to make just this one improvement (which only works when downslope) work.

<BLOCKQUOTE>quote:</font><HR>Wouldn't switching from 20m to 10m tiles result in 4 times as many tiles as there are now, instead of 2 times as many?<HR></BLOCKQUOTE>

My bad Yes it would, but it wouldn't necessarily increase the number of polygons by 4. I would guess that instead of a 4x increase in polygon counts, most maps might only increase by 2x since a lot of terrain is flat.

Tris, the level of terrain resolution you are thinking about is probably 10 years off. But it isn't really necessary for CM. Abstractions can take care of the subtle stuff and in game terms there would be hardly any difference. One of those things where the 90% mark is all you need, and the rest is a case of serious diminishing returns.

If we got the tile size down to 10x10 I think you would be astonished what a difference it would make. 5x5 would, of course, be even better. 2x2 would be mouth watering

Steve