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: Major problem with the path code


Hans Ronne wrote:


The pathfinding is now implemented as part of the action code, and that
is wrong, it should be part of the player code, because the path that
is found is only ever hypothetical. Also it ie expensive, so should not
be replicated on all computers in a networked game. So have pathfinding
called from task.c, but not move.c.

This would require that move tasks be private to each player, and not
broadcast over the network. So the logical thing to do is to stop
broadcasting all tasks, only actions, and for each game loop to only
process local ai players. Also the shared state should not include
tasks or plans. Plans should be private, it should be irrelevant to the
referee code what the plan for each unit should be, only what its
actions are.


I agree. I discussed this with Stan a long time ago. I remember that he had some good arguments why plans and tasks also should be broadcasted, but I am not sure to what extent they still apply today. They might have had to do with performance, which is not an issue any longer. I will have to do some email archeology to find out. Or maybe Stan can comment on this?

OK, I've been trolled - or more accurately, had the lure bobbed up and down
in my face. :-)

All I remember ("my mind is going, I can feel it") is that if a task had to
broadcast all the actions it generated, it seemed like it would be a lot of
extra traffic for slow connections. The more synchronized state you have,
the more you can do locally. I also wasn't expecting to support much per-peer
variability at the plan/task level, because those are made at least partly
visible to the UI, and it would be good to have at least a modicum of
consistency by wiring it into the kernel.


These don't seem like really strong arguments though; I suspect everything
could be made to work OK with local plans and tasks.

Stan



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