fuzzy notepad

Atom feed [blog] blog

[blog] You should make a Doom level, part 3: cheating

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.

[blog] You should make a Doom level, part 2: design

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.)

[blog] You should make a Doom level, part 1: the basics

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.

[blog] ZDoom on a Wii U GamePad with a Raspberry Pi

Well. That was the idea, anyway. SPOILERS: It didn’t work.

Vladimir Costescu has upped the ante and bought a day of my time this month, requesting:

It would be cool to read about you tinkering with a Raspberry Pi or similar cheap device and trying to get it to do cool stuff (where “cool stuff” is left up to your discretion).

Well it just so happens that I already have a Raspberry Pi. I got it at PyCon US, I think three years ago, when they gave every single attendee a Pi for free. I thought it was super duper cool and I spent a whole afternoon tinkering in their Raspberry Pi lab and then I came home and put it in a drawer forever because I had no idea what to use it for.

At first I thought it would be cool to rig something that would download a random wad from idgames (like vectorpoem‘s WADINFO.TXT) and just launch it and let you play it. A teeny tiny portable Doom box.

Then I realized you’d still need a mouse and keyboard (well, at least a keyboard) to actually play, which is a little bit more cumbersome and detracts from the portability a bit.

But I remembered hearing about a Linux-only project that had managed to interface with the Wii U GamePad. Run ZDoom on a light wireless controller with gyros and everything? That sounds awesome.

So off I went.

[blog] Undertale

Undertale is a very good game.

So you should play it, because I am about to spoil the hell out of it.

No, really. Don’t read this if you haven’t played the game. It won’t even make sense. I’m reflecting on it, so I’m not gonna bother explaining stuff you would know if you’d seen the ending(s).

This is a heavily story-based game. Dissecting the plot without playing it will not entertain you and may ruin your enjoyment of the game later. I’m not kidding.

Okay then.

[blog] The tech diversity blind spot

Twitter recently lost its only black engineer in a management role.

The top-voted comment about this story on Hacker News begins thusly (emphasis mine):

I’ve been working for over 20 years in tech at 10+ different companies around the Valley, and I can count on 1 hand the number of direct coworkers that were black, and on 2 hands the number of coworkers that I indirectly worked with that were black.

I don’t believe this is due to any sort of racism, but rather due to the education system in general. Trying to solve the diversity issue at the hiring end, when the number of qualified candidates is so small, is not the right way to solve the problem. The only way you will hit higher-than-normal diversity numbers is to reduce hiring standards, which is wrong.

This is an interesting thing to say (and upvote) when the article itself said the exact opposite:

In the course of the meeting, [the VP of Engineering] suggests that we begin tracking the ethnicity of potential candidates in the pipeline to understand better where candidates are falling out. I agreed that this is an important metric to track and conveyed that the current data we had indicated that the problem is not just the pipeline. While ethnic and gender data early in the pipeline is incomplete, we do know that in 2013, 4.5% of CS graduates from the top 25 schools were African-American, and 6.5% were Hispanic/Latino.

A chart in the article indicates that in 2014, Twitter’s tech employee population was 1% black and 3% Hispanic.

[blog] Internet novelty: testing personality

This month, Vladimir Costescu has requested (with dollars):

For this month’s funded post, I’d like to see you write about personality typing, with an emphasis on Myers-Briggs / Jungian typology. This means I’d like to see you write mostly about MBTI and dig a bit into cognitive stack theory, but if you happen to have tidbits of knowledge about other methodologies (e.g. Big Five, Enneagram, etc.) already in your mental data banks, it would be cool to hear about them too.

Don’t worry: I don’t know anything about cognitive stack theory, or even what that means. But that’s never stopped me before!

[blog] Copyright is broken

Undertale is a fantastic game. I might even write about it sometime. But not right now.

See, Undertale’s creator said a few weeks ago that taking Undertale commissions is fine, but selling unofficial merch is not. I said yesterday that I think this is kind of uncool, and I was somewhat surprised to get half a dozen people instantly disagreeing with me for various reasons. I thought about this a lot in the shower, and here are some words.

First let me clarify why I think this is uncool. The merchandise I had in mind was buttons and stickers and prints and other physical incarnations of art. You see this kind of stuff sold rather a lot at anime conventions, because it works really well — it combines a popular subject with unique custom artwork. Commissions are all well and good, but they don’t pay very well and there’s a physical limit on how many a single person can do. It’s much more efficient to put more time into a smaller number of things with broad appeal, then sell them as physical objects to a greater number of people.

That’s what I see being disallowed here. Someone could pour days or even weeks into a beautiful illustration, and then not be able to sell it — to be compensated for their hard work. Meanwhile, the free spread of that same illustration online helps keep the source material popular, fueling more sales of the game.

Some people said, well, he might want to sell his own merchandise. My kneejerk reaction is that maybe he should get on that then? He even had a head start, seeing as he knew everything about the game long before it was released. My second kneejerk reaction is that I really doubt artwork competes with itself as strongly as direct copies might; there are plenty of people who will gladly buy many different depictions of the same thing. There’s a cap on how much a given person can spend, sure, but official merch is always wildly popular and I can’t see it seriously being cannibalized by a few indie keychains.

But the more I thought about this, the more I started to wonder: why do we even take for granted that he should have a monopoly on merchandise?

[blog] Fair warning: minor restructuring ahead

I started using Tumblr some time ago to publish sporadic shorter writing, as a way to combat the feeling that everything I wrote in this “real blog” had to be long and semi-formal. The short writing more or less migrated to Twitter, but Tumblr remained for some community-specific griping. When I started learning to draw, it was an obvious place to stick my doodles as well.

But Tumblr is a frustrating platform that I’ve never found myself particularly enjoying. Plus, it seems a shame to have this amazing domain hack and only use it for one kind of thing.

So I’m going to try expanding the purview of my tiny platform. Pelican isn’t quite designed for this, but I’m going to turn its concept of “categories” into more like content types, whatever that ends up meaning. “Blog” is now its own category; I’ve put all my old posts in it and will put other long-form writing in it in the future. (I also cleaned up the tags I use, merged the old categories into tags, and hid single-use tags from the sidebar.)

I haven’t decided exactly what else will go here yet. Posting art is an obvious start, and I might even backfill all my doodles since I started drawing in January. I might write some shorter and more “disposable” things. I might write short updates on particular projects. I might post tons of cat photos, and backfill those too. I might try keeping a “dev journal”, where every single day I write a quick paragraph or two about what I did.

I mention this mainly as a heads up to any techies who’re following via the feed. If you want to see anything and everything I publish, it’ll all be in the same global Atom feed, so you don’t need to do anything. If you only want to follow my blog, there should be a new feed just for blog posts. Every category gets its own feed, so you can also mix and match as you please, once I get some other categories started.

Are you excited? I’m excited.

[blog] Next steps for beginning programmers

Last month @zandrmartin asked me on Twitter:

i would love to read a post about things you would recommend newish programmers learn, esp those coming from a php web background

not even tutorials as such, just like ‘you should learn about x and how to implement it effectively’ would be great

like when you were talking about bit masks a while back, i have no idea what those are or why you’d use them, but i want to

I’ve opined on this sort of thing briefly in various impermanent places, but somehow never tried to consolidate it at all. So here you go, some stream of consciousness on being more better at computers.

[blog] My search history is now full of illegal drug terms

Someone has generously pledged a pile of money and asked me to write about the War on Drugs. Preliminary research reveals that this is not actually anything to do with programming, which confuses and bewilders me, but I’ll give it a try anyway.

My gut reaction is to say “it’s bad”, on the basis of victimless crime and right to private action and all that, but that doesn’t make for a very interesting post, and there are plenty of thinkpieces along those lines anyway. I’ll try to do a teeny bit of research, so I’m not just paraphrasing Wikipedia.

[blog] Dark corners of Unicode

I’m assuming, if you are on the Internet and reading kind of a nerdy blog, that you know what Unicode is. At the very least, you have a very general understanding of it — maybe “it’s what gives us emoji”.

That’s about as far as most people’s understanding extends, in my experience, even among programmers. And that’s a tragedy, because Unicode has a lot of… ah, depth to it. Not to say that Unicode is a terrible disaster — more that human language is a terrible disaster, and anything with the lofty goals of representing all of it is going to have some wrinkles.

So here is a collection of curiosities I’ve encountered in dealing with Unicode that you generally only find out about through experience. Enjoy.

Also, I strongly recommend you install the Symbola font, which contains basic glyphs for a vast number of characters. They may not be pretty, but they’re better than seeing the infamous Unicode lego.

[blog] Security through misanthropy

I love programming. It’s like playing with Lego — here are some blocks, see what you can build with them.

That sounds a bit less impressive now, but when I was a kid walking uphill both ways, I only had a very generic Lego set where all the pieces were cuboids. If I wanted to build a house with a sloped roof, well, that was too bad. I could cheat a little, though, by making several layers in a terrace pattern. It wasn’t actually sloped, but it did the job well enough by making creative use of the tools I had within the constraints I was given. You might call it a hack.

Self-identified hackers will often lament how “hack” now has two meanings and everyone assumes the wrong one. I think there’s really only one meaning, and the “break into computers” sense is a special case. It’s not like breaking into a system is magic, or done by running hack.exe; it’s just a creative use of the tools you have within the constraints you’re given. Like when the constraint is “your username is placed in a string of SQL” and you decide to place a couple quotation marks in your username.

So I’m always a little surprised when programmers don’t get security issues or how to defend against them, because to me, it requires exactly the same mindset as programming. And I suspect the problem is a quiet assumption most people tend to make: no one is that much of an asshole.

That’s not entirely unreasonable. Every stranger you pass on the street could be a hired assassin, but that’s fairly unlikely, and we have punishments to discourage that sort of thing. Ultimately we have to have some level of trust in other people in order to be around them at all.

And yet.