Jump to content

  • Log In with Google      Sign In   
  • Create Account

Scripting for games [C++ and Lua]

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 KanonBaum   Members   -  Reputation: 277


Posted 30 December 2011 - 06:17 PM

I am aware of the post on this forum "Java and Lua" and the premise is very similar, but my question is different.

Basically, I'm not new to scripting; but I am new to Lua scripts and integrating it into my C++ programs. Now, I have already found libraries to do that, so everything's fine for that particular concept. My problem, is that I'm not sure what should be scripted. I understand the "logic" should be what's scripted, but I'm not visualizing it in my mind correctly. How should I separate the C++ classes and code from the LUA script's tasks?

Say I am making a 2D car game. The psuedo-C++ file of the car might look something like this:

class Car : public Drawable, Entity
        Car(...) { ... lua_do("CarLogic.lua") }
        void onDraw() { ... } 

        void onUpdate( ...  )

        void onEnd() { ... }

I am assuming the script wouldn't do anything for onDraw() but am I on the right track for the rest of the functions? Also, what about other auxiliary functions I may want to add? Would I simply define them in the script? What would that look like for one script to define a class? I'm skeptical about the whole thing I suppose.

Thanks so much for any enlightenment on this.
I'm that imaginary number in the parabola of life.


#2 slicer4ever   Crossbones+   -  Reputation: 5515


Posted 31 December 2011 - 04:01 PM

personally, my approach when attempting to draw a line between what the script handles, and what does the engine handle, is such:

-i generally keep most drawing left to the engine, i allow my script to control what can be drawn(through flags), and the shape of the object, but i generally attempt to leave the actual draw pipeline to my engine.
-anything modular, if their is anything in the game i forsee that could be expanded dynamically, i try to leave it as much to my script as possible, i leave anything to do with updating(including the physic's aspect), collision management(although not collision detection), and finally, i generally have a resolve/create function, which do not directly create/destroy the object, but define/close anything that needs to be done.

at the end of the day, you need to make the decision between, "This is what my engine will handle", and "This is what lua will handle". lua can handle everything if you truly wanted, or it can handle just the small stuff(for example, variable interpolation techniques between animation frames.)
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#3 vleugel   Members   -  Reputation: 252


Posted 02 January 2012 - 01:38 PM

The biggest reason I use scripting is because I want to easily change something without touching the source code which eliminates the need for a rebuild.
I always split up my games in 2 layers; GameEngine, GameLogic. The GameEngine contains my graphicsManager, soundManager scriptManager etc.
the GameEngine defines all stuff that can be re-used in other games. The GameLogic all classes for game objects / entities, basicly the game logic that is different in each game. Most of the game logic will be read from script. For example, I can create a Maze class that reads a Maze.Lua script file and constructs a maze in the game based on the script being used. This way I can create new mazes simply by creating a new script. The same is true for a platform game, where you can use scripts to generate the level. You can also use scripts to define how the enemies in the game will respond to certain actions. You can even use a design where you can add completely new enemies with an own unique sprite and AI just by changing some scripts. It is all up to you what kind of acces you give to the scripts.


#4 ddn3   Members   -  Reputation: 1486


Posted 03 January 2012 - 02:08 PM

Scripts usually encode dynamic or complex behavior which are runtime configurable as opposed to compile time.. For your 2d racing game, ask yourself how you will need to use the scripts to meet your design requirements? Will the game have user configurable hard points on the car you can mount any number of upgrades too? Will the game need dynamical behavior upon collision with other cars based upon some game state or car state? etc..

Your game design determines how and where the scripting engine falls. Some people do everything in script, which is ok but without a proper debugger, debugging your scripts will be a nightmare and there is a performance penalty for doing it all in script unless you use some sort of JIT. I'm leaning toward all in script scheme myself these days aswell with the advent of LuaJit and a home grown debugger..

Good Luck!

#5 coderx75   Members   -  Reputation: 412


Posted 03 January 2012 - 04:29 PM

I'm leaning toward all in script scheme myself these days aswell with the advent of LuaJit and a home grown debugger.

Just downloaded! I didn't know there was a JIT compiler for Lua. I've been using Lua for about 3 years and remember seeing something about a Lua compiler called "Kore", IIRC. This was commercial software though and I never bothered with it. Lua's fast, so this should be pretty amazing!

Back OT to the OP, I'm big on prototyping so I make nearly everything accessible from Lua though I leave a lot of the heavy lifting to the applications systems. There's usually a single update call per system (renderer, physics, etc.) that handles things within the main game loop and many of those systems run in threads. All initialization and uninitialization is handled by Lua. I also have a master script written in Lua that initially loads and manages all scripts and other major details of the application.

I started off in Lua trying to embed it in a game application so that I could use it to run AI. Problem with this was that I had so many other things I wanted to use it for: defining game object behaviors, level map logic, menu systems, etc. So, I backtracked and started with a simple application that registered some functions for graphics and input and fired up the Lua VM. I used this to make a couple of simple Lua-based programs such as a star field, pong clone and stuff like that. This got me familiar with both the language and the API. I revamped the application I was working on and, rather than try to embed Lua into the application, I integrated the application into Lua, using the VM as the central core of the app. It's heavy-handed but there have been so many benefits in prototyping and saving time in general.

Quit screwin' around! - Brock Samson

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.