-
Notifications
You must be signed in to change notification settings - Fork 2
Core Concepts
Core terms:
| Term | Explanation |
|---|---|
| Game Controller | A prim in a level that contains all the code that controls the level. In the obstacle course levels it's the "Join Game" pad. |
| Event | ObstacleScript is event driven, everything happens in the event block. |
| Method | A way of sending data from one script to another, including inter-linkset. |
| Module | A script that's using the ObstacleScript event handler |
| Asset | An object spawned in a level |
| Portal | A script that links Assets with the level |
| HUD | The XOBJ HUD |
| Level DB | In SL database that stores information on where/how Assets should spawn. |
The HUD is mostly used as an RLV relay, visual effects, and quick time events. The gameplay is controlled by the level controller.
- The pink bar in the obstacle courses are created by the level going "Create a bar with this color, and set the percentage value to this". It's just a visual effect and the HUD doesn't have any information of what the HUD does or not.
Methods are a way of communicating with a specific script directly. Methods are called through the runMethod function, but are usually abstracted away in header files to easy to use macros such as Rlv$exitMouselook( target ). Methods can be run either within a linkset, or between objects.
Unlike methods, events can be captured by every script in a linkset. They're raised internally within the linkset. In order to have an external script raise a method you need to do that through an external input such as a method or built in event. The standard SL events are also events.
ObstacleScript events are raised by using raiseEvent, and can be captured through an if statement (commonly you'd make event handler macros).
For an instance you could manually use: handleEvent( "Level", LevelEvt$mainMenu ) ...code... end, or use the built in macro onLevelMainMenu() ...code... end
Since ObstacleScript wraps everything between two includes, using one singular event handler. You can't add the default event handlers the normal way of ex: touch_start( integer total ){}, but you have to make a define at the start of the script that you want to use it. Ex: #define USE_TOUCH_START. This allows you to use the ObstacleScript event handler onTouchStart( total ) ...code... end
See a list of implemented LSL events here.
The level uses a standard LSL prim media DB to store a table of assets. After setting up the scripts, you can save any rezzed Assets to the DB by saying SAVE. The DB allows you to store:
- Name of object
- Position relative to root
- Rotation relative to root
- Description
- Spawn label
The first 3 are just used in rezzing.
The description can be read by the Asset after spawning and initializing. Usually this is a JSON array allowing you to configure the object. Such as setting up keyframes where a trapdoor should move, or how far a crusher wall should move.
The spawn label allows you to group assets to rez. An empty spawn label "" is the default, and used for any objects that should spawn initially. Note that the obstacle courses only use "" as all obstacles should be spawned at once. But this could be used if you wanted to make a linear stage where things spawn as the players advance.
To see a list of commands to interact with the DB, check the main page.
An asset is considered an item that's spawned by the level. These all rely on the Portal script to link them to the level database.
The core philosophy of xMod is that the level controller (the board that controls the game) should have as much control over the gameplay as possible. Usually the Assets (such as the obstacle course obstacles) will take commands from this central controller, and/or send events to the main controller when something happens.
- The crusher walls in the obstacle course levels won't move on their own. The level controller tells them when they should move, and their description tells them how they should move.
- The wall tentacles send a message to the level controller when someone collides with them. The level then tells the tentacle to grapple that player.
Exceptions can be used when an item needs as quick of a reaction time as possible, or when offloading their behavior to the level controller would eat too much script memory (such as the shimmy walls).
Items can be injected into the players HUDs by the level controller. Todo.