Lua game integration

Started by
3 comments, last by cr88192 11 years, 1 month ago

Hey guys. I've just integrated lua in my game (which isn't finished yet). Anyway, some things are bothering me.

I've registered functions a list of function pointers that I want to be able to call from Lua. It works fine. Although I feel like I'm making a facade between lua and my game and it requires (constant) changes to the code itself. I used lua as a logic for the debuff system in my game just to see what the scripts are all about. I'd basically implement the debuff logic inside the script, load it and execute it on an enemy. I started by making a facade class who's static functions would lua call and delegate the call to the enemy passed from lua to the engine.Something like this:

1.Debuff update

2.Call debuff script ( pass the enemy obj. to lua)

3.Debuff logic inside the script

4.Call the adapter class function (and pass the enemy if necessary).

Problem: writing function pointers for everything i want to be able to call from lua.

I'm pretty sure I'm doing something wrong, so it'd be better if I'd get on the right track from the beginning.

Thanks in advance

Mercurial

Advertisement
this is a fairly common issue with scripting languages.
it is kind of ugly and annoying, but more "just how it is done".

if relevant, maybe try looking into something like SWIG or similar.


( in my case, for developing my own language/VM I integrated SWIG-like functionality directly into the VM. not sure why more people don't do this, apart from maybe the fear and pain of parsing C and C++ headers... ).
It's a pain sometimes. The first time I embedded Ruby I almost had an aneurism. Later on I tried it again and it went a lot smoother because I had planned ahead as far as where I wanted to place the division between the high and low levels.

The code is indeed ugly any way you slice it, but it can still be moderately manageable. IIRC the pattern I settled on was to create a class in C++ with a header file and a code file, then create an interface file for that class that contained all the code necessary for interacting with the class, including its injection into the scripting engine. By writing the C++ class with its script-side implementation in mind I was able to implement it in a way that made the interfacing a lot less complex. Most of the method wrappers were just argument conversion followed by a member function call on the object.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

IIRC the pattern I settled on was to create a class in C++ with a header file and a code file, then create an interface file for that class that contained all the code necessary for interacting with the class, including its injection into the scripting engine. By writing the C++ class with its script-side implementation in mind I was able to implement it in a way that made the interfacing a lot less complex. Most of the method wrappers were just argument conversion followed by a member function call on the object.

I actually did the same thing and thought there must be an easier way.


IIRC the pattern I settled on was to create a class in C++ with a header file and a code file, then create an interface file for that class that contained all the code necessary for interacting with the class, including its injection into the scripting engine. By writing the C++ class with its script-side implementation in mind I was able to implement it in a way that made the interfacing a lot less complex. Most of the method wrappers were just argument conversion followed by a member function call on the object.

I actually did the same thing and thought there must be an easier way.


well, to restate, if not already done so it may be worth looking into something like SWIG or similar and seeing if it will work.

This topic is closed to new replies.

Advertisement