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.

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.

It’s been a while, but someone’s back on the Patreon blog topic tier! IndustrialRobot asks:

What does your personal utopia look like? Do you think we (as mankind) can achieve it? Why/why not?

Hm.

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.

I’ve now made a few small games. One of the trickiest and most interesting parts of designing them has been making them accessible.

I mean that in a very general and literal sense. I want as many people as possible to experience as much of my games as possible. Finding and clearing out unnecessary hurdles can be hard, but every one I leave risks losing a bunch of players who can’t or won’t clear it.

I’ve noticed three major categories of hurdle, all of them full of tradeoffs. Difficulty is what makes a game challenging, but if a player can’t get past a certain point, they can never see the rest of the game. Depth is great, but not everyone has 80 hours to pour into a game, and it’s tough to spend weeks of dev time on stuff most people won’t see. Distribution is a question of who can even get your game in the first place.

Here are some thoughts.

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.

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.

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.

On January 1, 2015, I started learning to draw.

I’d made a couple brief attempts before, but nothing very serious. I’d eyeballed some official Pokémon artwork on two occasions, and that was pretty much it. I’d been dating an artist for seven years and had been surrounded by artist friends for nearly half my life, but I’d never taken a real crack at it myself.

On some level, I didn’t believe I could. It seemed so far outside the range of things I was already any good at. I’m into programming and math and computers and puzzles; aesthetics are way on the opposite end of a spectrum that only exists inside my head. Is it possible to bridge that huge, imaginary gap? Is it even allowed? (Spoilers: totally.)

In the ensuing sixteen months, a lot of people have — repeatedly — expressed surprise at how fast I’ve improved. I’ve then — repeatedly — expressed surprise at this surprise, because I don’t feel like I’m doing anything particularly special. I don’t have any yardstick for measuring artistic improvement speed; the artists I’ve known have always been drawing for years by the time I first met them. Plenty of people start drawing in childhood; not so many start at 27.

On the other hand, I do have 15 years’ experience of being alright at a thing. I suspect, in that time, I’ve picked up a different kind of skill that’s undervalued, invaluable, and conspicuously lacking from any curriculum: how to learn!

I don’t claim to be great at art, or even necessarily great at learning, but here are some things I’ve noticed myself doing. I hope that writing this down will, at the very least, help me turn it into a more deliberate and efficient process — rather than the bumbling accident it’s been so far.

Part 1: the basics · Part 2: design · Part 3: cheating

Tens of thousands of words later, you’ve watched me build a little world, and hopefully tried building your own. All the way we’ve had to deal with Doom’s limitations. Flat surfaces. No room over room. The world can only move vertically. The only tool we’ve found so far that can get around those restrictions is the sky hack, and even that’s fairly limited.

I’ve saved this for last because it’s more complicated than anything else, by far. It also finally, utterly, breaks compatibility with vanilla Doom. You could apply everything I’ve said so far to vanilla with some tweaking — use line types instead of specials, make a Doom-format map, skip the separate light levels and other tricks. But, this, all of this, is very much ZDoom only.

Finally, the time has come.

It’s time to annihilate all of those restrictions.

Mostly.

Part 1: the basics · Part 2: design · Part 3: cheating

I assume you’ve read the introduction, which tells you the basics of putting a world together.

This post is more narrative than mechanical; it’s a tour of my thought process as I try to turn my previous map into something a little more fun to play. I still touch on new editing things I do, but honestly, you already know the bulk of how to use an editor. Poke through SLADE’s keybindings (Edit → Preferences → Input) to see what hidden gems it has, click that “Show All” checkbox in the prop panel, and go wild. But please do comment if I blatantly forgot to explain something new.

(Fair warning: NVidia’s recent Linux drivers seem to have a bug that spontaneously crashes programs using OpenGL. SLADE is one such program. So if any of the screenshots seem to be slightly inconsistent, it’s probably because the editor crashed and I had to redo some work and it didn’t come out exactly the same.)

Part 1: the basics · Part 2: design · Part 3: cheating

I love Doom. Or, well, I love Doom 2, which is the game we actually had when I was nostalgia years old.

I love the aesthetic — pixely in a 3D(ish) environment, and consistent in a way that meshes together really well. The classic levels are abstract (occasionally too abstract), but still detailed enough to feel like they could represent real places as long as you don’t think about it too hard. The environment is surprisingly dynamic: there are switches and devices everywhere. That seems to have gotten much rarer over time, as climbing polygon counts have required ever-heavier optimizations on environments, which make it harder to move at runtime.

Plus the engine is really simple, so mapping is really simple, and anyone can make a little world they can then move around in and share with others.

And I think that’s fantastic. Everyone should try making games. They’re a great medium, a way to express nearly any kind of creative idea, no matter what your interests. If you like music (Audiosurf), or art (BECOME A GREAT ARTIST IN JUST 10 SECONDS), or storytelling (Photopia), or programming (TIS-100), or puzzles, or human interaction, or ANYTHING, you can probably find a way to express it with a game. You don’t need to be good at everything. You can focus on one thing, or you can focus on everything, or you can pair up with people who have very different interests. A lot of the existing tools are aimed at programming types (probably since they’re all made by programming types), but they’re only getting better over time.

And what better way to get your feet wet than one of the oldest forms of homebrew game development: Doom modding.

I thought I’d try something different this month, especially because I keep writing ludicrously long posts (I say, as if this one were any better), and also this month I’m trying to focus on an intersection of gamedev and writing, and also it’s Christmas (???). So here is part 1 of a three-part series on how to build you a world.

Sketch is still buying days of my time, which is super cool of him. Continuing from last month, he asked that I make it possible to disable normal editing and only accept proposals on the wiki.

After some internal debate about how to add a real configuration system, I realized this could just be expressed with permissions, so I wrote some little permissions UI. And actually added them to the proposal code. Which is good.

I wanted to have a nice way to iterate all possible permissions from whatever plugins are currently active, but the way permissions work right now is kind of fucked up anyway, so in the end I just hardcoded a list of existing permissions. Oh, well. I’ll get around to it.

Also I added CSRF protection everywhere. Whoops. Like I said, spline is still lacking in a lot of niceties, such as “being ready for production use”. But it’s getting there, one architecture astronauting session at a time.

While I was in there I finally added UI so Glip can attach videos and cutscenes to Floraverse pages without my intervention. It was pretty easy and I don’t know why I subjected myself to messing with the db manually for so long.

This isn’t very long or exciting; it was my project and I knew what I was doing, and there was a lot of pondering involved, and I don’t have anything to complain about.

---

Which is why I’m using it to start off a dev log, containing shorter posts about things I have done that don’t merit some deep dive into obscure technology. I also started keeping a notebook (a real, physical notebook) for jotting down stuff I do every day, and maybe I’ll summarize it once a week or so. I’ll also post about little “releases” like Mario Maker levels. In fact I might go make backdated posts for all the levels I’ve made so far.

Remember, if you’re following via the Atom feed and only want to see the blog, there’s a feed with only blog posts.

I’m not sure what this means for the projects page, which has always been kind of a mess. It’s also annoying that you can’t easily filter by project, because they’re just tags, and it’s not obvious which tags are projects. I’ll figure this out as I go, I suppose.

Sketch bought a day of my time this month (and, er, last month) to work on adding “pull requests” to a git-backed wiki. I picked spline, because, uh, I wrote it.

Don’t use pickle. Don’t use pickle. Don’t use pickle.

The problems with Python’s pickle module are extensively documented (and repeated). It’s unsafe by default: untrusted pickles can execute arbitrary Python code. Its automatic, magical behavior shackles you to the internals of your classes in non-obvious ways. You can’t even easily tell which classes are baked forever into your pickles. Once a pickle breaks, figuring out why and where and how to fix it is an utter nightmare.

Don’t use pickle.

So we keep saying. But people keep using pickle. Because we don’t offer any real alternatives. Oops.

You can fix pickle, of course, by writing a bunch of __setstate__ and __reduce_ex__ methods, and maybe using the copyreg module that you didn’t know existed, and oops that didn’t work, and it’s trial and error figuring out which types you actually need to write this code for, and all you have to do is overlook one type and all your rigor was for nothing.

What about PyYAML? Oops, same problems: it’s dangerous by default, it shackles you to your class internals, it’s possible to be rigorous but hard to enforce it.

Okay, how about that thing Alex Gaynor told me to do at PyCon, where I write custom load and dump methods on my classes that just spit out JSON? Sure, you can do that. But if you want to serialize a nested object, then you have to manually call dump on it, and it has to not do the JSON dumping itself. There’s also the slight disadvantage that all the knowledge about what the data means is locked in your application, in code — if all you have to look at is the JSON itself, there’s no metadata besides “version”. You can’t even tell if your codebase can still load a document without, well, just trying to load it. We’re really talking about rolling ad-hoc data formats here, so I think that’s a shame.

But I have good news: I have solved all of your problems.

I bought Super Mario Maker a few days ago. I was a little iffy on blowing $60 on a level editor, but I really like level editors, so here we are.

This is a story of how nothing in this story is my fault.

I’ve got a coworker who’s super into Clojure, a Lisp-like that runs on the JVM. In particular he’s super into how it’s got notions of mutability (and, thus, immutability) all throughout.

More than once he’s lamented that Python lacks a frozendict—a dictionary type that can’t be changed. Dictionaries tend to crop up a lot in Python, and in a very large codebase, it’s very easy to end up with this scenario:

1. Some function somewhere generates a dict that’s only used by one caller. The interface is obvious since the keys and values are created right there in one place. No problem.
2. Other code comes along, notices this handy function, and starts using its return value. Some of this code may pass the ad-hoc dict up to callers, too.
3. Some of that other code needs more things added to the dict, but computing the extra data is expensive, so arguments are added to the function that optionally turn on certain keys.
4. Some code needs even more things added to the dict that are outside the purview of the original function, so they add helper functions that take the ad-hoc dict and add more things to it.
5. Since this has all now happened multiple times throughout your codebase, someone addresses the problem by writing adapter code that infers the original dict from some other object describing its structure, thus saving everyone from writing all these functions that return dicts.

A lovely spaghetti dinner. It’s now nigh impossible to trace what the dict contains or where half of it came from.

Returning an object in the first place would have avoided much of this, but when you’re sitting at step 1, that seems like a lot of effort just to return half a dozen things from a function you wrote to another function you wrote. Swapping out dict() for frozendict() is easy.

My opinion on frozendict had never grown stronger than “I guess that would be cool”, so I never sat down and wrote the class, and there must be enough subtleties that nobody else at Yelp has either.

Then today, PEP 416 came to my attention. This PEP proposed adding a frozendict type, but was rejected last year as being largely unnecessary. What’s interesting about it is that the rejection ends with almost a footnote suggesting that perhaps dictproxy ought to be exposed to Python-land, instead. And indeed this was done, and it exists in Python 3.3.

Mel, Jayson, and I are attempting to construct a game called Flora. It seems obvious now that we’ve actually started: between us we have the pixels, the words, and the binaries. That’s everything right there.

I could blather about my adventures figuring out how to make OpenGL do anything useful, but who the hell cares. Far more interesting is the adventure of figuring out what the game actually is.

We have a pretty simple approach here: we’ve each played some decent set of video games, and we each have unreasonably strong opinions about what was good or bad. All we have to do is make a game with all the good stuff and none of the bad stuff. Done. Ship it.

The big picture

The game revolves around Mel’s fictional universe, populated by all manner of colorful critters. The protagonists and namesakes are flowercats, so named because they are flowers with cats growing out of their stems.

It’s a top-down role-playing adventure, except everyone has a different idea of what that means, so let’s say it’s roughly the same style of game as Link’s Awakening. Turns out all three of us like adventuring: exploring a world, feeling like part of it, discovering secrets, finding teases of the plot, and hitting stuff. Luckily, the main characters are into the same kinds of stuff, so we’re off to a good start there.

The theme is turning out to be “elements”: both of nature (earth, fire, etc.) and of gameplay itself. We keep finding ways that distinct focus on each of exploration, puzzles, and combat seems appropriate. Possibly because each of us has a different favorite of the three.

Balance

Which brings me to the tricky bit: finding a middle ground between what we like and what drives us fucking bonkers.

• Good: Exploring a wide, open world. Bad: Calling GTA4 a “wide, open world”. Backtracking like crazy. Fast-travel that makes you never see the world. A map that, paradoxically, doesn’t show you where anything is or how to get to it.
• Good: Unlocking new ways to move through the environment. Bad: Realizing you don’t remember the ten places you saw an obstacle that you can now pass.
• Good: Collecting stuff. Bad: Being forced to collect the same worthless plot items to progress. Collection that doesn’t actually lead anywhere. Collection you don’t have a prayer of finishing until you’ve otherwised finished the game, thus turning it into a lame “post-game”.
• Good: A populated world. Bad: NPCs who walk back and forth their entire lives and only say one thing to you. A quantum world that seems to pause while you’re not around to look at it.
• Good: Multiple ways to defeat obstacles. Bad: Letting the player skip an obstacle with no punishment. Fallout 3.
• Good: A sense of progression. Bad: Screenfuls of stats that don’t seem to mean anything or change predictably. Huge numbers of stat-changing options. Minmaxing.
• Good: Novel puzzles that instill a sense of accomplishment when solved. Bad: Puzzles the game solves for you. Puzzles that are afraid to be difficult. Puzzles that rely on the author’s perspective. Puzzles that you can opt to skip, thus making solving it a complete waste of time.

Avoiding the bad is going to be tricky, to say the least. Some of these plague virtually every game because it’s just damn hard to do anything else. Still, I have every confidence that we are uniquely suited to avoid pitfalls that the biggest and most successful game development studios have yet to subvert. Cause we’re awesome.

Status

So far we have one sprite drawn, and I’ve built an engine that lets it walk around a fixed region. (Spot the programmer art.) Basically done! I guess I’m building it half-from-scratch: I’m using pyglet and cocos2d, which provide a lot of basic niceties like event handling and layering and transformation and actions over time, but they’re both simple enough that I can easily understand everything they’re doing and could replicate it with a gun to my head. It’s the same kind of sweet spot as Pyramid is for Web development.

We have a Large Pad with tons of small ideas scribbled on it, and we brainstorm every other day. Currently trying to pin down how combat and advancement will work; there are a ton of options and getting it right is tricky. As the engine becomes useful, we’ll be able to actually try stuff out.

This is a side project among side projects for all of us, completely unfunded, with no deadline. So there’s no ETA, and we’ll just work on it as we feel inspired to do so. Interest is always interesting, of course.

The code is ISC and the assets are CC BY-NC-SA. All of it lives on GitHub. We’d still like to sell the completed game, but the plan is to only charge for the installer. (Oh, right: I develop on Linux (who doesn’t!) and it’s all Python and OpenGL, so it oughta run on pretty much anything.)

Yep, that’s all I got. May write about bits of it in more detail later, if there be interest.

floof does not, as of yet, support deleting artwork. It’s not exactly a high priority for getting an art site off the ground; we need to facilitate creating content before removing it is even a thing to be done.

Recently, I keep returning to the question of whether deletion should even be supported at all.

I hear complaints about this all the time on FA: people move accounts, people “clean up” their old art (what?), people just up and decide to leave and remove all traces of themselves in the process. Suddenly, a lot of people have tons of gaps in their favorites, with no trace of what used to be there or why.

Now, obviously part of this is purely technical: it’s easy enough to let favoriters know what’s been removed, and those gaps shouldn’t really exist in the first place.

But then, my whole philosophy so far has been about compromise. There are sites where producers have all the power, and sites where consumers have all the power, but not really anywhere that tries to appeal to both sides, and that’s the niche I’m either inventing or filling.

Consider a wiki: when you write an article, you’re creating something. The article is your prose, created by you, copyright to you. Yet nobody leaving a wiki project would think to delete all the articles they’d written in the process; the very idea is absurd, because we hardly even acknowledge that the individual writing itself is an individual creation. The project is the wiki itself, created by everybody and owned by nobody.

So can an art site do this? Can the site itself function as that kind of singular project, with individual artwork acting as mere contributions to the whole? I’ve always had the inkling that public art sites are for sharing the art, and features like disabling comments or restricting viewing ability run contrary to that goal; this is the same kind of idea taken to a further extreme.

I’m still not sold on this myself; I feel like there’s some obvious use case I’m missing that would drive many artists away. But most of the problems I think of aren’t actually solved by deletion from a single art site, since most art ends up mirrored in untold dozens of archives and imageboards. The only real difference is that the artist doesn’t directly see that it’s going on.

The biggest hurdle won’t be with discouraging artists from deleting art they upload. It’ll be discouraging artists from uploading art they might want to delete in the first place. If you don’t well and truly want to share it, then you probably just shouldn’t. This is a tricky problem; if the site resembles deviantArt-style sites, it’ll be easy to assume that it works the same way. Big scary warnings are helpful, but “no deletion” sounds more like lazy development than a nod to the subtle philosophy I’m gradually figuring out here.

I don’t know. Are you interested? Are you an artist? Am I crazy?

Addenda: Some things that were mentioned to me:

1. Wikis tend to require that you (often passively) license your contribution under a free documentation license or similar. I doubt that would be amenable to everyone, but at the very least we’d need something granting permission to display the work indefinitely.

2. One comment implied allowing an artist to remove art from his/her gallery without actually deleting it from the site. This is actually kind of interesting, and hints at another problem I haven’t much thought about: some artists let commissioners upload purchased work, but don’t bother to upload the works themselves. If “your gallery” is just all the art tagged as being created by you, how can we handle that?