Introducing weekly updates

Hey everyone!

As part of our efforts to rekindle the development of Jaakan, I’ve decided to start publishing weekly updates on the progress of the game. Normally, I’d do that on devsofa, but I think everyone could benefit from a more open form of communication.

If I’m late in releasing an update, feel free to poke me about it at @fasterthanlime or @JaakanGame! I now try to regularly tweet screenshots from my personal account & retweet them from the official account.

The screenshot linked in this post is of the Universe Editor, which I’ll get to in a minute, but first I want to talk about some technical stuff. Because it’s fun! Plus it’ll get it out of the way.

Goodbye Lua

As mentioned in our “rebirth post”, the game’s codebase is now in v3. The original was written in pure ooc (my language). Then a few months later I played around with a MoonScript version — a language by itch.io’s creator which compiles to Lua.

The Lua version was an interesting experiment. First off, it showed that ooc was kind of a nice “glue language” between C libraries like SDL, libyaml, etc., and higher-level, interpreted languages. Second, it reinforced my intuition that reducing the cost of each “test->code->test” iteration is critical in gamedev (as NorthernLion would say, hindsight is 20/20).

Not having to recompile the executable for every little silly change in the game is huge. And it allowed us to experiment with things that we would have been afraid even to think about, back in the pure ooc version. But still, there was a major annoyance with that workflow: Lua (and by extension, MoonScript), does no type checking at all — as a result, if you mess something up, you don’t learn about until runtime. When the game crashes.

full

Plus, the way LuaJit was embedded into the game engine was rather fragile, and loosely integrated: whenever a crash happened in the native (ooc) code, there was no easy way to see which part of the lua code caused it. And if it crashed in lua, there was, again, no easy way to map it back to the original MoonScript. Both these issues might have been solved with time and effort, but when I came back to the codebase a few weeks later, I couldn’t even get my contraption to compile. That’s when I tried another approach.

Hello JavaScript (kind of)

Just as I was unsuccessfully trying to get the lua version of Jaakan to compile and run, I stumbled upon Duktape on HackerNews. I had looked into embedding V8 (Chrome’s JavaScript engine) or SpiderMonkey (ditto for Firefox), but the procedure is rather complex, fragile, involves unhealthy amounts of C++, and what’s more, they are pretty big codebases in themselves.

In contrast, Duktape seemed very light — Lua-comparable light. Almost too light to be true: I was worried about performance, but a few tests quickly reassured me. (I have no hard data other than “the game runs fast enough” — but you can make your own benchmarks if you want!).

JavaScript isn’t everyone’s cup of tea, and while its shortcomings aren’t exactly the same as Lua’s, they’re definitely numerous. However, since my day job is web development, I’m rather familiar with the beast.

With Duktape, I had a small-enough, fast-enough scripting engine to write most of the game logic in. But that still didn’t solve the whole “compile-time error checking” problem. Luckily, Microsoft (of all companies!) has been doing wonderful work with their language TypeScript, which compiles down to JavaScript.

In short: you get all kinds of compile-time checks, a syntax for modules, classes, properties, enums, some of it borrowed from future versions of JavaScripts. The latest version of the compiler is rather fast, and there’s even an Open-source IDE for it, CATS, to which I’ve already had the chance to make a contribution or two.

full

With those tools in hand, I quickly put together the missing pieces. ooc bindings for duktape, and a Duktape+TypeScript FFI code generator, so that ooc classes can be seemlessly used from TypeScript (with type checking, IDE auto-completion, and everything). I’ve also hooked into Duktape’s error system and mozilla’s source-map package so that whenever the game crashes, I get a pretty stack trace with line numbers from the original TypeScript file.

Today, the TypeScript codebase counts 6.3K lines of code (not counting the auto-generated glue), which generates just shy of 10K lines of JavaScript. It’s in great shape, and easy to modify — and already heaps ahead of the Lua version, in just 3 weeks. While I won’t be able to sustain this coding spree at the same rhythm now that my winter holidays are coming to an end, I’m definitely optimistic given the outcome.

The new editor

Those of you who have already read Lestac: The Making Of know that we were originally using Tiled to create levels.

Now, Tiled is a great tool. For example, it supports isometric tilesets — but we don’t use that. It has great support in existing 2D game engines — but we don’t use any of them. What it didn’t have support for, however (until version 0.10, which was released in September 2014!), was custom collision shapes for tiles — and we have plenty of irregular tiles in Jaakan levels nowadays. So, back in the Lua days, in the absence of a better solution, we’ve started annotating tilesets with custom properties like ‘poly’, which was a list of points, and then using a separate layer for collisions, which looks a little bit like this

full

Doing levels this way was very flexible, but also very time-consuming. Every single room was a daunting task. And if you remember the non-linear nature of the original (as shown on this megamap from the making of), you’ll understand that we also had to add teleport objects on each side of every room, to ‘connect’ them to outer rooms. And believe me, when one of them is connected to xmas25 instead of xmas12, that’s one hard bug to figure out.

So, it was time to get to work on a proper, in-game editor. I had experimented some in Lua, but didn’t go very far: no multi-layer editing, all was polygon-based, no saving/loading, and a complete disconnect with the game engine which couldn’t use the levels made in the editor. It was just a tech demo!

Armed with a mockup from @bigsylvain, I started building it from the ground up. Along the way, I made a UI system — a makeshift rite of passage from game developers suffering from NIH Syndrome, but as surprising as it may sound, the result is quite usable. I haven’t made a video recording of it yet, because there’s a few more features I want to get in before doing that, but it’ll come.

full

In the screenshot, I’m showing what it would look like if we were to make a ripoff of SMB3 based on Jaakan’s game engine. In this particular room, I’m using three layers of tiles that are purely graphic, and one layer of polygons, which is solid (the only kind of layer that supports collisions for now), and hidden (cf. the spooky ghost in the layer list). Oh and there’s one empty object layer — which cannot do anything yet — just to show off my fantastic icon design skills!

Polygon layers can be painted on and erased with a variable-radius brush, like in the old video (but better). Tile layer edition is not quite at Tiled-map-editor-levels of comfort yet, but it’s coming quickly. Rectangular-style selections from the tilesets, copy/paste & undo will remove a lot of pain from the whole process. However, tilesets can be mixed and matched at will.

The editor also takes care of the links between room itself — the red arrows you can see at the top and right boundaries of the room show where other rooms would be. Doing a Ctrl-click in these areas fires up a room creation dialog, or just switches to that room if it already exists.

In short, we’re not far from having the ideal tool to create entire worlds for Jaakan, while keeping the non-linear spirit of the original — after all, in real life, time and space aren’t perceived by humans as perfectly linear either :)

Until next time, (I promise I’ll try to keep it shorter), may you all have a wonderful week & take care.