what would be the C++/OOP way to implement this architecture ?
audio would play music and sound effects stored in the databases. it would be told what to play and when by the simulator.
input would get input from the keyboard, mouse, and other input devices, and send it to the simulator as needed/requested.
video would produce everything seen on the screen, as directed by the simulator. so it would include the renderer and gui components.
the databases would store all the game info. meshes, textures, materials, models, animations, sfx, music, the world map, the entities list, databases of entity types, object types, etc. databases would be of 3 basic types: static databases would not change during one run of the game/level/mission. they would be read only - a database of target types for example. dynamic databases would be expected to change every frame. an entities list would be an example of this. semi-static databases might change, but usually not every frame. a list of dropped objects, or a changeable world map might be examples of this. other game specific databases might also be used. for example, CAVEMAN has action type and skill type databases.
the simulator would run the show. it would contain the main game loop. it would receive input and process it, updating databases as needed. it would perform all the update functions (IE run the game for one "frame" or "turn") or dispatch commands to the appropriate databases to update their contents. It would also dispatch commands and parameters to the audio and video units to do sound, music, and to render the screen. So its largely a controlling unit.
needless to say, this diagram is high level in the extreme, and each unit in it would in turn be composed of a number of sub units.
i'm pretty familiar with the non OO way this would be done, basically a bunch of adt APIs. but i was wondering what form a c++/oo implementation might take.
so before / while i start to slice this thing into classes and such, i thought i might get some suggestions from folks who do this everyday.
my natural approach would be to simply convert ADTs to classes. but i'm not sure if this would be considered the "usual" way to slice things or not.
for example, the entities list:
apparently in C++/OO, its common to implement an entities list as some sort of array or linked list of pointers to objects, where each object contains the info for one entity. furthermore, its also apparently common to create and destroy entity objects on the fly as needed.
in the non-OO world, this is a flat file database. a simple array of structs, nothing more. anyone who implemented an array of structs as a linked list of pointers to structs allocated on the heap would be thought to be "odd" at the least, if not "crazy".
so converting an entities list ADT to a C++/OO entities list in a straight forward manner, one would get and array of structs data structure with methods that operated on structs. the entire array would be one object. there would be an entitylist class, with a single instance, one entity list object.
but this doesn't seem to be the usual way its done in OO/C++.
i'm sure there are other places where this situation arises as well. I think it stems from the OO vs non-OO way of looking at data. Apparently, in OO, it not uncommon to take "everything is an object" literally, and to the extreme. To the point where individual records in a database become objects, and perhaps even fields in those records. The result would/could/might be a proliferating tree of objects on the heap. Add in creating and destroying objects on the fly, and you have a constantly changing giant rats-nest tree of objects possibly/probably fragmenting the heap.
i'm thinking there's a way to slice things in an OO/C++ style with out the usual difficulties encountered, perhaps by using objects primarily as higher level modules / units.
