Go to the first, previous, next, last section, table of contents.

## Interface Architecture

An interface is always compiled in, so it has complete access to the game state. However, if your version of Xconq has any networking support, the interface should not modify kernel structures directly, but should instead use the networking-enabled kernel modification routines. The kernel routines will forward any state modifications to all other programs participating in a game, so that everybody's state remains consistent.

A working interface must provide some level of capability in each of these areas:

- Main program. The interface includes the main application and any system-specific infrastructure, such as event handling.
- Interpretation of startup options. This includes choice of games, variants, and players.
- Display of game state. This includes both textual and graphical displays, both static and dynamic.
- Commands/gestures for unit tasks and actions, and for general state modifications.
- Display update in response to state changes.
- Realtime progress. Some game designs require the interface to support realtime.
- Error handling.

The file `skelconq.c` in the `kernel` directory is a good example of a minimum working interface.

Don't let interfaces ever set kernel object values directly, always go through calls that can be "siphoned" for networking.

Go to the first, previous, next, last section, table of contents.