Compound Terrain Effects

Compound Terrain Effects

[Eric McDonald]

Hello,

  Currently, unit visibility is determined by several factors in 
Xconq. One of these factors is the terrain of the cell upon which 
the unit is positioned. However, this factor is limited only to 
the primary terrain of the cell, and does not take into account 
connectors (such as roads) or coatings (such as snow). The same 
limitation is also true regarding a unit's attack and defense 
advantages. After reviewing the code, I think it would be fairly 
simple to also factor in the effects that connectors, coatings, 
etc... could have on visibility and ability to attack/defend.
  As an example, suppose that a unit is sitting on a forest cell 
that has a road running through it. Now, if the unit is on the 
road, it should be more vulnerable than if it is just in forest. 
Under my proposal, a game designer could say that the unit has a 
25% chance of being seen in forest, but a 200% chance of being 
seen on road, and the aggregate effect would be 25% * 200% = 50% 
chance of being seen on a forest road.
  Another example would be a unit affected by a sandstorm 
coating in a desert environment.

  As I previously stated, I think the proposed changes would be 
simple and straightforward. They primarily involve iterating 
through subterrains associated with cells, and making sure that 
tables such as visibility can have values greater than 100%. (Of 
course, if the final calculated chance is >100%, then it just 
means that being seen is guaranteed.)

  So, my questions are:
  (1) Are any gamers interested in playing game modules with  
these compound effects?
  (2) Are any game designers interested in using them?
  (3) Is it too late to add a "semi-feature" to Xconq as the 
release is coming up?

  Comments welcome.

  Thanks,
   Eric

Re: Compound Terrain Effects

[Hans Ronne]

>  So, my questions are:
>  (1) Are any gamers interested in playing game modules with
>these compound effects?
>  (2) Are any game designers interested in using them?
>  (3) Is it too late to add a "semi-feature" to Xconq as the
>release is coming up?

It's never to late to add a feature, provided that it works, of course. And
what you propose sounds pretty straightforward. I would say that it is more
urgent to fix the tank-on-road-in-forest ZOC bug that you reported earlier,
however, which also involves the connection code. I haven't had time to
look into that bug myself, since I have been busy with other things.

Hans

Re: Compound Terrain Effects

[Jim Kingdon]

> (1) Are any gamers interested in playing game modules with  
> these compound effects?

It might be kind of confusing (why am I seeing this unit and not
that?), but the way to find out would be to implement it and start
play-testing.

Probably it would be OK, once the player got used to it.

Re: Compound Terrain Effects

[Bruno Boettcher]

On Wed, Oct 15, 2003 at 06:02:15AM -0400, Jim Kingdon wrote:
> > (1) Are any gamers interested in playing game modules with  
> > these compound effects?
yep, me :D

> It might be kind of confusing (why am I seeing this unit and not
> that?), but the way to find out would be to implement it and start
> play-testing.
> 
> Probably it would be OK, once the player got used to it.
exactly, and its only a variation of allready present mechanisms, i
wouldn't be too confused by that....

but as said earlier, the plotting mechanisms problem to use roads is
more important to fix :D

and since i am at it, are rivers only there to look nice? shouldn't
there be a possiblity for (certain?) water units to take them?

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

Re: Compound Terrain Effects

[Jim Kingdon]

> and since i am at it, are rivers only there to look nice? shouldn't
> there be a possiblity for (certain?) water units to take them?

In the standard game, armor has to spend an extra movement point to
cross a river [1].  I was working on one game (maybe log.g?) in which
it was even harder for armor to cross rivers.

Having units located in a border rather than in a cell is going to be
a big hassle (in terms of how movement, combat, and everything else
works), so I'd be reluctant to go down that road.

[1] This is achieved by:

(table mp-to-enter-terrain
  . . .
  (a river 1)

Re: Compound Terrain Effects

[Bruno Boettcher]

On Wed, Oct 15, 2003 at 07:46:44AM -0400, Jim Kingdon wrote:
> In the standard game, armor has to spend an extra movement point to
> cross a river [1].  I was working on one game (maybe log.g?) in which
> it was even harder for armor to cross rivers.
yep was aware of that, still the impact of rivers is quite low, and only
as impedement... (nothing that couldn't be solved by building 'bridges',
    or for forrests 'roads' = lines of bases that only are there to
    simulate a road or bridge...)


> Having units located in a border rather than in a cell is going to be
> a big hassle (in terms of how movement, combat, and everything else
> works), so I'd be reluctant to go down that road.
yep forgot that they are allways located at a border... would have been
easier indeed if the rivers were inside the cells....


oh BTW would be nice to make the reply either to the list or to me
privately ;) i don't have a filter that takes out doubles....

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

Border Terrain (was Re: Compound Terrain Effects)

[Eric McDonald]

Hello Jim and Bruno,

On Wed, 15 Oct 2003, Jim Kingdon wrote:

> > and since i am at it, are rivers only there to look nice? shouldn't
> > there be a possiblity for (certain?) water units to take them?
> 
> In the standard game, armor has to spend an extra movement point to
> cross a river [1].  I was working on one game (maybe log.g?) in which
> it was even harder for armor to cross rivers.

There is also the possibility of doing a border slide.

> Having units located in a border rather than in a cell is going to be
> a big hassle (in terms of how movement, combat, and everything else
> works), so I'd be reluctant to go down that road.

I simply would not go down that road (or is it river? :) at this 
stage.

  Regards,
    Eric

Re: Border Terrain (was Re: Compound Terrain Effects)

[Hans Ronne]

>Hello Jim and Bruno,
>
>On Wed, 15 Oct 2003, Jim Kingdon wrote:
>
>> > and since i am at it, are rivers only there to look nice? shouldn't
>> > there be a possiblity for (certain?) water units to take them?

>There is also the possibility of doing a border slide.

Precisely. Though it didn't work last time I tested it (WWII-Europe, Black
Sea fleet trying to get out through the Bosporus).

>> Having units located in a border rather than in a cell is going to be
>> a big hassle (in terms of how movement, combat, and everything else
>> works), so I'd be reluctant to go down that road.
>
>I simply would not go down that road (or is it river? :) at this
>stage.

Actually, we've already been there. This is how the connection code worked,
before I rewrote it this summer (extra space for units inside connections).
There were some good reasons why we removed this possibility, but it has
already been discussed on the list, so I am not going to repeat myself.
It's all in the list archive for those who are interested.

Hans

Re: Border Terrain (was Re: Compound Terrain Effects)

[Eric McDonald]

Hi Hans,

On Wed, 15 Oct 2003, Hans Ronne wrote:

> >There is also the possibility of doing a border slide.
> 
> Precisely. Though it didn't work last time I tested it (WWII-Europe, Black
> Sea fleet trying to get out through the Bosporus).

Ironically, I think I saw an instance of it working (when it 
shouldn't have) last weekend when I was play-testing Bellum. 
Specifically, I accidentally clicked on a cell that the current 
unit (a land unit) could not reach because of intervening illegal 
terrain. The path-finding algorithm told it to go toward a river 
(which was 1 cell away) and then suddenly the unit was sitting on 
the cell it wasn't supposed to be able to go to (which was 1 or 2 
cells up the river). Strange....

> >I simply would not go down that road (or is it river? :) at this
> >stage.
> 
> Actually, we've already been there. 

Right, I remember. After the 7.5 release, I think we need to have 
a good discussion about the merits and the problems with possibly 
reimplementing this, perhaps in conjunction with a 
subterrain-size-in-terrain table. But, I'm not prepared to argue 
the case until after I get some more exposure to the connector and 
movement code (which may happen if I manage to fix the previously 
mentioned ZOC bug).

  Regards,
   Eric

Re: Compound Terrain Effects

[Eric McDonald]

Hello,

On Wed, 15 Oct 2003, Jim Kingdon wrote:

> > (1) Are any gamers interested in playing game modules with  
> > these compound effects?
> 
> It might be kind of confusing (why am I seeing this unit and not
> that?), but the way to find out would be to implement it and start
> play-testing.

OK, time to start play-testing.

There is currently only one game that takes advantage of compound 
terrain effects, and that is Bellum Aeternum. But the 
functionality is now there for any game designer who wishes to use 
them.

Specifically, the compound effects are active for the following 
tables: visibility, attack-terrain-effect, 
fire-attack-terrain-effect, defend-terrain-effect, and 
fire-defend-terrain-effect.

They are used in Bellum to help expose land units on roads. I have 
not tried them with coatings or borders, but they should work the 
same in those cases.

The implementation is still somewhat primitive in the regard that 
it does not consider the direction of the attack and whether the 
border is actually present in that direction. I will hopefully get 
around to addressing that at some point. Another detail is whether 
a unit is actually using a connector or not; I need to research 
the proper way to test for that.

  Regards,
   Eric

RE: Compound Terrain Effects

[Erik Jessen]

I created a whole set of test-cases, to illustrate things like
- how road/rail reduces MP cost in woods, but not in clear
- how to do slides
- how to vary cost of entering a hex v. leaving

This was mainly for my own education; they're certainly not games per
se,
But are only 10-20 hexes, 1-2 units.  I would think others would find
them useful, but how should they be added to Xconq?

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Eric McDonald
Sent: Saturday, October 25, 2003 9:32 PM
To: xconq7@sources.redhat.com
Subject: Re: Compound Terrain Effects

Hello,

On Wed, 15 Oct 2003, Jim Kingdon wrote:

> > (1) Are any gamers interested in playing game modules with  
> > these compound effects?
> 
> It might be kind of confusing (why am I seeing this unit and not
> that?), but the way to find out would be to implement it and start
> play-testing.

OK, time to start play-testing.

There is currently only one game that takes advantage of compound 
terrain effects, and that is Bellum Aeternum. But the 
functionality is now there for any game designer who wishes to use 
them.

Specifically, the compound effects are active for the following 
tables: visibility, attack-terrain-effect, 
fire-attack-terrain-effect, defend-terrain-effect, and 
fire-defend-terrain-effect.

They are used in Bellum to help expose land units on roads. I have 
not tried them with coatings or borders, but they should work the 
same in those cases.

The implementation is still somewhat primitive in the regard that 
it does not consider the direction of the attack and whether the 
border is actually present in that direction. I will hopefully get 
around to addressing that at some point. Another detail is whether 
a unit is actually using a connector or not; I need to research 
the proper way to test for that.

  Regards,
   Eric

Test Cases (was RE: Compound Terrain Effects)

[Eric McDonald]

Greetings Erik,

On Sun, 26 Oct 2003, Erik Jessen wrote:

> I created a whole set of test-cases, to illustrate things like
> - how road/rail reduces MP cost in woods, but not in clear
> - how to do slides
> - how to vary cost of entering a hex v. leaving
> 
> This was mainly for my own education; they're certainly not games per
> se,
> But are only 10-20 hexes, 1-2 units.  I would think others would find
> them useful, but how should they be added to Xconq?

Thanks for taking the time to do this. Not only can they be 
instructional to others, but can serve as test cases to make sure 
features still work after changes to the Xconq kernel. I also 
think that you have demonstrated that there are plenty of ways to 
contribute to the Xconq project without actually writing C code.

I am not quite sure where to put them. I am tempted to suggest the 
creation of another directory in the Xconq source tree, but I 
already added 3 new dirs last weekend, so I am not going to say 
anything....

If you want to send them as attachments to me by private email, I 
will take a look at them.

  Thanks again,
    Eric

Re: Test Cases (was RE: Compound Terrain Effects)

[Jim Kingdon]

> Thanks for taking the time to do this. Not only can they be 
> instructional to others . . .

Yeah.  Demonstrating each feature with a 10-20 hex, 1-2 unit example
is really good in a lot of ways.

> but can serve as test cases to make sure features still work after
> changes to the Xconq kernel.

This would be maximally useful if you can run "make check" and get a
pass/fail type result.  Right now there are only one or two tests that
work like that (see check-auto in test/Makefile.in and autotest in
kernel/skelconq.c and autotest.c).

But if that is too hard (as in, "the perfect is the enemy of the good"
or "let's check it in while we work on it" or whatever), then an
explanation of how to manually see whether the examples are working
right would be helpful.

> I am not quite sure where to put them. 

There are a number of such things in the test directory.  Although
those go with the current tests (which are mostly semi-automated)
rather than primarily being aimed at human consumption.

So I'd probably say put them in test, although I could also see a new
directory examples or test/examples if there is no intention of
writing test code to use them.

Re: Test Cases (was RE: Compound Terrain Effects)

[Hans Ronne]

>There are a number of such things in the test directory.  Although
>those go with the current tests (which are mostly semi-automated)
>rather than primarily being aimed at human consumption.
>
>So I'd probably say put them in test, although I could also see a new
>directory examples or test/examples if there is no intention of
>writing test code to use them.

Putting this stuff in the test directory makes sense.

Hans

RE: Test Cases (was RE: Compound Terrain Effects)

[Erik Jessen]

Could you tell me how to check that something happened in the Make file?
I don't know how to run a game for a couple of turns, save it, then
check for things inside the saved game.

Erik 

-----Original Message-----
From: Jim Kingdon [mailto:kingdon@panix.com] 
Sent: Sunday, October 26, 2003 8:57 PM
To: mcdonald@phy.cmich.edu
Cc: ejessen@adelphia.net; xconq7@sources.redhat.com
Subject: Re: Test Cases (was RE: Compound Terrain Effects)

> Thanks for taking the time to do this. Not only can they be 
> instructional to others . . .

Yeah.  Demonstrating each feature with a 10-20 hex, 1-2 unit example
is really good in a lot of ways.

> but can serve as test cases to make sure features still work after
> changes to the Xconq kernel.

This would be maximally useful if you can run "make check" and get a
pass/fail type result.  Right now there are only one or two tests that
work like that (see check-auto in test/Makefile.in and autotest in
kernel/skelconq.c and autotest.c).

But if that is too hard (as in, "the perfect is the enemy of the good"
or "let's check it in while we work on it" or whatever), then an
explanation of how to manually see whether the examples are working
right would be helpful.

> I am not quite sure where to put them. 

There are a number of such things in the test directory.  Although
those go with the current tests (which are mostly semi-automated)
rather than primarily being aimed at human consumption.

So I'd probably say put them in test, although I could also see a new
directory examples or test/examples if there is no intention of
writing test code to use them.

RE: Test Cases (was RE: Compound Terrain Effects)

[Eric McDonald]

Hi Erik, Jim,

On Mon, 27 Oct 2003, Erik Jessen wrote:

> Could you tell me how to check that something happened in the Make file?
> I don't know how to run a game for a couple of turns, save it, then
> check for things inside the saved game.

Based on what I understand your test cases to be, I would just 
write up a description about how to use them for now, and we can 
worry about automation later, if that is something we think we 
should worry about.

> From: Jim Kingdon [mailto:kingdon@panix.com] 
> Sent: Sunday, October 26, 2003 8:57 PM
> 
> > I am not quite sure where to put them. 
> 
> There are a number of such things in the test directory.  Although
> those go with the current tests (which are mostly semi-automated)
> rather than primarily being aimed at human consumption.

Yes, I had this concern, which is why I refrained from suggesting 
the test directory proper.

> So I'd probably say put them in test, although I could also see a new
> directory examples or test/examples if there is no intention of
> writing test code to use them.

I vote for test/examples.

  Regards,
    Eric

RE: Test Cases (was RE: Compound Terrain Effects)

[Hans Ronne]

>> So I'd probably say put them in test, although I could also see a new
>> directory examples or test/examples if there is no intention of
>> writing test code to use them.
>
>I vote for test/examples.

One could also make an argument for putting them in the lib directory. This
is where tank.g lives, which is precisly this kind of minimalistic game
module for testing/education.

It really depends on whether we want these files to be available to
everybody or just to developers. The stuff in the test directory is used to
check for bugs in the kernel code, so it clearly falls into the latter
category. But something that is useful to players and/or game module
writers should probably be included in the installed version. Which means
lib (or possibly a new subdirectory of lib).

Hans