The below is a brief explanation of how graphic assets interact with the programming as implemented Mystery on Telescope Hill, Adventure Beyond Time, and The Secret of Chimera Labs. The graphic assets used in this article are from The Secret of Chimera Labs, specifically the ‘Second Floor Cart’ conceptual space; The Secret of Chimera Labs contains approximately 120 such conceptual spaces.
The style of game employed in The Secret of Chimera Labs is often described as a ‘Room Escape’; and, indeed, moving through of series of spaces is an object of the gameplay and narrative progression. For this reason the term ‘Room’ will here be adopted to describe a one of these conceptual space.
The space is conceptual for the experience is created through the use of 2-dimensional bitmap images; images which can be divide into two broad categories based upon their relationship to one another: backgrounds [above] and sprites [below]. The sprite file has a corresponding XML file [below] which provides coordinate data on the location of single sprites within the bundled sheet. Individual images are bundled together because a single image is much more quickly loaded into computer memory and has a lower memory footprint than a series of image files.
The entire game is, in part, made up of series of these conceptual spaces. Each ‘Room’ in the game has script which handles all function within that singular conceptual space. Part of this ‘room script’ handles the loading and unloading of graphic assets.
Individual rooms are loaded into the display by a higher level ‘View Controller’ class method. Each room is like a little bundle of code [AS Class file] and art [JPG, PNG, ETC1, PVRCT, XML]. A good metaphor for the structure might be a deck of cards: when the View Controller (dealer) is instructed, it will move the specified Room (card), including all it’s included code and assets, to the display (top of the deck).
Within the room class [‘Second Floor Cart Class’ in the above diagram], a portion of the script [below left] specifies where the sprites should be placed in the 2D field. Yet another part of the script [below right] defines and instantiates a second type of object: a polygonal shape, i.e. a hit-area.
Hit-areas are created and defined for memory management purposes. Rather than listening on each sprite object in the room’s layered space for a mouse or touch interaction event, a single listener checks to see if any touch or click occurs within the enclosed bounds of a polygonal hit-area. If the touch or click is within an area, a true/false switch is tripped and a corresponding method is called and game’s state is manipulated.
In the below infographic, the layered space of the room ‘Second Floor Cart’ is shown, with background on the lowest level, sprites on the next series of level, and two series of hit-area levels. The hit-area polygons have been color-coded based upon their respective triggered functions: purple polygons may give some information but will not effect the game’s state; red polygons may trigger adding an item into the inventory system, opening a door, or effecting the game’s local and global state in other ways.
The hit-areas are made transparent once the debugging phase of development is completed. The below image shows the visual composite of the background and sprites as show in-game during a particular game state.