Game Development Community

Inside Look: Derivitive Data Structures

by Christopher Dapo · in Game Design and Creative Issues · 08/06/2005 (8:22 am) · 2 replies

Welcome to an explanation of Derivitive Data Structures.

Derivitive Data Structuring (DDS) works by assigning values to parent values for extended data usage throughout a game architecture. This allows for faster access to data contained and extended variations and associations with that data. The system itself it based off of a tree of data references based on absolute values of data, whereby the system resources need but to look at the parent and decend to the data it wishes to access instead of processing it in it's entirety.

The results of using DDS:
- Unlimited LOD
- Universal Usage System
- On Demand Data Referencing
- Unlimited Game Object Manipulation
- Superior Editing Capabilities

Basics of using DDS:
All game object referances are based from a common parent reference, which is best done using location within the game world.
Our DDS Base == worldSurface
From here, we can extend the parent's paramaters to provide exact location and current state:
worldSurface <- trueSurface(position_x,position_y,position_z,state)
The <- denotes the data on the right being associated with it's parent data on the left. Similar to the above, we can also add support for multiple planes of origin, again from the same parent:
worldSurface <- liquidSurface(x,y,z,state)
worldSurface <- airSurface(x,y,z,state)
For deeper association between planes, as well as extended referancing capabilities, we can also add a general area value:
(area,x,y,z,state)
Now we currently have our planes defined to accomidate ground surfaces, water surfaces, and air positionings. When we make the call to check planes, we find all three in detail:
worldSurface(currentArea)
 -> trueSurface(currentArea,1,1,1,"")
 -> liquidSurface(currentArea,1,1,1,"")
 -> airSurface(currentArea,1,1,1,"")
As we see, they not only parent from worldSurface, but also share the same area. The locations have yet to be defined, same with the state.

Next, we will look into our next parent group - Objects.
NextNext Thread
PrevPrevious Thread
More from Game Design and Creative Issues


Torque Owner Christopher Dapo
#1
08/06/2005 (9:05 am)
The Object parent group comes directly in referance to the worldSurface group. Hence, every object within our game world resides at a location.
worldSurface <- trueSurface <- objectLocation(x,y,z,state)
Notice we always have a state value signified. This allows us to develop the level of detail with any referance to an extent limited only by what we wish to add.

For instance, the following object is referancing a falling pot:
worldSurface(cityA,1,1,1)
  <- trueSurface(cityA,1,1,1,"")
  <- airSurface(cityA,1,30,1,objectEvent)
    <- objectLocation(1,30,1,fallingAction)
      <- object(pot)
Breaking down the above, we have:

worldSurface (our main parent) (cityA (our current area), 1,1,1 (our current exact location))
trueSurface (our parent ground surface) (cityA (again, current area),1,1,1 (exact location on the surface),"" (undefined state))
airSurface (parented from trueSurface) (cityA (again, current area),1,30,1 (exact location in the air), objectEvent (an event involving an object in this location))
objectLocation (parented from airSurface) (1,30,1 (exact location of the object),fallingAction (the current state of the object))
object(pot) (the pot object in short detail)

The "30" referances the pot object's location in the air. Note that there is no liquidSurface, hence no body of water at this location.

Let's introduce our third parenting referance, Characters, into the above example:
worldSurface(cityA,1,1,1)
  <- trueSurface(cityA,1,1,1,charEvent)
    <- charLocation(cityA,1,1,1,standingAction)
      <- character(man)
  <- airSurface(cityA,1,25,1,objectEvent)
    <- objectLocation(1,25,1,fallingAction)
      <- object(pot)
We see now that trueSurface's state has changed due to character involvement. Let's see what happens...

Torque Owner Christopher Dapo
#2
08/06/2005 (10:03 am) 
<- airSurface(cityA,1,10,1,objectEvent)
    <- objectLocation(1,10,1,fallingAction)
      <- object(pot)
Now, we require two new sub-surfaces:
worldSurface(cityA,1,1,1)
  <- trueSurface(cityA,1,1,1,objectEvent,charEvent)
    <- aboveSurface(1,10,1,objectEvent)
      <- objectLocation(1,10,1,fallingAction)
        <- object(pot)
    <- charLocation(cityA,1,1,1,standingAction)
      <- character(man)
  <- airSurface(cityA,1,1,1,objectEvent)
    <- lowerAir(1,10,1,objectEvent)
      <- objectLocation(1,10,1,objectFalling)
        <- object(pot)

The two added planes - aboveSurface and lowerAir - act as a connection point between the two planes trueSurface and airSurface, respectively. This allows us to interperit this information to characters and objects between both planes. The aboveSurface can represent objects leaving the trueSurface or falling to it. The lowerAir can represent objects moving in and out of airSurface. Objects which reside in either are represented as within either parent at that time.

If we continued with this example:
worldSurface(cityA,1,1,1)
  <- trueSurface(cityA,1,1,1,objectEvent,charEvent,collisionEvent)
    <- aboveSurface(1,2,1,objectEvent,collisionEvent)
      <- objectLocation(1,2,1,breakingAction)
        <-object(pot,breakingAction)
          <-collision(1,2,1,man,1,1,1)
    <- charLocation(cityA,1,1,1,koAction)
      <- character(man,koAction)
        <- collision(1,1,1,pot,1,2,1)
  <- airSurface(cityA,1,2,1)
    <- lowerAir(1,2,1,objectEvent,collisionEvent)
      <- objectLocation(1,2,1,breakingAction)
        <- object(pot,breakingAction)
          <- collision(1,2,1,man,1,1,1)
...Our character (man) would be knocked out by the falling object (pot)! That could hurt! Why don't we help him out a bit in our next post! ;)