civil-devel Mailing List for Civil

On 30 Aug 2001, Michael Earl wrote:

>On 30 Aug 2001 17:52:11 +0300, Jan Ekholm wrote:
>> 
>> I've looked though the plans and code for combat, and it all starts to
>> look quite nice. Good work, Mike. I remember I suggested a while ago that
>> all actual combat would be resolved at the same time by the server, not
>> the execute() method in the plans themselves. Mike, do you still think
>> this is a good idea?
>
>Quite possibly.  I suppose instead of Fire generating the damagecmd
>itself, it would toss the attack event into a queue (dictionary?) to be
>resolved all at once after the movement phase; the resolve-combat
>routine would actually send out the damagecmds, maybe?  Also, should
>units move and shoot at same time?  How about reload time?

Yep, something like that. A dictionary would be smart, maybe have the
target unit id as key, so that it would be easy to get all firing targeted
at one unit without traversal.

What I had in mind would still leave the decision *when* to fire to the
plans. An attacking unit would, say, move 10 turns and then prepare for
fire 2 turns (reload), then 1 turn actual fire and then again 10 turns
movement. It would keep track of the current state internally and only
when actually firing it would enqueu the firing data.

For skirmish the idea would be similar, but it has a faster firing cycle,
maybe 1 fire, 2 reload and 1 wait? These cycles would eventually be
modified by unit modifiers such as morale (longer delays if low),
experience (faster if more experience and vice versa). For a first version
we may keep hardcoded values, just to keep it simple.

So, the plans send the MoveCmd:s and resolveCombat() the DamageCmd:s.

>There are some glitches with the formation stuff, too; that should be
>completed/stubbed-out/fixed soonish...

Where? Something I've coded up? There should be limitations as to what is
allowed in various formations. Limbered artillery will not do any forms of
attacking, they will defend themselves using handguns if close-range
assaulted and so on.

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

I did some minor hacking today and added use of a new button in the setup
dialogs. If you select a scenario and press "More info" you now get full
info about the scenario. A new button is also used in that dialog.

I also removed the file scenario/scenarioindex.xml, as it always should be
generated by the player/developer to suit his/her system. it contains
paths, and there has been more than one question as to why the server
tries to load scenarios from /home/chakie. :) So now it must be
regenerated manually when doing a checkout, as described in INSTALL.

This should reduce the amount of problems new players/developers face.

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

On 31 Aug 2001, Michael Earl wrote:

>On 30 Aug 2001 03:01:35 -0700, John Eikenberry wrote:
>> Anyways... I need to get more familiar with the code before I can think in
>> practical terms. I have the code from CVS, any tips on how to work through
>> the code to get a feel for it? 
>
>Probably the main things the AI would look at would be properties.units
>and properties.map for the terrain info (see map) and units (see unit).
>Note that the client has perfect info, so no peeking at units you can't
>really see!

That would be scenario.units and scenario.map. :)

>To see what sending orders looks like, have a look at the stuff under
>state; it has the code for the various interactive client modes and the
>commands they're sending.

Yep. There are basically two forms of things that get sent over the
socket:

	* plans
	* commands

A plan is something the player wants to do. When a unit should be moved
the player issues a Move plan. For retreating a Retreat plan is sent. Same
thing goes for Chat, Quit etc. The server receives the plans and can the
do two things:

    * immediately execute the plan (a Quit plan)
    * store the plan in the affected unit and send it back to the
      clients

The latter means that the players get sent back the plans they just
issued. The need for storing plans in the clients too is that then the
movements can be visualized easily, attack targets are known to the
players etc. The plans can't be directly stored by the clients themselves
in the unit, as they may be cancelled for some reason by the server.

So far, so good. Now the units know what to do. The actual execution and
all logic in a plan is executed by the server in its main loop. For
instance when a unit has a Move plan it will most likely move a few pixels
each turn, and those small movement steps should be known to the clients
too. So the server sends out a command, in this case a MoveCmd that
contains the needed info. The clients when the receive commands know it
contains updated data and just "apply" it to the internal structures. The
next time the unit is repainted its position has moved a few pixels. There
will be commands for all kinds of actions, such as: movement, state
changes (such as mounted -> dismounted), damage, morale changes etc.

The system may seem complicated, but the problem at hand is fairly
complicated too. I hop this helps somewhat in understanding the system.
The plans and commands are in protocol/plan and protocol/command
respectively.

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

On 30 Aug 2001 17:52:11 +0300, Jan Ekholm wrote:
> 
> I've looked though the plans and code for combat, and it all starts to
> look quite nice. Good work, Mike. I remember I suggested a while ago that
> all actual combat would be resolved at the same time by the server, not
> the execute() method in the plans themselves. Mike, do you still think
> this is a good idea?

Quite possibly.  I suppose instead of Fire generating the damagecmd
itself, it would toss the attack event into a queue (dictionary?) to be
resolved all at once after the movement phase; the resolve-combat
routine would actually send out the damagecmds, maybe?  Also, should
units move and shoot at same time?  How about reload time?

There are some glitches with the formation stuff, too; that should be
completed/stubbed-out/fixed soonish...

 - mikee

On 30 Aug 2001 03:01:35 -0700, John Eikenberry wrote:
> Anyways... I need to get more familiar with the code before I can think in
> practical terms. I have the code from CVS, any tips on how to work through
> the code to get a feel for it? 

Probably the main things the AI would look at would be properties.units
and properties.map for the terrain info (see map) and units (see unit).
Note that the client has perfect info, so no peeking at units you can't
really see!

To see what sending orders looks like, have a look at the stuff under
state; it has the code for the various interactive client modes and the
commands they're sending.

 - mikee

I've looked though the plans and code for combat, and it all starts to
look quite nice. Good work, Mike. I remember I suggested a while ago that
all actual combat would be resolved at the same time by the server, not
the execute() method in the plans themselves. Mike, do you still think
this is a good idea?

But ATTACK and ASSAULT need to be able to move the unit too, the first one
slowly and the latter fast. So they need code for moving the unit too.
Having the server duplicate this code is not wise, as it's already done
once in the plans Move and MoveFast. Duplicate code is usually evil.

So, I think it would be good to have the combat plans subclass Fire and
Move/MoveFast so that they get the movement code and firing code "for
free". But, neither SKIRMISH, ASSAULT nor ATTACK would ever resolve and
combat, they would move the unit if needed, but just *register* in the
server that they are firing at a unit. If you look at src/engine/engine.py
there's already a method resolveCombat() that is run after all plans have
executed. It could resolve all registered combat and thu be able to
resolve all fire targeted at one unit at the same time. 

What do you think? If it doesn't make sense at all please let me explain
further.

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

On Thu, 30 Aug 2001, John Eikenberry wrote:

Hi John,

>I've been mostly lurking hoping I'd get some time to help out and this is
>just the area I was interested in...  I'm still not sure if I have what I
>would consider copious free time to take on a new project, but I'd like to
>try to help out. 

Welcome in among the active developers! Nobody has copious amounts of free
time, but we do what we can. So don't feel stressed up if Real Life
demands full attention every now and then. That's just the way it is. :)

>I have a Masters in AI, and have always wanted to work on game AI. Though I
>have never done it professionally I've tried to keep up on it, reading an
>article here and there. I have at least used Python extensively in my web
>work.

Your knowledge seems to be a gift from heaven. :) Josh and Mike said they
were possibly interested in doing some Ai code, but otherwise there is
nothing real AI code at all. A framework for the AI client works ok
though, so there is very little "admin" work to do to add AI code.

>Anyways... I need to get more familiar with the code before I can think in
>practical terms. I have the code from CVS, any tips on how to work through
>the code to get a feel for it? 

Hmm, the best way is maybe to start digging in the AI client, i.e.
civil-ai.py and ai subdirectory. The main event loop for the AI client is
in src/ai/event_loop.py. It is quite simple, as it handles no graphics at
all. Otherwise the best way is maybe to ask this list if there's something
that is not clear or just seems weird.

	Chakie

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

I've been mostly lurking hoping I'd get some time to help out and this is
just the area I was interested in...  I'm still not sure if I have what I
would consider copious free time to take on a new project, but I'd like to
try to help out. 

I have a Masters in AI, and have always wanted to work on game AI. Though I
have never done it professionally I've tried to keep up on it, reading an
article here and there. I have at least used Python extensively in my web
work.

Anyways... I need to get more familiar with the code before I can think in
practical terms. I have the code from CVS, any tips on how to work through
the code to get a feel for it? 

Michael Earl wrote:

> On 29 Aug 2001 20:27:46 +0300, Jan Ekholm wrote:
> > Currently is does absolutely nothing. Not a bit, except for some automatic
> > retreats or attack orders the server may assign to units. But I will not
> > touch that part, at least not yet. I have no experience in making AI code,
> > and I still hope someone would volunteer to do that part. Anyone? Please?
> 
> I have some minimal AI background (1-semester class, um, oh-my-god, 12
> years ago) and a couple vague ideas how to go about this.  The most
> straightfoward might be some kind of recursive rules based system:
> 
> Win the game by destroying all enemy units.
> 
> Destroy all enemy units by iteratively picking the most vulnerable enemy
> unit and destroying it.
> 
> Destroy an enemy unit by picking a group of units and order them to
> attack it.
> 
> Pick a group of units to attack an enemy by...  (etc, etc. until you get
> to something that's actually calculatable and/or an order).
> 
> 
> My plan had been to start on this once minimal combat was working, but I
> can stay busy on other stuff until doomsday if other people are psyched
> up to go after it...
> 
> 
> OT: The explicit listing of the protocol stuff (protocol._init_) strikes
> me as ugly.  Is there some clean way we can do that by introspection?
> I'm not that familiar with python meta-class stuff...
> 
> - mikee
> 
> 
> _______________________________________________
> Civil-devel mailing list
> Civ...@li...
> http://lists.sourceforge.net/lists/listinfo/civil-devel

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"They who can give up essential liberty to purchase a little temporary
 safety, deserve neither liberty nor safety."
                                          --B. Franklin

On 29 Aug 2001, Michael Earl wrote:

>OT: The explicit listing of the protocol stuff (protocol._init_) strikes
>me as ugly.  Is there some clean way we can do that by introspection?
>I'm not that familiar with python meta-class stuff...

It's quite prone to errors too. It's the best thing I know of, as the
command and plan makers need to be available when a plan or command
arrives so that it can be deserialized. Knowing Python there probably is a
better way of doing things, but I don't know how. I think the current way
is fairly effcient at least. :)

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

On 29 Aug 2001 20:27:46 +0300, Jan Ekholm wrote:
> Currently is does absolutely nothing. Not a bit, except for some automatic
> retreats or attack orders the server may assign to units. But I will not
> touch that part, at least not yet. I have no experience in making AI code,
> and I still hope someone would volunteer to do that part. Anyone? Please?

I have some minimal AI background (1-semester class, um, oh-my-god, 12
years ago) and a couple vague ideas how to go about this.  The most
straightfoward might be some kind of recursive rules based system:

Win the game by destroying all enemy units.

Destroy all enemy units by iteratively picking the most vulnerable enemy
unit and destroying it.

Destroy an enemy unit by picking a group of units and order them to
attack it.

Pick a group of units to attack an enemy by...  (etc, etc. until you get
to something that's actually calculatable and/or an order).


My plan had been to start on this once minimal combat was working, but I
can stay busy on other stuff until doomsday if other people are psyched
up to go after it...


OT: The explicit listing of the protocol stuff (protocol._init_) strikes
me as ugly.  Is there some clean way we can do that by introspection?
I'm not that familiar with python meta-class stuff...

- mikee

On 29 Aug 2001 22:04:02 -0400, Michael Earl wrote:
> Not much.  Most of my PC time recently was 


Ack.  Mail-client clumsyness, don't mind me.

I haven't done too much code lately; I was short on time for a bit, then
was getting Debian up and running on my new harddrive.  (And I still
have some bizarre font problem I don't understand under X, but
anyway...)

I haven't done much for combat so far.  Essentially, I added the
'damagecmd' command to indicate damage done, made plan.fire use it, and
tweaked a couple of methods in unit so that damage reduces man count and
units with 0 men do nothing.

That's pretty much it, but it's something; the only thing still
desperately needed is a skirmish mode (ought to be striaghtforward).
About a dozen things I can think immediately that ought to be added; I
wanted a quick minimial implementation so that combat was no longer
blocking AI-work and/or an Alpha-release.

On 29 Aug 2001 13:46:08 +0300, Jan Ekholm wrote:
> Mike, what's the status of combat?

Not much.  Most of my PC time recently was 

On Wed, 29 Aug 2001, josh lucas wrote:

>Jan Ekholm wrote:
>> 
>> Oi,
>> 
>> I did a small change to protocol/plan/plan.py to make sure that the AI
>> client no longer crashes when it receives plans from the server. It may
>> still crash, but that would be for other reasons... :)
>> 
>> So, now it's possible to start adding real AI code to the AI client.
>> Currently is does absolutely nothing. Not a bit, except for some automatic
>> retreats or attack orders the server may assign to units. But I will not
>> touch that part, at least not yet. I have no experience in making AI code,
>> and I still hope someone would volunteer to do that part. Anyone? Please?
>> 
>
>I can honestly say that I know next-to-nothing about writing AI code but
>I will be more than willing to learn and hack.

That sounds good. "Real" AI can be very hard to do, I think, but it just
needs to do something simplish that resemles intelligence. Hmm, that's
already quite a lot, especially as it has to deal with a lot of troops and
several objectives:

	* enemy units
	* objectives

My approach would be to try to hack up some kind of simple recognition for
groups of units, and do stuff with those. But I haven't really thought too
much about it. The framework for the AI code is there though. :)

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

Jan Ekholm wrote:
> 
> Oi,
> 
> I did a small change to protocol/plan/plan.py to make sure that the AI
> client no longer crashes when it receives plans from the server. It may
> still crash, but that would be for other reasons... :)
> 
> So, now it's possible to start adding real AI code to the AI client.
> Currently is does absolutely nothing. Not a bit, except for some automatic
> retreats or attack orders the server may assign to units. But I will not
> touch that part, at least not yet. I have no experience in making AI code,
> and I still hope someone would volunteer to do that part. Anyone? Please?
> 

I can honestly say that I know next-to-nothing about writing AI code but
I will be more than willing to learn and hack.


josh

Oi,

I did a small change to protocol/plan/plan.py to make sure that the AI
client no longer crashes when it receives plans from the server. It may
still crash, but that would be for other reasons... :)

So, now it's possible to start adding real AI code to the AI client.
Currently is does absolutely nothing. Not a bit, except for some automatic
retreats or attack orders the server may assign to units. But I will not
touch that part, at least not yet. I have no experience in making AI code,
and I still hope someone would volunteer to do that part. Anyone? Please?

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

Hi all,

Well, my upgrade to Debian last night went ok, so now I can actually *run*
Civil on my home machine. I was stuck with an ancient Redhat that would
not let my upgrade pygame to 1.0 or 1.1 without really major other
upgrades.

What has been done, where should I jump back in? I thought that the "ai"
client should at least not crash when it runs, so I may fix that at least.

Mike, what's the status of combat?

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

Hi all,

The new units that Gareth made are now being used. They get loaded in
playfield/unit_layer.py which is the only place that paints units. A
simple fix, and now we also see differently colored enemies on the map. A
screenshot is on it's way one of tese days. :) I'm a lazy sucker.

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

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

> I've been away on a honeymoon in the Greek 
> archipelago, so this is my

Congrats Chakie! Welcome back etc... I hope you 
had a great time...

Gentlemen: start your coding! :)

G


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

Hello all,

I've been away on a honeymoon in the Greek archipelago, so this is my
first contact with this list for over a week. Things will slowly get back
in shape here, and I'll resume hacking where I left off... :)

Oh, yeah, I need to finally get that Debian Woody on my box so I can get
pygame > 0.9 working too. 

-----------------------------------------------------------------------------
      Real children don't go hoppity-skip unless they are on drugs.
           -- Susan Sto Helit, in Hogfather (Terry Pratchett)

Hi folks,

Ok, the new cracked mud terrain has been committed. Update the tree etc... 
A usage diagram for the actual main mud hexes can be found at: 
http://civil.sourceforge.net/incoming/usage.png

FYI; the terrain is only meant to meet grass, and there will be no hills 
for it -- however, I will be adding patches of dead grass, and some rocks 
(this will likely mean re-doing the grassy rocks we have to meet the new 
ones I've created... I'll look into that). There are also some more angled 
bits to add for where grass meets the cracked-mud. I'll try and get these 
committed this week. Depends on time though...

For now I'm gonna relax and make the most of the bank-holiday...

Happy hackin' all...

429-hexes-in-/terrains-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 26 Aug 2001 14:01:25 +0200, Josef Spillner wrote:
> I installed python from source, it didn't include the XML parser per default. 
> It was in one of the configuration files where you had to specify the 
> location of the expat source location (because expat doesn't really build a 
> lib as it said), and recompile/install again.

Yeah, it was a seperate debian package.  Loaded that and all seems well.

Now, if I can just get a text-mode print filter, and figure out why the
heck the font used by gnome help/about menus and the Gimp's menus isn't
rendering (small boxes only :( ), I'll be all set!

- mikee

On Saturday 25 August 2001 19:30, Michael Earl wrote:
> Now if I can just get Civil working under it: "xml.parsers.expat not
> found".  Anybody know that one off the top of their head?

I installed python from source, it didn't include the XML parser per default. 
It was in one of the configuration files where you had to specify the 
location of the expat source location (because expat doesn't really build a 
lib as it said), and recompile/install again.

Josef

-- 
The MindX Open Source Project: Fighting proprietary games
GGZ now! - The GGZ Gaming Zone: http://ggz.sourceforge.net
ggz.morat.net | ggz.snafu.de | jzaun.com | mindx.sourceforge.net/europeone

At 18:30 25/08/01, you wrote:

>Wow, very quiet on this list lately.

Honeymoons and too much work! ;-)

>I've had a little bit of time
>again lately, but it was mostly spent on diddling around with OS stuff,
>rather than Civil.  I've got debian-unstable on my machine now - it's a
>little more, um, unstable than I'd like, but it's growing on me.
>
>Now if I can just get Civil working under it: "xml.parsers.expat not
>found".  Anybody know that one off the top of their head?

Ok, from recent discussions with Chakie re: this subject, it seems that 
Python 2.0 or Pygame require Expat to be installed (it's an XML parser).

First check you have the 'expat' parser (by james clark) -- a good starting 
point is http://www.jclark.com/xml/expat.html, or (i guess?) apt-get 
install expat... This may resolve the issue entirely...

Or, it's down to some module dependency, and here I can't really help -- 
I've yet to get my debian woody install going either... :-\ Chakie may have 
used an XML module for the DOMParser that is part of Civil. I recall 
lengthy discussions about it. If this is the case then it's that module 
that is causing the problem. To be honest though, I'm guessing. A quick 
check through the Python 2.0 module docs may reveal more, or maybe whatever 
the scenario handlers pull in?

Soz Mike, I can't really help more. I've been trying to figure out the same 
thing re: debian but decided I had to re-install due to the new hardware 
I'm putting in. I got a bit lost in DSelect, and ended up putting far too 
much on my machine! :-|

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,

Chakie: hope you had a good week! ;-)

I've uploaded a quick mock of the new terrain-type I'm making. Have a peek 
at http://civil.sourceforge.net/incoming/cracked-mud-tbc.png

It's still pretty early on, you can see I've not yet done the tessellation 
for instance, but I think it'll be pretty kewl...

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
--

Wow, very quiet on this list lately.  I've had a little bit of time
again lately, but it was mostly spent on diddling around with OS stuff,
rather than Civil.  I've got debian-unstable on my machine now - it's a
little more, um, unstable than I'd like, but it's growing on me.

Now if I can just get Civil working under it: "xml.parsers.expat not
found".  Anybody know that one off the top of their head?

 - mikee