First useful MERPG game engine release

TL;DR

Memapper/merpg-engine (I really should rethink branding of this thing) version 0.1.3, the first one without glaringly obvious bugs AND in which you can make games you can deploy to users, has been released. Pick it (and the accompanying emacs mode if you wish to script your games) up from the github.

A long long time ago

Back in the dark age of 2010 I thought "Hmm, Pokemon Mystery Dungeon is an awesome game. I want to make a clone of its mechanics". I began hacking the engine with C++/SDL, because big boys had told me that you're not anyone unless you're hacking games in C++. Well, they forgot to mention that hacking C++ in Windows (which was my sole OS at the time) is a pain in the arse compared to Linux ("whaddaya mean you want the *.lib files (or whatever Windows called object files) available EVERY time you compile?" - Visual C++ 2010). Alongside I began to write the map editor using Best Software Engineering Practices™ in Java, because at the time I had my first course in Java starting in a month.

A shorter while ago

In about half a year I grew tired of VC++ 2010 ("what the fuck is a multithreaded apartment and why does my code break with 'MERPG STOPPED WORKING - LOOKING FOR SOLUTIONS' if I don't want to live in one?" - Me, 2010) and instead of doing the right thing and migrating to a sane build environment (Emacs, gcc, Linux with modern repositories (ie. not CentOS nor debian), scons or make) I decided to scrap that codebase and either write the whole game in Java or not write it at all. That was a passable plan for a while, but then I got employed and saw what a mess software written in languages without metaprogramming, introspection and macros will become. Always.

I learned to Clojure and rebooted the project. I did that for half a year and found out painfully that using a not useless language is not magical fairy dust you can sprinkle over a project and save it from the certain doom

After half a year of meditating and doing everything but this project, I had an idea: game in which I've cloned the mechanics of another game ISN'T A VIABLE DESIGN DOCUMENT. After that realization, I scrapped the first clojure codebase that had gone bonkers and rebooted the project, with the aim of creating an editor in which you can edit maps and put sprites in a GUI and script the live instance like you'd script Emacs. I like to think that this idea began already a year before with this blogpost, but that post's ideas are mostly either evolved or still unimplemented (because that'd make this engine too specialized lazy developer without enough time).

Present

That particular reboot has finally brought some results. I published memapper 0.1.2 in github a few hours ago, and an hour later I did a bugfix which made the mouse api usable. You can import scripts, sprites (both animated and static) and everything gets saved in the project file. There's an embedded nrepl-server which extends the protocol by adding a few nrepl ops that cider-merpg (the emacs mode that knows how to find and save script files inside the live editor) requires. Thus if you need to run the editor from the source, use 'lein run' and connect manually with M-x cider-connect (or C-c M-c). When you need to run the final game, mark a map as initial map, save the image, copy the editor's jar next to the image and run 'java -jar ./editor.jar --image ./project.memap' in the shell.

I realize that this way of deployment leaves Windows users in a difficult position, with cmd.exe being a piece of shit and Oracle's jre being too dumb and stupid to actually install the relevant binaries in tha %PATH%. I'm sorry about that, and I'm searching for a better way to deploy, but the desktop deployment is the JVM's achilles heel mostly because of Windows. If anyone knows how to generate a jar-archive that runs on double click on explorer.exe AND an installer that for sure installs the jre-dependency in an unbroken state, let me know!

Download MEMAPPER-0.1.3 from github

Thoughts on scripting a game engine

Scripting is hard

Letting users script your system is a hard problem. How do you do it. Do you just expose eval of your favourite scripting environment with the selected apis to your system's machinery? Do you hack up an eval with an all-access pass to your machinery?

I'm using the terms I think I learned from Steve Yegge. The machinery, the engine refer both to the immutable parts of the software system set in stone by the original compiler. Think of the parts in Emacs or a web browser written in C. Scripting layer refers to the parts written in, using those examples, Lisp or Javascript.

I haven't researched Emacs' codebase at all, so I'm basing my understanding on reading blogs and inferring on its behaviour. AFAIK Emacs is implemented with the absolute minimal base system written in C, and as much as possible scripted on top of that in Lisp. Thus almost every parameter is trivially open to mutation by the user. There seems to be a way to extend Emacs with shared objects, but you don't want to do that unless you have to, because unless doing native, system-dependent things Lisp and C are equivalent in power and the tooling is a lot better in the lisp side. In fact, with Lisp you can mold Emacs to a email app or browser or anything which doesn't resemble the original text editor at all. I know Amazon used to have an email app written inside Emacs. I have also seen a few POS-systems running inside unix shells which might've been more useable to both the users and the developers if done inside Emacs.

But, but, but. Emacs has complete access to the shell and the filesystem. That's... that's... a security hole isn't it?

Might be. It doesn't really matter though, unless you're using Emacs as a http server and routing input from the sockets to eval, which might be a bit stupid. If you're paranoid of the third party Emacs extensions you're installing, it might be useful to grep for '(shell-command' and other IPC functions in the extension's sources. But that's why we have MELPA these days. Scripts user runs inside Emacs are assumed to be trusted.

Let's have a look on the browsers. There's a shitload of C, C++ and other compiled things in their machinery. There are the websites browser is a runtime for. A website can be a static, declarative document which makes interpreting it easy(ish). A website can also include procedural scripts. Those scripts, written in JS, are by definition not trusted. There's a sandbox in the browser the scripts are run in so that a website can't just ‘rm -rf --no-preserve-root /‘. Scripts are not allowed (or supposed? I'm not sure if the apis exist to do this) to mess with the browser's window chrome, only with the viewport browser assigns them.

The difference is the level of trust. Emacs scripts are assumed to be run by a user who knows what they're doing, and thus if a third-party script succesfully ‘rm -rf‘s everything, it's user's fault for running Emacs as root. Javascript is assumed to be run either by a babbling bumbling band of baboons who haven't dedicated their lives on computers or silently, completely unbeknownst to the user. However both leave the eval function open. Thus, if you have a way to ask textual input from the user, implementing a runtime REPL is easy.

  while(true) {
    alert(eval(prompt("Input: ", "")));
  }

;; don't do infinite loops in single-threaded, completely synchronous Emacs
(while true
  (message (prin1-to-string (eval (read)))))

Maybe it isn't that hard after all

How do Emacs and browsers map to the ways-to-script I started this text with? Browsers follow the first principle. Everything is forbidden until someone with enough authority (be it the user or someone in the w3c) authorizes it. Emacs does the second. It wishes to be able to script everything runtime, but because Unix won and our machines aren't lisp all the way down, that's not plausible.

Secret in these two environments is that they are easy and fun to script. I think Microsoft's tools like Office and Visual Studio are also runtime scriptable with a Visual Basic variant, but opening their scripting environment has never caused me the feeling to poke the system with a stick and see how it behaves. Last I checked (which I admit might have been in the XP era, me being somewhere around 10-16 years old) the VBA environment was a lousily documented, heavy gui app, with APIs that make, IDK, Java's ZIP-file API beautiful.

What are browsers then? Well, when I got into the web programming, the introspection in browsers was lousy and the DOM API has never won any beauty contests either. However, I thin these days they have introspection (in a form of the console and the dom viewer) and discoverability/self documentation (in a form of console auto-complete at least), they have always (in the context of one who learned to spell 'internet' well past the first browser wars) been freely available, and the feedback loop is much faster than with the compiled languages. The first argument was mostly a filler to achieve the magical count of arguments, but the latter two are important. They invite poking, and even though the user didn't fully grok how DOM works, they can hack functional stuff up fast and iteratively make it better afterwards.

Even though DOM isn't beautiful, it's necessary to have. In the browsers you don't have access to the machinery without it. If the scripting layer implemented only the base language, stdlib (dates etc.) and a runtime eval, you'd have a glorified calculator. You need a way to read stuff from the user and to print to them. If scripting had completely access to the environment's windowing system, that'd be cool, but then they'd be able to shell to rm too. Unnecessarily called rm isn't cool. Instead the browser decides to expose the selected parts of the windowing toolkit inside its own window to the scripts. The environment's windowing machinery is hidden under a common, system independent abstraction known as the dom.

I don't know much about how Emacs fills the needs like the one filled by the DOM in browsers. I haven't had the need to do much more with Emacs Lisp than re-assigning a few keystrokes, setting up modes and generating repetitive Java- and C#-shit. Yet. What I know is that Emacs does both the introspection and self-documentation a lot better than the browsers. In every mode you can write a small lisp snippet and press Ctrl+x Ctrl+e (or wherever you've bound eval-last-sexp). This evals the snippet in the context of the current buffer (similarly to how browser console evals javascript in the context of the currently open website). The lisp symbols carry their own documentation with them. Unlike in Java where documentation has to be separatedly compiled from the metadata in the source, you can ask an Emacs Lisp function for its documentation.

Let's assume you're writing an Emacs extension where you need to run a query-replace in the current buffer. As user you'd call it by pressing Alt+Shift+5 (M-%), but how do you do it as a programmer? The help system is under Ctrl+h. You need to know the group in which you are trying to get help. Now you need to know what happens when pressing Alt+Shift+5 (M-%). Let's ask help on keybindings: Ctrl+h k (for keybindings) Alt+Shift+5 (or C-h k M-%). This tells us all we need, API looks like this: (query-replace FROM-STRING TO-STRING &optional DELIMITED START END BACKWARD). The info-page has a lot more interesting stuff too, M-x count-words tells me there's about 328 words documented.

The example is a bit foolish, but that's because I've not done anything deep enough on Emacs to have any real-world examples. It still demoes the help system that's always near your fingertips, and unlike Visual Studio's unIntellisense, stays hidden when necessary and doesn't disappear halfway through the reading. To get more information on the help categories press C-h ?

(Somewhat stupid or ironic that just after I tell how the help system doesn't hide without user's consent, I find the one cursor in which I can put neither mark nor point in)

Scripting MERPG

So, how can these observations be used when designing my engine's scripting system? You might've not heard (ha :D) but the engine is as deeply written in Lisp as possible. This provides an excellent base to build a scripting api on top of. To be clear, this particular Lisp is Clojure and the machinery is written in Java. The only part I've had to do in Java that's not in either JVM's base class library or Clojure's runtime is the map renderer. There are a few parts in the render process written in Clojure which are the low hanging fruits if I ever have to optimize things. So, aside from the finer rendering details, everything else is done in the Clojure layer. The important stuff is even documented, so the users can connect to the engine's nrepl-server (nrepl-server basically exposes in-process eval to sockets) and either run (doc 'merpg.important.symbol) in the repl or use Cider's C-c C-d C-d - keybinding that opens the dedicated *help* buffer.

But exposing eval and rudimentary introspection tools provided by nrepl to the end-user isn't enough. Well, if your app's importance is similar to browsers', then you might get away with it, but those having to work with your half-assed system will curse you with their dying breaths. It's better to write a lot of documentation, and provide a lot of hooks for events you expect user's to have a need to script on (like, for example, DOM's onfoobar - event api). We also need a few really well thought out abstractions. Not like DOM's, which has useful abstractions but a horrible API, but like in Emacs, which's buffer abstraction is beautiful and the language permits making beautiful API's around it.

I like to think highly on my choices on how the game assets and -state is stored in The Registry, how registry is optimized on insertion, deletion and easy lookups when you know what you're looking for, and how it's transformed in the background to structures more optimized for rendering and other stuff. Time will tell though whether this design works or if it leads to worse performance than Minecraft's. Similarly, I like to think that the registry is an easy abstraction for the end-user to comprehend (I mean, what could be simpler than key-val - tables?), but only time will tell. When this editor has a "Build Executable" - button, I plan on implementing a couple of simpler games on the engine and improving the it based on those experiences.

Anyway, the relevant abstractions are the registry and every object type you see on the editor's domtree. Maps, tilesets, layers, animated and static sprites, tiles (which aren't visible on the domtree), and after I've designed this through, scripts.

The simplest way to add reactions to events would be to add watches on registry based either on the concrete ID (think of the following scenario

;; we're inside some other event
(let [sprite (animated-sprite! (re/peek-registry :selected-map) "./my beautiful spritesheet.png" 10)]
  (re/add-watch-on-key sprite
                       ;; This is called before committing the new-sprite-obj to the registry so you can check what's changed.
                       ;; new-sprite is an atom so that events can manipulate the object before it ends up in the registry without
                       ;; causing endless loops
                       (fn [new-sprite]
                         (let [{:keys [x y] :as new-sprite-obj} @new-sprite
                               {old-x :x
                                old-y :y} (re/peek-registry sprite)]
                           (if (or (not= x old-x)
                                   (not= y old-y))
                             (println "The sprite has moved!"))))))

this reacts to the movement of the dynamically loaded animation. animated-sprite! (like all the others that load assets from disk) puts the loaded asset automagically to the registry and returns the key with which you could fetch it from the registry. With re/add-watch-on-key you add the event that's called every time someone does a re/update-registry with the key you're interested in. The event gets called with the value that's en route to the registry. Surprisingly the value is an atom though. This way events can modify it without firing any events.

The user should also be able to set watches on the :types of objects. Call an event every time a sprite has moved.

There should be a simple way to poll the status of both the keyboard and the mouse. Every new environment I've moved to after I stopped doing coolbasic has disapointed me with the complexity of reading those. Events are cool and follow the best practices (or whatever is the buzzword for following whatever they were teaching as the gospel decade and a half ago in the java certification universities) for reading the IO state when you're doing a CRUD app, but with polling you can do a lot more complex actions with really simple code.

I'll provide filterable and map-able reagi streams for keydown, keyup, mousedown, mouseup and mouse coordinates. I'm not 100% certain these are as simple as I think. In case they prove to be too complex in the demo phase, I'll fart up a Windows VM and check if my recollection of the Coolbasic's IO API is just pure nostalgy or if it really was simpler.

Of course I have to expose :onload and :onclose - events, which are run on the startup and closing of the final game.

Script - assets and the editor

So, how would an user actually write and eval these scripts? The obvious way would be to let them write the scripts in their favourite text editor, keep the files with the .memap - project file and somehow import those files into the editor. I think last I checked Unity did something like this, but Unity's project directories are a nightmare. Let's not do that. Users having to carry multiple files in a project directory provides a lot more possibilities for the system to break than having a single file that contains the whole project image.

Thus I have to embed the scripts as assets inside the image. Which means having users using their favourite text editor becomes a bit more difficult. In theory you can open files-in-a-zip with Emacs' dired, but that's not exactly simple, Emacs is hardly everyone's favourite text editor (for reasons I've never understood :P) and the more complex editors are complex enough to miss the extremely simple use case of being able to save to a file handle pointing to inside a zip file.

I could implement an Emacs-like editor inside the map editor. But I sure as hell am not going to do that. I'd have the lisp machine model ready, but to make it useful even to those fond of Emacs I'd have the fart up an elisp->clojure - compiler (not impossible), rewrite Emacs' abstractions and do a fuckload of testing to find the corner cases. I'm not ready to clone Emacs, better people have tried and not-yet-succeeded.

The third option: make a server. If we already have an nrepl-server running for poking the live instance with a stick, it's no problem to make another server you could query the text-file assets from. I'm not sure if I could just extend nrepl-server to do this or if I have to invent a completely new protocol and dedicate another socket for this. If we assume we can trust everyone connecting to this file-server-socket, making it support find-file and save-buffer isn't hard. If the user has been able to connect with cider (or any other nrepl client) before reading the script asset from the server, we get the eval- and introspection capabilities for free.

Making a dedicated server or extending nrepl means I have to hold my nose and dive into the wonderful world of elisp. I plan on making a minor-mode which overloads find-file and save-buffer to work with urls pointing to the running server. I have almost no clue on how this would work technically, I just know that Emacs does async socket IPC and I have the Emacs' online help and the whole internet near my fingertips. The UX would be such that the user first connects to the running nrepl. Then in a buffer with cider running they'd use C-x C-f and input an url like "localhost:33500/your.games.ns.core". Format is "server:port/ns-name.here". If I can make this server by extending nrepl, I probably could make the format such that host:port/ isn't compulsory and if left out, Emacs would just use the default nrepl connection. When pressing C-x C-s in a buffer that's been loaded from a server, it could remember the path in a buffer-local variable, send it there and the server would either save the new source or ask the client to merge if there's been new material from another client after the last read on this client.

Format of the asset

The assets in the game server's registry is simple. Relevant properties are :id with which you refer to the asset in-engine, :name (which is completely irrelevant for development, and is used only in the editor's domtree as a prettier string than the id) and :parent-id. :parent-id belongs to the set of the loaded map-ids. It matters also in a way that when :selected-map changes in the registry, those scripts with the new :map-id as their :parent-id will be run. :order specifies the order in which the files are loaded. The most import property is :src. It's a textual representation of the source, what will be sent to the editor requesting it with C-x C-f and what will be overridden when (C-x C-s)ing. There might be more properties if I implement the support for concurrent editing.

Watches are installed when loading map's scripts. Scripts are autoloaded based on their :parents. There's no automatic cleanup of the old map's scripts, because generating a complement of an indefinite impure function is somewhat difficult. If you require cleanup, keep a hold of your watches' ids and install a watch on :selected-map that drops them.

There are also the game's :onload and :onclose which are run on process startup and process shutdown. To those you bind dedicated script assets in the game editor.

Zonetiles

This became a bit longer post than I anticipated. Bear with me, this should be the last title.

Zonetiles are an old concept based on the idea that a certain code will be run when there's a sprite entering a certain tile. My favourite use case for zonetiles are the doors to houses or dungeons or whatever. In the past they've been implemented as a hashmap of [tile-x tile-y] => lambda. That doesn't cut it currently, though, because entering lambdas sucks without all the base work I've specified on this text. Besides, simple coordinate-lambda - mapping is... a bit too simple in way.

Instead I plan on making a zonetile api in which the user filters the set of current map's tiles they wish to set the zone in with an indefinite predicate. Then they filter the sprites the zone matters to with another predicate. Then every whateverth millisecond, the engine shall search all the colliding tile-sprite pairs and call a zonetile lambda with their ids.

Conclusion

There's a lot to do. First I implement the script assets in the merpg editor. Then I'll research how to implement the file server. Afterwards is time to hack Emacs. When that's done, the editor side of this project is done. I think running the game shall require an optimized mode where it doesn't, for example, rerender the whole map every frame. Only when it has changed. After that mode is done, I need a way to dump the project image to disk as an executable jar file. Then... it's... playtime?

A slight file format changed cause by implemented sprites and animations

I implemented sprites, both animated and static, in the memapper codebase. That required some changes on the file format. This document applies from tag sprites-implemented onwards until otherwise mentioned (or src/merpg/IO/out.clj gets undocumented changes).

Surprisingly you can't view a png image and say whether it's certainly a tileset, a sprite or a spritesheet. Thus I had to change the tilesets' filenames to follow format "TILESET - :kwid - Tileset's name.png". Then I implemented saving of the sprites. They (both sprites and spritesheets, which are to be split to a list of frames on load) follow the filename format "SPRITE - :kwid.png".

Sprite metadata is put into the file called sprite-registry. It's a Clojure map, where keys map to the sprite filenames. On this registry is saved everything about the loaded sprites that can be serialized to s-expressions. In other words, everything but the concrete image data. Expected keys of the sprites and spritesheets are found in the /src/merpg/mutable/sprites.clj.

Next, I think, I'm supposed to design how the hell users are supposed to script this engine. Wish me luck, there's some hacking around nrepl and emacs to be expected

MEMAPPER 0.1.1

I pushed the new memapper to github. It's been tested to run on Arch Linux, almost-latest OS X, and it should work on Windows, but I don't have any with a relatively recent jre to test on. Reports and comments are appreciated, but the editor is so barebones/useless that I'm not going to be disappointed by the lack of them. Here's the changelog copypasted from github:

Changelog:

• A completely new state model which makes stuff accidentally both simpler and faster by using Reagi library
• GUI is a lot cleaner due to new state model making it easy to put the whole dom in a treeview.

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.

Painting the future

First things first, I currently have three open issues in the Github-page. 2 of them are trivial to fix, I'll probably start with them friday evening, but the memory leak will be slightly more interesting to solve. Were I leaking file handle or even naked pointers, they'd be easy to fix with a bit of macrology. No such luck though. I have a hunch I'm doing something incredibly stupid with STM. Memory-usage rises like hell when manipulating the state of the map. I thought STM-primitives carried their history all the time, but it seems I'm wrong. And I'm happy about that. In general case such behaviour would explode the already ridiculous RAM usage of JVM.

Sometimes I wonder if I romanticize the sixth-generation and older video game consoles a bit too much

Anyway, let's assume I'll get those bugs fixed on friday evening. That leaves me ˜48 hours to create new things. I should use them wisely.

First I have to parametrize hit-layer's tiles' size. I'm not certain, with the whopping 0 users this editor has, that 50px*50px isn't too big rectangle for controlling the places player can or cannot step on. I have a feeling though that it is. Thus, in the next version, hit-layer's tile-size can be anything, as long as (= h w).

In case I get really experimental, I'll parametrize the regular layers' tile-size too. It will have to be a different param though. (not= hitlayer-tile-w layer-tile-w) can be true.

Like I've spoken in the past, this map-editor will not be only a map-editor when I have realized my vision. I have this vision of a unity-like 2d-games editor with the added benefit of being Lisp all the way down, at least till you find pieces of crusty Java-machinery. So this editor will gain a possibility to load characters. They should probably be loaded as children of the Map-struct. These characters can be then moved and rotated around by either a script or a player. Animation subsystem should be easy to write.

The way I've imagined scripting to work will be different to Unity's kind. Scripts do not live in the file system. Instead they are in the same image as maps, characters, and other objects I haven't yet come up with. When editor loads an image (yes, henceforth the .memap-files editor produces are called images) it opens up an nrepl-server for scripting both the game and the engine. It also opens another server for my own protocol that dumps the image's script-files to the Emacs minor mode. This minor mode overrides find-file (C-x C-f) and save-buffer (C-x C-s) to communicate with this fileserver instead of operating system's.

Game is running in the background, rendering the scene, animations, scripts and updating AI and physics if I'll ever implement such luxury. User can edit maps and character-animations in the editor window. They can peek and poke the state of the game in REPL. On top of the game's namespaces, also editor's namespaces are open for customizing. Considering that by default Clojure's compiler (or whatever component Leiningen calls when uberjarring) keeps as much code inside a jar noncompiled as possible, it shouldn't be hard to provide the editor's sources too to Emacs through the aforementioned protocol. It should be a setting defaulted to off though, because unless user is sure to know what they want to create, they probably don't want to customize the editor.

So what am I to implement? Loading of animations (or static characters), decide what interesting properties I'm going to base my interpration of animations on (initial-frame-index, amount of sprites in a spritesheet, is-playing?, location and angle probably), and some sort of selection-rotating-and-moving tool for them. Some context-specific views on editor's sidebar would be nice too. Maybe a listbox where user could open certain frames to the pxart-editor? And replacing the animation sequence with another spritesheet without scrapping rest of the character's properties should be supported too.

Once characters can be loaded, scripted, and they can react and interact with the map, I'll probably have another go at game-design (instead of game-devtool-design). I'm a little on the fence on what I'll actually put into to game. Last October's spec on the game mechanics should be mostly applicable. Story will cause me most pain. On the other hand, the old, finnish manuscript found somewhere in merpg.webs.com is shit. On the other hand, it's my best finished game-manuscript (as opposed to a book-manuscript), and if Nintendo dares to save a princess in every other Zelda and Mario (a hyperbole, I know), I can use this as a source. I'll sell a better story to my next game then.

But, before I can take any stress of what I've written, I want to make a pxart-application (with possible dropbox-bindings) to Android! I've done it before, somewhere in Memapper's history you might even find the code for it, so it shouldn't be a long project. Hardest part will probably be finding how one commanded Android's 2D-rendering from Clojure again.

But now I'm off to sauna. Hack merrily!

Initial release of MEMAPPER

It's released!

Wow,

Back in 2011 I incrementally developed five versions of this infamous tilemap editor and published them $deity knows where, probably in the initial F&C. Then I understood that spec was too simple, we needed a multilayered format. One which understood alpha channel and layer-transparencies Paint.NET-style. One which could rotate tiles in real-time. One which understood multiple maps per file, with multiple tilesets per file.

I created an interpration of this spec with Java. It was shit. I began a software-job, which negatively impacted the schedule. I spent most of 2012 trying to understand Linux and Lisps. April -13, I began with a new revision of clj-memapper. I hacked it till christmas and decided it was shit. I sulked until summer of '14. I hacked a better version in July, and for $deity knows why, left it rotting 80% ready for a year. Last weekend I decided that the image-thing I had tech-wanked over for two years would be the death of this thing. I wrote procedures that dump editor's state to disk and the inverse of that, plus fixed a few bugs, and released the damn thing.

Look!

It is released!

I repeat: the thing I've techwanked over for last four years is released. Feature-freeze of 2011 is finally implemented. Codebase doesn't suck. Everything is fine and underdocumented.

What's interesting is that if I do radical stuff like this more, this project called MERPG has a slight chance of shipping before my grandchildren roam the earth.

 What now?

If you have a project where you'd need tilemaps, with 50px*50px tiles, and actually understand clojure (enough to use the github-visible merpg.IO.out - functions) or are able to deduce the yet-undocumented file format (hint: editor produces zip-packages), please do give this thing a try. I'm certain there are ways to break the system, and I'd love to find them.

What next?

I'll need to document this thing. At least the file format, although one versed in Clojure (or EDN) can probably understand it easily. Do I have to create the documents that hold user's hand through the main use-cases?

After that I think a new blogpost will follow. There are some new techwankments I'd love to explore while waiting for the new story and any graphics to materialize.

Let me repeat:

MEMAPPER IS RELEASED. DOWNLOAD FROM GITHUB. 

It runs on Java, so it shouldn't matter which OS you run it on. Currently I've only tested it on Linux though, but I have no idea why it should refuse to run anywhere else. It needs at least a Java 6 JRE. I recommend the latest OpenJRE. As far as I know Oracle is still distributing ask-malware with their Windows-JRE.

Memapper is tested only on a powerful workstation. Due to Swing's software renderer and not-really-optimized code of mine Memapper might get high CPU Usage that drains laptop battery fast.

This is beta quality software. It doesn't implement Ctrl+Z - functionality (yet I hope) and might crash without a notice. If it does so, I'd love some sort of a report.

Gamedesign from Pyhtää

I seem to be a proud owner of an iPad2 - device. I had one of these in the spring, and I didn't like it then. However, that device was school's, not mine, so I didn't dare to abuse it in the ways I'm known to abuse my computing devices usually. I'll do some iOS games-market research with this thing, and explore if I'm able to combine it, its physical keyboard and one of my raspberry pis into an ultimate computing experience. The keyboard feels bloody awful, but unlike last time, it's physical.

But, iPad's not what I'm here to talk about today. Last week I spent in the Pyhtää, trying to shape the MERPG into a profitable form. Boy how it formed: the current idea in my head is to ditch the old manuscript from the http://merpg.webs.com completely, maybe recycle a few of the character designs. I'd still keep the story of Rajol, the one of the two discrete stories I've written into the world of Kanariffa I actually like, unpublished to the masses until I decide it's ready, and the fancier Clojure-techdesigns for a more artsy game in the future, and make this game-designed-for-CambridgeVC to have it's own story, own world, and a set of monsters one can team with to uncover the story.

Why? Because I fear if I go to Cambridge to pitch an interactive movie/technical wankery I've designed the game to be, I'll be laughed out of the island.

But this new game, which is called in-team 'Pröng', but due obvious reasons, is from now on called 'The Game' in-blog. Until someone comes up with a better one, of course. It's very limited visual designs still apply: the style of the graphics is still 2D-highly saturated-pixel or vector -art. How do the mechanics of this game work?

Single player

You begin by customizing your character's sprite, name and base-type. I think it's best to win the secondary type through lottery, but I can imagine implementing the secondary types through Dragon Ageish specialization system. You meet some new team member or NPC that knows this specialization, you ask if they can teach it to you too, and presto, you've become a grass-assassin or something as insane.

Anyway, you start your game, with one or two friends following you. You run around the world, finding and doing quests, uncovering the story. The world is open as in Pokemon, and the difference between in-fight and out-fight is not as huge as in Pokemon. In neutral territory, sometimes based on randomness, sometimes because the maker has decided to put a trigger there, you're attacked by Dragon Ageish wave(s) of enemy. The fighting system is also inspired by DA. You ran around freely in pixel-space (instead of 20px*20px tile-space), use moves (that autolock to the nearest target if you don't pick a target with mouse/touch) and can pause the game as conveniently as in DA. I guess if it will seem better, implementing a Pokemon MDish turn- and tile-based system is a possibility, as the reasons I originally ditched that idea for are unbelievably underspecified.

As I said, the world is open like in Pokemon. There are also closed, randomly generated dungeons, from where you try to find your way through with as little casualties as possible. I'll try to come up with a good generation algorithm, but as I haven't done this kind of a thing ever, I'm open to suggestions of material to learn the theory from.

Not only can you fight NPCs, you can discuss with them, answer their questions in different ways (because, you know, RPG, even though I don't have time to write a true multithreaded story in the week before the Kotka's Warming Game jam), bring items to and from them. They can be led through the random-dungeons, you can fetch items from these dungeons for them, save their friends... there are a million possibilities I'm too tired to come up with currently.

I like the idea of generating monsters teammates randomly, but in Pyhtää I was told that evolution of the teammates is a crucial element in this kind of game. I agree, but it makes the random-generation a bit harder. An idea I've played in my head is to have every monster share the generic baby-teenager-grownup - evolution stages, and do some magic to customize the pre-rendered animations according to a die.

Training teammates can be done outside the storymode too. There will be a random quest generator in the game, a sort of like the pelipper post office in Pokemon MD.

You can save the game any time you want in single player mode. If in a fight, just pause the game and save. You will resume from the exactly same circumstances.

Multiplayer

You can trade teammates with your friends, you can fight in a PvP setting against them, there's possibly some sort of chat for those in the game just for the sociality. You can play multiplayer quests co-operatively with your friends too. I don't know wheter these quests form a parallel storyline or are just a series of randomly generated quests.

Differentiation

The game differentiates from the Pokemon games through much better storyline, and at least from the older games, through a better multiplayer. I haven't extensively researched the Wifi-properties of the games >=Diamond. The real time combat is also a differences, but it will probably be disliked by as many pokemon-addicts as liked. One plus for us is that if you haven't yet bought a 3DS and X/Y, and are considering between that and our game, there's a high chance you'd rather buy ours because you don't need another device for it. Statistically speaking, you probably already have one of the following: PC/Mac/iOS/Android/Windows Phone.

How does it differentiate from the Pokemon MD? The combat system isn't turn based, and most of the flaws in the original MDs (friend abandons you after finishing the story, random generated quests are boring, story progresses way too randomly) will be averted. The evolution system is better also, but that doesn't mean it's a good system in our game. It just means evolution is mostly fucked in all MD-games.

How does it diff from the DA games? I dunno, 2D-graphics, happy-happy graphics, a bigger team, more diverse (pokemonish) type/class system... to name a few.

These are the most obvious differences, but why would someone pay for this game? I have no idea! The singleplayer will be free-to-play, because I've been told that's better than selling it for 8€ in app stores. It's possible that I'll publish both ad-crippled, free version, and 8€ ad-free version. I've also toyed with the idea of having a subscription fee to the multiplayer, because running heroku servers isn't exactly free, and it'd be a bit more expensive for those playing the otherwise free game.

Does this sound cool? Am I speaking crazytalk?

MERPG's specification as of October '14

I seem to have a malfunctioning Razer keyboard reading keypresses twice, like thiis. Just to let you know I haven't lost my ability to write mostly OK english

Bloody hell, yesterday I was complaining about not having time to complain of the stagnation of the 2D-MERPG, and know I seem to have a team of few designers determined to hone the sharp edges of the spec away and to implement it in or after the Cambridge Venture Camp. I'm not entirely certain anymore what's happening, but the finishing words of the last text are more true than ever in their small lives: these future weeks will be interesting.

But! If we are going to hone the sharp edges of the spec, I have to write one beforehand. There is a spec-of-a-sort in the game's website, but it's in finnish, it's huge (although it has to be, for it contains most of the game's story. Story is however inessential in a pitchable spec), and it's old. Please let me fix the situation here:

MERPG

The title is a working-title, I'm open to better titles, but nobody has yet come up with one. The game is played in 2D, camera looking down on the world in the same angle as the on in Pokemon games. Like in the hotlinked Pokemon Blue Rescue Team or PC-title Dragon Age, the team consists of multiple of playable characters. In the manuscript this multiple is defined to be 3, but there's no reason for the team's count of characcters to be an even number like 4, with the last slot being filled with visiting characters. The game could contain some kind of waystation system, where the game could replenish their HP & PP, buy & sell items and wiggle the members of the party.

Anyway, the main idea of the game is to be an interactive movie get the player to explore the epic storyline. Seriously, I've never been fond of John Carmack's quote ^[1] about stories in games. Gameplay can be shit, which I could almost say it is in Witcher 1, but the writing can redeem the game. Other way around it doesn't work, in every other finnish mobile game (for example Angry Birds & Clash of clans) the gameplay works rather nice, but I lost interest in them in a day. Why? Because I can't be attached to only pawing the touch screen without a story. I either need a complex system to paw, like Age of Empires on the PC, or a bloody story that makes me feel like reading something in between a comic and a book.

Battle and stuff

But back to the game. Player can control any character of the party. Swapping the controlled one is done like in Dragon Age: just click their face on the HUD-area. Battling is done in real time too, like in DA and unlike in Pokemon Blue Rescue Team. Characters have moves, but I'm not sure whether to allow using them infinite times per battle, implement a stamina pool that's drawn by all the moves, or to give every move a discrete set of PP. Moves have either a target, and if one can draw a straight line from the caster to that target (and that line can be limited to be infinitely small in case of non-ranged attacks) without overlapping anything else the move hasn't missed, or they have a target coordinates on the map and area-of-effect, and everyone within this area is cast some damage.

Battling can be paused, and while done so, it's possible to give commands to AI-controlled characters. When unpaused, they fulfil their commands and continue thinking for themselves afterwards. So, to summarise: the battling system is Dragon Ageish, but in 2D, with stamina pool possibly replaced by Pokemon's PP-system or a big void. The moves and the type-system will draw inspiration from Pokemon rather than DA, but it seems only fair for this project began as a Blue Rescue Team inspired clone. Moves have to be detailed soon, but the type-system should probably be a straight clone from the Pokemon games, with the same type-weakness matrix.

One can use the mouse to choose targets, just as in DA. If one doesn't want to, the game autolocks on the nearest interactable NPC.

However, why is the fighting done in real time? Unless I'm seriously misrecalling, the moving- and fighting system of the Pokemon Mystery Dungeons was turn-based. Why not do it that way? Because moving in this game is continuous (to a pixel level at least). MD did have these N squarepixels sized tiles that could be inhabited by only one character at a time, which made turn-basedness sane by providing a clear limit on how much one could do in a turn, but with the continuous movement there's no such limit anymore. That's why.

Maps

Maps are built of square tiles, and are thoroughly specsed in the blog and the github. If a lower-than-here level question of them arises, I will gladly answer. The largest maps are supposed to fill a 1920x1080 screen on the editor (=> decrease a little of both dimensions for the sidebar and the tileset-view), and maps make up a graph. In current implementation one can define functions to be called when the player moves out of the map in any cardinal direction, but I have to change it to be possible to set triggers to any tile, or otherwise we can't implement enterable houses. And if I haven't said it clearly, these functions called in triggers are free to reset character coordinates and change the current map.

I think routes are static maps inhabited by enemies. I don't know if they should form waves like in DA or just pop out of thin air alone, in pairs, triplets or quartets. If it serves the storyline, I could possibly implement a dungeon generator, but that'd need some time on pure experimentation and learning the theory. Cities are inhabited by friendly NPC:s, selling & buying stuff, managing your quests. It is possible to meet friendly NPC:s outside cities, but vice versa (unfriendly NPCs inside cities) is not.

Dialogue and sounds

Discussions are done in a dialog box in a way shown in the Pokemon MDs. That means player's own character speaks too, unlike in other Nintendo games I've played (the not-spinoff pokemons of NDS & Gameboy and Zelda Twilight Princess). There's no voice acting, because this is a low-budget game, and even if someone invests on us with a large bag of pure gold, there still won't be, as this game is supposed to feel like a garage production. An epic soundtrack, (think of something like 8-bit Nightwish), would be a must at some point but not until we have a playable prototype

Token economy

Reading this is recommended, although even I haven't yet read it to the end, as I haven't played the Borderlands. Mr. Yegge speaks of an important thing in it: people love collecting stuff. This, I think, is what made the Pokemon games as popular and timeless as they are. The newer revisions of them are still the same game: people (me included) are buying them just for the sake of new things to collect, and honed collect experience. This is so powerful force that it invalidates most of my rant against the Carmack's quote. Story may be shit, gameplay might also be (which it isn't in the pokemon), but if people get addicted to collecting (where collecting includes the improving-through-training in Pokemon), the game is saved!

So, it would be foolish to overlook the token economy on a game pokemon clone such as this one. Unfortunately I have done so for years spent developing and not-developing this. I have however a theory, that we could improve on the MD's concept of collecting playable characters. Making them both more diverse and differentiated than pokemons in the aforementioned. We could let the player customise their outlook, and of course we could make all the characters have DAish experience system. Instead of XP granting levels, which grant predefined amounts of stats, we could grant the player predefined amount of stat-points to distribute among the stats the way they see fit.

Of course a good token economy requires a way to show off the collection. A character trading system as in original Pokemon, a send-character-to-help system as in MD, and of course the voluntary public profiles in the internet. The profileservice could also used to distribute mods and backup saves.

The rest

I dream of multiple platforms, and a striving modding community, but they aren't essential in a pitch and for the prototype.

Have I forgotten anything essential (for the pitch, I mean)

---

Footnotes

[1] Story in a game is like a story in a porn movie. It's expected to be there, but it's not that important. (http://en.wikiquote.org/wiki/John_D._Carmack)

I get that this is supposed to apply to FPS-games like stuff by Id, not wnb-RPGs, but it's still a wonderful inspiration on a rant of the current game scene.

Home is where the book is

I love to travel, that I do. One might not believe it, for after a few hours of anything with less personal space than a train-car, I tend to get an urgent need to rise up with my cracking joints, but I do love it all the same. Especially on the summer, for what would be better way to spend summer than to take an overnight-train to the ass-end of north and spend a day/weekend up there being creative? Well, travelling the 6km it takes to get to Tässi's place near the Siikajärvi lake and being creative there, of course.

I am fascinated by new places, which I think is one of the reasons I love reading and writing fiction so much. I am disgusted by the everyday life so badly I'm practically a living cliché. I loathe the repetitiveness of waking up at 6am and spending a few hours commuting for five days a week. Once summer is gone, which also requires its own sulking, I loathe waking up to the sound of the alarm (although I don't complain of the more humane time it's usually set in the winter, 8am UTC+2, instead of 6am UTC+3 it is currently set) , pedalling through the hail, sleet, tears and blood to the school, wasting a day there and pedalling back to the empty fridge and full project-directory.

So, I like escaping the (not horrible but) dull everyday life to the worlds of Roland & Rajol. And what would be better environment to practice this art of escapism than aeroplane/train-car/the front seat of a car? I have found none. Unfortunately however one has to eat, and no one will pay that one dude to travel writing and reading fiction. Not unless you've built yourself an image of being the next Stephen King, but at least I wouldn't want such. I wish to develop my own style, albeit it tends to look like whatever I'm currently reading.

However, if everyday life is dull and escapism doesn't pay, what is a man to do?

I've spoken of setting up a one-to-three man shop (for various definitions of manhood), developing a story-based game and trying to earn some money of it, but since the only one I have yet achieved to have any interest in the story is the Tässi, and neither of us has any idea of how to monetize things, it has become a sort of eternity-project. Another way of achieving undullness in life I've thought of is commuting with bus for this summer carrying the mac of mine with me, writing 100 to 1000 words of prose a day, and self-publishing the story after a few editing iterations in the leanpub.com. Is anyone of my finnish readers (all one of you :P) up for proof-reading a story derived from Assassin's Creed? And this question is directed at everyone but Tässi and my godmother, for you two will receive a copy wanted you or not :)

Retreating back to the problem of dullness, can I find a solution to it by thinking of the reasons I find the everyday life such?

Well, I obviously don't like being woken up nor having to go to sleep once the creative juices are flowing. I dislike the finnish weather, unless it's as it was in the summer of '13. I dislike cities, and I'd dislike having a 1,5h commute (of which barely 45 min is suitable for writing with the laptop) were I not an obsessive fiction writer capable of taking advantage of these day's most productive minutes. I dislike using software that tries to be smarter than me (in other words, most of the .net devtools, windows in general and all the wysiwyg office BS) and usually fails. I dislike people, who introduce themselves as experts in areas I'm interested in and immediately proceed to invalidating their claim of experthood.

A year ago I held a hope of moving to Kotka would solve the problem of ever-increasing feeling of boredom inside me. No such luck. After spending the then-previous year getting kicked by the Winforms designer to different parts of my body, the very last thing I'll need is a professor telling me how the Visual Studio's forms designer is the best thing since the sliced bread, and I should "learn to program object-orientedly". A common disagreement among the younger of us wannabe-FPeers, I guess. After that I found a few more profs I had disagreements with, and my attitude problems reached their local peak in the spring, when I began asking myself: "what else could I do if not programming?".

That was bad; so bad I had to wonder in the meta-level how things could've gone so bad. In this digital world of ours programming is one of the best professions to be in, for instead of being sent to unemployment, programmers are usually the ones sending people there. When you are programming, you don't have to deal with people 8am-4pm, but instead get to play with... well, calling them toys would undermine my point, because you usually don't do serious work with toys, but then doing serious work with Clojure is so painless it's almost as if playing mere games. And you get to play this game whenever you feel like doing it: in an ideal environment you could run you REPL wherever you want and conncet to it from another side of the globe.

I guess I didn't get in to the Aalto university I applied to in the peak of this all, and I dare not open the results website (for the results will arrive in post in a few weeks) and check them, so I am quite sure I'm returning to the beautiful city of Kotka this fall. I guess this is for the best, because going to Aalto would have meant moving nearer to Helsinki, which would surely have driven me insane. I'll keep going to the school, because the society doesn't view dropouts without 8am-4pm job in a good light (and the engineer's degree isn't bad at all to have), and try to finish the prose of mine and actually learn to program the unity engine. I might need to make real acquaintances in the Kouvola to get real graphics to this story-driven-über-RPG of mine, but the static models made by myself would be enough when presenting the prototype to the potential designers.

Oh yes, haven't I mention? Currently I'm planning on utilizing the MERPG-manuscript in a 3-dimensional unity-project. Scripting it will probably be an experiment in pain, but at one could try to write its scripts on JS. And aside the foolish script-environments and complex (although probably necessarily such) GUI, that engine isn't actually so bad ("seriously? :O")

The 2D-Clojure-engine hasn't seen the light of the day since the christmas, and likely won't at least until the next. I've thought about it at lot, and will return to it at some moment, because the lispy core makes its development, to quote myself, as if playing mere games. That core will also make the engine/game a lot more flexible and longer-living, assuming I'll actually finish with it anytime soon, than most of the 2D-games done with unity.

To summarize: the future holds prose, interesting game projects, a lot of mental effort to keep the school from killing this interest, and lot of wondering and wandering for me. Anyone interested of tagging along? Everything (maybe excluding the writing-process of the prose, as the writing is THE loneliest profession) I enumerated would be more pleasent had I not to face them alone </lolangst>. I will probably push the unity-thingy to the github once I've began developing it, and I am ready to distribute the manuscript quite freely (and probably am currently distributing at http://merpg.webs.com, I can't be arsed to open it in the safari and check).