#ActualNorman Barrows

There's a major difference between live data (in RAM, workable) and storage data

as you can see in the updated diagram. the "databases" are only that data currently in ram or on the video card. not stuff on the hard drive, or received via network, etc.

sorry for the confusion!

a single "databases" block while there are clearly different databases involved

obviously - or at least i thought it was obvious. <g>. lack of precision - my bad!

yes, the "game data" represents multiple data structures of different types, holding different types of data.

here's what the list might look like for CAVEMAN:

* a list of active players (like an entities list, but for multiple player characters).

* an entities list (vector, list, component-entity system, etc).

* a list of world objects (basically static entities like dropped inventory items)

* the world map data structure

* a list of known npc's and their data.

( CAVEMAN generates npc's on the fly, so it only needs to track npc's you've met. a game like Oblivion would have a large "database" of NPC's, although the data might be split up between many levels or cells. in such a case, the equivalent would be the npc's active in the currently loaded level / cell / area. )

* entity type definitions

* object type definitions

* action type definitions

* skill type definitions

plus others that don't come to mind.

The point is that you have "blobs" of data which you don't modify directly but use specific functions instead. In many OOP languages, the functions are "near" the data they manipulate. But they don't have to be! OOP is possible in C and even ASM.

yes. this is what i do now. basically ADT's in C.

you'll be able to fit classes to what your program really does

over the years, i've noticed that what most games "really do" is something similar to the above diagram.

i suspect that the layout as presented is still too high level, and lacks sufficient detail to elicit responses on implementation recommendations for different parts.

i should probably take it one unit at at time.

i'll reformulate my question to be multiple specific implementation questions, instead of "so what would be some cool classes for this architecture?" <g>.

please stay tuned, as i was hoping you guys would chime in with some advise.

#1Norman Barrows

Posted 26 August 2013 - 12:31 PM

There's a major difference between live data (in RAM, workable) and storage data

as you can see in the updated diagram. the "databases" are only that data currently in ram or on the video card. not stuff on the hard drive, or received via network, etc.

sorry for the confusion!

a single "databases" block while there are clearly different databases involved

obviously - or at least i thought it was obvious. <g>. lack of precision - my bad!

yes, the "game data" represents multiple data structures of different type, holding different types of data.

here's what the list might look like for CAVEMAN:

* a list of active players (like an entities list, but for multiple player characters).

* an entities list (vector, list, component-entity system, etc).

* a list of world objects (basically static entities like dropped inventory items)

* the world map data structure

* a list of known npc's and their data.

( CAVEMAN generates npc's on the fly, so it only needs to track npc's you've met. a game like Oblivion would have a large "database" of NPC's, although the data might be split up between many levels or cells. in such a case, the equivalent would be the npc's active in the currently loaded level / cell / area. )

* entity type definitions

* object type definitions

* action type definitions

* skill type definitions

plus others that don't come to mind.

The point is that you have "blobs" of data which you don't modify directly but use specific functions instead. In many OOP languages, the functions are "near" the data they manipulate. But they don't have to be! OOP is possible in C and even ASM.

yes. this is what i do now. basically ADT's in C.

you'll be able to fit classes to what your program really does

over the years, i've noticed that what most games "really do" is something similar to the above diagram.

i suspect that the layout as presented is still too high level, and lacks sufficient detail to elicit responses on implementation recommendations for different parts.

i should probably take it one unit at at time.

i'll reformulate my question to be multiple specific implementation questions, instead of "so what would be some cool classes for this architecture?" <g>.

please stay tuned, as i was hoping you guys would chime in with some advise.