• ### Popular Now

• 15
• 15
• 11
• 9
• 10

#### Archived

This topic is now archived and is closed to further replies.

# Relationship Driven Engine

This topic is 5458 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
Ok, I have some relational database development experience, so I think I understand you, but I''m not sure. I don''t see any benefits to the approach you suggest, especially since a pointer in C can be considered a relation of sorts anyway. I don''t see how it makes it easier to update object states either. The relation between the ship and missile would be implicit in most C implementations, but still there. I think one major reason why having some sort of explcit relationship isn''t done, is because it''s rarely needed. It''s pretty simple to add a ''SourceShip'' pointer to a Missile object to show where a missile came from, for instance. This is not going to be significantly harder than having a relationship variable somewhere.

Regarding MMORPGs - from what I know from reading comments made by MMORPG developers, they don''t use databases for the benefits of the relational model, they use it as a robust and reliable form of persistence for massive amounts of data. It gets converted to ''traditional'' data structures once loaded into memory.

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

##### Share on other sites
Recently I was thinking about storing information about game objects and also came to (theoretical) conclusion that many of such information could be stored in relational tables.

For example, if there are 3 types of spaceships and each has associated missile type that it can launch. The C approach would be something like:

  // spaceship types (missiles are considered to by spaceships)enum ShipType{	SHIP_TYPE_1,	SHIP_TYPE_2,	SHIP_TYPE_3,	MISSILE_TYPE_1,	MISSILE_TYPE_2,	MISSILE_TYPE_3	NULL_SHIP,};// struct ShipInfo{	float radius;	float mass;	ShipType missileType; // associated missile type};// info about all ships and missilesShipInfo shipInfos[NUM_SHIP_TYPES] = {	10.0, 3.0, MISSILE_TYPE_1, // ships of type SHIP_TYPE_1 fire missiles of type MISSILE_TYPE_1	12.0, 5.0, MISSILE_TYPE_2, // and so on...	15.0, 8.0, MISSILE_TYPE_3	3.0, 1.0, NULL_SHIP, // missiles cannot fire missiles	4.0, 2.0, NULL_SHIP,	5.5, 4.0, NULL_SHIP};

To find out what missile a particular spaceship should fire, you could write:
ShipType missileType = shipInfos[ship->type].missileType;

However the same information can be stored in relational form:

  struct ShipInfo{	ShipType shipType;	float radius,	float mass};//ShipInfo shipInfos[NUM_SHIP_TYPES] = {	SHIP_TYPE_1, 10.0, 3.0,	SHIP_TYPE_3, 15.0, 8.0, // can store in any order	SHIP_TYPE_2, 12.0, 5.0};//struct MissileInfo{	ShipType shipType;	ShipType missileType;};//MissileInfo missileInfos[NUM_MISSILE_TYPES] ={	SHIP_TYPE_3, MISSILE_TYPE_3, // again, order is not important	SHIP_TYPE_2, MISSILE_TYPE_2,	SHIP_TYPE_1, MISSILE_TYPE_1};////Now we can write:MissileInfo *getMissileFromShip(ShipType shipType){	MissileInfo *info = 0;	int i;	for(i = 0; i < NUM_MISSILE_TYPES; i++)		if(missileInfos[i].shipType == shipType)		{			info = &missileInfos[i];			break;		}	return info;}//// and//MissileInfo *info = getMissileFromShip(ship->type);ShipType missileType = info->missileType;

Notice that now it's easy to find the ship type from the missile type it can fire.

Or, for example, in a RPG we could make a table defining the results of applying one object to another:

  struct Action{	ObjectType object1;	ObjectType object2;	ObjectType result;	char *message;};Action actions[] = {	PIZZA_BASE, TOMATO, INCOMPLETE_PIZZA, "You add tomato to pizza",	PIZZA_BASE, CHEESE, NOTHING, "You should add tomato first",	INCOMPLETE_PIZZA, CHEESE, UNCOOKED_PIZZA, "You add cheese to pizza"};

I typed it all in about 10 minutes, it must be full of bugs and mistakes.

[edited by - Advanced Bug on April 2, 2003 7:27:45 AM]

##### Share on other sites
As far as I know, relational algebra is complete, so any kind of data can be stored in it. The only question is - why bother? Standard databases are designed to solve different problems to game programs. And I wouldn''t agree that the second example below is an improvement on the first.

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

##### Share on other sites

First, whether to store all information in one big array or multiple small arrays (for example, when you need to associate some additional information only with a small subset of all data, for example, only spaceships can fire missiles, so you can create additional table with records only for spaceship types, to associate them with missile types).

Second, how to express many-to-many relationship (for example, after killing a monster of type MONSTER_TYPE_1, it will always drop an iron sword, monster of type MONSTER_TYPE_2 will drop either iron sword or steel dagger, monster of type MONSTER_TYPE_3 can drop steel sword, 50 coins, iron helmet or a gold bar. How to store this information?)

Third, how to find the right array elements. The easy and fast method is to use pointers or integer indices, but, in my opinion, it''s quite error prone. Accessing the array elements based on some key field IMO would increase the robustness of the program (at the expense of speed, of course).

On the other hand, there can be many different approaches to storing such information (especially in dynamically typed languages). At the same time, relational tables are very easy to implement (and initialize) in C as arrays of structures.

Also, all my examples are about storing static data (describing object types, not actual objects themselves) that doesn''t change during program execution. I''m not sure whether runtime data can be stored in relational form.

Conclusions: relational tables are easy to implement, they are robust, and it''s easy to add and change the information. At the same time they can be much slower than other data structures.

##### Share on other sites
quote:
Original post by Kylotan
As far as I know, relational algebra is complete, so any kind of data can be stored in it. The only question is - why bother? Standard databases are designed to solve different problems to game programs. And I wouldn't agree that the second example below is an improvement on the first.

And not in so much as being just about no different in implementation, the second code is now LOCKED (i.e. what relational databases do to verify integrity of data) to the implemented relations. So you have now basically capped any emergent behavior this engine could produce, which IMHO, is entirely counterproductive to AI development.

"Five passengers set sail that day, for a three hour tour, a three hour tour...."

[edited by - joviex on April 3, 2003 4:40:13 AM]

##### Share on other sites
Joviex- it''s true that it is locked. I was hoping on getting ideas for a dynamically changing relationship.

It seems that most advances in software engineering design (which I also consider games to be a vital part of) come from a total change in direction of thinking. Why should we always approach game design as being just object oriented (or as 10 years before that, completely procedural oriented)?

Kylotan said that pointers in C are sort-of relational in uses. But just because it so happens to turn out that way, doesn''t mean it is. What would happen if we took a totally look at game design as being based conceptually from the beginning as relational, and not just an after-thought of "oh neat, that looks like relational programming."

I think games would be more complex and less static feeling, and that many areas of games (not just MMORPG''s) would greatly benefit.

For example in many games that claim to have "realistic" enviorments and such, are just nothing more than cool, but limited, interactions that a programmer put in. If we used dynamically changing relationships in data, we could create completely realistic interactions, and not just designs that are "locked".

So- how do we go about doing this? Is there langauges being developed with this in mind? Can we possibly use the last 100 years of science (like the theory of relativity?), besides just for cool effects? How about if we designed game engines to dynamically change from the beginning? Delevopers could technically create add-ons that don''t just add more of the same game on, but more interactions that make the game more fun. I believe that MODs in game are great, and that games like quake, half-life, etc, allow us to completely change the look and feel of the game, but they don''t necessarilly allow us to changing the core, because the core is "static".

Thoughts?

-Pac
"The thing I like about friends in my classes is that they can''t access my private members directly."
"When listening to some one tell about their problem (whether it''s code or not), don''t listen to what went right or wrong, but what they assumed....."

##### Share on other sites
I am thinking AI. We need to take the static, or, stupid, out of engines.

Even with a relational DB it will only ever contain the data (static) you put in.

Now, do something along the lines of making the data mutate and also mutate how the engine can deal with this (along the lines of NN trees with GA searches mayhaps), now you are talking interaction, feedback and use of data in a way that was perhaps never thought or intended.

Granted, 90% will prolly be junk spit back at you. Its the 10% that would make for some interesting new directions/breakthroughs in future engine creation.

"Five passengers set sail that day, for a three hour tour, a three hour tour...."

##### Share on other sites
quote:
Original post by Pactuul
What would happen if we took a totally look at game design as being based conceptually from the beginning as relational, and not just an after-thought of "oh neat, that looks like relational programming."

I think games would be more complex and less static feeling, and that many areas of games (not just MMORPG''s) would greatly benefit.

This is the kind of thing I would expect to hear from someone who was trying to sell me a relational database product

quote:
For example in many games that claim to have "realistic" enviorments and such, are just nothing more than cool, but limited, interactions that a programmer put in. If we used dynamically changing relationships in data, we could create completely realistic interactions, and not just designs that are "locked".

It''s easy to make things ''data-driven'' and you don''t need ''relations'' in the database sense to do so. So I''m still not seeing your point

quote:
I believe that MODs in game are great, and that games like quake, half-life, etc, allow us to completely change the look and feel of the game, but they don''t necessarilly allow us to changing the core, because the core is "static".

What do you call ''the core''? Tried any of the Unreal games, or Neverwinter Nights? Or LPMuds, which are almost entirely scripted, allowing you to edit the code from within the game itself? In those games, if you want to change the combat formula so that goblins called Herman always hit for 234 damage when wielding a broom and carrying a bottle, you can do that, theoretically while the combat is ongoing.

I''m not trying to bash your idea, but I am interested in hearing some concrete benefits that the relational model would have over any number of other data-driven approaches we can (and do) already employ in games. I think some real examples would help drive the discussion. Perhaps if I answered some of your questions explicitly, you can work from there:

- Can we feasibly develop relations between all objects, as they do in databases and AI? : I expect it''s feasible, except for the inconvenience of interfacing 2 different paradigms (and probably languages) together.

- would these relations between all objects make it easier to update object states : No, I can''t see that it would. You''d just be updating 2 fields in a table containing the relationship, instead of updating 1 field on each of 2 sides of the relationship.

- and allow for more complex interactions? : Not really; it takes no more effort to add a ''Ship* firedBy'' member and a couple of accessor/mutator functions to a missile class than it would to add a relationship variable to the missile or a separate table of "missileID/relationship/otherObjectID" relations for missiles. Do you see a 3rd approach?

- If these relations could be automatically added (as AI-techniques would dictate), how would we know they have been added? : They have to be added by code, or implemented in terms of other relations which would make them deducible according to predicate logic. (eg. You could define a GrandParentOf(x, y) in terms of ParentOf. Sadly I don''t remember predicate logic well enough to give you the proper syntax.) When it comes down to it though, the relations end up needing to hook onto code that does something, so you don''t gain much.

- How do we store these relations? : As text in a table, if you''re using logic to evaluate them all. Eventually they will have to resolve down to the lowest-level relations, which must be attached to some sort of code.

- Would this structure benfit us by allowing us to store the data in relationship form, for easy retrieval and allow us to use conceptual and syntax correct techinques? : If you''re saying that SQL is ''easy retrieval'', then I''d have to disagree. SQL makes it easier to get quite complex queries out, but from my game programming experience, you rarely need very complex queries.

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

##### Share on other sites

Well I''m not trying to sell ya , but if you wanna buy....

My main point is that I think that if we as industry re-think our practices and paradigms, that we could quite well reach a new step in programming.

Most of us are very fimiliar with Object-oriented and function paradigms. Is there a relational paradigm or something similiar being worked on?

quote:
Original post by Kylotan
- Can we feasibly develop relations between all objects, as they do in databases and AI? : I expect it''s feasible, except for the inconvenience of interfacing 2 different paradigms (and probably languages) together.

- would these relations between all objects make it easier to update object states : No, I can''t see that it would. You''d just be updating 2 fields in a table containing the relationship, instead of updating 1 field on each of 2 sides of the relationship.

- and allow for more complex interactions? : Not really; it takes no more effort to add a ''Ship* firedBy'' member and a couple of accessor/mutator functions to a missile class than it would to add a relationship variable to the missile or a separate table of "missileID/relationship/otherObjectID" relations for missiles. Do you see a 3rd approach?

Those are all very true, but I think all these answers are limited by our current programming practices. My point is that we should change this. I picked a relational approach, because I think that''s the next most natural step in our thinking. The point of these posts (for me at least) is for a discussion on this, and if this something to go to, then what problems/benefits arise.

From what i''m fimiliar with lisp programming and AI pratices, I think they are taking a good approach. They use pathfinding, npc responses, etc, which are based on weights and relations between objects. I suggest that we try approaching programming that way too. If we delevop a new language and pratice, we could make a paradigm that solves this problem.

The big question is why is this necessary? Are there problems that could be solved using this? It''s very hard (for me at least) to come up with a good problem that could be solved using just relations between objects (as a note "objects" are not necessarily what we think of as physical entities, but also abstract entities).

This new language, would, for one, eliminate the need for massive amounts of data being needed to substain the relationships, as it is a problem in database design with just "static" data.

Second, it would should/could be able to maintain relations without the need for underlying code. In other words, the problem about having relations is based on the computer not being able to "code" or "rewrite" functional code on the fly, without it strictly being told what to do.

-Pac
"The thing I like about friends in my classes is that they can''t access my private members directly."
"When listening to some one tell about their problem (whether it''s code or not), don''t listen to what went right or wrong, but what they assumed....."