pybem-developers — List for pybem developers

Re: [Pybem-developers] Question about starting a new game

[Anthony B. <ab...@we...>]

Piotr wrote:
> Hello Anthony,
> 
> how do I set up a new faction? When I enter a "Faction: new" line into
> players.in and run the script, it gives me the following output:
> 
> ******
> piotr@vs150230:~/source/pyatltest$ ./atlantis1.py run
> playerDict is now: {'no': 'new'}
> Traceback (most recent call last):
>   File "./atlantis1.py", line 524, in ?
>     game.main()
>   File "./atlantis1.py", line 72, in main
>     self.loadgame()
>   File "./atlantis1.py", line 142, in loadgame
>     self.readplayers('players.in')
>   File "./atlantis1.py", line 346, in readplayers
>     f.new(playerDict['name'], playerDict['addr'], playerDict['password'])
> ******

Hmm, you've chopped off the actual error, but I suspect that you might 
not have the player address, name or password listed. You need to have 
them for regular Atlantis too, I think. If you put those in, it should 
work. If not, let me know :)

> pyAtlantis development seems to have halted a little. Any info on
> further progress?

Yep, it has stalled for a while. There wasn't a huge amount of interest, 
and I have a distinct lack of free time at the moment. That may change 
at some point this year, but not for the next couple of months at least. 
I am available for questions though :)

My plan btw, was to get the reports readable in ALH and run another game 
as a second test platform while I added more stuff (cities, monsters, 
etc.). You're welcome to follow that plan, or create your own.

Ant

[Pybem-developers] Question about starting a new game

[Piotr <sel...@go...>]

Hello Anthony,

how do I set up a new faction? When I enter a "Faction: new" line into
players.in and run the script, it gives me the following output:

******
piotr@vs150230:~/source/pyatltest$ ./atlantis1.py run
playerDict is now: {'no': 'new'}
Traceback (most recent call last):
  File "./atlantis1.py", line 524, in ?
    game.main()
  File "./atlantis1.py", line 72, in main
    self.loadgame()
  File "./atlantis1.py", line 142, in loadgame
    self.readplayers('players.in')
  File "./atlantis1.py", line 346, in readplayers
    f.new(playerDict['name'], playerDict['addr'], playerDict['password'])
******

pyAtlantis development seems to have halted a little. Any info on
further progress?

Cheers,


  Piotr

[Pybem-developers] PyBEM design document

[Anthony B. <ab...@we...>]

Hi All,

I've just committed the first draft of a design document for PyBEM. Most
of it is wishlist-y stuff or thinking alound, but it outlines the kind
of game that I'm planning on making (once some of the other programming
stuff is out of the way).

You can access it at:
https://pybem.svn.sourceforge.net/svnroot/pybem/pyatlantis/trunk/docs/pybem-design-doc.txt

Suggestions welcome :)

Anthony

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

[Pybem-developers] Thera 2.0 released

[Anthony B. <ab...@we...>]

Hi All,

I've just released the latest installment of Thera. It's a big jump from
the last version, and the first version in three years, so I've bumped
the revision number fairly significantly.

You can download it from sourceforge by following this link:
http://downloads.sourceforge.net/pybem/thera-2.0.zip

I've pasted in the release notes, where I've tried to explain what the big
deal is :) I'm particularly interested in hearing from people who:

  a. have tried to install it under Windows (note that Thera now reads
     from mbox files), or

  b. new users who have trouble with the documentation.

If you can't install it, let me know and I'll do my best to help you fix it.

Thanks,

Anthony

---
Thera v2.0 release notes:

This version is intended to be much easier to install, 
modify and configure. The core code is also much simpler 
and smaller, although some of the external libraries still
need some work ;)

This should be fairly stable, since I've been using it to
run Elderlands, my pyatlantis test game - but do let me 
know if you run into any problems.

New features:

  * It only runs one game, making configuration much 
    simpler. Want to run multiple games? Run multiple 
    copies :)

  * It now reads from an mbox, rather than stdin, so it
    should be much easier to run under windows (you should
    only need a mail reader that can save into mbox format)

  * Chopped out a lot of cruft, like blacklists/paidlists,
    zipping up turns and all of the 'manual' mail parsing
    that was being done (now it uses python libraries).

  * Reworked a lot of the core code, which should allow 
    easy modification if you want to add new commands 
    or replace them and add your own.

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

Re: [Pybem-developers] PyAtlantis Blatherings

[Anthony B. <ab...@we...>]

On Mon, Dec 03, 2007 at 12:28:01PM +1100, Anthony Briggs wrote:
> Jan Rietema wrote:
> > 
> > But an easy start isn't going to circumvent more painful refactoring
> > and redesigning later on.
> ...
>  > What gives me the creeps is that you decided to carry over all the ugly
>  > things from A1, and schedule them for refactoring later. I think a lot
>  > of better code design could have been done from the outset - more
>  > OO-goodness, more abstraction for skills/orders/items, better
>  > configurability, and a more modular design in general. These things are
>  > painful to introduce as an afterthought.
>
> For Orders, have a quick look at the latest work that I've been doing on the order system:
> 
>    http://pybem.svn.sourceforge.net/viewvc/pybem/pyatlantis/trunk/runorders.py?view=markup
> 
>  From 'class Order:' onwards is the new version,
>  'runInstantOrders(game):' onwards is the old version. Is that what
>  you had in mind?

Just a quick note to let you guys know that I've finished that
particular refactoring (although it's just for instant orders right now,
the design is basically done for the moment).  That URL above is still good,
although there are other bits in atlantis1.py and faction.py that it
calls.

The idea behind it is mainly breaking down the massive order processing
functions that A1 is saddled with, but the long term plan is that I'll
have a directory of modules which override particular types of
functionality, add new orders, etc.

Thanks,

Anthony

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

Re: [Pybem-developers] PyAtlantis Blatherings

[Anthony B. <ab...@we...>]

Jan Rietema wrote:
> Hi,
> 
> Earlier this week I was dabbling with the Atlantis code for another
> time - and then your posts came. Strange coincidences.
> 
> I tried to interface the Arcadia code with Ruby (sorry, Pythonistas!)
> using SWIG, but I'm not getting AString to work under SWIG
...
> I had a little bit more success with embedding Ruby into the C++
> source, but my knowledge of C++ is just too flaky
...
> Still, I think this idea would have a lot of potential, if someone more
> skilled was involved. ;)

That's an interesting idea, and one that I hadn't thought of, but my C++ skills are similarly flaky, so it's not 
something that I could support, either. Also, I suspect that you might need a lot of refactoring to be able to make it 
work properly, unless your Ruby code was exceptionally cunning ;)


>> I'd be interested to hear what people have to say about getting
>> involved, or what's impeding them as far as getting going.
> 
> Apart from a chronic lack of time and not having Atlantis on my radar
> at the moment (excepting the most recent foray), mostly the following
> personal, subjective and biased set of reasons:
> 
> Atlantis ONE?! I understand your intention of going back to the
> smallest codebase, but A1 is so raw and lacking in game elements,
> and is crudely coded, that it's just not a very good starting point.
> Geoff wrote A3 mostly from scratch (or so the legends say!), and when I
> look at the code (of A1) I can see a reason...

There's a very easy explanation for that, best viewed using SLOCcount:

atlantis4:
SLOC    Directory       SLOC-by-Language (Sorted)
47976   atlantis-4      cpp=47797,ansic=179
Total Physical Source Lines of Code (SLOC)                = 47,976
Development Effort Estimate, Person-Years (Person-Months) = 11.64 (139.73)
  (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))

atlantis1.c:
SLOC    Directory       SLOC-by-Language (Sorted)
5614    top_dir         ansic=5614
Total Physical Source Lines of Code (SLOC)                = 5,614
Development Effort Estimate, Person-Years (Person-Months) = 1.22 (14.69)
  (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))

Not that I think SLOCcount is particularly accurate (I think it overestimates time fairly significantly), but even given 
that, you're looking at *at least* an order of magnitude difference in the code bases. I've put in a fair bit of work 
into C++ Atlantis over the years, but I don't understand even a tenth of what it does. I doubt anyone would have the 
time or energy to rewrite *that* in Python.

Also, I don't think A3 was written entirely from scratch, based on what I can see in the codebase - there's too much 
similarity in how things are coded for that. It was probably a significant rewrite though.

> I appreciate your motivation of getting something basic running first,
> and then expanding on it. Because, when we are really honest with
> ourselves and not dreaming (as a lot of what has been written on
> atlantisdev in the past has), none of us can do the amount of full-time
> or part-time work on a hobby project to put a completely new vision into
> code.
> 
> But an easy start isn't going to circumvent more painful refactoring
> and redesigning later on.
...
 > What gives me the creeps is that you decided to carry over all the ugly
 > things from A1, and schedule them for refactoring later. I think a lot
 > of better code design could have been done from the outset - more
 > OO-goodness, more abstraction for skills/orders/items, better
 > configurability, and a more modular design in general. These things are
 > painful to introduce as an afterthought.
 >
 > I guess that this might be due a lesson learned from Boojum, and that
 > you try to use a different approach this time.

I could quote all sorts of Joel Spolsky, etc. to counter your point, but I'm sure you know all that already. I'm 
basically using the atlantis1.c code as a glorified scaffold to get my code up and running. It's much easier to refactor 
something that already exists than to write it all from the 'raw billet'.

And yes, I was burnt that way on the Boojum project. Note that that project is now defunct -- basically it's hard to 
write from scratch and know ahead of time all of the issues that you'll run into, but breaking out chunks of code from 
an existing codebase and 'fixing' them is easier.

I terms of ugliness - yes, PyAtlantis is still fairly ugly, particularly in the low levels, but it's improving 
dramatically. Certainly faster than the C++ Atlantis ever will. That in and of itself means that the project is worth 
doing. Two examples of what I've been doing: Silver and Orders:

The silver was easy - Atlantisv1 separates out silver and items, maintaining separate orders for 'paying' silver and 
'giving' items. The refactoring for that took ~1/2 hr, including editing the elderlands game file manually and putting 
in migration code.

For Orders, have a quick look at the latest work that I've been doing on the order system:

   http://pybem.svn.sourceforge.net/viewvc/pybem/pyatlantis/trunk/runorders.py?view=markup

 From 'class Order:' onwards is the new version, 'runInstantOrders(game):' onwards is the old version. Is that what you 
had in mind? It's basically what you're asking for, I think - good design .. or better design at least, but in this case 
I'm more aware of how the methods will be called and what they need to do than if I were writing from scratch. Hopefully 
that brief glimpse will give you an idea of where I'm headed. It might be a little while before that's completed, but 
I'm back from a 2 week holiday, so we'll see... so far I've spent about a couple of hours on it.


> The question of how to approach this has been nagging me over the past
> years. Incremental improvement or complete redesign? A few years ago, I
> tried to do some medium-level changes to the A5 code - economy and
> fleets. I'm neither happy with the results, nor has the process of
> working those into the existing code been a rewarding experience.
> 
> At the same time, I feel that incremental changes cannot address the
> basic design problems both of you described. I don't think it's a
> coincidence that so many players use the word "addiction" in
> conjunction with Atlantis: you want it to be wholesome, and it is for
> the first 30 turns, then it just gets ugly but it's too late to admit
> it.

I think that a lot of the 'core' of a PBEM is basically the same from game to game. You have a map, with units on it, 
regions, buildings, ships, magic, combat, you send orders into the server and get a syntax check back, etc.  From there, 
you have customisations - perhaps the magic is different, or the combat. But that core is what you need to get started. 
If you're writing from scratch, you're recreating that core to no real end (IMHO). Much better to do something 
relatively simple which handles that core and allow people to build on top of it.


>> have you tried getting up and running on the code base? Or have
>> you looked at it and been confused? Is my code style horrible?
> 
> I haven't tried to get it running, mostly for above reasons. I looked
> at the code yesterday, and I think you've done a good job
> writing clear code, documenting methods and naming variables etc.
> Documentation, even!!

Thanks, but it's a long way off yet. The 'documentation' as such is fairly minimal, but that plus a read through the 
code should get you going. Anyway, if there's anything that you think is unclear in the code or docs, sing out.

> Personally, while I'm self-taught coder rather than a trained one, there
> would need to be a minimum of design goodness for me to want to spend
> time with a project. I want to exercise good practice by coding, and
> not pick up bad habits. What little work I did on ALH has been so much
> more rewarding in this regard than work on the Atlantis source.

Yep, the Atlantis source is fairly hideous :)

As far as good design, I don't think that's something that you can pick up by reading a book or going to college. To a 
certain extent you have to work on a bad design, and try several things to fix it, in order to recognise a good design 
when you see it. Certainly I've found that working on bad codebases has been better for my overall coding prowess than 
adding to good ones :D

> To sum up what's missing: a good answer to the gameplay problem, and a
> good redesign of the codebase. You can arguably make a better game by
> just doing the code refactoring... but what would be the motivation -
> making a broken game more stable or configurable?
> Having an answer to the first question is going to provide the
> motivation AND some core concepts around which to shape the design.
 >
 > I think this is what has prevented any progress of Atlantis over the
 > past years, despite a pretty stable level of interest (seen by the
 > number of people who still lurk and respond ad hoc).

I'm not necessarily taking on the job of fixing Atlantis. I'm tackling a much lesser goal - a simpler, easier to modify 
Atlantis. That's it. Hopefully once I've done that, other people (including myself) will jump onboard and start trying 
new things (like my city-as-playable-thingie idea). As above, the only real way to see whether some things work is to 
try them out. That's fairly expensive to do in Atlantis, particularly for anything which deviates significantly from the 
current design (eg. Centaurs in Fracas V were a nightmare), but with Python and a reasonable design (hell, even a 
half-assed design), I'm guessing that you could do some crazy, crazy things ;)


> Over the time I haven't been involved in Atlantis, ideas have been
> accumulating here that could be shaping up into a game at some
> point (soon?). They don't fit into Atlantis, because they
> redefine the game elements from the ground up, but the feel and theme
> would be very close to Atlantis. I'm not sure if posting them here or on
> atlantisdev is going to be helpful to either projects, since they
> demand a departure from Atlantis both code-wise and in gameplay
> respects. At the same time I haven't spent much time putting these
> ideas into a concise whole (yet), which I feel is there somewhere.
> 
> So until these ideas stir up enough momentum that I write them down (to
> share or to code), I will continue to sit on the fence, willing to give
> moral support to Ant, because despite all my reservations his
> project is actually going somewhere! I am also eager to share ideas,
> discuss concepts of game and code design (preferrably on a concrete
> level and not whether to go xml or not)... for getting involved in
> actual coding I'd have to hammer out my motivation and compare it to the
> project at hand to decide if there's enough overlap of interests.

Hopefully I've done something to persuade you that I'm on the right track :) I'm definitely interested to hear your 
ideas - my other 'subplan' is to try to interest other games in porting to use PyAtlantis (I may have one taker already 
- AEpic <http://sourceforge.net/projects/aepic/>, run by a friend of mine from uni). It's hard to write a flexible 
core/backend if you're just writing for one game, but being 'forced' to consider other, potentially vastly different, 
game modes will definitely help in the long run.

Feel free to sign up to the pybem-developers list <https://lists.sourceforge.net/lists/listinfo/pybem-developers> and 
lurk :)

Thanks for your input,

Anthony

Re: [Pybem-developers] PyAtlantis Blatherings

[Jan R. <jan...@we...>]

Hi,

Earlier this week I was dabbling with the Atlantis code for another
time - and then your posts came. Strange coincidences.

I tried to interface the Arcadia code with Ruby (sorry, Pythonistas!)
using SWIG, but I'm not getting AString to work under SWIG. SWIG is a
tool to write interfaces that are shared between C/C++ and higher-level
languages. I gave it a brief shot to see if this was an avenue to
marriage parts of the existing game with a more flexible whole.

I had a little bit more success with embedding Ruby into the C++
source, but my knowledge of C++ is just too flaky for me to be able to
encapsulate game data into classes that are successfully shared across
both the C++ and Ruby processes.

Still, I think this idea would have a lot of potential, if someone more
skilled was involved. ;)

> I'd be interested to hear what people have to say about getting
> involved, or what's impeding them as far as getting going.

Apart from a chronic lack of time and not having Atlantis on my radar
at the moment (excepting the most recent foray), mostly the following
personal, subjective and biased set of reasons:

Atlantis ONE?! I understand your intention of going back to the
smallest codebase, but A1 is so raw and lacking in game elements,
and is crudely coded, that it's just not a very good starting point.
Geoff wrote A3 mostly from scratch (or so the legends say!), and when I
look at the code (of A1) I can see a reason...

I appreciate your motivation of getting something basic running first,
and then expanding on it. Because, when we are really honest with
ourselves and not dreaming (as a lot of what has been written on
atlantisdev in the past has), none of us can do the amount of full-time
or part-time work on a hobby project to put a completely new vision into
code.

But an easy start isn't going to circumvent more painful refactoring
and redesigning later on.

The question of how to approach this has been nagging me over the past
years. Incremental improvement or complete redesign? A few years ago, I
tried to do some medium-level changes to the A5 code - economy and
fleets. I'm neither happy with the results, nor has the process of
working those into the existing code been a rewarding experience.

At the same time, I feel that incremental changes cannot address the
basic design problems both of you described. I don't think it's a
coincidence that so many players use the word "addiction" in
conjunction with Atlantis: you want it to be wholesome, and it is for
the first 30 turns, then it just gets ugly but it's too late to admit
it.

> have you tried getting up and running on the code base? Or have
> you looked at it and been confused? Is my code style horrible?

I haven't tried to get it running, mostly for above reasons. I looked
at the code yesterday, and I think you've done a good job
writing clear code, documenting methods and naming variables etc.
Documentation, even!!

What gives me the creeps is that you decided to carry over all the ugly
things from A1, and schedule them for refactoring later. I think a lot
of better code design could have been done from the outset - more
OO-goodness, more abstraction for skills/orders/items, better
configurability, and a more modular design in general. These things are
painful to introduce as an afterthought.

I guess that this might be due a lesson learned from Boojum, and that
you try to use a different approach this time.

Personally, while I'm self-taught coder rather than a trained one, there
would need to be a minimum of design goodness for me to want to spend
time with a project. I want to exercise good practice by coding, and
not pick up bad habits. What little work I did on ALH has been so much
more rewarding in this regard than work on the Atlantis source.


To sum up what's missing: a good answer to the gameplay problem, and a
good redesign of the codebase. You can arguably make a better game by
just doing the code refactoring... but what would be the motivation -
making a broken game more stable or configurable?
Having an answer to the first question is going to provide the
motivation AND some core concepts around which to shape the design.

I think this is what has prevented any progress of Atlantis over the
past years, despite a pretty stable level of interest (seen by the
number of people who still lurk and respond ad hoc).

Over the time I haven't been involved in Atlantis, ideas have been
accumulating here that could be shaping up into a game at some
point (soon?). They don't fit into Atlantis, because they
redefine the game elements from the ground up, but the feel and theme
would be very close to Atlantis. I'm not sure if posting them here or on
atlantisdev is going to be helpful to either projects, since they
demand a departure from Atlantis both code-wise and in gameplay
respects. At the same time I haven't spent much time putting these
ideas into a concise whole (yet), which I feel is there somewhere.

So until these ideas stir up enough momentum that I write them down (to
share or to code), I will continue to sit on the fence, willing to give
moral support to Ant, because despite all my reservations his
project is actually going somewhere! I am also eager to share ideas,
discuss concepts of game and code design (preferrably on a concrete
level and not whether to go xml or not)... for getting involved in
actual coding I'd have to hammer out my motivation and compare it to the
project at hand to decide if there's enough overlap of interests.

Have a good weekend,

  Jan

Re: [Pybem-developers] PyAtlantis Blatherings

[Anthony B. <ab...@we...>]

On Thu, Nov 29, 2007 at 11:55:45PM +0100, Piotr wrote:
> >Hi Piotr,
> 
> >Good to see that someone's paying attention :)
> 
> Well.. somehow one can not get rid of that addiction ;) And I think
> that I am not the only person looking on Your code with one eye.
...
> I am checking the code from time to time, looking through it/playing around.

Yep, a few people have downloaded it and had a look, and a few of those
have said that they're interested, but so far no contributions. I know
it's early days, but still.

> True. No patches. And this is actually the crux.. I do not have the
> time to get involved in coding, for I am coming into the third third
> of my PhD, and I am going to have an internship in the industry to
> attend. Difficult update my python knowledge and commit myself to
> PyAtlantis these days.

Hmm, I suppose, but even small contributions can make a difference. A
couple of unit tests here, a small patch there, it all starts to add up
over time. Plus it's fun -- I work on PyAtlantis because I enjoy it; for
me it's much like watching TV or going to the movies or riding my bike.
No 'work' involved :) Of course, YMMV.

> On the other hand, once the code is pythonized completely, I may start
> to mingle around in it.

Currently the code is fairly well 'pythonised', in that it's entirely in
python, and most of the high level stuff is reasonably well broken down.
It's not perfect, but getting there I think.

I'd be interested to hear what people have to say about getting
involved, or what's impeding them as far as getting going.
eg. have you tried getting up and running on the code base? Or have you
looked at it and been confused? Is my code style horrible? I've started
putting in tests - maybe that'll help clarify some things?

There's a README-DEV which contains most of the documentation (such as
it is). Is that enough? Do you need more? If so, what sorts of questions
do you need answered? Are there enough comments in the code? I've tried
to make it as clear as possible, but what's clear to me may not be clear
to others.

Finally, I don't know whether I've been clear in describing the sorts of
changes that I'd like to make in terms of extensibility - perhaps that's
what's putting people off (Yawn, Atlantis in Python - why bother if we
have the C++ version?).  This reply is pretty long, but I've hopefully
covered most of the bases as far as why I'm doing this, and why I think
it's the only real hope as far as future Atlantis development goes.

> Again, I think Your initiative to restructure the Atlantis code in a
> language like Python starting from a low version number is a great
> opportunity to make it a much more interesting, and playable game.

It's a good way (I think) to sidestep some of the design issues that
Atlantis has had (ie. micromanagement) while still keeping the original
feel of the game.

> Well... I have sent a cc to two Arcadia veterans, notably the Arcadia
> developer and coder, Bradley, and one of the most feared strategist,
> Patrick. Both played Atlantis extensively and some other play by email
> games as well, and may be the will give some feedback on this one.
> Also, Jan and Max are on board here.

Based on what I've seen of their work on Atlantis, Arcadia and ALH,
they'd be more than welcome to jump in and help out. Just let me know
what your sf.net ids are and I'll add you to the project. (You can send
me patches too, but that tends to be annoying).

>> ps. Just for the record, I think v4 is fairly reasonable, for some
>> definition of 'reasonable'.

> The point is, 'reasonable' is not enough.

Well, yes - if you don't like the design of Atlantis. It's quite
possible to bend the rules in interesting ways, but there are some core
issues which are much harder to remove without rewriting large chunks of
the game.

> 1) Roleplaying:
> There is not enough roleplaying for a roleplayer.

I'd say it goes much deeper than that. The issue is that there's
basically one way to win: conquest. All of the players will therefore be
warlords, or minions of warlords, and roleplay accordingly. Perhaps an
example will clarify things:

  I didn't really agree with the changes that Arno made to st.atlantis,
  but after playing in it for a while, I can see some good things -
  trade is much more worthwhile, perhaps even better than taxation in
  some cases, so there's much more incentive for neighboring factions
  to try and hammer out trade routes. I can envisage factions coming to
  blows over access to cities, and the associated trade, or ambushing
  trade caravans. From a game design point of view, this is good, since
  there's now more than one way to make money/hurt other players: target
  their trade routes.

If there's more than one way to succeed, and war isn't everything, then
you'll attract more types of player, rather than just the min-maxing
weenies.


> 2) Micromanagment:
> We had this before. Too many useless, or unimportant options to mingle
> with.

Yep. My main plan for this is to make cities a player-controllable
object, which once controlled can produce resources, buildings, roads
(and bridges?), and generate armies directly. A'la Civ, basically. Once
you have some basic buildings, you can build more advanced ones, and so
on.

Probably other stuff too, like decent trade -- if you have more
resources (iron, copper, zinc, lead, etc) you can require them for
various buildings, or spells. This gives players much more incentive to
actually trade, and cities can help set up trade routes or set market
prices, etc. 


> 3) Strategy, Game Goal, Faction Development
> Currently, there are few good ways to win a game of Atlantis. Usually,
> it is something about expanding exponentially, getting the first ally,
> ganging up on Your neighbour, get mages/heroes high level items, crush
> more enemies.. until micromanagment kills You. Your faction becomes
> more and more static until turn 30, when You decide that You can not
> deal with it any more.

I think that there is one basic problem, which is that factions get much
harder to control to their full potential as they get larger. This means
that in any sort of 'conquering' game you grind to a halt as soon as you
get successful. I've had two main thoughts as far as how you 'fix'
this:

1. Make factions easier to control (see cities above). Once you start
winning, you'll tend to keep winning. I don't see a big problem in
rewarding players (with in game power) for doing well in the game. If
someone gets big and nobody can stop them, then they should win.

Another thing to mention is that compared to the map size in Atlantis,
units *crawl*. By the time your empire gets succesful, it can take a
*game year* for reinforcements to arrive. Compare that to the early
european explorers, who could circumnavigate the globe in a sailing ship
in a year or two.  What would the game look like if a winged unit could
move 12 hexes per turn instead of 6? or 20? Or riding units could do
8-16? More diplomacy?  Very possibly, since relatively far away factions
could come to your aid. I have some ideas to rein that in, but you get
the idea.

2. Once a faction gets to a certain size, it becomes possible for them
to have a revolution in parts of their empire. This could be a
legitimate in-game reason for adding new players in an open-ended game,
or they could cede to a neighboring faction, or become neutral (NPC?)

Neither of these options are particularly feasible in the C++ Atlantis
AFAIK.

> Ergo: There are lots of games like Atlantis on the open source market,
> and most of them have the flaws mentioned above. What would be really
> a challenge to a game developer is a crackdown, simplifacation and
> refinement of the essential rules that play a role in this game and
> it's implementation in the code. A fresh code like PyAtlantis.
> 
> My opinion is: The simpler, the better. Most brilliant and addicting
> games I have played had a quite simple ruleset, i.e. chess, Starweb,
> space empires (by Richard Wolfe, now run as hegemony by Skotos),
> diplomacy, Poker, Brigde, etc. And note: These games were not open
> ended, they all were balanced according to a certain game goal.

My (different) take is this - I have no idea what'll make Atlantis a
better game :) Most of the things that I've suggested could be awful, or
could be big crazy rabbit holes of work. The only way to find out is to
try them, and I'm not keen on trying them out with the current C++
Atlantis code.

In Python however, it's a different story. Much more flexible and
powerful (although that doees create interesting problems in and of
itself), and therefore much easier to test out different ideas and see
what works. Python's an ideal prototyping language.

> By the way, here is a small present for You :)
> 
> ------------------------------------------------------
> BUG REPORT:
> 
> piotr@vs150230:~/pytest$ ./atlantis1.py new
> Traceback (most recent call last):
>   File "./atlantis1.py", line 442, in ?
>     game.main()
>   File "./atlantis1.py", line 57, in main
>     self.newgame()
>   File "./atlantis1.py", line 137, in newgame
>     self.map.makeblock(0,0)
>   File "/home/piotr/pytest/map.py", line 215, in makeblock
>     region = Region(self)
> NameError: global name 'Region' is not defined

Yep, there are bugs in the code base :) That's hardly suprising, since
I'm basically only running one game. The test game is sporadic, btw,
since I have to babysit it when it runs. Once it's stable enough it'll
get run automatically.

That bug, and another more serious one to do with caching, have been
fixed in svn. I've also added the preliminary work that I've done
towards making orders more modular (an Order class). I've started
putting in unit tests to stop these issues recurring, but it's early
days yet.

Hope that helps encourage a few of you to help out :)

Anthony


-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

[Pybem-developers] PyAtlantis 1.3

[Anthony B. <ab...@we...>]

Hi Guys,

Just a quick note - I released PyAtlantis 1.3 a couple of days ago, but
forgot to tell you about it ;) Here's a link, just in case you wanted to
download it and check it out:

http://downloads.sourceforge.net/pybem/pyatlantis-1.3.zip

Thanks,

Anthony

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

Re: [Pybem-developers] Ships

[Anthony B. <ab...@we...>]

On Fri, Sep 14, 2007 at 04:46:22PM +0200, Piotr wrote:
> could be changed the way that they are movable buildings.
> 
> object = ship + building
> 
> Or is this too difficult?

Nothing's too difficult at this stage - strike, while the codebase is
small ;)

A better way to do it might be to define a 'mix in' class which could
contain other objects (eg Container). Ships and Buildings would then both be
subclasses of Container. I'm pretty sure Atlantis v4 goes along these
lines, so you might want to have a look at the code from there.

In other words:
Ship = Container + ship stuff
Building = Container + building stuff

Other ideas for this spring to mind - Armies/Schools would be a subclass too
when they get added. Cities within regions, or even regions themselves
are also possibilities, so you'd want the possibility of adding various
different objects in, not just units.

Anthony

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

[Pybem-developers] Ships

[Piotr <sel...@go...>]

could be changed the way that they are movable buildings.

object = ship + building

Or is this too difficult?

  Piotr

Re: [Pybem-developers] PyAtlantis-stable and PyAtlantis-trunk

[Anthony B. <ab...@we...>]

On Sun, Sep 09, 2007 at 05:10:33PM +0200, Piotr wrote:
> Hello Anthony,
> Hello List,
> 
> I had looked into Your code and want to make some small comments.

Excellent. More eyes and more input in terms of design and code
decisions will make PyAtlantis a better program.

> First of all, You have done a lot of work and invested a lot of energy
> to translate the code from C to Python. That was good work, and
> certainly some sort of hassle.

It's still not entirely done - there's no C code, but the design still
leaves a bit to be desired.

> I think the best way to approach these things is to follow Your
> roadmap, although there is still the question if we should follow the
> way the old Pyatlantis was done. There, we already have a 1:1
> translation of Atlantis 4.0. Maybe it is not working yet, but still it
> is a solid codebase full of objects, XML, etc.

Hmm, that's not my understanding - they've got a lot of framework stuff
in place, eg. for translation into other languages, but very little
actual code. That, plus it's been dead for quite a while - I picked up
on the source a few years back.

Creating objects, etc. is part of the plan now, so that should come
along reasonably quickly. You can do XML if you like (personally I'm not
really a fan) - it should be fairly easy to swap the existing readgame
and writegame routines for ones which use XML instead of text. Player
reports might be a bit harder if you want to go down that route, but
still possible. (Of course, really it should be done on a per object
basis, ie. regions return their text representation, etc.)

> But essentially, the rules were kept the same - the one and only but
> essential mistage these guys did. So much needed "big objectification"
> starts, we have to keep in mind that "Atlantis" as a game-set is not
> necessarily the best outcome of it.

Not sure what you mean here, but I think that one thing which can kill
projects like this is to have a massive idea/codebase, with XML, objects
for everything and start coding bits of it, but never actually have a
playable game. In this case, we're adding/improving different bits at a
time, so there's not that huge effort required to get anything going.

> Keep room for modification, kill the one or other thing if it does not
> seem to be very important. And most importantly: Simplify the rules in
> order to make room for more complexity, which could be an interesting
> economic system, a title/liege system, etc.

That's basically what I'm doing at the moment - simplify the codebase,
break it down into smaller functions and reduce dependencies. That will
hopefully reduce the barriers to entry for other GMs/developers. For
example, I've just broken down processorders into bits - so if somebody
wanted to take on movement, and make it more flexible (currently it's
just one region per turn) then they can do that without stepping on
anyone else's toes.

Ant

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 ab...@we...
------------------------------------------------------

[Pybem-developers] Effects

[Piotr <sel...@go...>]

Hi all,

I want to share an interesting, fresh codebase from a german Atlantis
derivative: MENOUTHIS. It is still in development, but it shows some
very promising engine features, i.e. XML for gamedata storage, XML
reports, and most interestingly, an effect system which allows the GM
to alter the propterties of certain game objects without manipulating
the host code.

Have a look at https://sv...@so.../svn/menouthis/unstable


  Piotr

[Pybem-developers] (no subject)

[Piotr <sel...@go...>]

Hello Anthony,
Hello List,

I had looked into Your code and want to make some small comments.

First of all, You have done a lot of work and invested a lot of energy
to translate the code from C to Python. That was good work, and
certainly some sort of hassle.

I think the best way to approach these things is to follow Your
roadmap, although there is still the question if we should follow the
way the old Pyatlantis was done. There, we already have a 1:1
translation of Atlantis 4.0. Maybe it is not working yet, but still it
is a solid codebase full of objects, XML, etc.

But essentially, the rules were kept the same - the one and only but
essential mistage these guys did. So much needed "big objectification"
starts, we have to keep in mind that "Atlantis" as a game-set is not
necessarily the best outcome of it.

Keep room for modification, kill the one or other thing if it does not
seem to be very important. And most importantly: Simplify the rules in
order to make room for more complexity, which could be an interesting
economic system, a title/liege system, etc.

Piotr

Re: [Pybem-developers] PyAtlantis-stable and PyAtlantis-trunk

[Piotr <sel...@go...>]

Hello Anthony,
Hello List,

I had looked into Your code and want to make some small comments.

First of all, You have done a lot of work and invested a lot of energy
to translate the code from C to Python. That was good work, and
certainly some sort of hassle.

I think the best way to approach these things is to follow Your
roadmap, although there is still the question if we should follow the
way the old Pyatlantis was done. There, we already have a 1:1
translation of Atlantis 4.0. Maybe it is not working yet, but still it
is a solid codebase full of objects, XML, etc.

But essentially, the rules were kept the same - the one and only but
essential mistage these guys did. So much needed "big objectification"
starts, we have to keep in mind that "Atlantis" as a game-set is not
necessarily the best outcome of it.

Keep room for modification, kill the one or other thing if it does not
seem to be very important. And most importantly: Simplify the rules in
order to make room for more complexity, which could be an interesting
economic system, a title/liege system, etc.

  Piotr

[Pybem-developers] Re: wiki (fwd)

[Anthony B. <ab...@ii...>]

I've put some of the design docs up on the wiki - you can get to them 
from the front page. They're a little out of date compared to the 
code - I'll work on that at some point... ;)

Ant
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

[Pybem-developers] Re: wiki (fwd)

[Adrian S. <fo...@ii...>]

---------- Forwarded message ----------
Date: Thu, 27 Jun 2002 16:49:56 +0800
From: Anthony Briggs <ab...@ii...>
To: Adrian Smith <fo...@ii...>
Subject: Re: wiki

Alrighty, I've got the wiki going, kind of. Basically, instead of
waiting for the SOurceforge people to get their act together (I guess
it is a free site), I've made some of the pages world-writable and
edited them. The CGI script then writes them back as files owned by
the www process, and I can make them non-writable again :\

I've put up one page (the homepage), and I may put up some more (like
the SandBox, and the EditingTips page)

Have a play, see what you think of it.

Ant
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

Re: [Pybem-developers] Re: base36!

[Adrian S. <fo...@ii...>]

On Tue, 25 Jun 2002, Anthony Briggs wrote:

> At 10:23 PM +0800 25/6/02, Adrian Smith wrote:
> >OK, deal, you do the items/skills and I'll do a parser.
> >We should be able to read in the items/skills from an XML file.
>
> I would prefer something a little more human-readable/writable, but
> it's up to you - maybe we could have some sort of switch to read in
> XML/text.
>
There are lots of tools available to read/write/edit/analyse XML,
so it just makes sense. No reason we can't have converters, to/from
plain text or whatever, or a custom GUI to create the XML config file.

> I just think that the syntax (at least for specifying items) would be
> better as something like:
>
> skill knight
> synonyms knig
> effect +lvl combat
>         +lvl upkeep
> requires skills sword riding shield heraldry
>           items sword horse plate_armour shield
>
> I think it's less readable as something like:
>
> <skillspec>
>      <synonyms>knig</synonyms>
>      <effect><bonus addto="combat">+lvl</bonus>
>              <require type="skill">combat</require>
>              <require type="skill">sword</require>
>              <require type="skill">riding</require>
>              <require type="skill">shield</require>
>              <require type="skill">heraldry</require>
>              <require type="item">sword</require>
>              <require type="item">horse</require>
>              <require type="item">plate armour</require>
>              <require type="item">shield</require>
>      </effect>
> </skillspec>
>
> I've expounded on this at length, so I'll shut up now, but just so
> you know what I think ;)  Feel free to poke your nose into items if
> you like...
>
> Ant
> --
> ----------------------------------------------------
> HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
> aB...@Ii...
> ----------------------------------------------------
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Pybem-developers mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pybem-developers
>

Re: [Pybem-developers] Re: base36!

[Anthony B. <ab...@ii...>]

At 10:23 PM +0800 25/6/02, Adrian Smith wrote:
>OK, deal, you do the items/skills and I'll do a parser.
>We should be able to read in the items/skills from an XML file.

I would prefer something a little more human-readable/writable, but 
it's up to you - maybe we could have some sort of switch to read in 
XML/text.

I just think that the syntax (at least for specifying items) would be 
better as something like:

skill knight
synonyms knig
effect +lvl combat
        +lvl upkeep
requires skills sword riding shield heraldry
          items sword horse plate_armour shield

I think it's less readable as something like:

<skillspec>
     <synonyms>knig</synonyms>
     <effect><bonus addto="combat">+lvl</bonus>
             <require type="skill">combat</require>
             <require type="skill">sword</require>
             <require type="skill">riding</require>
             <require type="skill">shield</require>
             <require type="skill">heraldry</require>
             <require type="item">sword</require>
             <require type="item">horse</require>
             <require type="item">plate armour</require>
             <require type="item">shield</require>
     </effect>
</skillspec>

I've expounded on this at length, so I'll shut up now, but just so 
you know what I think ;)  Feel free to poke your nose into items if 
you like...

Ant
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

Re: [Pybem-developers] Re: base36!

[Adrian S. <fo...@ii...>]

On Tue, 25 Jun 2002, Anthony Briggs wrote:

> At 8:52 PM +0800 25/6/02, Adrian Smith wrote:
> >On Tue, 25 Jun 2002, Anthony Briggs wrote:
> >  > At some point, Adrian said:
> >  > >The PLY package you emailed me the pointer to looks excellent.
> >  > >Much better in Python using introspection than in C
> >>  >(where you had to create a file, run it to create source code,
> >>  >then compile the source code, .. egghh!)
> >>
> >>  The things that drew me to it were:
> >>
> >>  a) it's been extensively debugged (by a CompSci class, no less)
> >>  b) it has reasonable documentation, and a fair few examples
> >>  c) it has a lot of testing modules, which should serve as additional
> >>  documentation.
> >>
> >>  Hopefully we should be able to get something off the ground fairly
> >  > quickly, as far as items and skills.
> >  >
> >Yes, it is very clean and clear.
> >Not just a wrapper of lex/yacc but done better!
> >
> >I'm almost inspired to get onto it..
>
> Almost? ;) I'm planning on doing some work on items/skills. But I've
> got some washing up to do first.  I'll work on that if you do some
> parser writing ;)
>
> And a thought: we could make some kind of skill/production based game
> (instead of Boojum) as a test. Something like - whoever builds a
> certain sort of building (a cathedral?) in a city wins that city, and
> a certain number of cities wins the game? The catch being that you
> need skills/raw materials to build, and there's a build heirarchy, so
> you can't just whack up a cathedral... Maybe this'd be interesting
> without combat (ie just raw production).
>
> Ant
> ps. Just realised this should be on the developer's list.
>
> pps. Did I tell you I had some emails from a guy trying to set up
> Thera? It worked, so I guess it passes one test. Though I haven't got
> any feedback from him yet as far as what he found hard, and what he
> didn't.
> --
> ----------------------------------------------------
> HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
> aB...@Ii...
> ----------------------------------------------------

OK, deal, you do the items/skills and I'll do a parser.
We should be able to read in the items/skills from an XML file.

Adrian

[Pybem-developers] Re: base36!

[Anthony B. <ab...@ii...>]

At 8:52 PM +0800 25/6/02, Adrian Smith wrote:
>On Tue, 25 Jun 2002, Anthony Briggs wrote:
>  > At some point, Adrian said:
>  > >The PLY package you emailed me the pointer to looks excellent.
>  > >Much better in Python using introspection than in C
>>  >(where you had to create a file, run it to create source code,
>>  >then compile the source code, .. egghh!)
>>
>>  The things that drew me to it were:
>>
>>  a) it's been extensively debugged (by a CompSci class, no less)
>>  b) it has reasonable documentation, and a fair few examples
>>  c) it has a lot of testing modules, which should serve as additional
>>  documentation.
>>
>>  Hopefully we should be able to get something off the ground fairly
>  > quickly, as far as items and skills.
>  >
>Yes, it is very clean and clear.
>Not just a wrapper of lex/yacc but done better!
>
>I'm almost inspired to get onto it..

Almost? ;) I'm planning on doing some work on items/skills. But I've 
got some washing up to do first.  I'll work on that if you do some 
parser writing ;)

And a thought: we could make some kind of skill/production based game 
(instead of Boojum) as a test. Something like - whoever builds a 
certain sort of building (a cathedral?) in a city wins that city, and 
a certain number of cities wins the game? The catch being that you 
need skills/raw materials to build, and there's a build heirarchy, so 
you can't just whack up a cathedral... Maybe this'd be interesting 
without combat (ie just raw production).

Ant
ps. Just realised this should be on the developer's list.

pps. Did I tell you I had some emails from a guy trying to set up 
Thera? It worked, so I guess it passes one test. Though I haven't got 
any feedback from him yet as far as what he found hard, and what he 
didn't.
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

Re: [Pybem-developers] boojum

[Anthony B. <ab...@ii...>]

Based purely on the README and a couple of examples, I think this one 
is probably the one we want to go for:

<http://systems.cs.uchicago.edu/ply/>

Looks like it's easy to use, and farily well debugged.

Ant

-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

Re: [Pybem-developers] boojum

[Anthony B. <ab...@ii...>]

At 10:11 AM +0800 18/6/02, Anthony Briggs wrote:
>skill sword synonyms swor effect +lvl combat requires item sword
>item sword effect +2 combat requires skill sword
>
>skill knight
>synonyms knig
>effect +lvl combat
>        +lvl upkeep
>requires skills sword riding shield  heraldry
>          items sword horse plate_armour shield
>
>...looks a bit more readable ;)

I've been thinking a bit more about the overall design of items. It 
seems to me that at the 'base level', items should have three things:

1. a type, eg. skill, item, attribute, and perhaps some other 
player-definable types

2. a list/dictionary of effects that the item will have, such as +2 
combat, increasing movement, adding extra skills(?), etc.

3. a list/dictionary of requirements for each effect, including 
anti-requirements.

I think the effects are going to be reasonably straightforward to do 
- you'd have the usual plus/minus/divide/multiply by an amount, as 
well as replacing it with a certain amount. You'd probably also want 
some sort of order that these were applied in, eg. start with a 
unit's best weapon type when adding up combat bonuses.

To save processor time, you'd probably also want to go through a unit 
prior to running the turn, and figure out which items were active (or 
not), so that you didn't have to redo it every time that unit's 
attributes were accessed. Except when your items changed, of course - 
perhaps we could have a 'dirty' flag for a unit's items, and then 
recalculate the attributes if necessary.

The hard bit is probably going to be writing the requirements in a 
flexible way. eg. You might want to have something that only works in 
a certain terrain type, or has particular 'extra' bonuses in a 
terrain type, only works when used on a certain type of monster, etc. 
The ones that requre a certain skill, item or the lack thereof are 
going to be easy, but the hex/target ones will probably have to be 
hard coded if we can't come up with am easy way to access generic 
objects' attributes.

To make life easier, perhaps we could do items that rely on skills 
first, and then add in the terrain and target reqs later.

Anyway, just some food for thought.

Ant
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

Re: [Pybem-developers] Another game to check out

[Anthony B. <ab...@ii...>]

At 11:59 PM +0800 17/6/02, Adrian Smith wrote:
>I played in "War of Wizards"  wow.pbemgame.com
>which had a few good ideas.
>
>Something I'm fairly keen to work on in pybem
>is a great GM tool for customising and setting up
>a game. Maybe with plugins, or load/save of game data
>(world creation, items, skills, background).

Yup. I think though, that pulling all of the game-specific code out 
into separate, minimalist files, and providing the config file 
ability, along with several well documented config files for 
particular games, will go a long way towards this.

Ant
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

Re: [Pybem-developers] boojum

[Anthony B. <ab...@ii...>]

At 6:24 PM +0800 17/6/02, Adrian Smith wrote:
>I think supporting Legends as a second game would be a good test,
>because it has a lot of feature richness but is limited by how it
>is hardcoded. A more flexible Legends would be amazing.
>One thing that it does do fairly well is separate the engine from
>the game (module).
>
>Another game you might want to have a look at is Eldritch,
>which Mark Thomas wrote after playing Atlantis, as basically a
>better Atlantis. I think he has succeeded in many ways, though it
>is more complex and basically a headache keeping track of all your
>stuff (to train a knight you need to have heroes with a variety of
>skills - sword, riding, manoever, armor, shield; plus magic to
>enchant up your knights; then to make the gear you need to gather
>iron, coal, make steel, hides -> leather, hors -> warhorse,
>oak -> make lance, make armour, make sword, make shield, make ...).

Yeah, all this will be (relatively) trivial to do if we can get 
items/skills working the way I'd like. To do that, we need two 
things: coding for the items,  and a general-purpose parser (for the 
config files). Once we've got those, it's probably going to be a case 
of adding lines to the config file:

skill sword synonyms swor effect +lvl combat requires item sword
item sword effect +2 combat requires skill sword

or

skill knight synonyms knig effect +lvl combat effect +lvl upkeep 
requires skill sword requires skill riding requires skill shield 
requires skill heraldry requires item sword requires item horse 
requires item plate_armour requires item shield

If you were after a general case, you could have something like:

skill combat effect +lvl combat requires item weapon
item sword synonyms swor type weapon effect +2 combat requires skill combat
item axe synonyms ax type weapon, tool effect +1 combat, +1 lumb, +1 weap
etc.

For readability, we could probably just read lines until we get to 
the next item/skill, and do the same for synonyms, effects and 
requirements. So, you could rephrase the knight skill as:

skill knight
synonyms knig
effect +lvl combat
        +lvl upkeep
requires skills sword riding shield  heraldry
          items sword horse plate_armour shield

That looks a bit more readable ;)

>I like what you say about RAD Python, it's great that you can throw
>something together to flesh out the design, then keep refactoring it
>continuously.

Yeah, though I really need to do more unit tests, as I found out 
after the last couple of commits ;)

Ant
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------