General Issues

The committee has a general forum to discuss issues that are relevant for all groups. Some discussions are given below.

Module Interaction

The role of individual modules was further clarified in the discussion, i.e., how they interact with the main game engine and among themselves. The main idea is that every module has a domain-specific interface component (the special working groups take care of these) and a general world interface (part of the world interfacing group's task). Here is an example - note, however, that this example architecture represents only one possible way, mainly to show a variety of possible processing pipelines, and is not how we want everyone to build a system.

In the example, if the NPC wants to move, it uses the PATH Interface to send a movement goal to the Pathfinding Module, which in turn uses its World Interface to query possible waypoints from the World, and returns a potential path by the PATH Interface to the NPC. The NPC then uses the STEER interface to send the first waypoint to the Steering Module, which requests by its World Interface that all information necessary for its steering should be passed to it. The NPC forwards these requests to the World by its World Interface. Every some milliseconds, the Steering Module is called by the NPC via the STEER interface to compute a move, which is returned via the STEER interface. The resulting movement actions are forwarded by the NPC to the World. The requested position/movement updates from the World are passed via the World Interface to the NPC, which forwards this information to the Steering Module by its World Interface. If, however, the waypoint is reached, the NPC uses the STEER interface to push the next waypoint of the path as movement goal to the Steering Module. The NPC has internal logic to compute further behavior for which it also makes use of its World Interface to the World.

In another scenario, for example, one could have pathfinding and steering on one level, a navigation module on top of them, and a finite-state machine module for the higher-level behavior on top of the navigation module. All of them could have an own World Interface directly to the World.

There is no "best" way to couple components, and they should be flexible enough to adapt to the architectural requirements of the game at hand.

State Handling

The discussions on the general design concept continued, and concepts like state-based, object-oriented and data-oriented calls to set module properties were discussed. Issues regarding compatibility, hardware, debugging, and so on were raised in this context. Overall, the discussions showed some strong resentment against the state-based approach, partially based on bad experiences with OpenGL. The exploration of appropriate mechanisms only just started, and will surely provide some interesting discussions in the near future.