It's gone

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.

I'm alive - and I've been hacking ClojureScript

TL;DR: I've been making a thing. It's not finished, but I might hold an interest long enough to finish it. Test instance of this thing is running on Heroku. Sources are in the prehistoric IM-project github repo of mine. Try it if you will, don't if you wont. There's only friend-requests, friendship and the basic messaging implemented.

With that done, hi. It's been a while. The timesinks after the last blogpost last august have been: I accidentally found myself in a romantic relationship, graduated a year early (well, I've done all the required coursework. It still remains to be seen if the bureacracy shall grant me the degree) from the polytechnic and related to that, I've been doing little projects here and there which either have never been finished enough to write a blogpost of or have required secrecy. After writing my thesis I relocated to Tampere. Then I began hacking.

I tried to apply to a Clojure job in this city. By doing that I also found out I'm probably not going to get employed if I can answer the question "Have you any experience on ClojureScript?" only with "None whatsoever, but I can try if you give me the specs". Well, after reviving the prehistoric IM-project design and hacking a server in Clojure and a client in ClojureScript in a couple of weeks, I can now answer "Yes, I know ClojureScript" and show what I've done with it.

The client is implemented with Reagent, the cljs-wrapper for the React - javascript framework. Had I been doing this in Javascript, I'd feel somewhat dirty right now, but with Reagent building the stateful UI was just building the dom as a clojure tree. With re-frame MVC what-ever managing the state of the app was even easier than in a traditional desktop app. Even though the introduction was a pain to read, I quite like what it does and will search if there's anything like it for the desktop apps using Seesaw.

On the server side it's a pretty basic ring/compojure rest api, using PostgreSQL and designed to be run on Heroku as easily as possible.

How shall I develop it further?

Issue-tracker provides a rather nice roadmap and a snapshot of the current status. It's easyish to break the ui with large display image (now that I think of it, it provides a nice xss-ish attack vector too), the user can't change their own details after registration and there are a few rough edges in the UI.

After admin-ui is done and the image sizes are limited, I'll probably research how websockets work and try to make real-time poll-less notifications with them.

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!

MEMAP-format

This is just a technical specification. If you're expecting war stories, this text might be a bit disappointment.

Specification for the memap-format

Files editor spits out are zip-files with a funny extension designed mostly to screw with prehistoric Windowses. Root of an example zip-file looks like this:

• Map 0.memap
• Map 1.memap
• Map N.memap
• initial.png
• G__1312.png
• G__4332.png
• asdfgh.png

Where N means arbitrary number, and names of the pngs' aren't strongly defined. Editor creates sequential id-numbers for the inner memap-files, but upon loading they may be called anything. Only *.memap-extension is needed. As for *.pngs, only requirement for them that filename is a legal Clojure keyword

.png-files are tilesets, .memap-files contain the maps. For each .png an expression

(and (= (rem (width *png-image*) 50) 0)
     (= (rem (height *png-image*) 50) 0))

is true. I highly recommend to keep an initial.png - tileset in your file. Editor allows removing it, but skies will open and horrible things will happen if it is removed.

Each .memap-file has a clojure-map full of data. Example of this follows:

  ^{:tyyppi :map,
  :id :G__9092,
  :hit-layer ^{:tyyppi :layer...}
              [[true ...] 
               [true ...]
               ...], :zonetiles {}, 
  :name "Map 228E9"}
  [^{:tyyppi :layer, :name "New layer", :opacity 255, :visible? true}
    [;;Layer begins here
     [{:x 3, :y 1, :tileset :G__8862, :rotation 0} ...]
     ...]]

First we have a map of metadata. :tyyppi (:type in english) can be either :map or :layer. It's used in editor's multimethod-dispatching machinery. :id:s are just to ease seeking a map, and in future I might write an upgradeable format where maps are stored in a map instead of a seq, and :id:s are used keys there. Map's :hit-layer is a layer with all the ordinary metadata, and the interesting data comes next: a 2D vector of booleans. Editor/future game engine will query if player can step on a tile with the following function:

(get-in hit-layer [x y])

:name is the string visible in editor's Maps-listbox. The actual data this metadata describes is a vector of layers. Layer's metadata is in my opinion self-explanatory. All values editor cares of are present in the example above. Valid :opacity values are 0<=:opacity<=255

Layers are again 2D-vectors, where one queries tile located at (x,y) completely the same way as with hit-layer. Instead of booleans real layers consist of tile-structures.

Tile's 4 interesting values are :x, :y, :tileset and :rotation. :tileset is the key editor queries the tileset with, valid values are defined by the names of the png-files in your zip-file. :x and :y define which of the 50px*50px chunks in the aforementioned tileset tile is rendered with. The origin is, similar to most of the 2D-things, in the upper left corner. :rotation's valid values are 0<=:rotation<4. Tile is rendered in the angle of 90&dg;*:rotation.

Map's origin is also in the upper left corner

Upgrade-path

It's possible that this isn't the final format :D. In case I screw with the format of the map I'll change the inner .memap-files' extension to something else, .memapx or something, and write an upgrade procedure. If I add something else (like, for example, script files), I'll just dump them to a specific folder in the root of the .zip-package.

That's it

It's really not a complex format. Files are not exactly small, but structure is loose, with Clojure's reader-facilities made implementation unbelievably easy, and XML would've been twice bigger.

Anyway, are there details I've overlooked?

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.

Road this far (sort-of like-a speech)

I'm tasked with making a speech tomorrow at school. Interesting. To fill the gaping void of my blog, I decided to write it up here too.

Note to those who shared these experiences I'm telling here with me: this is obviously a bit dramatized and I'm pulling the years mostly out of my arse. They might be correct, but their exact correctness doesn't matter to my message.

Specs of this speech are: 5 minutes of talk about a subject somehow relating to my profession of choice, with optional ppt-diashow.

So, hello everybody. I'm Feuer and I've come here today to tell you of my history as a programmer. I might draw some nice conclusions along the way, but let's not go there yet.

Let's return to the year of our lord 2005. It's christmas. I've caught cold just in time for the holidays. At 24th the sun rises, sun sets and somewhere along the evening Santa Claus arrives. Cool. The best part of christmas has arrived for the 12-year-old me. I open the minor presents, which I sadly can't recite anymore almost a decade after. Then I get to the last, surprisingly heavy present. I tear the wrappings off. It seems to be a new bag. Whatever has Santa thought I'd need that for? It was way too heavy and small to be used as a schoolbag. Fortunately I get my thoughts together and check if the bag contains some surprise.

It did

(META: It wasn't exactly that computer, but it was some sort of presario from early -00s. I seem to have forgotten the model and unfortunately have got rid of the computer)

There was a used Compaq from early -00s. She had some sort of duron, 128MB of RAM and a real S3-graphics chip. OS was XP. With that beauty I really began my career. I played the first two Age of Empires games and the Age of Mythology deity knows how much. I think I also began my first really long prose with her. We shared so many great moments I've not been able to relive with any of my later computers.

But I don't think you're here to listen about my first love. You want to know how that computer prepared me for this education and profession.

As an avid gamer I had always wanted to make a game. One fine day in the summer of -06 I was visiting a friend. We were playing with a computer, or something. The day before I had downloaded Coolbasic, but as the code seemed incomprehensible (albeit being almost pure, imperative, english). I took a glance on it and decided I'd try to understand it later. That day I was considering on removing the whole programming environment, for I probably wouldn't understand a thing of it or its tutorials.

Then my friend's father, my idol in the context of computers, arrived to the scene. "Feuer, do you know how to program a computer?" he asked. "Well.. I have downloaded a thing. I don't know how to use it though." I told him. "You should learn to. It's a nice feeling to hold a complete command of the computer in your fingertips" he said the truest words I have ever heard anyone speaking.

That inspired me to change the way I had approached programming. Instead of probably never understanding a thing of it, I decided, like I had so many times before as a kid done, to understand the trade as well as it's possible to in one lifetime. I learned (Cool)basic, hacking with it until I could tear the very seams of the runtime interpreter open.

My hardware got upgraded a few times during that era. Two years later I had moved from a 128MT/XP-laptop to a 4GB/Vista - self-assembled desktop computer.

By 2010 I began to be fed up with the limitations of the environment. I learned enough C++ to be dangerous. I spent a few months trying to hack an implementation of a game design of mine with C++ & SDL. I never got a finished product, but I got enough scars and knowledge to gain a new perspective on this field. Programming can be hard and most programmers seem to like pain in great amounts.

After the first half of 2011 I spoke fluently Java and C# . With C# I've never had a specific goal in mind, it has just been a nicer java with lousier 2D-drawing libraries. With Java I've always been on the road to implement my game any day now. Back in -11, instead of actually listening in the programming classes of my vocational school I proved my worth to the lecturer by implementing a two-dimensional tile map editor in Java. He was a great teacher, manipulated me to attend the classes and stay silent by providing helpful feedback when I got stuck. When I wasn't stuck, he stayed out of my way, as long as I passed the tests. I did, usually with the best grades. Our school could probably learn a thing or two of this way of teaching programming.

At some point I also learned PHP. I used it to write my first, self-written vulnerabilities. Fortunately my PHP-dabbling has happened with my own websites, which are to be expected to be of lower quality for being a playground for a newbie programmer.

By the end of 2012 C# and Java, those I had written all my desktop stuff in and had used professionally, began to feel a bit painful to write in. I asked why I have to write ten lines to just write "Hello world!" to console. I also asked if one could cheat the compiler to write some of the final code from a template. I also wondered why Visual Studio, the environment programmers tend to regard highly, leans so much on mouse. Are we not programmers, whose main tool is the keyboard!? If using a bloody mouse is so loved by many, why are we all not coding with Android-tablets?

I found Lisp. It answered my questions: you don't have to write a book to get a string to console. It's just (format t "Hello world!"). AST-manipulating macros of Lisp are templateish functions that generate and return new parts to AST in the compile phase. Emacs, the editor used by almost every Lisp aficionado, prides itself on not requiring mouse.

All the languages before the Lisp felt like work. They were almost the same language, with variable amounts of complexity and insanity thrown in. Lisp, however, was different. People who have designed it in the 50 years it has existed were not after pragmatism, which I think is a synonym for complexity in the proglang communities. They were university-folk making a tool that made them easier to do really smart things. That feels to be a major design principle in the language: keeping it simple, yet powerful.

Once I figured this principle out, I began to ask myself a lot of questions like "Why is this thing so complex?" and "Why isn't this thing half as powerful as it could be?". This, and better supported lisp-environments and emacs-packages, led me out of the world of Windows. Suddenly I realized I'm using Arch Linux, the operating system that optimizes best the axes of usability and simplicity. I'm crying literal tears every time I have to not be inside Emacs. In my ideal world, I'd be writing server-softaware in Lisp (META: probably Clojure) without foul things like X bothering me. Or possible some system-level stuff with C

In conclusion: after a decade I finally think I have some sort of idea how this thing called programming is done.

Also, in Finland, the promised land of Microsoft and Java, I fear I'm almost unemployable for not liking languages that aren't Lisp. (and to strengthen the joke here, let me add a smiley:) :D.

Thank you, any questions?

META:

It seems I have about 1400 words by now. Wish me luck in transforming this into an oral presentation.

Humen!

So, last year has gone, this year begun. I'm in Kotka, land is white with snow and everything seems ordinary. Unbelievably dull and uncreative environment for such a free spirit as me, don't you agree? Well, for starters, I don't. Last spring I tried to enhance the creativity of this dull-sounding environment by barricading myself in this flat. Results I've hopefully talked long enough already here. Last autumn I tried similar thing by participating in the startup-things. That worked out a bit better. I didn't produce anything concrete in them, but now I understand how my thinking has been flawed. I might be committing one of the deathly sins, but I think I'm scrapping the Lomaproosa, the original unreleased tale of my world of Kanariffa, to be just a (too) long-lived design document. Currently I have a prequel to that tale under development, in english this time, and once I have solid foundations, I'll rewrite the Lomaproosa in english too. It needs a rewrite, not only because of my arguably stupid dream of worldwide audience, but there is the whole middle-section I'd like to burn in eternal fires of oblivion.

Let's return to this world. Barricading myself in with the computer is supposed to be more creative than trying to be a bloody extrovert, isn't it? I mean, last spring I came up with the instant messenger-thingy, whereas last autumn I didn't create anything, as I just said. If we value our actions only by concrete creations, then yes, last spring was infinitely better, but if we value also well-being and have some long term vision, autumn was better. It pains me to say this, for I know what a PITA people can be, but creativity is not something that is found within oneself. Or at least not within me. I actually do require people to be able to think at all. There would be no Kanariffa without me and a few friends abusing caffeine in the middle of the long summer nights. There could be MERPG if I interacted with any designers face-to-face in my daily life (thanks KyAMK for keeping them in the north and us in the south!). Fortunately though I don't, for if such a thing existed, its biggest asset, the story, would be a disappointment.

But past is past, and I must face this newish year bold. Shall I also perish with it boldly? That remains to be seen.

I don't remember if I have announced this here yet. I'm in our local student association's board. I don't have (at least yet) any real responsibility, so pedagogically I'm just trying to infer how these organization thingies are ran. There's also some space to influence things, and I see a WTF in a need of fixing, I wont hesitate to do so. But the best thing I enjoy there? The general feeling of insanity. Days are long, but people seem to enjoy each other. This is nice, for this kind of environment boosts creativity. The organization has existed for thirty years, so there's some culture I need to get familiar with. So, more things to inspire from.

I'm interested if it's only the company of diverse people that has creative results in things I do, or being out of the comfort zone in general. I'm very close to applyin as a tutor. This sounds like the complete opposite of what I like doing, what with a billion familiar and unfamiliar people to interact with, and no absolute, correct answer to solve the whatever problem tutors are trying to solve.

There are serious human-related thingies (not neccessarily problems) that I'm looking forward to pondering on. Now, with clock 1:30am and alarm set up at 8am, I fare thee good night and merry last day of GGJ tomorrow.

Poet without a rhyme - Vuosikertomus -14

Apologies for anyone not capable of reading Finnish. This is the annual text that just has to be done in my native language because reasons. I'll resume with the english material in January. Or February. Or at some distant point in future.

Taas on planeetta kiertänyt täydet 2π radiaania auringon ympäri. Numeraalisesti lahjakkaat tietävät mitä tämä tarkoittaa: historiikkia ja ennakointia. Vuosikertomus (2013)ssa selitän kuinka minulla on ihanjustkohta jotain valmista näytettävää MERPGistä. Yllätys! Ei ole! Vieläkään! Eikä tule ennenkuin saan jonkun muunkin inspiroitumaan tästä! Enkä usko että tällaista ihmettä tulee ihan hetkeen tapahtumaan, koska itsekään en ole millään lailla inspiroitunut ennen kuin ymmärrän miten Kanariffan maailma toimii. Tämä taas vaatii uskomattomia määriä proosaa, sen editointia, ja mahdollisesti englanniksikääntöä. Minulla on täydellinen pelimottori karttaviritys, sekä kilo suunnitelmia siitä miten rakentaisin täydellisen, modattavan kaksiulotteisen tarina-/roolihörhöilyn Clojurella. Minulla ei kuitenkaan ole ketään, joka piirtäisi näitä, ja vaikka vanha viisaus sanoo insinööripohjaisten tikku-ukkojenkin olevan parempia kuin ei-minkään... niin ei. Ne eivät toimisi.

Siltä varalta että joku tuttu lukee tätä: puhun CVC-designeista myöhemmin, jos muistan. MERPGillä tarkoitetaan vielä sitä, mitä MERPGillä tarkoitettiin vuosi sitten. Lisäksi, minulla olisi Tässi, mutta hänelläkin on parempaa tekemistä. Tai jotain. En itse asiassa ole täysin varma miksi emme upota Öitä tähän projektiin! Ehkä siksi, kun niitä on nykyään niin vähän, niin on sitä kuuluisaa parempaakin tekemistä. Vanhaksi kasvaminen on tyhmää, koska tulee oikea elämä, jota pitäisi elää.

Mitä olen vuoden -14 aikana saanut aikaiseksi? 2 pientä ja sööttiä peliä: The Geometrician, yksinkertainen match-3 peli Candy Crush Sagan tyyliin. Se on tehty Clojurella, joten se toimii missä vaan mihin saa Javan asennettua, eli käytännössä kaikissa pc-käyttiksissä paitsi Windowsissa. Toinen peli on luovasti nimetty Tetris, joka on tehty C++:lla, ja täten toimii tuskin missään. Se kuitenkin kääntyy kaikilla unixeilla joihin SDL2 ja SDL2_ttf ovat saatavilla, sekä Windowsilla, jos on niin pähkähullu että jaksaa selittää Visual C++lle missä yllämainitut kirjastot sijaitsevat. Visual C++ totuttuun tapaan ei täysin ymmärrä C++11ä, joten kannattaa kääntää windows-branchiä, ei masteria.

Näiden lisäksi rakensin pikaviestimen Clojurella Herokun päälle. Sekä serverin että clientin sorsat ovat githubissa. Systeemin turvallisuus ei välttämättä ole kovin hyvä, muistan lyöneeni päätä seinään kun en löytänyt Clojurelle yhtään fiksua sessionhallintakirjastoa, enkä myös halunnut keksiä omaa. Silti, projektin loppupelissä tappoi Worse is Better-periaate. Tässin kanssa sosialisoidessa skype on riittävän hyvä sen neljä kertaa kvartaalissa kun hän on tietokoneella sosialisointitarkoituksissa, satunnaistuttujen kanssa sosialisoidessa jopa facebookin ällöchat on riittävän hyvä, ja irkkaus ERC:llä on itse asiassa paljon parempi tapa kommunikoida kuin pikaviestittely clojureclientillä. Silti, toiminnallisuudeltaan Windows Live Messenger -09:ää vastaava Clojuretoteutus, joka pitää NREPL-serveriä kustomointia varten auki olisi minulle melko märkä uni, jos viitsisin ratkaista sosiaaliset ongelmat tämän tieltä.

Githubin projektilistalta silmiin sattunee projekti nimeltä melisp. Kesällä murehdin Clojuren JVM-riippuvuuksia, JVM:n alustakohtaisia ongelmia (en mitään nimiä halua mainita, mutta windows) ja Oraclen huonoa käytöstä, ja pohdin että jos joskus aikoisin tehdä jotain oikeasti hienoa lisp-softaa, opiskelisin joko Common Lispin työkalut (jolloin olisin riippuvainen SBCL:n kehittäjäjoukkiosta, mikä sopii minulle) tai tekisin oman Lispin, jonka jännyydet ja ominaisuudet olisivat minulle ilmiselvät. Koska minulla on historiaa virtuaalikoneiden kanssa urpoilusta, oman lispin toteutus tuntui ideoista parhaimmalta. Kesällä jaksoin toteuttaa projektia niin paljon että sain tulostettua shelliin "Hello world!" C:stä. Siihen se sitten jäi, minulla oli työmatkoilla parempaakin tekemistä kuin yrittää saada selkoa stdlibin dokumentaatiosta 1024x600 - kokoiselta näytöltä, koneelta jonka keskusmuistiin mahtuu juuri ja juuri kerneli, X ja Firefox.

Tutustuttani marraskuussa tetriksen myötä Linuxin C-kehitystyökaluihin tarkemmin jaksoin jatkaa tätä projektia. Parseri muistaakseni erottaa listat, atomit ja stringit toisistaan. Se ei kuitenkaan osaa avata listoja syystä, jota en ymmärrä lainkaan.Minun pitäisi repiä C++-luokat pois projektista, jotta pääsen varmuuteen siitä että taistelen loogisen härön kanssa enkä pelkästään typerän oliomallin, ja joko kikkailla C:llä tai korvata koko systeemi joko Common Lispiin tai Clojureen pohjautuvalla virityksellä. Kun saan listatkin auki, opiskelen stackkoneiden toimintaa, rakennan jonkinlaisen prototyypin, säädän kääntäjän tuottamaan puumallitulosteen sijaan oikeaa tavukoodia ja viritän prototyyppistackkoneen ymmärtämään tätä tavukoodia.

Mitä tästä projektista tulee isona? En tiedä, ei välttämättä muuta kuin tietojenkäsittelytieteellinen kokeilu, jonka myötä voin lopultakin väittää olevani aito koodari. Mahdollisesti integroin opengl_thingie - projektissa oppimiani juttuja tähän projektiin, ja aikaansaan jonkinlaisen 3D-työkalun? Jos näkisin tulevaisuuden, ei minun tarvitsisi kirjoittaa näitä vuosittain.

Minkälaisia projekteja ensi vuonna olisi odotettavissa? Minulla on mielessä eräs projekti, joka vaatii sekä Herokua että Android-clienttiä, mutta ennen kuin saan vihreää valoa kirjoittamalleni speksille, en siitä täällä hölötä. Lisäksi minulla on eräs kouluprojekti, joka voisi vaatia tetrispelin porttausta clojurescriptille ja oikeita grafiikoita, mutta hän on yhä odottamassa että viitsisin esitellä häntä projektin päättäville tahoille.

Viime vuonna ennakoin että startuppijuttuihin voisi olla kiva sekaantua. Noh, minähän sekaannuin. Toukokuussa (vai Kesäkuussa? En muista) olisi ollut ensimmäinen Cambridge Venture Camp, jolla KyAMK oli mukana. Mieleni olisi tehnyt sekaantua siihen, mutta kun olin jo Helsingissä palkkatyössä, en ehtinyt. Lokakuussa Kouvostoliittolaiset alkoivat puhua uudesta Venture Campistä, jolle mentäisiin hiomaan liikeideaa ja harjoittelemaan sen esittelyä. Sinnehän minä hain, mutta koska hakemukseni oli järkyttävän myöhässä, oli lähellä ettei tiimimme päässyt sinne. Sinne kuitenkin pääsimme, ja loppujen lopuksi minulla oli taiteellisen MERPGin rinnalla tuottelias MERPG. Lisäksi minulla on muusikko ja ohjelmoijavoimaa jolla toteuttaa tämä tuottava suunnitelma, mutta tiimistä puuttuu visuaalisen tuotannon lahjakkuutta jonkin verran. Tällä hetkellä tiimistä puuttuu myös inspiraatiota, mutta sen löytyminen on riippuvainen lähinnä ajasta.

Siinä taisi olla tiivistelmä kaikesta, jota olen tänä vuonna ohjelmistomaailmassa työstänyt. Seuraavaksi kuukausiyhteenveto:

Tammikuussa suutuin silloiselle karttaeditorille, ja sen myötä välimme olivat poikki puoli vuotta. Koulu jatkui, pääsin opiskelemaan oikeaa matikkaa ja fysiikkaa, kun lukionkertailu jäi taa. Helmikuussa oli hiihtoloma, jonka vietin helsingissä palkkatyössä. Windowshommia, aloin oikeasti miettiä onko Visual Studio ja mitä Windows-devit käyttävätkään paras, tai edes hyväksyttävä työkalu ohjelmointiin. En vieläkään ole aivan varma tämän ongelman ratkaisusta, mutta tiedän olleeni paljon onnellisempi päästyäni kotiprojekteissa eroon VS:stä ja Windowsista.

Maaliskuussa oli... jotain. Sonata Arctica julkaisi Pariah's Child-kiekon. Myös Delain julkaisi kiekkonsa alkuvuodesta. Within Temptation julkaisi Hydran, mutta sitä on tullut yllättävän vähän kuunneltua. En ole varma onko se vaikea vai tylsä levy. Voi olla että se avautuu vielä minullekin, mutta en lupaa mitään.

Huhtikuussa Tässi pyörähti Japanissa, ja toi sieltä paikallisen tulkinnan Pariah's Childista ja Tokion metrokartan tuliaisiksi. Huhtikuussa oli myös ensimmäiset Insinööriopiskelijapäivät, joille osallistuneet saivat nauttia hehkeästä seurastani. IOP järjestettiin Rovaniemellä, ja voin vannoa sen olleen ensimmäinen ja viimeinen kerta kun kuljen Rovaniemelle jollain muulla kuin yöjunalla. IOP:n rastikierros oli hauska, illallakin saattoi olla jotain ohjelmaa, ja seuraavanakin päivänä tapahtui... jotain. Minulla oli hauskaa, ja kuten kuvasta kuuluu, saattoi alkomahooli virrata. Huhtikuun loppupuolella kävin Virossa, josta löysin jotain kaunista. Kingin Musta Torni on kaunein kirja, jonka olen tähän mennessä lukenut. Ainoa Mustaa Tornia parempi lukukokemus on vain Mustan Tornin luku uudestaan. Ainoa Mustaa Tornia parempi lukukokemus on vain Mustan Tornin luku uudestaan...

Toukokuussa koulu oli loppu. Kuukausi näytti lähinnä tältä. Luin, pyöräilin, luin, ja pyöräilin vähän lisää. Viime kesänä en jaksanut pitää yhtä tarkkaa lukua poljetuista kilometreistä kuin edellisenä, mutta pelkästään toukokuussa tuli tehtyä useampi 40km lenkki.

Toukokuun puolivälissä, muistaakseni 16.5, herätyskelloni oli viritetty soimaan poikkeuksellisen aikaisin. Helsingin päärautatieasemalta lähti Allegro-juna, jonka numeroa en muista enää, klo 6:06 kohti Pietaria. Se oli hieno reissu, kolmen päivän aikana emme muistaakseni paljoa muuhun ehtineet tutustua kuin hermitaasiineremitaasiin, mutta kotiin palasin taas kokemusta rikkaampana. Pidän venäjän kielestä, alkeistasolta katsoen se vaikuttaa paljon loogisemmalta kuin germaaniset kielet... tai ainakin substantiivista näkee välitt&oml;mästi mihin sukuun se kuuluu. Ergo venäjä on loogisempaa kuin ruotsi.

Kesäkuussa oli palkkatöiden vuoro.

Heinäkuussa palkkatyöt jatkuivat, ja innostuin vääntämään karttaeditoria. Lopputulos on Githubissa odottamassa paljon puhuttua inspiraatiota. Heinäkuussa pyörähdin myös AssCreed2:n maisemissa Firenzessä. Tukikohtamme oli viiden päivän ajan Milanossa, ja useimpina päivinä tutkimme ympäristöä, ja eräänä päätimme lähteä junalla vähän kauemmas. Kevyesti arvioiden 18h myöhemmin olimme palanneet Milanoon todella väsyneinä. Se oli hauska reissu, josta olisi kuvia jos jaksaisin kaivaa niitä.

Elokuussa palkkatyöt loppuivat. Kesän suurin menestys oli tulkinnasta riippuen joko ne muutamankymmentä opintopistettä jotka tienasin työskentelemällä, muutama tuhatta euroa jotka tienasin työskentelemällä, tai ne kolmisenkymmentä tuhatta sanaa, jotka aikaansain kantamalla netbookkia aamubussissa mukanani töihin.

Elokuussa, kun kutsu fuksiristeilylle kolahti pärstäkirjaani, mietin että yök, pitäisikö minun viettää laivalla ilta ihmisten kanssa sosialisoiden. Ajateltuani asiaa tarkemmin, tavoitteeni elämässä on löytää parhaat ihmiset, ja tehdä heidän kanssaan jotain aivan parasta. Miten sitten ajattelin löytää nämä parhaat ihmiset, kotona murjottamalla? Niinpä niin, risteilylle tieni kävi, eikä näin jälkikäteen harmita yhtään. Turku on hieno paikka, ja maanteitä sinne kulkeminen Kotkasta on lähes yhtä parasta kuin rautateitä.

Syyskuu oli... jotain. Koulu jatkui, pelasin AssCreed4:n läpi, harrastin matematiikkaa, fysiikkaa, leikin raspilla. Tein kaikenlaista. Leikin ekstroverttia. Lokakuussa Startup-hörhöilin. Startup Workshop Kotka, Startupweekend Vantaa, CVC... monia mahdollisuuksia verkostoitua ja leikkiä ekstroverttia. Huomasin verkostoitumisen olevan jollain perverssillä tavalla oikeastaan aika mukavaa.

Marraskuussa olin enemmän verkostoitumassa kuin koulussa. Silloin kun olin koulussa, keskityin enemmän Tetrikseen kuin siihen mitä tunnilla tehtiin. Se sitten näkyi Joulukuun tenttiarvosanoissa.

Marraskuussa osallistuin Kotkan Insinööriopiskelijat KoiO Ry:n kokoukseen ilmaisen pullan toivossa, ja päädyin seuraavan vuoden hallitukseen. Miksi? Verkostoitumisen toivossa, tietysti! Se on uusi lempisanani. Toinen on ekstrovertti. Jos hoen niitä tarpeeksi, saatan ymmärtääkin niistä jotain ennen ensi vuoden loppua.

Mitä odottaa ensi vuodelta? Tuttuun tapaan ensireaktioni tähän kysymykseen on "emmietiiä", mutta toisin kuin vuosi sitten, tällä kertaa minulla on pieni, haalea aavistus. Verkostoitumista, ihmisiä, ekstrovertismia (jos se on sana). Ehkä saan jopa jotain oikeaa valmiiksi. Tulevaisuus on jännä. Tule tutkimaan sitä kanssani?

La oscuridad va romperme
No puedes salvarme
Será mi perdición
Siento un dolor abrazarme
La vida me destruye
No tengo salvación

I made a tetris!

I made a tetris. You can download it from the Github, if you can make sense of the Releases - list. I might have to hack a real release-distribution channel at some point, but for a leisure project such as this, github has to suffice. It's still better than distributing links to my Dropbox's Public-folder.

There are binaries for Windows and Mac. Because practically nobody at school is going to grade this as .rpm, .dpkg, or whatever-the-arch-pacman-uses, I don't care to learn to wrap such packages for Linux. I made a Mac package, because I was somewhat interested in how .dmgs are made, had my laptop with me, and a free slot of time to kill. Windows package I made because if someone is going to try my game, for example in school, it is most likely tried on a Windows machine.

If on linux, what you have to do would be the following on my arch-box:

git clone https://github.com/feuery/tetris.git
pacman -S scons SDL2 SDL2_ttf
cd tetris
scons
cd ./bin
*Copy a font of your choosing to this dir, with name 'DejaVuSans-bold.ttf'*
./tetris

On you basic Fedora- or Ubuntu-boxen the dev-sdl-packages and regular sdl-packages are different packages.

Merry christmas!

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?

Building MERPG and a Startup

So, I've upgraded my Mac to the Yosemite, changed the Emacs from the emacsforosx-build to the brew's build with Cocoa bindings, broken the cider-eldoc - connection, fixed a couple of bugs on the MERPG's map editor, written the map-save-procedure halfway... and lived through the soft landing of the Cambridge Venture Camp. The last one was especially crazy: by the end of the two-day event I got to actually think about where I'm supposed to make the money from with this game, how am I going to differentiate from all the other pokemon-lookalikes (a phrase I've begun to use with this game, which is fitting considering the idea began as a clone of the Pokemon MD: Blue Rescue Team), and then I had to actually communicate pitch these things successfully. In bloody english.

Next week I'll spend in Pyhtää, a small city near Kotka. Unless I seriously misremember, we're mostly honing the pitches and theorizing about the business model.The evenings will be free to hack the MVP, for I think there's not much else to do in that city. MVP will probably need another blogpost as soon as I've got a base understanding of what kind of tech we'll be building it upon. As I'm not the lone engineer, using Clojure will be a PITA as I can't be arsed to spend half a day to teach my fellow teammates the language and relevant APIs and a year to teach (why this is better) than(this, abomination, of, a, syntax);

Startup world is an interesting mini-economy. The major groups are the devs, the designers and the business guys. Of course any of these can be broken into minor groups, such as back-end-, front-end-, FP-, OO-, and such developers; marketeers, sales(wo)men, and all the subsets of X designers. It's a perfect symbiosis. Most of the designers are absolutely brilliant with the visual aspects of the job, but once one has to bake functionality to the beautiful sketches, they are... well, not useless, but somewhat out of their area of expertiese. Especially salesguys seem to understand customers and what they need, but for the sake of not drowning in techical debt, they must not be left alone near a computer with Microsoft Office. Devs are incapable of interacting with an ordinary human being, be it a customer or a coworker, and for the sake of everyone's eyes they must not be left alone near a photoshop.

This Cambridge-thing will either kill me or make me a more sales-y engineer. When I say sales-y, I am applouding salesguys' ability to make themself a friend of the customer, convince them of the value of their product and usually perform the transaction too. I dread opening my mouth, I don't like it if I have to make sounds approaching human speech, and... blahblahblah. Look at me trying to make the venture camp to kill me. There are other people, yes. Other people are scary, very yes. Speaking to them will make or melt a man, and as the team is still in a fragile state where I'm not entirely certain if the others are as fanatically dedicated to this project as I am, I cannot leave the pitching entirely for others to do.

I do my best thinking with my fingers, so let me transcribe my last-friday 1,5 minute pitch I spent about twice that time writing:

Hello! We're making an epic game!

The genre of this game is RPG. It'll be a Pokemon-lookalike with a hooking token economy and a complex story.

The trading of tokens will hoke the players for generations to come.

Euros will come from paid app, and in the free app from the in-app purchases and one-time price to get to the global multiplayer center.

I have understood that in finland game shops cooperate rather than compete, and market size analyzis is a bit unnecessary, because unlike in regular world, the customer isn't lost to us if they buy another pokemon-lookalike ^[1]. If they buy such a game, they are in fact in our target group, and more prone to buy ours.

We're the most epic team ever, 2 awesome engineers from Kotka and an artist from Kouvola. ^[2]

We're asking for monetary investment, as one does have to eat every now and then even when developing epic games.

Thank you dear people. Do you have any questions?

That's the essence of the draft I wrote to support me on the stage. In other words, that's what I tried to say. What's good in it? I was told the abuse of adjectives like 'epic', 'hooking' and such made me sound enthustiac. What's bad in it? For example, I failed to articulate my enthustiasm for the game's story, the only part that's received enough love. Back in the first weekend of September, I was visiting some sort of game-startup-gathering in Kouvola. There I saw this game, called Avenging Angel, 3D-fpsrpgwhatever that takes place in a futuristic steampunk world. I can't recall exact details of its pitch, but I remember on being sold on the idea of the Dark Amber making a game based on this universe Mr. Brandt has created over a 20 year period.

That reminds me of the way I've progressed with the MERPG. While trying to find an artist to share this vision of mine with, I've done a few sketches of the game engine (and a few gazillion sketches of the tilemap editor, and now at last the second clojure-based revision seems to fit in the sweet spot of enough flexibility, effectiveness and a niceness to develop) and built the world by writing loads of prose. I've got around 70 000 words now, and most of it should be useable in the game. The only problem is that while the original manuscript, one designed for the game, and the later prose, designed to expand the game's world, use the same characters in the same world, they are not exactly compatible.

Anyway, another negative on this pitch is the paragraph of finnish game industry cooperating rather than competing. I'm repeating the footnotes, but I have no idea if this is actually how it works. I just heard someone say this in an IGDA Kotka meeting back in May. I dislike saying aloud stuff that has a possibility of being false even more than I dislike saying anything aloud. I don't understand how to analyze the market in the software level of the gaming world, and I'll most probably need to minor in economics in school or find someone who has before anything on this insane scheme has a chance to generate revenue.

And the last & the worst problem: I was asked how I'm planning to differentiate from all the other pokemon clones/lookalikes. I almost made a clown of myself by asking what I'm supposed to differentiate from, but saved myself by mumbling about how to differentiate from the real pokemon games ("Story is a lot more complex^[3] than in pokemons, the tokens aren't monsters but the same kind of characters as your original team, blahblahblah"). The truth however is that I played Pokemon MD: Blue Rescue Team back in -11 or -10, wondered what the heck for there was no more such wonderful experiences to play with, and ran off to design and implement MERPG on top of this idea INSTEAD of actually researching the market. That's why it took me a year to understand that the MD-series had gotten a new title already back in -09.

As far as I know, there are no pokemon clones (at least like the one I've spent years designing)(aside from the actual sequels I've missed). Am I wrong or am I seriously wrong?

See you again sometime; now I'm off to bed and to Pyhtää in the morning

---

Footnotes

1. I'd love if someone could affirm or refute this paragraph. I have no hard data on the subject.
2. Outside the academic season, we could possibly have Tässi with us also. He's not bad with photoshop/paint.net, he has drawn everything currently on http://merpg.webs.com, and thus has the best idea of the style I'm after in this game. He also does brialliant job interpreting my thoughts to the regular people and vice versa, and isn't as hopelessly horrible in presenting in english as I am.
3. Words "complex story" bring shivers of pure joy to anyone that's played Witchers or almost any other RPG on PC, but to the audience of last friday's pitch these words brought negative connotations. Interesting.

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.