All, I am looking to get into game development and had a few questions. My primary interest is map based, coming from a GIS major, and I am assuming that maps and building/POI objects are starting to become more and more database driven, so I would be able to use some of my DBA experience in this. From what I am seeing, digital cities, “real” maps, and a lot of the 3-D representation of real road and building attributes are really starting to play big into a lot of games, as they are starting to advertise real cities more and more rather than ficticious planets etc. . (Did I hear correctly that Bizarre Creations spent 1000 hours just filming the roads and buildings in Project Gotham?) Given this, can anyone point me toward information where I might be ale to learn about how games are presenting spatial data from a relational database rather than the original the WarCraft 2-D style concept of pictures overlaid on a tile with X/Y attributes? Thank you MVShogun

No; but, to be honest, when I studied GIS at college I saw just how horribly redundant their data structures were compared to most 3D formats, even if the 3D formats were stored as text. For this reason, I doubt anyone is going to move to a relational format for storing 3D objects and meshes. The relational system is well-suited to data mining but it''s not too quick or compact.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost

Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Fair enough. So forgive the ignorance, as I am a newbie to this particular area, but how are developers storing map related data for games such as GTA? I wouldnt imagine that a game like that is simply a bitmap overlaid on some topo data with X/Y Co-Ords placing the buildings? Or am I waaay off base here.

Thanx
MVShogun

This is a huge oversimplification, but a model would tend to be basically described in terms of 3D vertices, and triangles comprising 3 of those vertices. Each of these triangles will have some sort of material or texture ID, dictating which graphic to display upon it, and each vertex will contain a 2D ''UV'' coordinate specifying a position within the texture or material.

Each model will have a 3D position in world space and that will be applied as a transform to each model''s vertices in order to calculate the world-coordinates. This allows a single model ''prototype'' to be re-used at several points within the world, rather than having to explicitly store all the vertex data for each and every one. So yes, there may well be just X/Y coordinates for the individual building instances, at the storage level.

From this data, triangles with world-coordinates can be sent to the graphics card complete with texturing information.

I doubt any of this would ever be stored in a relational database, although you could certainly do so if you wished - it just wouldn''t be quick enough to access in-game. You might do it with an intermediate caching layer, but you wouldn''t really gain much from it.

Instead there are proprietary formats, customised to suit the particular feature you''re modelling. For example, within a single game, it might be common to store the ground as a heightmap (eg. raster data, a 2D array of Z-coordinates) but to store obstacles as vector data (as described above).

You might want to take a look at the MD2 format as one example of how model data is stored in Quake 2 and similar games.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost

Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

I understand that you essentially have polygons defined by vertices, and that each polygon has its own representation. The question I have is how are attributes associated across multiple polygons? A river or a road will be presented as multiple pieces rather than one large piece for memory purposes, but how are the attributes applied to that entity propagated to all of its sub-polygons or instances?



The example would be navigating down a river. Each portrayed piece of that river would have the same attributes such as maximum character speed, direction of water flow etc.



How is this stored behind the visual representation?


[edited by - bulldog232 on March 20, 2003 5:44:43 PM]

Yes, this is similar to what I am looking for. The texturing representation I understand. What I am rather fuzzy on is how the physical attributes of each polygon, model, or entity is stored for interaction with the game. A road will have attributes that make a character travel at certain speeds, or the suspension of a car react a certain way... How is that information stored across the entire road.

Bump...bump

This seemed like a pretty interesting topic. Well, at least it caught my attention.

Anyone have any thoughts on it?

"How is this stored behind the visual representation?"

instead of importing raw triangle data into your game, you add some space for flags to your triangle/polygon structure which the user of your game-editor can change just like he/she assigns a texture to it.

struct Triangle
{
Vertex v[3];
unsigned long textureID;
unsigned long flags;
};

#define FLAG_ASPHALT 0x1
#define FLAG_DIRT 0x2
#define FLAG_LAVA 0x4
#define FLAG_WATER 0x8

then in the game when you check your character for collisions against the game world, you look at the flags of the triangle(s) under the player and for example slow the players'' vehicle down or kill the player or whatever.

of course this was a very simple example, but i hope you get the idea. i suggest go play with some editors like Unreal,Quake,Halflife to learn about nice things like zones/brushes and how the game engine interprets the data you created.

quote:Original post by MVShogun
Yes, this is similar to what I am looking for. The texturing representation I understand. What I am rather fuzzy on is how the physical attributes of each polygon, model, or entity is stored for interaction with the game. A road will have attributes that make a character travel at certain speeds, or the suspension of a car react a certain way... How is that information stored across the entire road.

It would be nice to say that there''s a standard procedure or method for doing this, but it differs for every piece of software. Most of the time, you''ll store it directly with the structure in memory, as Morebeer has shown. Often the graphical side of things (ie. all the polygon data) would be totally separate from game-entity data, like so:

class Road{    vector<models> polygonData;    int travelSpeed;}; 

So you have a one-to-many relationship between Roads and models. (Perhaps. Some engines might do a road as one big model. The fact that there are so many possible implementations in game development makes any blanket statement wrong.) In order to access one of those models, you must have already traversed to this Road object, and therefore the travelSpeed is readily accessible.

To go back to the original question, the main difference between a game''s database and a relational database is that games store one-to-many relationships via container classes and pointers rather than using any kind of ID or key. This is especially true when dealing with low level graphical data, and not necessarily true for high level constructs. Apart from that, the concept is the same - normalise data as much as you can to avoid redundancy. You still essentially have the same one-to-many relationships between different data entities, but rather than store them in separate tables, you tend to have the ''many'' part of the relationship owned by the structure or class that constitutes the ''one'' part. How the developer chooses to save this to disk varies, but you can bet it''s not going to be in a relational database except in the massive online games

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]