Hell forum!

Usually I separate graphics from physics: One goes into a file with the description on how to render the screen and the rest goes into the physic calculation component, where I do all the needed physic tests.

However, this time it feels like my game would benefit from a more tightly knit bond.

Therefore, I want objects that know how they look (a sprite-class as member) and who they surround (references to other objects).

Additionally they should have "scripteable" behaviour. This is where it gets a bit tricky for me:

The game field is being described in a Lua-file. All sprite-sheets and possible triggers together with their event reside in them, object by object.

Now... if I run through each described object and call a C++ function, I can create those above mentioned objects in the C++ part.

Nonetheless, how would I link them to their Lua equivalent?

Nearly every object shall have a trigger on mouse click and many will have triggers once the player touches a nearby referenced object (we can assume a tile-grid here).

But how would the Lua-objects push their triggers onto the C++ components?

I imagine something like this:

A Lua-object registers for a on-click event on its own C++ equivalent.

C++ will only bother evaluating mouse click coordinates to registered possible triggers. As a result, if only one object has a trigger and this one is set to itself, C++ will only compare the mouse click's coordinates to this object. If there are more, it will iterate through the list of registered objects.

Once the coordinates of a click and its C++ object hit box met, the checking function will return true to the trigger-handler-component.

But how would this find the Lua-object that once called it? How would it store the type of its trigger in order to tell the Lua-object it actually has been triggered?

If you have any recommendations, I would be really happy to hear of them : )

Also, thanks for taking your time to read through this topic. If something has been unclear, please inform me!

Pretty open to every binding, not using one in particular at the moment.

1) Every event handler is a Lua function. The sprite object has as a member a pointer to the Lua function (possible in Luabind). The sprite class I'd write a "RegisterEventHandler(std::string function_name)" class, that takes the name of a function and sets the handler pointer. I'd call RegisterEventHandler() when my script is running its load/setup code, and if I wanted to change handlers mid-execution, just call the same function again with a different name.

This goes into a direction I like. But how would I progress from there?

It sounds like there is an event-checker-class, that would iterate over all my objects and call the Lua function via the pointer and that Lua function would run its if-requirement.

But what is about the Lua objects? Can Luabind refer to object's classes? Or can Luabind actually give the sprite class a pointer to the right object as well?

Another thing, this would actually cause Lua to run every single frame as long as some even-trigger has been set, right?

Isn't there a way to use Lua only when its required to run?

If Luabind supports sending single Lua-objects pointers to C++, couldn't the Lua-objects listen to certain happenings in the C++ engine?

Let's say, a Lua-objects says, it needs information about incoming mouse clicks that actually hit a game object. Whenever a mouse click happens, C++ will contact all Lua-objects that registered themselves for this event, giving them the information of which object the has been hit.

Though, how would my Lua-object know what C++-object it should edit?

Thanks a lot! Yeah, the contra is something that was lurking in the corners for me as well, losing the flexibility.

Just afraid of running Lua every cycle as that is what they are all preaching to avoid. Maybe it is more about avoiding heavy calculations.

I just found out that Luabind needs Boost, is there an alternative binding sufficing the things needed?

Pointers of Lua-Objects to C++ and then calling their functions?

One really important thing is, that I can compile it on Linux, Windows and Android.

Thanks, I just went through all interesting bindings.

Nonetheless, I realised, that all these bindings usually present the idea of referencing C++ objects to Lua, but not the other way around.

Is it common practise to actually put the C++ objects into the Lua objects? I thought that this might be dangerous, Lua might hold references to dead C++ objects, this sounds like ugly work to manage.

Nonetheless, I guess this refers to the idea of running through a list of triggers in some Lua-table, checking whether they would be triggered by accessing the referenced C++ object and directly comparing the variables of this C++ object with the requirements in the Lua trigger.

Is this right?

I decided to go with Sol 2 as binding, as it seems to cover all the necessities I have.

However, I'm not entirely sure how to implement everything yet.

My current "sprite"-class, or let's say tile-class, owns following:

A SFML vertex array (these might be organised differently at some point of development)

A hash key for the texture factory

Multiple height/width values

Now, I could define a user-type in Sol for my tile-class. However, how would I insert the customised functions to it?

Here is a reference to user-types: http://sol2.readthedocs.io/en/latest/api/usertype.html

Let's say: Check_Triggers() or an Update() could be

if (player.y_position == 2)
{
gameover()
}

or

if (player.y_position == 4)
{
player.lower_health(30)
}

and even complete different things.

But if I would do this all via C++ objects that get translated into user-types... I cannot think of a way doing these.

Also, how would I tell C++ where a list of the Lua objects are? Insert them all in a table and passing this as a reference back to C++, I assume?

In Lua, I could just simply create one file per typical object that I will use.

One for enemy of type a and one for type b and c...

But how would I let Lua iterate through their update function?

I mean, I could let the editor hard-code calling the object's update/trigger function. It would probably be a wiser decision to just store them all in a table and for-loop over them. Lua should not care too much about the different classes as this is a not statically typed, right? As long as they have the same function that I want to call.

Only problem would be the SFML vertex array and the lack of being a drawable SFML class. Luckily, I planned on moving the vertex arrays to another place of code already, anyway.

In the end, I might go way too complicated with this. Maybe someone could push their ideas to me.

Thanks for reading : )