Should I be creating chaiscript::ChaiScript for each of my objects?


#1

I’m trying to add ChaiScript to my MMORPG, but I think I was misunderstanding how ChaiScript works exactly…

Originally, I thought running eval_file would execute the script and be done with it. Allowing us to reuse the chaiscript::ChaiScript object without it being flooded with ALL our scripts. Seems that’s not the case, and the scripts stay in the chaiscript::ChaiScript object (this is actually perfect in the sense that we’re not re-loading scripts all day).

So here is my question… I want to apply ChaiScripts to a bunch of different mechanics in my game… but I want to demo it first on Monsters. So I first have ONE MonsterPopulation object, this stores a dictionary of ALL our monsters. I then have a Monster object, there is 1 made for each monster.

I want to make it so that different monsters run different scripts when they die. So my question is… Should I be assigning each monster their own chaiscript::ChaiScript object? Or should they all be sharing ONE chaiscript::ChaiScript object, and I just have unique function names that I call for each monster…

I’m 99% sure it’s the first one, but I want to be sure.


#3

Nah, don’t make a ChaiScript instance per monster, that sounds wrong. You could have one function that takes a monster-object or monster-id or monster-type as parameter (in script) which then dispatches the appropriate action. Or give the monster-object a std::function which calls the right script-function upon death, or none if the monster has none assigned. that way you could also share some functionality between monsters. Like all dragons get the same on-death function assigned, but pass their dragon-type to it to specialize it. Or even handle the death in script, and call the onDeath from there.


#4

Actually it’s not a simple question.

In some extreme situations, it might be necessary to have ChaiScript VM instances running for some specific entities
which have complex behavior.

However in general, most game entities behave with a simple behavior that can run in 1 VM which execute the same update function on all the elements of the game that match that behaviour. That VM could then be loaded with a script with all the possible scripted behaviours, but do nothing until the update functions are called (in entity type batch manner, preferably).

This is not the only setup possible. If you have a game console, you might want to make a ChaiScript VM instance loaded in it. Or you might want several instances depending on different totally unrelated systems, like an editor.

Just note one thing: all the data that exist in one VM will be visible to all scripts and calls being done through the same VM.

So basically you have to know:

  1. What needs scripted behavior.
  2. Can their behavior be gathers in a bunched of scripts loaded in 1 VM? Is it ok that they have access to the same data in the VM?
  3. What is the cost of a VM? Am I ok running more than one?

Anyway try to limit the VM instances count to the minimum necessary.
In a very complex game I am making, which is not finished, I plan to have several VMs because of different systems needing separation but also scripting, like the behaviour of each “place” (aka level/zone/area). But I don’t need a VM for entities because they have a dumb behavior (they are RTS units more or less). There is other places where I could use a VM, like the editor or some oppoonent’s behavior. We’ll see.

So it totally depends on the game. But keep in mind that a VM running is expensive.