This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: advances.g, unit construction speed
- From: Jim Kingdon <kingdon at panix dot com>
- To: hronne at pp dot sbbs dot se
- Cc: xconq7 at sources dot redhat dot com
- Date: Sun, 10 Mar 2002 22:40:32 -0500 (EST)
- Subject: Re: advances.g, unit construction speed
- References: <l03130300b8b1b30611e8@[217.115.37.233]>
> 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 ).