EGM

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:

1. 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.
2. 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!

''