Re: [Pybem-developers] PyAtlantis-stable and PyAtlantis-trunk
Brought to you by:
abriggs
From: Anthony B. <ab...@we...> - 2007-09-10 12:03:28
|
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... ------------------------------------------------------ |