Game structure question: Entity interaction

[justkevin]

I'm working on the core engine for a new top-down 2d game. The basic structure is this:

This is not a question about hit testing, but rather how to handle the questions "Can object X interact with object Y" and "What happens?"

Some solutions I've thought of:

1. Object X uses a switch or if statements based on a property of Object Y to determine what methods if any to call.

2. Object X uses a switch or if statements based on Object Y's interfaces to determine what methods if any to call.

3. Object X uses an integer bit mask on Object Y's integer bit mask, which determines what interactions occur using a look up table. E.g., 10001101 and 10100001 interact on bits 1 and 8.

4. A single, static "Interactor" class handles the interaction.

Concerns and goals are:
1.) Extensible. If I think of a new type of interaction later on, how easy will it be to add? Will it be possible to define a new interaction without changing the code at all?
2.) Performance. If two entities don't interact at all, how can I quickly figure that out?

Just looking for ideas or solutions I haven't thought of.

[newblack]

interesting question!

i like the bit mask approach. perhaps paired with some sort of command-ish structure where the execute method gets passed Object X and Object Y.

public interface ICommand
{
    function execute( obj1:GameObject, obj2:GameObject ) : void;
}

each on bit index maps to either an instance of an ICommand implementer or the implementing class itself. that should keep your code modular and abstracted from whatever deems the objects as interacting, and which interaction commands are applicable to an object. You can then find the right mix of obj type checking vs. number of ICommands to suit your style.

if you end up with more than 32 interaction commands, you can use a bit vector instead of an integer. i just wrote a post on my blog with source about bit vectors here: http://blog.generalrelativity.org/ac...d-bit-vectors/

[Pazil]

A habit I've ended up doing in the past while now for (somewhat) similar situations is
(This will be in context of a hit detection system between lines, circles, and polygons (each a different class.). They all contain functions like: hitTestLine, hitTestCircle, and hitTestPolygon.) make each class have a simple hitTest function, which all it does is call the other object's hitTestLine or whatever function. This is the hitTest function for the Line object (the IShape interface is simply an interface with the hitTest methods):

function hitTest( object:IShape):Array
{
object.hitTestLine( this);
}

The only problem with this is, of course, extensibility...You need to modify each class every time you add another type of object. I'd say that the best way for objects to interact with each other is via your look up table. Seems solid, and should be fast!

P.

[dVyper]

I don't know if it's the best way but I personallly think your Interactor class is the best.
That way the objects don't need to be concerned with working out whether it has to interact with another object, only with what happens when it does interact.
Plus if you have to make a change to the interaction you only have to change the Interactor class and not the classes for the different objects.
Plus the Interactor class, because it has information on all the objects, will be able to quickly determine which objects will actually interact (if each object has to determine this on their own it might take more time to process).

[TOdorus]

When I read through it I immediatly thought: "Interactor class hands down."

1.

function checkCollision(Actor1:Actor, Actor2:Actor){
     switch(true){
          case (Actor1 is Circle):
               switch(true){
                    case (Actor2 is Circle):
                    break;
                    case (Actor2 is Square):
                    break;
               }
          break;
          case (Actor1 is Square):
              switch(true){
                    case (Actor2 is Circle):
                    break;
                    case (Actor2 is Square):
                    break;
               }

          break;
     }
}

You need to find out which function to use Circle vs Circle, Circle vs Square or Square vs Square. The other way to do this is to have a function on every Actor type for every other actor type. This would mean you need to update every previous actor everytime you decide to change something, instead of just having to update one class. You can do this to for damage vs armor types and whatnot. Neat, tidy and easy to extend.

2. A interactor class can have a broadphase which elimenates checks. If you split it up, every class needs to check it's enviroment for possible collisions, resulting in pairs bieng checked twice.

In short: what dVyper said.

PS if the Actor is Something check is rather slow, you could always define a intergral type property to check against and speed things up.

[justkevin]

Some excellent suggestions. I'm still not certain which way I want to go-- I think I need to go through the game design and work out exactly what kinds of interactions I'm expecting and see if that clarifies the best approach.

[AluminX]

First do not let x be depend of y's flags or vice versa. because if z object comes into play and is completley different, than x and y need to change their flags again. if x and y are game objects then they should be implementing colliders(or creating a collider object internally). you should also have a collider manager which registers all game objects which have a collider object created.
this will help manage all the collisions for all object in one centralized place.
if later on you decide to create a new game object z from a different class, then all it has to do is define a collider object the collider manager should take care of the rest.

if you want to engineer an engine the right way
I would recommend do some more research on game design patterns. I'm sure there are some good and proven techniques you can implement

[TOdorus]

First do not let x be depend of y's flags or vice versa. because if z object comes into play and is completley different, than x and y need to change their flags again.

Sorry AluminX, that's a bit to abstract for me. What do you mean by x being dependent on y's flags?

I think the singleton can be used for many kinds of interactions kevin. I also use it to create a fire. If something stands next to the fire it will heat up, but some objects catch fire, some don't and some explode. I can't imagine a situation where a singleton, which does a broadphase and selects the appropiate functions for interaction, wouldn't be desirable. If anybody can prove me wrong, please do.

[AluminX]

1. Object X uses a switch or if statements based on a property of Object Y to determine what methods if any to call.

2. Object X uses a switch or if statements based on Object Y's interfaces to determine what methods if any to call.

the above suggests that X interacts based on a property(flag) Y has.

[Pazil]

The problem with having switch statements is that every time you add a new object, you need to write statements for number_of_objects^2. That's a lot of editting after you have more than 3 objects, and you want to add more. That's why I'm still suggesting using a look-up table, since it not only should be faster, but can be editted a lot easier.

[newblack]

it's all about abstraction here. you don't want to fill your objects up with conditional logic (that's what she said).

the bitwise approach still seems best to me. the logic of what makes each object unique is done offline, as opposed to running it through an enormous switch case, type-checking, but only if it's not these 2 types, or 1 is this type and the SECOND ONE is this type, etc. mess. if in the end each element subclass behaves exactly as is described, all you have to do is not set any unique flags on their bitmasks.

[TOdorus]

The only experience I've had with bits is setting dmx adresses. I've looked some stuff up and am willing to make a complete arse out of myself here, so bear with me and feel free to correct.

When the interaction function is independent of what objects interact, then I don't see a problem in using a lookup table like justkevin proposed. Is something poisenous and can the other be poisened? Look up the corresponding bits and see if one poisons the other, both poison each other, or nothing gets poisened.

But when that isn't the case? A hittest between a line and a circle is something completely different from a hittest between a line and a square as the mathematical defination differs.Then I suppose it should look something like this:

1000 Line
0100 Circle
0010 Square

1000 Line
0100 Circle
1100 Line Circle interaction

1000 Line
0010 Square
1010 Line Square interaction

If I understand that correctly, I think the best solution would be to use this within a singleton handling all interactions, as this will give the added advantage of a broadphase.

[justkevin]

To ground the problem with a concrete example, this image shows several different possible real game interactions:



The grid represents the map. Each square is a node, which is used for broadphase collision detection. Entities may not be larger than a single node, so an entity only needs to check against the entities in at most 4 nodes.

The types of "hittable" entities shown on the map are:
Enemy units (red A & B)
Player unit (green C)
Player hovercraft (green D)
Water (blue squares)
Destructible obstacle (gray block)
Indestructible obstacle (black blocks)

Also show are two projectiles. Projectiles cannot be hit (they don't track their node), they can only hit other objects.

There are two primary types of interaction that can occur: Movement & Damage

Examples:
D can move through water.
B cannot move through water.
Nothing can move through the indestructible obstacles.
Nothing can move through the destructible obstacle.
Projectiles damage the destructible obstacle.
Player projectiles can move through player units.
Enemy projectiles can damage player units.

I'm still going back and forth on how to handle this. The various solutions I've started down solve one scenario, but seem to be inefficient or hackish at solving another.