Previous posts in this series have focused on the technical aspects of getting the G-Engine up and running. For this post, I’m going to take a short break from writing engine code to instead analyze how GK3 is built. It’ll be important to understand this as I move forward and try to recreate it.

As a data-driven game, GK3 makes heavy use of various custom data and file formats. I’ll refer to each piece of data as an asset.

A key challenge in this project is understanding what the different asset types are, how they relate to one another, how to parse and load them into memory, and how to make use of them at runtime in a meaningful way. The developers would have documented all this, but much of that is unavailable to me - time for some detective work!

This post focuses on those first two questions: what are the different asset types, and how do they relate to one another? We’ll take a look at the various assets, what they do, and the web of relationships between them.

Barn Archives (.BRN Extension)

The average commercial video game will contain thousands of assets for 3D models, image files, sounds, gameplay logic, and other custom data defined by programmers and designers. It’s actually uncommon to ship a game with all those assets existing as “loose files” on the hard drive. It’s much more common to combine a bundle of assets into an “archive” of some sort. There are a couple reasons for this:

• Shipping loose assets would make it easier for players to either modify assets or use them for other purposes
• Loose assets are easier to misplace or accidentally delete, causing the game to malfunction in some way
• There may be limits on the number of simultaneous files you can access at one time when the game is running
• Loading individual files from the hard drive with separate file streams may be slower than either loading a single archive in full or seeking around to load individual parts of the archive
• Lumping assets into archives can be helpful to only load assets needed for a particular part of a game, which assists with memory management

GK3 stores all its assets in a handful of archive files called “Barns.” GK3 ships with a total of eight barns:

• ambient.brn
• common.brn
• core.brn
• day1.brn
• day2.brn
• day3.brn
• day23.brn
• day123.brn

As you might guess, the “day1” barn contains files used only during “day 1” in the game, “day2” has assets only used during “day 2”, and so on.

Why are they called “barns”? Comically, several of the asset types used by the engine are named after animals. In keeping with that theme, someone must have considered that a container holding many types of animals is sometimes called a “barn.”

These archives are essentially just giant blobs of binary data. The first X bytes of the blob can be considered a “header” and “table of contents,” explaining what assets exist in the archive and what byte offsets each asset exists at. At runtime, we open the archive, read the header data, and then seek to various assets to load them into memory and use them during gameplay.

All the assets we talk about below are stored in Barn archives on disk. Even though some assets are text-based, they are still part of the binary archive format - we just interpret those particular parts of the archive as text data instead of binary data.

Graphics & 3D Assets

The bedrock of any 3D game engine will be support for various graphics data formats to enable rendering interesting 3D scenes. GK3 uses a relatively limited set of resources to define renderable geometry and images.

Image Files (.BMP Extension)

GK3 makes use of BMP files for 2D image data, or textures. You may know BMP as a fairly common image file format.

BMP files are known to be quite large and “uncompressed” usually, but the BMP specification actually allows for a variety of different internal data formats. GK3 primarily makes use of two variant BMP formats: a standard 8-bit palettized format, and a non-standard compressed format.

8-bit Palettized BMP Files

This variant matches the documented BMP file format where the file contains a palette of colors (defined in RGBA 32-bit format) and each pixel of the image is stored as an 8-bit index (0-255) into that palette. This limits the number of colors you can use in the image to 256, but it saves a lot of space because each pixel is only 1 byte.

This format is only used for a few special purposes. The main use is for “walker boundary” assets, which store the walkable areas in each scene of the game in a texture format - different colors indicate whether spots on the floor are walkable. The game also contains some scripting support for turning on or off certain walkable areas based on the palette indexes associated with certain floor areas in these files.

The only other use I’ve seen is to sometimes hold an alpha channel for an otherwise opaque image. For example, inventory item images are stored as opaque compressed BMP files, but the alpha channel is stored in 8-bit palettized format. In this case, the palette index corresponds to a certain amount of alpha from 0-255.

Compressed BMP Files

This variant does not follow the documented BMP file format - it is custom. These can be identified by a unique 4-byte identifier at the beginning of the file (0x4D6E3136, or “Mn16” in ASCII). The “16” in the identifier refers to the fact that this is a 16-bit (or 2-byte-per-pixel) image format. Each pixel is stored in 16 bits where 5 bits are used for Red/Blue and 6 bits are used for the green channel. This equates to a relatively common “RGB565” format.

This format is used for the majority of the game’s visual texture assets. So, like 95% of the textures in the game use this format.

GK3 does not support any image format with an alpha channel. As a result, most of the images in the game are opaque. In situations where we need pixels to be either 100% opaque or 100% transparent, a magenta-based chroma key method is used. If semi-translucent pixels are desired, the only option is to use a separate 8-bit palettized alpha channel texture, as described above.

BSP Geometry (.BSP Extension)

Binary space partitioning is a method to efficiently and correctly render static 3D geometry in games that was commonly used during the 90s and 00s - some notable examples are Doom, Quake, Unreal, and Half-Life. You can still find BSP in some games today, but it is less common than it used to be. Unreal Engine 4 still provides support for BSP mainly as a method of quick level design iteration: Unreal 4 BSP Docs.

GK3 uses BSP to render the majority of the static 3D geometry in the game. The primary limitation for BSP is that the 3D geometry is static - it can’t be easily repositioned and it can’t animate. As a result, BSP is commonly used for things like buildings, terrain, foliage, furniture, and various unmoving props of any kind.

BSP assets are binary. They mainly contain 3D geometry data used for rendering, but they also contain some relevant gameplay data, such as the “names” of certain objects in the scene. For example, if all the polygons in the BSP that make up a bench may have the name “Bench”. Elsewhere, game designers define “Bench” as a thing you can interact with.

A BSP asset contains one or more “objects.” Each object consists of one or more surfaces, and each surface consists of one or more polygons. The surface also defines textures, uv scale/offset, and other attributes. BSP geometry also contains some lighting data, but I’m not sure whether this is actually used at runtime. GK3 has some basic lighting support, but it seems much simpler than what is contained within the BSP.

BSP assets are mainly referenced from scene assets to define the overall look of a particular location in the game. During gameplay, BSP is queried frequently for things like floor height and checking whether a user clicked on a particular object in the geometry for interaction purposes. The BSP asset used for a scene is either explicitly defined in a scene asset, or if the scene asset doesn’t specify a BSP to use, it is implied to be the BSP with the same name as the scene file.

BSP assets reference texture assets to define what texture a surface should use.

MUL Files (.MUL Extension)

I have not gathered much info on this asset yet - it remains a bit of a mystery. Based on how it is used within scene assets, I suspect this is lighting data that is used in conjunction with BSP.

GK3 has several locations that are visited at different times of day. A location with particular BSP geometry is sometimes visited in the morning, afternoon, evening, or night. Rather than duplicate BSP assets that differ only by their lighting data, storing the lighting data in a separate asset allows the same BSP to be used in conjunction with multiple lighting variations.

MUL files are binary; thus far I have not been able to decipher much about them!

They are referenced as part of scene assets.

3D Models (.MOD Extension)

GK3 uses a custom 3D model format with a .MOD extension (for “model”, I presume). The files are binary and fairly complicated - some portions of the format I have not yet figured out.

Each GK3 model consists of one or more “meshes.” Each mesh consists of one or more “submeshes.” Each submesh consists of vertices, indexes (for rendering indexed geometry), uv coordinates (for texture mapping), normals (for lighting) and a texture name. The texture name correlates to a BMP file that should be used as the texture when rendering the submesh.

The format also supports LOD (level of detail), though this isn’t used frequently. There are additionally some mysterious “MODX/GRPX” blocks in the binary files - these seem like possibly additional metadata or additional vertex attributes for the model, but I haven’t yet deciphered that.

GK3 models were authored in 3D Studio Max and exported to the custom MOD format. 3D Studio Max files are exported with the z-axis up and x/y-axes for the floor. GK3 uses y-axis up and x/z for the floor, so some conversion is required when importing the MOD files. Usually, this sort of conversion would occur at build-time, but for whatever reason, that isn’t generally the case here. However, it’s easy to flip these values when reading in the file.

Models can be used to render static geometry, but they are usually used for dynamic or animating 3D objects. If you need an object to play an animation or move around the scene, you need to use a model instead of BSP geometry.

GK3 models are referenced in many scene assets (SIF and SCN assets), since a particular scene of the game will often be made up of one or more 3D models. GK3 also uses vertex-based animation (as opposed to skeletal animation), so vertex animation files (ACT assets) reference specific MOD files.

Each submesh in a model specifies the texture asset that should be used when rendering.

Animation Assets

When you think of an animation in games, you probably think of either a traditional 2D “cell-based” animation or a 3D model animated via a skeleton or vertex animation. However, GK3 also has a higher-level animation construct that provides a way to “direct” or “coordinate” multiple animation-related actions and synchronize them with other effects, like sound.

Animation Files (.ANM Extension)

Animation files are text-based definitions of how multiple in-game effects coordinate with one another. When you want to play an animation in GK3, you almost always specify a particular animation file to use.

Animation files are used to coordinate or direct multiple scene objects during an animation. For example, a “walk” animation file specifies that a model should play an animation and that certain frames should play footstep sounds. A cutscene animation might tell multiple models to play animations, change the camera angle, play multiple lines of VO, modify the texture on a model, and change a character’s facial expression.

Animation files are referenced any place an animation might need to be played - script files, noun/verb/case files, etc. Therefore, they are one of the most frequently used asset types.

Animation files can reference many other assets: vertex animation files, textures, BSP object names, sound file names, etc. There is a fairly extensive list of supported features: play vertex animations, swap scene textures, swap scene object visibility, swap model textures, swap model visibility, play 3D sounds, play soundtrack files, move the camera, change facial features, etc.

“Mother of all Animations” Files (.MOM Extension)

These files seem to be exactly the same as normal animation files. They are both text files and they contain the same syntax and supported keywords. A piece of documentation refers to these as “Mother of all Animations” files!

It’s unclear why the game needed these in addition to the standard animation files. One trend I see is that MOM files tend to define more complicated animation sequences. Perhaps they were treated differently at runtime?

Vertex Animation Files (.ACT Extension)

In the GK3 postmortem, Scott Bilas laments the decision to use vertex animations, rather than convert everything to skeletal animations when it became apparent they were a better choice. Since I’m trying to re-implement GK3’s animations, I feel his pain!

There are annoyances with this approach that the postmortem enumerates: each animation only works on a single model. If the model is changed, the animation needs to be redone. It requires more storage and is more computationally expensive to use. From a workflow perspective, imagine that you want to improve a model in the game, but doing so means EVERY animation that model uses also needs to be redone!

A vertex animation file is a binary asset that defines one or more frames of animation for a model. Each frame can specify data for each submesh in the model. The data defined for the submesh could be positions or position deltas for individual vertices, an updated translation/rotation/scale, or updated bounding boxes.

Vertex data is heavily compressed. Usually, the first frame defines full 3D coordinates for each vertex. Subsequent frames define position deltas that are heavily compressed to save space. If a vertex doesn’t update on a frame, its data is omitted.

Vertex animation files are mostly referenced by animation files. They are usually easy to distinguish from other assets because they tend to be prefixed with the target model’s name (e.g. gab_walk).

Vertex animation files contain a reference to the name of the 3D model the animation is meant for. Attempting to play a vertex animation on the incorrect 3D model will probably not look correct at all!

Sequence Files (.SEQ Extension)

Sequence files define a sequence of elements, with the elements being either animations or textures. I believe the idea is to play a sequence of animations or textures in order.

Though these assets exist in the game, I have not yet found a situation where they are used.

Logic Assets

By the time GK3 was made, Sierra had been in the adventure game business for many years. Their prior AGI and SCI engines implemented scripting languages to avoid hardcoding gameplay logic in the core engine.

Fortunately, GK3 also takes this approach - the vast majority of the game’s logic is not in the game’s executable, but in various bundled assets.

Sheep Script Files (.SHP Extension)

Sheep Script files are binary AND text assets that can be executed using GK3’s internal scripting language system, Sheep. The majority of the game’s logic and functionality is defined using this scripting language. This is extremely cool - expect a blog post in the future exploring this in much more detail!

Sheep is a relatively simple scripting language that has basic support for user-defined variables of int/float/string, user-defined functions, and system functions. The majority of sheep script operations involve calling system functions to do various things (move actors, play animations, play sounds/VO, etc).

Many of the Sheep assets in the game are in a binary format, but some Sheep scripts exist in text format, such as those found in SIF and NVC files. It is also possible to execute Sheep code from the in-game console. As a result, the engine must be able to execute “compiled” Sheep byte code, and it must also be able to compile Sheep scripts “on the fly” to byte code for execution. Fun!

Sheep assets are referenced in plenty of places: SIFs, NVCs, and GAS files to name a few. Whenever we want the game to do some arbitrary action or check some arbitrary conditions, this is usually done with a snippet of Sheep script.

Sheep scripts do not reference assets directly, but calls to system functions often involve specifying the name of a model, texture, animation, sound file, etc. It’s perfectly possible for Sheep files to try to reference invalid asset names, so that’s got to be accounted for.

GAS Files (.GAS Extension)

The documentation refers to this as the “G-Engine Auto Scripting Language.” When you look at GAS files compared to Sheep files, you can see a world where maybe only Sheep files were needed - does a game really need TWO scripting languages!?

Well, technically, GAS files are not truly scripts. They are relatively simply text-based assets that contain one command per line and extremely simple control structures. The main commands in GAS are to play an animation or walk to a spot.

The idea behind GAS script files is to control what an actor does when not being actively commanded to perform actions by the player or Sheep script files. If an actor is just standing in a room and not being interacted with, it’d look strange if they did absolutely nothing. GAS script execution allows such an actor to play idle “fidget” animations or follow some path to walk around.

GAS scripts are also used for the dialogue system - generally, an actor will have three GAS scripts that it alternates between: idle, talk, and listen. When engaged in dialogue, actors will play their talk scripts while talking and listen scripts while someone else is talking.

GAS scripts are primarily referenced in Scene Initialization Files (SIFs), where they are used to declare what GAS scripts an actor should use. They are also referenced in Sheep files to change an actor’s GAS script under certain circumstances.

GAS scripts mostly just reference animation files, but they occasionally reference position markers that are defined in Scene Initialization Files (SIFs).

Scene Assets

Many video games are level-based or have discrete locations. Games and game engines have a variety of names for this concept: levels, courses, maps, rooms, locations, or scenes to name a few.

GK3 fits pretty nicely into this mold. Gameplay is split into discrete locations that you visit to explore and perform actions (e.g. Hotel Room 25, Hotel Lobby, Church Interior, Graveyard, Train Station).

One interesting requirement in GK3 is that scenes are not totally static. For one, you can visit a particular location during multiple “timeblocks.” Visiting a location at 10AM vs. 8PM will graphically look different, just due to lighting and skybox requirements. But locations also tend to behave differently at different times: NPCs exist in one scene at one time and are elsewhere later on. A car might be in a parking lot in the morning, but gone later.

GK3 sometimes refers to these as “scenes,” sometimes as “locations.”

Scene Initialization (SIF) Files

When you enter a new scene in GK3, the appropriate scene initialization file(s) (or SIFs, for short) are loaded based on the location and timeblock the player is currently in. For example:

• R25.SIF is loaded when you are at the location “R25” (which is Gabe’s room in the game)
• R25306P.SIF is loaded when you are at the location “R25” on Day 3 at 6PM

The idea is that the “general” SIF is always loaded when you are at a location, but a “specific” SIF (for a specific timeblock) can also be optionally defined. If the “specific” asset does not exist, it is simply not loaded. The purpose of the specific SIF is to provide additions, alternatives, and overrides for the scene that only apply in that specific timeblock.

SIF files are fairly complicated text files in INI format (with some customizations). Basically, anything that needs to be defined and loaded for a scene is specified in this file. For example:

• Which scene file to use (which in turn defines the lighting and BSP to use)
• A global light position
• Camera movement boundaries and actor walker boundaries
• All “actors” to load. Actors are essentially humanoids and some animals. The model to use, noun, start position, and GAS file to use are specified
• All “models” to load. Models are potentially dynamic 3D objects, such as a fountain, motorcycle, or door. The model to use, noun, position, and type are specified. Type indicates whether the model is part of the BSP asset or loaded separately as a 3D model asset
• Meaningful positions are defined with X/Y/Z coordinates, orientations, and identifiers
• Meaningful camera positions are defined with X/Y/Z coordinates, orientations, and identifiers
• 3D regions and trigger volumes are defined and named
• Soundtrack files to play are specified
• NVC files to use are specified

One interesting deviation from the INI format is the ability to specify a “condition,” using Sheep script, for any block of data in the SIF file. The result is that certain declarations for what models to load or what scene files to use can change depending on gameplay variables.

SIF files are not really referenced by other assets. The correct ones to load are derived from the specified location and timeblock.

SIF files reference A LOT of other assets. They reference models, BSP, soundtracks, GAS files, Sheep files, and NVC files.

Scene Files (.SCN Extension)

Scene files are relatively simple text files that seem somewhat superfluous, though they contain some relevant data.

The most useful thing this file does is identify the BSP file to use. If no BSP is specified in this file, it is assumed that we should just use the BSP that has the same name as the scene file asset. The name of the scene file asset also matches the MUL file we should use.

Beyond that, the scene file contains definitions for lights and a list of object names in the BSP. Thus far, neither of these seem useful.

Scene files are referenced from scene initialization files (SIFs).

Noun/Verb/Case Files (.NVC Extension)

Noun/verb/case files (or NVC files) are really the meat of defining interactivity within a particular scene. These are text files that define:

• What “nouns” are interactive? The mapping between nouns and 3D objects is defined in scene initialization files.
• What verbs can you perform on the object? These tend to be like “LOOK”, “OPEN”, “CLOSE”, etc.
• Under what cases is the verb valid for the noun? Some interactions are always available, others are only available for Gabe or Grace, and others are only available if arbitrary conditions (defined in Sheep scripting language) are met.
• When you perform the verb on the noun, what action is performed? Also defined in Sheep scripting language.

A typical line from one of these files looks like this:

CANOE_PAINTING, LOOK, GRACE_ALL, approach=WalkToSee, target=r25pic01, script={wait StartVoiceOver("1LLJ644QS1",2);}

Some conditions (like GRACE_ALL) are globally defined. But it is also possible to define custom cases, such as this one:

DRESSER_OPEN = {(GetNounVerbCount("DRESSER", "OPEN") == 1) && IsCurrentEgo("Gabriel")}

You can only perform an action in a scene if it is defined in an NVC file. NVC files are loaded in scene initialization files, and they are often conditionally loaded depending on the particular timeblock that is currently active.

Audio Assets

Beyond the obvious sound files, GK3 also defines a couple novel asset types related to audio.

Music/SFX Files (.WAV Extension)

Most sound effects in GK3 have a .WAV extension, which might lead you to believe they are uncompressed WAV files. However, they are actually in compressed MP3 format. Despite the lack of MP3 extension, the WAV file format is perfectly capable of storing MP3 compressed audio data.

Audio files don’t reference other assets, but they are referenced frequently - pretty much anywhere you’d want to play a sound or music file.

VO Files (Random Extension)

There is another type of audio file in GK3 that is, at first, a bit mystifying. Anytime a script specifies some character voice-over to play, they specify a filename like “A0144J44.N61”.

For some reason, all VO audio files are named rather obscurely with random letters and numbers. The documentation even sometimes refers to these as “license plates.”

I don’t know the reasoning for this naming convention, but these files are still WAV files, just with different extensions. The distinction is just that these always play VO.

Soundtrack Files (.STK Extension)

Music in GK3 is not usually defined using minutes-long MP3 files. Instead, to make the music feel less repetitive and more varied, the music for a location tends to be separated into multiple music clips that can be mixed-and-matched to provide the ambient background music.

To achieve this, the game uses a “soundtrack” asset type that contains data in INI format. Using a couple simple keywords, it defines orderings for each chunk of music, a randomized wait time between chunks, and potentially even randomization of the music chunks themselves.

Soundtrack files only reference audio files.

Soundtrack files are primarily referenced in scene initialization (SIF) files. They can also be referenced by animations or script files to change the soundtrack suddenly as part of some gameplay event.

Dialogue Files (.YAK Extension)

Subtitles for spoken word in movies or video games doesn’t seem complicated, but when you think about it, somebody probably needs to manually parse the speech to text AND synchronize it with the audio. That is the case in GK3.

YAK files define the subtitles for every piece of spoken dialogue in the game. In the case of a cutscene or multiple lines of dialogue, they also specify the pacing of those subtitles so that a subtitle only appears when the audio changes.

Most YAK files have names that correlate to the “license plates” used to name VO files. The correlation is: when you play a VO file, lookup the YAK file with the same name! YAK file names are usually prefixed with the letter ‘E’ - I suspect this was some future-proofing for localization, but the game was never localized.

UI Assets

The UI in GK3 is fairly simple. It feels like UI was definitely not the focus during development - more of a “just implement what’s needed” than a “let’s implement a full framework” sort of thing.

UI Definition Files (.TXT Extension)

These are relatively piecemeal TXT files that contain definitions for particular UIs in the game. For example, a file “RC_LAYOUT.TXT” defines the layout and behavior of the options menu.

The use of these files in the game must be hardcoded - I don’t see references to them elsewhere. The format of the files are also very specific to each screen. So, I suspect there were specific C++ files for each UI definition, and the C++ file would read in what it needed from the data.

These files tend to primarily reference image files for things like buttons and other graphical elements.

Cursor Files (.CUR Extension)

GK3 uses a couple different cursors: the normal arrow cursor, a highlighted arrow cursor, and a loading cursor come to mind.

These cursors are defined as simple text files in INI format. The name of the asset usually implies the texture to be used for the cursor.

Some cursors are animated - in this case, the INI format specifies a frame count and frame rate. It is assumed that the cursor texture’s width is divisible by the frame count, and that all the frames are in that one texture.

Font Files (.FON Extension)

GK3 uses only image-based fonts. Many fonts are used throughout the game, actually - subtitles of varying colors, UI text, console text, etc.

A font is defined using a text file in INI format. The image containing the font is implied from the font asset name, unless the font asset explicitly specifies an image to use.

The font asset defines in a simple ordered list which language character correlates to each glyph in the texture. Some fonts do have “monospace” glyphs, where each glyph is exactly the same size, but that isn’t a requirement. In the case that a texture has glyphs of different widths and heights, this is signified using particular pixel colors in the font texture. Pretty complicated to parse and use!

Tooltip Files (.TIP Extension)

There’s only one of these in the game, and I think it’s only used with debug tools. It’s basically what you’d expect: a little box with some helpful text in it that only appears if you hover over something with your mouse for awhile.

Browser Files (.HTML Extension)

Wait, why does this game need HTML files!? In GK3, the biggest puzzle in the game involves Grace researching and solving a massive riddle to find a buried treasure. To do this, she uses a laptop system called SIDNEY that contains a faux-internet experience, where you can search for topics and follow links between topics.

Since this experience behaves just like a basic internet browser, the developers must have thought simply using HTML would be a good way to go.

The HTML system is pretty feature rich: it can display paragraphs, text alignment, body vs. header text, inline images, links to other documents, etc.

Misc Text Assets

Finally, GK3 uses a number of text assets for various miscellaneous purposes. In these cases, it’s pretty clear that the game just needed a one-off data file to define one thing or another.

Character Definitions

All characters in the game are defined in two text files: CHARACTERS.TXT and FACES.TXT.

CHARACTERS.TXT mainly defines various traits of the character in-game. I suspect many of the fields may not actually be used. But two that are quite helpful are: the model to use for the character, and the shoe type (used for footstep logic).

FACES.TXT defines all the traits of a characters face. This includes face texture, default eye colors, blink frequencies, frequency of eye jitter, offsets into face texture for eye/mouth placement, etc.

Footstep Definitions

GK3 contains a system for playing footstep or “footscuff” sounds based on a character’s shoe type and the floor type.

FLOORMAP.TXT maps specific textures on floors to a floor type. For example, 20-something textures in the game are designated as “carpet” floor type.

FOOTSTEPS.TXT and FOOTSCUFFS.TXT define lists of sound effects to use for various shoe types on various floor types. Lists are used so that multiple sounds can be randomized.

Verb Definitions

GK3’s noun/verb/case files define verbs that you can use to interact with objects in the game world. The file VERBS.TXT maps verbs to UI images representing that verb.

For example, the LOOK verb may be mapped to an image of an eyeball.

Inventory Definitions

The file INVENTORYSPRITES.TXT maps inventory item names to textures used to represent them when they’re in your inventory.

Localization Resources

Files called ESTRINGS.TXT and KEYBOARD.TXT seem to provide mappings from localization keys to values in English. It appears that this was meant for when the game was localized, but it never was!

SIDNEY Definitions

As described above, one of the puzzles in the game involves heavy use of a fictional computer system called SIDNEY. To implement this interface, the game uses a number of piecemeal data files.

ESIDNEY.TXT and ESIDNEYEMAIL.TXT provide mappings from keys to values for the computer’s interface and all emails received during the game. Again, seems meant to be localized, but never was.

SIDNEYDIALOG.TXT defines how visiting certain pages in the in-game browser will trigger in-game events under certain conditions. For example, a part of the puzzle may be to figure out the right thing to search for. Once you find the correct page, it triggers a bit of dialogue from Grace and you get some points.

SIDSEARCH.TXT maps search terms to specific web pages. This mainly provides some leeway when searching for topics, so you don’t always have to get the exact term right.

Binoculars Definition

One GK3 mechanic allows you to use a pair of binoculars from certain outdoor locations to see what characters are doing in other locations.

BINOCS.TXT defines where this feature can be activated and what happens in each instance when you do it.

GPS Definition

There are maybe 2-4 times during the game where Grace uses a GPS to determine the exact spot she should dig to find something buried underground.

GPS.TXT defines the gameplay aspects of this mechanic. When using the GPS at certain locations, it defines what positions in the scene you need to go to in order to “solve” the GPS puzzle.

GPS_VISUAL_INTERFACE_SPEC.TXT defines how the system works - just documentation!

Conclusion

As you can see, GK3 makes use of a wide variety of assets to achieve its gameplay goals. As I try to build an engine that recreates that gameplay experience, a huge challenge is simply understanding how all the pieces fit together.

Through careful investigation, we now have a pretty good idea as to the breadth of asset types, what they’re used for, and how they relate to one another.

Future posts in this series will focus on the challenges associated with parsing and using each of these asset types in G-Engine.