civil-devel Mailing List for Civil

Hey guys,

have any of you tried civil in a win32 environment, with the win versions
of python, sdl and pygame?  I'm currently downloading them - any
suggestions/snafus encountered with running civil in win32, or am I the
lone person to try this?

mike
-- 
  -------------------------
Mike Szczerban | m...@sz...
  -------------------------
--

On Wed, 29 Nov 2000 mik...@rc... wrote:

>This design seems good to me.

Thanks, but it's mostly your design, Mike.

>When you say 1 second turns, I assume you mean that's 1 second
>real-time, and 1*N seconds game time for some value of N?

Yep. Internally the game would use seconds. The player would never see
seconds anywhere, but there the time would be measured in game-hours and
game-minutes. One game-minute is a few real world seconds. The game time
is shown in the status panel at all time.

The player would also never see the term "turn" used anywhere, as the game
isn't turnbased. One game-minute *could* be thought of as a turn, but that
is not entirely correct either, as much things can happen in one
game-minute.

I hope you understand what I mean. It's still early here (well, 08:41...),
and I haven't yet got my morning coffee (off to get it now).

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

This design seems good to me.

When you say 1 second turns, I assume you mean that's 1 second
real-time, and 1*N seconds game time for some value of N?

> >This would have nothing to do with a recently purchased PSX2 
> would it?
> >Things have been so quiet this week I figured there was 
> serious gaming going
> >on! ;-) 
> 
> Of course not... I've been gaming the one game and the demos 

Oh! I'm actually a little disappointed! You're my roving reporter for all
things PSX2 until I actually see one available for sale in this country... 

> Basically I've been totally chewed up by the assignments I've 
> postponed
> all fall, so they have to be done if I want my university credits. 

Err, I remember that. Oh well, hope they're all going well. Good Luck!
 
> Next week will again see more hard work from my side on 
> Civil. But I will

I'm only kidding you... You work too hard as it is! :)

G

On Wed, 29 Nov 2000, Gareth Noyce wrote:

>This would have nothing to do with a recently purchased PSX2 would it?
>Things have been so quiet this week I figured there was serious gaming going
>on! ;-) 

Of course not... I've been gaming the one game and the demos on a demo CD
quite a lot. Also had to view our DVD:s too. The demos are basically crap,
there is no game there that I really like, but Timesplitters is a
Unreal-like thing which is great fun.

Basically I've been totally chewed up by the assignments I've postponed
all fall, so they have to be done if I want my university credits. 

>I have to admit I've been busy catching up with my Lady, and sorting out
>some misc developments for Sotonians (Benchmarking XSLT processors, doing
>the design docs) this week, /purely/ under the assumption that a certain
>lead-developer's thumbs would be too sore to type... ;-)

Next week will again see more hard work from my side on Civil. But I will
do small updates (such as the slice-thing) this week, unless MikeE
objects.

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

> If nobody objects I'll start to move Civil towards a time management
> system based on only turns, as I described in my mail yesterday.

I have been following, but it's not something I'm experienced in... Whatever
you and MikE decide is best rules...

> these changes tonight either. I have an assignment that must 
> be completed
> ASAP (a graphical 'top'). Why do today what you can do the 
> day before the
> deadline? :-)

Ahem, 

This would have nothing to do with a recently purchased PSX2 would it?
Things have been so quiet this week I figured there was serious gaming going
on! ;-) 

I have to admit I've been busy catching up with my Lady, and sorting out
some misc developments for Sotonians (Benchmarking XSLT processors, doing
the design docs) this week, /purely/ under the assumption that a certain
lead-developer's thumbs would be too sore to type... ;-)

G

If nobody objects I'll start to move Civil towards a time management
system based on only turns, as I described in my mail yesterday.

I will do:

* waste slices
* 1s is one turn
* one game minute is a number of turns (properties.turns_per_minute)
* client informa server with 'time' command that it has changed turn

The engine design will be for later, and probably I won't have time for
these changes tonight either. I have an assignment that must be completed
ASAP (a graphical 'top'). Why do today what you can do the day before the
deadline? :-)

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

On Mon, 27 Nov 2000 mik...@rc... wrote:

>re: Turns/slices.  My thinking here is this; as you say, we need the
>minimal time unit to be short.  (Ideally, the engine should support it
>being variable, but that's another issue.)  Slices can do this if the
>turns are too large.  But is there any reason to use X slices in a
>N-second turn instead of a N/X second turn?  (Well, yes - we probably
>have X times more messages that way, at least if N was small to begin
>with.)  Not sure what the correct optimization here is - many questions.  
>Should we start without slices and add later if necessary? Are slices
>something that the server is aware of at all, or are they purely a
>cosmetic client-side product?

There is no technical reason to divide the time known by the server into
two different units (turns and slices). Instead we could do with only one,
let's call it turns. I'd propose to have them 1s long. How many turns then
make up one game minute is configurable, and relaly does not affect the
engine that much. The number of turns/gane minute does matter when
calculating movement, combat etc, as we then have to be able to calculate
how long things should take to perform for the units.

Having only one time unit is easier as you say. Slices are probably
unnecessary by now. Slices were something the game was aware of, and use
to perform timing, so they are not totally "vapour", but they can easily
be made unnecessary by now.

Why not try this to begin with:

* game server run internally with a 1s time unit (one turn). 

* a certain configurable number of these turns make up a game minute.

* the game engine runs a few turns ahead of what is displayed on the
  screen

* the display engine runs a few turns after the game engine

* the engine sends out events to both the client and server display
  queues, from which they are displayed when the display engine reaches
  that turn

* the client sends a message when it has switched turns so that the game
  engine (server) knows not to expect any more actions from the client for
  the turn in question.

* every thing the player do result in an action that is timestamped with
  the current time (the lagged time, not game engine time), and sent to
  the game engine

* the game engine places the new actions on an incming queue, pops them
  at the proper time, checks when the action should be performed and
  places data in its own internal queues

* the game engine resolves actions for the current turn and sends events
  to both players


>About minimum latency and AI: sorry, I hadn't meant by that that AI
>players could cheat - I figure them to operate just as a human player
>would.  What I meant was more this:

Ok, I understand what you mean. We do have to have some kind of basic AI
that will do some simple actions for the units when that player "isn't
watching", such as retreat, return fire etc. Simple orders that are
individual. It gets hard if we try to do an AI to control masses of units
at the same time.

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

re: Turns/slices.  My thinking here is this; as you say, we need the
minimal time unit to be short.  (Ideally, the engine should support it
being variable, but that's another issue.)  Slices can do this if the
turns are too large.  But is there any reason to use X slices in a
N-second turn instead of a N/X second turn?  (Well, yes - we probably
have X times more messages that way, at least if N was small to begin
with.)  Not sure what the correct optimization here is - many
questions.  Should we start without slices and add later if necessary?
Are slices something that the server is aware of at all, or are they
purely a cosmetic client-side product?

About messages/second, you're right, of course, I completely neglected 
overhead of all kinds.  I actually have excellent tools for analysing
this sort of problem here at work and will take a few minutes to model 
that this week. :)  

About minimum latency and AI: sorry, I hadn't meant by that that AI
players could cheat - I figure them to operate just as a human player
would.  What I meant was more this:

I imagine units (companies?) have certain 'atomic' orders they follow.
(eg. shoot at X, turn to facing Y, rally, fortify, march forward).
There could be a limited AI, a 'company commander', for both AI and
human players, that operates on a slightly higher level and which
(once it exists, anyway) recieves the actual higher-level orders from
the player (eg move to [x,y], defend your position, asault enemy unit
Z) and can enact those or take simple actions on its own with
effectively zero latency ('face and shoot at nearby enemy units')
unless their standing orders/doctine are previously overridden by the
player.

Oops, back to work for me.

- MikeE

I had a hectic weekend with all play and no work, so this response is a
little late. :-)


On Fri, 24 Nov 2000 mik...@rc... wrote:

>Both the local (server) and remote (client) display keep a sort of
>queue (well, I don't know if it's technically a queue...) of events to 
>apply.  The local display reads it from the engine directly somehow,
>the remote reads it from the network.
>
>This pending event structure looks something like:
>
>Turn 10:
>     Complete
>     Events:
>	Unit 1 moves to (x,y)
>	Unit 2 shoots unit 1
>	Unit 1 damage 80%
>Turn 11:
>     Incomplete
>     Events:
>	Unit 1 turns to 90
>
>
>Currently, turn 9 is being played on the display (events cut up into
>slices?), and the player can issue orders, which are game-time-stamped 
>as turn 9 (finer than that?) and sent to server.

This scheme is quite exactly what you've lately managed to convice me to
believe in (does that make sense?). Both the client and the server has a
queue of things that "has happened" in the game engine and should be
displayed at the proper time. This is logical, and quite easy to
implement, I think.

We do need some kind of time unit that is less than a gamworld minute (or
12 realworld seconds above), as we otherwise will get really jerky
movement. As en example cavalry in full charge could move up to 50km/h,
which little more then 800m/minute. If we do the update only once for each
turn this would be horrible, as the cavalry could bounce all over the
place. We need to be able to move quite small steps, in the case above
maybe once per every 1-3 seconds to make sure we get smooth(er) animation. 

As for timestamps I think we should timestamp all packets going from both
players to the engine with the turn and slice (or just turn if we get rid
of slices). More accuracy is better. Much happens in, say, 12 seconds, so
there must be some way of timestamping messages more accurately than that. 

>Now, the display is running a clock at (say) 12 real-world-seconds per
>turn.  So, after 12 real-world-seconds play out (game clock advanced
>proportionally), it begins playing out turn 10, and sends a meta-game
>message to the server, "Starting turn 10" - once both players do so,
>this is the server's cue to start processing turn 12, since all orders
>for 12 must be in by now.

Hmm, yes, this could be a good idea. This would make it quite simple for
the engine to keep track of the turns, without the need for millisecond
latencytiming etc.

>If turn 11 is *still* incomplete when it becomes time to play it, the
>display freezes with a dialog box "Waiting for server...".  (Possibly
>this message is different based on whether the server is only unable to
>calculate fast enough, or is awaiting a 'starting turn' from the other
>player?)  If for some reason, the display has events for turn 10 but
>is unable to apply them all before turn 11 starts.... um, what is
>correct behavior in this case?  Send message to server requesting a
>5-second pause?  With these two cases there is no (little?) need for
>explicit clock synchronization; they can't get more than 1 turn out of 
>sync.
>
>It would be nice if the turns could be cut so fine that we do away
>with slices entirely, but that costs bandwidth.  I calcuate that with
>a 28.8 modem and 80 byte updates (?) we can send 45 events/second....

Please elaborate a bit on this. Nothing of course stops us from making
turns short (1-2 seconds) and skipping slices entirely. It could be a good
idea. But we need the smallest unit of time to be quite short, so that
animation can flow smoothly.

45 events/s is much, and something like that would be enough. Of course
over a modem that may be quite optimistic, as we have quite high latencies
and the TCP traffic and IP headers need to be accounted too.

>One other comment on delays: While players suffer a minimum
>turn-around on orders, AI company commanders (for both players and AI
>players) would not, and within their limited battle doctrine/standing
>orders could react pretty much instantly.

Yes, this could be called "cheating", but a competitive AI which uses the
same requirements as a human player is hard to make. But this is so far
secondary, the most important is to leave hooks for the AI and provide a
working two-player mode.


Well, this seems to gradually level out into something that can be
implemented. I think this will work out just fine once we ponder it a
little bit more.

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

Ok, more detailed thoughts on how an asynchronous scheme might work,
with some redundant restatement just to clear my own head:

Both the local (server) and remote (client) display keep a sort of
queue (well, I don't know if it's technically a queue...) of events to 
apply.  The local display reads it from the engine directly somehow,
the remote reads it from the network.

This pending event structure looks something like:

Turn 10:
     Complete
     Events:
	Unit 1 moves to (x,y)
	Unit 2 shoots unit 1
	Unit 1 damage 80%
Turn 11:
     Incomplete
     Events:
	Unit 1 turns to 90


Currently, turn 9 is being played on the display (events cut up into
slices?), and the player can issue orders, which are game-time-stamped 
as turn 9 (finer than that?) and sent to server.

Now, the display is running a clock at (say) 12 real-world-seconds per
turn.  So, after 12 real-world-seconds play out (game clock advanced
proportionally), it begins playing out turn 10, and sends a meta-game
message to the server, "Starting turn 10" - once both players do so,
this is the server's cue to start processing turn 12, since all orders
for 12 must be in by now.

If turn 11 is *still* incomplete when it becomes time to play it, the
display freezes with a dialog box "Waiting for server...".  (Possibly
this message is different based on whether the server is only unable to
calculate fast enough, or is awaiting a 'starting turn' from the other
player?)  If for some reason, the display has events for turn 10 but
is unable to apply them all before turn 11 starts.... um, what is
correct behavior in this case?  Send message to server requesting a
5-second pause?  With these two cases there is no (little?) need for
explicit clock synchronization; they can't get more than 1 turn out of 
sync.

It would be nice if the turns could be cut so fine that we do away
with slices entirely, but that costs bandwidth.  I calcuate that with
a 28.8 modem and 80 byte updates (?) we can send 45 events/second....


One other comment on delays: While players suffer a minimum
turn-around on orders, AI company commanders (for both players and AI
players) would not, and within their limited battle doctrine/standing
orders could react pretty much instantly.

On Thu, 23 Nov 2000, Gareth Noyce wrote:

>Civil-ians,
>
>Small snippet that may be of interest; my boss has a list of official
>military symbols for objectives, targets and the like. Dunno if these are
>valid for the time period we're developing under, but I think it will be
>well worth using them regardless -- they'd give a bit more accuracy for the
>military aspects of the subject matter...
>
>I'll forward them to the site for you all to peruse when I get hold of them
>-- you can make a decision regarding their use...

Oh, yeah! Please put them on the list (or on the www-incoming if big).
Could be very interesting to see. The more 'real' stuff the better.

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

Civil-ians,

Small snippet that may be of interest; my boss has a list of official
military symbols for objectives, targets and the like. Dunno if these are
valid for the time period we're developing under, but I think it will be
well worth using them regardless -- they'd give a bit more accuracy for the
military aspects of the subject matter...

I'll forward them to the site for you all to peruse when I get hold of them
-- you can make a decision regarding their use...

G

--
Gareth Noyce -- Applications Engineer
         Pennant E-Services 
Tel: 023 8090 8218; Fax: 023 8033 6117
--

... I could not resist tinkering a little and putting Gareth's new icons
to work. Two new screenshots on the homepage are the result of this.
Painting units worked already (well almost), so that was easy to get
working, as was the new "New game" icon.

The direct links are:

	http://civil.sourceforge.net/screenshots/snapshot18.png
	http://civil.sourceforge.net/screenshots/snapshot19.jpg

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

On Thu, 23 Nov 2000, Gareth Noyce wrote:

>> One question though. Did you plan on making different sizes 
>> of the icons,
>> or just one size?
>
>You want different sizes to reflect losses yes? If so, this can be done. How
>many sizes would you like? 2? 3? 

Well, we talked about 6, but that is probably overkill. Maybe 3? As units
in real life would likely be bale to differ (even over longer distances)
on 100, 50 and 10 men, so it would make sense to visualize these sizes
somehow.
 
We could have the sizes represent 0-33, 34-66 and 67-100+ men. This means
a lot more work for you though, but would add to the playability a lot. It
is easier to be able to judge your own strength (and the enemy's too) if
you can see a rough size of the units available.

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

Thanks for the compliments Jan! I'm feeling better already this morning! :)

> These look good too. I haven't seen the artifacts yet, as I 

They're there. They'll go soon... And the aliasing sux right now...

> One question though. Did you plan on making different sizes 
> of the icons,
> or just one size?

You want different sizes to reflect losses yes? If so, this can be done. How
many sizes would you like? 2? 3? 

G

--
Gareth Noyce -- Applications Engineer
         Pennant E-Services 
Tel: 023 8090 8218; Fax: 023 8033 6117
--

On Wed, 22 Nov 2000, Gareth Noyce wrote:

[map editor]

>I've been involved in the creation of map editors before for Spliff n Tokey
>(the platformer). That was quite a beast as it had to calculate jump arcs,
>enemy actions and such... On the face of it, the Civil editor is a little
>simpler... Unfortunately, making a map is one thing, getting all the
>objectives set in a framework that is easy for the user is more tricky...

Ok, you have most experience here, so we'll follow you advice here.
 
>> Creating units and objectives (basic data, not placing them) 
>> can be done
>> using a simple textbased application, maybe curses if we're 
>> really fancy.
>> The GUI part could maybe then use the defined units/objectives so that
>> they could be positioned. Still a lot of work.
>
>Yes, it is unfortunately. We'll have to look at it quite hard before we get
>too involved. These things are easy on the face of it -- as it's tempting to
>assume that it's purely for the maps. It may be worth splitting it into
>mini-apps as you say above. One for the basic scenary generation (Gimme some
>grass... Gimme a hill...), and one for the scenario editing. This makes
>sense, but I don't know if it's a Good Thing to have them split...
>
>Regardless, its not something to code now. Certainly something to design
>tho...  

Id didn't mean split it into several apps, but just to have several
'views'. One graphical view where the map is created and one textual view
where units, objectives etc are created.

I think there are these individual tasks that need to be done:

* main scenario info (name, description, date etc)
* information about the author
* objectives (add, delete, view, change)
* units (add, delete, view, change)  
    * create the organizations (brigades, regiments etc)
    * create all leaders
    * create the companies (name, size, type)
        * assign leader
        * assign them to a battallion or regiment

* define the map (size)
* edit map terrain 
    * choose an icon and paint with it
    * validate map for correctness (hills line up etc)
* place units
* place objectives
* save to XML
* load old scenario from XML
    
Other things? As Gareth said we can plan this now, let it bubble for a
while and then implement later.

One thing I find that is missing from the scenarios is information about
the author. I know it is more encouraging for people to create and submit
scenarios if they get their name on it too. If we then distribute
contributed scenarios at some time I think people will feel pride to see
their name in screen "Scenario Info". This is our way to credit people.

So I propose a new tag <authorinfo> or <author> to be placed in the
<scenarioinfo> tag. Maybe with the following children:

* name
* email
* modified (date when last modified)

Other data?

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

On Wed, 22 Nov 2000 mik...@rc... wrote:

>re: pickling.  I haven't used it, but I had also used the Object
>Serialization in Java, and it worked like a charm for me (plus I'm
>lazy, so...)  Your Milage May Vary, I guess.

Yes, I think so. It all worked ok for a few months, but then we got
occasional corruption. What was weird was that is mainly seemed like the
deserializer part seemed to fail to give some members the correct values.
They got the values that the constructor would have given them, not the
current value. If the stream would have been totally corrupt we'd have got
an exception, but now we just could not trust the data, and that is worse.

>If you think you have no time due to girlfriends, try a wife and
>2-month old daughter and see how much you have. :)

I think you may be the winner in the competition "I have least time".

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

On Tue, 21 Nov 2000 mik...@rc... wrote:

>*) Symmetrical.  Each side transmits their orders to the other, and
>they run simulations in parallel.  Since orders don't take effect
>within much more time than the transmission latency, this is fine.

This is the easy solution, and the one I've been proposing so far. It does
however have a few weak points, the most serious one I think is
guaranteeing that both simulations reach eaxctly the same results.
Discrete calculations should solve this problem quite far, but we might
get some calculation which becomes 1.999999 for one party and 2.00000 for
the other, and this gets truncated to 1 resp. 2. This creates a lot of
problems later on, and could be extremely hard to debug, as the error may
have happened a few *hours* earlier.

This scheme therefore requires extremely deterministic calculations that
don't generate fractions at all, which can be hard.

>
>       Good: Probably least bandwidth requried.  Simpler high-level
>	     design.

How we look at much bandwith usage anyway? I the simulations are run in
parallell we do not have much traffic, as you state above. Only some
packets for each action the player does, and a few others for combat
resolutions etc. Negligible(sp?) traffic, I think.

>       Bad:  Making sure simulations run exactly the same may impose
>	     limitations on engine and be difficult to debug if there 
>	     is a problem.

This is correct.



>*) Assymmetrical.  One side runs the simulation and recieves orders
>from the other, transmitting updates to it.  The displays lag the
>calculated action by 1 turn or more (is this really necessary?).
>
>       Good: Simulation engine coding simpler.
>       Bad:  More pieces.   Networking code more complex.
>             Some updates (fatigue?) may need to be done locally
>	     anyway, creating complexity.

By lagging the display we also increase the minimum response time to
actionst he player does. As each action results in something being placed
on the simulation queue the action must be placed "a little" forward in
time compared to where the simulation is right now. Example (turn.slice):

Player seems time: 0.0
Engine calculates: 2.0

Player does something at 0.0.
New action created.
Action placed onto queue at 2.1
(Action sent to other player)
Advance slice.

Player seems time: 0.1
Engine calculates: 2.1
Engine calculates player action, creates display event.
Event placed onto display queue for time 2.1

So, it takes two turns (or one if the engine is only one turn ahead of the
display) + a few slices before the player sees any action. This can be too
long for simple actions, such as 'fire at target', or 'turn 10 degrees',
which would in real life be faster.

If the engine is only one turn ahead of the display this would probably be
ok, but we'd have less margins for lag etc. But if one turn is, say, 3
seconds it should be enough for the packets to arrive.

What would you prefer? Symmetrical or a server-based system? I'm slowly
leaning over to the serverbased version. It will generate a lot of more
traffic, as we need to send:

From server:
  * all movements, each pixel or the smallest step a unit can take
  * all rotations, each step (10 degrees could be the minimum delta)
  * all stat changes (fatigue, morale)
  * all combat resolutions (loss of men, morale, fatigue, leader,
    advances/retreats etc)
  * all visibilty changes (unit spots another unit)

To server:
  * all actions taken by the client player
  * movement orders
  * rotation orders
  * attack orders
  * stat change order (column/battle/mount/dismount/etc)
  * rally orders

All actions performed by the player at the server machine will generate no
network traffic.

Hmm, maybe we can live with this?

>Symmetrical is easier and probably fine for right now but I worry that
>it might prove limiting in the not-too-distant future; if units can
>take arbitrary facings we'll run into rounding issues no matter what
>we do, I think, because their correct positions may turn out to be
>irrational or infinite repeating decimals...  in short, I'm worried
>about the simulation being perfectly determinate and being able to
>prove to ourselves it is.  I believe the symmetrical system is easier
>to build but harder to maintain.

I wrote the above yesterday. For some silly reason I had postponed the
message instead of sending it, so I continue with some fresh ideas today.

I'm starting to feel that a serverbased solution is the best one. It would
keep all calculations in one place and have the client more as a "dumb
terminal" that receives input and displays output, but with little other
functionality. We then don't get any rounding problems or similar, and all
data management is easier. What we could get problems with is time and
syncronization.

My proposal/idea for time management is to change that way we handle time
now. Presently Civil synchronizes each new turn with both players through
the command 'time' and 'timeack'. Instead of this I think both games could
run their own internal time loop, based on seconds. When the players
connect the time is reset to 0. From that point on time runs independently
in the client and server. At regular intervals time needs to be resynched,
due to clock skew, maybe once every hour?

When a player does something a command is generated which contains a
timestamp when it happened and sent of to the server (or just passed to
the server engine if player is the server). Based on the timestamp the
engine calculates when something should happen (maybe 2 turns ahead in
time), puts events on the internal queue and sends back events to the
client too.

The part of the engine that resolves actions should, as you suggested, run
maybe 1 turn ahead in time. That should allow for time to send events back
to the client for display. The trickier part is to get commands from the
client to the server *before* the engine has reached the time when the
command should do something.

Argh, this is hard to describe in writing, I hope someone understands what
I mean. Basically I mean we further investigate the asymmetrical solution
MikeE suggested. Does anyone else have any ideas? Obvious flaws are good
to point out before 10kloc are written. :-) 

Oh, well, back to serious work again.

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

On Wed, 22 Nov 2000, The Corruptor wrote:

>Civilians,
>
>Some work has been done! There is a 'New Game' button and the website has
>been updated. Mike Earl has been added to the front page. Sorry Mike for not
>including you sooner, this was an oversight on my part (as is fairly usual
>for this project... :-\

Thank you Gareth. It looks wonderful. Reminds me of the new Playstation 2
I'll get tomorrow. :-) You said that it could be hard to get some hexes in
the icon, but I don't think you could've done it better than that.

>I have also included some rough unit sprites. These are not complete. For a
>start they still have white artifacts, and the aliasing hasn't been fixed
>since the programmatic rotation... But, it'll probably take nearly a week to
>fix this for all 35 sprites and I'm keener to get on with the mounting list
>of things to do (like the other units).

These look good too. I haven't seen the artifacts yet, as I just completed
some code for loading them. I think they will look awesome together with
all other stuff on the map.

One question though. Did you plan on making different sizes of the icons,
or just one size?

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

Civilians,

Some work has been done! There is a 'New Game' button and the website has
been updated. Mike Earl has been added to the front page. Sorry Mike for not
including you sooner, this was an oversight on my part (as is fairly usual
for this project... :-\

I have also included some rough unit sprites. These are not complete. For a
start they still have white artifacts, and the aliasing hasn't been fixed
since the programmatic rotation... But, it'll probably take nearly a week to
fix this for all 35 sprites and I'm keener to get on with the mounting list
of things to do (like the other units).

I will return to these at a later date... Just remind me if I forget! ;-)

Cheers all...

G

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0

iQA/AwUBOV4dgWtL7e1IGHY8EQIZpQCgzcgfbemfYvuXxMGsIrE4GVkLOIYAoPpn
ygxEeOudynAwxqeYKjo7PhlF
=S/8P
-----END PGP SIGNATURE-----

Just noticed: the link to screenshots from the text on the front web
page still points to grabs.html, which no longer exists.  (The sidebar 
link is fine.)  A couple of the links on the screenshot page - main
game view, old screenshots - point to "*".

re: pickling.  I haven't used it, but I had also used the Object
Serialization in Java, and it worked like a charm for me (plus I'm
lazy, so...)  Your Milage May Vary, I guess.

If you think you have no time due to girlfriends, try a wife and
2-month old daughter and see how much you have. :)

- MikeE

> Yes, please update the site.  I will be doing the remaining 
> terrains (did a
> heavy mud and stony last night)

Can you tell me if you are only producing one hex per terrain, or multiple?

I added a directory 'incoming' where temporary stuff can be put for
vieweing by other people. It is:

shell1.sourceforge.net:/home/groups/civil/htdocs/incoming/

You can 'scp' stuff there using your normal SF name. The stuff can be
simply reached through the url: 

	  http://civil.sourceforge.net/incoming/


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

> Done. Have a look at: 
> 
> 	http://civil.sourceforge.net/list.php
> 
> Minor changes to the code, and the generated page is quite nice. 

Smart, I'll update tonight...