The Mason Engine is a web enabled game development platform for 2D tile based games.
This project is still a work in progress. Herein you'll find the documentation for the engine's design as it becomes available.
A magic thing happens the moment you're able to turn your pixel art and graph paper designs into a working game. Today's explosion of interest in game development mirrors the creative boom among PC hobbyists in the 1980's. Back then myself and other enthusiasts were captivated by our newly discovered powers of digital creation.
Yesterday's "Hello World" has become "Welcome to Game Development", and for many of today's new programmers JavaScript fills the role that BASIC once did for me. However, there are many pitfalls and gotchas new JavaScript developers must watch out for. Code that runs on one browser is not always supported, or implemented the same way on other browsers. This fact alone can be rather daunting to new devs.
The Mason Engine handles some of the more complex and finicky features that HTML5 games need so that game devs can focus on creating their game instead of deciphering cryptic browser errors. Other frameworks like JQuery or YUI help a great deal, but are not specifically optimized for use in games.
This project is my way of carrying on the spirit of digital exploration; To place within reach the sense of accomplishment that is earned by realizing a creative spark and sharing it.
For engine scalability the elements that make up a game are arranged in a hierarchy. Listed from most specific to most generic these elements are: Assets, Sectors, Zones, Worlds, and Games
An asset is the smallest unit of game content. Graphics, sound, music, logic, etc. are all classified as assets. Some assets are built from other assets. For example: A slice asset is a smaller part of a larger image. The specific types of assets are discussed elsewhere. An asset can be a single tile, a logic script, a list of other assets, and other types of elementary game data.
An instance is an occurrence of an asset in the game. In order for a background image, tile, enemy, etc. to appear in the game an instance of it must be placed within the world.
Layers determine the rendering order of overlapping assets. Layers can also be used to apply a specific type of logic to some assets and not others. For example, instances that experience gravity can be placed in a physics layer.
A sector is a collection of assets that become active at once. For visual assets, being active means being considered for rendering and animation. For non visual assets, becoming active may mean processing logic. Multiple sectors may become visible all at once. Each sector is responsible for one physical area of the game, but sectors can overlap. The play area is typically divided into uniform size areas along sector boundaries, but sectors can also vary in size in some cases -- A platformer game, for example, may use differently shaped and sized sectors to more efficiently contain a game level's assets; A sector may span an entire level to contain logic that must run at all times while within the level.
Some sectors are designed for specific uses. For example: A TiledSector is a type of sector specifically optimized for containing assets arranged in a regular grid.
A zone is a loadable chunk of a game world composed of one or more sectors. Each game world has at least one zone, but a large game world can have many zones. The sectors in a zone usually cover a single larger area.
Each zone may have "neighboring" zones that are reachable from within the zone. The neighbor zones don't have to be physically adjacent.
When loading a zone Mason will also load the neighboring zones asynchronously so that there won't be lag when transitioning between zones. This behavior can be disabled by removing neighboring zones from the list. Note that a zone's neighbor list does not affect whether a zone can be reached from another zone.
A game world is a compartmentalized chunk of the game's experience.
Some simple games like Chess or Match 3 may only have one game world. Other more complex games may have several worlds connected via an intermediary "Hub" world. A world is comparable to a level, but it is a bit more abstract and generic in that a world can also be a pre-game menu system.
A game is the highest tier of the game element hierarchy.
There are many types of assets. Everything from images to sound or even text is considered an asset. Mason's asset system can even be extended to include new types of assets.
An image is what you'd expect: A rectangle of pixel data. Images have a width and height determined by the image file itself.
A slice is a part of an image. Slices are typically used to divide a larger image into smaller individual pieces. Slices can target a region of pixels by fixed pixel offsets or by percentage based offsets. The latter is helpful when creating games that have re-skinnable content. This way the base image can change, and not only pixel appearance, but also resolution. A slice has a width and height of its own to ensure its size remains fixed independent of the backing image. Non animated tiles are typically created using slices.
Cells are composed of one or more images or slices. Multiple images or slices can be positioned within a cell. Cells have a width and height determined by the positions and sizes of the images and slices they're composed of. A cell can have a base color that fills regions not fully covered by images or slices; When used with transparent slices or images this can give the appearance of multiple different re-colored images. Cells also have a pixelated or smooth property that determines what type of scaling operation to use if any slices of images require scaling operations.
This and more to be added soon.
Mason Engine uses a virtual file system to avoid file name collisions at the OS file level while allowing you to handle versioning of assets automatically. This allows you to change the location and names of files in the virtual asset tree without actually modifying the files themselves. Assets that depend on other assets are not linked by name, they are linked to the unchangeable ID number of the asset, so renaming an asset won't break the game or cause every asset to be searched to replace an asset name. Decoupling the asset name also allows the asset names to be internationalized. To this end, the asset names support Unicode even if your underlying OS file system does not support it.
Instead of renaming an asset to change it you simply write over the asset with a patch. This creates a new version of the asset and replaces all occurrences of the asset with the new changed version. If it's found that the previous asset version is needed it's a simple matter of creating a new asset and pointing it at the older version.
The changes you make to your local game are recorded on your own system, but not made available to other devs and players. These local changes will be saved between browser restarts so long as you don't delete your 'Local Storage' data (clearing cookies will not delete your work). In order to make your local changes visible to other developers you must create a "patch image" which is a snapshot of all the changes you've made so far. Other developers can then apply your patch file to their copy of the game. Once the online copy of the game is updated everyone will be able to see your changes.
While it is possible to edit the files in your local copy of the game's folders, doing so will make changes that Mason Engine doesn't know about, which will prevent you from sending those changes to others.To support collaborative game development you can have multiple different patches loaded at one time by merging the patches.
Besides the data required solely
When mason is first started it pulls down game.js and editor.js The latter contains the standard list of editing assets, which are all loaded by the game engine when in edit mode. Otherwise, just world.js is loaded.