[Sxengine-devs] Architectural "Big picture"

[TerryP <spi...@us...>]

The concept is fairly simple at the top level the engine is divided into 5
parts:

   - Client application
   - Server application
   - Shared libraries
      - Parts of the engine
      - Dependencies of the engine
   - Plugins providing backends
      - Dependencies of the plugins
   - Header files to #include in game code

The client application is responsible for rendering and input (etc). If need
be it would launch the server on the localhost to handle single player or
host a multiplayer game.

The server application is entrusted with world management, the kind of thing
that decides if you win/lose, tracks scores, and so on. It can obviously be
hosted in Bolivia as long as the client(s) can talk to it.

Shared libraries are the meat and potatoes of the architecture. The engine
itself needs to offer a class library of useful code. Stuff like
SxE::String, interfaces to log handling scripting, game settings, and so on.
Little of it should be strictly necessary for writing a game but making
peoples lives easier is the point of doing an engine ;). Plugins would be
shared libraries that get loaded on at run time, for example the games
configuration may say to use the Spidermonkey JavaScript engine to implement
the engines scripting interface. So the engine goes a head and loads
the necessary plugin DLL implementing the interface by way of Mozilla
Spidermonkey. This model works for most any component. Any other runtime
dependencies like a Direct3D runtime or Boost.Thread would be included in
the binary distribution as needed.

This keeps the engine flexible, so for example if the Irrlicht rendering
engine doesn't work on platform XYZ, an implementation of
the necessary interfaces can be written for a rendering backend that does
work on platform XYZ, and used as identically as possible. Mating a
client/server architecture so deeply can also simply the task of making a
game with both a single player campaign and a multiplayer, and better yet
co-op modes!


There are at least 3 schools of thought on how to implement a game using an
engine with regard to what writing a game on it will look like.

One is to simply fork the engine code and hack away until it implements your
game. That is the model Id Softwares DooM and Quake III game engines
followed. Works nice except you have to cuddle up to the engine internals to
actually do anything :-o. It's more practical for in-house use than a
general purpose system, in my humble opinion. That is also how most such
engines began in the good old 90s.

Another less often used method is to treat the game as an object to be
called by the engine, rather than it calling the engine. I haven't seen many
game engines made this way.

The third way, which could be implemented through the second one: is to shut
off the game specific code into a separate environment from the actual game
engine. That's the model that Epics Unreal Engine (C++) follows with its
UnrealScript language, and to a lesser extent the original Quake (C) with
it's minimalist "Quake C" game language. I say to a lesser extent beacause
while you should never have to go past UnrealScript for most UE games,
eventually you'll want to modify Quake I engine code instead of just Quake C
code.

Of course only the fourth method of game engine design likely works \o/.



For SxEngine, my vision could be called an implementation of the second
method: treating a game as something the engine calls rather than vice
versa.


A game is written as  a C++ library expected to export an implementation of
an interface between game and engine. When the client or server application
executes, it loads that DLL. It is theoretically possible to implement that
proverbial "Game Application" class as a simple adapter for a more dynamic
language (including the script engine) instead of doing the game largely in
C++. I'm actually interested in testing the performance of that sometime.

Doing it 'this' way has some interesting properties. It should reduce (and
usually eliminate) the need for a games developer to write their own client
and server programs, and modifying SxEngines client/server should only be
needed for specialised cases. Like wise this allows the games code to
receive access to relevant portions of the game engine via C++ references
where needed instead of A.) having to manage the engine internals and
various component memory allocations by hand, or B.) having to ask for
handles to singleton objects on demand. It makes a very nice design with
less complexity and can readily be grown to it's fullest potential. At
least, that's what several hours thinking tells me lol.



Any questions, comments, advice (Q.A.C.s) or the like before we move on?
Quack, quack!
-- 
         TerryP / Spidey01
Just Another Computer Geek.