Jam Debrief

So hey. This game was made by one person for the GMTK Gamejam.

The jam lists 48 hours (well, 50:25 in real money, but notionally 48), I work alone, and I like to sleep in. Realistically this was nearer 16 hours of actual coding, drawing, etc than 48 — but the hours I spent in bed or cooking food while the game mechanics ticked over in my head were not wasted.

The theme this year was Roll of the Dice

The GMTK themes are always fun. The last couple of years had Out Of Control and Joined Together — it's always something that suggests a mechanic or style but can be interpreted in other ways. I always like to build something that could only have been built for the theme, there's nothing wrong with making a platformer where your character is a rolling die — it completely fits the theme — but I want to engage with the theme as fully as I can, deep in the game mechanics, because that's what happens  to interest me, and there's no point doing a gamejam if it doesn't interest you.

The first thing I wanted to do was come up with an idea. I latched onto randomness fairly early because the theme rather dictated it, although I've seen some very clever puzzle games that use the geometry of a die rather than its traditional gaming purpose as a starting point and I wish I'd thought of them. Except I don't, because those games still exist and I quite like Z-POINT too. Then I watched GMTK's randomness video. That video is in their "popular videos" panel at the moment so I suspect I was not the only person with this idea. It's fairly easy to see why.

Ideas I had, then rejected

I thought about a turn-based RPG where instead of actually playing a turn, you select one of maybe five dice, each of which has six possible turns on. You could gamble on the die with two brilliant moves and a terrible move, or play it safe with the die with six basically OK moves. That seemed like it would need a lot of content, and content — at least, content I have to make — is the enemy of short-form gamejams. That's why all the levels in Z-POINT are procedurally generated.

I thought about a top-down shooter where your gun fires in one of the six standard die-spot patterns at random — eg, 2 would fire north-west and south-east, and five would fire in all four diagonals and drop a timed explosive. It's a cute idea, but I couldn't work out a way to stop the gameplay descending into button-mashing — there's really no better way to attack something than stand near it and hit fire until you roll something that hits it.

I thought about an X-Com style affair where you have a squad of six agents and every time you issue an instruction — "move left" or "fire" — one of them at random would obey. I like this idea, but I think it would be quite annoying to play — either there are moves that are safe whoever does them, in which case the game is boring (and basically what everyone built for Joined Together), or there aren't, in which case it's dumb luck. I've played a few games from this jam that suffered from the latter problem and while it doesn't stop them being nice diversions to play for a few minutes while browsing the submissions page, I wanted to make something that could in principle be expanded into a full release one day. IDK, perhaps it would have been fine. You never know how a game's going to turn out until you prototype it, but a 48h jam is a prototype, so I might as well prototype my best idea.

My Best Idea

The paragraph from my notes that became Z-POINT just reads:

a game where the collectibles are dice and different yahtzee-style combinations net you different rewards. you can’t tell what a die will be before you pick it up but you can throw away dice to “go for” a particular thing

The next question was what kind of game to put that mechanic into. I enjoy a gamedev process where "what genre is it" is a secondary consideration. My main consideration was that the randomness should function to screw up your plans — maybe you're collecting for one move, but you get the dice for another, and you should be able to (or have to) quickly change tack to suit your new circumstance. Planning should be advisable, but not sufficient for success.

To my mind, the obvious model for this kind of gameplay is Tom Francis' superlative Defenestration Trilogy — Gunpoint, Heat Signature, and the up-coming Tactical Breach Wizards. Heat Signature's array of gadgets and random environments are incredible at creating these sudden re-planning moments. I can't count how often I've fully intended to wander unseen through a spaceship and ended up blasting myself out of a window to escape some surprise consequence of my own actions.

So I went for a kind of stealth game. There would be guards, and cameras, and maybe lasers and switches and blast doors and metal detectors and whatever else I could think of, and different moves would affect different ones. Can't get the dice to unlock the door? Better hope you can fight off the guards! I think the office setting came just from the fact that scrolling means you need to have a camera system and ugh, life's too short to write camera controls. An office block is literally a series of compact, square levels, so it seemed a natural fit. I opted not to explain why the stairs are apparently on opposite sides on each floor. This is a terrible design for an office.

I considered not having any guards, keep everything static and make the game thinky, but I don't think that would have been the right call. The randomness adds chaos, and you can't have intellectual chaos. That would just be Twitter, and Twitter is awful.

That gave me a few basic moves — an EMP blast, some kind of anti-person weapon... The flashbang and 'lights out' options came fairly quickly as well. I never did put in any doors or lasers, so I didn't need moves to work against those. I tried to assign the moves to die combinations that would maximise replanning — so five-of-a-kind knocks out all the guards, but four-of-a-kind knocks out all the cameras, so your plan will be fundamentally different if you can't get that fifth die. Similarly, a run of five gives you a knockout grenade, while a run of four gives you an EMP grenade. (Generally I assumed the mobile guards were a bigger threat and required better dice to dispatch them.)

The last move to go in was the "emergency teleport". A worry with this game was that people would be able to ignore the dice mechanic and barrel through the game using the basic moveset that didn't require dice. My solution to this was to not put in any basic moveset. You need dice to do anything beyond move around. This worked a charm, but created a new issue where you could get stuck in a corner, able only to wait for a guard to either come and find you, or wander off. This was not fun. The teleport is designed so you can get out of that situation, but at a cost of all your dice — you can start over from elsewhere in the level, but you will start over. It's not a superpower, it's an escape hatch.

In many ways, the teleport is an extension of "run", a bad move you should not do — it's designed to get you out of a tight spot in a pinch, not to accomplish much. If you hold A, your character stands up and runs, increasing their speed but meaning guards can see them over desks. Some of the early levels you might be able to run through before anyone has time to sound the alarm. That stops early on.

The next challenge was the control system. Obviously the left stick was move, and start was pause, and I need a face-button for 'run' — A. The first version used L and R to select dice to discard, and X to discard them. That left Y and B for the context-sensitive moves. I put the "best" move on B and left Y for "secondary fire", like if you had a knockout grenade but really wanted to throw an EMP grenade instead. This was fucking unplayable.

The problem was that you just couldn't get it in your head. Even with the HUD telling you, Zelda-style, what each button was, they changed so often that your instincts were useless. In order to make the game work but at all, the controls had to be more predictable. So I shuffled all the dice-discarding controls to the left hand (d-pad and L) and kept X, Y and B for special moves. It works out that X (because it's blue) is always EMP; B (because it's red) is always an attack, and Y is "panicky escape moves" — but the real idea of it is that (because of how I separated the EMP and attack moves when assigning die-combinations) you can never have two moves available on the same button. You can't have a run of five dice and five dice the same, or a full house and no dice at all. You can (technically) have four dice the same and a full house, but we ignore this because the EMP and smoke bombs are nearly always so much better than Lights Out that I didn't think anyone would notice or care (and arguably five dice the same isn't a full-house anyway).

This also left R open to cancel targetting, which is just a nice thing to do — user actions should always be cancellable until they're done. The only real annoyance with the controls now was that buttons sometimes required a single tap and sometimes had to be held down for aiming. This doesn't sound like a big problem, but after the third time I dropped a flashbang at my feet and all the guards came running over to my exact position, I changed the code so that you had to hold the button for a little while or else the move would be cancelled. Handily, the target flashes up while that happens so you get a little reminder of why nothing happened.

Balance

An aim was that this game should as far as possible teach itself. That's not really possible with a 48h window, one dev, and seven special moves, but I made sure the early levels were heavy on dice and low on enemies so you could get used to the mechanics before you faced any real threat. These numbers slowly change until level 15, which I defined as "hard". I think after that they just keep on going. I suppose in theory the game will eventually be completely plastered in guards and cameras and there'll be no dice at all. This is not a game you can win.

The main deliberate 'balance' think I threw in was keys — these are designed to prevent players simply running through the level. By forcing you to move around the screen a bit, you have to spend time in the level, which gives the guards the chance to sound an alarm if you're not careful.

I considered fudging the RNG slightly. Forcing it to give you the value you're obviously going for after (say) 8 dice, or making the last die a one in four chance rather than one in six, but I chose not to. Because it sounded hard. I watched a YouTube video about conservative propaganda children's books instead. I think it was the right call.

AI

...would be a very generous term for the guards in this game.

The game is designed to be playable without this information, but here it is for those as like to know exactly what they're up against:

They mostly just amble about — bouncing off walls and occasionally turning a corner. If they see you, or a flashbang goes off, they will become Suspicious. If they are suspicious of something they will head toward it, a little faster than their normal patrol. Suspicion is indicated by a yellow line. A red line means they can see you right now. All the time they can see you, they grow Worried. Worry is indicated by an icon above their heads. When they are too worried, they sound an alarm. Cameras grow Worried faster than guards, but obviously cannot move.

The Levels

Levels are generated by a process called "waveform collapse", because I saw it on YouTube and wanted to try it out. The idea is (in a loose analogy to quantum mechanics) you start out with a map where any tile can be anything, pick a tile, and decide what it is. This "collapses" the nearby tiles into the allowed neighbours — eg, if you picked "empty floor", the tile above it might be "empty floor" or "bottom edge of desk" but couldn't be "top edge of desk" or "top right corner of desk". Having narrowed down that tile, its neighbours can be narrowed down a little. Eventually, you get a nice-looking map. Then we check there's a path from top to bottom, and then throw in a bunch of guards and so on.

The Name

Z-POINT is a reference to two things — firstly, this game is similar to Gunpoint but without a gun. Secondly, a point is a kind of punctuation, so Z-POINT could be a reference to Zero Punctuation, which again describes a game with no guns in it, but is also an oblique reference to the game's two main mechanics: Yahtzee, and crosshairs.

The Tech

My previous jam games were both made in PICO-8. I love PICO-8. If you're not familiar, it's a "fantasy console" — that is, a console that exists only as an emulator. It's designed to be similar in spec and general limitations to a NES-era console. The screen is 128x128, you have a pre-set palette of 16 colours, and the sounds are all saw waves and noise. The difference is that the games are written in Lua rather than 6502 assembly code (which is a bad choice for a gamejam).

I do not like Lua. I mean it's fine. But the arrays are 1-indexed so it has to go. More importantly, the PICO-8 doesn't have a great processor — by which I mean that the emulator counts how many things you ask Lua to do and will drop the framerate if you ask too much of it. This is an arbitrary limitation imposed by the designers, and for good reason — the resolution, palette, CPU and sound "chip" are all designed to say "hey, don't worry about making this thing incredibly rich and detailed, because I won't let you. Just make it fun". That makes it a really good platform for making smol games. But that limitation has bitten me in both previous jams, and if I wanted to optimise graphics code on tight deadlines for no pay on a Sunday afternoon, I'd have applied for a job at Activision Blizzard. So for this jam, I went too far in the other direction, and wrote my own engine, which as a codename I've been calling Nano 5 (after the PICO-8 and HTML5, in which it runs).

The Engine

"Game engine" is perhaps a rather grandiose term for what I wrote. The idea is that (like PICO-8) you provide an "update" function and a "draw" function. "Update" applies one frame of game logic, and "draw" updates the screen. In principle they should run one after the other, but IRL, "draw" calls could be dropped if the game is slowing down. Nano 5 will more or less do the following:

• make sure your game runs at a steady framerate, to a maximum number of dropped frames;
• load sprites, sounds, etc from external files;
• provide handy functions like "draw sprite", "play sound" and "write text";
• provide information about user input, regardless of whether it's come from a gamepad or the keyboard;
• etc.

It doesn't have any Unity-style "gameobject" logic or a physics engine or anything like that. I don't want that. That sounds hard to understand. I already know how to JavaScript and moving objects around a map isn't super hard. So this is just a way to make JavaScript a bit more game-oriented. I don't mind spending my weekend writing a tiny physics system but I personally don't want to write a sprite renderer twice.

Speaking of which, it is pure JavaScript. This is important to me. All content on the web is just a bunch of text files which in principle you can write in Notepad and test in Edge — any off-the-shelf compyter comes with a basic but functional set of tools you can use to build arbitrarily complex apps to run in the cross-platform, open sandbox that is the web. It's one of the most democratic platforms we have, and I think it's important that people can build on it without having to install a whole slew of slightly gatekeepy "build tools". I've nothing against tooling in the right context — realistically there's a cap on what you can build without it — I just don't want it to be mandatory. So many tutorials and things start with "create-react-app" and I really think we should teach people that you don't have to work that way. You can, if it's appropriate, just type out the whole app from scratch. So my engine doesn't require or use such things. The build process is "put the files on the internet". You can run it from Github Pages or itch.io for free with no messing about. It isn't minified or bundled so you can poke around inside it and see how it works.

This was its first proper test and it did really well. One of these days I should release it properly. Suggestions for names are welcome. Perhaps it will become Z-something after this game.

In Hindsight

If I was to expand this, I'd want to add more content. I always planned to have a potplant you could push around for mobile cover, maybe a "hide guard bodies under desks lest they be discovered" mechanic, the doors and switches and lasers and so on... Generally just more stuff to interact with.

I'd also improve the level generation. It's fine as-is for a jam game but it doesn't generate what you'd call "realistic" environments.

I'd also want to experiment with a larger dice inventory — maybe you should be able to carry six or seven dice, but that would have been really hard to add into this game after I'd started. Perhaps it would become an issue if you could have four dice the same and a run of four. The control scheme might need radically rethinking. It might even become turn-based, or have a Zelda-style pause-menu to choose what moves you equip. It might even become a tabletop game — honestly I think this has legs as a mechanic in DnD-style dice-based tabletop RPGs.

Overall

I'm honestly very pleased with this game. It generates some really fun moments of blind panic, terrible plans that somehow work, and frustration when you just need one four and you pick up 12 dice and get none. You can tell it's built in two days, it won't hold up as much more than that, but I'm happy with it being what it is.