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