Jump to content

  • Log In with Google      Sign In   
  • Create Account


Lua game integration


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Mercurialol   Members   -  Reputation: 221

Like
0Likes
Like

Posted 23 February 2013 - 05:31 PM

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


Edited by Mercurialol, 25 February 2013 - 05:59 AM.


Sponsor:

#2 BGB   Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 26 February 2013 - 11:14 AM

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... ).

#3 Khatharr   Crossbones+   -  Reputation: 2957

Like
0Likes
Like

Posted 26 February 2013 - 11:53 PM

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.

#4 Mercurialol   Members   -  Reputation: 221

Like
0Likes
Like

Posted 03 March 2013 - 02:16 AM

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.



#5 BGB   Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 03 March 2013 - 03:02 AM


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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS