Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

C++ Real Time Design Issues

2 views

Skip to first unread message

Bryan Murphy

unread,

Apr 22, 1997, 3:00:00 AM4/22/97

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

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:

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/

Christopher Eltschka

unread,

Apr 22, 1997, 3:00:00 AM4/22/97

Just some thoughts (every sentence to be completed by "IMHO"):

The objects have two different sets of data: One "physical" set
(location,
velocity, mass, ...) and one display-only set (color, shape, ...).
If I understand you correctly, the server is just for calculating the
physics, while the client is just for graphics. So I would
split these two into different objects, one "physical" and one "visual".
The physical objects would be used on the server side, while the client
would operate with the visual objects. There may be several visual
objects for
just one physical (the server doesn't need to distinguish between stars
and planets, f. ex.), and there could also be several physical objects
represented by one visual (if they look the same, but behave
differently).
This splitting would also allow different ways of displaying the same
data (f. ex. planets could be displayed as points, as filled circles,
as colored filled circles, or as bitmaps - each version needing
different
data) without affecting the physical objects at all (the server is not
even touched).

The 3D graphics should be a system by its own, but it seems to make
sense
to embed the visual objects into this system. If you don't want to give
the objects complete control, the position could be determined by
3D components which are not visual objects, while the visual objects
themselves would determine their appearance (f. ex. scale their size by
being given the distance to the viewer). The rest of the 3D graphic
system
would then combine the appearances to the complete picture of the
universe
in the output bitmap. BTW, this bitmap should not be the desktop, but be
owned by a GUI object, which itself can manipulate it again (f. ex. can
copy a part of it into a window with scrollbars, so you can have a
larger
view than your screen). Of course the GUI object could just decide to
give
you the desktop as output bitmap.

The general structure of the client/server system would look like
the following:

Server:
- contains the physical objects
- does the physical simulation (calculation of physics)
- is only concerned with "physical" data (i.e. what is needed for the
calculations)
- of course maintains connections to clients
- could have a database for physical data (f. ex. masses and
trajectories
of the planets in the solar system)
- might have a database for visual data (f. ex. bitmaps of the
planets in the solar system or of different types of spaceships,
or color/brightness tables for stars), but doesn't really handle this
data, just give it to the client on demand
- GUI for checking state and potentially handling the database(s)

Client:
- contains the visual objects, as part of the 3D graphics system
- Allows users to specify physical as well as visual data for the
objects
(maybe including accesses to server side database(s))
- Physical data is sent to the server, while visual data is kept locally
(of course, physical data can be kept locally as well, f. ex. to
allow to restart the simulation, but it's just "dead data")
- Physical data received by the server (positions, maybe orientation)
is combined with the local visual data by the 3D graphics system to
a view of the universe into a bitmap provided by the GUI
- Showing this view on the screen is done by the GUI, which certainly
does
the other user interaction (specifying the object data, f. ex.) as
well

The 3D object tree could look s.th. like the following:

3D_BASE_OBJECT
|
+-> SPACE (object to combine visual objects to an "universal view")
|
+-> VISUAL_OBJECT (describes the appearance of a physical object)
|
+-> STAR
+-> PLANET
+-> SPACE_SHIP
+-> ...

Instead of having a SIMULATION object creating the update messages,
I'd define them just as another source of input (therefore sent by an
INPUT
object): It is application input generated by a timer.

Some points which should be considered:

Should different clients be able to access the same physical data (i.e.
operate in the same universe)?
If yes, how should access to the data be governed?
Should other clients be allowed to manipulate the universe?
Or should view/manipulate access be possible to be controlled by the
"creator" client? Should clients then be allowed to "donate" their
universe to others? Or to share ownership of the universe?

Should universes be destroyed when the client disconnects, or should
it be halted to be re-accessed when connecting again?

Should one client be allowed to create more than one universe?

The easiest solution would of course be the one client/one
universe/destroy on
disconnect one. But it would also be the least flexible one.
OTOH, if the other possibilities are considered from the beginning, the
server can possibly be designed so that addition of those features later
can be made without restructuring the server program.

[...]

Alaric B. Williams

unread,

Apr 22, 1997, 3:00:00 AM4/22/97

On 22 Apr 1997 09:56:52 -0400, br...@alpha.hcst.com (Bryan Murphy)
wrote:

>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.

Oh, /yes/! I've a friend who's been moaning for such a game for YEARS!

> I'm not trying for state of the art graphics,
>though they would be nice, I just want functional.

Agreed. Our plans were for simple graphics over a very playable core.
Graphics are nice, but modern 3D texture mapped graphics are usually
at the expense of something else!

> Hopefully this will serve two purposes, a fun atmosphere
>for blasting your friends out of the galaxy, and for some exploration and
>experimentation.

Those are our goals, too :-)

> 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).

Our slant was more on large scale tactical control with a turn based
system. Due to the limitations of mice and monitors, we'd decided to
stick to 2D; the only advantage in using 3D would be scientific
realism, at the cost of usability.

Anyway, we decided to use long long ints as a coordinate system
measuring metres, to create a fine-grained universe of about 1,000,000
cubic light years. All objects are modelled as circles; they have
bitmaps, which are used if they would cover more than a few pixels,
otherwise a non-scaling symbol is used (you have completely smooth
zoom, you see). Laser-type weapons firing was instantenous, but
missiles and railgun rounds were tracked as objects. Everything
exerted gravity due to mass; the play was turn based, clicking on
ships to get status displays, and to edit their order lists (go to X,
chase Y, etc). The orders covered motion or focussing all attacking
strength on specific targets; most combat consists of telling your
ships to shoot on sight, or shoot when shot upon, and then telling
them to go into orbit around the enemy homeworld.

The computer controls the ships, which have real momentum. Thrusters
generate impulse; hyperdrives directly convert electrical energy
to/from kinetic energy, for instantenous acceleration!

There are also jump drives, which simply translate linearly (without
moving accross the intervening space), but which have time distortion
effects (the ship arrives at the target a few seconds later, but weeks
worth of supplies get used up :-)

The momentum thing is there just so ships follow realistic
trajectories, have to steer clear of black holes, etc.

ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."

(Windows for Early Warning and Defence User's manual P26)

Alaric B. Williams Internet : ala...@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

Keith M. Lucas

unread,

Apr 23, 1997, 3:00:00 AM4/23/97

In article <5jig34$pu9$1...@alpha.hcst.com>,

Bryan Murphy <br...@alpha.hcst.com> wrote:
>
>---------------------------------------------------------------------
>
>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!
>
>---------------------------------------------------------------------

OK -- I'll give you my experience on this -- we developed our own X11
GUI library ( since none of the others suited our purposes ).

Like you we start with a base object but we have a none OO kernel that
underlies it -- this is what gets X11 messages from X11 and turns them
into our messages ( this bit would be re-written for Windows ). One of
the things it does is run timers ( so objects can have a TICK event
called, without using system resources ) and examine file descriptors
( so objects can respond to file events. ) -- the sockets arrive as
FDs so basically, we have a TSpace in which hang a bundle of TInstance
objects which have pointers to a TPolyMesh. So incoming packets from a
socket kick an event on a TClient which modifies the data in the
TSpace/TInstance. There is also a TCamera which knows where it is in
the space and gets TICK events -- on each TICK it renders its current
view of the window to a bitmap and then asks the TWindow to display
the bitmap.

Useful hint here, ripped off from Delphi. Make your base object have a
list and able to insert itself into lists and so on. That way your
TWindow object simply has a list of all the TWindows and TControls (
TButton etc ) that live inside it.. give the base object a render()
method and all of a sudden drawing a window is easy and it saves you
constantly using list objects and so on.

( Actually there is a chance that we'll be making the code for out
stuff available in the near future.. it should port to Windows very
easily ( the X11 code is hidden away ) )

>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.

>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).

In our system the TCamera is the only one that knows anything about
the graphics. It uses a support object ( a TView ) that works at the
level of "a pointer to a bitmap and its size" and methods like
"texture_polygon()" and "flat_polygon()"

----------------------------------------------+--------------------------------
"It's not a personality.. it's a bulldozer" | Current project: Computer
sillywiz at excession dot demon dot co dot uk | wargaming's next generation...
----------------------------------------------+--------------------------------
IQ test in my email address. Humans can solve it to reply, spambots can't (yet)
----------------------------------------+--------------------------------------
For best results, view this with Linux. | Support death penalty for spammers !
----------------------------------------+--------------------------------------

0 new messages