How do the parts of your game data relate to each other? In this
independent technical article, originally published in Game Developer magazine and posted online as part of Intel's Visual Computing section, game development veteran Noel Llopis looks at how coders should structure and retrieve the intertwined world of game data in memory.
Each approach to describing relationships between different data parts has advantages and disadvantages, writes Llopis, and finding the right method for the job is important.
For example:
"In C++, regular pointers (as opposed to "smart pointers," which we'll discuss later on) are the easiest and most straightforward way to refer to other data. Following a pointer is a very fast operation, and pointers are strongly typed, so it's always clear what type of data they're pointing to.
However, they have their share of shortcomings. The biggest drawback is that a pointer is just the memory address where the data happens to be located. We often have no control over that location, so pointer values usually change from run to run. This means if we attempt to save a game checkpoint which contains a pointer to other parts of the data, the pointer value will be incorrect when we restore it."
One way to get around this limitation is through the use of indexing, but even that's not a perfect solution:
"Unfortunately, they still suffer from the same problem as pointers of being strictly a many-to-one relationship and making it difficult to relocate or delete the data pointed to by the index. Additionally, arrays can only be used to store data of the same type (or different types but of the same size with some extra trickery on our part), which might be too restrictive for some uses.
A good use of indices into an array would be particle system descriptions. The game can create instances of particle systems by referring to their description by index into that array. On the other hand, the particle system instances themselves would not be a good candidate to refer to with indices because their lifetimes vary considerably and they will be constantly created and destroyed."
You can
now read the full technical feature at Gamasutra (no registration required, please feel free to link to this feature from other websites).
