From:	bryan AT alpha DOT hcst DOT com (Bryan Murphy)
Newsgroups:	comp.lang.c++,comp.os.msdos.djgpp,gnu.g++.help,rec.games.programmer,rec.games.design
Subject:	C++ Real Time Design Issues
Date:	22 Apr 1997 09:56:52 -0400
Organization:	Hassler Communication Systems Technology, Inc.
Lines:	180
Message-ID:	<5jig34$pu9$1@alpha.hcst.com>
NNTP-Posting-Host:	alpha.hcst.com
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

---------------------------------------------------------------------

WARNING, EXTREMELY LONG! :)

I have a few questions about some Heirarchical design issues I faced
or will face in my current program, and I was wondering if anybody
would be willing to help me out/give me ideas or discuss some 
concepts?  Please try to respond via e-mail if you post a reply to
UseNet as I don't read the groups to thoroughly and might miss any
replies!!  Any help is much appreciated!

---------------------------------------------------------------------

First off, I'm going to give you an idea of what I am trying to do, 
what I have done, and how I am going about it.

I am trying to write a 'Universe Simulator'.  I suppose it would be
along the lines of Microsoft's Space Simulator when finished, though
I have much grander ambitions than what was accomplished in SS.  

I am writing it in C++ (currently using DJGPP, but that could change
at any moment).  My goal is to create a fully object oriented program 
with different modules that work together.  I can easily create a
simple game using my current model, but I want to do a Client/Server
design, and I want my graphics classes to be completely separate from
the Universe simulator, that way I can rewrite the graphics classes
without having to modify any of the programs functionality (for porting
to different operating systems or graphics libraries, as well as for
enhancing the graphics as I get better at it).

Currently, I've written a simple GUI interface.  In many ways it
resembles MFC, but there are a few significant differences.  Anyways,
I have a base heirarchy of objects that goes something like this:

BASE_OBJECT                  -> Timer Functions
 |
 |-+-----> COMPONENT         -> Initialize, ShutDown, OnUpdate
 | |
 | |-+---> WINDOW            -> Window, contains Components 
 |   |                          and sub Windows
 |   |---> Window Components -> Buttons, Dialogs, etc.
 |   |
 |   |---> DESKTOP           -> Window with special functionality
 |                              to act as a desktop. 
 |-+-----> APPLICATION       -> Application Architecture.  Contains
 | |                            Desktop and Input objects as vars
 | |-----> SIMULATION        -> Extends Application Architecutre  
 |                              to execute in real time
 |-------> INPUT             -> Simple Input Library


Now, I have an object, descended from Window called Desktop.  The
desktop interfaces with the screen, and also provides a few functions
so that I can easily copy bitmaps to the desktop.  All these objects
use a BITMAP object, descended from BASE_OBJECT, that uses Allegro (if
you don't know what it is, all it is is a graphics library) for
it's functionality.  The Desktop object is the only object that is
allowed to write directly to the screen.  Everything is blitted to
bitmaps which are stored and blittled to their owner's bitmaps when
changes occurr, then eventually they get down to the desktop who owns
everything, and does the final blit to the screen.

That's how the GUI works.  The APPLICATION itself is a class 
descended from BASE_OBJECT that has two Class Objects stored as variables
in it.  One Object is the Desktop, obviously, and the other is called
Input, since it interfaces with the hardwdare for getting input.  
It's functionality isn't important, all it really returns are numbers
signifying various inputs (MOUSE_PRESED, K_KEY_PRESSED, etc. etc.)

The SIMULATION object is where most of the program will take place.  It
is based off of the APPLICATION object.  It's only major difference is
that a U_UPDATE message is placed into the INPUT Queue every x milliseconds.
This U_UPDATE message is what allows it to be a real-time simulation,
instead of a simple event driven application.

This is what I have.  My major problem right now is that I want it to
have a Client/Server type model.  I want the server to update all of
the Universe information, and the Client to get only the absolutely
necessary information and display that on the screen.  How can I fit
this concept into my model?  I haven't really implemented much of the
3D Models, but here is what I've been planning on doing:

BASE_OBJECT
 |
 |-+-----> SIMULATION
 | |
 | |-----> UNIVERSE     -> Expands Simulation Architecture to add support
 |                         for our universe.
 |-------> VERTEX       -> Vertex
 |
 |-------> VECTOR       -> Vector
 |
 |-------> OBJECT       -> An Object in space.  This currently only stores
                           enough information to describe a point in space,
                           but will be inherited by more complex objects.

Universe inherits the properties of simulation.  On every U_UPDATE message,
it calls the OnUpdate() procedure of all objects in 3D space. These objects
then do what they need to do, such as move, rotate, slow down, etc.  It
would also pass down any other messages to these (such as commands from the
user).

This effectively models the universe, with some minimal graphics support.
My plan was then to extend these base objects with Objects that actually
do 3D Graphics and displaying.

So, now the problem is:  How do I implement a Client/Server type approach
into this structure, along with 3D Graphics Support that is completely
separate from the GUI (this is fairly important to me, but if it needs to
be integrated into the GUI, I can do that).

Here are my thoughts on the matter.   I would like any comments, criticisms,
suggestions, insults, pointers, or any information you could provide me to
help me (such as net resources, books, source code, etc.).

I will create the server using the object heirarchy above.  It will model
the universe.  INPUT will have to be modified a bit to get information from
Sockets.  The Universe object will probably also have to have Sockets
support built into it, so that it can send any appropriate information to
the client.  The server will most likely show information about what is
going on and not the game itself, so it will probably need only minimal
GUI and 3D graphics support.

The client, will be slightly different.  Rather than being based off of
SIMULATION, it will be based off of application.  It will simply wait for
input, and do what it needs to do (actually, SIMULATION vs APPLICATION
isn't really important.  I may go with SIMULATION if I find a need to
constantly update something).  It will recieve only VELOCITY and VECTOR
locations of objects, and update the objects appropriately.  I could
probably build some prediction into it, but that's down the road a bit.

Now, the client definately needs some heavy duty 3D graphics support.  I
see two methods:  Build it into the GUI, and only use it for the Client,
or extend the Universe Objects to include Graphics Support.  Which would
be my best bet?  Putting it in the GUI would limit the Objects to what
the GUI is capable of, but putting them in the Objects would make the
objects autonomous units that could do whatever they want.  Or, is a
path somewhere down the middle the best approach?  Afterall, the DESKTOP
is simply a bitmap.  All 3D Graphics need to output to a bitmap, and
don't rely on the GUI functions.

Well, that's my program/problem.  Programming is not the issue, design
is.  It doesn't matter what I specifically use to encapsulate such things
as Screen Output, Input, Communications, the 3D Graphics and Client/Server
are where I need some help/ideas/comments/criticisms/whatnot.

Any help would be GREATLY appreciated!!

---------------------------------------------------------------------

I'm putting in one last section.  I may have sparked your interest in my
project, so I'm just going to tell a little bit about my plans.  I want
to make a 3D Space Simulator.  I want it to support multiple objects
(from space ships, to planets, stars, etc. etc.) and I will probably use
a lot of physics to model it.  I'm not trying for state of the art graphics,
though they would be nice, I just want functional.  I am doing this as
a learning experience, and to put on my resume.  I want to prove to myself
and others that I can do all the above, and I can do it well (which is why
I'm not doing this in MFC, or using the multitude of libraries available.
I'm only using Allegro for the very basic low level routines, because I
want to be able to port this project, and low level routines are a no-no
for porting).  Hopefully this will serve two purposes, a fun atmosphere
for blasting your friends out of the galaxy, and for some exploration and
experimentation.  On of my main goals is to offer a multitude of methods
for controlling the ship, including various levels of Flight Control Systems.
I want to experiment with flying ships in 3D.  I'm not satisfied with the
current methods used in games (Tie Fighter/Wing Commander specifically).

What I do with the project all depends on how it turns out.  If it turns
out to be something great, I may try to market it.  Otherwise I will probably
make it freeware, or very cheap shareware.  I will definately market the GUI
library as some form of shareware.  If its a lot of code, I probably won't
release (or sell) the code till I move on to something else completely.  If
it's minimal code I'll probably sell the code along with the program.  Every
thing would be reasonable of course.  No stupid $100+ for dumb libraries that
you can get everywhere else.

Up to date (usually) information is available at:
  http://www.hcst.com/~bryan/project/

- Raw text -