Lua and GameCode2

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Lua and GameCode2

      I've got the Lua Manager classes from Game Programming Gems 5 integrated into Teapot Wars if anyone is interested. I need to fix the timer on it, though - it's using timeGetTime() and this isn't working well in the OnGameUpdate() callback (I'm losing time somewhere).

      Anyway, just thought it might be of interest - I'll send a copy of the project to anyone who's curious.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • Ok, you can find it here:

      braggingrightsproductions.com/Downloads/default.aspx

      Just make a copy of your current GameCode2 directory then move the Lua5 folder up to the next level up in the tree:

      From :

      x:\programming\gamecode\lua5

      to:

      x:\programming\lua5

      Or you could just re-point everything to the new spot....
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • You know - I'd LOVE to integrate Lua or LuaPlus into the next source code update - any ideas on which one would be better??? I'll bet Kain has an opinion...
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Before anyone gets too excited - I pooched this one!

      As it turns out, I didn't do enough research before I dove in and I hit my head on the bottom of the pool. I'm still trying to clean up the mess, but it's a doozie....

      Basically, I attached a Lua manager class to the GameCodeApp class and got the functions working fine - basically just took the example from Game Programming Gems 5 "Building Lua into Games" and got the little beeping bit working. Little did I know how deceptive that was.

      As it turns out, I should have probably just separated it out into a global object of its own. I'm still playing with setting up a static manager member for key classes, but at the moment I'm about to bash my skull apart trying to figure it out.

      That'll teach me!

      Anyway - I've got to research this one a bit more before I can produce anything useful. I've got it beeping again as a member of the TeapotWarsGameApp class, but what I wanted was to be able to play a sound from the resource cache via scripting before moving on to bigger and better bindings.

      Guess I'd better not quit my day job....

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • Originally posted by mrmike
      You know - I'd LOVE to integrate Lua or LuaPlus into the next source code update - any ideas on which one would be better??? I'll bet Kain has an opinion...


      I haven't really played with Lua much, but I intend to. I've been looking at luabind and whatnot but it seemed like it would be easier to just bind it manually. Shot myself in the foot good with that one....

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • I have no opinions. My breadth of experience with Lua is not wide enough.

      I would agree with Nebuchadnezzar's plan to keep the lua code as separate from the app as possible (encapsulated in that LuaManager class). That is what I did, at least.

      Nebuchadnezzar, my lua experience is limited to LuaPlus, only. I haven't had time to compare its use to LuaBind or plain naked lua, but I'd be interested to hear any analysis you might have if you happen to compare the three.

      I don't have the Gems volume 5 book. How exactly did you shoot yourself in the foot? Just curious.
    • I guess by "shot myself in the foot" I meant that by binding to a class so far up the heirarchy I was making it nearly impossible (probably completely impossible) to bind to the extended functionality of the child classes. Basically, by binding to GameCodeApp instead of TeapotWarsGameApp I was hiding tons of functionality from the "System" script thread.

      I think I've settled down a bit on this, though. It looks like things will work out ok, as long as I can create a LuaManager for each class of object I want to bind. Otherwise I would need to do something like make a bunch of static functions in my classes to bind to a common LuaManager, which might start to get ugly. Perhaps I'll look a little closer at luabind and tolua....

      I'll probably spend a bit of time tinkering with it tomorrow, alternating with getting a terrain engine set up. There are some issues I'd like to discuss with that, too. I'm very interested in hearing what everyone thinks on that particular topic.

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • Having a common LuaManager doesn't seem so bad, especially if you use a callback method for the registration function. I'd actually prefer to have just one LuaManager in the app as opposed to having one for each class of object I'd want to bind.

      That way, you don't have to divide your scripts into separate sets of commands for each subsystem because your monolithic Lua state will have registered all of your binded Lua functions into a single dictionary of commands.
    • There are indeed trade-offs either way in my opinion. On the one hand a single LuaManager is simpler. On the other, I really like the namespace-style separation by class, mainly for the same reason there are namespaces - to avoid having to sort out what type of object is utilizing the callback. As you know, Lua's stack is typeless and while you can sort out string from int and whatnot it's not sensitive enough to sort out a CDog from a CLamp. Having fiddled with Neverwinter Nights' C-like scripting I have to say that I'd rather do -

      Source Code

      1. Object lamp = getNearest("lamp");
      2. if(lamp.state == OFF){
      3. lamp.activate();
      4. }

      than -

      Source Code

      1. Object lamp = getNearest("lamp");
      2. if(GetState(lamp) == OFF){
      3. ActivateObject(lamp);
      4. }


      Purely personal preference, I know, but it just feels cleaner. And it bundles relevant functionality under one "heading" so to speak - sort of an OOP-feel thing.

      I know - the other way is much simpler, and I'll probably end up adding a global LuaManager anyway to tie up loose ends. I guess I'm just being stubborn.

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."

      The post was edited 1 time, last by Nebuchadnezzar ().

    • Ok, call me slow....

      It just occured to me while watching TV with my wife (some romance or other - you can tell where my mind was) that I can set up one base LuaManager with it's State, then register libraries as I add classes. So, the current master State has a "System" library registered like so:

      Source Code

      1. static LUASCRIPT* GetScriptObject(lua_State* l);
      2. static int LuaBeep (lua_State* l);
      3. static int LuaWaitFrame (lua_State* l);
      4. static int LuaWaitTime (lua_State* l);
      5. static int LuaWaitSec (lua_State* l);
      6. static int LuaPlaySound (lua_State* l);
      7. static const luaL_reg scriptLib[] =
      8. {
      9. {"Beep", LuaBeep},
      10. {"WaitFrame", LuaWaitFrame},
      11. {"WaitTime", LuaWaitTime},
      12. {"WaitSec", LuaWaitSec},
      13. {"PlaySound", LuaPlaySound},
      14. {NULL, NULL}
      15. };
      16. void LuaOpenScriptLib( lua_State* l)
      17. {
      18. // register our library of routines under the table name "System"
      19. luaL_openlib(l, "System", scriptLib, 0);
      20. }
      Display All


      So then for each class that I want a "namespace" for - a new script library -- I just do the same thing and register static member functions for the class in question with the new library name.

      Man - I'm glad I don't like TV or I might not have thought of this...

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."

      The post was edited 1 time, last by Nebuchadnezzar ().

    • Damn, I have a graduation picnic, and you guys have a huge discussion about Lua.

      I'm currently finishing up using Lua for my own project. I never actually heard of LuaBin or LuaPlus, so I can't comment on them, but I love Lua. I have it wrapped in a global class, and then I have a seperate static library class that offers C-functions for Lua to use. I'm also going to turn off the built-in Lua libraries so that rogue scripts can't do anything a different way than I will allow (though turning off the i/o library while I'm debugging is pretty damned foolish). So, I'm hardly an expert on Lua, but I'm getting there.

      Lua rocks, and I will never again start a project of my own without it. What does THAT tell you?

      Mike, email me if you want.
      -Larrik Jaerico

      www.LarrikJ.com
    • RE: Lua and GameCode2 - my two cents

      One day my friend's husband introduced me to the Boost
      library. He sent me a CD with Boost and Lua on it. I didn't
      pay much attention to Lua, so I just put it off. When I
      got Mr.Mikes book, he mentioned briefly about Lua,
      but I again sat it aside and and didn't look further. When
      Nebuchadnezzar stated this thread about Lua, I went
      back and took a deeper look at. I found a nice
      introduction to Lua found at gamesdev.net. I really have
      NO clue how to use scripts in a game and of course I
      would have no idea what to do with it. I see some scripts
      for games here and there on the Internet, but never see
      anything specific or concrete.

      Ok, so I'm starting to ramble on and on. There's no point
      to this post but to say that I started to look at Lua
      I guess I will have to find out what other uses are for
      Lua, and start playing with it from there. I see
      Nebuchadnezzar posted some samples of Lua in a game,
      but it looks Hungarian to me, or is that Greek?! Oh well.
      Right now I'm kinda way back in the line, I mean I'm
      still trying to figure out how that CProcess works and
      the EventManager thing works. Even my cat its getting
      crossed eyed. Maybe some day with I get as smart and
      rich as Mr.Mike I will have the strength and courage to
      stand up and say "I saved a bunch of money by switching
      to Geico!"

      Thats my two cents worth.

      Sabrina.

      The post was edited 2 times, last by Sabrina ().

    • RE: Lua and GameCode2 - my two cents

      Um, okay. Basically, you would build the Lua interpreter straight into the game, then attach a few functions to it that Lua scripts can call. lua.org is a great reference. In fact, it's where I go the most for things.
      -Larrik Jaerico

      www.LarrikJ.com
    • RE: Lua and GameCode2 - my two cents

      Well, you could build the standalone interpreter and compiler, then play with building Lua scripts to do various things.

      LaMothe's "Game Scripting Mastery" by Alex Varanese has a small C Lua game engine in it which uses SDL to provide a very open base. You can control 90% of the game from the Lua VM. It's probably not worth $60 just for that, but you can get a grasp on how to build your own script engine from scratch, too. The biggest downside is that the first 1/3 of those books always covers newbie C++, so if you own more than one of them you have multple copies of basicallly the same crap. The newer editions leave that stuff out, though - guess they got some feedback....

      Rich
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."