This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: advances.g, unit construction speed


> I don't see the massive proliferation of units later in the game as a
> problem

Well, it becomes very tedious to move them around.  Especially with
the limit of 4 units per hex.  It takes longer and longer to get
through a turn.  So if the problem is "nobody will want to play the
game more than once" we seem to have problem either way.

> I have long intended to improve the advanced construction part of the ai,
> and also integrate it better with the rest of the ai code

I guess this is the real issue...

> I think a better way to curb unit numbers might be to slow down city
> growth.

Probably...

Anyway, I've updated the advances.g section of
http://www.panix.com/~kingdon/xconq.html - I guess that is the thing
to do for now.

> Speaking of the new network code, has anybody found any bugs yet? How
> is real life performance?

See Bob's message concerning the games he and I just attempted (short
summary: we had to go back to xtconq).  I'm not sure you should wait
the release for it, though.

Maybe writing a monkey tester would be a good idea?  (That is,
generate random unit moves and other commands with random timings).

If by "performance" you mean network bandwidth and such, it seemed
fine.  If you want to see for yourself, there must be programs
floating around to simluate it (the only one I quickly found was the
DreamTeam Network Simulator (DNS), which was just for Java programs as
far as I could tell - or a Linux kernel patch at
http://www.uwsg.iu.edu/hypermail/linux/kernel/9604.1/0563.html ).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]