Sign in to follow this  

Interaction between an Ingame-Tool and Object

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello forum!

 

Following problem:

 

A player can select a tool and use it on objects.

Tools and objects can be created from scratch by a level creator (every player can be one) - using Lua.

 

The issue is, who should be in charge of handling interactions between tool and object?

Should a tool contain a list of possible identities of objects and how to react to them?

Or should an object contain pieces of information about each tool that can operate on them?

 

I'm sure that a tool should be in charge for telling the engine what range/how many/which objects are in question.

As my objects are entities with their plugged in components, there is literally a list of interact-able ones.

 

If the tool owns the information, it can easily iterate over possible objects and check conditions.

Let's imagine a laser beam that shall hit every object in a row until an object rejects the beam.

The tool would easily iterate over all objects as long as none did reject it.

 

What if objects would have to handle this? The tool would need to run a sort of protocol with them.

Object one, you are hit by a laser-tool-level 1? Object one checks for that tool and acts accordingly.

It returns (just as example) true as it has been damaged and the tool receiving this boolean can continue attacking the next object.

If false, it simply would have stopped.

 

Is there an ever better way of solving this?

It is quite a key element of my game, therefore I'm looking for something that keeps a lot of options open for the players.

But also minimises complicity - as leaving information within the tool would end up in letting the player meddle with default data.

 

I hope I did not confuse you! Thanks for taking your time to read my thread!

 

 

 

 

 

Share this post


Link to post
Share on other sites

The way I would do it is to give the objects logical and geometric properties and then the tools can itarate through them amd see if they can interact with them.

The abstraction can come from other parts of the logic , like what happens when the object is removed from the stage / scene or added there and so on .

Share this post


Link to post
Share on other sites
What do you mean by other parts of the logic?

So you would give the objects properties that help determining on how a tool should react?

Thing is, the player has to implement new tools.
Adding certain properties and then manually checking against seems a bit complex for a usual user.
Also, properties are not really explaining why a tool should behave in a certain way.
Nonetheless I can see how having a false delete property would work.
But then, if a hammer tool encounters a window with the false destruct property, how does that keep working with a stronger tool?
If I make properties too creative, as in "Glass Property" things might become a bit strange.
Though it might be a good way of handling this all.
But it might add logical loop holes. If the glass property is set, it might add other characteristics of glass in general according to real world logic when they are unwanted.

This all breaks my head more than it should!

Share this post


Link to post
Share on other sites

I understand that you want to make everything flexible , but you have to create some context / world to work with in.

From what I understand you want to create some sort of Minecraft type of game .

You can use the component - object model where you have a class GameObject and a bunch of components with their properties.

 

like this

 

class Object
{

WoodComponent * wCompoent;

 ...

 

WoodComponent * woodCompoent();
};

 

And you create just the component that you need , and the other ones are null . I know this could be heavy on the stack but .. still it's a nice model. You can add components very easy without changing the current code.

Share this post


Link to post
Share on other sites

Usually the game logic should be thought of as the master of your code and the objects are the data it operates on, in some cases this becomes a bit blurred though.

 

In your tool example you could say, have a basic definition in your code of what a tool is, perhaps tools have different interaction types. Maybe someone makes a new "ranged tool" that fires a beam, beam being some kind of predefined setting that causes the tool to cast a ray. Thus when you use the tool your game logic would be in control, it would figure out what the beam collided with(penetrating or not) and then perhaps the tool has some kind of callback script that receives a list of objects it hit as a parameter. That way my laser cannon can do some pretty effect and if it hits any rabbits they turn into puffs of smoke. The tool would run the actual code that determines how the objects are affected and the game logic acts as the marshal between them.

 

That's probably what I would do anyway. You have to come up with a base system to really know how you should write it.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this