Hash table, used as prefix in hashcode tag defines.
Sound effect.
Virtual filesystem used in EngineX games; it is made out of a single, uncompressed file (.000) and and a index or descriptor file with a .bin extension.
Same thing as EDB files. It's how the engine calls the main resource files, they generally sport the .EDB extension. These files are generated from the Output function of EuroLand, by munging/processing/cooking/optimizing/outputting/converting one or more .ELF files into a single, often self-contained .EDB blob and appending it to the Filelist.
One-off static data initialisation, for more information take a look here. These files are loaded once during bootup to grab their data and then deloaded.
Stands for EuroLand File. Not to be confused with UNIX-style program binaries, which also share the .ELF extension and are used in consoles like GameCube or PlayStation 2, that's a different thing. Eurocom's .ELFs shouldn't ship with the game, they are source files.
Name of the in-house Eurocom game engine for sixth generation consoles and beyond. Probably a play on words for Sphinx, the way they called other folders seems to confirm this: Sonix, Grafix, TeamX. Exes all the way down.
A music track.
Prefix used by map trigger types.
Prefix used by monster types, even if they are called monsters or enemies this also includes any kind of friendly NPC. So it would be better to call them agents or actors.
In Euroland lingo it refers to a standard, static 3D model. Without rigging, but they still contain UV coordinates, polygons, per-vertex colors, texture references, flags and LOD settings. One polygon can have multiple layers of materials to add details and break repetition.
A Excel .XLS file littered with special text markers to annotate type of sheet, rows, spans and columns. Euroland stores a path to the spreadsheet and reads it when outputting. A sheet can be marked as containing either special data or in-game text, for localization.
Euroland macro file. These small scripts, written in a custom language, can instrument and automate all kinds of tasks, letting Euroland run headless. Example macro scripts can be found in the Sphinx\GameSpec\Macros and ServerX\Sphinx\Project\Macros folders.
An interpreted piece of code written in the Sphinx Scripting Language, every trigger can have its own gamescript and a little text editor. We can use conditions, procedures, callbacks, read and write objectives, call game-specific operations; like giving gold Ankhs, displaying RPG dialogs, or setting the amount of scarabs, handling how we send and receive custom messages from and to other triggers we are connected/referenced to. To give an idea of how powerful this is, most of the Abydos minigames are entirely coded like this, as a complex web of gamescripted triggers. Displaying the connections between triggers as lines with arrows is fundamental to make sense of it.
A flexible event-based timeline made out of entities, animations. particles, sounds, cameras and even other scripts. There is no programming involved here, event blocks can be placed in a WYSIWYG editor in different lanes and their positions, movement, rotations and colors keyframed. They can be used as trigger animators to make interactive objects like levers or even cutscenes.
A self-contained, interactive but immobile thing in a map that exhibits special behaviors depending on its type. Generally, triggers at least have a position, a type, a name and a radius of action. The other common trait is that each trigger can connect with up to eight other triggers via their references tab, and can receive and send things like activation and deactivation messages. Other configurable properties vary, for more information take a look here.
Most triggers activate, creating their items and loading their animators when the player is within their radius of action and suspending (destroying by fading out the items) when not. Their state can also be saved via objective. For example, knowing if a door has been opened.
Items can be inspected via the corresponding debug window. Generally speaking, an item is the most basic kind of dynamic in-game object. They have a position, an orientation, a name, an item type and can be as simple or as complicated as required. Things like the player camera, or the player character itself, are items, as well as any small wandering fish spawned by an active trigger or any interactive object, hardcoded or not, created by the game.
Items by themselves do or show very little, they can be plugged a physics system into it to enable collisions or govern it via an item handler. An item contains a series of animators.
Any renderable 3D object. From rigged animations to humble particle systems. They need to be attached to an item in order to appear. When an item is rendered it renders any animators hooked into it. They only exist as part of that instance. The complete list of admitted animator types is: Script (for hashcode references of type/section HT_Script/0x04000000), Anim (HT_Animation/0x03000000), Entity (HT_Entity/0x02000000), Map (HT_Map/0x05000000), Particle (/0x11000000), Sound (either HT_Sfx/0x1a000000 or HT_Music/0x1b000000) and DynLight (HT_Light/0x13000000).
An EngineX window is the root of what can be displayed by EngineX. The main game window is what generally draws most of the 3D elements and sits at the bottom, covering the entire display. There are secondary windows that are overlaid during normal gameplay, like the HUD, or the Debug Windows or the Book of Sphinx, that always sit on top. Keep in mind that this doesn't have anything to do with the operating system windows; they are hierarchical abstractions that reside within the bounds of the framebuffer. They exist to draw items.
A display draws a series of EngineX windows, recursively. Every rendered frame. As long as they are enabled.
A persistent piece of information that survives game restarts/level reloads and can track in-game progress. They are stored in savegames and restored at load time. Each objective has a hashcode tag and its value can store an unsigned 32-bit number. The final version of Sphinx has space for 1700 objectives, of which 1379 are already defined in hashcodes.h, albeit a good portion are beta/unused and can probably be reused without affecting the normal game state. Search for HT_Objective_Pairs_InProgress or HT_Objective_HASHCODE_END.
Book of Sphinx, the inventory screen. Originally included the map viewer, stats with number of steps and other niceties. It's also used by the Mummy, even if their inventories are stored separately.
Community content is available under CC-BY-SA unless otherwise noted.