New MEMAPPER-specification

Because after 7 years I still have no functioning syntax highlighter on this blog, I'll be using github's gists instead of <pre> - blocks when necessary. I've been toying on migrating this blob of documents to a more programming-friendly environment, but that's obviously not done yet.

I'm really close on releasing a new version of memapper. This new version was a bit delayed by Java's Swing's JTree being a horrible pain in the ass to work with and by me having to do actual work for my degree last semester. But after a bit more than a year the state model is redone, the mess of listboxes is replaced with a treeview (which makes the relationships of parents and children explicit), and the app saves and loads projects correctly again. On this text I shall document the new format somewhat informally.

The new state model is based on a single hashmap on which all the components are saved. There is a single canonical place (merpg.mutable.registry/registry) where the state is saved. This format is optimized for quickly forming the dom tree. There are "views" that transform this registry to other formats that are more optimized for other things by using Reagi-library in background threads. Thus the rendering can be done by looping through a three-vectors deep data structure and getting the relevant data by just dereffing indexes (O(1)) instead of continuously hitting the central registry and filttering tiles based on their :map-x and :map-y (O(MFG)).

In the *.memap file (which is a zip-file) saved to disk there's a file called 'registry'. This is just a snapshot of whatever data there is in the registry, created by (pr snapshot-of-registry-without-tilesets).

Here is an example of what the registry could contain. The first map's keys are obviously the IDs you look stuff in the engine up with. Values are usually maps themselves too. All values have the following properties:

• :id

  The same as the key you get this object with. This exists because values need to know their keyes even though the keyset has been dropped from the registry

• :parent-id

  Who's this object's parent? To which map does this layer belong? Etc. Etc. Objects that want to be visible in the domtreeview's top-level need to have :root as their :parent-id.

• :type

  Is this a :layer, :tile, :tileset, :tool or what?

Further keys are either self-explanatory in their context (as if :D), or have been documented before.

Additionally there are also .png - files in the .memap - zip directory. Those contain the tilesets which obviously can't be serialized to s-exprs. As in the last specification, dimensions have to be divisable by 50px. The names of the .png files are important. The format of the filename is the following: ":clojure-kw-to-us-as-id - Tileset's name.png". Those filenames starting with : will cause grey hair to those hacking these files on Windows, but I believe zip format's filename requirements equal those usually seen in linux's filesystems, only disallowed characters are / and \0, so I don't care.

The string in between the first dash and the file extension is used as the tileset's name in the domtreeview.

That's it, I guess. During weekend I try to push a new release to github, after which I'll begin adding game objects and writing down how I've thought the scripting to work.