civil-devel Mailing List for Civil

> I can't really think of anything really good, and changing the music
> requires a lot of work (i.e. a new tune). Ideas?

* Fading a little logo/piccie type thing in the middle when mode turns
* I knock up a little mode icon which sits/spins about in a random corner of
the screen during each mode, giving a nice clear indication throughout the
mode
* Change the cursor so we have one for playback, and one for "action"

Or all of the above!

G

-- 
"In 1974, computers were oppressive devices in far-off air-conditioned
places. Now you can be oppressed in your own living room."

  -- Ted Nelson
--

Hi,

Reading the BUGS file I noticed this little gem in "MSA's NITPICKING
SECTION":

"""
Clearer visual signs when we are in action mode, and when in "real" play
mode. Clearer visual signs how to end turn, and how to end action phase.
"""

This can indeed be a problem. The only indication currently is that the
little window with unit orders disappears and the time controls window is
shown. But what more can be done?

* show a message in the playfield?
* change background music?

I can't really think of anything really good, and changing the music
requires a lot of work (i.e. a new tune). Ideas?

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times

Oi,

Just some ideas. Meant for documentation and future reference, as well as
comments.

Routed and disorganized units
------------------------------

I've started to finally get this part into some kind of order. It's not
too hard, just a lot of work. The idea is that a unit may become
disorganized or rout in some special situations:

routed:
    * a morale check for an assault fails (the unit chickens out)
    * a unit takes too much punishment and morale has dropped too low

disorganized
    * after a unit has engaged in melee combat
    * after a routed unit gains morale it will become disorganized before
      it becomes fully normal
    * after retreating

Both of these implies that the unit is in a suitable routed or
disorganized mode. A few new Mode subclasses will be needed, but that's
easy work.

The current idea is that there will also be plans that implement the
practical parts of the routing and disorganized units. These plans will
set the unit in a suitable state, and take care of moving it if needed. A
routed unit will move towards the own lines, until it is no longer fired
upon from a certain distance. When in safety the routed unit will stop and
starts to regain morale. So a Rout plan also is a Move plan.

A unit that is disorganized is just a little bit messy, and will need to
be organized to get back into a suitable formation. It will not need to
move in any way (unless it takes a morale drop from something and routs).

A unit becomes routed mainly through combat resolution. A unit can become
disorganized through several ways, mainly retreating and rallying. While
routed/disorganized the unit gets a plan Rout or Disorganized that does
not allow any orders being given to the unit. The player can just silenty
watch the unit slowly rally, and maybe speed the pace up a bit by moving
some higher commander near the unit. 

The plans must be a bit special in that they can not be cancelled. All
normal plans can in the orders phase be cancelled by pressing backspace or
choosing "Cancel" from the menu. This means we need an extra flag for each
plan that says wether it is "cancellable" or not. Should be easy enough,
and only plans that are not cancellable should have to do anything about
the flag, as it would default to having the plan cancellable.

These plans would be active for the units until they think they are done.
They would also clear out any old plans. I think it would be silly to have
a unit rout 500m, get rallied and immediately continue where it left off
and doing something totally inappropriate.

Doing stuff with a plan and some modes would mean that the engine.ai.rally
class is not needed anymore. Hmm, maybe it should instead just increase
morale, and the plans would check when morale is high enough and then take
proper measures when the morale is heigh enough.

Comments? Anyone understand anything from these ramblings?


-- 
    - "Remember -- that which does not kill us can only make us stronger."
    - "And that which does kill us leaves us dead!"
                                           -- Terry Pratchett, Carpe Jugulum

> 
> eMac? You mean the iLamps? Those flatties are not too cheap...

No, I mean "eMac". Not the flatties, the "similar to the old iMacs, but
cheaper" model... Check their website.
 
>> Oh, and Project Builder ++ SDL rox my world ;-)
> 
> I've heard it has OpenGL nicely integrated too. And apparently it all
> builds on top of the normal GNU toolchain (gcc & co).

That it does. And for dummies like me, you don't even have to worry about
it. Project Builder looks after you ;-)

G

-- 
"Like German tourists: The stupid are everywhere!"

    -- Arnold J. Rimmer, Red Dwarf Series 8, Episode 2
--

On Wed, 26 Jun 2002, Korruptor wrote:

>> Great! It would be fun to some day play a little with developing stuff on
>> OS X. I'm a bit curious about the development environment that's been
>> built up there. If they were a bit cheaper (for decent hardware) I could
>> get one to play with.
>
>Think "eMac". Nice, Cheap, Fast...

eMac? You mean the iLamps? Those flatties are not too cheap...

>Oh, and Project Builder ++ SDL rox my world ;-)

I've heard it has OpenGL nicely integrated too. And apparently it all
builds on top of the normal GNU toolchain (gcc & co).

-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

> Great! It would be fun to some day play a little with developing stuff on
> OS X. I'm a bit curious about the development environment that's been
> built up there. If they were a bit cheaper (for decent hardware) I could
> get one to play with.

Think "eMac". Nice, Cheap, Fast...

Oh, and Project Builder ++ SDL rox my world ;-)

G

-- 
A man's four essential food groups are: white meat, red meat, warm beer and
cold lager. Please ensure all meals contain a good balance of the above in
acceptable quantities.  Everything else falls under the category 'garnish'.

  - Author: Unknown Sexist...
--

On 26/6/02 10:23 am, "Marcus Alanen" <maa...@ra...> wrote:

> On Wed, 26 Jun 2002, Korruptor wrote:
> 
>> Depends how advanced we want to go. We can also include Pygame and Python
>> for the real dumb-ass users...
> 
> Basically, we need to do this for windows. For .rpm and .deb we use
> dependencies ofcourse.

RE, Windows: Not so sure. Python and pygame are easy installs from fixed
locations. If we package the lot we'll be pron to support questions for
Python/Pygame. I'd rather they got those themselves from the original
locations. I merely threw the comment in as an illustration of how easy it
is to create win32 installs.

G

-- 
    "If Bill Gates had a dime for every time Windows crashed...
     Oh, wait a minute. He already does..."

        -- Anon
-- 

        

> There'll be some more work with the deb:s and rpm:s, but that's also for
> later. What does OS X use as a native package? Are they doable by mere
> mortals?

OS X has something called package builder. I'm quite happy to play around
with this, although I hesitate from offering the "full" decencies package.
Bob's kitchen sink distro will have to be downloaded separately...

Package builder looks fun, and I need to learn it. Civil will be a good
exercise.

G


-- 

  "A computer is essentially a trained Squirrel"
      - Theodor Holm Nelson, Literary Machines 93.1 1/3

--

On Wed, 26 Jun 2002, Korruptor wrote:

> Depends how advanced we want to go. We can also include Pygame and Python
> for the real dumb-ass users...

Basically, we need to do this for windows. For .rpm and .deb we use 
dependencies ofcourse.

On 26/6/02 9:48 am, "Jan Ekholm" <ch...@in...> wrote:
>> I don't know how he did it, but I'm sure I can ask :)

Oh, addendum: It's trivial to do, and there's a choice of installers for it.
Depends how advanced we want to go. We can also include Pygame and Python
for the real dumb-ass users...

But we don't need to worry about it for a while...

G

-- 
  "You know, I have one simple request...and that is to have messages with
  freakin' laser beams attached to their headers. Now evidently my MIME
  specification informs me that can't be done. Uh, can you remind me what
  I pay you people for? Honestly, throw me a freakin' bone here."
    
    -- http://www.advogato.com/person/fejj/diary.html?start=77
--

>> I don't know how he did it, but I'm sure I can ask :)
> 
> Cool. I know it can be done, but I haven't done installation stuff for
> Windows for years. If Civil is easy to install and hassle-free we'll get
> more users, that's a fact.

I've already booked this as a G "thing to do" when we approach 1.0...

G

-- 
   "Just think of all of us as the french mental resistance..."
    -- Mr Nigel Rudgely Esq. (with 'ologies')
--

On Wed, 26 Jun 2002, Marcus Alanen wrote:

>On Thu, 9 May 2002, Michael Chermside wrote:
>
>> > WINDOWS INSTALLATION
>> > --------------------
>> > 
>> > If you run Windows we recommend that you use the prebuilt package available
>> > from the homepage. This installs nicely and requires no configuration. Just
>> > make sure you have installed the required software packages.
>> So I guess I'm going to have to read through the code and try to guess 
>> about dependencies in order to get things to work. But most Windows 
>> users probably aren't as presistant as I am, so I'd suggest that either 
>> a prebuilt Windows package be posted, or the INSTALL instructions be 
>> improved.
>
>The project at work uses python also, and the rather overworked 
>project leader managed to create a "one-click" windows installation 
>for windows computers [at least for those without python installed].
>
>I don't know how he did it, but I'm sure I can ask :)

Cool. I know it can be done, but I haven't done installation stuff for
Windows for years. If Civil is easy to install and hassle-free we'll get
more users, that's a fact.

-- 
           "Right, you bastards, you're... you're geography"
                                         -- Terry Pratchett, Guards! Guards!

On Thu, 9 May 2002, Michael Chermside wrote:

> > WINDOWS INSTALLATION
> > --------------------
> > 
> > If you run Windows we recommend that you use the prebuilt package available
> > from the homepage. This installs nicely and requires no configuration. Just
> > make sure you have installed the required software packages.
> So I guess I'm going to have to read through the code and try to guess 
> about dependencies in order to get things to work. But most Windows 
> users probably aren't as presistant as I am, so I'd suggest that either 
> a prebuilt Windows package be posted, or the INSTALL instructions be 
> improved.

The project at work uses python also, and the rather overworked 
project leader managed to create a "one-click" windows installation 
for windows computers [at least for those without python installed].

I don't know how he did it, but I'm sure I can ask :)

This just FYI, chakie & others

-- 
Marcus Alanen * Department of Computer Science * http://www.cs.abo.fi/
maa...@ab...

Hi Michael,


>I'm really excited by what I saw on the website about Civil, and thought 
>I would really like to try it out. After all, I like turn-based 
>strategic games, as well as programming in Python. So I went to the 
>website, looking for a download (I'm using Windows).
>
>The download info page says:
>
>> Due to the on-going development process there are no distributions 
> > available. However the CVS tree can be accessed anonymously.
>       [... instructions on CVS use ...]
>
>Well, I thought... it's EASIER when there's a pre-built binary, but 
>there's no excuse for my being lazy. I'll get it out of CVS and build it 
>myself.

There's actually no building involved at all. You check it out, and
optionally "install" it, but that's mostly for Unix-based systems. So,
after a CVS checkout you are ready to give it a whirl.

>Well, imagine my surprise. The INSTALL instructions read as follows:

Ignore that for now. INSTALL is written with Civil 1.0 in mind. See the
section DEVELOPMENT INSTALLATION instead. Until we've reached 1.0 and
actually *have* prebuilt binaries that section is lying.

>So I guess I'm going to have to read through the code and try to guess 
>about dependencies in order to get things to work. But most Windows 
>users probably aren't as presistant as I am, so I'd suggest that either 
>a prebuilt Windows package be posted, or the INSTALL instructions be 
>improved.

No need to read the code. You should be able to just check out Civil from
CVS and then do this from a DOS prompt (I don't develop using Windows
myself, so I'm not 100% sure):

	# cd path-to-civil/src
	# python2.X civil.py

for the main client. If you have no networked friend to test with, open
another client to play against, or use the dummy AI client. Open another
DOS window, change to the same src directory and:

	# python2.X civil-ai.py

after having made your main client a listening server (just press OK a few
times). That should do it, and if it doesn't, we'll figure it out and get
it running. Don't hesitate to get back with more questions, comments
(especially what a new player finds confusing, not working or just plain
stupid) and other feedback.

Good luck! 

-- 
  And it came to pass that in time the Great God Om spake unto Brutha,
    the Chosen One: "Psst!"
                                        -- Terry Pratchett, Small Gods

I've got to be missing something here.

I'm really excited by what I saw on the website about Civil, and thought 
I would really like to try it out. After all, I like turn-based 
strategic games, as well as programming in Python. So I went to the 
website, looking for a download (I'm using Windows).

The download info page says:

> Due to the on-going development process there are no distributions 
 > available. However the CVS tree can be accessed anonymously.
       [... instructions on CVS use ...]

Well, I thought... it's EASIER when there's a pre-built binary, but 
there's no excuse for my being lazy. I'll get it out of CVS and build it 
myself.

So I checked out the "NCIVIL-0_70" tag from CVS, grabbed the latest 
version of PyGame (I hadn't updated my copy of PyGame since moving from 
Python 2.1 to 2.2), and waited until I got a chance to try it out.

Well, imagine my surprise. The INSTALL instructions read as follows:

> 
> WINDOWS INSTALLATION
> --------------------
> 
> If you run Windows we recommend that you use the prebuilt package available
> from the homepage. This installs nicely and requires no configuration. Just
> make sure you have installed the required software packages.
> 

So I guess I'm going to have to read through the code and try to guess 
about dependencies in order to get things to work. But most Windows 
users probably aren't as presistant as I am, so I'd suggest that either 
a prebuilt Windows package be posted, or the INSTALL instructions be 
improved.

Anyway... hopefully I'll get it working soon -- I'm still excited!

-- Michael Chermside

More music news...

-- 
    Pets are always a great help in times of stress. And in times of 
    starvation too, o'course.
                                        -- Terry Pratchett, Small Gods


---------- Forwarded message ----------
Date: Mon, 24 Jun 2002 08:41:44 -0400
From: Dirk Griffin <ddg...@ne...>
To: ch...@in...
Subject: Re: Civil

Jan:

That's great! You should know that I'm actually involved in education 
and the studio is something we use for preparing courses at the 
university, but, since I wrote the specs on it, it can be used for other 
things. Is there a format that you'd prefer the music in, or would MP3 
be good enough? I probably won't get them back to you until late July as 
I have a recital mid-July and am involved in a video project pretty 
heavily between now and the end of July. If that time frame is suitable 
I can do both the marching tune and a more subtle piece of muisc for 
underscoring the actual battle turns.

Dirk

ch...@in... wrote:

>Hi Dirk,
>
>Sorry for the late answer, but Midsummer is one of those weekends over
>here when everyone does nothing useful at all, typically at a lake in the
>middle of a forest. :)
>
>>Are you guys looking for any music to add to this game? I'm a composer 
>>looking for an opportunity to put my name on a credit and I have a great 
>>feel for American Folk music and adapting it to concert music. It also 
>>happens that I am just starting on the third book in Bruce Catton's 
>>Civil War History and have been loving it -- which is sort of why I 
>>checked this out in the first place.
>>
>
>Yes, music is definitely something we would like to have. If you've tested
>Civil you notice that we have "something" playing in the background. It's
>just a MOD file that one of us found somewhere (from the Amiga days, I
>think), and does not represent what we'd eventually like to have. I put it
>in when I wanted to test how to do background music and sound effects.
>
>When discussing music we've been thinking of maybe two different kind of
>tunes. One more aggressive one for the setup dialogs. The players would
>usually not spend too long time setting up the game, so a short piece is
>good, maybe something that could loop. One of the ideas was some kind of
>marching music, a bit like in the ancient "North and South" Civil War game
>that was available for the Amiga 10 years ago, but that was just an idea.
>
>The in-game music needs to be more quiet, and will be played fairly low.
>It shouldn't disturb the player so the he/she turns it off. 
>
>These are just ideas, and we don't really have a too good grasp of what
>music suits the time frame of the Civil War. I assume you know a little
>bit better then us?
>
>>I have a small digital studio at my disposal and can pull musicians in 
>>to perform as well as build using midi instruments.
>>
>
>Seems like you are professionally involved in th emusic bussiness?
>
>>Please let me know if you are interested in any examples so I can put 
>>them together for you.
>>
>
>Oh, we definitely are interested. Gareth Noyce who provided the music we
>have right now has said that he could come up with something more
>suitable, but he's had problems getting access to the needed equipment, so
>he told me to "go ahead!". It sure would be fun to listen to some samples!
>
>We appreciate your offer to help out, especially as the audio side is
>currently our weakest point.
>
>Regards,
>    Jan Ekholm
>
>--
>             In the Beginning it was a nice day.
>                           -- Terry Pratchett & Neil Gaiman, Good Omens
>               
>

I committed in a little fix that allows the editor to skip icons that
should not be selectable as terrain icons. Their positions are simply left
blank, and clicking on those blank icons does nothing. Seems to work fine,
but ymmw. :)

-- 
   "I like the idea of democracy. You have to have someone everyone
       distrusts," said Brutha. "That way, everyone's happy."

                                        -- Terry Pratchett, Small Gods

On Mon, 24 Jun 2002, Marcus Alanen wrote:

>On Mon, 24 Jun 2002, Jan Ekholm wrote:
>
>> >Given no reason why they should be static, I'm not fond of the idea.
>> Ok. As it now works the way we have it, I don't see a reason to smash it
>> to pieces again, it's just an idea that would make it a bit faster.
>
>Hmm, if you really mean it's faster, go for it.

It would move creation of 600+ objects along with quite a lot of dict
searches to be done at startup and without textual parsing.

We can do it later if needed. Right now the format should, as you say,
remain simple and easy to read. Adding the "code stuff" makes it more
complicated.

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times

On Mon, 24 Jun 2002, Korruptor wrote:

>On 24/6/02 8:49 am, "Jan Ekholm" <ch...@in...> wrote:
>
>> 
>> Am I the only one that seems to miss icons 574 to 591? The new wooded
>> hills start at 592, and the last bridges end at 573. The gap causes some
>> interesting problems in the editor, and would force us to do some heavy
>> rewriting (I've relied on having a straight non-interrupted sequence).
>
>Trenches cover the missing "external" numbers atm.
>
>Feel free to rename if you don't agree. Personally, I still consider
>trenches to be a terrain type, even tho they reside in /objects...

Ah, forgot about them... Ok, will work around it somehow, I won't start
renaming stuff, that would be a major pain for everyone. 

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times

On Mon, 24 Jun 2002, Jan Ekholm wrote:

> >Given no reason why they should be static, I'm not fond of the idea.
> Ok. As it now works the way we have it, I don't see a reason to smash it
> to pieces again, it's just an idea that would make it a bit faster.

Hmm, if you really mean it's faster, go for it.

-- 
Marcus Alanen * Department of Computer Science * http://www.cs.abo.fi/
maa...@ab...

On Mon, 24 Jun 2002, Marcus Alanen wrote:

>On Mon, 24 Jun 2002, Jan Ekholm wrote:
>
>> Terrains. Yes. Would there be a really silly reason for not putting the
>> terrain data (now in terrains.txt) as a static list? A bit like it was
>
>Yes, it is not as compact as your old representation.
>
>> before, but this time for *all* icons and with *all* data? So we could
>> have something like:
>> 
>> terraindata = {
>> 
>> 1: ( (t['g'],t['g'],t['g'],t['g'],t['g'],t['g']), 
>>      (0,0,0,0,0,0),
>>      (5,5,5,5,5,5), 
>>      (50,205,50) )
>> 2: ...
>
>Comparison:
>
>  1 gggggg ------ 555555 50,205,50
>  2 gggggg ------ 555555 50,205,50
>
>...which is like a zillion times easier to understand, change and 
>debug. Why not have all data of the icons in terrains.txt instead?
>The parsing and placing into structures is not a speed issue, since
>we are loading hundreds of other icons anyway.

It did get considerably slower to load a scenario with the new format.
Instead I think Civil starts faster. Adding a splash is less work than
adding something that's shown during the loading of a scenario and tells
the player that "sure, we haven't crashed yet, hang on".

>Note that if an editor would support changing terrain icon information 
>in a nice GUI, it would have to output code. (Lot of if's and would's 
>there... ;-)

Sure. But moving the static array out into a separate file would make it
really easy to write. Not any harder to write than the textual format.

>Given no reason why they should be static, I'm not fond of the idea.

Ok. As it now works the way we have it, I don't see a reason to smash it
to pieces again, it's just an idea that would make it a bit faster.

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times

On 24/6/02 8:49 am, "Jan Ekholm" <ch...@in...> wrote:

> 
> Am I the only one that seems to miss icons 574 to 591? The new wooded
> hills start at 592, and the last bridges end at 573. The gap causes some
> interesting problems in the editor, and would force us to do some heavy
> rewriting (I've relied on having a straight non-interrupted sequence).

Trenches cover the missing "external" numbers atm.

Feel free to rename if you don't agree. Personally, I still consider
trenches to be a terrain type, even tho they reside in /objects...

G

-- 
    "If Bill Gates had a dime for every time Windows crashed...
     Oh, wait a minute. He already does..."

        -- Anon
-- 

        

On Mon, 24 Jun 2002, Jan Ekholm wrote:

> Terrains. Yes. Would there be a really silly reason for not putting the
> terrain data (now in terrains.txt) as a static list? A bit like it was

Yes, it is not as compact as your old representation.

> before, but this time for *all* icons and with *all* data? So we could
> have something like:
> 
> terraindata = {
> 
> 1: ( (t['g'],t['g'],t['g'],t['g'],t['g'],t['g']), 
>      (0,0,0,0,0,0),
>      (5,5,5,5,5,5), 
>      (50,205,50) )
> 2: ...

Comparison:

  1 gggggg ------ 555555 50,205,50
  2 gggggg ------ 555555 50,205,50

...which is like a zillion times easier to understand, change and 
debug. Why not have all data of the icons in terrains.txt instead?
The parsing and placing into structures is not a speed issue, since
we are loading hundreds of other icons anyway.

Note that if an editor would support changing terrain icon information 
in a nice GUI, it would have to output code. (Lot of if's and would's 
there... ;-)

Given no reason why they should be static, I'm not fond of the idea.

-- 
Marcus Alanen * Department of Computer Science * http://www.cs.abo.fi/
maa...@ab...

Am I the only one that seems to miss icons 574 to 591? The new wooded
hills start at 592, and the last bridges end at 573. The gap causes some
interesting problems in the editor, and would force us to do some heavy
rewriting (I've relied on having a straight non-interrupted sequence).

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times

Oooh, I just saw that we've got some new icons over the weekend! Excellent
stuff! They look truly bjuuttiful.

Off to play with the editor. Hope it still works...

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times