EGM - hpgDesigns/hpgdesigns-dev.io GitHub Wiki

This page explains the general concepts and proposals behind the EGM format. For actual specifications and documentation of the implemented format, please see EGM format.

EGM generally stands for Extensible Game Module. The name intentionally resembles that of ENIGMA, without the NI and A.

EGM is ENIGMA's new game format designed with speed in mind. One of the faults of ENIGMA's competition, namely Game Maker, is the massive save and load time for both the source and the executable. Those who run larger projects often end up waiting for whole minutes for the compiler to save the game, and then for the game to load. The wiser of them migrate to external resource storage, but this idea isn't well-supported by the IDE.

These applications likewise use their own, undocumented, proprietary format, which is difficult for novices to navigate and understand (I mean, especially when they encrypted it, and all).

ENIGMA should meet these issues with an extensible, plain-text format with a database-like runtime. Sun has demonstrated that ZIP is a viable format for such, Zip, and similar archiving formats, allows for the insertion of new items into the directory structure without modification to the entire file. It is also recognized by all modern operating systems (at least the latest several versions of each), meaning that most anyone who can run ENIGMA can open a Zip file. Not to mention, it saves hours on documentation. These in combination make it a good bet for a structural format.

Basic format

As mentioned, the articles of information will be stored in a Zip archive. Beyond that, we must consider what sorts of information we will be saving. For ENIGMA's purposes, all such sets of information fall into a package known as a resource, which typically comprises a set of plain-text attributes, and a binary section, be it an image (background), a set of images (sprite, font), or metric information (such as room instances or path nodes).

Tracking and Enumerating

Since each of these resources has at least some amount of text associated with it, they should be based on a plain-text "properties" file, similar to the ones employed by Sun in the JAR format. The files should not be restricted to one format, however. Limiting the format hinders extensibility. At the same time, the files should be easy to traverse, and so should meet one of the two criteria:

The files should be named, in any desired order, particular or otherwise, in a table-of-contents file (TOC) in the same directory. This is the ideal solution for ENIGMA resources; the TOC would list them in the order they will appear in the Resource tree. Because of the simple linear fashion of the TOC, a simple text file will suffice - no need to use .properties.
As a lighter-weight alternative, the files can be stored in a predictable sequence as specified in the documentation of the application that will be using this format. For example, if ENIGMA were to use INI, we would look in the Sprites/ directory of the archive to find spr_0.ini, spr_1.ini, spr_2.ini. (Wherein 'ini' is just a familiar extension. The actual extension would more likely be .properties or .ey)

In the second case, this specification does not call for a particular prefix, or that the static characters be a prefix or even that there are static characters in the sequence at all. The sequence must, however, be easily generated by starting at a given index and incrementing by a small, positive integer. Hence, [1, 2, 3], [a, b, c], and [J, K, L] are acceptable, while [i, ii, iii, iv, v] is not. Numbering in alternative bases is also acceptable, even where leading digits (plural) are in a different base than the trailing digit (singular). For example, A1, A2, A3... A8, A9, B1. But people will hate you if you do that. Note that, when omitting leading zeroes, whether there is an implied 0 there is application specific - so if you use spr_0 through spr_9, and then spr_10, it is up to the application as to whether spr_10 will appear before spr_2 or after spr_9. To guarantee ordering, you should either use a TOC, or include leading zeroes, or ensure that the application used handles this consistently.

The extensions are mandatory and must be consistent, and in the prior case, the TOC must always have a set name, such as "toc.txt". A program attempting to read this spec to populate the tree would first begin by attempting to locate the TOC. If it exists, it will use that. It is undecided at this time what the specification should do with entries with no corresponding properties file (either discard or use a default set of attributes). Properties files not listed in the TOC shall be appended to the tree in aforementioned sequential order after the TOC entries. Resultantly, there is no difference between an empty TOC and a missing/omitted one.

This specification does not yet specify how to handle Secondary Groups of resources.

Binary Data

Resources requiring binary data should store ONLY binary sequences under 512 bytes in with text attributes. In such a case, the format must be hexadecimal, but spacing and capitalization are at the discretion of the implementing application.

In cases of binary data in excess of, or likely to be in excess of, 512 bytes, this data should be stored in a separate file, and the relative path to that file should be referenced in the text-attributes file mentioned in the subsection above.

EGM Anthem

вздор, ерунда, нонсенс, чепуха, абсурдность, EGM!
сумасбродство, абсурд,  нонсенс, EGM!
пустяки, бессмыслица, EGM!

Cosa diavolo sto cantando,
Non ho indizio;
Ma l'ho cantare per uno: EGM!

‫‏;מה חרא, עכשיו אני לשיר עברית
‬‏‬אז אני אשיר על אהבה אמיתית שלי: EGM!

Sottises, balivernes, inepties, plus sur d'EGM!