civil-devel Mailing List for Civil

Hi all,

I promised Gareth to post some screenshots of other wargames that we're
"competing" with. Well, there aren't that many, but here are a few. Mainly
the panel/info parts of the shots are interesting at this point. The links
are directly to some screenshots of the games, not the "main" pages.

Sid Meier's Antietam:
	http://www.wargamer.com/antietam/sma_ss.asp
http://www.firaxis.com/antietam/index.cfm?openalmanac=y&page=units/units_p06.cfm

Sid Meier's Gettysburg:
	http://www.firaxis.com/getty/
	
Horse & Musket:
	http://www.wargamer.com/horsenmusket/hnm_game.asp

Age of Empires II:
	http://www.wargamer.com/reviews/ageofkings_main.asp

Battleground 9: Chickamauga
	http://www.wargamer.com/reviews/chickamauga_main.asp

Campaign 1776:
	http://www.wargamer.com/reviews/campaign_1776_main.asp

Combat Mission:
	http://www.wargamer.com/reviews/combat_mission_main.asp
	
	The age is dead wrong here, but this is the most acclaimed game
        for the last few years, and it has the most detail I've seen in a
 	wargame, forget the clumsy-looking 3D.

North vs. South:
	http://www.wargamer.com/reviews/north_south_main.asp
	http://www.wargamer.com/reviews/north_south_main2.asp

Shogun:
	http://www.wargamer.com/reviews/shogun_main.asp

Sid Meier's Alien Crossfire:
	http://www.wargamer.com/reviews/alien_crossfire_main.asp

	Never underestimate Sid Meier, he know what he's doing...

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On Fri, 30 Mar 2001, Gareth Noyce wrote:

>On first reading I have no serious comment. Its 
>seems like the min requirements... I'm more 
>worried about how to represent these modes to the 
>player...

Hmm, yeah, it could be *quite* hard to do for all modes. So I suggest we
try to maybe represent a small subset of them, such as "column" and
"formation", and leave the rest out. The player will see the mode when
he/she activates a unit.

>One thing: does a unit need an 'engaged' mode -- 
>for situations when thay are in the middle of a 
>fight? I would have thought that a unit in the 
>middle of a scrap is going to react slower to 
>commands, and movement will be impaired by the 
>fight...

Thinking a little more about the thing there is really two separate
questions I've tried to represent:

1. how are the troops physically organized on the ground? Column,
formation, dug in, disorganized?

2. what are they doing? Moving, charging, engaging an enemy unit,
retreating?

So we can have a unit in column mode that is moving, a unit in formation
that is charging or a disorganized unit that it retreating etc. This
becomes quite tricky when you look at it that way. We could of course have
a lot of modes that represent all valid combinations (not too many, i.e.
not n*m [n=question1, m=question2]), as some things they do imply some
physical organization. For instance retreating or routing units are always
more or less disorganized.

So, have two different "mode" flags, or have only one with many possible
values. I could try to list them later today and send them here. 

Or am I going in the wrong direction?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Quoting Jan Ekholm <ch...@in...>:

> >Jan, can you clarify the exact areas need in 
> >the 
> >status bar? 
> 
> :-) Certainly!

Thank you. That was pretty much what I thought...

G




-------------------------------------------------
This mail sent through UK Online webmail

On Fri, 30 Mar 2001, Gareth Noyce wrote:

>Hi,
>
>Jan, can you clarify the exact areas need in the 
>status bar? 

:-) Certainly!

>So far we have the map area, and two text areas. 
>If the size of the text areas is increased (as 
>you pointed out) -- does that cover all that is 
>needed for the status bar?

I think we need the map where it is, and a fairly large area for all info
about units, state, weapon, leader etc. It will be slimmed down if needed.
To the far right the buttons away, and instead a scrolling text area for
the messages.

>A little rough diagram of what you need will suffice...

+------------------------------------------------------------------------+
|+---------+ +-----------------------------+ +--------------------------+|
||         | |                             | |                          ||
||         | |                             | |                          ||
||  map    | |    stats, unit etc          | | messages to the player   ||
||         | |                             | |                          ||
|+---------+ +-----------------------------+ +--------------------------+|
+------------------------------------------------------------------------+

Something like that? The 'stats' and 'messages' may look different, i.e.
have different background or something like that. But not too colorful, so
that colors for the texts would not be visible. 

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hi,

Jan, can you clarify the exact areas need in the 
status bar? 

So far we have the map area, and two text areas. 
If the size of the text areas is increased (as 
you pointed out) -- does that cover all that is 
needed for the status bar?

A little rough diagram of what you need will 
suffice...

Cheers

G

-------------------------------------------------
This mail sent through UK Online webmail

Quoting Jan Ekholm <ch...@in...>:

[SCHNIP]

> When we agree on this (or is this an entirely 
> fubar approach?) I'll add
> it
> to the docs, and create a src/mode/ 
> subdirectory.
> 
> So, comments, feedback?

On first reading I have no serious comment. Its 
seems like the min requirements... I'm more 
worried about how to represent these modes to the 
player...

One thing: does a unit need an 'engaged' mode -- 
for situations when thay are in the middle of a 
fight? I would have thought that a unit in the 
middle of a scrap is going to react slower to 
commands, and movement will be impaired by the 
fight...

Other than that I can't think of much.

G

-------------------------------------------------
This mail sent through UK Online webmail

Hi all,

This is just some brainstorming and a RFC, so I'd appreciate all input and
feedback, both negative (especially negative), so that we don't end up
coding in something that does now work properly.

All units in the game will at all time be in some "mode". A mode indicates
the physical layout of the troops as well as their readiness for combat
and movement of various kind. A mode affects most things the units do.
This is quite hard to get right, so input is needed. The modes I've come
up with so far are below. Note that several of these are overlapping and
mean almost the same. We need to figure out which we remove (or add), and
wether there really are *two* separate forms of modes.


Formation:
----------

Normal formation mode. The troops stand organized in proper fighting mode,
ready to do combat. Artillery pieces are lined up and prepared for firing.
The unit moves slower in formation mode, so it is bets used when an enemy
is nearby.


Column:
-------

Mode used for moving the troops around. The troops line up "in depth"
rather than "in width", suitable for road and track movement. Moves
faster, but has reduced offensive and defensive stats. Use for moving
units long distances.


Dug in:
-------

The unit is dug into the terrain and has prepared the best available
defense. Fences are used, logs, even trenches are dug. It is much harder
to cause casualtities to a dug in unit, and the unit will not as easily
break up and retreat. Added defensive bonus.

Digging in:
-----------

The unit is in process of getting "dug in". As this operation will take
some time there could be a separate mode for it. Other modes can be
entered quite fast.


Charging:
---------

Well, the unit is advancing against an enemy unit. Slow advance at first,
the charging the last distance. Firing a volley here and there. May cause
the enemy to break up and retreat, or cause the charging unit to do the
same. 


Disorganised:
-------------

A disorganised unit has its units disorganised. The unit is still in good
spirit, and may have driven some enemy away through a "charge" order. it
takes some time for a disorganized unit to organize itself again. Will be
done automatically after some time.


Retreating:
-----------

The unit is retreating away from the enemy after taking losses, or after
being ordered to retreat through the order "retreat". Retreating units
will not attack and defend at reduced strength. Through a "rally" order
the unit will organize itself again.


Routing:
--------

This is the ultimate form of disrupted units. The unit has probably taked
massive losses, for instanc through a attack or a failed assault. A
routing unit will retreat and will not obey any orders, apart from
"rally". A routed unit will defend itself with greatly reduced strength,
and performs no attacks. Really routed units who've taken heavy losses may
surrender.



When we agree on this (or is this an entirely fubar approach?) I'll add it
to the docs, and create a src/mode/ subdirectory.

So, comments, feedback?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hi all,

I put up a new screenshot on the homepage showing off the new
visualization of plans/orders for units. Seems to work quite ok. Please
have a look!

To make screenshots press F10 while no unit is selected. Arrange whatever
you want, click on some empty terrain to make sure no unit is active and
the press F10. The file is called 'snapshot.bmp' and saved in the current
working directory. New snapshots overwrite old, so copy away old ones
before taking new ones.

Also update your local CVS repository and add yourselves to the AUTHORS
file with the info you want to have.

Now I'm tired...

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hi all,

The recent ChangeLog says:

* movement orders are now properly visualized by UnitOrdersLayer.
* units now know the plans they have been given.
* DoneCmd are sent out when a plan is completed.
* MoveFast works ok, moves faster then a Move.
* a lot of other small tweaks to command- and plan-handling.

Which means that the command/pland modifications are soon all done. When
you issue a move or movefast plan to a unit the plans are properly
visualized in the playfield using colored lines. Similar for rotations to
be added soon (quite simple, just draw a line...).

Only cancelling plans does not yet work (at least I don't think so).

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 28 Mar 2001 19:19:22 +0200, Kalle Svensson wrote:

> Yeah, but watch out:
> >>> l = [[None] * 320] * 200
> >>> l[0][0] = 1
> >>> l[0][0]
> 1
> >>> l[1][0]
> 1


Doh!  Of course, the reason it's fast is that it's just copying
pointers, not in-depth copies.  Well, that's not so useful.

Hi all,

Current ChangeLog:

* panel now handles mouse presses internally, states don't do it anymore
  for it. Less code in each State subclass.
* rotation works ok now. Will always face to rotate the clicked position
  on the map => no more weird facings due to using old position for angle
  claculations.
* movements work again. Rotates properly before moving.
* plans for a unit get queued as they should => two moves don't get
  executed in parallell. Rotates beofre/after movements are also properly
  executed. Proper delays are used (baseDelay()).
* much other tweaking. 


This all means that we've reached and passed the point we were at before I
started reorganizing the command handling. Everything seems to work ok
now, and some things now work much better, such as several plans for a
unit at the same time. I also cleaned up a lot of code from the State
subclasses and put it all in Panel. 

Now we can go on with other tasks again. I'll do the 'MoveFast' plan as
next, as well as start thinking about the messages to the player. These
messages are somthing the game tells the player, and they should be in the
panel. Something like:

10.58: Company Foo attacks Bar, routing it.
11.01: Union says: got me there, bastard!
11.02: Reinforcements arrive on Buzzword Road:
       4 companies and 1 artillery

This should be properly handled and visualized. Should be quite simple,
but needs to be done. It is something that can be done quite separately.
A class such as Messages could be ok. The Panel needs to manage the sole
instance of that class, i.e. let it paint itself. The class should have
some simple facility for accepting various messages (player tells, attack
results etc) and store them internally. On demand it should repaint itself
and generate PyGame labels from the messages it has. It should also work
as a kind of "listbox" so that the player can scroll back to earlier
messages.

Any takers?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Sez I:
> Check it out:
> >>> l = map(list, list(((None,)*320,)*200))

Just noticed that one of the list calls is unnecessary:
>>> l = map(list, ((None,)*320,)*200)
works just fine.

The importance?  Ummm...

Peace,
  Kalle
-- 
Email: ka...@gn...     | You can tune a filesystem, but you
Web: http://www.gnupung.net/ | can't tune a fish. -- man tunefs(8)
PGP fingerprint: 0C56 B171 8159 327F 1824 F5DE 74D7 80D7 BF3B B1DD
 [ Not signed due to lossage.  Blame Microsoft Outlook Express. ]

Just jumping in here.  I've got a lot to do, but I'm alive.

Sez Mike Earl:
> 2) Another possibility; objects are large, but *pointers* are quite
> small.  If there are a small number of hex types, keep a dictionary of
> the ones being used, and put them in the map instead of creating new
> ones.  We'd only have 1 copy of any duplicated hexes, which would reduce
> the memory required dramatically.   Haven't really thought this all the
> way through, but it might be useful...

Sounds like a Flyweight.

> btw: in testing some of this, I found a nice python tidbit.  To
> initalize a 320x200 array of blank objects, you can just take
> 
> [[None] * 320] * 200
> 
> This operation is also very, very fast, for some reason.

Yeah, but watch out:
>>> l = [[None] * 320] * 200
>>> l[0][0] = 1
>>> l[0][0]
1
>>> l[1][0]
1
>>>

Check it out:
>>> l = map(list, list(((None,)*320,)*200))
>>> l[0][0] = 1
>>> l[0][0]
1
>>> l[1][0]
>>> 

It's almost lisp!

Peace,
  Kalle
-- 
Email: ka...@gn...     | You can tune a filesystem, but you
Web: http://www.gnupung.net/ | can't tune a fish. -- man tunefs(8)
PGP fingerprint: 0C56 B171 8159 327F 1824 F5DE 74D7 80D7 BF3B B1DD
 [ Not signed due to lossage.  Blame Microsoft Outlook Express. ]

Hi all,

The recent ChangeLog comes here:

* removed obsolete plan Done.
* src/civil-server.py now catches all thrown exceptions in the main
  function.
* all commands updated to use applyServer() and applyClient(), all plans
  use the new names too.
* major updates to the engine's handling of plans. Incoming plans from
  clients now get "attached" to the proper unit when received.
* plans are queued properly for the units.
* rotating units work again, as does quitting.
* clients do not yet receive (and thus visualize) plans fromt he server,
  only commands for the updates.
* several new methods the class Plan for better management of the
  plans on the server side. Documentation still sucks.
* server now runs a few turns (server.properties.engine_keepahead_time)
  ahead of the clients. 


What this means is that I'm finally getting it all back together. I must
say I'm quite happy with what it looks like, but there still is some work
to do to get back to the same level as before the changes started...
Please have patience. It is playable now, and should not crash, unless you
do something with the units other than rotate them. It's currently just a
big ballet. Tomorrow I'll hack movements to work too.

I think the split into Command and Plan was good, thanks to MikeE for the
design of that part. It makes Command subclasses really simple, and keeps
the complexity in the Plan subclasses, which still are simpler than they
were before. I've added quite a few methods to Plan, but it should all be
quite straightforward, and I'll do a proper document about it all once it
stabilizes.

One drawback is that there is a lot of code in the Plan classes that the
clients never use, but I don't want to split that Plan:s into server and
client versions. The clients only use the Plan:s for sending to the server
and storage in the units for visualization purposes. Neither need any of
the fancy logic that is in there. Well, I say "live with it". :-)

Plans are not yet sent back to the clients, so the units on the client
side know nothing about what they are doing, until a Command updates their
facing/position. To be fixed soon, should be quite simple, maybe split the
method Plan.attach() into Plan.attachServer() and Plan.attachClient()?

Ideas? Comments? Flames?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 27 Mar 2001, Mike Earl wrote:

>Well, I did some simple experiments yesterday, and Python objects do
>appear to have a considerable memory overhead, on the order of 100
>bytes.  I don't see where that comes from, but it's plausible.

Probably some internal Python magic or bookkeeping?

>1) Proper objects have overhead; arrays of basic types don't appear to
>(a 320x200 array of strings is not any bigger than you'ld expect).  We
>could, as chakie suggested earlier, keep the map's data in a big array
>and rebuild objects as necessary, or work directly with the values.  The
>latter is basically reducing us to working in C for the relevent code,
>though. :p

If memory usage of basic types is low we should use them wherever
possible, without making the data too hard to use. I'd personally not want
to work with a big array of tuples which contains other tuples, and just
extract data from the big heap of data using some "magic index values".
If possible I want to get my hands on proper objects at some stage! 

Conclusion: raw numbers in big arrays/tuples works, with minimal memory
overhead, but is a pain to work with.

>2) Another possibility; objects are large, but *pointers* are quite
>small.  If there are a small number of hex types, keep a dictionary of
>the ones being used, and put them in the map instead of creating new
>ones.  We'd only have 1 copy of any duplicated hexes, which would reduce
>the memory required dramatically.   Haven't really thought this all the
>way through, but it might be useful...

Yes, this could be an excellent idea. We'd of course need to keep any base
height values separate for each map location, but that should be no big
overhead. So, initialize the needed hexes in some shared list, array or
whatever, and insert from this container into the map. Should only copy
references, and thus allocate a maximum of (currently) 242 Hex objects.
Not that bad.

It would mean that the heights should be moved out from Hex and placed in
the [][] in Map. So Map would get a method getHeight() or similar to get
the base height for a hex, and the terrains in the Hex would then use this
base height for calculating the height of the 6 triangles.

 -- OR --

Hex would keep the interface it has, and calling Map.getHex(x,y) could
look like:

def getHex (self,x,y):
   # get the tuple with the hex and height for this position
   hex, height = self.data[x][y]

   # assign the height to the hex
   hex.setHeight ( height )

   # off we go
   return hex


This would of course lead to disaster iff the caller somehow uses several
hexes of the same map at the same time, as the height in the centrally
stored Hex instance gets modified all the time.


>btw: in testing some of this, I found a nice python tidbit.  To
>initalize a 320x200 array of blank objects, you can just take
>
>[[None] * 320] * 200

Ha! Good work Mike! Creating 2D/nD arrays has always been cumbersome, but
this is quite easy to use.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Well, I did some simple experiments yesterday, and Python objects do
appear to have a considerable memory overhead, on the order of 100
bytes.  I don't see where that comes from, but it's plausible.

I have a couple thoughts about reducing map memory use if it's
necessary:

1) Proper objects have overhead; arrays of basic types don't appear to
(a 320x200 array of strings is not any bigger than you'ld expect).  We
could, as chakie suggested earlier, keep the map's data in a big array
and rebuild objects as necessary, or work directly with the values.  The
latter is basically reducing us to working in C for the relevent code,
though. :p

2) Another possibility; objects are large, but *pointers* are quite
small.  If there are a small number of hex types, keep a dictionary of
the ones being used, and put them in the map instead of creating new
ones.  We'd only have 1 copy of any duplicated hexes, which would reduce
the memory required dramatically.   Haven't really thought this all the
way through, but it might be useful...

btw: in testing some of this, I found a nice python tidbit.  To
initalize a 320x200 array of blank objects, you can just take

[[None] * 320] * 200

This operation is also very, very fast, for some reason.

On Mon, 26 Mar 2001, Gareth Noyce wrote:

>Ok, thanks to you both for clearing up my confusion. MikeE -- I understand 
>what you're implementing more clearly now. Sorry for not picking this up in 
>the threads...
>
>Jan -- Stop teasing me about full 3D in version 2.0! ;-)

Yeah, sorry. :-) We should focus on getting 1.0 out of the door first. But
by the time we really start on 2.0 normal hardware should be so fast that
we can drive some kind of 3D fullscreen.

Anyway, so far this is quite OT, but you may get to use to 3DS Max talents
of yours sooner or later!

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hi all,

Ok, thanks to you both for clearing up my confusion. MikeE -- I understand 
what you're implementing more clearly now. Sorry for not picking this up in 
the threads...

Jan -- Stop teasing me about full 3D in version 2.0! ;-)

G

-- 
"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music." -- Unknown
--

Hi all,

I'm in the middle of the heavy reorganization for the new plan/command
handling. Created a few new directories and split up all old files in
src/protocol into a separate Plan and Command in src/protocol/plan and
src/protocol/command.

Nothing will work now, although the server does start... No comments are
yet updated, 95% of code still not updated. :-)

Command and plans are serialized separately now, a first character in the
text stream indictaes wether it's a plan ('p') or a command ('c'). 

Lots of other stuff. Please ask if there's something
weird/unclear/interesting, and I'll do my best to clear things up.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On Sun, 25 Mar 2001, Gareth Noyce wrote:

> From a side view (taking into account how I have imagined it, and 
>consequently designed the GFX):
>
>                                 [hill 2]
>                             __________________
>              [hill 1]      /
>          _________________/
>  [Grass]/
>_______/
>
>Now, I'm not arguing for either solution - that's entirely down to you guys 
>- it's just not been clear to me during these threads on LOS what the 
>intentions are for basic terrains: are all terrains one basic height, 
>merely deviating from this for hills? Or, is each terrain variable by some 
>choice made in the editor? With hills affecting this by a fixed or variable 
>amount?

This is also the idea I've had. It is not physically accurate, i.e. you
don't find terrain in nature that looks like this, but we have to draw the
line somewhere. I think it would be easier to imagine everything as flat,
except for the explicit hillsides. As all hexes are split into triangles
it is also easy to say which tris in a hillside hex are flat and which are
not. So, to climb the above hill the unit would go:

flat   climb    flat      climb      flat

I think that if we want more continuos terrain we'll have to leave it for
2.0, when we go fully 3D... Then it will fit nicely in, and we can use the
current icons as texture maps... :-)

>There is some weight behind the argument that the contour lines feature 
>should not be a gameplay device, and that the terrain graphics should 
>provide enough clues for the player to 'know' his field of battle. I guess 
>I'd like to hear your thoughts on what you want and intend to do. Are the 
>graphics suitable for the representations you are producing in code? If 
>not, they need to be changed, and I need to know how. If they are, fine, 
>I'll shut up and leave you all to continue...

I'm for a "middle way" approximation that uses terrain internally that
looks like the current gfx, but splits hexes into smaller parts (tris). No
needs for redesign of anything graphically, is what I really mean.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hard questions!


On 25 Mar 2001 16:40:04 +0100, Gareth Noyce wrote:
> Sorry to butt in here on a slight tangent, but I'm curious as to the need 
> for contour lines when the hills themselves are basically designed around 
> the idea of representing a contour elevation implicitly. Hence the reson 
> for chosing a fixed elevation approach for each hill, as opposed to a more 
> undulating terrain overall (graphically). I'm curious; are you both 
> intending that the basic sand/grass/mud terrains will have variable 
> elevations for each hex? Ie. they won't be flat?

Well, that was my thinking.  The current representation (well, it's not
quite fully coded) has each hex broken into 6 triangles with constant
slope.  It's derived from... um, backing up a step.

I assumes we know 'hex altitudes'; this is taken to be the altitude in
the center of each hex, and comes from the map file.  Each hex has 6
corners; we assume the altitude of a corner is the average of the three
hexes around it.  Then we connect the center with each corner, and we
have our triangles.  Flat will still be flat; hills will slope
more-or-less smoothly.  (I suppose a 1-hex hill in otherwise level
terrain would be a six-sided pyramid...)

If that isn't clear, let me know and I'll try again; the code, which
would be the best explaination, is only mostly done and thus no help.
(It makes sense to *me*, but that doesn't mean much.)



>  From a side view (taking into account how I have imagined it, and 
> consequently designed the GFX):
> 
>                                  [hill 2]
>                              __________________
>               [hill 1]      /
>           _________________/
>   [Grass]/
> _______/
> 
> Now, I'm not arguing for either solution - that's entirely down to you guys 
> - it's just not been clear to me during these threads on LOS what the 
> intentions are for basic terrains: are all terrains one basic height, 
> merely deviating from this for hills? Or, is each terrain variable by some 
> choice made in the editor? With hills affecting this by a fixed or variable 
> amount?
> 
> I ask, because I am worried that the terrains were designed to represent 
> the figure above - essentially flat terrains. If we have undulating 
> terrains, I'm not sure the current terrain graphics are really suitable. 
> They don't provide anywhere near enough implicit representation of 
> angle/elevation across small areas - say the width of a hex. Taken in the 
> same context, the hills do not seem to fit in to the more natural 
> calculations for terrains /at all/.


The source of the issue, I think, is that the movement of units is
continuous; things can happen in increments of much less than a hex.  So
it's much more straightforward for the engine for the map to be
continuous at that level; I was trying to effectively 'smooth' the
altitudes between adjacent hexes
so that we would end up (in the drawn picture) with a steady slope from
the middle of the grass to the middle of hill 2.

An example; if moving uphill slows a unit, and it marches from left to
right above, what happens?  Does it go at a steady, slower rate?  Slow
in some narrow zone at hex boundries?

On the other hand, this sort of continuous calculation is relatively
expensive in terms of memory and/or CPU; maybe a simple hex-based kludge
would be better in that regard.  It's tough to reconcile the continuous
unit placement with discrete hexes...  maybe another approach.  Don't
have one handy right now, though.  Have to think on that a bit.

> There is some weight behind the argument that the contour lines feature 
> should not be a gameplay device, and that the terrain graphics should 
> provide enough clues for the player to 'know' his field of battle. I guess 
> I'd like to hear your thoughts on what you want and intend to do. Are the 
> graphics suitable for the representations you are producing in code? If 
> not, they need to be changed, and I need to know how. If they are, fine, 
> I'll shut up and leave you all to continue...


It's certainly a sensible point that we don't want two visual
representations of the same thing, especially if they don't 100% agree. 

If the 'steps' up and down produced by hills are a consistant height, or
at least set according to icon (maybe some are steeper), otherwise
level, and we stick with the terrain graphics, is this a problem, or do
we maybe still have a significant issue with level vs. unlevel inside
hexes?


- mikee

At 04:52 AM 3/24/01, you wrote:
> > All surfaces (i.e. bitmaps) will be the same depth as the current screen
> > (most likely 16-32 bpp), otherwise blitting out the bitmap will mean
> > conversions every time it's blitted. I'm stil not sure what it will do or
> > look like? Is it supposed to be blitted on top of the map? Some kind of
> > countour lines? I'm quite lost here...
>
>
>Yes, contour lines.  The idea would be a set of lines drawn on the map,
>such that... um.  Suppose we take the map, and color every point where
>the elevation is *Exactly* a multiple of say, 5M.  The result would be a
>set of lines; tight concentric circles around hills, more distant
>parallel lines on long slopes, etc.  The logic to calculate this is not
>too bad, but I suspect it's too slow to do on the fly...  well, will
>see.  But a big surface at >=16bpp is a lot of memory....

Sorry to butt in here on a slight tangent, but I'm curious as to the need 
for contour lines when the hills themselves are basically designed around 
the idea of representing a contour elevation implicitly. Hence the reson 
for chosing a fixed elevation approach for each hill, as opposed to a more 
undulating terrain overall (graphically). I'm curious; are you both 
intending that the basic sand/grass/mud terrains will have variable 
elevations for each hex? Ie. they won't be flat?

As I've always imagined it (and certainly, as I've drawn it), the basic 
terrain icon represents an essentially flat surface, there is no _visual_ 
design for the basic terrain to be anything other, otherwise the hexes 
should be split into triangles, whos' colour provides visual clues as to 
the variation in angle/resulting elevation.

Again, as I've imagined it, all hills elevate from a flat base by a set 
amount -- providing a very clear contour of elevations across the map:

 From a side view (taking into account how I have imagined it, and 
consequently designed the GFX):

                                 [hill 2]
                             __________________
              [hill 1]      /
          _________________/
  [Grass]/
_______/

Now, I'm not arguing for either solution - that's entirely down to you guys 
- it's just not been clear to me during these threads on LOS what the 
intentions are for basic terrains: are all terrains one basic height, 
merely deviating from this for hills? Or, is each terrain variable by some 
choice made in the editor? With hills affecting this by a fixed or variable 
amount?

I ask, because I am worried that the terrains were designed to represent 
the figure above - essentially flat terrains. If we have undulating 
terrains, I'm not sure the current terrain graphics are really suitable. 
They don't provide anywhere near enough implicit representation of 
angle/elevation across small areas - say the width of a hex. Taken in the 
same context, the hills do not seem to fit in to the more natural 
calculations for terrains /at all/.

There is some weight behind the argument that the contour lines feature 
should not be a gameplay device, and that the terrain graphics should 
provide enough clues for the player to 'know' his field of battle. I guess 
I'd like to hear your thoughts on what you want and intend to do. Are the 
graphics suitable for the representations you are producing in code? If 
not, they need to be changed, and I need to know how. If they are, fine, 
I'll shut up and leave you all to continue...


G

-- 
"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music." -- Unknown
--

On 23 Mar 2001 11:52:17 +0200, Jan Ekholm wrote:

> Yes, memory usage for huge maps will be huge. Maybe we should do some kind
> of streamlining of the contents of the Map class? Maybe have Map
> internally keep only a tuple of the needed data, and when needed create a
> Hex (with all instances of Terrain) and return to the caller. This could
> be done like:


Hrrrm, that could work.  The terrains are an unavoidable problem,
though; the LoS code will access them frantically (every triangle along
the LoS between a moving unit and nearby units each time it moves).  And
the derivation of them is relatively slow.  You could simplify a great
deal by just saying, 1 altitude per hex, flat - this is what xconq does
- and fudge the LoS to handle that sensibly.

I have to admit, my first impulse is to say, 'Don't do that then! unless
you have 256MB'.  

I'm still wondering about overhead; that's 800 bytes per hex, more or
less.  Is the object overhead really so much?  Do we somehow end up with
a copy of hex.iconcolors in each hex??



> Yes, I meant absolute values, but wrote deltas. I thought about my
> wording, but it was clearly misleading. Deltas are often evil, try doing
> some 2D/3D rotations with deltas as opposed to absolute values calculated
> from some "original" value, and you'll end up with heavily distorted stuff
> quite soon. Done that... 


Wow, I think I have 15-year-old code of mine with exactly that bug in it
somewhere.  ;)  Odd that I never noticed... guess I never ran the
rotations long enough...  


> No data sent should be floating point, only integer data, to avoid stuff
> you described. 

I'm not too worried about sending floating point; even if something odd
happens, at least the errors won't accumulate.  OTOH, no reason to
burden the network with 12 decimal places of irrelevent precision.


> All surfaces (i.e. bitmaps) will be the same depth as the current screen
> (most likely 16-32 bpp), otherwise blitting out the bitmap will mean
> conversions every time it's blitted. I'm stil not sure what it will do or
> look like? Is it supposed to be blitted on top of the map? Some kind of
> countour lines? I'm quite lost here...


Yes, contour lines.  The idea would be a set of lines drawn on the map,
such that... um.  Suppose we take the map, and color every point where
the elevation is *Exactly* a multiple of say, 5M.  The result would be a
set of lines; tight concentric circles around hills, more distant
parallel lines on long slopes, etc.  The logic to calculate this is not
too bad, but I suspect it's too slow to do on the fly...  well, will
see.  But a big surface at >=16bpp is a lot of memory....


I like the command/plan/action structure discussed pretty well, I think
that will work as described.  Or at least the bugs are not apparent to
me now.

- mikee

On 22 Mar 2001, Mike Earl wrote:

>Just tried this (well, initializing 320x200 map, not editor).  Yikes!
>It takes me about 25 seconds, and adds a rather alarming 54MB (!) to the
>Python process size.  A 128x128 map is a more reasonable (but still
>largish) 5 seconds and 14MB.  That comes to almost 1KB per hex.  Where
>on earth is all the space going?  What's worse, my next bit was to
>assign an instance of util/math_util/plane3d as the height of each
>terrain, which will make the memory a bit worse and the time
>significantly worse.  Hrrm.  128x128 is the biggest map I've seen, if I
>remember correctly, in the Blizzard (*craft) games, with 64x64 more
>common; I begin to appreciate why!  But still...

Yes, memory usage for huge maps will be huge. Maybe we should do some kind
of streamlining of the contents of the Map class? Maybe have Map
internally keep only a tuple of the needed data, and when needed create a
Hex (with all instances of Terrain) and return to the caller. This could
be done like:

   class Map:
     ...

     def getHex (x,y):
         # get the internal tuple of data
         tuple = self.hexes[x][y]

         # create and return a new hex
         return Hex ( tuple )

This *could* save a lot of memory on the expense of making it slower to
access the map. The Playfile painting the map is one heavy user of the
Map, but it will cache the icon id:s internally in an array, just for
performance.

What do you think of that? Would reduce the number of object instances
that are allocated to a fraction, while retaining the same amount of
available data. I think there is some memory overhead for using objects
instead of a tuple, but I'm not sure.

>It's worse even than this, of course, because the server will have a
>copy of the map, too, when the game is running.

Yep.

>That all sounds good; it's also nice for future work.  A suitable 'Plan'
>subclass (with appropriate initialization?) would be a big piece of an
>AI player!  (You'ld still need some overall intellegence to coordinate
>units, but semi-intellegent units are a big first step.)

Yes, the AI player would then only need to concern itself with analyzing
the battlefield and issue plans. Oh, that is of course a quite large
"only" in the previous statement...

>My only quibble with updates is that I'd just send the new (modified)
>values, rather than the deltas, to the clients; otherwise there's some
>possibility of differences in rounding errors gradually building up (if
>they handle rounding differently).  Floating point is *really*
>treacherous:

Yes, I meant absolute values, but wrote deltas. I thought about my
wording, but it was clearly misleading. Deltas are often evil, try doing
some 2D/3D rotations with deltas as opposed to absolute values calculated
from some "original" value, and you'll end up with heavily distorted stuff
quite soon. Done that... 

No data sent should be floating point, only integer data, to avoid stuff
you described. What if Linux and Windows have some small difference in
their datatypes, and we end up with weird stuff. Only integer data. The
server can handle floats for its calculations, but should round all
results to ints before sending to clients. 

Do you otherwise have any input on the new command handling?

>I'll see if I can get the last of the altitude stuff in tonight and
>tomorrow before going out of town this weekend.   After that I'll
>probably do something for the isoclines, because a) it's cool-looking,
>and b) it may, in any case, be the fastest way to test the altitude
>code.  It will be slow to calculate, though.  If were stored as a b/w
>(or low-color??) bitmap, I wonder if that's too big/slow to just blit to
>the screen... any ideas?

All surfaces (i.e. bitmaps) will be the same depth as the current screen
(most likely 16-32 bpp), otherwise blitting out the bitmap will mean
conversions every time it's blitted. I'm stil not sure what it will do or
look like? Is it supposed to be blitted on top of the map? Some kind of
countour lines? I'm quite lost here...

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 22 Mar 2001 09:19:23 +0200, Jan Ekholm wrote:
> I tried to make really big maps (300x200 hexes), and that will stress the
> editor quite heavily. It takes a while to initialize the map (~30s for
> me), but after that scrolling etc is just as snappy as with smaller maps.


Wow,  you've been cranking right along on the editor.

Just tried this (well, initializing 320x200 map, not editor).  Yikes!
It takes me about 25 seconds, and adds a rather alarming 54MB (!) to the
Python process size.  A 128x128 map is a more reasonable (but still
largish) 5 seconds and 14MB.  That comes to almost 1KB per hex.  Where
on earth is all the space going?  What's worse, my next bit was to
assign an instance of util/math_util/plane3d as the height of each
terrain, which will make the memory a bit worse and the time
significantly worse.  Hrrm.  128x128 is the biggest map I've seen, if I
remember correctly, in the Blizzard (*craft) games, with 64x64 more
common; I begin to appreciate why!  But still...

It's worse even than this, of course, because the server will have a
copy of the map, too, when the game is running.

I don't immediately see a way out of this problem, other than 'don't do
that, then'.  Is all that space reasonable?  I wonder what the minimum
memory size for a python object is.  My feeling (and I will claim some
talents, but not user-interface guru, so take for what it's worth) is
that a slow startup is probably tolerable, especially if there is status
while loading, as long as interactive updating is snappy.  I'd keep it
simple for the time being and focus elsewhere, there being no lack of
things to do.  OTOH, if we need maps this big, we might want a new plan
now.

<plans, updates, etc.>

That all sounds good; it's also nice for future work.  A suitable 'Plan'
subclass (with appropriate initialization?) would be a big piece of an
AI player!  (You'ld still need some overall intellegence to coordinate
units, but semi-intellegent units are a big first step.)

My only quibble with updates is that I'd just send the new (modified)
values, rather than the deltas, to the clients; otherwise there's some
possibility of differences in rounding errors gradually building up (if
they handle rounding differently).  Floating point is *really*
treacherous:

>>> 1.1+.1
1.2000000000000002


I'll see if I can get the last of the altitude stuff in tonight and
tomorrow before going out of town this weekend.   After that I'll
probably do something for the isoclines, because a) it's cool-looking,
and b) it may, in any case, be the fastest way to test the altitude
code.  It will be slow to calculate, though.  If were stored as a b/w
(or low-color??) bitmap, I wonder if that's too big/slow to just blit to
the screen... any ideas?

- mikee