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