How DimensioneX Works – 2
Posted on Dec 22, 2014 | 0 comments
1.2.2 Custom command panels
Available commands are determined by sets of controls named PANELs.
The game engine has a pre-defined set of available commands which produce a series of a well known events and actions. The game programmer, though, can produce custom command panels and use them in the game, as well as she can define custom events to be triggred when custom controls are used.
Command PANELs can be assigned to players and to rooms via the PANEL tag in the game’s design section, or via the SetPanel instruction at run time.
During gameplay, the player is always located in a room. The available, displayed commands will be a combination of commands associated to the player and commands associated to the room:
Available commands = commands from player’s panel + commands from room’s specific panel
Check out the following sections for more information:
- DimensioneX DXW Reference -> PANEL definition
- DimensioneX DXW Reference -> ROOM
- DimensioneX SmallBasic Reference -> Instructions -> SetPanel
See also the Panels Demo included in the DimensioneX kit.
The panels used in login/logout sequences can be customized, too, but in the present version you have some limitations regarding custom scripts to be executed during these sequences. See “Game connection sequence” below for more details.
1.2.3 Dynamic pages and descriptions
Although DimensioneX is not designed to work as a dynamic website platform, in a number of cases you want a description of a room or object to dynamic.
The description property of each object can be made dynamic by placing a traling [email protected] sign in front of a function call, example:
Will produce a dynamic description by executing and using the return value of myFunction($AGENT).
This is very handy for displaying context-menus associated to rooms and objects, without the need to using system events.
Since each room you are into displays a web page on the client, this gives the game designer the freedom to use DimensioneX as it was a kind of dynamic site platform. It is important to bear in mind, though, that dynamic descriptions force the game engine to run code each time a user looks somehow at that specific room and object, and therefore they consume lots of CPU time.
Using system events instead of dynamic descriptions can, in most cases, improve your game performance.
1.2.4 Game connection sequence
The sequence for login/logout/save and exit/restore saved game (both panels and logic behind) are built-in the game engine and ready to use.
Recently an increasing number of users expressed the need to customise the logon sequence.
In the present release, all panels can be customised so the game programmer can easily add a field to any of the panels and remove existing ones, just be re-definining the correct panel via its panel ID (See the section: DimensioneX DXW Reference -> PANEL definition for more details).
The logic behind the panels, though, cannot be customised in the present version. In other words, if we add a new field for the player’s e-mail there is no software hook to let us specify what to do with such piece of information.
For this reason, it is recommended that game developers use the standard sequences at present. They can, however, add special, custom ROOMs and write the proper scripts to add steps for players entering the game, where we let them specify their e-mail address, etc.
Experienced developers can modify the java sources to alter the game engine behaviour if the solution proposed above don’t fit their purposes.
1.2.5 Game Object Types
For the DimensioneX game engine, all the game objects are intrinsically the same type. The same applies for characters/players.
Nevertheless, it is useful in the game to have a means to distinguish between similar objects.
In true OOP languages, the programmer is forced to plan in advance and design a class hierarchy so fitting the program objects.
In the DimensioneX game scripts (SmallBasic language), there are some devices to simulate what OOP programs do. These tools are:
- The TYPE property
- Attached events
The TYPE property is some string with the form:
For example, the following definition:
ITEM sword1 TYPE sword.steel
ITEM sword2 TYPE sword.iron
Tells the game engine we are defining two items of type=”sword” which slightly different as the subtype tells us.
If, at a certain point in the game, we need to detect swords in the room, we can use the getObjectType function like this:
iron_swords = getObjectsType($WORLD,”sword.iron”) ‘ only those made of iron
all_swords = getObjectsType($WORLD,”sword”) ‘ all swords
Also, we can use the AttachEvent instruction to tell the game engine that the steel sword has a slightly different effect than the iron sword has.
Upon clicking USE and any of the two swords, they will behave differently.