pybem-developers — List for pybem developers

[Pybem-developers] Another game to check out

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

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

Adrian

Re: [Pybem-developers] boojum

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

On Mon, 17 Jun 2002, Anthony Briggs wrote:

> >>  * big thought - we should try to support TWO of everything,
> >>  from the outset.  ie.  two different game worlds, with different
> >>  attributes, orders, coordinate system, output display(?)
> >>  Basically, for everything that we plan to make customisable,
> >>  we should start off supporting two versions of that option,
> >>  to force us to generalise.
> >
> >Absolutely. Every time I've heard from a person who's said "Oh, I
> >can't code" or "I don't know Python", I've said "Well, come up with
> >a design for a game that you'd like to play". Even if it's just
> >something for us to think about, it's valuable to look at the
> >problem from a "non-Atlantis" point of view. Hence that whole post a
> >little while back on the sorts of games we might want to think about
> >doing. eg. MOO, MOO2, Civ, even chess ;)
> >
> >That said though, I think it'll be easier to do/convince people to
> >do once we've got some basic classes up, like items and skills, plus
> >a parser to read in all the config files. At the moment, it's pretty
> >sparse, and you need to be a python hacker to tinker with it. Plus I
> >think Boojum's starting to stretch it's initial design somewhat.
> >This is where the RAD aspect of python comes into play - it's pretty
> >easy to modify stuff on the fly, so if someone comes up with
> >something we hadn't thought of, we can just alter items, or skills,
> >or units to fit. I suspect armies are eventually going to be a
> >sub-class of Unit.
>
> Another thing -- in the TODO file in the most recent version of
> Atlantis are a whole bunch of different suggestions for features,
> including some I hadn't considered.  Might be a good idea to go
> through it before we set the skills/items design in stone?
>
> Ant
> --

Good idea.

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

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.

Adrian

Re: [Pybem-developers] boojum

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

At 9:11 AM +0800 17/6/02, Anthony Briggs wrote:
>>Ant, I reinstalled cygwin on my laptop and it's all cool,
>>I can ssh to sourceforge, and cvs out the code.
>>
>>Read through all the boojum files, and created a game,
>>though it crashed when I tried to 'trample nw'.
>
>Did it give you a traceback? I'll put some sample orders into the 
>test script...

Ignore this. I just updated the script to exercise some of the common 
orders (not sure of an easy way to test the 'give' orders, other than 
having a pre-set world in there).  Anyway, there were a whole load of 
left over case changes that I'd missed last time around. I think the 
testing script exercised most, if not all, of them.

Hooray for the automatic testing script! ;)

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

Re: [Pybem-developers] boojum

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

>>  * big thought - we should try to support TWO of everything,
>>  from the outset.  ie.  two different game worlds, with different
>>  attributes, orders, coordinate system, output display(?)
>>  Basically, for everything that we plan to make customisable,
>>  we should start off supporting two versions of that option,
>>  to force us to generalise.
>
>Absolutely. Every time I've heard from a person who's said "Oh, I 
>can't code" or "I don't know Python", I've said "Well, come up with 
>a design for a game that you'd like to play". Even if it's just 
>something for us to think about, it's valuable to look at the 
>problem from a "non-Atlantis" point of view. Hence that whole post a 
>little while back on the sorts of games we might want to think about 
>doing. eg. MOO, MOO2, Civ, even chess ;)
>
>That said though, I think it'll be easier to do/convince people to 
>do once we've got some basic classes up, like items and skills, plus 
>a parser to read in all the config files. At the moment, it's pretty 
>sparse, and you need to be a python hacker to tinker with it. Plus I 
>think Boojum's starting to stretch it's initial design somewhat. 
>This is where the RAD aspect of python comes into play - it's pretty 
>easy to modify stuff on the fly, so if someone comes up with 
>something we hadn't thought of, we can just alter items, or skills, 
>or units to fit. I suspect armies are eventually going to be a 
>sub-class of Unit.

Another thing -- in the TODO file in the most recent version of 
Atlantis are a whole bunch of different suggestions for features, 
including some I hadn't considered.  Might be a good idea to go 
through it before we set the skills/items design in stone?

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

Re: [Pybem-developers] boojum

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

>Ant, I reinstalled cygwin on my laptop and it's all cool,
>I can ssh to sourceforge, and cvs out the code.
>
>Read through all the boojum files, and created a game,
>though it crashed when I tried to 'trample nw'.

Did it give you a traceback? I'll put some sample orders into the 
test script...

>I must admit I haven't gone through the UML yet,
>but as you say it's pretty simple so far and makes sense.

Yeah, I haven't heard back from Sheldon yet. He was saying that he 
would look at generating a new UML thingie to design from.

>Haven't thought about it too much to comment on the code,
>but some random thoughts:
>
>  * could make it a bit more OO, everything should be in a class

This is still a carry-over from my initial "get everything running as 
a proof of concept" hacking around. It's gotten a lot more OO than it 
was initially...

>  * could set some constants

I'd prefer that everything like this came out of a config file, but I 
guess that in Python, it's all pretty much of a muchness (see the 
config.py files for thera ;) )

>  * could load all the config from a file (World.loadConfig)
>  * maybe jot down some sort of coding standards,
>  like how to name files / functions / variables?
>  I've been using Java style lately, eg.  World.loadConfig()
>  where the function has first word no-caps, other words caps.
>  I think either that or using underscores is more readable than
>  running them together  (eg. World.loadconfiganddosomethingrandom)

I think that if you have names like this, it's a sign that you need 
to break your functions down more (ie you'd have two methods: 
World.loadconfig() and World.dosomethingrandom() ). As far as coding 
standards, Python's pretty reasonable, so I haven't set too many. 
Some of the key ones that I've been using:

Methods should be capitalised (eg unit.Update() ) - Pretty arbitrary, 
but it helps tell them apart from your attributes.

As above, methods should only be a few words long, and preferably 
take the time to make it a good one.

Strings should be double quotes unless you have a damn good reason, 
ie "This is a string" rather than 'This is a string', since strings 
like 'This is still a string, isn't it?' will make Python barf. Not 
hard to find & fix, but still, they take up from several to thirty 
seconds of your time, and if you do it routinely, well, there's five 
minutes gone...

It's ok to create a 'placeholder' variable if the variable you're 
assigning to is waaay deep, and you're going to be using it more than 
once. eg. In Unit.Give(), I create a targetmonster about halfway 
down, since

   targetmonster = self.faction.factionlist.units[theunitnum], and then
   targetmonster.items.append( self.items.pop(itemnum) )

is self-commenting, and so much more readable than:

   self.faction.factionlist.units[theunitnum].items.append( 
self.items.pop(itemnum) )

etc.  Btw, "targetmonster = ..." doesn't create a copy of the 
variable, it's a pointer to it.

>  * big thought - we should try to support TWO of everything,
>  from the outset.  ie.  two different game worlds, with different
>  attributes, orders, coordinate system, output display(?)
>  Basically, for everything that we plan to make customisable,
>  we should start off supporting two versions of that option,
>  to force us to generalise.

Absolutely. Every time I've heard from a person who's said "Oh, I 
can't code" or "I don't know Python", I've said "Well, come up with a 
design for a game that you'd like to play". Even if it's just 
something for us to think about, it's valuable to look at the problem 
from a "non-Atlantis" point of view. Hence that whole post a little 
while back on the sorts of games we might want to think about doing. 
eg. MOO, MOO2, Civ, even chess ;)

That said though, I think it'll be easier to do/convince people to do 
once we've got some basic classes up, like items and skills, plus a 
parser to read in all the config files. At the moment, it's pretty 
sparse, and you need to be a python hacker to tinker with it. Plus I 
think Boojum's starting to stretch it's initial design somewhat. This 
is where the RAD aspect of python comes into play - it's pretty easy 
to modify stuff on the fly, so if someone comes up with something we 
hadn't thought of, we can just alter items, or skills, or units to 
fit. I suspect armies are eventually going to be a sub-class of Unit.

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

[Pybem-developers] boojum

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

Ant, I reinstalled cygwin on my laptop and it's all cool,
I can ssh to sourceforge, and cvs out the code.

Read through all the boojum files, and created a game,
though it crashed when I tried to 'trample nw'.

I must admit I haven't gone through the UML yet,
but as you say it's pretty simple so far and makes sense.

Haven't thought about it too much to comment on the code,
but some random thoughts:

 * could make it a bit more OO, everything should be in a class
 * could set some constants
 * could load all the config from a file (World.loadConfig)
 * maybe jot down some sort of coding standards,
 like how to name files / functions / variables?
 I've been using Java style lately, eg.  World.loadConfig()
 where the function has first word no-caps, other words caps.
 I think either that or using underscores is more readable than
 running them together  (eg. World.loadconfiganddosomethingrandom)

 * big thought - we should try to support TWO of everything,
 from the outset.  ie.  two different game worlds, with different
 attributes, orders, coordinate system, output display(?)
 Basically, for everything that we plan to make customisable,
 we should start off supporting two versions of that option,
 to force us to generalise.

What do you think?

Adrian

Re: [Pybem-developers] Busted build - the fix...

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

On Sun, 16 Jun 2002, Anthony Briggs wrote:

> Hi Adrian (and whoever else is listening),
>
> Basically, the base object class wasn't being initialised. So faction
> stuff was turning up in the unit's info field, for some bizarre
> reason.
>
> I'm still not fully clued in as to why this was happening, since it
> seems that the general flow of events should go something like
> 'create faction, create unit, create unit, etc.' why would a
> faction's info class override a unit's, when the init for the faction
> comes first, and the unit second.
>
> Any ideas?
>
> 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
>
Maybe put some more debug in the init functions?

*I need to check the code.

Adrian

[Pybem-developers] Busted build - the fix...

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

Hi Adrian (and whoever else is listening),

Basically, the base object class wasn't being initialised. So faction 
stuff was turning up in the unit's info field, for some bizarre 
reason.

I'm still not fully clued in as to why this was happening, since it 
seems that the general flow of events should go something like 
'create faction, create unit, create unit, etc.' why would a 
faction's info class override a unit's, when the init for the faction 
comes first, and the unit second.

Any ideas?

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

[Pybem-developers] Ideas

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

Here are some ideas for the sorts of game we might consider 
supporting. A wide array would be good, if only because it'll help 
get us out of the Atlantis mould:

turn-based war games:
The obvious one. Atlantis, wyreth, et al are what inspired this 
project in the first place.  There could be many different genres, 
though - a civil war game, WWII mission, or a city-based game.

other turn-based games:
I reckon that pretty much any turn-based game is up for grabs. Civ, 
Civ II, Masters of Orion I&II, possibly even things like Star Fleet 
Battles (not that I'd ever want to play it, but someone might)

non-simultaneous games:
ie game where people take turns - Chess, Draughts, Go, tic-tac-toe ( 
this has potential as a tutorial) etc.

wackiness:
What about a version of Pimpwar? Or Bartok?

the map:
We're not limited to a simple, hex-based map. We could make a 
three-dimensional one, if we were writing a space game. We could make 
a simple, ten-'hex' map with American cities, for Pimpwar, or an 8x8 
board for Chess. Players could even have orders to be able to create 
their own hexes. Actually, that's a really good idea for my mage game 
;)

programming games:
Like codewar, or robowar(?). In most games, scripting can really take 
the micromanagement out of running a large faction, even if we don't 
specifically write a game as a coding exercise, so I think it's 
something worthwhile to do (just not right now). Creating some sort 
of bastion function with limited access to a unit's functions would 
let players script their monsters in python(!)

Hope this gets you thinking... I'm off to bed.

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

Re: [Pybem-developers] Welcome!

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

At 12:17 AM +0800 12/6/02, Adrian Smith wrote:
>I've joined the list,
>looking forward to some great Python development!
>
>Adrian

Now what we need to do is sign up someone in the US.  That way, we 
can get the evil '24-hr coding' thing happening, where one timezone 
hands off to the next, and then goes to bed ;)

I'm also wondering if we should set down some sort of methodology too 
(eg. semi-XP, with unit tests and small changes), but we may want to 
wait for the others..

Ant
ps. Good idea about putting up a Wiki. I'll see if I can put one up 
sometime soon.
pps. Signed up to Sourceforge yet?
-- 
----------------------------------------------------
HyPEraCtiVE?  HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB...@Ii...
----------------------------------------------------

[Pybem-developers] Welcome!

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

I've joined the list,
looking forward to some great Python development!

Adrian