Back to General and Gameplay Programming

what's the C++/OOP way to implement this architecture ?

Norman Barrows · 2013-08-30T01:36:07

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.

General and Gameplay Programming Programming

Started by Norman Barrows August 25, 2013 06:16 PM

20 comments, last by Norman Barrows 10 years, 7 months ago

Norman Barrows

7,180

Author

August 30, 2013 01:09 AM

Going defensive much?
You don't need to.
I think you should start writing something (regarding this) if you haven't already.

defensive, hardly! guess i misunderstood. writing code? or something like a blog entry?

that was just an example of the code i've written or am writing that i'm basing my observations on.

i already have pretty much all the bits and pieces for a "game engine architecture" sitting here on my hard drive, either in libraries, or as modules in game projects. but the "gestalt" of the the design has yet to fully coalesce.

its like peering through an out-of focus telescope. at first the image is general and indistinct - like the first diagram. what you're witnessing in this thread here is the slow focusing of the telescope to bring the design into clear, sharp view.

as usual, as with many of my "questions", the overall discussion is spread throughout a number of related threads, and spawned some interesting discussion.

i plan to cross link the threads for the convenience of all.

in this particular thread, at this particular time, the most helpful thing would be if someone could take a look at the snippet i posted, and tell me the c++ way to get rid of the global reference to texture[texID].

as an aside, i had another interesting insight / discovery / pattern (dare i use the term?) that i noticed, similar t the link from animation player to audio:

you can't move a ground target in a generic game engine - even given all the 3d Newtonian kinematics data required - without game specific heightmap data to set the target's new "altitude" after moving. i discovered this while turning off callbacks in the library version of the target list / game engine.

perhaps a bit tangent to the topic, but: what does everyone out there think of callbacks? like? hate? necessary evil?

i've got the engine api down to two calls:

void Zmain(Hinstance); and void Zrungame();

and about a dozen callback routines, almost half of which are empty hooks for the user' convenience, and only the remaining ones actually require any user implementation.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php