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 Precedence: bulk --------------------------------------------------------------------- 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/