# Lua Question: Multiple States

This topic is 4369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi everybody, This is my first time in the world of scripting, but I want to try and make this game I'm making as expandable as possible. So, I thought I would have Lua scripts control the enemies. So I started programming, but then I kind of got stuck on something. This might be a really stupid question, but is it best to use a different lua_State for every enemy (with different AI), or is it better to have one overarching lua_State that controls everything? Sincerely, LZR

##### Share on other sites
I have been pondering this one myself. Perhaps an answer from the fellow who did the magic on Far Cry's VM and scripts..

I have seen so many suggestions to go with multiple states, but I fail to have found an actual reason why.

For instance, I have a fair amount of table "templates" that are used to clone into the real objects that are used within the system. At the same time, a number of other static tables exist ("Server", etc.) that do most of the top end logic. I am running a single VM state, and at no less than 200 fps with hundreds of objects and communication with the host (C++, luaplus). Breaking up into multiple states would mean registering so many tables that are used with so many other states, plus the possibility that two objects that exist in different states cannot communicate with each other? I'm not sure, as the docs don't specify that exactly.

So, I have yet to find a reason to use more than one state. If somebody can provide a rational one, that would be much appreciated.

##### Share on other sites
Well, to tell you the truth, I would [I]prefer[/I] to have a different Lua state per object because that just works better with my engine. I guess what I meant to say is will it be a big performance problem to have a seperate state for each of the (possibly hundreds of (but that's probably an overstatement)) objects.

##### Share on other sites
Hm. It's hard to answer this question because it really depends on how you actually are making use of Lua--that is, what is actually being controlled by the scripts, how the scripts are working, that sort of thing. Without a lot more information, I'd just say do what feels most elegant.

Quote:
 Original post by sordid...plus the possibility that two objects that exist in different states cannot communicate with each other? I'm not sure, as the docs don't specify that exactly.

It's in those docs somewhere. Any LuaPlus:::LuaObject instances can interact with eachother regardless of the state from which they originate. If you're just using straight Lua on the other hand (ie. doing all the stack management yourself), then it's rather a non-issue since there's really no sensible way in which two states could directly interact.

##### Share on other sites
If you're like most people, your AI script for a given character consists of a function which is called each frame to determine the character's current action and/or event-handling functions which are called whenever events of note to the character happen. So the question then becomes: should all these functions exist in the same lua_State, or in different lua_States? Personally, I am all about the former. That allows you to have common code and data shared between entities without taking up extra space; it allows you to create Lua-side associations between the characters; it keeps you from wasting time setting up and destroying global Lua states (pretty much the slowest operation you can do in Lua); and it makes you use Lua's built-in organization features, instead of an ad-hoc solution consisting of a series of independent flat namespaces.

In my opinion, there are very few reasons to have multiple Lua states. These reasons generally relate to multithreading and probably don't apply to you.

##### Share on other sites
That's exactly the same reasoning I came up with, but it's always nice to hear somebody validate your feelings so you can put them in a drawer and continue merrily along.

Thanks, Sneftel.

##### Share on other sites
Quote:
 Original post by SneftelIf you're like most people, your AI script for a given character consists of a function which is called each frame to determine the character's current action and/or event-handling functions which are called whenever events of note to the character happen.

I think the problem arises when people decide they want scripts that read like a list of instructions, and which need to be interrupted periodically for control to return to the engine. Co-routines are the standard solution here, although how to set this up is often non-trivial, and managing shared data and concurrency issues is a potential problem, so perhaps people think that storing everything totally separately will solve their problems? (Although I don't really see how it does.)

##### Share on other sites
Quote:
 Original post by sordidI have been pondering this one myself. Perhaps an answer from the fellow who did the magic on Far Cry's VM and scripts..

I'm the fellow in question.
Nowdays, with lua 5 there are only 2 difference between having 1 states per 'entity', or sharing multiple states. Using multiple states requires more memory(I'm not sure how much but is quite a difference) with the advantage that you can suspend execution on demand(coroutines).
So, it depends on your scenario, for instance I'm working on MMOG, we do not use lua, but because we have thousands of entities in memory we definitively could not afford use multiple states. If you are coding an FPS, probably is not a big issue.

As a pesonal opinion I wouldn't use multiple states, in fact Far Cry uses only one. I deeply dislike cooroutines programming model; considering that would just be a waste of memory. But that's me.

ciao
Alberto

##### Share on other sites
Quote:
 Original post by Anonymous PosterAs a pesonal opinion I wouldn't use multiple states, in fact Far Cry uses only one. I deeply dislike cooroutines programming model; considering that would just be a waste of memory. But that's me.

Out of interest then, how would/do you handle long-running scripts like this?

while True:  Go to north edge of map  Wait until enemy sighted  Run to south edge of mapEnd While

##### Share on other sites
This is how would be done in my current game

class Monster extends Entity {	constructor()	{		//init stuff		GotoState("ToTheNorthEdge");	}		</ type = "state" />	ToTheNorthEdge = {		function OnEnterState()		{			MoveTo(northEdgePosition);		}		//called when moveto reaches the target pos		function OnTaskCompleted(event)		{			GotoState("WaitForEnemy");		}	}		</ type = "state" />	WaitForEnemy = {		function OnEnemySeen(enemy)		{			GotoState("ToTheSouthEdge");		}	}		</ type = "state" />	ToTheSouthEdge = {		function OnEnterState()		{			MoveTo(southEdgePosition);		}		function OnTaskCompleted()		{			SetTimer(60) // waits a minute and then returns to the northern edge		}		function OnTimer()		{			GotoState("ToTheNorthEdge")		}	}}

Looks much more complicated, but a real script doesn't just move a guy from A to B,
probably a would add more event handlers to stop if something happend, timeouts,
enemy encounters etc... I've tried to prototype a concurrent system using generators
but wasn't very good to work with. IMHO an even driven system is more natural and scales better.
The issue I found is that a real game object usually has to react to different inputs
also while is performing a scripted action.

ciao
Alberto

##### Share on other sites
I think people might disagree on what a 'real script' is. :) The event-based method works well but as you admit, it's much more complicated than a simple "do this, then do that" script, and I'm not sure how often people would want to add in different responses based on the current state. If I had a lot of NPCs of the same type, I think your method would work well to give them believable behaviour. But there are a lot of games where you have lots of unique NPCs, each with their own distinctive script, which would probably work better with the linear script style.

##### Share on other sites
Quote:
 Original post by KylotanI think people might disagree on what a 'real script' is. :)

I agree, what a 'script' is, is not really well defined. I always start with the assumption that 'script' means gamecode, that is true for very few games. Most of the time is a bit more than a config file.
Probably this kind of design issues are way too broad to be descussed on a public forum.

ciao
Alberto

##### Share on other sites

This topic is 4369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628659
• Total Posts
2984080

• 10
• 9
• 9
• 10
• 21