Yesterday I spoke a lot about the Selenite Editor; explaining that it basically is a 'game maker' tool where the game developer can create complex gameplay in a small amount of time.
While that will probably require more explanation to understand the fine details of what is possible; suffice to say game objects can be created and scripts to govern their action can be written.
After the developer has poured in all of this data, I mentioned that the Selenite Editor produces 'Build Products'; we're now going to have a look at what the build products actually are.
The editor exports two files, and a directory of files;
Those first two files are the most important, they are classes.bin and game.bin; these two files make up constant data and the initial state data for the game.
classes.bin
This file, as you might imagine contain 'classes'; most programmers here will be familiar with the concept of a class, as a building block for creating a template for a reusable set of data and functionality. What Selenite considers a class isn't much different
The Selenite Class Object
Class-Object might sound like an oxymoron; but to selenite is it a runtime object which defines various pieces of data; the data a particular class object holds depends on its type.
There are three first-class Class Object types, GameClass, RoomClass and ActorClass; each of these class types 'backs' a corresponding instance of the same type (Game,Room,Actor).
While these three are the only script-accessible types, they actually share some common base classes
StateClass::GameClass
StateClass::DisplayClass::RoomClass
StateClass::DisplayClass::ActorClass
StateClass
Contains a dictionary of eventName and scriptResourceHash, which represents the scripts an object can run.
Contains a dictionary of soundClasses, where each sound class has a string id (ex. "bang") and the sound class stores if the sound is Music or an Effect, if it loops endlessly or not, and the resource hash for the actual sound data.
GameClass
Contains a dictionary of items, keyed by item id, and holds the item description (for the player) and a max value, that determines the maximum amount of an item you could ever posses; in addition to the item image id, as a resource hash.
A dictionary of languages, keyed by language id, where each language object contains translation strings, optional voice-over resource hashes and optional lip-sync viseme data.
A dictionary of videos, keyed by video id, with a resource hash to the video file.
A set of interface skins, as resource hashes, used to skin the interface components, such as the subtitle panel, item menu, topic menu, etc.
DisplayClass
Contains a list of ShapeDefenitions, either circles or polygons (3 to 8 point range) which represent the collision boundaries, and physics properties (friction, restitution, etc.) for an object (both rooms and actors have collision shapes)
RoomClass
Dimensions of the room, in both full tile size (256x256) cols and rows
and width and height in pixels (as room background images rarely fall on 256x256 boundries)
Contains a dictionary of Markers, a marker is a named point in space, accessible via scripts to position things by name instead of absolute coordinates.
A list of 256x256 images (cols*rows), as resourceHashes which makeup the map background image.
ActorClass
A dictionary of animation sheets, which contain the frame data and images as resourceHashes.
A dictionary of topics, keyed by topic id, which contain the text used for the topic for display.
A bundle of data
Together these three class types make up a library of data used for instances; the key is that the data in the class objects are runtime-immutable; and as such it doesn't get factored into the game-state.
In my next post we'll talk about the flip side; The Instance Objects
