Re: Major problem with the path code

[Peter Garrone <pgarrone@acay.com.au>]

On Mon, Dec 01, 2003 at 08:46:13PM -0800, Stan Shebs wrote:
> Hans Ronne wrote:
> 
> >
> 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
> 

The current structure has a wholesome consistent feel to it, in
that all these networked instances share the same enormous state at multiple levels,
against the thrust of modularity in software I suppose,
but its sort of awesome in its own right.

I suppose xconq is essentially an implementation of a language, the GDL.
Are plans, tasks, doctrines implicit in the GDL? The thrust of kernel
development will probably be in the direction of moving these concepts
outside of the inner core, leaving actions as the essential common element.

Regarding networking, if its possible to play something like xpilot
online, it should be possible to share actions in "realtime". Generally
xconq is categorised as a strategic turn-based game anyway, though in
reality it isnt. I think it has a big niche as a strategic turn-based
game. I would like to see a play-by-email mode, which is preety far from
what it does now, I believe.

Anyway, I am a long way from understanding it all, so I could be wrong,
 Regards,
  Peter