13th Age

I'm trying to write an adventure (or actually, several) for a new tabletop RPG campaign that's going to start in a couple of months, and I am struggling.

My issues stem, I think, from how different the new system, 13th Age, is from the game I finished running last week, Monster of the Week. Where MotW is extremely light and relies heavily on improv, 13th Age is much closer to D&D's school of thought, with much more stuff to track moment-to-moment, especially once combat starts. The notes required for an entire arc in MotW feel like they'd barely be sufficient to cover a single scene in 13th Age.

While it should be easy enough to adapt the approach that worked for Monster of the Week into any other roleplaying system, in practice I'm finding it hard not to take things in a rules-heavy direction, with pages and pages of stuff written up.

Monster of the Week's missions - called "mysteries" - are largely self-contained and driven entirely by the players' investigations. The most amount of planning in a mystery is writing the six-point "countdown" of events that would happen without the players' involvement. Each location and character only needs a name and a role to indicate their involvement. I added a personality trait and "what this person knows" to my bystanders - a couple of lines, total, and almost no prepared dialogue.

Compare that to the eleven pages of stuff I've written for the first adventure in 13th Age - and that's not even all of it finished yet! I've got sketches of scenes and characters and places that would be more than enough to run with in Monster of the Week that I feel compelled to flesh out for this game. Monster of the Week's contemporary setting helps, as there's often a common real-world or pop culture reference for what a trailer park or a military base or someone's living room looks like, but a fantasy game demands (it seems) a level of ornate and detailed description that quite frankly I'm not sure my writing skills are up to.

Of course, it could just be a matter of the tools I'm using. Monster of the Week's lightweight setup lent itself perfectly to Trello boards, with columns to group cards for locations, bystanders and the monsters - but there's a separation between roleplay and combat in any initiative-driven that makes it too complex for Trello. Google Docs has been okay for making notes and blocking out the rough timeline for an adventure, but its layout encourages linearity, and I'm concerned it'll be difficult to jump between sections in the heat of a fight.

Hmm. Suddenly, I'm worried that I'm going to end up writing my own system to store everything.

Ejector

On Sunday morning, I woke up with a game idea stuck in my head; I spent a few hours with GameMaker over the course of the day, and by 9pm I had something I was happy enough with that I posted about it on Twitter. I'm never happy with my stuff enough to post about it on Twitter.

It's still full of other people's art assets and unlicensed fonts, and most of the code is borrowed from ShaunJS tutorials (but that's what they're for and anyway I used to work with him, so that's probably okay).

As I've worked on it over the last couple of days, and started thinking about how to make it a game rather than just a partially-implemented mechanic, I've come to realise that it's pretty much Nanaca Crash: the player has some limited control over the initial vector of their character's travel, and then it's basically just a case of seeing how far they can go.

I'd started to write about another GameMaker project I was working on earlier this year, but when it came to implementing the shooting mechanics I realised that I didn't want to make a game about shooting, so that's been canned until I figure out what the verb needs to be.

(This is still kind of violent, but it's very slapstick and only against your own character so I feel like that's okay.)

I'm close to getting all of the input mechanics finished - rather than Nanaca's single click-and-hold for both angle and power, I want to separate them into a hold for setting acceleration and some kind of Ouendan-type trigger for controlling angle (in progress). Initially these inputs were both controlled by the car object, but since I'm hoping to eventually have an upgrade system that would let you change the car, moving them into a separate launch controller took up most of today.

I'd dropped a basic sin() function in for setting the acceleration value - which worked for the proof of concept, but in practice the way it decelerated around the maximum value made it too easy to get the best distance reliably (in the absence of control over your launch angle).

acceleration_modifier = (1 + (sin(frames_held/period + 3*pi/2)))/2;

What I was after was a curve that would speed up as it got close to the maximum value, and bounced away just as quickly, making it much harder to hit the top every time. It was only when I drew out what I wanted that I realised that it's still basically just a sine wave, but with part of it inverted - which led me to

acceleration_modifier = 1 - abs(sin(frames_held/period + pi/2));

And now, onto the launch angle…

Where we were together

At first blush, there are not many obvious similarities between Say Sue Me's lazy winding surfgaze and Aimee Mann's more traditional indie pop, but listening to the Korean quartet's latest album, Where We Were Together, over the last few days, I can't help but feel like they're musical siblings, somehow.

When her most recent album, 2017's Mental Illness, was released I got quite annoyed by the reviews consistently describing Aimee Mann's output as "depressing". Although there's a deep melancholy to many of her songs (often disguised under a major key and an upbeat tempo), it's not accurate to say it's depressing; I've come to the conclusion that a more truthful description would be that it's depressed.

But at the same time, there's no sense of resignation or defeat - acceptance, maybe, but I've always found it somehow hopeful. It's the music of coping with your problems, of feeling sad or anxious or unloved but still picking yourself up and getting on with things - in a way I find helpful when my own subconscious threatens to overcrowd me.

I get that same sense from Where We Were Together: a reassurance that nothing is as insurmountable as our own demons would have us believe, that we're not as alone in our troubles as we often feel, and that there's light just around the corner.

Doki Doki Literature Club

Warning! Spoilers follow for Doki Doki Literature Club and The Beginner's Guide

There's a content warning at the start of Doki Doki Literature Club which is, on some level, a spoiler. It's not unusual for visual novels to touch on heavy subject matter, but to call attention to it before the title screen does stick out.

Up front, I feel like I need to say that this is a game worth playing, if you can get past the anime/VN presentation. I don't remember the last game that surprised me with its audacity this profoundly, let alone this often (and all in a package that I saw end-to-end in a little over four hours). Its density of ideas and the quality of its execution, within a medium that's uniquely suited to tell this story this way, is hugely impressive.

It will help if you have some familiarity with harem anime or other visual novels (both their general content and mechanics, even if you've not played any others; you've got to be willing to meet the genre halfway on its long periods of clicking through and reading dialogue). There are common tropes and archetypes it uses as shorthand - the childhood friend, the overly familiar upperclassman, the reluctant new club member - that not only make the opening 30 to 60 minutes much more efficient, but which set up expectations that can be exploited later.

I've been unpacking what the game means since I finished it earlier today, both its "message" and my interpretation of it, and the closest game I can think of, philosophically, is Davey Wreden's The Beginner's Guide - albeit coming from a radically different angle.

Last chance to turn back.

Isometrish: Automatic walls

Obviously, when you're building a game level (and especially if, like I hope to, you're building it procedurally), you can't spend ages making sure you've put the correct-facing wall object down at every part of the level, or fixing them every time you move a bit of floor around.

Well, you could, but wouldn't it be much better to just have a single wall object that could automatically detect which sides it needed to match to the neighbouring floor tiles?

Yes! And luckily, this is really easy to do!

There is some heavy lifting involved, though: you'll still need a sprite with a separate frame for each possible combination of walls - north on its own, east on its own, north and east together, south on its own, north and south together…

(If you want a shorter notation, you need 2n-1 sprites, where n is the number of sides you need to consider. For most cases, this'll be four, so you need 24-1, or 15 images - plus one with no walls.)

But how do you know which image to draw based on the combination of faces required? Binary!

Assign each face a binary number - for a square, this'll be 1 for North, 2 for East, 4 for South and 8 for West. The neat trick with binary numbers like this is, the sum of any subset of them is unique! Which means we just need to add up the numbers corresponding to each 'active' face, and that tells us which image to load.

In GameMaker Studio 2, sprites have subimages - this is most commonly used for animation frames, but we can also use it here to keep a collection of images together in a common object. You need to make sure the various subimages are added in the correct order (the easiest way to do this in GMS2, I found, was to save the images into a common folder numbered 1.png to 15.png, then use the 'Create sprite from image(s)' option).

Now that our sprite is set up, we can add the following to the object's create event:

iso_sprite = sWall;
var f = 0;
if (place_meeting(x, y - grid_size/2, oFloor)) f += 1;
if (place_meeting(x + grid_size/2, y, oFloor)) f += 2;
if (place_meeting(x, y + grid_size/2, oFloor)) f += 4;
if (place_meeting(x - grid_size/2, y, oFloor)) f += 8;
iso_subimg = f;

This checks the room for a floor on each side of our wall, and adds that face's value to the total, resulting in the correct subimage index that we need to draw, which is done in the draw event:

draw_sprite(iso_sprite, iso_subimg, screen_x, screen_y);

(In this example, screen_x and screen_y are the pre-converted grid-to-screen coordinates.)

And presto - a single wall object that you can drop into your room, which will automagically show the correct wall faces for any surrounding floor tiles!

Isometrish: Perspective

Do you ever suddenly realise that you understand something that's been bugging you for days, and then find it impossible to see how you didn't get it in the first place?

GameMaker is great at 2D - side-scrolling and top-down games are a breeze to get working. There are dozens of video tutorials that can get you up and running with a platformer in fifteen minutes or less. But if you want to do anything slightly more complicated than that, well… time to do some maths.

Luckily for me - and you, if you're wanting to do this yourself - YellowAfterlife has a really good piece (aside from some confusing terminology) about translating grid coordinates to on-screen coordinates which, although it still took a lot of practical trial and error for me to really understand, gave me enough confidence to actually start trying things.

While drawing objects to the screen is the more technically challenging part of the process, it actually took me longer to understand moving around - even though it's really simple.

The short version is, I needed to realise that the character's not moving on the screen, but moving on a 2D plane (as if you're doing basic a top-down game); those 2D X and Y coordinates are then warped by a couple of simple functions to correspond to the on-screen, 'isometric' plane that's on the screen.

Basically, you don't need to care about the screen coordinates- the maths will take care of it for you! Just do your stuff as normal, and the maths around the drawing step takes care of the rest.

Which can use the exact same movement code I used in the top-down version, and results in this on the screen:

I had some other issues drawing things in the right place - like I said at the start, that's actually the technically complicated bit.

I'd assumed, incorrectly, that when you're drawing a sprite in code the X and Y coordinates you give it would be where it started drawing, with the top-left corner of the sprite. Turns out the origin you set in the Sprite window matters! For walls and floors to line up correctly, this means you need to set the origin in the same place on the 'floor', which took me some time to figure out (particularly since the sprites in the room editor aren't the same as the ones you'll see when playing).

I also hit some trouble with aspect ratios because my grid (and the isometric sprites) were larger than those used in YAL's example - and since I'm still not 100% on the maths involved it took a little bit of trial and error to iron that out. (Turns out you just need to calculate the ratio of the isometric tiles' dimensions to your grid squares'.)

The way GameMaker Studio 2 handles 'depth' for draw orders has changed slightly too, favouring its built-in layers which are, in practice, pretty incompatible with isometric drawing (but are still really handy for organising objects in the room editor). The documentation suggests you should still be able to arbitrarily assign depth to your objects, but in practice I found that doing so prevented them from rendering at all, until I added the following in an init script:

layer_force_draw_depth(true, 0);

So now I've got a map, and the ability to move around it! And, as it turns out, right through the walls…

Isometrish

Right, fuck it. I'm going to write about something that terrifies me: my own code projects.

About the only thing I've programmed 'publicly' is a 140-character random level generation script (in Ruby). I'd written it in JavaScript originally, but decided for no particular reason to try and shorten it until it fit in a tweet. (This was before tweet length got doubled.)

def l w,h;g=(1..h).map{[]};y=rand h;x=g[y][0]=0;(g[y][x]||=1;n=y+rand(-1..1);n>=0&&n<h&&g[n][x].nil?? y=n : x+=1)while x<w;g[y][x-1]=2;g;end

But I've started something a bit more ambitious: I'm trying to make a game. Or at least, most of a game's systems.

I worked at YoYo Games for over six years, and it's only since I left in November that I've really started to use the product, GameMaker. I've thrown together little proofs of concept - platformers, a tank driving thing, some experiments with shooters - but never really had a specific goal in mind.

Having something to aim for means having something to miss; it's easy to just try out hitscan shooting in a tiny demo level, but make a game?

I'm now a couple dozen man-hours into a clone of Crusader: No Remorse. I don't know how often, if ever, I'm going to write updates on my progress, but I want to try and get less defensive about my code, and exposing some of it to the air might help.

(It helps that I don't expect anyone to read this, though.)

I've been meaning to find something to make me blog more this year, and maybe this is it.