An attempt at an orbital-height view of the major components in involved in the sort of space-based MMOG that we've been discussing.

When we get to 'small enough' subsystems, I would like us to assign an 'owner' to each one, who will be the primary driver of the subsystem's design.

Some guidelines:

• Because we would like a flexible, distributed architecture, the traditional client/server architecture is not directly applicable. Many, perhaps most, subsystems can be identified without deciding a priori whether they run on a 'client' (end-user node) or a 'server' (company node). In fact, almost any system in the network can be a server to a greater or lesser degree. However, there are some components that can definitely be associated with user interaction.
• We will model many things besides physical objects. There are some common needs for all modelled objects, particularly with respect to distribution, persistent storage, and security. We will try to identify subsystems that provide relevant services regardless of the 'category' in which a particular object falls.
• Front-end user interfaces are significant development efforts in their own right, but might be the most amenable to the application of third-party libraries.

The game is all about simulating things in a variety of realms - physical, economic, sociopolitical, etc. In a sense, even the front-end user interfaces are a simulation -- of a spaceship's control interfaces, or of a terminal for interacting with a trading network, for instance. It may serve us well to organize the system around discrete simulations that can be programmed and executed relatively independently, although they may communicate with one another. This will simplify the programming by treating each simulation as a single-threaded unit. Multi-processing and distribution issues can be handled primarily in the communications channels between simulations, and related interfaces to the environment within which a simulation is executing. As an initial design, each simulation could run in a separate process. Later, alternative implementations of the communications channels would allow us to consider a multi-threaded, single-process aggregation of some simulations.

This approach leads to a design based heavily on message flow. Top loops of simulations may be message-driven, or clock-driven, as appropriate for the simulation. Clock-driven loops, for instance the user interface, will arrange for the handling of incoming messages as needed.

The biggest downside to this arrangement is probably in the performance-critical player client, where such a strict separation discourages the sharing of memory between the rendering code (which is part of the ship interface simulation) and physical modelling code. The physical simulation benefits from this sort of design because it needs to be executable in two very different environments; on the player's machine, and on network servers. On the latter class of machines, physical simulation is needed to verify and arbitrate among the physical simulations running on player's computers. However, the amount of information flowing between the physical simulator and the renderer might not be that high. The renderer will have its own data structures describing the models and such, most likely in a different form than needed by the physical simulator. The renderer will need periodic updates on position and orientation of all objects. Should performance become an issue, the physical simulator could support an alternate direct-call interface to provide this data more efficiently.

Subsystems, areas of expertise and concern:

• Database Systems
• Network Services Need a system with high-level abstractions for activating objects, distributing state information, and establishing communications between various components. Tools must be available to assist higher-level software with load and bandwidth management, ultimate decisions on prioritizing communications have to be made at that level. Security will be an issue for at least some communications.
• Simulation engines: There are various simulation engines, with varying requirements on capacity and responsiveness. Some will be working in real-time primarily with data from activated objects, others will tend to be intensive users of database information that don't need to be as responsive. The simulation engines are distinct from AI and player agents that may interact with them.
  • Space Physics (Space as opposed to the possibility of someday also having ground physics, or in-station physics, for FPS-style components.) This engine simulates everything you see when flying around.
  • Economy Probably a system of independent economies with some communication between them. However, most interactions between separate economies will be via the actions of active objects (players and AI).
  • Galactic Comms Models the galactic comms network. Voice? (Istvan: suggest not only a real-time "chat-like" system, be it text or voice, but also the equivalent of a simple internal email that would work as a "message drop" for people not necessarily online at the time.)
• AI: Various AI components are envisioned.
• User interaction subsystems: Things that let users interact with the system. Primary target is probably Windows, but portability or alternate implementations for other systems would be a nice bonus.
  • Graphics Engine: Turning the output of the physics simulation into pretty pictures. Third-party library usage likely.
  • User Input System: Turning user input from controllers into input for the various simulators.
  • Audio System
• Scripting Systems The benefits of a custom language that can interact with many of the subsystems cannot be overstated. Once the engines are in place, a custom language can greatly accelerate the enrichment of the milieu.
• Installation and patching A (very) necessary evil.

Istvan: Proposed additional subsystems: ;;Sociopolitics simulation engine: visualized at the moment as mostly a database holding information on relationships among abstract entities-not-players. However, because I conceive of the data being adjusted dynamically based on in-game events, this system is not just storage but also must include functions that act on the data, and preferably a simple toolset that allows manual adjustment of stored data. The easiest events upon which to trigger change on stored relationships would be such things as missions/tasks (also stored in a subset of the game database), because mission-end conditions can be tracked.

Dan Muller wonders if this shades over into AI? Can/should the sociopolitical environment be simulated indirectly by the interaction of various AI components? (Admittedly, the distinction between 'simulation components' and 'AI components' may be a matter of opinion in some cases.) Istvan: qualified 'maybe'. I don't think the admittedly simplistic "engine" I thought really quite makes it into 'AI' - However, I could see a potential for the handler functions being made more sophisticated and managing the relationship database in a more complex manner. More likely, however, I see a real valuable role for true 'AI components' as the sociopolitical 'actors' which execute the decisions behind each 'non-player' Org, or entity as I'm calling them in some places. The handlers would work off the AI generated events and do so no differently than they would off player generated events. Much more importantly, the AI actors would examine the present state of the relationship table when making decisions about what actions to prioritize with their resources, and what other actors to target/influence.