Using Lua to define NPC behaviour in a C++ game engine - c++

I'm working on a game engine in C++ using Lua for NPC behaviour. I ran into some problems during the design.
For everything that needs more than one frame for execution I wanted to use a linked list of processes (which are C++ classes). So this:
goto(point_a)
say("Oh dear, this lawn looks really scruffy!")
mowLawn()
would create a GotoProcess object, which would have a pointer to a SayProcess object, which would have a pointer to a MowLawnProcess object. These objects would be created instantly when the NPC is spawned, no further scripting needed.
The first of these objects will be updated each frame. When it's finished, it will be deleted and the next one will be used for updating.
I extended this model by a ParallelProcess which would contain multiple processes that are updated simultaneously.
I found some serious problems. Look at this example: I want a character to walk to point_a and then go berserk and just attack anybody who comes near. The script would look like that:
goto(point_a)
while true do
character = getNearestCharacterId()
attack(character)
end
That wouldn't work at all with my design. First of all, the character variable would be set at the beginning, when the character hasn't even started walking to point_a. Then, then script would continue adding AttackProcesses forever due to the while loop.
I could implement a WhileProcess for the loop and evaluate the script line by line. I doubt this would increase readability of the code though.
Is there another common approach I didn't think of to tackle this problem?

I think the approach you give loses a lot of the advantages of using a scripting language. It will break with conditionals as well as loops.
With coroutines all you really need to do is:
npc_behaviour = coroutine.create(
function()
goto(point_a)
coroutine.yield()
say("Oh dear, this lawn looks really scruffy!")
coroutine.yield()
mowLawn()
coroutine.yield()
end
)
goto, say and mowLawn return immediately but initiate the action in C++. Once C++ completes those actions it calls coroutine.resume(npc_behaviour)
To avoid all the yields you can hide them inside the goto etc. functions, or do what I do which is have a waitFor function like:
function waitFor(id)
while activeEvents[id] ~= nil do
coroutine.yield()
end
end
activeEvents is just a Lua table which keeps track of all the things which are currently in progress - so a goto will add an ID to the table when it starts, and remove it when it finishes, and then every time an action finishes, all coroutines are activated to check if the action they're waiting for is finished.

Have you looked at Finite State Machines ? If I were you I wouldn't use a linked list but a stack. I think the end result is the same.
stack:push(action:new(goto, character, point_a))
stack:push(action:new(say, character, "Oh dear, this lawn was stomped by a mammoth!"))
stack:push(action:new(mowLawn, character))
Executing the actions sequentially would give something like :
while stack.count > 0 do -- do all actions in the stack
action = stack:peek() -- gets the action on top of the stack
while action.over ~= true do -- continue action until it is done
action:execute() -- execute is what the action actually does
end
stack:pop() -- action over, remove it and proceed to next one
end
The goto and other functions would look like this :
function goto(action, character, point)
-- INSTANT MOVE YEAH
character.x = point.x
character.y = point.y
action.over = true -- set the overlying action to be over
end
function attack(action, character, target)
-- INSTANT DEATH WOOHOO
target.hp = 0
action.over = true -- attack is a punctual action
end
function berserk(action, character)
attack(action, character, getNearestCharacterId()) -- Call the underlying attack
action.over = false -- but don't set action as done !
end
So whenever you stack:push(action:new(berserk, character)) it will loop on attacking a different target every time.
I also made you a stack and action implementation in object lua here. Haven't tried it. May be bugged like hell. Good luck with your game !

I don't know the reasons behind you design, and there might be simpler / more idiomatic ways to it.
However, would writing a custom "loop" process that would somehow take a function as it's argument do the trick ?
goto(point_a)
your_loop(function ()
character = getNearestCharacterId()
attack(character)
end)
Since Lua has closures (see here in the manual), the function could be attached to your 'LoopProcess', and you call this same function at each frame. You would probably have to implement your LoopProcess so that that it's never removed from the process list ...
If you want your loop to be able to stop, it's a bit more complicated ; you would have to pass another function containing the test logic (and again, you LoopProcess would have to call this every frame, or something).
Hoping I understood your problem ...

Related

Maintaining lua/c++ variables through through multiple script calls

I'm pretty new to lua scripting, but want to incorporate scripting into my game engine. Currently I have lua linked up to c++ in a basic manner where I can call methods from c++ classes and vise-versa. Lua scripts are setup as components and you can essentially attach scripts to a game object. However, I'm having an issue where my variables are being reset each time a script is called. Here is a basic example of a script:
--lua script--
input = InputManager()
function initalize()
end
function update()
if(input:KeyDown(KEY_SPACE)) then
print("Random before: ", input.random)
input.random = input.random + 10
print("Random after: ", input.random)
end
end
Initialize is called when the script component is attached and update is called every frame. In this example, in my c++ InputManager class that I bind up to lua, I have a integer random that is initialized to 5. I'm using lunafive properties to control the getting and setting of variables.
When I hit space i expect the first iteration to print out:
Random before: 5
Random after: 15
And then the next iteration:
Random before: 15
Random after: 25
However, every iteration I get that first result of 5 and 15. I realize this is because I'm loading the script each update method so it is probably just creating a new instance of InputManager.
How do I go about creating an instance of an object (i.e InputManager) and maintain that same instance every time I call update.
That way I could do something like this:
input = nil
function initalize()
input = InputManager()
end
function update()
print(input.random)
end
and not have an undefined instance of input once update is called. Hopefully this all makes sense, if not I can clarify! Any help is much appreciated!

Standard ML multiple condition statement

I am about finished with a script I am writing but I have one last condition statement to add to my function.
fun whileloop (x:real,a:int,b:real) =
if (a<1)
then (x,a,b)
else whileloop(x+1.0,a-1,b-1.0)
This is my current loop I have created. It is basically accomplishing everything I need under one exception. I want it to exit its loop once the b variable hits zero[if this happens before a reaches zero). I believe Standard ML will not let me do a condition statement for a real variable...such as b<1.0. just to give you an idea of what I am trying to accomplish...I want the following code to work below:
fun whileloop (x:real,a:int,b:real) =
if (a<1 or b<1.0)
then (x,a,b)
else whileloop(x+1.0,a-1,b-1.0)
of course this code does not work due to the syntax and a condition statement being checked against a real number...but how could I accomplish this task while keeping my skeleton somewhat intact. I simply want to add another if condition statement to the existing skeleton. In C++ this was a fairly simple task.
Here is the answer. Thanks to John Coleman.
fun whileloop (x:real,a:int,b:real) =
if (a<1 orelse b<1.0)
then (x,a,b)
else whileloop(x+1.0,a-1,b-1.0)

Applescript - running handlers from a list

I'm trying out this code in applescript:
the first one works, the second doesn't
global theOpts
on saySomething()
--some code that it runs
end
set theOpts to {saySomething}
--the one that does
set t to theOpts's item 1
t()
--the one that doesn't
on runByIdx(idx)
set thefun to item 1 of theOpts
thefun()
end runByIdx
Is there a way I can get this to work?
What I want to do in summary is have a list of handlers that I can call by index rather than by name.
Don't do that. It's an undocumented behavior and known design flaw. Handlers aren't meant to be manipulated as objects, and it breaks the handler's bindings to the enclosing script.
The right way to do it is to wrap each handler in its own script object, and put those script objects in the list instead.
script Foo
on doIt()
say "this"
end doIt
end script
script Bar
on doIt()
say "that"
end doIt
end script
set opts to {Foo, Bar}
doIt() of item 1 of opts
Though you should also not underestimate the value of a simple if...else if... block:
if idx = 1 then
doThis()
else idx = 2 then
doThat()
else ...
Basically it depends on what problem you're trying to solve. But I'd lean towards the latter approach (i.e. KISS) unless it's a task that requires the extra flexibility, otherwise you're just adding unnecessary complexity and making work for yourself.
(FWIW, the AppleScript book I co-wrote a few years back has a chapter on working with script objects. The section on libraries doesn't cover the new library system in 10.9+, and the section on OOP has a corker of a technical error if you know where to look:p, but it's probably the best explanation of this subject you'll find so worth a look if you really want to know more.)
This way both work...
global theOpts
on saySomething()
return 1
end saySomething
set theOpts to {saySomething()}
--the one that does
set t to theOpts's item 1
--t
runByIdx(1)
on runByIdx(idx)
set thefun to item idx of theOpts
thefun
end runByIdx

Lua preserving global values

I use Lua for my game engine logic. My main game loop is not done in Lua. Only special nodes in my scene hierarchy have Lua scripts attached. These scripts are executed every frame. The problem I face is that I need to keep global variable values from one frame to another.
My temporary solution looks like this:
finish = useBool("finish", false)
timer = useInt("timer", 0)
showTimer = useBool("showTimer", true)
startTimer = useInt("startTimer", 0)
play0 = useBool("play0", false)
play1 = useBool("play1", false)
play2 = useBool("play2", false)
play3 = useBool("play3", false)
delta = useInt("delta", 0)
gameOverTime = useInt("gameOverTime", 5000)
finishTime = useInt("finishTime", 5000)
checkPoint = useInt("checkPoint", 255)
<...> Game logic <...>
setInt("message", message);
setInt("checkPoint", checkPoint)
setInt("finishTime", finishTime)
setInt("gameOverTime", gameOverTime)
setInt("timer", timer)
setBool("play3", play3)
setBool("play2", play2)
setBool("play1", play1)
setBool("play0", play0)
setInt("startTimer", startTimer)
setBool("showTimer", showTimer)
setInt("timer", timer)
setBool("finish", finish);
I call special methods that retrieve global variables from hash maps in C++ at the beginning and I set them again at the end of the script.
Is there a way to do this implicitly?
Is it a bad design to use Lua not as the main game loop?
Well, while there is nothing technically wrong with your solution, you might start to notice some performance issues if you end up with a lot of global variables (something you should, in general, avoid).
With that said, there is room for improvement. For example:
At the beginning of the script, check if your global variable is nil. If it is, then you can initialize it, if not, this is probably not the first time you're running the script, so leave it unmodified. But that means a lot of pesky if-else statements, which one can easily forget about. We can do better!
I would recommend looking at Chapter 14: The Environment, from the Programming in Lua book. Here's a quick quote from the intro:
Lua keeps all its global variables in a regular table, called the environment. ... The other (actually the main) advantage is that we can manipulate this table as any other table. To facilitate such manipulations, Lua stores the environment itself in a global variable _G. (Yes, _G._G is equal to _G.)
Since _G is a table, it also has a metatable, so you can define __index and __newindex metamethods to handle access to and creation of global variables. You can find examples of this in section 14.2. Go read the whole chapter, it's not that long (if you're unfamiliar with metamethods and metatables, also look through chapter 13 - this is where Lua really shines in terms of flexibility).
Now that we've covered the trivial and normal methods, let's look at the overkill end of the spectrum. As an example I'll look at Unity's approach to scripting. A Unity javascript usually defines variables, functions, and types. Any variables defined outside of the scope of methods or types are persisted between frames because the script itself is not executed every frame. Instead, they let the script define functions and call the functions at the appropriate time. So if you want something executed every frame - you put it in the Update function. Every script can define it's own Update function because it has it's own scope. So every frame the scripting engine goes through all objects, checks if the script's scope has an Update method and calls it.
Back to Lua - a solution like this would involve creating separate environments for each object/script/whatever your node is. Then, instead of executing the script attached to your node every frame, your main loop will go through all the nodes and run a function inside of their environment. You can also switch environments, so you can set the global environment to your node's env before executing it, and then switch back when you're done. This allows your scripts to use globals as they see fit, have them persisted between frames and excludes the possibility of name collisions or global namespace pollution. Additionally you can use metamethods to nest the node's environment inside the actual global environment or inside an API environment with helper methods (basically, if __index does not find something it looks it up in a parent).

Retain cycle with CCAction and CCCallFunc/CCCallBlock

I'm in the final stages of releasing my first game, and after running Instruments:Leaks & Allocations, I see that I have a leak in my code caused by a retain cycle. I am using Cocos2d 2.0, and compiling my app with ARC, and I should mention that I started the project pre-ARC, and used the Xcode refactoring tool to convert it. My game has several animated objects per screen, each of which has a small number (1-7) of animated "variants" of that object (i.e. the barn opens to show a horse once and a zebra another time). I have a class that represents each animation, and another class for each variant. The variant creates a CCAnimation from a sequence of frames, and then creates an action which will be run whenever a touch event is received in the correct region. This action is what is causing my retain cycle. My declaration for the action ivar looks like this:
#interface AnimationVariant : NSObject
{
#private
CCAction* _action;
...
}
#property (readonly, nonatomic) CCAction* action;
...
-(void) setupActionWithMask:(int)mask
cycles:(int)cycles
hasScale:(bool)hasScale
scale:(float)scale
masterScale:(float)master_scale
animationFrames:(NSArray*) frames
duration:(float)duration
andBlock:(VoidBlock)block;
#end
In the implementation of the setupActionWithMask method, I build up an NSMutableArray of CCActions, actionList. The sequence of CCActions varies depending on args, but usually it looks something like this:
[actionList addObject:[CCScaleTo actionWithDuration:0.0f scale:scale]];
[actionList addObject: [CCAnimate actionWithAnimation:animation] ];
[actionList addObject:[CCScaleTo actionWithDuration:0.0f scale:master_scale]];
[actionList addObject: [CCCallBlock actionWithBlock:block]];
And I create the action like this:
_action = [CCSequence actionMutableArray:actionList];
The consuming class creates an AnimationVariant instance, sets its properties, calls setupActionWithMask, and passes in a block it wants executed when the action completes. When the consuming class wants to play the animation variant, it does so like this:
[self runAction: variant.action];
I tried declaring _action as:
CCAction* __unsafe_unretained _action;
which of course broke the retain cycle, but the action is destroyed, and is no longer around when it's needed (which is what you would expect, since __unsafe_unretained does not retain). I know __weak is the recommended solution, but as I am targeting iOS 4 and up, I don't think it's available to me.
I had another retain cycle in my code, exactly like this one, also caused by retaining (automatically with ARC of course) a CCSequence containing a CCCallFunc/CCCallBlock. I solved that one by just re-creating it whenever I needed it, which I could also do in this case, but these animations are triggered maybe a couple hundred times in the whole game, so I was hoping to follow the recommended Cocos2d Best Practices and retain the actions.
Thanks!
Retaining actions is not best practice. It's not even good practice. Though it comes heavily recommended by many, quite unfortunately.
Retaining actions works in many cases, but fails in others causing objects to leak. I'm guessing your case may be one of those.
Since you're targeting iOS 4 you can't use weak references. But you should probably reconsider unless you have to target the remaining few 1st and 2nd generation devices. Otherwise, google for iOS 5 adoption rate. The handful of devices that haven't been updated yet are well below a reasonable threshold, in particular if you consider that those users probably don't buy (many) apps (anymore) anyway.
Since you meantioned CCCallFunc, make sure you don't use them and replace with CCCallBlock. CCCallFunc are not safe to use with ARC, in particular whenever you have to __bridge_transfer cast a data object to void* (also bad practice).
There's always the chance that the necessary bridge cast back to the original object never occurs, and then ARC doesn't get the chance to clean up that object. With CCCallFunc this can happen when you run a call func action but the action is stopped before the callback selector is called, for example by changing scenes or stopping the action/sequence.
Cocos2D is also prone to retain cycles if you don't follow this rule:
any node should only retain another node that is one of its children or grandchildren
In all other cases (ie node retains (grand)parent or sibling node) you must make sure to nil those references in the -(void) cleanup method. Doing so in -(void) dealloc is too late because the object will never get to dealloc when there's a retain cycle.