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