Scripting API

Scripting API

Postby Edward_Lii » 02 Feb 2013, 16:08

Hello all,

I think it's time to start thinking about the scripting API. :)

In my opinion the scripting should be event driven.
At the moment there can be one script for every GameObjectEventType there is per block.
When there's a script for a certain event, that script will be executed instead of the default behaviour.

I think it might be best to extend this a bit and add more events for which scripts can be written.
After loading the level, allowing the levelmaker to start action sequences, etc...
One thing I noticed is that GameObjectEvent_PlayerLeave is never used, so that needs to be implemented.

A script should be able to do the following things:
  • Add/delete/move a block
  • Change properties of a block
  • Move the player and shadow
  • Retrieve information from the player/shadow/block (e.g. location, in-view, block standing on, etc...)
  • Start/stop music and sfx
  • Change certain aspects of the theme
  • Interact with the player by showing messages (and perhaps images?)
  • Store values for use in other/later scripts

For the block manipulating I think there should be a few methods which will take an index as additional parameter.
{l Code}: {l Select All Code}
setBlockLocation(x,y,index)

The index will correspond with the index in the levelObjects vector and acts as a handle.
A handle should be retrievable by id, something like this:
{l Code}: {l Select All Code}
//Get handle based on id.
handle = getBlockById('blockid')
//Get handle based on player or shadow location.
handle = getPlayerStandingOn()

The creation of a block will probably be quite simple:
{l Code}: {l Select All Code}
//Create a new block.
handle = createBlock(type,x,y)
//Set a certain property of the block
setBlockProperty(handl,'id',10)


I'm not sure how music/sfx/theme interact should be done, but I don't think it's a good idea to allow loading stuff from within scripts.
Resources should be managed at level or even at levelpack level.
This way the needed files can already be loaded and accessed by name when needed, a missing file should only be a warning and not interrupt the level.
{l Code}: {l Select All Code}
//Play sfx
playSFX('resource')
//Change music, fading set to true.
changeMusic('resource', true)


There are still some problems that I'm not 100% sure how to fix.
All handles will can become invalid when adding/removing blocks or changing the levelObjects vector in any other way.
One solution is making proper handles that point to the gameobject instead of the index.

On the other hand could we make this a warning, meaning that it's the levelmakers responsibility to make sure the handle is correct.
This may sound bad, but since the scripting is event driven it is known when the handle change.
From the start to the end of a script the levelObjects vector is untouched, unless the script changes it, in which case the levelmaker should be careful.

Another way this could go wrong, though, is if the script stores a handle for later use.
In that case it's near impossible to tell what has changed in between the scripts, so handles should never be stored, the id should be stored instead.

Also I think we shouldn't at any form of random behaviour in, for the following reasons:
  • It makes the replay incorrect (can be solved by storing the used seed)
  • Determining a target time/recording will be a lot harder.
  • Simply doesn't fit the puzzle aspect of the game.
But there are probably more ways to make it not deterministic, if we allow the script to get best time/number of recordings, window size properties, etc...
These can be used in many ways, but IMHO should only be used for enhancing the playing experience and NOT influence the level/game mechanics.

Finally there is a problem that the LevelEditor only allows linking triggers to "suitable" targets, in which case only those blocks can react with a script to these events.
I think we should allow linking to all blocks for more flexibility.
Maybe we should consider an "expert" mode for the LevelEditor, which allows such linkage and scripting, etc...
In the simple mode those things will be hidden from the user?

Suggestions and feedback are welcome! ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby Sauer2 » 03 Feb 2013, 01:51

How about modifying text boxes and things like path of spikes?
Just out of curiosity: How are you realizing this, technically? Also: Will there be an in-game script editor?
User avatar
Sauer2
 
Posts: 430
Joined: 19 Jan 2010, 14:02

Re: Scripting API

Postby acme_pjz » 03 Feb 2013, 07:26

Hi everyone,

Edward_Lii {l Wrote}:In my opinion the scripting should be event driven.
At the moment there can be one script for every GameObjectEventType there is per block.
When there's a script for a certain event, that script will be executed instead of the default behaviour.

I think it might be best to extend this a bit and add more events for which scripts can be written.
After loading the level, allowing the levelmaker to start action sequences, etc...
One thing I noticed is that GameObjectEvent_PlayerLeave is never used, so that needs to be implemented.


Sure ;) maybe we need an event which is executed at every frame.

Edward_Lii {l Wrote}:A script should be able to do the following things:

(1) Add/delete/move a block
(2) Change properties of a block
(3) Move the player and shadow
(4) Retrieve information from the player/shadow/block (e.g. location, in-view, block standing on, etc...)
(5) Start/stop music and sfx
(6) Change certain aspects of the theme
(7) Interact with the player by showing messages (and perhaps images?)
(8) Store values for use in other/later scripts


Don't you use Lua for scripting? Then (8) is automatically done ;) For (1)-(7) we need to write glue code, it shouldn't be hard IMHO

As for handle problems, Lua has fake object-oriented syntax, maybe we should use
{l Code}: {l Select All Code}
handle:setBlockProperty('id',10)
instead of
{l Code}: {l Select All Code}
setBlockProperty(handle,'id',10)

For the invalid pointer problem :| needs investigating... maybe we should use some GC feature in Lua library...

Sauer2 {l Wrote}:Just out of curiosity: How are you realizing this, technically?
Probably we will use Lua for scripting, just grabbing Lua at its official website, read documents, and writing some glue code :)

Sauer2 {l Wrote}:Also: Will there be an in-game script editor?

Maybe only a text box without syntax highlighting :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 04 Feb 2013, 09:54

Hello all,

I have made some progress regarding scripting.
A pointer to a block can now be retrieved using getBlockById:
{l Code}: {l Select All Code}
object = getBlockById("id")

I plan on making the id of a block configurable through the scripting window.
This will require some work to get it right, since it allows the user to change ids of already configured triggers/movingblocks/etc, which won't update the configure lines in the editor.

At the moment only the methods setLocation and getLocation are implemented.
But that's enough to allow scripts like:
{l Code}: {l Select All Code}
move = getBlockById('id')
x,y = move:getLocation()
x = x + 10
move:setLocation(x,y)


This also brings up a problem, which I forgot to mention in my first post.
Changes made to the objects in a script are applied to the same levelObjects vector as the editor uses.
So if a block is moved by a script it will be moved in the editor and stay there.

The easiest way to solve this is to store the complete editor state before entering playMode and reverting afterward.
If this performs well enough, we could use this for undo/redo. ;)

Another problem, which tomreyn warned us for on the irc channel is the possibility of "malicious scripts".
By default lua script can execute a wide range of function, including file access, executing binaries, etc...
We try to load the absolute minimum of libraries/methods, but a sandbox might be a good idea:
http://lua-users.org/wiki/SandBoxes

Sauer2 {l Wrote}:How about modifying text boxes and things like path of spikes?

This will hopefully be possible in the future.
I think paths for moving blocks might be quite tricky to make easy/straightforward.
But who needs paths when you can script the movement. :p
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 04 Feb 2013, 12:18

Edward_Lii {l Wrote}:This also brings up a problem, which I forgot to mention in my first post.
Changes made to the objects in a script are applied to the same levelObjects vector as the editor uses.
So if a block is moved by a script it will be moved in the editor and stay there.


For moving blocks, the original position is stored at 'boxBase'. The problem will be solved if we store original position for all block types.

Edward_Lii {l Wrote}:Another problem, which tomreyn warned us for on the irc channel is the possibility of "malicious scripts".
By default lua script can execute a wide range of function, including file access, executing binaries, etc...
We try to load the absolute minimum of libraries/methods, but a sandbox might be a good idea:
http://lua-users.org/wiki/SandBoxes


I think current approach is already a fake sand box, because our host program is C++ program, not Lua program, so we don't need such complicated code. Of course we should still disable some individual function, still investigating for which and how :think:
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 04 Feb 2013, 15:50

Hello all,

acme_pjz {l Wrote}:For moving blocks, the original position is stored at 'boxBase'. The problem will be solved if we store original position for all block types.

All blocks use this variable in svn revision 565 now and it works like a charm.
As for removing blocks, I think we should only "disable" them, effectively being removed for the game mechanics.

Adding blocks on the fly on the other hand is a bit of a problem.
We could change it so that pre-disabled blocks can be enable through scripts, which is sufficient in most cases, I think.
There might be a few use-cases where you really want to spawn in new blocks, although this could be solved with a "pool" of blocks. :think:

acme_pjz {l Wrote}: think current approach is already a fake sand box, because our host program is C++ program, not Lua program, so we don't need such complicated code. Of course we should still disable some individual function, still investigating for which and how :think:

I just want to be sure.
The biggest danger at the moment is the base library, it contains a lot of possible exploitable functions.
Maybe it's best to not load the base library and copy over/create our own implementation of print and any function we need.

Also the math, string, table and bit32 tables can quite easily be manipulated.
Although this can only break scripts, it could be used to cheat in scripted levels. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 04 Feb 2013, 17:51

Edward_Lii {l Wrote}:As for removing blocks, I think we should only "disable" them, effectively being removed for the game mechanics.

Adding blocks on the fly on the other hand is a bit of a problem.
We could change it so that pre-disabled blocks can be enable through scripts, which is sufficient in most cases, I think.
There might be a few use-cases where you really want to spawn in new blocks, although this could be solved with a "pool" of blocks. :think:


My idea is actually delete them, of course in a copy of 'Game' copied from 'LevelEditor' data. It will introduce invalid object reference problem, but I have a rough idea how to implement it correctly: Every user data contains three fields: a pointer point to the GameObject and the other two pointer points to the previous and next user data containing same GameObject, hence they form a (doubly) linked list. When a new user data is created (through 'getBlockById' and other functions), add it to the linked list (store the head of linked list to GameObject). When a GameObject is destroying, traverse the linked list and set the contents of all associated user data to NULL. And unlink the user data from linked list in '__gc' function of the user data. Using this mechanism, the script can store queried blocks for future use without invalid pointer problems. (Of course, the saved reference can be invalid, but we can detect it by checking whether the pointer is NULL.)

BTW, maybe we should add some signature as the first few bytes of the user data, prevent the (malicious) script transfers incorrect type of user data. For example, the blocks can have 'BLOK' and player can have some other signatures. I don't know if use C++ RTTI can solve this problem :|

Edward_Lii {l Wrote}:Also the math, string, table and bit32 tables can quite easily be manipulated.
Although this can only break scripts, it could be used to cheat in scripted levels. ;)


We can reset the whole Lua state (close it and create a new one) when restarting a level. Not sure if it will be slow :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 04 Feb 2013, 18:12

acme_pjz {l Wrote}:My idea is actually delete them, of course in a copy of 'Game' copied from 'LevelEditor' data. It will introduce invalid object reference problem, but I have a rough idea how to implement it correctly: Every user data contains three fields: a pointer point to the GameObject and the other two pointer points to the previous and next user data containing same GameObject, hence they form a (doubly) linked list. When a new user data is created (through 'getBlockById' and other functions), add it to the linked list (store the head of linked list to GameObject). When a GameObject is destroying, traverse the linked list and set the contents of all associated user data to NULL. And unlink the user data from linked list in '__gc' function of the user data. Using this mechanism, the script can store queried blocks for future use without invalid pointer problems. (Of course, the saved reference can be invalid, but we can detect it by checking whether the pointer is NULL.)

So if I get this right there's one linked list, which contains pointers to the previous userdata in the list, one to the next and a pointer to the corresponding GameObject.
A GameObject holds one end of the linked list (the head) and can, if needed traverse through the list to set pointers to him to NULL.

I assume this can be done by representing the userdata as a struct, holding three pointers?

acme_pjz {l Wrote}:BTW, maybe we should add some signature as the first few bytes of the user data, prevent the (malicious) script transfers incorrect type of user data. For example, the blocks can have 'BLOK' and player can have some other signatures. I don't know if use C++ RTTI can solve this problem :|

Not sure if this will help that much, it can prevent the script from sending incorrect type/garbage.
But if the script is capable of making it's own 'type' all that it has to do is add the 'BLOK' signature at the start followed by a few pointers.

I think RTTI won't help in this case, the danger lies in the fact that pointers might get altered.

acme_pjz {l Wrote}:We can reset the whole Lua state (close it and create a new one) when restarting a level. Not sure if it will be slow :|

I believe it isn't that slow, if we do it that we, we are at least sure there are no leftovers of any previous levels.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 04 Feb 2013, 18:50

Edward_Lii {l Wrote}:o if I get this right there's one linked list, which contains pointers to the previous userdata in the list, one to the next and a pointer to the corresponding GameObject.
A GameObject holds one end of the linked list (the head) and can, if needed traverse through the list to set pointers to him to NULL.

I assume this can be done by representing the userdata as a struct, holding three pointers?


Yes, a struct can :) But I prefer a CRTP template class, it can do all the tricks, once and for all :lol:

Edward_Lii {l Wrote}:But if the script is capable of making it's own 'type' all that it has to do is add the 'BLOK' signature at the start followed by a few pointers.


According to the manual, user data can only be made using C API ;) and its contents can't be read or write using script itself
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby acme_pjz » 05 Feb 2013, 13:38

I made a simple script test:
{l Code}: {l Select All Code}
name="Script Test"
size=800,600
tile(Block,0,100)
tile(Block,50,100)
tile(Block,100,100)
tile(Switch,100,50){
   behaviour=toggle
   id=0
   script(65536){
      script="
      local b=block.getBlockById('block1')
      if b~=nil then
         local x,y=b:getLocation()
         if y>=50 then b:setLocation(x,y-50) end
      end
      "
   }
}
tile(Switch,150,50){
   behaviour=toggle
   id=1
   script(65536){
      script="
      local b=block.getBlockById('block1')
      if b~=nil then
         local x,y=b:getLocation()
         if y<=500 then b:setLocation(x,y+50) end
      end
      "
   }
}
tile(Block,150,100)
tile(Block,200,100){
   id=block1
}


[EDIT] I think we should save the name of event in level file, instead of the number of event :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby acme_pjz » 05 Feb 2013, 15:29

An improved version of script test:
{l Code}: {l Select All Code}
name="Script Test"
size=800,600
tile(Block,0,100)
tile(Block,50,100)
tile(Block,200,100){
   id=block1
   script(onCreate){
      script="
      print('onCreate')
      block1=block.getBlockById('block1')
      "
   }
}
tile(Button,100,100){
   behaviour=toggle
   id=0
   script(playerIsOn){
      script="
      local x,y=block1:getLocation()
      y=y-1
      if y>=0 then block1:setLocation(x,y) end
      "
   }
}
tile(Button,150,100){
   behaviour=toggle
   id=1
   script(playerIsOn){
      script="
      local x,y=block1:getLocation()
      y=y+1
      if y<=550 then block1:setLocation(x,y) end
      "
   }
}
This level requires latest SVN revision.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 06 Feb 2013, 18:03

Hello acme_pjz,

Great progress, the scripting API is really getting along. :)

One thing I'm wondering is if we should use ScriptUserData for the player and the shadow.
I think it isn't needed since there will always be one player and one shadow.
Ideally the player and shadow userdata will be defined in the global scope so they can be accessed easily.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 07 Feb 2013, 08:43

Edward_Lii {l Wrote}:One thing I'm wondering is if we should use ScriptUserData for the player and the shadow.
I think it isn't needed since there will always be one player and one shadow.
Ideally the player and shadow userdata will be defined in the global scope so they can be accessed easily.


:cool: Yeah, the pointer for the player and shadow userdata is unnecessary, only a signature 'PLAY' and 'SHAD' for distinguishing whether the user data is player or shadow.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby acme_pjz » 15 Feb 2013, 17:36

Hi Edward_Lii,

How about move the function implementations from ScriptAPI.h to ScriptAPI.cpp? Only leave function declaration of luaopen_block, luaopen_player and registerFunctions in it, and remove luaopen_block, luaopen_player in ScriptExecutor.h :think:
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 15 Feb 2013, 17:39

Hello acme_pjz,

acme_pjz {l Wrote}:How about move the function implementations from ScriptAPI.h to ScriptAPI.cpp? Only leave function declaration of luaopen_block, luaopen_player and registerFunctions in it, and remove luaopen_block, luaopen_player in ScriptExecutor.h :think:

I agree, it makes more sense that way.
Feel free to change it. :)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 21 Feb 2013, 08:38

Hi Edward_Lii,

Maybe we should create test/example levels for each script function, and put them in documents? :)

BTW, why did you remove the doxygen comments from ScriptUserData.h in svn r600? :| These special comments prefix (/** in C, /// in C++) are used by doxygen to auto-generate documents :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 21 Feb 2013, 17:44

Hello acme_pjz,

acme_pjz {l Wrote}:Maybe we should create test/example levels for each script function, and put them in documents? :)

I think this is a great idea, but we might want to wait with doing that in case some things change as we go along.
There are still a few things I would like to implement, for example automatically creating a userdatum for the block that executes the script.
This way a block that doesn't influence other blocks can be scripted without giving itself an id and requesting that block by id every time.

About the doxygen comments, I changed them since it made the file look a bit out of place compared to the other files.
Doxygen documentation can still be generated by using an input filter, I wrote a small bash script that changes the comments in header files to doxygen comments.
AFAICS there are no problems/artefacts doing it that way, but if you need the doxygen comment style for something else (e.g. IDE) we could perhaps change all comments.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 22 Feb 2013, 14:27

Hi Edward_Lii,

Edward_Lii {l Wrote}:There are still a few things I would like to implement, for example automatically creating a userdatum for the block that executes the script.
This way a block that doesn't influence other blocks can be scripted without giving itself an id and requesting that block by id every time.


Yes, something like 'this' in C++ :) Should we put it in global scope?

Edward_Lii {l Wrote}:AFAICS there are no problems/artefacts doing it that way, but if you need the doxygen comment style for something else (e.g. IDE) we could perhaps change all comments.


I just wonder if in future we should make documents of source code, at least header files :| For example, the document of Lua functions exposed by the game. Change all existing comments is future work IMHO ;)
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 22 Feb 2013, 16:06

Hello acme_pjz,

acme_pjz {l Wrote}:Yes, something like 'this' in C++ :) Should we put it in global scope?

I was also thinking about naming it 'this' and I think we should place it in the global scope.

acme_pjz {l Wrote}:I just wonder if in future we should make documents of source code, at least header files :| For example, the document of Lua functions exposed by the game. Change all existing comments is future work IMHO ;)

I have used doxygen to generate html documentation for the project once, somewhere before V0.4.
It can still be found on the project web: http://meandmyshadow.sourceforge.net/doc/

At the moment I have doxygen running locally with an input filter that converts our comments to doxygen comment style.
I could upload that so you can see how it looks, not sure which configuration to use, though.
I let doxygen generate all fancy call and caller graphs and paste in the source code for each method since it can, but perhaps that's a bit over the top. :think:

We still need to implement the saving/loading of the lua_State.
At first I thought about using environments and storing those, but perhaps that isn't the best approach.
It depends on the way blocks will be removed/added if this is done, the userdata will be incorrect.
Maybe it's actually better to let the levelmaker implement save and load, this way only the needed variables are stored and userdata can be recreated.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 23 Feb 2013, 05:24

At first I thought about using environments and storing those, but perhaps that isn't the best approach.
It depends on the way blocks will be removed/added if this is done, the userdata will be incorrect.

Yes, the user data will be invalidated when C++ object pointer changed (e.g. object created or destroyed) :|
Maybe we should leave dynamic add/remove objects for 0.6 :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 16 Apr 2013, 18:44

Hello all,

There hasn't been much progress recently, partially because I'm quite busy. :(
What we should do is add a few more things to the scripting API, making it ready for V0.5.

acme_pjz {l Wrote}:Maybe we should leave dynamic add/remove objects for 0.6 :|

I fully agree, I implemented an enable state for blocks to substitute dynamic addition and removal of objects.
This way blocks can be disabled and re-enabled through scripting making them fully disappear, both visually and collision wise.

Another thing we should implement is the saving/loading of scripting variables.
I think the easiest way to do this is by also adding scripts to the level and add onCreate, onSave, onLoad(, onReset?) events.
A simple key/value pair system will probably be enough.
The scripts only have to be written if the level has checkpoints and scripts that keep track of a certain state.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby odamite » 17 Apr 2013, 15:59

Hello,

Edward_Lii {l Wrote}:There hasn't been much progress recently, partially because I'm quite busy. :(
What we should do is add a few more things to the scripting API, making it ready for V0.5.

I think that there's been much progress in general. We do have a well working scripting system right now. :D

Talking about V0.5, what should be still done? Are there any big features to implement? For scripting we should definitely have API documentation and some examples in our wiki. Other things to that could be done are general fixing for example GUI.

Edward_Lii {l Wrote}:I fully agree, I implemented an enable state for blocks to substitute dynamic addition and removal of objects.
This way blocks can be disabled and re-enabled through scripting making them fully disappear, both visually and collision wise.

Sounds great and useful :D

Edward_Lii {l Wrote}:Another thing we should implement is the saving/loading of scripting variables.
I think the easiest way to do this is by also adding scripts to the level and add onCreate, onSave, onLoad(, onReset?) events.
A simple key/value pair system will probably be enough.
The scripts only have to be written if the level has checkpoints and scripts that keep track of a certain state.

Sounds like a very important feature. I'm not so familiar with LUA but could something like global variables work in this situation for more flexible/native system than key/value pairs?
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: Scripting API

Postby Edward_Lii » 17 Apr 2013, 16:38

Hello odamite,

odamite {l Wrote}:Talking about V0.5, what should be still done? Are there any big features to implement? For scripting we should definitely have API documentation and some examples in our wiki. Other things to that could be done are general fixing for example GUI.

I don't think there are that many things to do before V0.5.
The scripting API should be "finished" up and documented as you stated.
The tutorial levelpack needs a complete overhaul and the GUI can use some fixing up here and there.

Other than that I think we're pretty much done. :)
There are some small things to do like bundling a CMake module for Lua 5.2.

odamite {l Wrote}:Sounds like a very important feature. I'm not so familiar with LUA but could something like global variables work in this situation for more flexible/native system than key/value pairs?

The problem is that we create a new lua_State every time a state is loaded.
So we'd have to store the values outside of Lua.

What we could do is keep the lua_State intact during a level.
This means that the levelmaker has to create save variables for each variable... :think:
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Scripting API

Postby acme_pjz » 18 Apr 2013, 05:54

Hi,

Edward_Lii {l Wrote}:I think the easiest way to do this is by also adding scripts to the level and add onCreate, onSave, onLoad(, onReset?) events.
A simple key/value pair system will probably be enough.
The scripts only have to be written if the level has checkpoints and scripts that keep track of a certain state.


Currently each block has its onCreate event... The level event is great :) but where should we add the text box to input level event scripts in level editor GUI? ;)

Edward_Lii {l Wrote}:The problem is that we create a new lua_State every time a state is loaded.
So we'd have to store the values outside of Lua.

What we could do is keep the lua_State intact during a level.
This means that the levelmaker has to create save variables for each variable... :think:


If you want to store the variables outside of Lua, then how do you decide which variables should stored? All variables? :| An acceptable idea... But if you want the level maker to decide it, then maybe you don't need to reset lua_State when state loaded.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Scripting API

Postby Edward_Lii » 18 Apr 2013, 16:47

Hello acme_pjz,

acme_pjz {l Wrote}:Currently each block has its onCreate event... The level event is great :) but where should we add the text box to input level event scripts in level editor GUI? ;)

I was thinking of adding a pulldown menu when right clicking in the background, just like the one for blocks.

acme_pjz {l Wrote}:If you want to store the variables outside of Lua, then how do you decide which variables should stored? All variables? :| An acceptable idea... But if you want the level maker to decide it, then maybe you don't need to reset lua_State when state loaded.

I think it's best to let the levelmaker handle it and simply create onSave and onLoad events.
At first I thought it would be best to (forcefully) store everything that is inside the lua_State, but this isn't really straightforward to do.

And who knows, maybe the onSave and onLoad events can be used for some interesting puzzles? ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Who is online

Users browsing this forum: Google [Bot] and 1 guest