Looking for a diagram type for event based scripts
by Kyrah Abattoir · in Game Design and Creative Issues · 05/21/2011 (7:52 am) · 13 replies
I am programming a small autonomous game entity which interact with the game world through events:
-when the script start.
-if the player touches it.
-if it receives a text message from another entity.
-when a specific time is reached.
This entity is fairly complicated in it's functions because it's doing some limited state tracking between events, and i have trouble actually programming it directly.
I was hoping to first make a comprehensive diagram ( UML or something else ) that present in a schematic view the different communication steps between the entity and it's environment, some sort of visual pseudocode.
I'm hitting a wall because the problem i'm working on is not OOP programming and most of the UML related diagrams assume that you are describing classes, and even tho it is an event based system, the code is completely sequencial.
Is there a prefered diagram system that peoples use to describe the inner workings of a program/entity that runs in an event based scripting environment?
My problem is basically to find the best way to model the tracking of the object's state across events and it's communication with the other objects (and ensure I do not make errors when translating the model into code)
-when the script start.
-if the player touches it.
-if it receives a text message from another entity.
-when a specific time is reached.
This entity is fairly complicated in it's functions because it's doing some limited state tracking between events, and i have trouble actually programming it directly.
I was hoping to first make a comprehensive diagram ( UML or something else ) that present in a schematic view the different communication steps between the entity and it's environment, some sort of visual pseudocode.
I'm hitting a wall because the problem i'm working on is not OOP programming and most of the UML related diagrams assume that you are describing classes, and even tho it is an event based system, the code is completely sequencial.
Is there a prefered diagram system that peoples use to describe the inner workings of a program/entity that runs in an event based scripting environment?
My problem is basically to find the best way to model the tracking of the object's state across events and it's communication with the other objects (and ensure I do not make errors when translating the model into code)
About the author
3D artist, programmer, game designer, jack of all trades, master of none.
#2
05/21/2011 (9:13 am)
I will look into this once i'm back home, anything else i should look into?
#4
My system rely on several objects and they don't really have finite states, I made a diagram of the relations between the objects:
http://bayimg.com/fAIaPaaDd
The basic idea is that we have 3 main compnent, the "furniture" entity which is the one the player is activating, the "MultiObject" entity which act as a single slot programmable inventory.
Based on what class of ingame item the multiobject is loaded with at the moment, the furniture object will deduct what action was attempted by the player
(multiobject is loaded with "wrench" data and the player clock an air conduit, the air conduit understands the player ment to unscrew it open)
what happened under the hood is that as the player clicked the furniture object, this one sent a broadcast message asking to identify the multi object that is eventually worn by the player, this one will answer by a short summary if it's currently loaded data.
From this point, depending of the furniture object it can decide to simply perform it's own action or it can decide to change the data inside the multi object, for example it can decide to break the wrench, and for this it will send a "write" message to the multi object with the new data.
all of this is split across multiple touch and message listening events, and it gets quite hairy pretty quickly, hence why i'm looking for the most sensible way to lay flat how each element work and interact with eachothers and which decisions they take before even trying to code it (i scraped already 3 versions of the system)
For those who feel it's a horribly convoluted way of doing things, it's not exactly on torquescript but in an embedded scripting engine where each script is protected from the others so they cannot go write in eachother's memory space (which would have been very convenient).
I have no say in changing this system so it's how it's gonna be.
05/21/2011 (10:19 am)
Thanks for all this, i've been looking at the UML FSM example and based on the examples it seems to work the best for simple automatons that... well in essence have only a couple of finite states in which they can be.My system rely on several objects and they don't really have finite states, I made a diagram of the relations between the objects:
http://bayimg.com/fAIaPaaDd
The basic idea is that we have 3 main compnent, the "furniture" entity which is the one the player is activating, the "MultiObject" entity which act as a single slot programmable inventory.
Based on what class of ingame item the multiobject is loaded with at the moment, the furniture object will deduct what action was attempted by the player
(multiobject is loaded with "wrench" data and the player clock an air conduit, the air conduit understands the player ment to unscrew it open)
what happened under the hood is that as the player clicked the furniture object, this one sent a broadcast message asking to identify the multi object that is eventually worn by the player, this one will answer by a short summary if it's currently loaded data.
From this point, depending of the furniture object it can decide to simply perform it's own action or it can decide to change the data inside the multi object, for example it can decide to break the wrench, and for this it will send a "write" message to the multi object with the new data.
all of this is split across multiple touch and message listening events, and it gets quite hairy pretty quickly, hence why i'm looking for the most sensible way to lay flat how each element work and interact with eachothers and which decisions they take before even trying to code it (i scraped already 3 versions of the system)
For those who feel it's a horribly convoluted way of doing things, it's not exactly on torquescript but in an embedded scripting engine where each script is protected from the others so they cannot go write in eachother's memory space (which would have been very convenient).
I have no say in changing this system so it's how it's gonna be.
#5
You have one object that is stationary in your world (furniture), and one object that is carried by the player (multiObject). When the player interacts with it, the stationery object test to see if the player has the correct multi-object, and depending on some internal variable this interaction can have different outcomes?
Your diagram makes sense, the only thing I would do slightly different is I would make your multiObject part of the player since the player is the one interacting with the furniture and the multiObject is owned by the player.
Is this for Second Life?
05/21/2011 (10:59 am)
If I understand you correctly:You have one object that is stationary in your world (furniture), and one object that is carried by the player (multiObject). When the player interacts with it, the stationery object test to see if the player has the correct multi-object, and depending on some internal variable this interaction can have different outcomes?
Your diagram makes sense, the only thing I would do slightly different is I would make your multiObject part of the player since the player is the one interacting with the furniture and the multiObject is owned by the player.
Is this for Second Life?
#6
I've been scripting in secondlife for about 5 years now. I guess the retarded environment limitations gave it away :)
So you probably know i can't make the multiobject part of the avatar entity.
ANother key element that make me unable to "see" the Final state machine model to work is tha tthe multi object can be reprogrammed on the fly, it ha sa set of toggleable stock behaviors, (particles emitting,sould emitting, beacon broadcast,...) that can be turned on and off by a furniture, aswel as a few all purpose variables (store the number of matches left in a matchbox for example) and about 5 prims worth of appearance data (this is why i had to also write a "buffered string transfer" protocol so I could pass more than 1024bytes of text at once)
05/21/2011 (11:02 am)
You got me :)I've been scripting in secondlife for about 5 years now. I guess the retarded environment limitations gave it away :)
So you probably know i can't make the multiobject part of the avatar entity.
ANother key element that make me unable to "see" the Final state machine model to work is tha tthe multi object can be reprogrammed on the fly, it ha sa set of toggleable stock behaviors, (particles emitting,sould emitting, beacon broadcast,...) that can be turned on and off by a furniture, aswel as a few all purpose variables (store the number of matches left in a matchbox for example) and about 5 prims worth of appearance data (this is why i had to also write a "buffered string transfer" protocol so I could pass more than 1024bytes of text at once)
#7
05/21/2011 (11:43 am)
I haven't played with LSL since 2007, but can't you just "attach" the multiObject to the Avatar? Also when you say the multiObjects can be reprogrammed on the fly, do you mean by the user? I thought that multiObjects are just a generic object class, that programmers use to create their own objects from?
#8
CLASS //STRING unique keyword for each object type
CAPACITY //FLOAT capacity of the object
MAX CAPACITY //FLOAT max capacity of the object
EXTRA DATA //FLOAT extra eventual data
CONTENT //STRING hovertext value for content usually.
EXTRA TXT //STRING hovertext value for feature usually.
PRIMCOUNT //INTEGER the number of prims of the appearance (for serialize command)
FULL data (only equested during a full transfer):
IDLE ANIMATION //STRING eventual idle animation, not played if not found.
SOUND START //KEY eventual sound start.
SOUND LOOP //KEY eventual sound loop.
SOUND END //KEY eventual sound end.
SOUND VOLUME //float sound volume.
FEATURE //INTEGER bitfield, indicate if the object possess specific features
HAND OFFSET //vector offset for hand held objects
HAND ROTATION //rotation rotation for hand held objects
DROP OFFSET //VECTOR offset of the root prim from the ground
DROP ROTATION //ROTATION rotation of the object from the ground
PRIM data (only requested during a full transfer):
PRIMDATA1 //CSV list of primitive parameters, this is the root prim when dropped MUST NOT CONTAIN ROT
PRIMDATA2 //CSV list of primitive parameters
PRIMDATA3 //CSV list of primitive parameters
PRIMDATA4 //CSV list of primitive parameters
PRIMDATA5 //CSV list of primitive parameters
EXTRA data:
OWNER //KEY who own the system we are currently tied to (if not tied, NULL_KEY)
USER POS //VECTOR user's position at the moment (fetched every query).
USER ROT //ROTATION user's rotation at the moment (fetched every query).
I have a specific message used by furniture objects that is the equivalent of a "ping" targeted to the user's key, the multiobject concerned will answer with a quick summary if it's stored data (the "SOFT" section)
From this the furniture object can then determinate the object class (what it is for the program)
and all the stored variables (capacity/max capacity/extradata/content/extratxt)
From there it can demand the full data set, which includes also the object's appearance (up to 5 prims worth of prim parameters) and do whatever it wants with it.
It can also send a "write" command to the multiobject with a new set of data (partial or full) which is equivalent to "reprogramming" the multi object with a new canned behavior, class and appearance, which allow to extend the system beyond what the multi object was initially designed for.
The rezzer is an object unique to the simulator, it's goal is to rez on demand of any multi object in the simulator a "sponge" object that will copy the content of the multi object and impersonate it when a player wishes to "drop" an object on the ground (this is also why the multi object include a ground rotation value, so the object will look properly once it has been cloned and placed at the avatar's feets)
I'm not sure if it was necessary to go to such "depth" in explaining what i'm working on, but i hope it helps you understand the kind of diagram i might use to describe the behavior of this system :D
The issue at hand is that it makes me work with large segments of data and behaviors scattered across several scripts and different scopes and i end up not being able to figure out what i'm doing.
05/21/2011 (12:35 pm)
Basically my multi object is a big data "cube" attached to the avatar with the following informations stored in it:CLASS //STRING unique keyword for each object type
CAPACITY //FLOAT capacity of the object
MAX CAPACITY //FLOAT max capacity of the object
EXTRA DATA //FLOAT extra eventual data
CONTENT //STRING hovertext value for content usually.
EXTRA TXT //STRING hovertext value for feature usually.
PRIMCOUNT //INTEGER the number of prims of the appearance (for serialize command)
FULL data (only equested during a full transfer):
IDLE ANIMATION //STRING eventual idle animation, not played if not found.
SOUND START //KEY eventual sound start.
SOUND LOOP //KEY eventual sound loop.
SOUND END //KEY eventual sound end.
SOUND VOLUME //float sound volume.
FEATURE //INTEGER bitfield, indicate if the object possess specific features
HAND OFFSET //vector offset for hand held objects
HAND ROTATION //rotation rotation for hand held objects
DROP OFFSET //VECTOR offset of the root prim from the ground
DROP ROTATION //ROTATION rotation of the object from the ground
PRIM data (only requested during a full transfer):
PRIMDATA1 //CSV list of primitive parameters, this is the root prim when dropped MUST NOT CONTAIN ROT
PRIMDATA2 //CSV list of primitive parameters
PRIMDATA3 //CSV list of primitive parameters
PRIMDATA4 //CSV list of primitive parameters
PRIMDATA5 //CSV list of primitive parameters
EXTRA data:
OWNER //KEY who own the system we are currently tied to (if not tied, NULL_KEY)
USER POS //VECTOR user's position at the moment (fetched every query).
USER ROT //ROTATION user's rotation at the moment (fetched every query).
I have a specific message used by furniture objects that is the equivalent of a "ping" targeted to the user's key, the multiobject concerned will answer with a quick summary if it's stored data (the "SOFT" section)
From this the furniture object can then determinate the object class (what it is for the program)
and all the stored variables (capacity/max capacity/extradata/content/extratxt)
From there it can demand the full data set, which includes also the object's appearance (up to 5 prims worth of prim parameters) and do whatever it wants with it.
It can also send a "write" command to the multiobject with a new set of data (partial or full) which is equivalent to "reprogramming" the multi object with a new canned behavior, class and appearance, which allow to extend the system beyond what the multi object was initially designed for.
The rezzer is an object unique to the simulator, it's goal is to rez on demand of any multi object in the simulator a "sponge" object that will copy the content of the multi object and impersonate it when a player wishes to "drop" an object on the ground (this is also why the multi object include a ground rotation value, so the object will look properly once it has been cloned and placed at the avatar's feets)
I'm not sure if it was necessary to go to such "depth" in explaining what i'm working on, but i hope it helps you understand the kind of diagram i might use to describe the behavior of this system :D
The issue at hand is that it makes me work with large segments of data and behaviors scattered across several scripts and different scopes and i end up not being able to figure out what i'm doing.
#10
Altho the diagram example looks interesting. Maybe i should inspire myself from it...
05/21/2011 (1:29 pm)
Erm isn't this a code generator?Altho the diagram example looks interesting. Maybe i should inspire myself from it...
#11
05/21/2011 (1:35 pm)
Good luck! :)
#12
05/21/2011 (5:48 pm)
Thanks :) if anyone else has a suggestion feel free to add up i'm sure it can benefit more than only myself :)
#13
Which i do not want to if possible. Because it isn't as modular.
So i'm back to square one...
05/22/2011 (4:33 am)
Okay i tried for some time this morning, the Fixed State Machine diagram type is not really helping me, if anything it's making me second guess my coding style and encourage me to basically use states.Which i do not want to if possible. Because it isn't as modular.
So i'm back to square one...
Torque Owner Alain Labrie
Ware-Wolf Games