Xconq has been also been designed to allow for different kinds of networking strategies.
The kernel/interface architecture can be exploited to build a true server/client Xconq, by building an "interface" that manages IPC connections and calling this the server, and then writing separate interface programs that translate data at the other end of the IPC connection into something that a display could use. My previous attempt at this (ca 1989) was very slow and buggy, though, so this is not necessarily an easy thing to write. The chief problem is in keeping the client's view of thousands of interlinked objects (units, sides, cells, and so forth) consistent with the server. Most existing server/client games work by either restricting the state to a handful of objects, or by only handing the client display-prepared data rather than abstract data, or by reducing the update interval to minutes or hours.
[When networking, all kernels must call with same values...]