fuzzy notepad - release

Cherry Kisses, on Steam

2020-11-30T16:44:00-08:00

Whoops! I meant to write about this when it originally came out, in April, but never quite got around to collecting my thoughts. Here is a very rushed subset of them.

The game is extremely NSFW, but the commentary below is not.

The game itself

I like the game. It’s essentially a visual novel, but disguised.

I’ve played a decent number of visual novels, and I’ve thought a lot about them and their role as kind-of-games, and I’ve noticed the thorny bits that I don’t like. And my thoughts have circled around the notion of player agency.

Agency is what makes a game feel like a game. You have input, in a broad sense. You can do something to the game, and it will react appropriately (fingers crossed).

This theory explains the awkward position of visual novels. The bulk of the experience is reading a passage, pressing spacebar, and GOTO 10. You don’t have meaningful input; pressing spacebar isn’t a decision, it’s scrolling.

When you do have input, it generally comes in the form of a menu. But this doesn’t feel like you’re making a choice; it feels like one is being extracted from you in the middle of an otherwise passive reading experience. The base form of the game is reading, and that has been interrupted at a predetermined point to demand something of you. You often don’t have enough information to make a meaningful choice, either, so this becomes a game of saving at each branch and performing an exhaustive depth-first search of the story. As time goes on, you end up skipping through more and more of the early parts, and may hit a point where you go down a decision branch not even remembering what form the story took before you got there.

This is a weird experience.

I wanted to try to improve the feeling of a VN without altering the substance, so this one is disguised as an RPG. I mean, not really an RPG, but that brand of top-down “walk around and interact with stuff” framing.

You play as Cerise, and the entire game takes place in her shop. At any given time, zero or more customers are present, and you can either twiddle your thumbs at the counter or talk to one of them. Whatever you do will generally advance time by an hour, which may change the set of customers; some folks left or arrived while you were busy doing something else. And different folks have different reactions to being ignored, so the whole game becomes one large meta scheduling puzzle.

The thing is, this could’ve been done just as well with a menu at the start of each hour, asking who you want to talk to. The gameplay would’ve been functionally identical. But this scheme feels completely different (at least to me) for several reasons:

Instead of choices being “on top of” the prose, the prose is on top of the choices. It feels like the choices you make cause the prose to happen, rather than being forks in the middle of a river you can’t escape. You can wander around the shop as long as you like, taking breathers, and time will not pass until you, the human at the controls, cause something to happen. (You could say the same about a menu in a VN, but there you can’t do anything else either; the entire game is frozen until you interact with this modal dialog.)
You can do other things. Not many, granted, but you can examine every single object in the shop, and they all have different descriptions (even if they look identical). A typical visual novel doesn’t give you the opportunity to go on frivolous tangents, but I think a big part of games is being able to forget about the progression for a minute and fuck around with something that looks interesting. Stop and smell the roses, in this case literally.
A menu spells out all possible options with equal priority. They’re just items in a list, after all. A physical world, on the other hand, can add subtle differences — choices may be more or less obvious, more or less compelling, or be presented in some way that adds to the narrative. For example, while customers tend to show up at arbitrary spots throughout the shop, your girlfriend Lexy will wait for you right behind the counter, suggesting a more personal relationship even if you don’t yet know who she is. Or consider the ubiquitous option of ignoring everyone in the shop and passing time at the counter instead. That would usually be pointless, so it would be obnoxious to list in every single menu, but having it as an option in-world makes it less obvious… which is perfect puzzle fodder. Just saying.

As an added bonus, every character in the game has a “happiness” rating from -3 to 3. If you can help them with their problems, their happiness will increase. The numbers are largely arbitrary, but you do get a final score tally at the end, and that gives some sense of measured accomplishment that’s more nuanced than a mere good/bad ending. You can ignore it altogether and be happy with the story you got, or you can go down the rabbit hole and try to find the unique path through the game that will make everyone happy and get you a perfect score.

These feel like really subtle design decisions that have an equally subtle impact on the experience. I don’t know what impact it had on anyone else, but I really liked the results. I didn’t mind playing through the game a gazillion times while I was developing it, because it’s just nice to play. The story isn’t especially deep, but it has a lot of little lighthearted interactions with a variety of characters, and sometimes different threads impact each other in really subtle ways. Sometimes I ran across an interaction I’d forgotten I’d written! It feels like the kind of story game that you can’t merely grind every ending out of, one that always has a chance to surprise you a little.

I still have other ideas for making narrative games that feel more player-controlled, so fingers crossed that I can pull them off.

Steam, numbers, business

This is the first game I’ve put on Steam, a platform I’ve long had mixed feelings about. On the one hand, it’s cool that video games have something like a package repository. On the other hand, that package repository is owned and controlled by a single company that sits back and rakes in billions (30% off of every sale!) from a glorified FTP server, something that Linux distributions do for free. And it’s normalized casual DRM, which I do not enjoy. (If I did it right, then manually running Cherry Kisses while Steam is closed should simply run the game without interacting with Steam at all.)

On the other hand, I can’t deny the impact. The Steam release earned more in its first two weeks than the itch release did in more than a year.

…okay, that isn’t an entirely fair comparison. The itch release also had a free “demo” version that was exactly like the “real” version, only with lower-resolution artwork. Loads of people played that (almost 20k downloads as of now), and in retrospect we may have shot ourselves in the foot a bit by offering a free version. But I do like when people can play my games, and releasing anything only in a paid form feels like extorting people out of their money.

I am not good at business. It mostly feels bad.

Despite that, the game has somehow grossed a bit over $10k in the last eight months (which shrinks to $6k net after the Steam tax, VAT, and refunds). That’s not a windfall, but it’s far more than I ever expected to earn on the back of a month-long jam game, and it all went to paying our 2019 taxes so it’s like nothing ever happened. It certainly makes me optimistic about selling something meatier.

Creating the Steam release

We did update the game somewhat for Steam, a process that ended up consuming almost a month somehow and still didn’t cover everything we wanted. The most obvious in-game things were the addition of character profiles, an image gallery, and an options menu — which is to say, all UI things, which I had to build in LÖVE, by hand, which was an incredible pain in the ass. But it works, somehow.

Of course I also added a bunch of Steam achievements, which were kinda fun to decide upon. It’s a story game, so they’re mostly of the form “encounter this bit of the story”, but that’s fine?

But oh boy, the thing that really took the longest time was linking to Steam at all. You get a DLL/SO, some header files, and some hit-or-miss documentation, and the rest is up to you.

The library is, of course, designed for C++.

I am not using C++. I am using Lua.

This posed something of a problem.

I prefer not to touch C++ with a ten-foot pole, so writing some glue on the C++ side did not sound appetizing. (That would’ve also left me with the difficult problem of compiling that code for platforms I do not own or develop on.) That left me with binding to the Steam API from the Lua side.

After several days of Googling, finding years-old projects that promised to do this, and completely failing to get anywhere at all with them, I resigned myself to writing something from scratch. LÖVE uses LuaJIT, which comes with the excellent FFI library, meaning I could bind to C with nothing more than a header file.

The Steam API does have a C compatibility layer, but it is basically not documented, so I had to do some guesswork to get from the documentation to the parts I actually needed. Also, the core of the Steam API is this hokey async messaging system built out of macros and C++ metaprogramming, so I had to do a clumsier polling thing using disparate parts of the C API instead. I finally discovered that there’s example code in a big honking comment in the headers themselves, except the example code is wrong, so I had to fix that as well. Plus all the obtuse bugs like with padding on different platforms which for some reason is baked into the messages that Steam sends because C programmers don’t know how to actually fucking serialize anything. It was an adventure!!

But after all that, I managed to get achievements working, and also leaderboards. Neat, cool, etc.

The game does leak coroutines indefinitely if it’s run through Steam but can’t connect, though. Sorry.

Man. The Steam website has so many features, and the documentation explains them all in one succinct list, but fuck me if I can actually find any of them. So many things are not linked from obvious places; there have been many times I knew a particular page existed but could not figure out how to get there, and ultimately I started relying on address bar history instead of trying to navigate this website.

And so many features are awkwardly built on top of older features that are actually something completely different. Like we have a “developer” page on Steam, but the only part of it we can really control is a single line of plain text at the top. If you go to the “about” tab, it just shows you that line again! That’s all we can put there! You have to click “visit group page” (why would you do that??) in the sidebar of that page to actually get to something we can control.

In stark contrast to itch, Steam really wants your store page to look like a Steam store page and not like a your-game store page. Your artwork (and there is so much artwork) has to be manually approved by a human, and along the way I discovered some extremely unintuitive rules, like that the library header has to be SFW even though it’s only visible to people who already own the game. Store pages also have a “legal” section, but I couldn’t list open source libraries I used (and their licenses) in that section, because I’m not allowed to have links. Like, at all. They really don’t want you to have links. Games exist independently of the humans that made them in the world of Steam; they are isolated jewels floating in a vast space that is linked directly to gaben’s bank account.

I cannot comprehend how weirdly low-key hostile the whole experience felt. All so they could take a third of my money.

Oh, and there’s no Mac release, because I do not have a Mac on which to sign Mac software and do not wish to pay Apple for the privilege, and Mac software does not run any more if it’s not signed. Sorry. Yes, I fucking know about fucking right-click open, please stop fucking telling me about that, that is not useful for software that is run from someone else’s launcher.

Reception

People seem to like it?? I mean, I’ve had a dozen or so people tell me to my face that they had an especially good experience with it, that it was cozy and upbeat and just nice. For a few of them, it apparently helped ease some aversion they’d had to sex, simply by showing it playing out well.

It’s funny that I thought so hard about the general design and how agency worked and all that, but 99% of the feedback has been about the feeling of the prose itself — something that just kinda fell out of my fingers. I guess I’m not surprised — after all, if these players thought as hard about game design as I do, they’d probably be designing games.

As of this writing, there have been 19.5k downloads on itch and 1750 sales on Steam. Of the Steam sales, a hair under 80% of the people who own the game have actually played it, so if I extrapolate wildly, maybe 17,000 people have played it.

But I don’t see anyone talk about it outside of my immediate circles, which feels a bit weird. Maybe? I’m not sure what the “normal” amount of conversation about an admittedly niche game is. I don’t know how things really spread by word of mouth, and I thought this might be an opportunity to gleam some insight about that, but it has not visibly materialized even though the game is being bought by people I don’t personally know.

On the one hand, it’s a sex game, so many folks are less likely to talk about it. (A couple people even specifically asked if Steam has a way to hide what game you’re playing from your friends — and, alas, it does not.) On the other hand, it’s a furry sex game, and furries are traditionally not so tight-lipped.

Maybe there’s not that much to say; the impact it’s had on people I know has been fairly personal, and if it didn’t have that kind of impact then it’s just a cute little story game.

Lessons learned

I have no idea. There are so many confounding factors here that I don’t know how to conclude anything.

I guess I’m pleasantly surprised by how many people bought a fairly short game for $7. As it turns out, people will give you money for a thing if you ask for it? That’s nice to know.

Releasing on Steam is such a huge pain in the ass lol.

Sales spiked right at the beginning and then flattened fairly quickly, but it still sells a few copies a week, so it looks like it’ll be a little trickle of income for a while. It’d be cool to get a few medium-sized games on Steam as an extra source of income. I suspect porn games have a bit more staying power, too.

Writing UI by hand sucks ass. I gotta switch to Godot asap.

Lexy’s Labyrinth

2020-09-26T19:28:00-07:00

🔗 Lexy’s Labyrinth
🔗 Source code on GitHub
🔗 itch.io later

Here is Lexy’s Labyrinth, a web-based Chip’s Challenge emulator.

It’s easy to get into and mostly speaks for itself, so here is a story.

Once upon a time, there was a puzzle game called Chip’s Challenge. It was created in 1989 for the Atari Lynx, an early handheld that is probably best known for… uh… Chip’s Challenge. It stood out as a curious blend of Sokoban head-scratching with real-time action, and it was one of the first computer puzzle games that had a whole pile of different mechanics and relied on exploiting the interesting interactions between them^{[citation needed]}.

The game found wider recognition with its inclusion in Microsoft Entertainment Pack 4, and later the Best of Windows Entertainment Pack (charmingly abbreviated “BOWEP”).

That in itself is a curious story — numerous features of the Atari Lynx version were lost in translation, most notably that the Lynx version has the player and monsters slide smoothly between grid cells, whereas the Microsoft port has everything instantly snap from one cell to the next. Also conspicuous is the presence of several typos in level passwords, which are exactly consistent with a set of notes a player took about the Lynx game, but which would be impossible in a straight port — the Lynx level passwords weren’t manually set, but were generated on the fly by a PRNG.

The most obvious explanation is that the developer responsible for the Microsoft port didn’t have access to the Lynx source code, and in fact, had never played the original game at all. That would explain nearly every major gameplay difference between the Lynx and Microsoft versions, which are all things you’d never notice if you only had static screenshots and maps to work from. Given that restriction, hey, not a bad job.

I played the BOWEP edition of Chip’s Challenge as a kid and was completely enamoured. I suppose what got me the most was the same thing that I found so compelling about Doom: the ability to modify your environment, whether by using blocks to clear water or toggling green blocks or generating new monsters from a clone machine. Being able to affect my environment in (more or less) free-form ways felt curiously powerful.

…

Well, let’s not think about that too hard. I’ll save it for my therapist.

Some years later I discovered an incredible tool called The Internet, and with it I learned of the impending Chip’s Challenge 2, a sequel with way more tiles and possibilities! Fantastic!

Unfortunately, there was a complication. Epyx, the original publisher of Chip’s Challenge, had gone bankrupt (somehow!) and had sold most of its assets, including the Chip’s Challenge rights, to a company called Bridgestone Media (now Alpha Omega Productions), a Christian propaganda distributor.

You read that correctly.

Bridgestone, a company that generally dealt in movies, had some very peculiar ideas about the video game industry. Apparently they expected the assets they’d acquired to magically make them filthy rich — you know, just like Jesus would want — despite having acquired them from a company that had just evaporated. As such, they told the original developer, Chuck Somerville, that he could only release Chip’s Challenge 2 if he paid them one million dollars upfront.

He did not have one million dollars, and so Chip’s Challenge 2 languished forever.

(At this point, in hindsight, I wonder why Chuck didn’t simply change the story and tileset and release the game under a different name. Apparently he did start on something like this some years later, in the form of an open clone from scratch called Puzzle Studio, but it was eventually abandoned in favor of Chuck’s Challenge 3D. But I still wonder: why start a brand new thing, rather than rebrand and release the existing thing?)

We did have some descriptions of new Chip’s Challenge 2 mechanics, and so at the ripe old age of 15, with no idea what I was doing, I decided I would simply write my own version of Chip’s Challenge 2.

In QBasic.

Also I didn’t really understand how to handle the passage of time, so the game was turn-based and had no monsters.

But, given all that, it wasn’t that bad. I found the source code a few years ago and put it on GitHub along with a sample level and a description of all the tiles you can use in the plaintext level format. I’ve got a prebuilt binary for DOS (usable in DosBox) too, if you like — just have a levels.txt in the same directory, and be sure it uses DOS line endings. I used to have one or two actual levels, but they have tragically been lost to the sands of time.

That would’ve been 2002.

Thirteen years later, in April 2015, a miracle occurred and defeated the Christians. Chip’s Challenge 2 was released on Steam.

It was fine. I don’t know. Over a decade of anticipation gets your hopes up, maybe. It’s a perfectly good puzzle game, and I don’t want to dunk on it, but sometimes I interact with it and I feel all life drain from my body.

I don’t even know whether to talk about this completely unreadable way of showing hints or the utterly baffling justification of “being female” for these properties.

But it’s fine. The game was Windows-only, but it was old Windows-only, so Wine handled it perfectly well. I played through a few dozen levels. Passwords were gone, so you were free to skip over levels you just didn’t feel like playing.

And then they patched a level editor into the game, and it completely broke under Wine. Completely. Like, would not even run. It’s only in recent years that it even tries to run, and now it can’t draw the window and crashes if you attempt to do anything.

The funny thing is, apparently it doesn’t draw for some people on Windows, either. It doesn’t for me in a Windows VM. The official sanctioned solution is to… install… wined3d, a Windows port of the Wine implementation of Direct3D.

I don’t know. I don’t know! I don’t know what the hell anything. This situation is utterly baffling. What even are computers.

I gave up on the game until recently, when something reminded me of it and I tried it again in Wine. No luck, obviously. I spent half a day squabbling with bleeding-edge versions and Proton patches and all manner of other crap, then resorted to the Bit Busters Club Discord, but they couldn’t help me either.

And then something stirred, deep inside of me. This game wasn’t that complicated, right? I actually know how to make video games now. I even know how to make art, sort of. And sound. And music. And…

And here I am, a month later, having replicated Chip’s Challenge in a web browser, fueled entirely by some new emotion I’ve discovered that lies halfway between spite and exhaustion. My real goal was to clone Chip’s Challenge 2 so I can actually fucking play this game I bought, but it is of course a more complex game. Still, CC2 support is something like 60% done; most of what remains is wiring, tracks, and ghost/rover behavior.

CC1 support is more interesting, anyway — there are far more custom CC1 levels around, and Lexy’s Labyrinth exposes almost 600 of them a mere click away. Given that the original Microsoft port was 16-bit and is now difficult to run (and impossible to buy), and the official (free!) Steam release is fairly awkward and unmaintained (the dev mostly makes vague statements about “old code”), and even the favored emulator Tile World has the aesthetics and usability of a 1991 Unix application, I’m hoping this will make the Chip’s Challenge experience a little more accessible. It has a partially working level editor, too, which lets you share levels you make by simply passing around a URL, and I think that is fucking fantastic.

LL cannot currently load level packs from the Steam release, but it’s a high priority. In the meantime, if you really want to play the original levels (even though CCLP1 is far better in my experience), it’ll load CHIPS.DAT if you’ve got it lying around. Also, it works on phones!

Probably the most time-consuming parts of this project were the assets. I had to draw a whole tileset from scratch, including all of the CC2 tiles which you don’t even get to see yet (and a few of which aren’t actually done). That probably took a week, spread out over the course of the entire last month. Sound effects took several days, though they got much easier once I decided to give up on doing them by wiring LFOs together in SunVox and just use a bunch of BeepBox presets. I spent a couple days on my own music track, and half a dozen other kind souls chipped in their own music — thank you so much, everyone!

And thank you to the Bit Busters Club, whose incredibly detailed knowledge made it possible to match the behavior of a lot of obscure-but-important interactions. The Steam version of CC1 comes with solution replays, and LL can even play a significant number of them back without ever desyncing.

I’ve been ignoring pretty much everything else for a month to get this in a usable state, so I’d like to take a break from it for now, but I’d really like to get all of CC2 working when I can, and of course make the level editor fully functional. I love accessible modding tools, you don’t see many of them in games any more, and with any luck maybe it’ll inspire some other kid to get into game development later.

…okay, I haven’t been ignoring everything else. I also reused the tiles I drew for a fox flux minigame in a similar style, except that you place a limited set of tiles in empty spaces and then let the game run by itself. Kind of like… Chip’s Challenge meets The Incredible Machine.

(That arrow tile has since been updated to be more clear, but it means “when you hit something, turn around instead of stopping and ending the game.”)

I guess two little puzzle game engines isn’t too bad for not quite a month of work!

Star Anise Chronicles: Oh No Wheres Twig??

2020-05-10T21:54:00-07:00

🔗 Play it on itch.io
🔗 Play it on the PICO-8 BBS (where you can also download the cart and view the source code)

(I originally drafted this just after publishing the game, but then decided to start a whole series about its development and wasn’t sure what to do with this! But it’s solid and serves a different purpose, so here it is.)

It’s been a while, but I made another PICO-8 game! It’s a little platformer with light puzzling, where you help Star Anise find his best friend Branch Commander Twig. It’s only half an hour long at worst, and it’s even playable on a phone!

This is the one-and-a-halfth entry in the Star Anise Chronicles series, which after several false starts, finally kicked off over Christmas with a… uh… interactive fiction game. Expect the series to continue with even more whiplash-inducing theme shifts.

More technical considerations will go in the “gamedev from scratch” series, but read on for some overall thoughts on the design. Both contain spoilers, of course, so I do urge you to play the game first.

The first attempt at a Star Anise game was two years ago, in early 2018. The idea was to make a Metroidvania where Star Anise had a bunch of guns that shot cat-themed projectiles, obtained a couple other cat-themed powers, and made a total mess of a serious plot happening in the background while he ran around collecting garbage.

After finishing up the Steam release of Cherry Kisses last month, we decided that our next game should be that one, which would now be Star Anise 2 (since i’d already released a Star Anise 1 some months ago). We have, uh, already altered these plans, but that’s the background.

I don’t really know why I started on this game. I guess there’s some element of stress to working on a project with someone, even if that someone is Ash (my spouse), and especially if I’m supposed to be driving it forward. I have to tell someone what to do, and then if I don’t like the result I have to ask them to fix it, and a lot of tiny design questions are out of my control anyway, and all of this is happening on someone else’s schedule, and I have to convey all the project state that’s in my head in a complicated non-verbal form, and… all of those things are a constant low-level source of stress.

So I guess we’d just finished a game that I’d designed, and it was looking like we were about to start a sizable project where I was the design lead again, and I wanted to make something I could finish by myself as an interlude.

And so I sat down with a teeny tiny tool to make a teeny tiny version of what I expected would be our next game.

Design

The basics were obvious: run, jump, land. I gave Star Anise little landing particles early on — they’re in the bigger prototype, I love landing puffs in general, and having them be stars adds so much silly personality.

I knew I wanted to have multiple abilities you collect, since that’s the heart of Metroidventures. I briefly considered giving Star Anise a gun, as in the prototype, but gave up on that pretty early. I would’ve had to sprite a gun, a projectile, a projectile explosion, enemies, enemy attacks, enemy death frames…

Don’t get me wrong; I have no problem with drawing all of that. The concern was that PICO-8 has a very limited amount of space for sprites — in the configuration I was using, 128 sprites of 8×8 pixels each. Star Anise himself takes up 9, even with some clever reuse for his walking animation. The star puff takes 4. The common world tile, plus versions for edges and corners, takes up 9. That’s 22 sprites already, more than 17% of the space I have, for absolutely nothing besides jumping around on solid ground. I would have to keep it simple.

That led me to the first two powers, both borrowed from the prototype:

AOWR starts conversation with NPCs and opens doors. I can’t really take any creative credit here, since these are both things Anise attempts to do with aowrs in real life.
Papping activates levers and knocks over glasses of liquid. Anise only does one of those in real life. (In the prototype, this is a gun — which shoots pawprint-shaped projectiles — but I’d already been thinking about making it a “melee” ability first.)

I adore both of these abilities. I think they both turn some common UI tropes on their heads. NPCs, doors, and levers are all things you usually interact with by pressing some generic “interact” button, but hitting a lever (and meowing at a door) adds some physicality to the action — you’re actually doing something, not just making it go.

And pressing A to talk to an NPC doesn’t really make any sense at all! Consider: almost universally, even in games where the player character speaks, pressing A to start a conversation leads off with the NPC talking. So what the hell did you actually do? What does pressing A represent actually doing that results in someone else casually starting a conversation with you, seemingly unprompted? I have no idea! It’s nonsense! But Anise meows at me all the time and I always respond to him, which is perfectly sensible.

The third power, telepawt, is a little newer. We’d conceived a cat teleporting power pretty recently, but it was more involved and required some big environmental props. I realized pretty quickly that I couldn’t possibly do much of interest on the tiny PICO-8 screen (16 × 16 tiles), but I do like teleporting abilities! I briefly considered ripping off Axiom Verge, but I’ve already done that in fox flux, and the physics are a little involved… and then, lo, inspiration! Combine the two ideas: teleport great distances, but in a controlled and predictable way, by teleporting to the point on the opposite side of the screen. It felt like a very 8-bit kind of power, and I could already imagine a few ways to hide stuff with it, so off I went.

And that seemed like a reasonable progression. A way to talk (and progress through doors), a way to interact with objects, and a way to move around. I decided about halfway through development to make jumping a faux powerup as well; it stretches out the progression a bit more by making you walk past potential jumps and then come back to them later, which is important when I don’t have much map space to work with.

I’d originally planned for items to be separate from abilities, but ran into a couple problems, the worst of which was that I really didn’t have much screen space for sprinkling more items around. I ended up turning items into abilities in their own right, which I think was an improvement overall; now you can crinkle the plastic bag wherever you want, for example.

The game deliberately doesn’t try to explain itself; PICO-8 only has six buttons, and four of them are a d-pad, so I figured button-mashing (as in ye olde NES days) would get everyone through. Still, several players were confused about how to jump (and possibly gave up before even acquiring jump?), and one didn’t realize you could switch abilities, despite the up/down arrowheads on the ability box. Not sure what to learn from this.

The map

I struggled a bit with the map. PICO-8 has a built-in map editor with enough space for 32 screen-sized rooms (arranged in an 8 × 4 grid), which it turns out is not very many. I also very much did not want the game space to be confined to exactly that size of rectangle, so I knew I’d have to do some funky stuff with room connections. (Armed with that power, I ended up making loops and other kinds of non-Euclidean geometry, but hey that’s plenty appropriate for an imaginary moon.)

The bigger problem was designing the rooms outside of the PICO-8 map editor. I tried sketching in Krita, and then on paper, but kept running into the same two problems: it was tedious to rearrange rooms, and I didn’t have a good sense of how much space was available per room.

I found a novel solution: I wrote a Python script to export the map to a PNG, opened it in Aseprite, and edited it there — with each pixel representing a tile and the grid size set to 16. Now I knew exactly how much space I had, and rearranging rooms was easy: double-clicking a cell selects it, and holding Alt while dragging a selection snaps it to the grid. Here’s the beginning part of the game, screenshotted directly from Aseprite at 400% zoom:

When it came time to pack it all back into a rectangle, I copied the whole map, rearranged the rooms, and numbered them all so I could keep track of connections. Surprisingly, it wasn’t that bad a workflow.

The non-Euclidean map connections came in handy for packing secrets in more efficiently; most of the secret stars are off-screen, making them harder to find, but I couldn’t really afford to have a dedicated treasure room for every single one. So I crammed two treasures into the same room a few times, even though the two routes you’d take to get there are generally nowhere near each other.

Doors helped stretch the map out, too. It’s probably obvious if you think about it in the slightest, but doors don’t lead to different rooms; they reuse the same room. But some tiles only appear in the overworld, some tiles only appear in cave world, and actors (besides doors) don’t spawn in caves. That seemingly small difference was enough to make rooms vastly different in the two worlds; the most extreme case is a “crossroads” room, which you traverse vertically in the overworld but horizontally in cave world. (Honestly, I wish I’d done a bit more of this, but it works best in rooms that only have two overworld exits, and there ended up not being too many of those. Also, caves are restricted to basically just platforming, so there’s only so much variety I can squeeze out of them.)

Designing caves was a little trickier than you might think, since the PICO-8 map has no layers! If something needed to occupy a tile in the overworld, then I could not put something in the same place in cave world. Along with the design nightmare that is telepawt, this gave me a couple headaches.

I do like the cave concept a lot, though. I love parallel versions of places in games, and I have an unfinished PICO-8 game that’s centered around that idea taken to extremes. It’s also kind of a nod to my LÖVE games, all the way back to Neon Phase, where going indoors didn’t load another map — rooms were just another layer.

Aesthetics

Originally, PICO-8 had a fixed palette of 16 colors. You could do palette swaps of various sorts, but you can’t actually change any of the colors.

But since I last used it, PICO-8 gained a “secret palette” — an extra 16 colors that you can request. You can’t have more than 16 colors on the screen at a time, but you can replace one of the existing colors with a “secret” color. There’s also an obscure way to tell PICO-8 to preserve the screen palette when the game finishes, which means I could effectively change the palette in the sprite editor. Hooray!

I didn’t want to completely change the palette, so I tried to keep the alterations minor. For the most part, I gave up reds and pinks for a better spread of greens, purples, and yellows. Here’s the core PICO-8 palette, the secret PICO-8 palette, and the game’s palette, respectively:

I think I did a decent job of preserving the overall color aesthetic while softening the harsh contrasts of the original palette, and the cool colors really helped the mood.

Note that I changed the background color (color 0 isn’t drawn when it appears in a sprite) to navy and promoted black to a foreground color, which helped black stand out more when used as an outline or whatever. Probably the best example of this is in the logo, traced from the vector logo I made for the first Star Anise game.

Hmm, what else. The tiles themselves felt almost forced, if that makes sense? Like I could only draw them one way. PICO-8 tiles are a rinky-dink 8 pixels, and boy that is not much to work with. If I had a lot of sprite space, I could make bigger metatiles, but… I don’t, so I couldn’t. I tried a lot of variations of tiles, and what I ended up with were pretty much the only things that worked.

I love how the emoting came out. I knew I didn’t have nearly enough room for facial expressions for everyone, but I wanted to give them some kind of visual way to express mood, and the tiny overlays kinda fell naturally out of that. I think they add a ton of personality, especially in how everyone uses them differently.

I’m pretty happy with the sound design, as well. I’m an extremely amateur composer, and I wrote 90% of the music in a few hours on the start of the last day, but I actually like how it came out and I like going back to listen to it. The sound effects are, with some mild exceptions, pretty much excellent — the aowr is incredible, it has fooled other folks in the house more than once, and I knew I had it right when I had a blast just running around mashing the meow button.

I’m also happy with the dialogue, and hope it conveys the lunekos’ personalities in just these few interactions.

While writing the ending, I had to stop in mid-draft to go cry. Then I cried again when I finished it a few days later. I’ll miss you forever, Branch Commander Twig.

If you did, thanks for playing.

Advent calendar 2019

2019-12-01T19:48:00-08:00

🔗 Advent calendar, with links to individual projects

Happy new year!

For December, I had the absolutely ludicrous idea to do an advent calendar, whereupon I would make and release a thing every day until Christmas.

It didn’t go quite as planned! But some pretty good stuff still came out of it.

Day 1: I started out well enough with the Doom text generator (and accompanying release post), which does something simple that I’ve wanted for a long time but never seen anywhere: generate text using the Doom font. Most of the effort here was just in hunting down the fonts and figuring out how they worked; the rest was gluing them together with the canvas API. It could be improved further, but it’s pretty solid and useful as-is!

Day 2: I tried another thing I’d always wanted: making a crossword! (Solve interactively on squares.io!) I didn’t expect it to take all day, but it did, and even then I found a typo that I didn’t have time to fix, and I had to rush with the clues. All in all, an entertaining but way too difficult first attempt. I’d love to try doing this more, though.

Day 3: I’ve made a couple SVG visualizations before — most notably in my post on Perlin noise — and decided to take another crack at it. The result was a visualization of all six modern trig functions, showing the relationships between them in two different ways. I’m pretty happy with how this turned out, and delighted that I learned some relationships I didn’t know about before, either! I do wish I’d drawn some of the similar triangles to make the relationships more explicit, but I ran out of time — just orienting the text correctly took ages, especially since a lot of it needed different placement in all four quadrants. I vaguely intended to get around to doing a couple more of these, but it didn’t end up happening.

Days 4 and 7: I love the PICO-8‘s built-in tracker, which makes way more sense to me than any “real” tracker, and set out to replicate it for the web. The result is PICOtracker! Unfortunately, this one didn’t get fully finished (yet) — it can play back sounds and music from the hardcoded Under Construction cart, but doesn’t support editing yet. Most of my time went to figuring out the Web Audio API, figuring out what the knobs in the PICO-8 tracker actually do (and shoutout to picolove for acting as source code reference), and figuring out how to weld the two together. I definitely want to revisit this in the near future!

Day 5: I’d been recently streaming Eternal Doom III and was almost done, and I keep being really lazy about putting Doom streams on YouTube, so I finished up the game (which took far, far longer than I expected) and posted the whole thing as a playlist. It spans like 24 hours. Good if you, uh, just want some Doom noise to listen to in the background.

Day 6: I’d expected Eternal Doom to be a quick day so I could have a break, and it was not. So I took an explicit day off.

Days 8 and 13: I made flathack, a web roguelike with only one floor! The idea came from having played NetHack a great many times, and having seen the first floor much more than any other part of the dungeon — so why not make that the whole game? It needs a lot more work, but I’m happy to have finally published a roguelike, and I think it already serves its intended purpose at least a little bit: it’s a cute little timewaster that doesn’t keep killing you.

Days 9–12: I got food poisoning. It sucked. A lot.

Days 14–20: Fresh off of making flathack in only two days, I got a bit too big for my britches and decided to try writing an interactive fiction game. In one day. Spoilers: it took more than one day. But I think the result is pretty charming: Star Anise Chronicles: Escape from the Chamber of Despair, a game about being a cat and causing wanton destruction, and also the first Star Anise Chronicles game to actually be published. A good chunk of the time was spent just drawing illustrations for it, which weren’t strictly necessary, but they add a lot to the game and they did get me back in an art mood.

Day 21: I feel like I’ve been scared of color for a long time, and that’s no good, so I drew and colored something.

Day 22: I drew some weird porn, and colored it too! Porn is just a blast to draw, and it’d been a while. I’ll let you find the link on the calendar if you really want it.

Day 23: Did not exist, due to becoming nocturnal.

Day 24–28: I started a big reference of a bunch of my Flora characters way back in November 2018, but I tried to paint it when I didn’t know what I wanted in a painting style, and eventually I gave up. Flat colors are better for references anyway, so I tried again, and this time I finished! I’m really happy with how it came out — I feel like I’m finally starting to get the hang of art, maybe, just as I hit five years of trying. Again, it’s wildly NSFW, but the link is on the calendar.

All told, I didn’t quite end up with 25 distinct things, but I did make some interesting stuff — some of which I’d been thinking about for a long time — and I’ll call that a success.

I’d love to get flathack to the point that it’s worth playing repeatedly, make more crosswords, and finish PICOtracker — but those will have to wait, since my GAMES MADE QUICK??? FOUR jam is coming up in a few days!

And speaking of which, I need to put a bunch of this stuff on Itch!

Doom text generator

2019-12-01T19:48:00-08:00

🔗 Doom text generator, locally hosted

I’ve been mad my entire life that one of these didn’t seem to exist. ZDoom can print arbitrary text, of course, but only if you fuck around writing and compiling an ACS script or whatever! There’s no console command for it! Outrageous!!!

So I finally made this. It took like ten hours, which I have to say, is fucking incredible.

I don’t want to make a whole blog post out of this (I mean it was only ten hours) but a few points of interest:

Probably most of the work was in getting stuff out of Doom and into a usable format. The end result is a thorny combination of three different file format parsers (half of which I threw away), manual extraction from game files via SLADE, both PyPNG and ImageMagick for some reason, and way too much JSON.
Did you know that the small Doom font’s | (pipe) character is inexplicably assigned to lowercase y? Neither did I! It’s the only lowercase letter in the font — it only supports uppercase.
I fucking love CSS grid.
The colors are done using ZDoom’s font color translation. I always thought those were palette remappings — which is what “translation” means elsewhere in ZDoom — but no! They actually use the perceptual brightness of the font, stretched to the full range, and then mapped to a color gradient. It’s not at all what I expected (which led me to some dead ends early on), but it’s kind of cool.
Implementing undocumented RLE is fun because if you’re off by even a byte somewhere you suddenly have either ten times more or ten times less data than you expected and it’s all complete garbage.
I haven’t put the source code up yet but will eventually. I want to put it on itch, too, but I have to put together a whole page and stuff and I’m very tired now.

Anyway now you can make your own cool in-game textures and other shenanigans, enjoy!

Particle wipe generator

2019-04-20T09:08:00-07:00

🔗 Particle wipe generator on itch or hosted locally
🔗 Source code

This is a tool for making particle wipes, a type of transition whose name I made up because I don’t think they have a well-known name! They can be used in Ren’Py, RPG Maker, or anything that lets you write a shader.

Most of my games have done screen transitions with simple fades, and I wanted to try something different here, but I couldn’t find a tool to make the effect I wanted. So I wrote my own. If you’re interested, here’s how it works:

The idea

I was inspired by two things. One is Cave Story’s transitions.

That looks rad, right? I think it does, anyway. I wanted to do something similar myself.

At a glance, this effect looks pretty simple. The screen is sliced into a grid. A diamond shape starts expanding from the center of each cell until the cell is filled. By staggering when each cell starts, you can make an animation that seems to wipe from the bottom upwards, or from the edges inwards, or who knows what else.

Here’s a frame from the above capture, showing the grid. You can see from the blocks near the middle that it’s the same as the tile grid.

Notice that Cave Story transitions either from a scene to a solid color, or vice versa. Offhand, I don’t think the game ever transitions directly between two scenes.

My guess is that it’s manually drawing solid color on top of the tilemap until the entire screen is obscured, switching maps in the background, then reversing the progress. The various sizes of diamond might even be physical sprites on a foreground layer!

That poses a slight problem for me, because I want to be able to transition directly between scenes as well. Enter inspiration number two: Ren’Py.

Ren’Py is a visual novel engine, and it supports a ton of screen transitions. That makes sense, since visual novels generally don’t have much animated art, so most of the animation happens in transitions and sprite effects.

One such transition is a generic one called ImageDissolve, which can do a mask transition (another term I made up). It takes a grayscale mask, which tells it the order to reveal pixels. Where the mask is black, the corresponding pixels of the “after” scene are shown almost immediately; where the mask is white, those “after” pixels are the last to appear.

(I suddenly realize that Ren’Py does that backwards, with white pixels being first, but that doesn’t make sense to be since black pixels are zero.)

That’s a bit of a mouthful to describe with text, so here’s a basic example. A linear gradient from black to white will play out as a straight wipe in the same direction.

This approach can capture any kind of transition where pixels are revealed in a given order, and if I implement it with a shader (which is very easy), I can emulate the Cave Story style without being limited to a solid color! Neat!

The problem

The problem is… how do I generate the mask image? I searched around a bit and found folks who’d made transitions for use with Ren’Py, but no explanation of how they did it.

Let me think about emulating Cave Story’s effect using the mask approach, one step at a time.

Forget about the wipe effect for now and concentrate on a single cell. When the diamond is just starting to appear, it should be black. When it completely fills the cell — i.e., when it’s big enough that its edges just barely touch the cell corners — it should be white. In the middle somewhere, it should be medium gray. Imagining (or drawing) a few cases suggests a simple diamond gradient, which seems correct.

Now for the wipe effect. All it really does is stagger when the animation starts. The upwards wipe, for example, starts animating all the cells on the bottom row, waits some short amount of time, then starts animating all the cells on the next row up, and so on. An ASCII diagram of this process (for a simplified, smaller screen) might look like:

   00 |                     XXXXXXXX
   01 |                  XXXXXXXX
R  02 |               XXXXXXXX
o  03 |            XXXXXXXX
w  04 |         XXXXXXXX
   05 |      XXXXXXXX
   06 |   XXXXXXXX
   07 |XXXXXXXX
      +-----------------------------
                  Time

My example cell above spans the full range from black to white, but if I want to stagger the cells like this, I need to squash that into a smaller range. What range, though? To get that scaling right, I need to know the total time the entire animation takes.

That’s kind of a weird question, because nothing I’m working with actually measures time! I only have numbers from 0 to 1; the amount of time is really a matter of how fast you play back the animation.

So let me approach this the other way around. The total “time” is 1, the full range of values I’m working with. My example has 8 rows. Each row starts playing after the row beneath it is ⅜ of the way through its animation; call this fraction the “delay”. There are 7 such delays, one fewer than the number of rows, because the first row doesn’t have a delay.

If the length of a single cell’s animation is $t$ (which is actually a fraction of the length of the whole animation), then the last row starts after a total delay of $t \times (8 - 1) \times \frac38$. Its own length is $t$, and that should bring us to the end of the animation, so:

$$ \begin{align*} 1 &= t \times (8 - 1) \times \frac38 + t \\ &= t \times (7 \times \frac38 + 1) \\ &= t \times \frac{29}{8} \\ \Rightarrow t &= \frac{8}{29} \approx 0.276 \\ \end{align*} $$

And indeed, if you count characters in the diagram, each bar is 8 long out of a total width of 29. Neat! All I have to do is make the bottom cells range from 0 to 0.276, the next row up range from 0.103 to 0.379 (the same size range, but moved up by $\frac{8}{29} \times \frac38 = \frac{3}{29}$), and so on.

Easy. Blog post done.

Except…

I wanted to use hearts. And hearts create two new issues.

The first is that I don’t know how big a heart would have to grow to cover the entire cell. For diamonds, that was easy: they’re symmetrical in the same way as squares, so it’s obvious that they just need to be big enough to touch the corners. But how big does a heart have to be to fit a square entirely inside it? Do I gauge it by hand in an image editor, or what?

The real problem there is that a heart is, presumably, a bitmap rather than a simple shape with properties I can examine mathematically. And even if it were a shape, the math would get pretty ugly pretty quickly.

But the second problem is worse. Hearts aren’t vertically symmetrical, which means a neighboring heart might poke into a cell and start covering pixels that the native heart hasn’t covered yet.

This complicates things considerably. If I took the naïve approach of gluing together a bunch of independent cells, then the top of each heart would reach the top of its cell and flatten out into a hard border! Sounds ugly, especially since the grid isn’t really supposed to be visible in the animation. (Technically this could happen with diamonds too, if the delay were high enough, but their symmetry makes it much harder to notice.)

Now, I could fudge my way through both of these problems with sufficient abuse of an imaging library. Draw a very tiny black heart, then draw a slightly bigger almost-black heart, and keep expanding until every pixel has a color, then either scale the colors or go back and do it again knowing the correct range.

But that’s not a very satisfying solution, and it’s not very precise — which is important when I only have 256 values to work with. I can do better!

Doing better

The approach I used for diamonds above is fairly promising. It’s most of the way to a blueprint for figuring out exactly what shade each pixel of the mask should be, independently of any other pixel. The position within a cell tells me how far along in the cell’s animation the pixel is (center black, corners white, everything else somewhere in the middle), and the delay tells me how to scale that to fit correctly in the full animation.

Those seem like reasonable steps. All I have to do is fix them to work with an arbitrary “particle” shape. Somehow.

Step 1: the stamp

Forgetting about the overall animation worked before, so I’ll do it again and concentrate on a single prototype cell. That cell will be repeated (with some adjustment) all over the final mask, so I call it a stamp.

I already know in advance that a single cell doesn’t need to scale from 0 to 1, since I’ll be adjusting it later anyway, so that frees me up to use any arbitrary quantity — as long as it’s scaled by some consistent factor I can eliminate later. A little thinking suggests that what I really want to know is: given a pixel $(x, y)$ within a cell, how big does the heart particle have to grow to hit that pixel? I can express that as a fraction of the particle’s original size (since it should grow proportionally), and then worry about scaling it down later.

The first thing I want to do is change my coordinate system. Consider: for a 10×10 cell, the center is at the point (5, 5), which neighbors pixels (4, 4) and (5, 5). But that would mean the heart would touch the pixel at (5, 5) immediately, whereas it would need to cross a whole pixel to reach (4, 4), even though both pixels touch the center!

Pixel coordinates refer to the top left corners of the pixels, indicated in red above. The center is a point, not a pixel, and it’s clearly much closer to one pixel coordinate than the other. The fix is to use the centers of pixels, indicated in blue, which are the same distance from where the heart starts. Phew!

(If you don’t do this, you’ll get a very noticeable diagonal gash where the particle touched lower-right pixels earlier than upper-left ones. Guess how I found that out!)

While I’m at it, pixel coordinates are relative to the upper-left corner of the cell, but the most interesting point here is the center. So let’s make them relative to that, too. That means (4, 4) and (5, 5) should really be (-½, -½) and (½, ½), or more generally: given a center at $(c_x, c_y)$, the point I’m actually interested in is $(x + \frac{1}{2} - c_x, y + \frac{1}{2} - c_y)$. Call this, I dunno, $(d_x, d_y)$.

Back to the actual problem, which is: how big does the particle need to grow to hit this point?

Like I said before, I could try scaling the particle up bit by bit (maybe binary search?) until it touches the point, but that still feels goofy and imprecise.

You know, it sucks that the particle is a two-dimensional shape. It would be swell if I could eliminate a dimension here, or something.

And here I borrow a couple techniques from collision detection. Scaling the particle up is equivalent to scaling the entire cell down. If I scaled the cell down towards the origin, the point would trace a straight line.

This is very helpful. It means I can solve this problem with a raycast: fire a straight ray into the particle, towards its center, and check each pixel it hits until I find an opaque one. That’ll give me a perfect answer!

But where does the ray start? I have a point in the grid, but not a point on the particle. So the first question is: if the particle scaled up just enough that the edge of the particle image touched the point, where on the particle would that contact be?

Call the particle dimensions $p_w$ by $p_h$. (My heart is contained within a square, but that isn’t strictly necessary.) In order to reach x-coordinate $d_x$, the particle would have to be twice as wide as the distance from the y-axis to that point — because it’s centered! — which is $\left|2 d_x\right|$ pixels wide. Its scale, relative to its original size, would thus be $\frac{\left|2 d_x\right|}{p_w}$. The scale for touching the y-coordinate would be computed the same way. To actually touch the point, the particle has to reach whichever coordinate is further away, so its scale must be:

$$ s = \max\left(\frac{\left|2 d_x\right|}{p_w}, \frac{\left|2 d_y\right|}{p_h}\right) $$

A special case crops up here: for a cell with an odd width and height, the center pixel is exactly aligned with the origin, and the scale computes to zero. I’m doing some division in a moment, so that’s very bad — but the center pixel is effectively touched immediately, so I can say the final answer for this pixel is 0 and skip the rest of this anyway.

Now for the fun part! When the expanding particle hits the point of interest, it makes contact at some point on the original particle image. If the necessary scale is $s$, the contact point is the center of the particle, offset by $\left(\frac{d_x}{s}, \frac{d_y}{s}\right)$.

And now I raycast from that point to the center of the particle and check every pixel that ray crosses, using a modified Bresenham’s algorithm — originally intended for drawing pixel-perfect lines, but perfectly suited for casting a ray through a grid as well. (Conveniently, I’d already implemented this sort of raycast for collision detection for this very same game! Then I ended up not using it, hm.)

When I find an opaque-ish pixel (alpha of 0.5 or greater), I compute its distance from the center, divide by the distance from the contact point to the center — that tells me how much bigger the particle has to grow for the opaque-ish pixel I found to actually touch the point.

Multiply that ratio by the $s$ I found earlier, and the result is exactly what I was looking for: the scale of the particle when it touches the point!

Now, raycasting for every pixel in the stamp — a thousand times even for a dinky cell size of 32×32 — is not exactly speedy. But it’s not unbearably slow, either. And this is something that’s generated once and played back a bunch of times, so why not spend a little CPU time upfront making it as high-quality as I can manage?

Anyway, that’s the hard part done! Now I can put the mask together.

Phase 2: the mask

With the stamp generated, I also know how big the particle has to grow for the entire cell to be covered: it’s just the highest scale in the stamp. For a simple full-screen effect, all I’d have to do at this point is scale the stamp values into the range [0, 1] and copy them to every cell in the grid.

But that’s boring; I wanted a wipe, which requires a couple more twiddles.

The wipe is essentially a second animation that controls when each cell’s individual animation starts. Above I considered a row-by-row wipe; for Cherry Kisses I ended up with a column-by-column wipe; Cave Story also has an “inwards” wipe. All of these can be generalized as numbered steps in a grid:

By row      By column   Inwards
77777777    76543210    01233210
66666666    76543210    12344321
55555555    76543210    23455432
44444444    76543210    34566543
33333333    76543210    34566543
22222222    76543210    23455432
11111111    76543210    12344321
00000000    76543210    01233210

The math is basically already done; I did it above. Given the number of steps $n$ and the delay $d$ (a fraction of the cell animation time), I can find the length of a cell animation $t$ as follows:

$$ \begin{align*} 1 &= t \times (n - 1) \times d + t \\ &= t \times ((n - 1) \times d + 1) \\ \Rightarrow t &= \frac{1}{n d - d + 1} \end{align*} $$

The process for generating the whole mask is thus:

Iterate over each pixel of the mask.
Figure out what cell it’s in, and the step for that cell.
Find the corresponding value in the stamp, scale it to the size of a cell animation, and add in the delay.
Write that to the mask.

Once every pixel is done, the mask is complete!

Except… this didn’t handle the overlap issue. No problem, though; that’s surprisingly simple to fix.

First, expand the stamp to the size of a 3×3 block of cells. The maximum scale for a stamp should only be taken from the central cell; the others are for the following process.

Then, when reading a pixel’s stamp in step 3 above, read it from the central cell — and also from the neighboring cells. In those neighbors, I read from the stamp cell on the opposite side, in order to know how long it would take for the heart to grow out of that cell and into this one.

(Diagonal neighbors aren’t shown here, but you get the idea.)

Since different cells may have different start times, I may need to add/subtract some extra delay from the neighbors’ values. Then I take the smallest of all these samples to figure out the earliest time that any heart — either in this cell, or one of its neighbors — hits the pixel.

And hey, presto, we’re done! Here’s a (somewhat laggy) recording I took of the very first time I got this working for Cherry Kisses:

It ended up a little nicer-looking than that, of course. (Feel free to play the game to see it in action?) And if you’re curious, here’s the mask from the final game:

Caveats

There’s one teeny tiny problem still lingering in this approach. I assume that the whole animation ends when the last cell animation ends, but because of cell overlap, it might actually end earlier. And indeed, when I went back to check the Cherry Kisses mask, I found that it ends early — the brightest color in it is #e2e2e2. Oops. So much for that ludicrous accuracy!

That’s still fixable by taking overlap into account when finding the maximum value in the stamp, but I haven’t done it yet, and it’s a bit more complicated if the grid pattern has adjacent cells that are more than 1 step apart. (Those cases can also lead to particles mashing against the cell edge too early, which could be fixed by using a 5×5 or larger stamp…)

That's it

Yep. The particle generator is just this logic with some knobs bolted on. It has a couple extra features, like a “halo” that highlights the transition point, and using all three color channels for extra precision, but it’s all built on the same basic idea.

There’s a lot of room for experimentation and variety here, and I’ve probably only scratched the surface. This is only a tiny subset of what can be done with a transition mask, too — it needn’t rely on a grid at all! See what you can come up with.

Oh, and here’s the exact shader I used in Cherry Kisses. It’s for LÖVE, so it has a couple non-standard #defines and globals, but you get the idea. The “ramp” is just a tolerance that adds a soft edge around the transition.

extern Image mask;
extern float t;
extern float ramp;

vec4 effect(vec4 color, Image texture, vec2 tex_coords, vec2 screen_coords) {
    vec4 pixel = Texel(texture, tex_coords) * color;
    float discriminator = Texel(mask, screen_coords / love_ScreenSize.xy).r;
    float alpha = clamp((t - discriminator) / ramp + 0.5, 0.0, 1.0);
    pixel.a *= alpha;
    return pixel;
}

Happy transitioning!

Alice’s Day Off demo

2018-03-02T16:00:00-08:00

🔗 Alice’s Day Off demo on itch

🚨🔞 HEADS UP: This game is super duper NSFW. It contains explicit cartoon porn. You have been warned! 🔞🚨

This is the game glip and I (and a co-writer) made for my horny game jam, Strawberry Jam 2. It’s a goofy visual novel about, well… sex, mostly. A few folks with no interest in the subject matter have played it and still enjoyed it, which seems like a great sign.

(Oh, right, and the jam is over, and has 63 entries! Like last year, they run the gamut from “highly abstract and thoughtful” to “let’s put porn in a game”.)

Some lingering thoughts about the process itself:

Visual novels combine narrative prose with the interaction of games, but the two forces are somewhat at odds: the more interaction you add, the more prose you have to write, with the worst case being a combinatoric explosion (which won’t even be appreciated by players who run through only once). And there’s a subtle tension between the design of those decisions and replay value, which… I maybe ought to go on about some other time.

Anyway, this is all really a distilled form of the problem of offering narrative choice in games in general, which I find fascinating, so I really wanted to play around with it. I have a few ideas for experimenting with what player choice even looks like in a visual novel, and we have thoughts about narrative variety at all levels so there’s something to appreciate no matter how much or little you replay the game.

Alas! We had to drastically cut down what we wanted to do due to time constraints, hence calling this a “demo”; it’s a sample of ten (mostly linear) routes. It’s good stuff, I’m happy with how it came out, and there’s a pretty decent chunk of it — I think a straight read in one sitting takes about an hour — but I naturally compare it to everything I know isn’t there.

This was my first time using Ren’Py, and it defied my assumptions so utterly that I have to go write a separate post about it now. I think it came out pretty well, considering I’d never touched the engine before three weeks ago.

The touch I like the most is the custom title screen, seen above. I think it’s fairly important to hide obvious traces of the engine you’re using, when feasible; otherwise the end result is covered in someone else’s (generic) fingerprints, not yours. So we added a splash, added a title screen, and completely changed the in-game interface. (The in-game menu is basically the same, but it’s general-purpose enough that I’m not sure it’s really worth changing. Maybe?)

Part of the point of this exercise was to force me to actually sit down and write a story, an activity I often attempt to do and then awkwardly shy away from. It feels like pushing against a river of molasses: it takes me so long just to get started at all, and if I stumble even slightly, I lose my momentum completely and have to start all over. It’s my ADD final boss.

Suffice to say, I spent a good chunk of the month mostly not-writing, which was frustrating and didn’t get us very far. It wasn’t until the final week that I felt like I really hit my stride and started churning out big chunks of prose at a time. I don’t have any inspirational tale about how this happened; I just kept trying to do it and failing to do it until I finally did it. Hopefully it’ll be easier to get into from now on!

I did half the writing, and it’s endlessly hilarious to me that my co-writer and I both looked at each other’s prose and came away thinking “damn, I need to do it more like that!” Probably a good sign.

That’s all I’ve got; back to work!

Strawberry Jam 2 🍓

2018-01-24T00:30:00-08:00

🔗 Strawberry Jam 2 on itch

I’m running a game jam, and this announcement is before the jam starts! What a concept!

The idea is simple: you have all of February to make a horny game.

(This jam is, as you may have guessed, NSFW. 🔞)

I think there’s a lot of interesting potential at the intersection of sex and games, but we see very little exploration of it — in large part because mega-platforms like Steam (and its predecessor, Walmart) have historically been really squeamish about anything sexual. Unless it’s scantily-clad women draped over everything, that’s fine. But un-clad women are right out. Also gratuitous high-definition gore is cool. But no nipples!!

The result is a paltry cultural volume of games about sex, but as boundaries continue to be pushed without really being broken, we get more and more blockbuster games with sex awkwardly tacked on top as lazy titillation. “Ah, it’s a story-driven role-playing shooter, but in this one part you can have sex, which will affect nothing and never come up again, but you can see a butt!” Truly revolutionary.

The opposite end of the spectrum also exists, in the form of porn games where the game part is tacked on to make something interactive — you know, click really fast to make clothes fall off or whatever. It’s not especially engaging, but it’s more compelling than staring at a JPEG.

So my secret motive here is to encourage people to explore the vast gulf in the middle — to make games that are interesting as games and that feature sexuality as a fundamental part of the game. Something where both parts could stand alone, yet are so intertwined as to be inseparable.

The one genre that is seeing a lot of experimentation is the raunchy visual novel, which is a great example: they tend to tell stories where sexuality plays a heavy part, but they’re still compelling interactive stories and hold up on those grounds just as well. What, I wonder, would this same sort of harmony look like for other genres, other kinds of interaction? What does a horny racing game look like, or a horny inventory-horror game, or a horny brawler? Hell, why are there no horny co-op games to speak of? That seems obvious, right?

I haven’t said all this on the jam page because it would add half a dozen paragraphs to what is already a lengthy document. I also suspect that I’ll sound like I’m suggesting “a racing game but all the cars are dicks,” which isn’t quite right, and I’d need to blather even more to clarify. Anyway, it seems vaguely improper as the jam organizer to be telling people what kind of games not to make; last year I just tried to lead by example by making fox flux.

If exploring this design space seems interesting to you, please do join in! If you’ve never made a game before, this might be a great opportunity to give it a try — everything is going to be embarrassing and personal regardless. Maybe hop on Discord if you need help or want a teammate. Feel free to flip through last year’s entries, too, or my (super nsfw) thread where I played some and talked about them. Some of them are even open source, cough, cough.

Previously:

Strawberry Jam (2017)

GDQ schedule dimmer

2018-01-23T23:35:00-08:00

🔗 Source code on GitHub
🔗 Install, maybe

Does this ever happen to you?

[TODO: insert black and white gif of someone struggling to read the GDQ schedule because it’s a single long table and it’s hard to even keep track of what day you’re looking at, let alone find out what’s going on right now]

Well, no more! Thanks to the power of IavaScript, now it’s like the picture above, which I guess gave it away huh.

Not very useful now, since I forgot to even post about it here before AGDQ ended, but presumably useful in SGDQ since they never seem to change this page at all.

Wait! Before you click on the “install” link above. Firefox users will need Greasemonkey. Chrome used to support user scripts natively, and legends say it still does, but there are so many walls around extensions now that I couldn’t figure out how to make it work, so just get Tampermonkey, which is also available for most other browsers.

GAMES MADE QUICK??? 2.0

2018-01-23T23:25:00-08:00

🔗 GAMES MADE QUICK??? 2.0 on itch

I realize, with all the cognitive speed and grace of a cat falling out of a chair, that I have my own website where I can announce things that I am doing.

Here is a thing that I am having done: it’s GAMES MADE QUICK??? 2.0, a game jam that runs concurrently with Games Done Quick. The inspiration was that I once spent the entire week of AGDQ doing nothing but watching the stream, which completely ruined my momentum and cost me the following week as well while I struggled to get back up to speed. What a catastrophe!

So my solution was to spend the week making a game instead, which prompted someone to suggest that I make a jam out of it, and so I did. The results were NEON PHASE and also the original GAMES MADE QUICK???.

It’s a bit late to join now, but look forward to the jam during SGDQ, which runs the last week of June! In the meantime, perhaps peruse the fruits of this season’s labor, or at least glance over my thoughts on some of them.

Previously:

GAMES MADE QUICK??? 1½ (SGDQ 2017)
GAMES MADE QUICK??? (AGDQ 2017)

Roguelike Simulator

2017-12-09T22:59:00-08:00

On a recent game night, glip and I stumbled upon bitsy — a tiny game maker for “games where you can walk around and talk to people and be somewhere.” It’s enough of a genre to have become a top tag on itch, so we flicked through a couple games.

What we found were tiny windows into numerous little worlds, ill-defined yet crisply rendered in chunky two-colored pixels. Indeed, all you can do is walk around and talk to people and be somewhere, but the somewheres are strangely captivating. My favorite was the last days of our castle, with a day on the town in a close second (though it cheated and extended the engine a bit), but there are several hundred of these tiny windows available. Just single, short, minimal, interactive glimpses of an idea.

I’ve been wanting to do more of that, so I gave it a shot today. The result is Roguelike Simulator, a game that condenses the NetHack experience into about ninety seconds.

Constraints breed creativity, and bitsy is practically made of constraints — the only place you can even make any decisions at all is within dialogue trees. There are only three ways to alter the world: the player can step on an ending tile to end the game, step on an exit tile to instantly teleport to a tile on another map (or not), or pick up an item. That’s it. You can’t even implement keys; the best you can do is make an annoying maze of identical rooms, then have an NPC tell you the solution.

In retrospect, a roguelike — a genre practically defined by its randomness — may have been a poor choice.

I had a lot of fun faking it, though, and it worked well enough to fool at least one person for a few minutes! Some choice hacks follow. Probably play the game a couple times before reading them?

Each floor reveals itself, of course, by teleporting you between maps with different chunks of the floor visible. I originally intended for this to be much more elaborate, but it turns out to be a huge pain to juggle multiple copies of the same floor layout.
Endings can’t be changed or randomized; even the text is static. I still managed to implement multiple variants on the “ascend” ending! See if you can guess how. (It’s not that hard.)
There are no Boolean operators, but there are arithmetic operators, so in one place I check whether you have both of two items by multiplying together how many of each you have.
Monsters you “defeat” are actually just items you pick up. They’re both drawn in the same color, and you can’t see your inventory, so you can’t tell the difference.

Probably the best part was writing the text, which is all completely ridiculous. I really enjoy writing a lot of quips — which I guess is why I like Twitter — and I’m happy to see they’ve made people laugh!

I think this has been a success! It’s definitely made me more confident about making smaller things — and about taking the first idea I have and just running with it. I’m going to keep an eye out for other micro game engines to play with, too.

Eevee mugshot set for Doom

2017-11-23T01:46:00-08:00

A full replacement of Doomguy’s vast array of 42 expressions.

You can get it yourself if you want to play Doom as me, for some reason? It does nothing but replace a few sprites, so it works with any Doom flavor (including vanilla) on 1, 2, or Final. Just run Doom with -file eeveemug.wad. With GZDoom, you can load it automatically.

I don’t entirely know why I did this. I drew the first one on a whim, then realized there was nothing really stopping me from making a full set, so I spent a day doing that.

The funny thing is that I usually play Doom with ZDoom’s “alternate” HUD. It’s a full-screen overlay rather than a huge bar, and — crucially — it does not show the mugshot. It can’t even be configured to show the mugshot. As far as I’m aware, it can’t even be modded to show the mugshot. So I have to play with the OG status bar if I want to actually use the thing I made.

I’m pretty happy with the results overall! I think I did a decent job emulating the Doom “surreal grit” style. I did the shading with Aseprite‘s shading mode — instead of laying down a solid color, it shifts pixels along a ramp of colors you select every time you draw over them. Doom’s palette has a lot of browns, so I made a ramp out of all of them and kept going over furry areas, nudging pixels into being lighter or darker, until I liked the texture. It was a lot like making a texture in a sketch with a lot of scratchy pencil strokes.

I also gleaned some interesting things about smoothness and how the eye interprets contours? I tried to explain this on Twitter and had a hell of a time putting it into words, but the short version is that it’s amazing to see the difference a single misplaced pixel can make, especially as you slide that pixel between dark and light.

Speaking of which, Doom’s palette is incredibly weird to work with. Thank goodness Eevees are brown! The game does have to draw arbitrary levels of darkness all with the same palette, which partly explains the number of dark colors and gradients — but I believe a number of the colors are exact duplicates, so close they might as well be duplicates, or completely unused in stock Doom assets. I guess they had no reason to optimize for people trying to add arbitrary art to the game 25 years later, though. (And nowadays, GZDoom includes a truecolor software renderer, so the palette is becoming less and less important.)

I originally wanted the god mode sprite to be a Sylveon, but Sylveon is made of pink and azure and blurple, and I don’t think I could’ve pulled it off with this set of colors. I even struggled with the color of the mane a bit — I usually color it with pretty pale colors, but Doom only has a couple of those, and they’re very saturated. I ended up using a lot more dark yellows than I would normally, and thankfully it worked out pretty well.

The most significant change I made between the original sprite and the final set was the eye color:

(This is STFST20, a frame from the default three-frame “glacing around” animation that plays when the player has between 40 and 59 health. Doom Wiki has a whole article on the mugshot if you’re interested.)

The blue eyes in my original just do not work at all. The Doom palette doesn’t have a lot of subtle colors, and its blues in particular are incredibly bad. In the end, I made the eyes basically black, though with a couple pixels of very dark blue in them.

After I decided to make the full set, I started by making a neutral and completely healthy front pose, then derived the others from that (with a very complicated system of layers). You can see some of the side effects of that here: the face doesn’t actually turn when glancing around, because hoo boy that would’ve been a lot of work, and so the cheek fluff is visible on both sides.

I also notice that there are two columns of identical pixels in each eye! I fixed that in the glance to the right, but must’ve forgotten about it here. Oh, well; I didn’t even notice until I zoomed in just now.

The original sprites might not be quite aligned correctly in the above image. The available space in the status bar is 35×31, of which a couple pixels go to an inset border, leaving 33×30. I drew all of my sprites at that size, but the originals are all cropped and have varying offsets (part of the Doom sprite format). I extremely can’t be assed to check all of those offsets for over a dozen sprites, so I just told ImageMagick to center them. (I only notice right now that some of the original sprites are even a full 31 pixels tall and draw over the top border that I was so careful to stay out of!)

Anyway, this is a representative sample of the Doom mugshot poses.

The top row shows all eight frames at full health. The first three are the “idle” state, drawn when nothing else is going on; the sprite usually faces forwards, but glances around every so often at random. The forward-facing sprite is the one I finalized first.

I tried to take a lot of cues from the original sprite, seeing as I wanted to match the style. I’d never tried drawing a sprite with a large palette and a small resolution before, and the first thing that struck me was Doomguy’s lips — the upper lip, lips themselves, and shadow under the lower lip are all created with only one row of pixels each. I thought that was amazing. Now I even kinda wish I’d exaggerated that effect a bit more, but I was wary of going too dark when there’s a shadow only a couple pixels away. I suppose Doomguy has the advantage of having, ah, a chin.

I did much the same for the eyebrows, which was especially necessary because Doomguy has more of a forehead than my Eevee does. I probably could’ve exaggerated those a bit more, as well! Still, I love how they came out — especially in the simple looking-around frames, where even a two-pixel eyebrow raise is almost comically smug.

The fourth frame is a wild-ass grin (even named STFEVL0), which shows for a short time after picking up a new weapon. Come to think of it, that’s a pretty rare occurrence when playing straight through one of the Doom games; you keep your weapons between levels.

The fifth through seventh are also a set. If the player takes damage, the status bar will briefly show one of these frames to indicate where the damage is coming from. You may notice that where Doomguy bravely faces the source of the pain, I drew myself wincing and recoiling away from it.

The middle frame of that set also appears while the player is firing continuously (regardless of damage), so I couldn’t really make it match the left and right ones. I like the result anyway. It was also great fun figuring out the expressions with the mouth — that’s another place where individual pixels make a huge difference.

Finally, the eighth column is the legendary “ouch” face, which appears when the player takes more than 20 damage at once. It may look completely alien to you, because vanilla Doom has a bug that only shows this face when the player gains 20 or more health while taking damage. This is vanishingly rare (though possible!), so the frame virtually never appears in vanilla Doom. Lots of source ports have fixed this bug, making the ouch face it a bit better known, but I usually play without the mugshot visible so it still looks super weird to me. I think my own spin on it is a bit less, ah, body horror?

The second row shows deterioration. It is pretty weird drawing yourself getting beaten up.

A lot of Doomguy’s deterioration is in the form of blood dripping from under his hair, which I didn’t think would translate terribly well to a character without hair. Instead, I went a little cartoony with it, adding bandages here and there. I had a little bit of a hard time with the bloodshot eyes at this resolution, which I realize as I type it is a very poor excuse when I had eyes three times bigger than Doomguy’s. I do love the drooping ears, with the possible exception of the fifth state, which I’m not sure is how that would actually look…? Oh well. I also like the bow becoming gradually unravelled, eventually falling off entirely when you die.

Oh, yes, the sixth frame there (before the gap) is actually for a dead player. Doomguy’s bleeding becomes markedly more extreme here, but again that didn’t really work for me, so I went a little sillier with it. A little. It’s still pretty weird drawing yourself dead.

That leaves only god mode, which is incredible. I love that glow. I love the faux whisker shapes it makes. I love how it fades into the background. I love that 100% pure “oh this is pretty good” smile. It all makes me want to just play Doom in god mode forever.

Now that I’ve looked closely at these sprites again, I spy a good half dozen little inconsistencies and nitpicks, which I’m going to refrain from spelling out. I did do this in only a day, and I think it came out pretty dang well considering.

Maybe I’ll try something else like this in the future. Not quite sure what, though; there aren’t many small and self-contained sets of sprites like this in Doom. Monsters are several times bigger and have a zillion different angles. Maybe some pickups, which only have one frame?

Hmm. Parting thought: I’m not quite sure where I should host this sort of one-off thing. It arguably belongs on Itch, but seems really out of place alongside entire released games. It also arguably belongs on the idgames archive, but I’m hesitant to put it there because it’s such an obscure thing of little interest to a general audience. At the moment it’s just a file I’ve uploaded to wherever on my own space, but I now have three little Doom experiments with no real permanent home.

NEON PHASE

2017-01-21T20:02:00-08:00

It all started after last year’s AGDQ, when I lamented having spent the entire week just watching speedruns instead of doing anything, and thus having lost my rhythm for days afterwards.

This year, several friends reminded me of this simultaneously, so I begrudgingly went looking for something to focus on during AGDQ. I’d already been working on Isaac’s Descent HD, so why not keep it up? Work on a video game while watching video games.

Working on a game for a week sounded an awful lot like a game jam, so I jokingly tweeted about a game jam whose express purpose was to not completely waste the week staring at a Twitch stream. Then someone suggested I make it an actual jam on itch.io. Then Mel asked to do a game with me.

And so, thanks to an almost comical sequence of events, we made NEON PHASE — a half-hour explorey platformer.

The game

The game is set in the Flora universe, as is everything Mel gets their hands on. (I say this with all the love in the world. ♥ Anyway, my games are also set in the Flora universe, so who am I to talk.)

I started out by literally copy-pasting the source code for Isaac’s Descent HD, the game I’ve been making with LÖVE as an extension of an earlier PICO-8 game I made. It’s not terribly far yet, but it’s almost to the point of replicating the original game, which meant I had a passable platformer engine that could load Tiled maps and had some notion of an “actor”. We both like platformers, anyway, so a platformer it would be.

We probably didn’t make the best use of the week. I think it took us a couple days to figure out how to collaborate, now that we didn’t have the PICO-8’s limitations and tools influencing our direction. Isaac is tile-based, so I’d taken for granted that this game would also be tile-based, whereas Mel, being an illustrator, prefers to draw… illustrations. I, an idiot, decided the best way to handle this would be to start cutting the illustrations into tiles and then piecing them back together. It took several days before I realized that oh, hey, Mel could just draw the entire map as a single image, and I could make the player run around on that.

So I did that. Previously, collision had been associated only with tiles, but it wasn’t too hard to just draw polygons right on the map and use those for collision. (Bless Tiled, by the way. It has some frustrating rough edges due to being a very general-purpose editor, but I can’t imagine how much time it would take me to write my own map editor that can do as much.)

And speaking of collision, while I did have to dig into a few thorny bugs, I’m thrilled with how well the physics came out! The collision detection I’d written for Isaac’s Descent HD was designed to support arbitrary polygons, even though so far I’ve only had square tiles. I knew the whole time I was making my life a lot harder, but I really didn’t want to restrict myself to rectangles right out of the gate. It paid off in NEON PHASE — the world is full of sloping, hilly terrain, and you can run across it fairly naturally!

I’d also thought at first that the game would be a kind of actiony platformer, which is why the very first thing you get greatly resembles a weapon, but you don’t end up actually fighting anything. It turns out enemy behavior takes a bit of careful design and effort, and I ended up busy enough just implementing Mel’s story. Also, dropping fighting meant I didn’t have to worry about death, which meant I didn’t have to worry about saving and loading map state, which was great news because I still haven’t done any of that yet.

It’s kind of interesting how time constraints can influence game design. The game has little buildings you can enter, but because I didn’t have saving/loading implemented, I didn’t want to actually switch maps. Instead, I made the insides of buildings a separate layer in Tiled. And since I had both layers on hand, I just drew the indoor layer right on top of the outdoor layer, which made kind of a cool effect.

A side effect of this approach was that you could see the inside of all buildings (well, within the viewport) while you were inside one, since they all exist in the same space. We ended up adding a puzzle and a couple minor flavor things that took advantage of this.

If I had had saving/loading of maps ready to go, I might have opted instead for a more traditional RPG-like approach, where the inside of each building is on its own map (or appears to be) and floats in a black void.

Another thing I really liked was the glitch effect, which I wrote on a whim early on because I’ve had shaders on the brain lately. We were both a little unsure about it, but in the end Mel wrote it into the plot and I used it more heavily throughout, including as a transition effect between indoors/outdoors.

Mel was responsible for art and music and story, so the plot unfortunately wasn’t finalized until the last day of the jam. It ended up being 30 pages of dialogue. Sprinkled throughout were special effects that sound like standard things you’d find in any RPG dialogue system — menus, branches, screen fades, and the like — but that I just hadn’t written yet.

The dialogue system was downright primitive when we started; I’d only written it as a brief proof of concept for Isaac, and it had only gotten as far as showing lines of wrapped text. It didn’t even know how to deal with text that was too long for the box. Hell, it didn’t even know how to exit the dialogue and return to the game.

So when I got the final script, I went into a sort of mad panic, doing my best to tack on features in ways I wouldn’t regret later and could maybe reuse. I got pretty far, but when it became clear that we couldn’t possibly have a finished product in time, I invoked my powers as jam coordinator and pushed the deadline back by 24 hours. 48 hours. 54⅓ hours. Oh, well.

The final product came out pretty well, modulo a couple release bugs, ahem. I’ve been really impressed with itch.io, too — it has a thousand twiddles, which makes me very happy, plus graphs of how many people have been playing our game and how they found it! Super cool.

Lessons learned

Ah, yes. Here’s that sweet postmortem content you computer people crave.

Don't leave debug code in

There’s a fairly long optional quest in the game that takes a good few minutes to complete, even if you teleport everywhere instantly. (Ahem.) Finishing the quest kicks off a unique cutscene that involves a decent bit of crappy code I wrote at the last minute. I needed to test it a lot. So, naturally, I added a dummy rule to the beginning of the relevant NPC’s dialogue that just skips right to the end.

I forgot to delete that rule before we released.

Whoops!

The game even has a debug mode, so I could’ve easily made the rule only work then. I didn’t, and it possibly spoiled the whole sidequest for a couple dozen people. My bad.

Try your game at other framerates

The other game-breaking bug we had in the beginning was that some people couldn’t make jumps. For some, it was only when indoors; for others, it was all the time. The common thread was… low framerates.

Why does this matter? Well! When you jump, your upwards velocity is changed to a specific value, calculated to make your jump height slightly more than two tiles. The problem is, gravity is applied after you get jump velocity but before you actually move. It looks like this:

1	`self.velocity = self.velocity + gravity * dt`

Reasonable, right? Gravity is acceleration, so you multiply it by the amount of time that’s passed to get the change to velocity.

Ah… but if your framerate is low, then dt will be relatively large, and gravity will eat away a relatively large chunk of your upwards velocity. On the frame you jump, this effectively reduces your initial jump speed. If your framerate is low enough, you’ll never be able to jump as high as intended.

One obvious fix would be to rearrange the order things happen, so gravity doesn’t come between jumping and movement. I was wary of doing this as an emergency fix, though, because it would’ve taken a bit of rearchitecturing and I wasn’t sure about the side effects. So instead, I made a fix that’s worth having anyway: when the framerate is too long, I slice up dt and do multiple rounds of updating. Now even if the game draws slowly, it plays at the right speed.

This was really easy to discover once I knew to look; all I had to do was add a sleep() in the update or draw loops to artificially lower the framerate. I even found a second bug, which was that you move slowly at low framerates — much like with jumping, your walk speed is capped at a maximum, then friction lowers it, then you actually move.

I also had problems with framerates that were too high, which took me completely by surprise. Your little companion flips out and jitters all over the place or even gets stuck, and jumping just plain doesn’t work most of the time. The problems here were much simpler. I was needlessly rounding Chip’s position to the nearest pixel, so if dt was very small, Chip would only try to move a fraction of a pixel per frame and never get anywhere; I fixed that by simply not rounding.

The issue with jumping needs a little backstory. One of the problems with sloped terrain is that when you walk up a slope and reach the top, your momentum is still carrying you along the path of the slope, i.e. upwards. I had a lot of problems with launching right off the top of even a fairly shallow hill; it looked goofy and amateurish. My terrible solution was: if you started out on the ground, then after moving, try to move a short distance straight down. If you can’t, because something (presumably the ground) is in the way, then you probably just went over a short bump; move as far as you can downwards so you stick to the ground. If you can move downwards, you just went over a ledge, so abort the movement and let gravity take its course next frame.

The problem was that I used a fixed (arbitrary) distance for this ground test. For very short dt, the distance you moved upwards when jumping was less than the distance I then tried dragging you back down to see if you should stay on the ground. The easy fix was to scale the test distance with dt.

Of course, if you’re jumping, obviously you don’t want to stay on the ground, so I shouldn’t do this test at all. But jumping is an active thing, and staying grounded is currently a passive thing (but shouldn’t be, since it emulates walking rather than sliding), and again I didn’t want to start messing with physics guts after release. I’ll be cleaning a few things up for the next game, I’m sure.

This also turned out to be easy to see once I knew to look — I just turned off vsync, and my framerate shot up to 200+.

Quadratic behavior is bad

The low framerate issue wouldn’t have been quite so bad, except for a teeny tiny problem with indoors. I’d accidentally left a loop in when refactoring, so instead of merely drawing every indoor actor each frame, I was drawing every indoor actor for every indoor actor each frame. I think that worked out to 7225 draws instead of 85. (I don’t skip drawing for offscreen actors yet.) Our computers are pretty beefy, so I never noticed. Our one playtester did comment at the eleventh hour that the framerate dipped very slightly while indoors, but I assumed this was just because indoors requires more drawing than outdoors (since it’s drawn right on top of outdoors) and didn’t investiage.

Of course, if you play on a less powerful machine, the difference will be rather more noticeable. Oops.

Just Do It

My collision detection relies on the separating axis theorem, which only works for convex polygons. (Convex polygons are ones that have no “dents” in them — you could wrap a rubber band around one and it would lie snug along each face.) The map Mel drew has rolling terrain and caverns with ceilings, which naturally lead to a lot of concave polygons. (Concave polygons are not convex. They have caves!)

I must’ve spent a good few hours drawing collision polygons on top of the map, manually eyeballing the terrain and cutting it up into only convex polygons.

Eventually I got so tired of this that I threw up my hands and added support for concave polygons.

It took me, like, two minutes. Not only does LÖVE have a built-in function for cutting a polygon into triangles (which are always convex), it also has a function for detecting whether a polygon is convex. I already had support for objects consisting of multiple shapes, so all I had to do was plug these things into each other.

Collision probably would’ve taken much less time if I’d just done that in the first place.

Delete that old code, or maybe not

One of the very first players reported that they’d managed to crash the game right off the bat. It didn’t take long to realize it was because they’d pressed Q, which isn’t actually used in NEON PHASE. It is used in Isaac’s Descent HD, to scroll through the inventory… but NEON PHASE doesn’t use that inventory, and I’d left in the code for handling the keypress, so the game simply crashed.

(This is Lua, so when I say “crash”, I mean “showed a stack trace and refused to play any more”. Slightly better, but only so much.)

So, maybe delete that old code.

Or, wait, maybe don’t. When I removed the debugging sequence break just after release, I also deleted the code for the Q key… and, in a rush, also deleted the code for handling the E key, which is used in NEON PHASE. Rather heavily. Like, for everything. Dammit.

Maybe just play the game before issuing emergency releases? Nah.

Melding styles is easier than you'd think

When I look at the whole map overall, it’s hilarious to me how much the part I designed sticks out. It’s built out of tiles and consists of one large puzzle, whereas the rest of the game is as untiled as you can get and mostly revolves around talking to people.

And yet I don’t think anyone has noticed. It’s just one part of the game with a thing you do. The rest of the game may not have a bunch of wiring puzzles, but enough loose wires are lying around to make them seem fitting. The tiles Mel gave me are good and varied enough that they don’t look like tiles; they just look like they were deliberately made more square for aesthetic or story reasons.

I drew a few of the tiles and edited a few others. Most of the dialogue was written by Mel, but a couple lines that people really like were my own, completely impromptu, invention. No one seems to have noticed. It’s all one game. We didn’t sit down and have a meeting about the style or how to keep it cohesive; I just did stuff when I felt like it, and I naturally took inspiration from what was already there.

People will pay for things if you ask them to

itch.io does something really interesting.

Anything you download is presented as a purchase. You are absolutely welcome to sell things for free, but rather than being an instant download, itch.io treats this as a case of buying for zero dollars.

Why do that? Well, because you are always free to pay more for something you buy on itch, and the purchase dialog has handy buttons for adding a tip.

It turns out that, when presented with a dialog that offers a way to pay money for a free thing, an awful lot of people… paid money! Over a hundred people chipped in a few bucks for our free game, just because itch offered them a button to do so. The vast majority of them paid one of itch’s preset amounts. I’m totally blown away; I knew abstractly that this was possible, but I didn’t really expect it to happen. I’ve never actually sold anything before, either. This is amazing.

Now, granted, we do offer bonuses (concept art and the OST) if you pay $2 or more, at Mel’s request. But consider that I also put my two PICO-8 games on itch, and those have an interesting difference: they’re played in-browser and load automatically right in the page. Instead of a payment dialog, there’s a “support this game” button below the game. They’re older games that most of my audience has probably played already, but they still got a few hundred views between them. And the number of purchases?

Zero.

I’m not trying to criticize or guilt anyone here! I release stuff for free because I want it to be free. I’m just genuinely amazed by how effective itch’s download workflow seems to be. The buttons for chipping in are a natural part of the process of something you’re already doing, so “I might as well” kicks in. I’ve done this myself — I paid for the free m5x7 font I used in NEON PHASE. But something played in-browser is already there, and it takes a much stronger impulse to go out of your way to initiate the process of supporting the game.

Anyway, this is definitely encouraging me to make more things. I’ll probably put my book on itch when I finish it, too.

Also, my book

Speaking of!

If you remember, I’ve been writing a book about game development. Literally, a book about game development — the concept was that I build some games on various free platforms, then write about what I did and how I did it. Game development as a story, rather than a lecture.

I’ve hit a bit of a problem with it, and that problem is with my “real” games — i.e., the ones I didn’t make for the sake of the book. Writing about Isaac’s Descent requires first explaining how the engine came about, which requires reconstructing how I wrote Under Construction, and now we’re at two games’ worth of stuff even before you consider the whole writing a collision engine thing.

Isaac’s Descent HD is posed to have exactly the same problem: it takes a detour through the development of NEON PHASE, so I should talk about that too in some detail.

Both of these games are huge and complex tales already, far too long for a single “chapter”, and I’d already been worrying that the book would be too long.

So! I’m adjusting the idea slightly. Instead of writing about making a bunch of “artificial” games that I make solely for the sake of writing about the experience… I’m cutting it down to just Isaac’s Descent, HD, and the other games in their lineage. That’s already half a dozen games across two platforms, and I think they offer more than enough opportunity to say everything I want.

The overall idea of “talk about making something” is ultimately the same, but I like this refocusing a lot more. It feels a little more genuine, too.

Guess I’ve got a bit of editing to do!

And, finally

You should try out the other games people made for my jam! I can’t believe a Twitter joke somehow caused more than forty games to come into existence that otherwise would not have. I’ve been busy with NEON PHASE followup stuff (like writing this post) and have only barely scratched the surface so far, but I do intend to play every game that was submitted!

Mario Maker: The Wreck

2016-11-01T14:52:00-07:00

33E8-0000-02B2-76DF
Difficulty: very easy
Quality: ★★★★☆
Secrets:

I was rolling a Doom random level theme generator for speedmapping purposes, and one of the prompts it gave was “The Wreckage”. I didn’t really know how to make that in Doom in only an hour, but I did know how to make it in Mario, so I did.

The additional rules were “no monsters” and “no stairs”, so neither of those things appear in this level. It’s quick and entirely atmospheric. I like it. Though it’d be slightly better if I’d correctly named it “The Wreckage”. Oh well.

Inktober

2016-10-23T23:37:00-07:00

Inktober is an ancient and hallowed art tradition, dating all the way back to sometime, when it was started by someone. The idea is simple: draw something in ink every day. Real ink. You know. On paper.

I tried this last year. I quit after four days. Probably because I tried to do it without pencil sketches, and I’m really not very good at drawing things correctly the first time. I’d hoped that forcing myself to do it would spark some improvement, but all it really produced was half a week of frustration and bad artwork.

This year, I was convinced to try again without unnecessarily handicapping myself, so I did that. Three weeks and more than forty ink drawings later, here are some thoughts.

Some background

I’ve been drawing seriously since the beginning of 2015. I spent the first few months working primarily in pencil, until I was gifted a hand-me-down tablet in March; almost everything has been digital since then.

I’ve been fairly lax about learning to use color effectively — I have enough trouble just producing a sketch I like, so I’ve mostly been trying to improve there. Doesn’t feel worth the effort to color a sketch I’m not really happy with, and by the time I’m really happy with it, I’m itching to draw something else. Whoops. Until I get quicker or find some mental workaround, monochrome ink is a good direction to try.

I have an ongoing “daily” pokémon series, so I’ve been continuing that in ink. (Everyone else seems to be using some list of single-word prompts, but I didn’t even know about that until after I’d started, so, whoops.)

I’ve got a few things I want to get better at:

Detailing, whatever that means. Part of the problem is that I’m not sure what it means. My art is fairly simple and cartoony, and I know it’s possible to be more detailed without doing realistic shading, but I don’t have a grasp of how to think about that.
Better edges, which mostly means line weight. I mentally categorize this as a form of scale, which also includes tips like “don’t let parallel lines get too close together” and “don’t draw one or two very small details”.
Better backgrounds and environments. Or, let’s be honest, any backgrounds and environments — I draw an awful lot of single characters floating in an empty white void. My fixed-size canvas presents an obvious and simple challenge: fill the page!
More interesting poses, and relatedly, getting a better hang of anatomy. I started drawing the pokémon series partly for this reason: a great many pokémon have really unusual shapes I’ve tried drawing before. Dealing with weird anatomy and trying to map it to my existing understanding should hopefully flex some visualization muscles.
Lighting, probably? I’m aware that things not facing a light source are in shadow, but my understanding doesn’t extend very far beyond that. How does light affect a large outdoor area? How can you represent the complexity of light and shadow with only a single pen? Art, especially cartoony art, has an entire vocabulary of subtle indicators of shadow and volume that I don’t know much about.

Let’s see what exactly I’ve learned.

Analog materials are very different

I’ve drawn plenty of pencil sketches on paper, and I’ve done a few watercolors, but I’ve never done this volume of “serious” art on paper before.

All my inks so far are in a 3.5” × 5” sketchbook. I’ll run out of pages in a few days, at which point I’ll finish up the month in a bigger sketchbook. It’s been a mixed blessing: I have less page to fill, but details are smaller and more fiddly, so mistakes are more obvious. I also don’t have much room for error with the composition.

I started out drawing with a small black Faber–Castell “PITT artist pen”. Around day five, I borrowed C3 and C7 (light and dark cool greys) Copic sketch markers from Mel; later I got a C5 as well. A few days ago I bought a Lamy Safari fountain pen with Noodler’s Heart of Darkness ink.

Both the FC pen and the fountain pen are ultimately still pens, but they have some interesting differences in edge cases. Used very lightly at an extreme angle, the FC pen produces very scratchy-looking lines… sometimes. Sometimes it does nothing instead, and you must precariously tilt the pen until you find the magical angle, hoping you don’t suddenly get a solid line where you didn’t want it. The Lamy has been much more consistent: it’s a little more willing to draw thinner lines than it’s intended for, and it hasn’t created any unpleasant surprises. The Lamy feels much smoother overall, like it flows, which is appropriate since that’s how fountain pens work.

Markers are interesting. The last “serious” art I did on paper was watercolor, which is pretty fun — I can water a color down however much I want, and if I’m lucky and fast, I can push color around on the paper a bit before it dries. Markers, ah, not so much. Copics are supposed to be blendable, but I’ve yet to figure out how to make that happen. It might be that my sketchbook’s paper is too thin, but the ink seems to dry within seconds, too fast for me to switch markers and do much of anything. For the same reason, I have to color an area by… “flood-filling”? I can’t let the edge of the colored area dry, or when I go back to extend that edge, I’ll be putting down a second layer of ink and create an obvious dark band. I’ve learned to keep the edge wet as much as possible.

On the plus side, going over dry ink in the same color will darken it, and I’ve squeezed several different shades of gray out of just the light marker. The brush tip can be angled in several different ways to make different shapes; I’ve managed a grassy background and a fur texture just by holding the marker differently. Marker ink does bleed very slightly, but it tends to stop at pen ink, a feature I’ve wanted in digital art for at least a century. I can also kinda make strokes that fade out by moving the marker quickly and lifting it off the paper as I go; surely there are more clever things to be done here, but I’ve yet to figure them out.

The drawing of bergmite above was done as the light marker started to run dry, which is not a problem I was expecting. The marker still worked, but not very well. The strokes on the cave wall in the background aren’t a deliberate effect; those are the strokes the marker was making, and I tried to use them as best I could. I didn’t have the medium marker yet, and the dark marker is very dark — almost black. I’d already started laying down marker, so I couldn’t very well finish the picture with just the pen, and I had to improvise.

Ink is permanent

Well. Obviously.

I have to be pretty careful about what I draw, which creates a bit of a conflict. If I make smooth, confident strokes, I’m likely to fuck them up, and I can’t undo and try again. If I make a lot of short strokes, I get those tell-tale amateurish scratchy lines. If I trace my sketch very carefully and my hand isn’t perfectly steady, the resulting line will be visibly shaky.

I probably exacerbated the shaky lines with my choice of relatively small paper; there’s no buffer between those tiny wobbles and the smallest level of detail in the drawing itself. I can’t always even see where my tiny sketch is going, because my big fat fingers are in the way.

I’ve also had the problem that my sketch is such a mess that I can’t tell where a line is supposed to be going… until I’ve drawn it and it’s obviously wrong. Again, small paper exacerbates this by compressing sketches.

Since I can’t fix mistakes, I’ve had to be a little creative about papering over them.

I did one ink with very stark contrast: shadows were completely filled with ink, highlights were bare paper. No shading, hatching, or other middle ground. I’d been meaning to try the approach anyway, but I finally did it after making three or four glaring mistakes. In the final work, they’re all hidden in shadow, so you can’t really tell anything ever went wrong.
I’ve managed to disguise several mistakes of the “curved this line too early” variety just by adding some more parallel strokes and pretending I intended to hatch it all along.
One of the things I’ve been trying to figure out is varying line weight, and one way to vary it is to make edges thicker when in shadows. A clever hack has emerged here.

You see, it’s much easier for me to draw an upwards arc than a downwards arc. (I think this is fairly universal?) I can of course just rotate the paper, but if I’m drawing a cylinder, it’s pretty obvious when the top was drawn with a slight bias in one direction and the bottom was drawn with a slight bias in the other direction.

My lifehack is to draw the top and bottom with the paper oriented the same way, then gradually thicken the bottom, “carving” it into the right shape as I go. I can make a lot of small adjustments and still end up with a single smooth line that looks more or less deliberate.
As a last resort… leave it and hope no one notices. That’s what I did for the floatzel above, who has a big fat extra stroke across their lower stomach. It’s in one of the least interesting parts of the picture, though, so it doesn’t really stand out, even though it’s on one of the lightest surfaces.

Ink takes a while

Ink drawings feel like they’ve consumed my entire month. Sketching and then lining means drawing everything twice. Using physical ink means I have to nail the sketch — but I’m used to digital, where I can sketch sloppily and then fixing up lines as I go. I also can’t rearrange the sketch, move it around on the paper if I started in the wrong place, or even erase precisely, so I’ve had to be much more careful and thoughtful even with pencil. That’s a good thing — I don’t put nearly enough conscious thought into what I’m drawing — but it definitely takes longer. In a few thorny cases I’ve even resorted to doing a very loose digital sketch, then drawing the pencil sketch based off of that.

All told, each one takes maybe two hours, and I’ve been doing two at a time… but wait, that’s still only four hours, right? How are they taking most of a day?

I suspect a bunch of factors are costing me more time than expected. If I can’t think of a scene idea, I’ll dawdle on Twitter for a while. Two “serious” attempts in a medium I’m not used to can be a little draining and require a refractory period. Fragments of time between or around two larger tasks are, of course, lost forever. And I guess there’s that whole thing where I spent half the month waking up in the middle of the night for no reason and then being exhausted by late evening.

Occasionally I’ve experimented with some approach that turns out to be incredibly tedious and time-consuming, like the early Gardevoir above. You would not believe how long that damn grass took. Or maybe you would, if you’d ever tried similar. Even the much lazier tree-covered mountain in the background seemed to take a while. And this is on a fairly small canvas!

I’m feeling a bit exhausted with ink work at this point, which is not the best place to be after buying a bunch of ink supplies. I definitely want to do more of it in the future, but maybe not daily. I also miss being able to undo. Sweet, sweet undo.

Precision is difficult, and I am bad at planning

These turn out to be largely the same problem.

I’m not a particularly patient person, so I like to jump from the sketch into the inking as soon as possible. Sometimes this means I overlook some details. Here’s that whole “not consciously thinking enough” thing again. Consider, in the above image,

The two buildings at the top right are next to each other, yet the angles of their roofs suggest they’re facing in slightly different directions, which doesn’t make a lot of sense for artificial structures.
The path leading from the dock doesn’t quite make sense, and the general scale of the start of the dock versus the shrubs and trees is nonsense. The trees themselves are pretty cool, but it looks like I plopped them down individually without really having a full coherent plan going in. Which is exactly what happened.

Imagining spaces in enough detail to draw them is tough, and not something I’ve really had to do much before. It’s ultimately the same problem I have with game level design, though, so hopefully a breakthrough in one will help me with the other.
Phantump’s left eye has a clear white edge showing the depth of the hole in the trunk, but the right eye’s edge was mostly lost to some errant strokes and subsequent attempts to fix them. Also, even the left margin is nowhere near as thick as the trunk’s bottom edge.
The crosshatched top of phantump’s head blends into the noisy grassy background. The fix for this is to leave a thin white edge around the top of the head. I think I intended to do this, then completely forgot about it as I was drawing the grass. I suppose I’m not used to reasoning about negative space; I can’t mark or indicate it in any way, nor erase the ink if I later realize I laid down too much.
The pupils don’t quite match, but I’d already carved them down a good bit. Negative space problem again. Highlights on dark areas have been a recurring problem all month, especially with markers.

I have no idea how people make beautifully precise inkwork. At the same time, I’ve long had the suspicion that I worry too much about precision and should be a lot looser. I’m missing something here, and I don’t know what it is.

What even is pokémon anatomy

This is a wigglytuff. Wigglytuffs are tall blobs with ears.

I had such a hard time sketching this. (Probably why I rushed the background.)

It turns out that if you draw a wigglytuff even slightly off, the result is a tall blob with ears rather than a wigglytuff. That makes no sense, especially given that wigglytuffs are balloons. Surely, the shape shouldn’t be such a strong part of the wigglytuff identity, and yet it is.

Maybe half of the pokémon I’ve drawn have had some anatomical surprise, even ones I thought I was familiar with. Aerodactyl and huntail have a really pronounced lower jaw. Palpitoad has no arms at all. Pelipper is 70% mouth. Zangoose seems like a straightforward mammal at first glance, but the legs and body and head are all kind of a single blob. Numerous pokémon have no distinct neck, or no distinct shoulders, or a very round abdomen with legs kind of arbitrarily attached somewhere.

Progress, maybe

I don’t know what precisely I’ve gotten out of this experience. I can’t measure artistic progress from one day to the next. I do feel like I’ve gleaned some things, but they seem to be very abstract things. I’m out of the total beginner weeds and solidly into the intermediate hell of just picking up hundreds of little things no one really talks about. All I can do is cross my fingers and push forwards.

The crowd favorite so far is this mega rayquaza, which is kinda funny to me because I don’t feel like I did anything special here. I just copied a bunch of fiddly details. It looks cool, but it felt more like rote work than a struggle to do a new thing.

My own favorite is this much simpler qwilfish. It’s the culmination of several attempts to draw water that I liked, and it came out the best by far. The highlight is also definitely the best I’ve drawn this month. Interesting how that works out.

The rest are on on Tumblr, or in this single Twitter thread.

I entered Ludum Dare 36

2016-08-29T18:01:00-07:00

Short story: I made a video game again! This time it was for Ludum Dare, a game jam with some tight rules: solo only, 48 hours to make the game and all its (non-code) assets.

(This is called the “Compo”; there’s also a 72-hour “Jam” which is much more chill, but I did hard mode. Usually there’s a ratings round, but not this time, for reasons.)

I used the PICO-8 again, so you can play it on the web as long as you have a keyboard. It’s also on Ludum Dare, and in splore, and here’s the cartridge too.

But wait! Read on a bit first.

Foreword

I’ve never entered a game jam before, and I slightly regretted that I missed a PICO-8 jam that was happening while I was making Under Construction. I’ve certainly never made a game in 48 hours, so that seemed exciting.

More specifically, I have some trouble with shaking ideas loose. I don’t know a more specific word than “idea” for this, but I mean creative, narrative ideas: worldbuilding, characters, events, gameplay mechanics, and the like. They have a different texture from “how could I solve this technical problem” ideas or “what should I work on today” ideas.

I’ll often have an idea or two, maybe a theme I want to move towards, and then hit a wall. I can’t think of any more concepts; I can’t find any way to connect the handful I have. I end up shelving the idea, sometimes indefinitely. This has been particularly haunting with my interactive fiction game in progress, Runed Awakening, which by its very nature is nothing but narrative ideas.

My true goal for entering Ludum Dare was to jiggle the idea faucet and maybe loosen it a bit. Nothing’s quite as motivating as an extreme time limit. I went in without anything in mind; I didn’t even know it was coming up until two days beforehand. (The start time is softly enforced by the announcement of a theme, anyway.) I knew it would probably resemble a platformer, since I already had the code available to make that work, but that was about it.

I already wrote about the approach to making our last game, so I can’t very well just do that again. Instead, here’s something a little different: I took regular notes on the state of the game (and myself), all weekend. You can see exactly how it came together, almost hour by hour. Is that interesting? I think it’s interesting.

I don’t know if this is a better read if you play the game first or last. Maybe both?

There’s also a surprise at the very end, as a reward for reading through it all! No, wait, stop, you can’t just scroll down, that’s cheating—

Timeline

Thursday

09:00 — Already nervous. Registered for the site yesterday; voted on the themes today; jam actually starts tomorrow. I have no idea if I can do this. What a great start.

Friday

09:00 — Even more nervous. Last night I started getting drowsy around 5pm, I guess because my sleep is still a bit weird. So not only do I only have 48 hours, but by the looks of things, I’ll be spending half that time asleep.

17:00 — I can’t even sit still and do anything for the next hour; I’m too antsy about getting started.

START!! 18:00 — Theme revealed: “Ancient Technology”. I have no ideas.

Well, no, hang on. Shortly before the theme was announced, I had a brief Twitter conversation that shook something loose. I’d mentioned that I rarely seem to have enough ideas to fill a game. Someone accidentally teased out of me that it’s more specific than that: I have trouble coming up with ideas that appeal to me, that satisfy me in the way I really like in games and stories. In retrospect, I probably have a bad habit of rejecting ideas by reflex before I even have a chance to think about them and turn them into something more inspiring.

The same person also asked how I want games to feel, and of course, that’s what I should be keeping front and center, before even worrying about genre or mechanics or anything. How does this feel, and how does it make me feel? I know that’s important, but I’m not in the habit of thinking about it.

With that in mind, how does “ancient technology” make me feel?

It reminds me immediately of two things: Indiana Jones-esque temples, full of centuries-old mechanisms and unseen triggers that somehow still work perfectly; and also Stargate, where a race literally called “Ancients” made preposterously advanced devices with such a sleek and minimalist design that they might as well have been magic.

The common thread is a sense of, hm, “soft wonder”? You’re never quite sure what’s around the next corner, but it won’t be a huge surprise, just a new curiosity. There’s the impression of a coherent set of rules somewhere behind the scenes, but you never get to see it, and it doesn’t matter that much anyway. You catch a glimpse of what’s left behind, and half your astonishment is that it’s still here at all.

Also, I bet I can make a puzzle-platformer out of this.

18:20 — Okay, well! I have a character Isaac (stolen from Glip, ahem) who exists in Runed Awakening but otherwise has never seen any real use. I might as well use them now, which means this game is also set somewhere in Flora.

I’ve drawn a two-frame walking animation and saved it as isaac.p8 for now. It’s enough to get started. I’m gonna copy/paste all the engine gunk from my unfinished game, rainblob — it’s based on what was in Under Construction, with some minor cleanups and enhancements.

19:00 — I’m struggling a little bit here, because Isaac is two tiles tall, and I never got around to writing real support for actors that are bigger than a single tile. Most of the sprite drawing is now wrapped in a little sprite type, so I don’t think this will be too bad — I almost have it working, except that it doesn’t run yet.

19:07 — Success! Apparently I was closer than I thought. The solution is a bit of a hack: instead of a list of tiles (as animation frames), Isaac has a list of lists of tiles, where each outer list is the animation for one grid space. It required some type-checking to keep the common case working (boo), and it blindly assumes any multi-tile actor is a 1×n rectangle. It’s fine. Whatever. I’ll fix it if I really need to.

19:16 — I drew and placed some cave floor tiles. Isaac can no longer walk left or jump. I am not sure why. I really, really hope it’s not another collision bug. The collision function has been such a nightmare. Is it choking on a moving object that’s more than a tile tall?

19:20 — I have been asked to put a new bag in the trash can. This is wildly unjust. I do not have time for such trivialities. But I have to pee anyway, so it’s okay — I’ll batch these two standing-up activities together to save time. Speed strats.

19:28 — The left/jump thing seems to be a bug with the PICO-8; the button presses don’t register at all. Restarting the “console” fixed it. This is ominous; I hope a mysterious heisenbug doesn’t plague me for the next 46½ hours.

19:51 — Isaac is a wizard. Surely, they should be able to cast spells or whatever. Teeny problem: the PICO-8 only has two buttons, and I need one of them for jumping. (Under Construction uses up for jump, but I’ve seen several impassioned pleas against doing that because it makes using a real d-pad very awkward, and after using the pocketCHIP I’m inclined to agree.)

New plan, then: you have an inventory. Up and down scroll through it, and the spare button means “use the selected item”. Accordingly, I’ve put a little “selected item” indicator in the top left of the screen.

Isaac hasn’t seen too much real character development; it’s hard to develop a character without actually putting them in something. Their backstory thusfar isn’t really important for this game, but I did have the idea that they travel with a staff that can create a reflective bubble. That’s interesting, because it suggests that Isaac prefers to operate defensively. I made a staff sprite and put it in the starting inventory, but I’m not quite sure what to do with it yet; I don’t know how the bubble idea would work in a tiny game.

20:01 — As a proof of concept, I made the staff shoot out particles when you use it. The particle system is from rainblob, and is pretty neat — they’re just dumb actors that draw themselves as a single pixel.

I bound the X button to “use”. Should jumping be X or O? I’m not sure, hm. My Nintendo instincts tell me the right button is for jumping, but on a keyboard, the “d-pad” and buttons are reversed.

20:04 — I realize I added a sound effect for jumping, then accientally overwrote the code that plays it. Oops; fixing that. Good thing I didn’t overwrite the sound! This is what I get for trying to edit the assets in the PICO-8 and the code in vim, when it’s all stored in a single file.

20:37 — I have a printat function (from Under Construction) which prints text to the screen with a given horizontal and vertical alignment. It needs to know the width of text to do this, which is easy enough: the PICO-8 font is fixed-width. Alas! The latest PICO-8 release added characters to represent the controller buttons, and I’d really like to use them, but they’re double-wide. Hacking around this is proving a bit awkward, especially since there’s no ord() function available oh my god.

20:50 — Okay, done. The point of that was: I rigged a little hint that tells you what button to press to jump. When you approach the first ledge, Isaac sprouts a tiny thought bubble with the O button symbol in it. PICO-8 games tend not to explain themselves (something that has frustrated me more than once), so I think that’s nice. It’s the kind of tiny detail I love including in my work.

21:04 — I wrote a tiny fragment of music, but I really don’t know what I’m doing here, so… I don’t know.

I had the idea that there’d be runes carved in the back wall of this cave, so I made a sprite for that, though it’s basically unrecognizable at this size. I don’t know what reading them will do, yet.

I also made the staff draw a bubble (in the form of a circle around you) while you’re holding the “use” button down, via a cheap hack. Kinda just throwing stuff at the wall in the hopes that something will stick.

21:07 — I’ve decided to eat these chips while I ponder where to go from here.

21:22 — So, argh. Isaac’s staff is supposed to create a bubble that reflects magical attacks. The immediate problem there is that my collision assumes everything is a rectangle. I really don’t want to be rewriting collision with only a weekend to spend on this. I could make the bubble rectangular, but who’s ever heard of a rectangular magic bubble?

Maybe I could make this work, but it raises more questions: what magical attacks? What attacks you? Are there monsters? Do I have to write monster AI? Can Isaac die? I need to translate these scraps of thematics into game mechanics, somehow.

I try to remember to think about the feel. I want you to feel like you’re exploring an old cavern/temple/something, laden with traps meant to keep you out. I think that means death, and death means save points, and save points mean saving the game state, which I don’t have extant code for. Oof.

22:00 — Not much has changed; I started doodling sprites as a distraction. Still getting this thing where left and up stop working, what the hell.

22:05 — Actually, I’m getting tired; I should deal with the cat litter before it gets too late. Please hold.

22:59 — I wrote some saving, which doesn’t work yet. Almost, maybe. I do have a pretty cool death animation, though it looks a bit wonky in-game, because animations are on a global timer. Whoops! All of them have been really simple so far, so it hasn’t mattered, but this is something that really needs to start at the beginning and play through exactly once.

23:15 — Okay! I have a save, and I have death, and I even have some sound effects for them. The animation is still off, alas (and loops forever), and there’s no way to load after you die, but the basic cycle of this kind of game is coming together. If I can get a little more engine stuff working tomorrow, I should be able to build a little game. Goodnight for now.

Saturday

07:48 — I’m. I’m up.

08:28 — Made the animation start when the player dies and stop after it’s played once. Also made the music stop immediately on death and touched up the sprites a bit. Still no loading, so death pretty much ends the game forever; that’s up next and should be easy enough. First, breakfast.

09:09 — The world is now restored after you die, and I fixed a few bugs as well. Cool beans.

09:14 — So, ah. That’s a decent start mechanically, but I need a little more concept, especially as it relates to the theme. I don’t expect this game to be particularly deep, what with its non-plot of “explore these caverns”, but I do want to explore the theme a bit. I want something that’s interesting to play, too, even if for only five minutes.

Isaac is a clever wizard. Canonically, he might be the cleverest wizard. What does his staff do?

What kind of traps would be in a place like this? Spikes, falling floors, puzzles? Monsters? Pressure plates?

What does Isaac’s staff do?

Hang on, let me approach this a much more sensible way: if I were going to explore a cavern like this, what would I want my staff to do?

09:59 — I’m still struggling with this question. I thought perhaps the cavern would only be the introductory part, and then you’d find a cool teleporter to a dusty sleek place that looked a lot more techy. I tried drawing some sleek bricks, but I can’t figure out how to get the aesthetic I want with the PICO-8’s palette. So I distracted myself by drawing some foreground tiles again. Whoops?

10:01 — I’d tweeted two GIFs of Isaac’s death while working on it, complete with joking melodramatic captions like “death has no power here”. I also lamented that I didn’t know yet what the game was about, to which someone jokingly replied that so far it seemed to be “about death”.

Aha. Maybe the power of Isaac’s staff is to create savepoints, and maybe some puzzles or items or whatever transcend death, sticking around after you respawn. I’ll work with that for a bit and see what falls out of it.

11:12 — Wow, I’ve been busy! The staff now creates savepoints, complete with a post-death menu, a sound effect, a flash (bless you, UC’s scenefader), a thought-bubble hint, and everything. It’s pretty great? And it fits perfectly: if you’re exploring a trap-laden cavern then you’d want some flavor of safety equipment with you, right? What’s safer than outright resurrection?

I can see some interesting puzzles coming out of this: you have to pick your savepoint carefully to interact with mechanisms in the right way, or you have to make sure you can kill yourself if you need to, since that’s the only way to hop back to a savepoint. And it’s a purely defensive ability, just as I wanted. And something impossibly cool and powerful but hilariously impractical seems extremely up Isaac’s alley, from what I know about them so far.

11:59 — Still busy, which is a good sign! I’ve been working on making some objects for Isaac to interact with in the world; so far I’ve focused on the runes on the wall, though I’m not quite sold on them yet. The entire game so far is that you have to make a save point, jump down a pit to use a thing that extends a bridge over the pit, then kill yourself to get back to the save point and cross the bridge. It’s very rough, but it’s finally looking like a game, which is really great to see.

12:28 — I finally got sick enough of left/up breaking that I sat down and tried every distinct action I could think of, one at a time, to figure out the cause. Turns out it was my drawing tablet, which I’d used a couple times to draw sprites? If the pen is close enough to even register as a pointer, left and up break. I know I’ve seen the tablet listed as a “joypad” in other SDL applications, so my best guess is that it’s somehow acting as an axis and confusing PICO-8? I can’t imagine why or how. Super, super weird, but at least now I know what the problem is.

14:28 — Uh, whoops. Somehow I spent two hours yelling on Twitter. I don’t know how that happened.

16:42 — Hey, what’s up. I’ve been working on music (with very mixed results) and fixing bugs. I’m still missing a lot of minor functionality — for example, resetting the room doesn’t actually clear the platforms, because resetting the map only asks actors to reset themselves, and the platforms are new actors who don’t know they should vanish. Oops.

Oh, I also have them appearing on a timer, which is cool. I want their appearance to be animated, too, but that’s tricky with the current approach of just drawing tiles directly on the map. I guess I could turn them into real actors that are always present but can appear and vanish, which would also fix the reset thing.

For now, it’s time to eat and swim, so I’ll get back to this later.

18:22 — I’m so fucked. Everything is a mess. The room still doesn’t reset correctly. The time is half up and I have almost one room so far.

I need to shift gears here: fix the bugs as quickly as I can, then focus on rooms.

20:05 — I fixed a bunch of reset bugs, but I’m getting increasingly agitated by how half-assed this engine is. It’s alright for what it is, I guess, but it clearly wasn’t designed for anything in particular, and I feel like I have to bolt features on haphazardly as I need them.

Anyway, I made progression work, kinda: when you touch the right side of the room, you move on to the next one. When you touch the right side of the final room, you win, and the game celebrates by crashing.

I made a little moving laser eye thing that kills you on contact, creating a cute puzzle where you just resurrect yourself as soon as it’s gone past you. Changed death so time keeps passing while the prompt is up, of course.

Now I have a whopping, what, three world objects? And one item you can use, the one you start with? And I’m not sure how to put these together into any more puzzles.

I made Isaac’s cloak flutter a bit while they walk. Cool.

20:31 — For lack of any better ideas, I added something I’d wanted since the beginning: Isaac’s color scheme is now chosen randomly at startup. They are a newt, you see.

21:07 — Did some cleanup and minor polishing, but still feeling blocked. Going to brainstorm with myself a bit.

What are some “ancient” mechanisms? Pressure plates; blowdarts; secret doors; hidden buttons; …?

Does Isaac get an improved resurrection ability later? Resurrect where you died? I don’t know how that would be especially useful unless you died on a moving platform, and I don’t have anything like that.

Other magical objects you find…?

Puzzle ideas? Set up a way to kill yourself so you can use it later? Currently there’s no way to interact with the world other than to add those platforms, so I don’t see how this would work. I also like “conflict” puzzles where two goals seem to depend on each other, but offhand I can’t think of anything along those lines besides the first room.

21:55 — I’ve built a third puzzle, which is just some slightly aggravating platforming, made a little less so by the ability to save your progress.

22:19 — I started on a large room marking the end of the cave sequence and the entrance to the sleek brick area. I made a few tiles and a sound effect for it, but I’m not quite sure how the puzzle will work. I want a bigger and more elaborate setup with some slight backtracking, and I want to give the player a new toy to play with, but I’m not sure what.

I’ll have to figure it out tomorrow.

Sunday

08:49 — Uggh, I’m awake. Barely. I keep sleeping for only six hours or so, which sucks.

I think I want to start out by making a title screen and some sort of ending. Even if I only have three puzzles, a front and back cover will make it look much more like an actual game.

09:57 — I made a little title screen and wrote a simple ditty for it, which I might even almost like?

11:09 — Made a credits screen as well, which implies that there’s an actual ending. And there is! You get the Flurry, an enchanted rapier I thought of a little while ago. It’s not described in the game or even mentioned outside of the “credits”, in true 8-bit fashion.

Now I have a complete game no matter what, so I can focus on hammering out some levels without worrying too much about time.

I also fixed up the ingame music; it used to have some high notes come in on a separate track, in my clumsy attempts at corralling multiple instruments, but I think they destroyed the mood. Now it’s mostly those low notes and some light “bass”. It works as a loop now, too. Much better in every way.

The awkward-platforming room had a particularly tricky jump that turned out to be trickier than I thought — I suddenly couldn’t do it at all when trying to demo the game for Mel. At their suggestion, I made it a bit less terrible, though hopefully still tricky enough that it might need a second try.

13:05 — Hi! Wow! I’ve been super busy! I came up with a new puzzle involving leaving a save point in midair while dropping down a pit. Then I finally added a new item, mostly inspired by how easy it was to implement: a spellbook that makes you float but doesn’t let you jump, so you can only move back and forth horizontally until you turn it off. I also added a thought bubble for how to cycle through the inventory, some really cute sound effects for when you use the book, and an introductory puzzle for it. It’s coming along pretty nicely!

14:13 — Trying to design a good puzzle for the next area. I made a stone door object which can open and close, though the way it does so is pretty gross, and a wooden wheel that opens it. I really like the wheel; my first thought was to use a different color lever, but I wanted the doors to be reusable whereas the platform lever isn’t, and using the same type of mechanism seemed misleading.

I might be trying to cram too much into the same room at the moment? It introduces the spellbook and the doors/wheel, then makes you solve a puzzle using both. I might split this up and try to introduce both ideas separately.

I think around 16:00, I’m gonna stop making puzzle rooms (unless I still have an amazing idea) and focus on cleaning stuff up, fixing weird bugs, and maybe un-hacking some of these hacks.

15:19 — Someone asked if I streamed my dev process, and I realized that this would’ve been a perfect opportunity to do that, since everything happens within a single small box. Oops. I guess I’ll stream the last few hours, though now no one can watch without getting all he puzzle spoiled.

I made a separate room for getting the spellbook, plus another for introducing the stone doors. The pacing is much much better, and now there are more puzzles overall, which is nice.

15:54 — My puzzles seem to be pretty solid, and I’ve only got space for one more on the map, so I’m thinking about what I’d like it to be.

I want something else that combines mechanics, like, using the platforms to block a door from closing all the way. But a door and a platform can’t coexist on the same tile, so the door has to start out partially open. And… what happens if you summon the platform after closing the door all the way? Hm. I wish my physics were more thorough, but right now none of these objects interact with each other terribly well; the stone door in particular just kinda ignores anything in its way until it hits solid wall.

16:04 — Instead of all that, I fixed the animation on the wheel (it wasn’t playing at all?), gave it a sound effect that I love, and finally added an explicit way to control draw order. The savepoint rune had been drawing over the player since the very beginning, which had been bugging me all weekend. Now the player is always on top. Very glad I had sort lying around.

16::57 — I guess I’m done? I filled that last puzzle room with an interesting timing thing that uses the lever, wheel, runes, and floating, but there are a couple different ways to go about it, and one way is 1-cycle. It bugs me a little that the original setup I wanted (repeat the platforming, then discover it won’t get you all the way to the exit and have to rethink it) doesn’t work, but, there’s no reason you’d think to do it the fastest way the first time, and I think being able to notice that adds an extra “aha”. Gotta resist the urge to railroad!

(Editor’s note: I later fixed a bug that removed the 1-cycle solution.)

I’ll call this done and let people playtest it, once I make it fit within the compressed size limit.

17:08 — God, fuck the compressed size limit. I started at 20538; I deleted all the debug and unused stuff inherited from rainblob and UC, and now I’m at 18491. The limit is 15360. God dammit. I don’t want to have to strip all the comments again.

17:39 — I ended up deleting all the comments again. Oh, well. I ran through it from start to finish once, and all seems good! The game is done and online, and all that’s left is figuring out how to put it on the LD website.

18:46 — Time is up, but this is “submission hour” and the rules allow fixing minor bugs, so I fixed a few things people have pointed out:

Two obvious places you could get stuck now have spikes. You can reset the room from the menu, but I’m pretty sure nobody noticed the “enter = menu” on the title screen, and a few people have thought they had to reset the entire game.
The last spike pit in the spellbook room required you to walk through spikes, which wasn’t what I intended and looks fatal, even though it’s not. The intention was for it to be an exact replica of the previous pit, except that you have to float across it from a tile higher; this solution now works.
One of those half-rock-brick tiles somehow ended up in the first room? Not sure how. It’s gone now.
Mel expressed annoyance at having to align a float across the wide penultimate room with no kind of hint, so I added a half-rock-brick tile to the place where you need to stand to use the high-up wheel.

Parting thoughts

I enjoyed making this! It definitely accomplished its ultimate goal of giving me more experience shaking ideas loose. Looking back over those notes, the progression is fascinating: I didn’t even know the core mechanic of resurrecting until 16 hours in (a third of the time), and it was inspired by a joke reply on Twitter. At the 41-hour mark, I still only had three and a half puzzle rooms; the final game has ten. The spellbook seriously only exists because “don’t apply gravity” was so trivial to implement, and the floating effect is something I’d already added for making the Flurry dramatically float above its platform. Half the game only exists because I decided a puzzle was too complicated and tried to split it up.

I almost can’t believe I actually churned all this out in 48 hours. I’ve pretty much never made music before, but I ended up really liking the main theme, and I adore the sound effects. The sprites are great, considering the limitations. I’d never drawn a serious sprite animation before, either, but I love Isaac’s death sequence. The cave texture is great, and a last-minute improvement over my original sprite, which looked more like scratched-up wood. I also drew a scroll sprite that I adored, but I never found an excuse to use it in the game, alas.

Almost everyone who’s played it has made it all the way through without too much trouble, but also seemed to enjoy the puzzles. I take that to mean the game has a good learning curve, which I’m really happy about.

I’m glad I already had a little engine, or I would’ve gotten nowhere.

I have some more ideas that I discarded as impractical due to time or size constraints, so I may port the game to LÖVE and try to expand on it. When I say “may”, I mean I started working on this about two hours after finishing the game.

Oh, and I'm writing a book

Right, yes, about that. I’ve been mumbling about this for ages, but I didn’t want to go on about the idea so much that actually doing it lost its appeal. I think I’ve made enough of a dent now that I’m likely to stick with it.

I’m writing a book about game development — the literal act of game development. I made a list of about a dozen free (well, except PICO-8) and cross-platform game engines spanning a wide range of ease-of-use, creative freedom, and age. I’m going to make a little game in each of them and explain what I’m doing as I do it, give background on totally new things, preserve poor choices and show how I recovered from them, say what inspired an idea or how I got past a creative roadblock, etc. The goal is to write something that someone with no experience in programming or art or storytelling can follow from beginning to end, getting at least an impression of what it looks like to create a game from scratch.

It’s kind of a response to the web’s mountains of tutorials and beginner docs that take you from “here’s what a variable is” all the way to “here’s what a function is”, then abandon you. I hate trying to get into a new thing and only finding slow, dull introductions that don’t tell me how to do anything interesting, or even show what kinds of things are possible. I hope that for anyone who learns the way I do, “here’s how I made a whole game” will be more than enough to hit the ground running.

I have part of an early chapter on MegaZeux written; I wanted to finish it by the end of August, but that’s clearly not happening, oops. I also started on a Godot chapter, which will be a little different since it’s for a game that will hopefully have multiple people working on it.

Isaac’s Descent will be the subject of a PICO-8 chapter — that’s why I took the notes! It’ll expand considerably on what I wrote above, starting with going through all the code I inherited from Under Construction (and recreating how I wrote it in the first place). I also have about 20 snapshots of the game as it developed, which I’m holding onto myself for now.

I want to put rough drafts of each chapter on the $4 Patreon tier as I finish them, so keep an eye out for that, though I don’t have any ETA just yet. I imagine MegaZeux or PICO-8 will be ready within the next couple months.

Under Construction, our PICO-8 game

2016-05-25T00:00:00-07:00

Mel and I made a game!

We’d wanted to a small game together for a while. Last month’s post about embedding Lua reminded me of the existence of the PICO-8, a “fantasy console” with 8-bit-ish limitations and built-in editing tools. Both of us have a bad habit of letting ambitions spiral way out of control, so “built-in limitations” sounded pretty good to me. I bought the console ($15, or free with the $20 Voxatron alpha) on a whim and started tinkering with it.

The result: Under Construction!

You can play in your very own web browser, assuming you have a keyboard. Also, that image is the actual cartridge, which you can save and play directly if you happen to have PICO-8. It’s also in the PICO-8 BBS.

(A couple people using Chrome on OS X have reported a very early crash, which seems to be a bug outside of my control. Safari works, and merely restarting Chrome has fixed it for at least one person.)

I don’t have too much to say about the game itself; hopefully, it speaks for itself. If not, there’s a little more on its Floraverse post.

I do have some things to say about making it. Also I am really, really tired, so apologies if this is even more meandering than usual.

The PICO-8

You can get a quick idea of what the console is all about from the homepage. I say “console”, but of course, there’s no physical hardware — the PICO-8 is a game engine with some severe artificial restrictions. It’s kind of like an emulator for a console that never existed.

Feel free to pore over the manual, but the most obvious limitations are:

Screen resolution of 128×128, usually displayed scaled up, since that’s microscopic on modern monitors.
16-color fixed palette. The colors you see in the screenshots are the only colors you can use, period.
A spritesheet with enough room for 256 8×8 sprites. (You can make and use larger sprites, or use the space for something else entirely if you want, but the built-in tools assume you generally want that sprite size.)
A 128×64 map, as measured in tiles. The screen is 16×16 tiles, so that’s enough space for 32 screenfuls.
Alas! Half of the sprite space and half of the map space are shared, so you can’t actually have both 256 sprites and 32 map screens. You can have 256 sprites and 16 map screens, or 128 sprites and 32 map screens (which is what we did), or split the shared space some other way.
64 chiptuney sound effects, complete with a tiny tracker for creating them.
64 music tracks, built out of loops of up to four sound effects. There are only four sound channels total, so having four-channel background music means you can’t play any sound effects on top of it.

The programming language is a modified Lua, which comes with its own restrictions, but I’ll get to those later.

The restrictions are “carefully chosen to be fun to work with, [and] encourage small but expressive designs”. For the most part, they succeeded.

Our process

I bought PICO-8 at the beginning of the month. I spent a few hours a day over the next several days messing around, gradually producing a tiny non-game I called “eeveequest” and tweeting out successive iterations. I added the basics as they came to mind, without any real goal: movement, collision, jumping, music, sound effects, scrolling, camera movement.

The PICO-8 did let me create something with all the usual parts of a game in a matter of hours, and that’s pretty cool. I’ve never made music before, save for an hour or two trying to get audio working with LMMS, but I managed even a simple tune and some chimes here.

Meanwhile, Mel was independently trying it out, drawing sprites and populating a map. I copied my movement code over to their cartridge so we could walk around in this little world.

Then, uh, they gave me an avalanche of text describing what they wanted, and I vanished from the mortal realm for ten days while I set about making it happen.

Look, I didn’t say this was a good process. Our next endeavor should be a little more balanced, since we won’t be eight hours apart, and a good chunk of engine code is already written.

One particularly nice thing: PICO-8 cartridges are very simple text files with the code at the top. I eventually migrated to writing code in vim rather than the (extremely simple) built-in code editor, and if Mel had been working on the map at the same time, I could just copy-paste everything except the code into my own cart. It would play decently well with source control, but for a two-person project where I’m the only one editing the code, I couldn’t really justify inflicting git on a non-programmer. We did have one minor incident where a few map changes were lost, but for the most part, it worked surprisingly well for collaborating between a programmer and an artist.

There was a lot more back-and-forth towards the end, once the bulk of the code was written (and Mel was no longer busy selling at three conventions), when the remaining work was subtler design issues. That was probably the most fun I had.

Programming the PICO-8

I picked on Lua a bit in that post last month. Having now worked with it for two solid weeks, I regret what I said. Because now I really want to say it all again, more forcefully. Silently ignoring errors (including division by zero!) and having no easy way to print values for debugging are my top two least favorite programming language “features”.

Plenty of Lua is just plain weird, but forgiveable. Those two things make it pretty aggravating. It’s not even for any good reason — Lua clearly has an error-reporting mechanism, so it’s entirely capable of having division by zero be an error. And half the point of a dynamic runtime is that you can easily examine values at runtime, yet Lua makes doing that as difficult as possible. Argh.

PICO-8's Lua

The PICO-8 uses a slightly modified Lua 5.2. The documentation isn’t precise about what parts of Lua are still available, so I had some minor misadventures, like thinking varargs weren’t supported because the arg global was missing. (Turns out varargs work fine, but Lua 5.2 changed the syntax and got rid of the clumsy global.)

If it weren’t yet obvious, I’m no Lua expert. The most obvious differences to me are:

Numbers are signed 16.16 fixed-point, rather than Lua’s double-precision floats. (This has the curious side effect that dividing by zero produces 32768.) I have a soft spot for fixed-point! It’s nice sometimes to have a Planck length that doesn’t depend on where you are in the game world.
Most of the standard library is missing. There’s no collectgarbage, error, ipairs, pcall, tostring, unpack, or other more obscure stuff. The bit32, debug, math, os, string, and table libraries are gone. The _G superglobal is gone.
Several built-ins have been changed or replaced with alternatives: all iterates over a sequence-like table; pairs iterates over all keys and values in a table; print now prints to a particular screen coordinate. A handful of substitute math and string functions are built in. There are functions for bit operations, which I guess were in the bit32 library.
There are some mutating assignment operators: +=, -=, *=, /=, %=. Lua doesn’t have these.

The PICO-8 does still have metatables and coroutines. Metatables were a blessing. Coroutines are nice, but I never came up with a good excuse to use them.

Writing the actual game stuff

Each of the PICO-8’s sprites has a byte’s worth of flags — eight color-coded toggles that can be turned on or off. They don’t mean anything to the console, and you’re free to use them however you want in your game.

I decided early on, even for EeveeQuest™, to use one of the flags to indicate a block was solid. It’s the most obvious approach, and it turned out to have the happy side effect that Mel could change the physics of the game world without touching the code at all. I ended up using five more flags to indicate which acts a tile should appear in.

I love rigging game engines so that people can modify as much stuff as possible without touching code. I already prefer writing code in a more declarative style, and this is even better: the declarations are out of code entirely and in a graphical tool instead.

Game code is generally awful, so I did my best to keep things tidy. First, some brief background.

A game has two major concerns: it has to simulate the world, and it has to draw that world to the screen. The easiest and most obvious approach, then, is to alternate those steps: do a single update pass (where everyone takes one step, say), then draw, then do another update, and so on. One round of updating and drawing is a frame, and the length of time it takes is a tic. If you want your game to run at 60 fps, then a tic is 1/60 seconds, and you have to be sure you can both update once and draw once in that amount of time.

You get into trouble when drawing to the screen starts to take long. Say it takes two tics. Now not only is the display laggy, but the actual game world is running at half speed, because you only run an update pass every two tics instead of every one.

The PICO-8 is not the kind of platform you might expect to have this problem, but nonetheless it offers a very simple solution. It asks your code to update, then it asks your code to draw, separately. If the console detects that the game is running too slowly to hit its usual 30 fps, it’ll automatically slow down its framerate to 15fps, but it’ll ask you to update twice between draws. (Put differently, it skips every other draw.)

This turned out to be handy in act 4, where the fog effect is sometimes a little too intensive. The framerate drops, but the world still moves along at the right speed, so it just looks like the animation isn’t quite as smooth.

I copied this approach all the way down. I have a simple object called a “scene”, which is what you might also call a “screen”: the title screen, playable area, text between acts, and ending credits are all different scenes. The playable scene has a handful of layers, each of which updates and then draws like a stack.

The map is kind of interesting. The PICO-8 has a function for drawing an entire block of the map to the screen, which works pretty well for static stuff like background tiles and solid walls. There’s no built-in support for animation, though, and certainly nothing for handling player movement or tiles that only sometimes exist.

So I made an “actor” type, which can be anything that wants to participate in the usual update/draw cycle. There are three major kinds of actor:

Decor shouldn’t move and doesn’t draw itself; instead, it edits its own position on the map. This is used for all the animated sprites, as well as a few static objects like radios.
Mobs aren’t on the map at all and can move around freely, possibly colliding with parts of the map and each other. Only the player and the rocks are mobs; each additional one makes collision detection significantly more expensive. (I never got around to adding a blockmap.)
Transient actors don’t actually update or draw, and in fact they don’t permanently exist at all. They’re only created temporarily, when the player or another mob bumps into a map tile. When you walk into a wall, for example, the game creates a temporary wall actor at that position that checks its sprite’s flags to see if it blocks you. This is how the spikes work, too; they don’t need to update every tic, because they don’t actually do anything on their own, but they can still have custom behavior when you bump into them. They also have a custom collision box.

You can declare that a specific sprite on the map will always be turned into a particular kind of actor, and give it its own behavior. Virtually everything works this way, even the player, which means you can move the mole sprite anywhere on the map and it’ll automatically become the player’s start point.

You can also define an animation, and it’ll automatically be turned into a type of decor that doesn’t do anything except edit the map every few frames to animate itself.

By far, the worst thing to deal with was collision. I must’ve rewritten it four or five times.

I’ve written collision code before, but apparently I’d never done it from complete scratch for a world with free movement and polished it to a mirror sheen.

Maybe I’m missing something here, but the usual simple approach to collision is terrible. It tends to go like this.

Move the player some amount in the direction they’re moving.
See if they’re now overlapping anything.
If they are, move them back to where they started.

That’s some hot garbage. What if you’re falling, and you’re a pixel above the ground, but you’re moving at two pixels per tic? The game will continually try to move you two pixels, see you’re stuck in the ground, and then put you back where you started. You’ll hover a pixel above the ground forever.

I tried doing some research, by which I mean I googled for three minutes and got sick of finding “tutorials” that didn’t go any further than this useless algorithm, so I just beat on it until I got what I wanted. My approach:

Get the player’s bounding box. Extend that box in the direction they’re moving, so it covers both their old and new position.
Get a list of all the actors that overlap that box, including transient actors for every tile. (This is the main place they’re used, so I can handle them the same way as any other actor.)
Sort all those actors in the order the player will hit them, starting with the closest.
Look at the first actor. Move the player towards it until they touch it, then stop. If the actor has any collision behavior, activate it now.
If the actor is solid, you’re done, at least in this direction; drop the actor’s velocity to zero. Otherwise, repeat with the next actor.
If there’s any movement left at the end, tack that on too, since nothing else can be in the way.

I had some fun bugs along the way, like the one where the collision detection was almost perfect, unless you hit a solid block exactly on its corner, in which case you would pass right through it. Or the multiple times you couldn’t walk along the ground because you were colliding with the corner of the next tile of ground.

This seems to be pretty rock solid now, though it’s a bit slow when there are more than half a dozen or so mobs wandering around. It works well enough for this game.

The runner-up for awkward things to deal with: time. Even a simple animation is mildly annoying. It’s not that the math is difficult; it’s more that you can’t look at the math and immediately understand what it’s doing.

I wished numerous times that I had a more straightforward way to say “fade this in, wait 10 tics, then fade it back out”, but I never had the time to sit down and come up with something nice. I considered using coroutines for this, since they’re naturally sleep-able, but I don’t think they’d work so well for anything beyond the most trivial operations. cocos2d has a concept of “actions”, where you can animate a change over time and even schedule several changes to happen in sequence; maybe I’ll give something like that a try next time.

The PICO-8's limits

Working within limitations has a unique way of inspiring creative solutions. It can even help you get started in a medium you’ve never tried before. I know. It’s the whole point of the console. I only got around to making some music because I was handed a very limited tracker.

Sixteen colors? Well, that’s okay; now I don’t have to worry about picking my own colors, which is something I’m not terribly good at.

Small screen and sprite size? That puts a cap on how good the art can possibly be expected to look anyway, so I can make simple sprites fairly easily and have a decent-looking game.

Limited map space? Well… now we’re getting into fuzzier territory. A limit on map space is less of a creative constraint and more of a hard cap on how much game you can fit in your game. At least you can make up for it in a few ways with some creative programming.

Hmm. About that.

There are three limits on the amount of code you can have:

No more than 8192 tokens. A token is a single identifier, string, number, or operator. A pair of brackets counts as one token. Commas, periods, colons, and the local and end keywords are free.
No more than 65536 bytes. That’s a pretty high limit, and I think it really only exists to prevent you from cramming ludicrous amounts of data into a cartridge via strings.
No more than 15360 bytes, after compression. More on that in a moment.

I thought 8192 sounded like plenty. Then I went and wrote a game. Our final tally, for my 2779 lines of Lua:

8183/8192 tokens
56668/65536 bytes
22574/15360 compressed bytes

That’s not a typo; I was well over the compressed limit. I only even found out about the compressed limit a few days ago — the documentation never actually mentions it, and the built-in editor only tracks code size and token count! It came as a horrible surprise. For the released version of the game, I had to delete every single comment, remove every trace of debugging code, and rename several local variables. I was resorting to deleting extra blank lines before I finally got it to fit.

Trying to squeeze code into a compressed limit is maddening. Most of the obvious ways to significantly shorten code involve removing duplication, but duplication is exactly what compression algorithms are good at dealing with! Several times I tried an approach that made the code shorter in both absolute size and token count, only to find that the compressed size had grown slightly larger.

As for tokens, wow. I’ve never even had to think in tokens before. Here are some token costs from the finished game.

65 — updating the camera to follow the player
95 — sort function
148 — simple vector type
198 — function to print text on the screen aligned to a point
201 — debugging function that prints values to stdout
256 — perlin noise implementation
261 — screen fade
280 — fog effect from act 4
370 — title screen
690 — credits in their entirety
703 — physics and collision detection

It adds up pretty quickly. We essentially sliced off two entire endings, because I just didn’t have any space left.

Incredibly, the token limitation used to be worse. I went searching for people talking about this, and I mostly found posts from several releases ago, when the byte limit was 32K and there weren’t any freebies in the token count — parentheses counted as two, dots counted as one.

This kind of sucks, for several reasons.

The most obvious way to compensate for the graphical limitations is with code: procedural generation, effects, and the like. Both of those eat up tokens fast. I spent a total of 536 tokens, 6.5% of my total space, just on adding a fog overlay.
I’m effectively punished for organizing code. Some 13% of my token count goes towards dotted names, i.e., foo.bar instead of foo_bar.
It’s just not the kind of limitation that really inspires creativity. If you limit the number of sprites I have, okay, I can at least visually see I only have so much space and adjust accordingly. I don’t have any sense for how many tokens I’d need to write some code. If I hit the limit and the game isn’t done, that’s just a wall. I don’t have a whole lot of creative options here: I can waste time playing code golf (which here is more of an annoying puzzle than a source of inspiration), or I can delete a chunk of the game.

I looked at the most popular cartridges, and a couple depressing themes emerged. Several games are merely demos of interesting ideas that could be expanded into a game, except that the ideas alone already take half of the available tokens. Quite a few have resorted to a strong arcade vibe, with little distinction between “levels” except that there are more or different enemies. There’s a little survival crafting game which seems like it could be interesting, but it only has four objects you can build and it’s already out of tokens. Very few games have any sort of instructions (which would eat precious tokens!), and several of them have left me frustrated from the outset, until I read through the forum thread in search of someone explaining what I’m supposed to be doing.

And keep in mind, you’re starting pretty much from scratch. The most convenience the PICO-8 affords is copying a whole block of the map to the screen at once. Everything else is your problem, and it all has to fit under the cap.

The PICO-8 is really appealing overall: it has little built-in tools for creating all the resources, it’s pretty easy to do stuff with, its plaintext cartridge format makes collaboration simple, its resource limits are inspiring, it can compile to a ready-to-go browser page with no effort at all, it can even spit out short gameplay GIFs with the press of a button. And yet I’m a little apprehensive about trying anything very ambitious, now that I know how little code I’m allowed to have. The relatively small map is a bit of a shame, but the code limit is really killer.

I’ll certainly be making a few more things with this. At the same time, I can’t help but feel that some of the potential has been squeezed out of it.

I made a Doom level

2016-03-31T02:23:00-07:00

Yes, dear readers, I have a confession to make. Despite spending 29,000 words explaining why and how you should make a Doom level, I’ve yet to actually publish one myself.

I’ve been… orbiting? the ZDoom community for over a decade, but only really contributed in the form of minor wiki edits and occasional advice. I started a good few maps when I was a teenager, but I tended to get bogged down in making some complicated contraption work, and then get bored with the whole idea and lose interest.

More recently I’ve actually made a few maps that got as far as having an exit (!), but I never really finished them, and I haven’t published them anywhere.

So when the Doom Upstart Mapping Project 2 was announced, with the goal of just getting something done with the short time limit of a week, I figured I should give it a shot. And I did. I spent six straight days doing virtually nothing but working on this Doom map.

Results: pretty good! I’m pretty happy with it, and a few people have played it and enjoyed it. I put a lot of thought into it — or tried, anyway — and have a lot to say about it, so this is my developer commentary.

I’ve described the course through the map as I go, and I’ve tried to include some context for people whose knowledge of Doom is only “you shoot monsters”, so I hope it’s at least a little accessible. It’s really long, though. Again. Sorry. Not actually sorry.

Play it first

If you have any intention of ever playing my map, you should do that before reading further. I’m going to spoil the progression as well as most of the secrets, and some of this may not make any sense if you haven’t seen it. It does support difficulty levels, and in the style of Doom II, the map is practically barren on easy. Or if you don’t care about combat and just want to tour the map, you can play with no monsters, or do kill monsters in the console, or use freeze to freeze them all, or notarget to make them ignore you (unless you shoot them). Or whatever.

If you’re not sold, here are some rave reviews:

not today, satan

uhh…it works?

how the fuck did u make this map in a week […] DID U JUST LIKE NOT SLEEP ALL WEEK

Anyway, you will need ZDoom and Doom II. I covered getting those in the first Doom mapping post, and it still applies. Recent ZDooms will even automatically find Doom II, on any platform, if it was installed by Steam or GOG. Slick.

Per the project requirements, anything based on ZDoom 2.5+ should work, including Zandronum 2.1.2, if that’s of interest to you. If you don’t know what that is, don’t worry, just grab the latest ZDoom.

Also you will need my map, of course. You can just drag it onto ZDoom to play it. Feel free to poke at it in SLADE, too.

You can also play the full mapping project, which was finally released on April 22, 2016. My map is MAP32, Throughfare, which you are welcome to try finding in the overworld hub map. (It’s in an alcove all by itself.)

The city

I’m structuring this as though it were real developer commentary: I ran through the map in normal progression and took screenshots of interesting things as I went. Most of these were taken with notarget (which makes monsters ignore you) or freeze (which pauses all object AI). I tried playing normally, but I kept getting wrapped up in shooting things and forgetting to actually take screenshots. Oops.

I also know that I said rather a lot of this before, in the design part of the Doom series, but oh well I’m saying it again.

One thing John Romero said in his IGN interview/playthrough really stuck out to me: he always tries to design the opening shot so that the player has something interesting to look at.

I realized, over the course of building this map, that that’s not enough. The “opening shot” of every part of the map should give the player something interesting to look at. I’ve compared level design to composition in visual arts before, and that’s a large part of (my limited understanding of) composition: arranging your work to guide the viewer’s eye through the important parts.

You could argue that I failed spectacularly with this opening shot, and you might be right. I took inspiration from Sandy Petersen here, rather than Romero. Sandy designed more than half of Doom II, and his maps are generally chaotic and sloppy and gimmicky. They’re also my favorites.

This, then, is something of a tribute to the Doom II map that’s most memorable to me: MAP13, Downtown. It’s still nowhere near as good an opening shot as Downtown had; instead it serves as a reminder of that map.

The very first thing I did was look for background music, in the hopes that it would conjure some inspiration. Alas, that didn’t work. I did eventually find music I liked, though: “Back in 1982” by warlord, if you want to give it an independent listen.

It’s not really a city map, though. I get the impression that a lot of the Doom community doesn’t much like city (or “sandbox”) maps, and whether that’s correct or not, this is my response to them.

Doom is fundamentally a creepy game. It’s still creepy to me now. It’s not merely that there are monsters; it’s that those monsters might be around the corner at any time, waiting for you. Doom’s atmosphere is unnerving more than anything else. That’s the point of all the key traps and monster closets, I think; not to surprise the player by popping monsters out, but to train the player to never think anywhere is safe.

I distinctly remember having that feeling as a kid trying to play Doom II. The further you go into these dozens of levels, the fewer safe places there are. You can clear out a level, sure, but then there’s nothing to do except go press the exit switch. There will be no reprieve, only another wave of things coming to get you.

I’d love to pass that unnerving feeling on, so here I tried to do it in a different way. The city is completely empty. None of the buildings even have doors. If you have the monster count on, you can see that there are plenty, so where are they? When will they come after you?

Something definitely went down here.

I had to improve this alley twice. The first time, it was using the same texture as the outside of the building, but the way the engine handled the light made it almost invisible. After I fixed that, someone still missed it, so I threw the burning barrel in there just in case the trail of corpses wasn’t obvious enough. I like it there thematically, anyway.

I love dead players with items scattered around them. It’s common to give the player a shotgun very early on, since the pistol is worthless, so here it is.

As you turn to leave, surprise! A strange swirling portal opens up, and a single demon emerges just before it closes. You have plenty of space to take it out before it reaches the end of the alley, and then it’s over, and you’re still left alone in an empty city.

Oops, no you’re not. You can even hear all these guys pop out of their portal — I made the portal sound carry for quite a ways.

Yes, the portal makes a sound as you walk through it. It’s actually part of the Arch-Vile’s attack sound, though on its own it doesn’t sound familiar to me at all. It’s a quick, short noise that sounds, well, like something emerging from a portal.

ZDoom is pretty heavily scriptable, and it’s possible to spawn any object anywhere in the level at any time. I feel pretty strongly that spawning monsters this way is bad form, because it makes that initial monster count inaccurate. Instead, I have a small army actually standing on the other side of this portal, and they walk through it. It makes for a better effect overall, I think, because they behave randomly in a way that would be very fiddly to duplicate on my own. You might kill them all and walk up to the portal just in time for one last imp to come waltzing through, or one of them might get confused and not come through at all, so they’ll be waiting for you on the other side.

There’s even a “bug” here that worked out in my favor. ZDoom has invisible “patrol point” objects, which you can use to make monsters follow a path. All I did was stick one behind the portal, and tell the entire army to walk towards it. The bug is that they keep trying to walk directly towards it even after they’re through the portal, because their very simple AI doesn’t know they can’t possibly reach it that way. By sheer coincidence, the direction they walk is towards the alley, so it seems as though they’re creeping towards the player.

The portal is now the only interesting thing in the city.

This is the heart of my response to those hypothetical people who don’t like city maps. Fine, have it your way; this isn’t one.

I love everything about the portals. The texture is FIREBLU1, one of a pair of notoriously gaudy stock textures. I think it works fantastically well here, and the swirling pattern (done with ZDoom’s Quake-like texture warping, usually used for liquids) helps distract from the fact that it’s just a rectangle.

I put a lot of effort into the portals upfront, figuring that they’d play a major role in the map. They open from the middle, which took a little finagling to make look right, since textures generally paint relative to the top. Walking through one makes a quick “fwuh” sound, and your screen abruptly gains a blue tint that fades away fairly quickly. You also lurch out of the portal slightly faster than you stepped into it.

Each portal requires a front line with FIREBLU as its lower textures, a thin triangle drawn behind that line, a control sector whose floor and ceiling are the same height as the middle of the portal, and a teleport destination object positioned in the exact center of the portal both horizontally and vertically. All of these things need to be tagged in very particular ways, so the portal script can orchestrate everything correctly. And you need all of that again for the portal on the other side, if you expect it to work. Like I said, a lot of effort.

I had a lot of bugs, too, including several different ones that trapped me in a teleport loop if I moved just the right way. I think my favorite involved a portal that was oriented diagonally on the map; I tried to walk through it, and the sound and blue flash played, but I came right out the back side of it. The ultimate cause? I’d drawn the line slightly misaligned with the grid, so its center didn’t quite pass through the teleporter object. If I walked through the portal very slowly, I would teleport once, arrive just in front of the other portal, and instantly teleport again to the back of the first one. That was maddening to figure out.

Hell

So this is actually a Hell map, I guess. My initial idea was to have Hell be underneath the city — not physically, but with some silent teleportation to create the illusion. I realized right away that the player would just be falling down holes and riding back up very long elevators, which is not very dramatic or exciting. Hence, portals. Maybe I took inspiration from the work being done on genuine portals in the ZDoom engine lately, or from the FIREBLU teleportation “bars” in TNT: Evilution’s MAP04, Wormhole. But mostly I just love portals.

Oh, there was one other allure of portals. Something that frustrates me occasionally about Doom’s 2D design is that you always know the area behind you is safe. Doom addresses this in various ways: monster closets, teleporters, teleporting monsters in, locking doors behind you, etc. (Sandy once replied to me on Twitter to explain that Doom II’s MAP04, The Focus, is so named because you’re constantly surrounded by critters.) Portals seemed like an interesting way to approach this problem, since you could be surrounded but still have a (very small) escape route. That said, I completely neglected to do it here, because I wanted to make you arrive on this cool altar.

The map is actually named “Throughfare”, out of the vague idea that you’re just passing through this city, but also passing through to somewhere else entirely. Then I looked it up and learned that it’s actually spelled “thoroughfare”, which clearly makes no sense at all. I was reminded of Doom II’s MAP03, The Gantlet, so I kept the misspelling as a nod to Sandy, who named all the levels. Granted, “gantlet” is an actual archaic spelling, but “throughfare” is apparently common enough to deserve a Wiktionary page.

The portal instantly closes behind you, which gives you a clear and immediate goal: get the Hell out of Hell. This is one of several reasons the map doesn’t support co-op, though I can imagine a couple ways it could be made to work.

I love this skull platform. I think it turned out to be surprisingly similar to the end of E1M8, which is nice even if unintentional.

I also love that door. I don’t know if I’ve seen it done elsewhere, but I just felt like making a door that doesn’t touch its own walls. Once I started adding monsters, I discovered that a couple of the imps outside would see you arrive and open the door to come bother you, which is great.

Outside is a whole lot of stuff going on. On the left is a switch behind some very small alternating flesh bars. The bars are pretty small to prevent the player from “gliding” — wedging the 32-unit-square player into a 32-unit-wide gap. Large chunks of several Doom II maps can be skipped because the mapper made some locked bars exactly 32 units apart.

To the right are two other outcroppings. The middle one has some door and switch stuff going on, and the far one mostly has some imps tossing fireballs at you.

Please take a moment to appreciate that the sky here is different from the sky in the city. It’s not particularly difficult to do, but I think it’s an important touch.

The lava, oh ho ho. The lava gave me a bit of a headache. If you’ll recall part 3 of the Doom series, I turned a flat lava-textured surface into deep lava. I don’t know how obvious it was in the article, but I very abruptly realized I didn’t know how to make the top surface of the lava brighter than the rest of the room. I think I ended up cheating and darkening the ceiling and walls, instead.

Here, I did it right. The lava is a deep swimmable liquid using Sector_Set3dFloor (the ZDoom feature that lets you stack multiple horizontal surfaces on top of each other), and it’s lit by two layers of ExtraFloor_LightOnly that extends slightly above it. You can see the banding of light on the walls; those are the EF_LOs. They’re like 3D floors, but instead of drawing an actual floor, they just change the light level for a particular horizontal slice of an area. (In vanilla Doom, an area can only have one light level, which applies to the floor, ceiling, walls, and objects.)

The headache was that the lava is set to inflict 20% damage, but I found that if you held the jump key so you sort of skidded along its surface, you’d never take any damage! For the longest time I thought this was a bug with the way damage inside a 3D floor works. Only in the second-to-last day of mapping did I realize: EF_LO really does act like a 3D floor. And while the dummy sector that controls the lava’s height is set to inflict 20% damage, the sector that controls the light‘s height is not. I changed the light to also inflict damage, and lo and behold! Fixed. I think the engine was looking through 3D floors from the top down, discovered that I was “inside” the light, saw it had no damage, and stopped looking there. Whoops.

It all works now, though. The lava is very pretty, it glows beautifully, it’s a rosy orange if you fall into it, and it will absolutely kill you very fast. There is no way out if you fall in, because it’s a gigantic chasm full of lava, and I can’t think of a better way to say “don’t fall in this pit” than to fill it with lava.

You can’t do anything outside except be shot at, so your only choice is to come back in. You have two options from here: up to the left, or down to the right. I always go down to the right first, largely because that’s the side I designed first.

That dead player and associated loot used to be on the steps, until someone told me they’d walked right over it several times without seeing it. Doom isn’t really designed for looking at stuff right below you, and the steps are fairly steep. Oops.

Lava cave

This is where I first really got stuck. It was awful.

I’d mostly finished the altar room. I’d drawn some stairs down here, and made a big box, and put a lava pit in it. The idea was that you’d drain the lava to be able to reach a switch in it. And then… nothing. That was all I had.

I only had a week, and this was day one or two, so I was pretty anxious about possibly being out of ideas already. A few people told me I should try looking at real places to get some inspiration. I don’t think that’s quite right; nothing in Doom is really a real place. Besides, real places are designed to be easily accessible, whereas Doom is about impeding your progress.

That’s something I’ve struggled to keep in mind. My instinct is to build things that are simple, straightforward, clean. And that makes really boring maps! The entire point of Doom — of games at all — is the experience of getting from start to finish, not just hitting the finish line. Games are the scenic route. That’s what I fundamentally love about Doom: exploring a slightly twisted environment, mashing buttons and having things happen.

It took me a while, but I finally made this a somewhat interesting area. It even follows Romero’s rule of being interesting to look at. There’s all kinds of stuff happening here: a huge pool of lava to your left, cliff with a glowing wall to the right, a very fancy switch in the distance. And a dude on a glowing platform shooting your face.

I really want to capture how I got from an empty room to this, but it’s hard to put into words. I just tried to remember all the design advice I’d heard and apply it a bit at a time. The lava pool was originally front and center, for example, which meant your whole initial view was just a big pit of lava that you then had to circle around. Not very exciting, so I moved it to one side. Now there was a lot of empty space left on the right. The room was pretty flat, so I made a cliff. The cliff was pretty long and monotonous, so I cut a large chunk out of it to hide the back part.

I went on about contrast in the design post, but having built this map, and in particular this area, I think “add contrast” is backwards. What I did here was remove monotony.

If some sizable chunk of the space all had the same property, I tried to break it up. Is the floor totally flat? Break it up. Is the light level the same? Break it up. Are there no switches? Hell, break that up too.

“Add contrast” and “remove monotony” sound equivalent; the difference is in the point of view. If you’re having trouble coming up with new ideas, it’s much easier to think about removing something than adding something. I had a big empty cave, and I spent hours drawing a total blank on what to add to it. Then I tried breaking up the very flat and boring floor, and suddenly I had a cliff, and I started to think about what I could do with a cliff. Just having a starting point was extremely helpful.

This is all relative — the size and importance of the area make a lot of difference! This area is huge and important, so the lava pool and cliff are similarly huge. But that glowing platform right in front of you is fairly small, so it only needs very small chunks varied. And in some cases, monotony is itself a form of contrast! If your whole map has decent contrast going on, then a sprawling monotonous area like that lava pool will stand out.

The rim of the lava pool doesn’t seem very interesting at first glance. If you look very closely, just above my crosshair, you can see the texture on the wall is a little off. That’s because there’s a little side cave there, and inside, the map’s chainsaw! A fine reward for anyone with an eye for detail, anyone who explores the rim, or even just anyone who bothers to look at the automap.

I’ve realized lately how much I love narrative touches in games. I guess it’s what you call “environmental storytelling”, but I think that sounds too much like there’s a single coherent story. There doesn’t have to be. I just want details that leave me feeling like the world exists independently of me, that someone else has been through here, that it’s not just a simulated world designed solely for my amusement. Which is hard, because that’s literally what it is.

Here, then, are some dead demons, like this is a shrine to a holy relic. I particularly love this because it seems to tell a story, but the story it tells doesn’t make any sense! Who would come to Hell, kill these demons, and then carefully leave their weapon on a glowing platform like this? It’s ridiculous, but it feels great anyway.

Teeny tiny easter egg: on easier difficulties, there are fewer demon corpses here.

Rooms that you can’t see all at once give the player something to explore.

That’s really hard to internalize. It feels so inefficient. Yet I’m hard-pressed to name many memorable rooms in Doom that are entirely visible from a single vantage point.

It’s so important, too. Players need direction, something to do, so they don’t feel like they’re just meandering from room to room. Games are interactive; leave space for the player to offer their own input.

After I drew the cliff and cut this hole in it, I needed a way for the player to get up to the cliff. Hiding a simple lift behind this rocky wall seemed too simple, so I tucked a spiral staircase in the void, and it kinda grew into its own little area. The metal texturing acts as a reprieve from the rock texture outside.

That rock texture, by the way, was fairly deliberate. A playtester even commented on it and suggested I use a different floor/ceiling, but I decided to keep it this way. It should be samey, because that’s what this place is: a jagged hole cut out of solid rock.

I realized, from this room, what didn’t feel right about taking inspiration from real places. In a medium where gameplay concerns heavily affect the design of the world, and especially in a game as abstract as Doom, it’s more important to evoke the feeling of a place. Not necessarily a “real” place, either. Lay enough groundwork that the place seems cohesive, and the rest will happen inside the player’s head. If you try too hard to model a real place, you might hit the uncanny valley and just look like a crappy replica of reality.

I didn’t really understand how to do that until I did it. I thought I needed to have the fully-realized place in mind, and pare down the details until I was just hinting at it. Nope. The details we fill in ourselves are hazy and different for everyone, so it doesn’t matter what they are. Just stick to a general theme until you start to get a sense of place in your own head, and then lean into it.

You know that early underground level in Super Mario Bros? Really? Why did you know exactly what I meant? Have you ever seen an underground place like that, with easily-smashed bricks floating in the void and pipes three times the size of a person jutting out of the ground? Me neither. It doesn’t matter, because it’s close enough to obviously be underground. It’s what underground looks like within the vocabulary of the game. The music is lower, the level is a shadowed blue color, and of course you get there by taking a pipe down through the ground.

This, then, is the lava cave. It’s rocky enough to pass for a cave, and it has lava. There’s a maintenance shaft in the middle, which doesn’t seem out of place at all, because why would it?

This tiny side room is a great example of all of this stuff. It doesn’t need to exist; I could just have well not drawn this wall, and had a single larger room with these items in it. I added the room because the style of this maintenance area has been small and cramped, and even that little combined room felt too big. Splitting out a side room preserves the theme, gives the outer room an interesting shape, and gives the player one more place to go. Plus it hides the secret on the back wall.

This whole area, by the way, reflects something else I really enjoy in Doom maps: folding a deceptively large amount of stuff into a very small space. From the outside, this is just a moderately-sized rocky wall; inside, somehow, there’s a tunnel and a spiral staircase and two rooms and a small cave outside with imps on it! You go through several areas and come out mere feet from where you started. It’s a really neat effect.

All of that led to this switch, which lowers the red wall.

The original plan was that you’d think the inner red wall was just the back side of the outer red wall, and when you pressed the switch to lower them, surprise! There’s a bunch of revenants in the middle. There are seven of them, and there’s not much space between them and the cave wall, so I was worried that they’d instantly swarm you and block your escape.

Luckily, I’m a doofus and forgot to flag them as ‘ambush’ — which would’ve made them wait silently until they actually saw me before yelling and giving chase. Instead, they hear your first shot in the cave and bunch up on one end of their little channel, so they’re easy to run away from. Even better, they’re yelling at you the entire time you’re making your way up to the cliffside. I thought that effect was much better than my first idea, so I left it how it was.

The switch that lowers them has a little stockpile in front, as a quiet hint that something’s about to go down. Also, if you’re clever, you can preserve the two barrels on the cliff and use them to inflict some splash damage, since you don’t have the rocket launcher yet.

And the point of lowering the red wall was to hit this switch that’s been tantalizing you since the beginning, which drains the lava pool.

I’d intended to have a physical pump mechanism that this switch activated; it’d explain why this switch drains the lava, and flavor the whole cave as a geothermal generator or something. I just never got around to it.

Lowering the lava also wakes up these three cacodemons, who rise out of some remaining pools in the floor. They’ve been there the whole time, but dormant.

The switch there raises a lift and grants access to the cool skull switch that’s been teasing you since you first arrived in this room.

There’s a blue armor behind it, which counts as a secret. If you hadn’t caught on yet, I love secrets. I love finding them, so I love providing them for other people to find. They’re little rewards for poking around, going off the beaten path. This one isn’t particularly hard to find, but then, neither is the chainsaw.

The switch still works even if the lava hasn’t been drained. If you know it’s there and are feeling incredibly gutsy, you could dive in, mash the switch, leap out, and skip the entire right half of the room. I haven’t actually tried this, but I think it’s just barely possible. What a shame that the only armor you can reach yet is also in the lava, on the other side of the switch.

I really, really like switches that visually indicate what they’re doing. You can get on with the game without running around for 20 minutes trying to guess what just changed, and the switch itself feels more interactive besides. It worked out particularly well here: this is the most grandiose switch in the room, by far.

You can’t tell from a screenshot, but the pink fleshy texture rotates while the pillars open, so it looks like tendrils are twisting into the rock.

That concludes the lava cave! Next is the, uh, other one.

Green cave

This area is a bit more abstract, but still holds together. The stairs up to it and this platform here have a mossy growth on them; the walls are unusually green for a cave; the ceiling reminds me of knotted roots. There are a couple dead trees here, in contrast to the fairly barren lava cave. And then there are the weird glowing flesh tendrils, framing the very Doom II scrolling face texture, which I adore. I don’t know what this is, but it feels alive, and seeing it in Hell with these grotesque parts stabbed through its core is a little unsettling.

Another one of Romero’s comments that stuck with me is that he hates symmetry. A symmetrical map is only half a map. The player has to do the same thing twice, and all the designer did is copy and paste the rest.

I kept that in mind and ended up with a very different second cave. The lava cave was big but fairly easy; the only ambush was the revenant army, which you could hear coming the entire time. This room is more straightforward, but also more compact and a little more tricky.

I love that sole arachnotron up there. I love how big and obnoxious arachnotrons are in general — all of their sound effects are just as annoying as the player’s own plasma gun, and their loud as hell death cry is suitably satisfying. I think they stand out to me because of the way Sandy sprinkled them all over the outside of MAP12, The Factory. Here’s a whole bunch of wide open space, so let’s dump these huge clunky monstrosities everywhere. Perfect.

Pressing that red brick switch converts that wall into a set of stairs, so you can walk up to the face platform. I tend to replay Doom design commentary that I like while mapping, and I listened to an entire Let’s Play of Doom II The Way id Did; somewhere in there was the offhand remark that stair-building effects aren’t used much in modern maps. That stuck with me, so I made some stairs out of this huge prominent wall. Creating the stairs somewhat reduces the amount of cover available, which is interesting now that I think about it.

I always do the other room first, just because I made it first. It’s also nice to get the blue armor as soon as possible, and you get the plasma gun (but not much ammo). This room deserved a reason to be done first, too, and so I put the super shotgun here. I feel like I watch a lot of expert Doom players get through maps almost exclusively using the super shotgun, so here, you have to earn it.

One of the videos I replayed mentioned that an ambush when picking up a key is boring and expected. I can understand that. It doesn’t make a lot of sense, anyway; why not attack before you get the key, to stop you from getting it? Most of the traps in this map, then, force the player to actively spring them.

In this case, the super shotgun is on a raised platform. Pressing the platform will lower it, but also lower the adjacent wall, behind which are two hell knights. If you fire or try to run, you’ll also wake up two revenants further along.

And the door… oh, the door. I love this door so much. It’s a “blazing” door, opening almost instantly and with a special sound effect. Coming in, that is. When you open it to leave, it opens veeeery slowly. I think the technical term for this is a “fuck-you”, and I think Doom is deserving of having a couple of them.

The rest of the room is fairly simple. Kill the things, take some stairs up to the smaller caves, press a switch. That raises the gate around the cool skull switch. (Raising a solid gate texture is a ZDoom thing that I dig.)

I know I just said that I like to make the player spring traps on themselves, but I broke that rule here. As you approach the switch, a wall opens behind you, and an arch-vile comes out. Arch-viles are monsters that “cast” a fire on you from a distance; you have about two seconds to break line of sight with him, or you will be in a world of hurt. This room has plenty of places to hide, making him more of a surprise than a serious threat.

Both of the skull switches automatically quicksave. If you rush directly for this switch and press it — and why wouldn’t you? — it’s possible that you’ll get a quicksave right as he’s starting to attack you. Oops. There isn’t a more appropriate place to save, though. Oh well.

I haven’t mentioned difficulty levels at all yet, and this room is where they’re most obviously different. Doom II has five skill levels, but the two easiest and two hardest use the same monster arrangements and just tweak some numbers. That leaves three skill levels to map for: easy, medium, hard. (You can set all five independently with ZDoom, but I don’t see why you would do that.) I designed the map for hard difficulty, balanced ammo and health, and then adjusted difficulty last.

To do that, I took a look at a few Doom II maps on doomwiki, which has a convenient table of how many of each type of object appear on each difficulty. I was somewhat surprised to find that ammo, health, armor, powerups, etc. are almost always unchanged between difficulties, meaning that you have plenty to spare if you play on easy. I was even more surprised to find that the monster count was roughly proportioned 1:2:3. The game is basically barren on easy.

As an extreme example: MAP16, Suburbs, is a very open map with a prominently-placed key. When you pick up the key, tons of enemies start teleporting in all over the map. It’s terrible. Aside from a handful of oddballs, the monster counts are as follows:

Hard: 97 imps, 25 cacodemons, 14 revenants, 15 mancubi
Easy: 49 imps, 0 cacodemons, 1 revenant, 0 mancubi

If you play on easy, the horde from my nightmares is reduced to a few dozen imps. Amazing.

Enlightened, I went through the map and made a third of the monsters not appear on medium, and those plus another third not appear on easy. I was a bit torn on what to do in places where I had only one tough monster, though, like this arch-vile trap. I decided to replace the arch-vile with a revenant on easy, and likewise replace the arachnotron with a less threatening hell knight. I took difficulty into account a couple other ways, too, which I’ll get to later.

If you’re curious, the final monster tally is 307 on hard, 227 on medium, 155 on easy.

Chasm

With both of those cool skull switches pressed, the eye switch in the chasm is now accessible. A whole lotta stuff has been released, though.

I’m really, really happy that this part of the map turned out to be truly non-linear. I say “truly” to distinguish from “faux” non-linear, which is usually what people mean. Maps like Downtown look linear at first blush, because there are a lot of places you can go… but most of them are optional and won’t help you progress. To complete the level, you always need to go through the same sequence of critical events in the same order: blue key, blue door, red key, red door, yellow key, yellow door, exit. Contrast with MAP19, The Citadel, where you always need the red key but can get either the blue or yellow key, and order doesn’t matter. Likewise, you do have to press both switches in my map, but the map doesn’t care which one you tackle first.

I didn’t use any scripting to do this, either. I feel very strongly that scripting should be kept as minimal as possible, to keep the game feeling as Doom-like as possible. I could’ve kept track of how many switches you’d pressed, and only released the monsters when you’d pressed both. Or I could’ve done the straightforward thing: stuff the monsters behind two doors, and have each switch open one door. Then the monsters can only come out when both doors are open. It’s the same reasoning as using native HTML instead of reinventing with JavaScript.

The eye switch makes this floating bridge rise slowly from the lava. The individual chunks bob slowly in the air. It’s not a very complicated effect, but it looks really cool.

This grants you access to the middle outcropping. If you’re playing on hard, you might be feeling pressed for ammo right about here. Good! A little ammo pressure is great. Like I said, I get the impression a lot of expert Doom players blaze through everything with just the super shotgun. I deliberately avoided leaving enough shells around to get away with that. Doom has a bunch of weapons, and you ought to use a few of them.

Placing the ammo was trickier than I thought. I realized pretty early on that it was hard to balance the pickups when they vary so wildly in value. I said in my Doom series that I measure damage roughly in terms of super shotgun (or rocket) blasts, so in terms of damage only, 20 bullets ≈ 2 shells ≈ 1 rocket ≈ 10 cells. Based on that, here are all the ammo pickups, how much of your maximum ammo they refill (assuming no backpack), and how many super-shotgun-equivalent blasts you get from them:

clip (10 bullets): ½ blast, 5% max ammo
bullet box (50 bullets): 2½ blasts, 25% max ammo
4 shells: 2 blasts, 8% max ammo
shell box (20 shells): 10 blasts, 40% max ammo
1 rocket: 1 blast, 2% max ammo
rocket box (5 rockets): 5 blasts, 10% max ammo
small cell (20 cells): 2 blasts, 7% max ammo
bulk cell (100 cells): 10 blasts, 33% max ammo

What a ridiculous spread. You’re full up with only three bulk cells, but you need ten boxes of rockets. A small shell pickup is worth four small bullet pickups. Full rockets do five times more damage than full bullets. How on Earth do you handle this?

I didn’t do a great job early on — I threw ammo around and immediately fed the map to my playtester before going to bed. It turned out that I’d front-loaded the ammo. Those boxes of shells add up real fast, and I had more than a few lying around. For my second try, I replaced most of the boxes of shells with a few individual shells sprinkled around, and used a couple more relatively-small rocket pickups. That seemed to work pretty well.

Someone has made a small resource mod that adds medium-sized pickups for all four types of ammo. I would’ve liked to have those available here, I think.

Two brief detours

Before making any further progress, I want to show the two most obtuse secrets in the entire map. If you don’t want them spoiled, you should skip this whole section.

…

Okay then.

Originally, the portal in the alleyway stayed open, and you walked through it. This little altar is where you came out. I hadn’t built anything else in the chasm yet.

There’s a secret in the alleyway that dates back to this original design: if you go behind where the portal opens, there’s an inset door that opens to reveal a berserk pack. (Berserk is the powerup that instantly refills you to 100% health, and also makes your punch 10× more powerful until the end of the level.) With the initial design, you could either grab it before you got the shotgun (which is a bit of a waste, since you have full health), OR you could re-enter the portal from the back and pop out behind it in the alley. Now that the portal closes right away, you can get it fairly easily whenever you want, which is probably a good thing since it’s the only berserk pack in the map.

Anyway, I realized that having only a single demon emerge from the depths of Hell was kind of weird and anticlimactic, so I started to build the altar and the little swarm of cannon fodder that comes after you. I realized that a fancy marble room with you as the focal point was a way cooler introduction than just popping out on a red cliff, and that’s when I made the alley portal close right away.

But. There’s a slight delay before the demon acts. If you know the portal will be there, you can charge straight for it and just barely get through before the demon does. You’ll end up here, and telefrag the demon.

Why would you do this? Because at the start of the level, there’s an alcove with three backpacks in it. The only backpacks in the map. And it closes as soon as you take the portal to the altar — not that it matters, since you can’t get back over there anyway.

The bridge used to extend all the way across the chasm, so you could press the switch to reopen the alley portal, and emerge back into the city, and… nothing would be different. It was confusing and pointless, so I cut off that end of the bridge.

The result is very deliberate and tricky and I love it. I had this whole chunk of unused map, and I turned it into a really cool secret. It’s right in front of you, rife with hints that you should be able to get there somehow. There’s an altar! There’s a big switch! (It just re-opens the alley portal so you can get back, of course.) And I didn’t mark the alcove as having a secret wall, so you can see something is hidden there if you look at the automap!

Someone commented that it’s kind of mean to have the only backpacks in an obtuse secret. Damn right it is. Having a backpack doubles your ammo capacity, which changes the ammo balance severely. If I give it to you late in the map, what’s the point, when you’re probably maxed out and near the end anyway? If I give it to you early in the map, what was the point of having it as a powerup at all when you’re never burdened by the default ammo capacity? The only satisfying answer I had was to make you earn it by being clever.

The other obtuse secret has a bright red hint in both caves. No, really, there’s a huge red slab of wall.

You might spot an out-of-the-way switch in one cave. The only visible effect is to make that huge red slab of wall a different texture. Until you find both switches, which fully opens the doors, in much the same way as the double-layered monster closets in the chasm.

This reveals a little marble passageway, connecting the two caves. In the middle is a lift, which takes you down to… a little tomb, maybe? It has some rockets for you, and two points of interest.

This tank is entirely flavor. I don’t know how well it conveys what I was thinking. If you look at the automap here, you’ll see that you’re right behind the altar where you first arrived. The idea was that the portal is being powered by blood, or something. (The corpses constantly spew little red particles that drift upwards and fade away.)

Fun fact: I originally had the map powerup down here. Then I came to my senses and realized that the item used for finding missed secrets really does not belong in the most obscure secret.

The other thing here is this portal, which takes you to a hellish beach floating somewhere out in the void. Guarded by two barons (minibosses who can take a beating) is the only BFG in the map.

The texture is a stock texture, but with its colors shifted from dark grays to light browns. I didn’t edit it; ZDoom has a feature for describing that kind of color shift with a single line in a text file.

Originally this was an actual beach in the ocean, but I felt obligated to give it sloping edges, which is a huge pain in the ass. None of the stock Doom II skies really belong above an endless ocean, anyway.

If you leave the island through the back of the portal, you come out behind it in the tomb, which lets you get to the only megasphere in the map! Secrets inside more secrets are the best kind of secrets.

The only hint to this is a misaligned section of brick. It used to be less misaligned, but I watched someone live on stream go behind the portal and still miss the door twice, so.

Now that we’re pretty beefed up, let’s get back to the game progression.

Middle outcropping

Here’s that “cool establishing shot” thing again. You’ve got some doors, a switch up on that cliff, and some little pillars awkwardly hanging out here.

This area is a calmer come-down from all the stuff you just fought in the chasm. I don’t have a lot to say about it. The left door leads to a dozen minor enemies, and the right door leads to a couple tougher ones. Both of them lead to the same revenant room behind the cliff with a lift on it. You can go whichever way you want. It’s probably worth doing both, since they have some ammo that you’re starting to hurt for.

Is it bad that I don’t feel too strongly about these areas? Or does it make sense that a somewhat quieter area would be less distinct? They’re not bland; they just don’t evoke anything in particular.

Oh, I do like this, though. A cage full of lost souls on the right side. They can only attack by charging, so they’re basically harmless in there and bumble around colliding with each other.

This is our lost soul cage, where we keep our lost souls.

Here’s another archvile, this time rendered fairly harmless. You can just peek around the corner of his cage and take potshots at him, or ignore him entirely and charge up the stairs.

I originally forgot to flag the bars as impassable, so he would see you and just charge straight through the bars to set you on fire. Two people played through this without mentioning it.

This used to be a single arch-vile, a great surprise to find on a lift. Then I added the arch-vile in the green cave, and the arch-vile in the cave, and that was too many arch-viles.

A playtester had been doing a Tyson run (punching only) for kicks, and he’d had to run past the cacodemon ambush in the chasm, since it’s hard to punch things that are floating over lava. While he’d made his way through the side rooms to get here, the cacodemons had been trying to move towards him and had clustered together at the top of this lift.

When he pulled the lift down, the floating cacodemons moved down with it. He thought that was absolutely hilarious. So now there are cacodemons here.

Pressing the switch on the cliff raises a switch below the cliff. Why? So you can watch what that switch does.

Pressing the second switch will lower it into the ground, then raise an altar right in front of you, underneath where those pillars are. Right between them, a portal opens. Finally! You’re free from Hell.

Homecoming

You arrive home in this weirdly nondescript room. What is this room? I don’t know. It’s textured like an apartment, but there’s not a lot of things in it.

I think that’s okay. I mean, the point of this room is for a lot of zombie men to shoot you with guns, so it’s not like it needs too many frills. If I had a potted plant object to work with, I might’ve stuck one in the corner, but I don’t, so I didn’t.

I love that revenant in the corner. Naturally, the flesh walls scroll around him. It’s great. Like Hell tried to force itself into our dimension, but it didn’t do a very good job, so now this one skeleton is just stuck in the wall.

The lift doesn’t go down, but once you leave this building, you can use it to return here (and back to Hell, if you wish). I added it in an embarrassed panic towards the end, after realizing that at one point you drop out of a shaft in the ceiling, meaning you had no way to ever go back and collect missed secrets. I’m pretty solidly in the camp that nothing in a level should become permanently inaccessible unless you have a really good reason. Like, say, if it’s an obtuse secret.

This room is so ridiculous. I love it.

At this point you’re inside one of the city buildings, so I had a finite amount of space to work inside. I carved it into rooms and then had to put something in each room. For this one, I stuck some pipes (a bundle of pipes?) in the corner. That reminded me of those huge room-filling bathtubs, so I made one. And put a single demon in it. With some dudes hanging around.

I don’t know what’s going on here, but it’s fascinating.

This elevator is true 3D. It’s one of the very few overt uses of room-over-room in the whole map. It seemed fitting.

I wanted to have sliding elevator doors, but for a variety of gritty technical reasons, it never worked out. Instead you get this very Doom-style open lift.

I said that I value preserving that Doom-like feel, and it’s true here too. If I’d done the Doom thing and used a traditional lift, the two floors would’ve had to be on different sides of the lift. I happen to think that draws attention to the fact that you can’t do room-over-room in Doom. What I built looks and feels like an analog for an actual elevator, but departs from vanilla Doom capabilities in fairly minor ways. The way the rooms are packed together feels like there could be two entirely separate floors here, but the only true overlap is the space immediately in front of the elevator. The switch has to use a script because it does a different thing every time you press it, but it still feels like an extension of pressing the elevator itself to summon it.

I’m hanging out with this frozen revenant. Usually you call the elevator down, he appears and yells at you, and you shoot him in the face a lot. Because sound can’t be blocked vertically, the dudes upstairs hear this and wake up. They can only hear you if you’re in the overlap area directly in front of the elevator, which makes sense if you don’t think about it too hard, so I didn’t bother fixing it.

Two options, as usual. The left is a dead end, but has a box of bullets in an open crate, which I like. There’s also a banister and some kind of pit? What’s going on there? I’m not sure.

The other room is kind of an empty square, but it has this really fancy light fixture in the center. It’s neat enough that it monopolizes the whole room and seems like a reason for the room to exist all on its own. I’m surprised how well it works.

It wouldn’t be a modern Doom map without some bricks cut out of the floor, so here’s that. It’s a silly trope, but I like it anyway.

This is just a hallway, but for some reason it’s lined with books.

The books are really another fuck-you. Everyone thinks the bookcase texture is a secret switch. Everyone presses the bookcase texture. So here you go: have a bunch of imps.

The first time someone else playtested this part was right after I’d added this hallway. It had eight imps and no reward. The result was unpleasant. Now, it has the map. A micro-library seemed a fitting place for it.

In order to make both bookcase lifts count as the same secret, they’re actually part of the same discontinuous sector.

This room is great. Yeah, yeah, the switch makes stairs come up — here’s my second contribution to stair-building. But look at that lighting! It’s glorious.

You follow the vents a bit, and you come out here. In the vents are a secret soul sphere behind that electric panel texture, which is my favorite place to have secrets, to the point that I don’t know why you would ever use that texture and not have a secret behind it. You don’t notice at the time, but the vents also cross over an alleyway, putting you in a different building here. That’s the second use of room-over-room, and you can see the third and final one in this screenshot: I made a tiny shelf for some shells.

I have slightly mixed feelings about these rooms. I do like the very open and interconnected design; you have to move around a bit to get the full picture of what’s going on. I like the wooden stage at the back. I like the stucco texture, even.

I’m just not sure I know what this is. It’s definitely something, which is good, but what that thing is eludes me. I don’t really feel like these rooms are missing anything — scattering pointless detailing around wouldn’t improve them — they’re just a bit odd.

I feel this way about both buildings, really. I did rush them a bit, but also, they’re vaguely-defined human structures; what else would go here besides what’s already here? They’re a transitional area, full of right angles to distinguish them from the (un)natural shapes of Hell, yet otherwise indistinct. You pass through them fairly quickly, with no real reason to linger. If they’re meant to evoke anything at all, it’s exactly that sense of banality, as a stark contrast to where you’ve just come from.

I’ve worried a bit that this whole building overstays its welcome, but it’s all fairly small and straightforward. The few side rooms are obvious dead ends, not major red herrings. I don’t know! I’m trying to reassure myself that I didn’t jam a boring bit in the middle here.

Hell on Earth

Finally you find some stairs that let you out to the ground floor, and you’re greeted with this. A portal with some dudes coming out of it. Well, no matter, you’ve seen this happen before.

Then you turn the corner.

I wasn’t originally sure what would happen when you got back to the city. There would have to be some monsters, of course, and… and what? Now you go in some buildings? Why couldn’t you before?

Then my playtester commented that when you come back to the city, Hell should come with you. Of course! The entire plot of Doom II.

So I set about filling these “buildings” with tiny Hellscapes that would be revealed when you returned. Yes, this is exactly the same city. All of this stuff is here when you start the map. It’s just sealed behind a few walls textured to look like buildings, all of which drop away when the altar is revealed.

I really like that Hell Cathedral; it came out surprisingly well considering I had to cram it into a fairly small space and only had a few relevant textures at my disposal. The towers are some of the only use of slopes in the map.

Those marble pillars out front could permanently trap you if you happened to fall between them and the steps. Oops! Thank goodness for playtesters.

The exposed city acts more like a traditional city map. There’s somewhere you need to go to progress, but it’s not immediately obvious, and there are a number of distractions in the meantime.

Here’s one of them. You may be running a little low on ammo by now, so if you intend to kill all the critters now filling the streets, you’ll need to find a bit more. You can run up this spire for a pretty nice reward, but you’ll have to deal with the baron and the harmful floor and the various things rushing towards you. I like this kind of risk/reward.

Another use of slopes. What exactly happened here? I’m not sure, but it looks interesting; it’s vaguely reminiscent of the Terminator time bubbles that cut spheres out of nearby objects.

There’s a little ammo cache here, too, as a reward for exploring this furthest corner and braving some revenants.

The monsters don’t actually walk through the portals this time — I wanted them fairly spread out, and choreographing them to walk to dozens of specific points would’ve been incredibly tedious and completely invisible to the player. Instead, they’re arranged in a few off-screen alcoves roughly shaped like chunks of the pavement. ZDoom has a TeleportGroup special that can teleport a group of objects relative to a particular point, and this is a very straightforward use of it. Each alcove has a teleporter thing inside it in the same relative spot as a portal, and when the altar is revealed, each group of monsters is teleported to around a portal in the same configuration.

I love this shot. It’s kind of a shame that most players will never see it; as soon as the lost souls spot you, they’ll start charging your way.

The only thing of interest in the flesh spires (which are harmless) is a switch in the back, which lowers the invulnerability sphere that’s been visible since the beginning, if you cared to look back here.

I had a couple interesting bugs with that invulnerability pillar. Originally, I had a green particle fountain on top of it to make the invulnerability sphere look all the fancier. Unfortunately, particle fountains aren’t affected by gravity, so when the pillar lowered, the particles stayed suspended in midair. Whoops.

The pillar sector was originally flagged as secret, but I found out that a player running over it at top speed might actually miss getting credit for the secret. I assume this is because the player’s center was never actually within the sector. Movement in games is usually done in discrete chunks: every given fraction of a second, the game multiplies your speed by that fraction of a second and moves you that far. It’s thus possible to be standing on one side of a small area and have such a high speed that you move onto the other side of the area without ever actually being inside it. You still get the invulnerability sphere as long as your entire radius touches the radius of the sphere, which makes for a large margin of error, but I guess secret tracking only looks at the single point marking your position.

The easiest fix was to change this so the sphere itself is the secret, which is a ZDoom-specific feature. It’s even a new enough feature that Zandronum, the ZDoom fork given as the compatibility base for DUMP 2, doesn’t support it. Zandronum will just think there’s one less total secret and not count the invulnerability sphere as being one. This is the only Zandronum compatibility issue, as far as I’m aware.

Oh, the hell knights had a curious bug. I’d been messing with another area that required a lot of careful vertical placement of objects, and then I came back to the city to add the hell knights. Due to SLADE’s somewhat obtuse handling of thing creation, the hell knights (and several other monsters) ended up inheriting a z height of 1536. I discovered this when a playtester showed me a screenshot of a hell knight standing on the wall around the city, which I can only imagine happened because a hell knight appeared in midair and then fell onto the wall… somehow.

I wanted this section to feel intense without actually being preposterously difficult.

Modders often like to make hard things. Really hard things. Mario Maker is a great testament to this. It makes sense — modders are generally people who are already very familiar with the base gameplay, so they’ll generally want more of a challenge and be capable of dealing with it. On the other hand, too much of this can alienate potential new blood, who try to get into the community and smack face-first into a difficulty wall.

But also… making hard things is easy. At the extreme end, it’s trivial to make an impossible level in any game: just surround the player with walls. Surround them with boss monsters to be only mostly impossible. Require someone to play exactly like you, or play extremely precisely, or not make any mistakes, and you have a level that’s just frustrating instead.

Creating a challenge that has consistent moderate difficulty is actually pretty difficult! You can tone down the enemies and give the player plenty of resources, but the really difficult part is finding all the accidental gotchas. Maybe it’s easy to take a rocket to the face here if you don’t know it’s coming; maybe you can fall into this inescapable pit; maybe a new player will struggle through the whole map because they didn’t know where the good weapons are. A few rounds of Mario Maker has humbled me considerably — every single level I’ve made, even the ones that were explicitly intended to be pretty easy, has had some kind of clumsy oversight. Just because other people don’t play the same way I do.

I took yet another crack at that here. Quite a few monsters spawn in the city, but there’s plenty of room for dodging, several places to hide, and a lot of infighting potential. Even these arachnotrons, a common sight in wide open spaces, spawn in this jagged street that hampers their offensive ability. There’s the invulnerability sphere, too, and it’s surrounded only by low-level zombies.

I’m not sure yet how well this worked out, but so far the handful of people who’ve played seem to have enjoyed it.

This is inside the black building seen on the right side in the previous screenshot. The entrance is blocked off until Hell emerges — another detail that makes sense as long as you don’t think about it too hard.

You come up a lift to see this revenant, with no obvious escape route; the lift doesn’t go back down. The crates are arranged to make navigation a little awkward.

This might be a bit mean. It used to be meaner, though completely by accident. I’m still unsure about it, but I do want it to be a little mean, just because there’s so much stuff up here: a decent chunk of health, a fresh blue armor, and quite a bit of ammo. Navigating a few surprise enemies in close and clumsy terrain is how you earn all that.

I love this little pile of crates that fell over. It also works as a staircase onto the large crate where those chaingunners are standing.

Not sure what happened to that front-most one; it seems to have lost its side textures somehow. The clip is also a little clumsy; you have to carefully drop between the small crates to actually pick it up.

Behind the crate from which the others were knocked is this glaringly incongruous switch, which lowers a glaringly misaligned wall on the other side of the room. If you charge through this room and immediately drop through the window the chaingunners are looking through, you’ll probably miss the switch. If you take just a moment to glance around, it’s a bit hard to miss the bright blue texture in the middle of a sea of browns and grays.

This secret is a combination of a few factors. I wanted to have a more clearly-telegraphed secret, after watching a playtester miss the megasphere twice, even after going behind the portal and pressing on the (wrong) wall. I wanted to have a significant reward for exploring this building, which is completely optional. I wanted to have a low-pressure “timed” secret, where you had to find and enter an area in a short amount of time — though the window here is fairly generous, and it’s easy enough to go press the switch again if you don’t make it. And finally, I just needed some way for the player to get out of the gap between those crates and the wall.

Only the middle sector is actually flagged as secret, so if you don’t pick up the bulk cell, you might not get credit for this secret. I originally had the outermost dark ring as the secret one, but then I watched someone run into the room at top speed, and they moved so quickly over the skinny ring that they didn’t get credit (again)! I figure pretty much everyone will grab that bulk cell.

Our old alleyway sure looks different now!

This is the only mid-air portal in the map, which honestly feels like a missed opportunity, but oh well. You have to come running out of the back of the portal to reach that alcove, which looks barren — but on the other side of the street (through the portal) is a shootable switch that leads to another secret stockpile.

I like everything about this shot. The inverted cross, the altars, the bloodfalls, the “congregation” of imps. I used the red skull “lock” texture as the door track on a whim; it seemed like the kind of bizarre thing Sandy might do.

The interior of the cathedral is one of the last areas I created. I was originally going to make it another optional area, but it didn’t sit right with me that if you knew exactly what you were doing, you could come out of the apartment buildings and skip the entire city in about one second. (You’ll see how in a moment.)

I get the impression that modders also love railroading. You might start to notice it if you play enough Mario Maker; you’ll think you have a clever idea for getting around a small area, only to find that the author made a jump just barely too high or wide to work.

I don’t like that. I especially don’t like when it happens multiple times in the same level, or even the same area. I like exploring in games, and I value that delicate middle ground where I feel like I’ve been clever but the designer rewards me for it anyway. If it’s glaringly obvious that the designer has slapped on multiple bandaids to force me to do this One Thing They Think Is Really Important, the illusion that I’m exploring an incidental world is ruined.

On the other hand, if you can walk right past this entire huge massive outdoor arena in about five steps, why did I bother building it in the first place? I decided to compromise a bit and introduce the only key in the map. You need it to progress, so you have to interact with the city a little, but you ultimately don’t have to go much further. Those barons in the back are meant to encourage you to run around gathering resources before tackling this room.

I’d originally intended not to use keys. Now that I was going back on that, I wanted something a little grandiose for the key, but this cathedral is rather small. Ah, good thing I have portals.

When you walk forwards, a portal opens and this “priest” comes through. There’s not really any cover in this room, so if you’re already hurting, you might be in for more hurting.

The cathedral door opens and closes pretty slowly, too… at least, on hard. It opens much more quickly on easy, giving you more time to heel-turn and bolt out of the room. I considered removing the arch-vile on easy, but decided against it because it serves a narrative purpose here.

I’m not a complete jerk, though. There’s one very quick, very conspicuous way to get out of the arch-vile’s line of sight, a way I’ve been trying to teach the player this entire time: just run through the portal.

Here’s my grandiose key grab. It’s ultimately pretty simple: haul ass over the lava and up the spiral stairs to get the key.

There are four revenants in all, and the only real cover is the spiral stairs themselves. It happened to work out so that if you just run for it, you can get behind the stairs just before any of the rockets hit you, and then you can grab the key and run back without taking any damage. Of course, if you’re after 100% kills, this room might be a little difficult. But again, you have the portal at your disposal.

If you look at the automap, you might notice that the four revenant towers and the key are arranged at the five points of a pentagram.

On medium difficulty, there are only two revenants. On easy difficulty, there are four imps instead.

All of the portals in the city streets lead here. I love this room. I think of it as the focal point of the map. It’s almost a shame that it comes so late.

Again, this doesn’t make too much sense if you think about it. How did all those enemies fit in here? The arachnotrons alone would fill the space. I don’t think of this room as a literal shape of the space, or even a space that could literally exist — it’s a small slice of nowhere, floating in the void, that only exists because all of these portals happen to intersect here.

There are eight portals, eight pillars, and four different light sources to help you orient yourself. I put a lot of effort into the textures and the lighting on the pillars, too. At first I tried having the room literally float in the void — or at least, in an endless sea of lava beneath a hellish sky — but the impact of the portals is much more powerful with darkness behind them.

Seven of the portals lead back into the city. They’re arranged in roughly the same order in this nexus as in the city, mostly because I placed the city portals clockwise around the perimeter. One portal, to the left of that white tech lamp, leads somewhere new. That’s why I felt the need to add the red key: if you knew the map, all you had to do after leaving the apartment building was charge directly into the nearby portal to get to the nexus, then take the only portal that doesn’t lead back to the city.

Techbase

This is the home stretch. You need the red key to open that blast door.

There’s another secret behind the portal you arrive through, the third or fourth such secret. Unfortunately, the hallway bulges around the portal, and you can walk right around it. I added the bulge after someone managed to get themselves stuck in the wall after walking through the very edge of the portal, but I guess I overdid it! I’ll fix that before the final DUMP release.

This area, and in particular this shot, is the weakest of the map by far. It’s pretty gray and barren and indistinct. I might spruce it up a bit in the next couple days.

More important is what this does to the story. You’ve been passing through portals that connect Hell to a (now corrupted) city. The portals have always been opened from the Hell side, suggesting an invasion on their part.

But now, what’s this? One of them connects to this distant UAC base. Does this mean that the UAC is the original source of the portals, or that Hell is invading the base at the same time? I guess that’s up to you.

One of the Doom Mixtape videos mentions that almost every Doom megawad follows the same progression as Doom II — techbase, city, Hell — and that reversing that progression is much more interesting. I’ve basically done that here. You do start in the city, but it’s only a brief jaunt until you reach Hell. Alas, the reason the reverse progression is interesting is that it means the Hell levels are smaller and simpler whereas the techbase levels are large and sprawling, and I haven’t done that at all! This techbase area is fairly short and straightforward.

You may notice another use of 3D floors to make a hallway that passes under a platform. I watched some Let’s Plays of the original Quake some time ago, keeping an eye out specifically for where true 3D made the level design more interesting, and this kind of small opening beneath a larger platform was one of the biggest things that stood out to me.

This is down the hallway and to the right. I put a little last-minute effort into decorating this area. It looks okay, but it’s a shame that most of the detail isn’t actually visible from the hallway that leads here. Oops.

Decorating tech areas is surprisingly difficult. Stock Doom only has a handful of computer textures, and there are only so many times you can stick a recessed screen in the wall before it gets old. I slapped both some computers and some recessed screens here, and then I ran out of ideas.

I like lifts with sides that aren’t solid textures, suggesting the presence of an actual mechanism that raises or lowers the lift. I think I later changed these support struts to something more technical.

This switch reveals a teleporter alcove on the other side of the room. I added the lowering struts after someone reported being confused about what the switch did. Not only do the lowering struts mirror the way the teleporter alcove opens, but you can actually see the teleporter from here.

Endgame

Here’s where the teleporter leads. This room might actually be more interesting than the previous one — it’s simple, but it also serves a very simple purpose, so it doesn’t need to be too fancy.

On the other side of those computers are two switches and an extremely fancy glowing platform. You can press the switches in either order — ooh, nonlinearity! The first causes a small quake and extends some struts from the floor; the second causes a much larger quake and opens a penultimate portal.

I originally wanted the first switch to also activate the fancy light effect, but I couldn’t make that work. I might be missing something, but it seems as though you can’t change a sector to start using one of the built-in lighting effects during runtime. The only alternative is to recreate the lighting effect entirely with scripting, which I didn’t really want to do.

I even more originally wanted the finale to more conclusively blame the UAC for the portals and ask the player to shut down a portal generator. I didn’t even begin to build it before I realized a number of problems: pressing a switch isn’t very dramatic, telegraphing what the player had actually done would be tricky, and I would have to either make the switch the exit (which obscures its narrative function) or have the exit be something else you do afterwards (which is clumsy). This approach is a lot more satisfying, both in its adherence to the portal theme and its adherence to Doom.

The finale!

My first crack at this just had a cyberdemon come through the portal. It felt a little anticlimactic to me, building this huge room only for a single enemy to emerge, but I didn’t have any better ideas.

Then someone played through the map and actually complained that they’d found so many secrets and accumulated so much ammo that “only” fighting one cyberdemon at the end was a bit of a letdown. I’m armed to the teeth; where’s the cannon fodder?

That gave me a great idea. The ending is now dependent on the difficulty and how many secrets you found. You get an initial “score” from 0 to 40 depending on your secret rate; there are 13 secrets, so about 3 points per secret. If you’re playing on medium, you get an extra 30 points; if you’re playing on hard, you get an extra 60 points. The maximum possible score is then 100, if you play on UV and manage to find everything.

Then, for each 41 points, you get a cyberdemon. For each 7 points after that, you get a baron. For every point remaining, you get five imps. And everyone gets ten extra imps just for playing.

The result is a small army charging through this portal after you, but roughly scaled to match how good you are at the game and how many resources you should have left. In case of emergency, there’s a little more ammo sprinkled around this room, but I really wanted you to be able to deal with the onslaught with whatever you had on you.

I love coming up with goofy ad-hoc algorithms like that, by the way. It’s a straightforward problem, but the requirements are completely arbitrary, so the algorithm can be equally arbitrary. I chose odd numbers like 41 and 7 so that they wouldn’t divide evenly into each other and create predictable behavior or obvious discontinuities in difficulty. 41 in particular was chosen because it ensures that someone playing on easy will never get a cyberdemon — the maximum possible score on easy is 40. On the other hand, someone playing on medium will get a cyberdemon just from finding a couple secrets, and someone playing on hard will always get at least one cyberdemon, and possibly two.

The most spectacular part by far is the imp horde. If you’ve found any secrets at all, you’ll probably get a couple dozen imps, and they just keep popping out one after the other. If you don’t start killing them immediately, they seem to fill the room — but they’re still relatively low-level monsters and not a serious threat. I really love the effect of having a seemingly-endless army pour into the room from some elsewhere.

I did break my own rule here. The monsters are actually spawned, rather than being nudged through the portal from the other side. (I still give them a nudge and play the portal sound, so the difference is very hard to notice.) The number of monsters varies depending on your own actions, so they have to be spawned. That does mean the monster count is inaccurate, but since these are the last monsters of the map, I think it’s excusable.

The first release candidate of this map had a hilarious bug. See, the Doom engine mostly handles fractional values with “fixed-point” numbers, which are integers that have a fixed number of digits reserved for the fractional part. Currency is a good example: we write $1.25, but what we really mean is 125 cents. It’s an integer with two decimal digits reserved for the fractional part. Doom’s fixed-point is similar — it uses 32-bit integers, with 16 of those bits reserved for the fractional part. 1.0 is thus represented as 65536 (which is 2¹⁶).

Fixed-point isn’t built into very many programming languages, so the Doom source code has to have its own functions for handling arithmetic correctly. Unfortunately, the scripting language inherited this fault, and is possibly worse about it — it only understands integers, and can’t distinguish between real integers and fixed-point values. All of this is to say that I did this to scale the proportion of secrets found to a score out of 40:

1	`int difficulty = FixedDiv(found * 1.0, total * 1.0) * 40;`

Seems reasonable enough. I want to divide the number of secrets found by the total number of secrets, but if I do it directly, it’ll just truncate to 0. So I multiply both values by 1.0 to make them fixed-point (the scripting language does understand that literal numbers with decimal points are fixed-points), then I use the FixedDiv function to perform a fixed-point division. Multiply by 40, and you have a score out of 40, right?

No, actually you have a score out of 40.0, because I never converted the result back to a regular integer. If you find one out of thirteen secrets, that’s 1.0 / 13.0 or 0.076923, times 40 is 3.076923. But remember, that’s really an integer being treated like it has decimal places, and the language can’t tell the difference. You have to multiply by 65536 to figure out the true value, which is 201649. And that’s your “score” for the finale. Divide by 41, and you will see that every secret you discover will cause an extra 4918 cyberdemons to be spawned in the ending. Oops!

I never noticed this because in my efforts to test the behavior of finding all secrets versus finding no secrets (without having to replay the entire map many times), I temporarily added a line like difficulty = 0; or difficulty = 40;. That replaced the bad result of the division and hid the bug. Double oops!

The fix was pretty easy. I want an integer in the end, so I don’t really need fixed-point numbers at all. If I do the division last, there’s no intermediate result less than 1 to be rounded into oblivion.

1	`int difficulty = 40 * found / total;`

Fixed. Alas, this fix didn’t make it into the first test release of DUMP 2, so a few people had a fun surprise.

Of course, even if you do find yourself facing down dozens of cyberdemons, there’s always one final tactic that you really should have picked up on after all the time you’ve spent in the map.

You can ignore all the monsters and run through the back of the portal.

Xen

It’s not really Xen, though it bears a certain resemblence.

I don’t know where or what this is. I wanted a denouement, a calm ending that whisks you away from these shattered spaces to whatever the next map is. I’m a huge fan of stuff floating in the void, so I made some stuff floating in the void.

I interpret this as being “outside”, whatever you might take that to mean. You’ve traversed so many portals and come so far that you’re well beyond Earth or Hell any more. You’re just out here with some debris. Nowhere.

There are no enemies here. No threats of any kind. Ths space exists purely for the atmosphere, so the platforming is as easy as I could make it — running straight from one platform to the next generally works, gravity has been reduced drastically, and missing a jump will quietly teleport you back to the first platform.

Touching that last massive portal will end the level.

Closing thoughts

I’m amazed I managed to build this in a week.

I’m also not without regrets! I didn’t make very effective use of lighting; there’s some, but it could be much improved. Hell is pretty nicely-realized, but the human areas (especially the base) tend a bit drab and bland; towards the end, I just completely ran out of ideas for what to sprinkle in them. Some of the details I do have are cliché and obvious; I’m much happier with the oddball touches like the “stage” in the stucco building and the bizarre whole-room light fixture in the apartments. Despite the resounding advice of “take inspiration from real places”, I did the best work when I managed to stop worrying about real places and just build stuff.

After I made the map, I learned about ZDoom’s sound environments, which add reverb to an area of the map. A couple other maps in DUMP 2 use them, and the effect is really quite impressive. I wish I’d known before, but maybe I can find time to insert some before the project ends.

I have a map set vaguely in progress that I work on from time to time, and I’ll adapt this to fit in there. One down, 31 to go!

Mario Maker: …

2016-03-08T19:29:00-08:00

14DC-0000-01ED-C104
Difficulty: fairly easy
Quality: ★★★★★
Secrets: —

…

I removed the music and only used monochrome obstacles, with very few actual enemies. No pickups, no secrets. It’s short, linear, pretty easy, entirely thematic.

The result is interesting.

Mario Maker: The Works

2016-01-17T12:13:00-08:00

ACD6-0000-0198-668D
Difficulty: fairly easy
Quality: ★★★★★
Secrets: 🍄🍄🍄🍄🍄🍄

This is great. I put a lot of effort into polishing it. I even set it aside for a while because I wasn’t happy with it, then came back and fixed it.

It’s fairly long, but doesn’t have any particularly tricky parts. Pretty atmospheric, I hope. Not all of the 1-ups are hidden, and not all of the hidden details are 1-ups.

I don’t even want to say anything more about it; I feel like I’ll ruin it. Just play it.