ME-non-MAPPER

Johdanto

Tjaha, kirjoitinkin tämän englanniksi huomaamattani. No, ei voi mitään, ˜1000 sanaa MERPGistä, toivottavasti joku tykkää :P

Idle but integrated thoughts

As I have written earlier (have I?), I am integrating MEMAPPER and MERPG-engine more tightly than probably is good for anyone's health. While running the engine, which has loaded the map set of test environment, one could press a well-documented key-shortcut, which fires up the map editor with the current map-set and current map. After doing whatever you were doing for the map, you press a button (or another shortcut) that sends the map back to the engine, which shows the thing "in the real world" and serializes it unto the disk.

Sooner or later I'll have to write a REPL-interface for actually creating the new maps, but since currently there's no real engine (only a Quil-based experimentation) the editor is a standalone program, with which you create new maps by restarting the thing. The unresetable nature of the program is an unbelievable pain in the arse when trying to do incremental development in the REPL, but tough luck, the alternative is to rewrite the old-as-hell state management in Clojure instead of Java... Which reminds me, if someone knows who to cheat leiningen to compile first (gen-class)'d clojure classes, then :java-sources, then the rest, feel free to answer my question in Javaranch.

Today while cycling to our local beach I kept thinking this mapeditor-engine - project which I have seriously developed for the last week (see the changelog's timestamps, Pröng's development seems to be postponed to the indefinite future...). Editor and engine sharing a map-set atom is a cool concept, but can this concept be extended? Could the user press one keyboard shortcut and enter the animation editor (Tässi? What kind of animations are we using? Some colourless gif-monster or png-series of images?), one to enter the NPC-editor, one to enter the Quest editor, one to enter the character-editor, one to enter the... whatever-editor?

Of course most of these are natural extensions of the map-editor. For example the NPC-editor would present an UI (for those uneducated pagans not fond of Emacs) for controlling enemy-spawning and scripting the artificial intelligence of the enemies and allies on the current map. I have no idea how the NPC:s are supposed to be scripted, but I think when the time comes, I'll have some sort of Clojure-based DSL ready. Character-editor will present tools to script your allies (remember: you have all the time two NPC-friends playing alongside you, and you can play any of them) on either global and per-map scale. One can also edit both the starting values and the values present in the engine's copy of the ally-atoms. Character-editor will also be able to assign animations to the all of the game's character classes in the game, and it'll maybe allow creating the whole new classes. We'll see, this system is meant to be open for poking, and I have grown fond of the Lispy idea of having unbelievably small kernel to build the things around, so probably all the game's character classes will be implemented through this system instead of hardcoding them.

Before I forget, a very important property of all the character classes is: singleton. This property ensures, as all those who have read their GoFs know, that there is only one concrete character of this class ever present. All the allies (err, main characters) will have this flag set to true, although this could present problems with some characters if taken to extremes :P

Quest-editor sounds also nice. Quest-data structure should probably have a :completed? - function, which is called every time player does something that could end a quest... or no. It is maybe nicer to make possible for adding a "Quest ready" - zone into maps. When the player wanders into the zones, all active quests are queried for their :completed? - function, and in case there's any, they are marked as such and archived. Unfortunately this approach will have some issues down the road, for example: who is going to host all the resources needed for specific quests. (@fatima-fought :completed?) - function will need to know the current HP of the Tutima-Fatima - singleton-character, but if one is nowhere near the fatima-fight (for example where? I have no idea! Let's just declare this situation hypothetical, so I don't have to open up the spec and begin searching for a needle in a haystack), it can't go loading the character from the filesystem every time player takes a step that ends up to the Zone.

Because RAM is cheap nowadays (and the JVM doesn't hoard it anyway, if you didn't catch the joke), I'll probably begin with an implementation that has instance of every singleton-character in the memory all the time. Their AI is just killed and they are not drawn when they are not needed, so there is no slow io required accessing them. They are maybe serialized to the same object as the set-of-maps. Or maybe they deserve their own slot in the global space, which unfortunately would require a whole new filetype next to the .MEMAP.

And this whole thing has to be documented somehow. For the relevant parts I'll follow the Quil's way of having a couple of functions listing all the relevant stuff, and telling everyone to (doc 'them-symbols). Opening up the doc-problem however would need twice this long text, so we shall not go there today.

tl:dr

The memapper (downloadable here) will be integrated to the engine, and will get a whole lot of functionality, which maybe disqualifies it to be a map editor, but it will still be cool. Let's hope I'll be able to write this "coolness" I feel into this software :P