Tag Archives: making things

I entered Ludum Dare 36

Post Syndicated from Eevee original https://eev.ee/blog/2016/08/29/i-entered-ludum-dare-36/

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.

Isaac's Descent

But wait! Read on a bit first.


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—



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.


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.


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.


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.

Notes on that StJude/MuddyWatters/MedSec thing

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/08/notes-on-that-stjudemuddywattersmedsec.html

I thought I’d write up some notes on the StJude/MedSec/MuddyWaters affair. Some references: [1] [2] [3] [4].

The story so far

tl;dr: hackers drop 0day on medical device company hoping to profit by shorting their stock

St Jude Medical (STJ) is one of the largest providers of pacemakers (aka. cardiac devices) in the country, around ~$2.5 billion in revenue, which accounts for about half their business. They provide “smart” pacemakers with an on-board computer that talks via radio-waves to a nearby monitor that records the functioning of the device (and health data). That monitor, “[email protected]“, then talks back up to St Jude (via phone lines, 3G cell phone, or wifi). Pretty much all pacemakers work that way (my father’s does, although his is from a different vendor).

MedSec is a bunch of cybersecurity researchers (white-hat hackers) who have been investigating medical devices. In theory, their primary business is to sell their services to medical device companies, to help companies secure their devices. Their CEO is Justine Bone, a long-time white-hat hacker. Despite Muddy Waters garbling the research, there’s no reason to doubt that there’s quality research underlying all this.

Muddy Waters is an investment company known for investigating companies, finding problems like accounting fraud, and profiting by shorting the stock of misbehaving companies.

Apparently, MedSec did a survey of many pacemaker manufacturers, chose the one with the most cybersecurity problems, and went to Muddy Waters with their findings, asking for a share of the profits Muddy Waters got from shorting the stock.

Muddy Waters published their findings in [1] above. St Jude published their response in [2] above. They are both highly dishonest. I point that out because people want to discuss the ethics of using 0day to short stock when we should talk about the ethics of lying.

“Why you should sell the stock” [finance issues]

In this section, I try to briefly summarize Muddy Water’s argument why St Jude’s stock will drop. I’m not an expert in this area (though I do a bunch of investment), but they do seem flimsy to me.
Muddy Water’s argument is that these pacemakers are half of St Jude’s business, and that fixing them will first require recalling them all, then take another 2 year to fix, during which time they can’t be selling pacemakers. Much of the Muddy Waters paper is taken up explaining this, citing similar medical cases, and so on.
If at all true, and if the cybersecurity claims hold up, then yes, this would be good reason to short the stock. However, I suspect they aren’t true — and they are simply trying to scare people about long-term consequences allowing Muddy Waters to profit in the short term.
@selenakyle on Twitter suggests this interest document [4] about market-solutions to vuln-disclosure, if you are interested in this angle of things.
Update from @lippard: Abbot Labs agreed in April to buy St Jude at $85 a share (when St Jude’s stock was $60/share). Presumable, for this Muddy Waters attack on St Jude’s stock price to profit from anything more than a really short term stock drop (like dumping their short position today), Muddy Waters would have believe this effort will cause Abbot Labs to walk away from the deal. Normally, there are penalties for doing so, but material things like massive vulnerabilities in a product should allow Abbot Labs to walk away without penalties.

The 0day being dropped

Well, they didn’t actually drop 0day as such, just claims that 0day exists — that it’s been “demonstrated”. Reading through their document a few times, I’ve created a list of the 0day they found, to the granularity that one would expect from CVE numbers (CVE is group within the Department of Homeland security that assigns standard reference numbers to discovered vulnerabilities).

The first two, which can kill somebody, are the salient ones. The others are more normal cybersecurity issues, and may be of concern because they can leak HIPAA-protected info.

CVE-2016-xxxx: Pacemaker can be crashed, leading to death
Within a reasonable distance (under 50 feet) over several hours, pounding the pacemaker with malformed packets (either from an SDR or a hacked version of the [email protected] monitor), the pacemaker can crash. Sometimes such crashes will brick the device, other times put it into a state that may kill the patient by zapping the heart too quickly.

CVE-2016-xxxx: Pacemaker power can be drained, leading to death
Within a reasonable distance (under 50 feet) over several days, the pacemaker’s power can slowly be drained at the rate of 3% per hour. While the user will receive a warning from their [email protected] monitoring device that the battery is getting low, it’s possible the battery may be fully depleted before they can get to a doctor for a replacement. A non-functioning pacemaker may lead to death.

CVE-2016-xxxx: Pacemaker uses unauthenticated/unencrypted RF protocol
The above two items are possible because there is no encryption nor authentication in the wireless protocol, allowing any evildoer access to the pacemaker device or the monitoring device.

CVE-2016-xxxx: [email protected] contained hard-coded credentials and SSH keys
The password to connect to the St Jude network is the same for all device, and thus easily reverse engineered.

CVE-2016-xxxx: local proximity wand not required
It’s unclear in the report, but it seems that most other products require a wand in local promixity (inches) in order to enable communication with the pacemaker. This seems like a requirement — otherwise, even with authentication, remote RF would be able to drain the device in the person’s chest.

So these are, as far as I can tell, the explicit bugs they outline. Unfortunately, none are described in detail. I don’t see enough detail for any of these to actually be assigned a CVE number. I’m being generous here, trying to describe them as such, giving them the benefit of the doubt, there’s enough weasel language in there that makes me doubt all of them. Though, if the first two prove not to be reproducible, then there will be a great defamation case, so I presume those two are true.

The movie/TV plot scenarios

So if you wanted to use this as a realistic TV/movie plot, here are two of them.
#1 You (the executive of the acquiring company) are meeting with the CEO and executives of a smaller company you want to buy. It’s a family concern, and the CEO really doesn’t want to sell. But you know his/her children want to sell. Therefore, during the meeting, you pull out your notebook and an SDR device and put it on the conference room table. You start running the exploit to crash that CEO’s pacemaker. It crashes, the CEO grabs his/her chest, who gets carted off the hospital. The children continue negotiations, selling off their company.
#2 You are a hacker in Russia going after a target. After many phishing attempts, you finally break into the home desktop computer. From that computer, you branch out and connect to the [email protected] devices through the hard-coded password. You then run an exploit from the device, using that device’s own radio, to slowly drain the battery from the pacemaker, day after day, while the target sleeps. You patch the software so it no longer warns the user that the battery is getting low. The battery dies, and a few days later while the victim is digging a ditch, s/he falls over dead from heart failure.

The Muddy Water’s document is crap

There are many ethical issues, but the first should be dishonesty and spin of the Muddy Waters research report.

The report is clearly designed to scare other investors to drop St Jude stock price in the short term so that Muddy Waters can profit. It’s not designed to withstand long term scrutiny. It’s full of misleading details and outright lies.

For example, it keeps stressing how shockingly bad the security vulnerabilities are, such as saying:

We find STJ Cardiac Devices’ vulnerabilities orders of magnitude more worrying than the medical device hacks that have been publicly discussed in the past. 

This is factually untrue. St Jude problems are no worse than the 2013 issue where doctors disable the RF capabilities of Dick Cheney’s pacemaker in response to disclosures. They are no worse than that insulin pump hack. Bad cybersecurity is the norm for medical devices. St Jude may be among the worst, but not by an order-of-magnitude.

The term “orders of magnitude” is math, by the way, and means “at least 100 times worse”. As an expert, I claim these problems are not even one order of magnitude (10 times worse). I challenge MedSec’s experts to stand behind the claim that these vulnerabilities are at least 100 times worse than other public medical device hacks.

In many places, the language is wishy-washy. Consider this quote:

Despite having no background in cybersecurity, Muddy Waters has been able to replicate in-house key exploits that help to enable these attacks

The semantic content of this is nil. It says they weren’t able to replicate the attacks themselves. They don’t have sufficient background in cybersecurity to understand what they replicated.

Such language is pervasive throughout the document, things that aren’t technically lies, but which aren’t true, either.

Also pervasive throughout the document, repeatedly interjected for no reason in the middle of text, are statements like this, repeatedly stressing why you should sell the stock:

Regardless, we have little doubt that STJ is about to enter a period of protracted litigation over these products. Should these trials reach verdicts, we expect the courts will hold that STJ has been grossly negligent in its product design. (We estimate awards could total $6.4 billion.15)

I point this out because Muddy Waters obviously doesn’t feel the content of the document stands on its own, so that you can make this conclusion yourself. It instead feels the need to repeat this message over and over on every page.

Muddy Waters violation of Kerckhoff’s Principle

One of the most important principles of cyber security is Kerckhoff’s Principle, that more openness is better. Or, phrased another way, that trying to achieve security through obscurity is bad.

The Muddy Water’s document attempts to violate this principle. Besides the the individual vulnerabilities, it makes the claim that St Jude cybersecurity is inherently bad because it’s open. it uses off-the-shelf chips, standard software (line Linux), and standard protocols. St Jude does nothing to hide or obfuscate these things.

Everyone in cybersecurity would agree this is good. Muddy Waters claims this is bad.

For example, some of their quotes:

One competitor went as far as developing a highly proprietary embedded OS, which is quite costly and rarely seen

In contrast, the other manufacturers have proprietary RF chips developed specifically for their protocols

Again, as the cybersecurity experts in this case, I challenge MedSec to publicly defend Muddy Waters in these claims.

Medical device manufacturers should do the opposite of what Muddy Waters claims. I’ll explain why.

Either your system is secure or it isn’t. If it’s secure, then making the details public won’t hurt you. If it’s insecure, then making the details obscure won’t help you: hackers are far more adept at reverse engineering than you can possibly understand. Making things obscure, though, does stop helpful hackers (i.e. cybersecurity consultants you hire) from making your system secure, since it’s hard figuring out the details.

Said another way: your adversaries (such as me) hate seeing open systems that are obviously secure. We love seeing obscure systems, because we know you couldn’t possibly have validated their security.

The point is this: Muddy Waters is trying to profit from the public’s misconception about cybersecurity, namely that obscurity is good. The actual principle is that obscurity is bad.

St Jude’s response was no better

In response to the Muddy Water’s document, St Jude published this document [2]. It’s equally full of lies — the sort that may deserve a share holder lawsuit. (I see lawsuits galore over this). It says the following:

We have examined the allegations made by Capital and MedSec on August 25, 2016 regarding the safety and security of our pacemakers and defibrillators, and while we would have preferred the opportunity to review a detailed account of the information, based on available information, we conclude that the report is false and misleading.

If that’s true, if they can prove this in court, then that will mean they could win millions in a defamation lawsuit against Muddy Waters, and millions more for stock manipulation.

But it’s almost certainly not true. Without authentication/encryption, then the fact that hackers can crash/drain a pacemaker is pretty obvious, especially since (as claimed by Muddy Waters), they’ve successfully done it. Specifically, the picture on page 17 of the 34 page Muddy Waters document is a smoking gun of a pacemaker misbehaving.

The rest of their document contains weasel-word denials that may be technically true, but which have no meaning.

St. Jude Medical stands behind the security and safety of our devices as confirmed by independent third parties and supported through our regulatory submissions. 

Our software has been evaluated and assessed by several independent organizations and researchers including Deloitte and Optiv.

In 2015, we successfully completed an upgrade to the ISO 27001:2013 certification.

These are all myths of the cybersecurity industry. Conformance with security standards, such as ISO 27001:2013, has absolutely zero bearing on whether you are secure. Having some consultants/white-hat claim your product is secure doesn’t mean other white-hat hackers won’t find an insecurity.

Indeed, having been assessed by Deloitte is a good indicator that something is wrong. It’s not that they are incompetent (they’ve got some smart people working for them), but ultimately the way the security market works is that you demand of such auditors that the find reasons to believe your product is secure, not that they keep hunting until something is found that is insecure. It’s why outsiders, like MedSec, are better, because they strive to find why your product is insecure. The bigger the enemy, the more resources they’ll put into finding a problem.

It’s like after you get a hair cut, your enemies and your friends will have different opinions on your new look. Enemies are more honest.

The most obvious lie from the St Jude response is the following:

The report claimed that the battery could be depleted at a 50-foot range. This is not possible since once the device is implanted into a patient, wireless communication has an approximate 7-foot range. This brings into question the entire testing methodology that has been used as the basis for the Muddy Waters Capital and MedSec report.

That’s not how wireless works. With directional antennas and amplifiers, 7-feet easily becomes 50-feet or more. Even without that, something designed for reliable operation at 7-feet often works less reliably at 50-feet. There’s no cutoff at 7-feet within which it will work, outside of which it won’t.

That St Jude deliberately lies here brings into question their entire rebuttal. (see what I did there?)


First let’s discuss the ethics of lying, using weasel words, and being deliberately misleading. Both St Jude and Muddy Waters do this, and it’s ethically wrong. I point this out to uninterested readers who want to get at that other ethical issue. Clear violations of ethics we all agree interest nobody — but they ought to. We should be lambasting Muddy Waters for their clear ethical violations, not the unclear one.

So let’s get to the ethical issue everyone wants to discuss:

Is it ethical to profit from shorting stock while dropping 0day.

Let’s discuss some of the issues.

There’s no insider trading. Some people wonder if there are insider trading issues. There aren’t. While it’s true that Muddy Waters knew some secrets that nobody else knew, as long as they weren’t insider secrets, it’s not insider trading. In other words, only insiders know about a key customer contract won or lost recently. But, vulnerabilities researched by outsiders is still outside the company.

Watching a CEO walk into the building of a competitor is still outsider knowledge — you can trade on the likely merger, even though insider employees cannot.

Dropping 0day might kill/harm people. That may be true, but that’s never an ethical reason to not drop it. That’s because it’s not this one event in isolation. If companies knew ethical researchers would never drop an 0day, then they’d never patch it. It’s like the government’s warrantless surveillance of American citizens: the courts won’t let us challenge it, because we can’t prove it exists, and we can’t prove it exists, because the courts allow it to be kept secret, because revealing the surveillance would harm national intelligence. That harm may happen shouldn’t stop the right thing from happening.

In other words, in the long run, dropping this 0day doesn’t necessarily harm people — and thus profiting on it is not an ethical issue. We need incentives to find vulns. This moves the debate from an ethical one to more of a factual debate about the long-term/short-term risk from vuln disclosure.

As MedSec points out, St Jude has already proven itself an untrustworthy consumer of vulnerability disclosures. When that happens, the dropping 0day is ethically permissible for “responsible disclosure”. Indeed, that St Jude then lied about it in their response ex post facto justifies the dropping of the 0day.

No 0day was actually dropped here. In this case, what was dropped was claims of 0day. This may be good or bad, depending on your arguments. It’s good that the vendor will have some extra time to fix the problems before hackers can start exploiting them. It’s bad because we can’t properly evaluate the true impact of the 0day unless we get more detail — allowing Muddy Waters to exaggerate and mislead people in order to move the stock more than is warranted.

In other words, the lack of actual 0day here is the problem — actual 0day would’ve been better.

This 0day is not necessarily harmful. Okay, it is harmful, but it requires close proximity. It’s not as if the hacker can reach out from across the world and kill everyone (barring my movie-plot section above). If you are within 50 feet of somebody, it’s easier shooting, stabbing, or poisoning them.

Shorting on bad news is common. Before we address the issue whether this is unethical for cybersecurity researchers, we should first address the ethics for anybody doing this. Muddy Waters already does this by investigating companies for fraudulent accounting practice, then shorting the stock while revealing the fraud.

Yes, it’s bad that Muddy Waters profits on the misfortunes of others, but it’s others who are doing fraud — who deserve it. [Snide capitalism trigger warning] To claim this is unethical means you are a typical socialist who believe the State should defend companies, even those who do illegal thing, in order to stop illegitimate/windfall profits. Supporting the ethics of this means you are a capitalist, who believe companies should succeed or fail on their own merits — which means bad companies need to fail, and investors in those companies should lose money.

Yes, this is bad for cybersec research. There is constant tension between cybersecurity researchers doing “responsible” (sic) research and companies lobbying congress to pass laws against it. We see this recently how Detroit lobbied for DMCA (copyright) rules to bar security research, and how the DMCA regulators gave us an exemption. MedSec’s action means now all medical devices manufacturers will now lobby congress for rules to stop MedSec — and the rest of us security researchers. The lack of public research means medical devices will continue to be flawed, which is worse for everyone.

Personally, I don’t care about this argument. How others might respond badly to my actions is not an ethical constraint on my actions. It’s like speech: that others may be triggered into lobbying for anti-speech laws is still not constraint on what ethics allow me to say.

There were no lies or betrayal in the research. For me, “ethics” is usually a problem of lying, cheating, theft, and betrayal. As long as these things don’t happen, then it’s ethically okay. If MedSec had been hired by St Jude, had promised to keep things private, and then later disclosed them, then we’d have an ethical problem. Or consider this: frequently clients ask me to lie or omit things in pentest reports. It’s an ethical quagmire. The quick answer, by the way, is “can you make that request in writing?”. The long answer is “no”. It’s ethically permissible to omit minor things or do minor rewording, but not when it impinges on my credibility.

A life is worth about $10-million. Most people agree that “you can’t put value on a human life”, and that those who do are evil. The opposite is true. Should we spend more on airplane safety, breast cancer research, or the military budget to fight ISIS. Each can be measured in the number of lives saved. Should we spend more on breast cancer research, which affects people in their 30s, or solving heart disease, which affects people’s in their 70s? All these decisions means putting value on human life, and sometimes putting different value on human life. Whether you think it’s ethical, it’s the way the world works.

Thus, we can measure this disclosure of 0day in terms of potential value of life lost, vs. potential value of life saved.

Is this market manipulation? This is more of a legal question than an ethical one, but people are discussing it. If the data is true, then it’s not “manipulation” — only if it’s false. As documented in this post, there’s good reason to doubt the complete truth of what Muddy Waters claims. I suspect it’ll cost Muddy Waters more in legal fees in the long run than they could possibly hope to gain in the short run. I recommend investment companies stick to areas of their own expertise (accounting fraud) instead of branching out into things like cyber where they really don’t grasp things.

This is again bad for security research. Frankly, we aren’t a trusted community, because we claim the “sky is falling” too often, and are proven wrong. As this is proven to be market manipulation, as the stock recovers back to its former level, and the scary stories of mass product recalls fail to emerge, we’ll be blamed yet again for being wrong. That hurts are credibility.

On the other the other hand, if any of the scary things Muddy Waters claims actually come to pass, then maybe people will start heading our warnings.

Ethics conclusion: I’m a die-hard troll, so therefore I’m going to vigorously defend the idea of shorting stock while dropping 0day. (Most of you appear to think it’s unethical — I therefore must disagree with you).  But I’m also a capitalist. This case creates an incentive to drop harmful 0days — but it creates an even greater incentive for device manufacturers not to have 0days to begin with. Thus, despite being a dishonest troll, I do sincerely support the ethics of this.


The two 0days are about crashing the device (killing the patient sooner) or draining the battery (killin them later). Both attacks require hours (if not days) in close proximity to the target. If you can get into the local network (such as through phishing), you might be able to hack the [email protected] monitor, which is in close proximity to the target for hours every night.

Muddy Waters thinks the security problems are severe enough that it’ll destroy St Jude’s $2.5 billion pacemaker business. The argument is flimsy. St Jude’s retort is equally flimsy.

My prediction: a year from now we’ll see little change in St Jude’s pacemaker business earners, while there may be some one time costs cleaning some stuff up. This will stop the shenanigans of future 0day+shorting, even when it’s valid, because nobody will believe researchers.

Join us for a day of making!

Post Syndicated from Rachel Rayns original https://www.raspberrypi.org/blog/digtialmakingday/

Hello all! Raspberry Pi would like to ask you out for the day. We have a day of making, hacking, bikes, bird boxes, picnicking, and filming lined up. All we need now is some good company!


No Description

This day of tinkering shenanigans is in preparation for our brand new programme for young people, which will be launching soon. If you’d like to apply, you need to be aged between 12 and 18, living in the UK, and free on Tuesday 23rd August 2016. You also need to be comfortable in front of a camera. We’ll be catching all the action throughout the whole day and making videos to share with the world, so we need smiley faces! If you love tinkering and getting creative, then this is for you. You don’t need any experience with computers or electronics; this is for anybody who enjoys making things.

We’ll cover your travel costs, and if you are coming a really long way we can provide accommodation for you and a parent or guardian. Accompanying adults will get the day to themselves to do whatever they please around Cambridge: it’s a beautiful place with lots to see.

Raspberry Pi Makers Day

Makers make!

In order to bag an invitation, you’ll need to send our judges a mini video about yourself. This video is your chance to shine, so get creative! (Don’t worry about special equipment – we’re expecting most of you to shoot on your phones.)

The video should be no longer than 30-60 seconds. It should introduce you and give us a little run down of what you like making and doing. That can be making cake, videos, clothes, robots, or even just making a mess. Please include anything else you think will entertain us. If you are entering in a group with friends, then feel free to get together for your filming session, but remember that each person must submit an individual video of themselves. Group videos will not be accepted: you all need to have your own 60 seconds in the spotlight.

Applications must be received by midnight on Sunday 7th August.

Submit your video and details to us via the Digital Making Day form.

If you have any questions email [email protected] .
Don’t forget to spread the word to anyone else who may want to take part!


The gif that never grows old!

The post Join us for a day of making! appeared first on Raspberry Pi.

Wearable Pi Zero Camera from Adafruit

Post Syndicated from Liz Upton original https://www.raspberrypi.org/blog/wearable-pi-zero-camera/

Over in a land of palm trees and breezy sunsets, Adafruit’s Noe Ruiz has been making things. (My Noe story: I waltzed up to him in the Adafruit factory once, grabbed his hand, pumped his arm up and down and said: “SO good to see you again. How’s your brother?” He looked deeply confused. Turns out we’d never met; I’d just recognised him, and his brother Pedro, from YouTube. I’m still red with embarrassment a couple of years later.)

Anyway. Camera.

adafruit camera_hero-lanyard

This build’s a great project for those of you with access to a 3d printer. It’s a teeny-weeny wearable camera which you can program to take a continuous stream or (more fun) use to take a time-lapse recording of your day.

Wearable Camera using Raspberry Pi Zero #3DPrinting

Worn on a lanyard or clipped to a pocket or pack, this adorable camera snaps a photo every few seconds. Slide the SD card into your computer to review the day’s activities or merge all the images into a timelapse animation. Powered by the diminutive and affordable Raspberry Pi Zero, this DIY project is eminently configurable and customizable!

Sample time-lapse output was showcased on Adafruit’s 3d Thursday Hangout. You can see some here:

3D Hangouts – Wearable Pi #3DThursday #3DPrinting

Hang out with Noe & Pedro Ruiz and discover 3D printing! Get your 3D news, projects, design tutorials and more each week on Google+ Hangouts On Air. Subscribe to the Adafruit and follow us on Google+ to catch future broadcasts. We’re warming up our printers, come hang out with us this Thursday!

Wearable cameras are fun – they’re great for recording events like parties or weddings, for keeping a record of holidays, or for dedicated diarists. They’ve also got a more serious side; there’s plenty of research available on using wearable cameras to aid people with memory impairments, not only acting as a piece of bionic memory, but also supporting the brain’s ability to build memories by enabling it to review material.

This being an Adafruit project, it’s documented down to the tiniest detail; there are even instructions to build the device using other models of Raspberry Pi if you haven’t got your hands on a Zero yet. (Good news: Zero availability at the four distributors, Pimoroni, The Pi Hut, Adafruit and Micro Center, is much improved, with stock appearing at each location weekly now – sign up to their newsletters to be notified when stock arrives.)


Adafruit have made files for your 3d printer available, and they’ve provided a ready-to-download SD card image for the project along with instructions on rolling your own if you want a bit more of a challenge. You’ll find an easy-to-follow wiring tutorial, and a user-guide.

Big thanks are due to Philip Burgess and both Ruiz brothers. We loved the whole thing: it’s a brilliant project, a perfect write-up, and it offers so much opportunity for expansion. Thanks all!



The post Wearable Pi Zero Camera from Adafruit appeared first on Raspberry Pi.

Under Construction, our PICO-8 game

Post Syndicated from Eevee original https://eev.ee/blog/2016/05/25/under-construction-our-pico-8-game/

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!

pico-8 cartridge

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.

  1. Move the player some amount in the direction they’re moving.
  2. See if they’re now overlapping anything.
  3. 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:

  1. Get the player’s bounding box. Extend that box in the direction they’re moving, so it covers both their old and new position.
  2. 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.)
  3. Sort all those actors in the order the player will hit them, starting with the closest.
  4. 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.
  5. 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.
  6. 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.

Learning to draw, learning to learn

Post Syndicated from Eevee original https://eev.ee/blog/2016/05/06/learning-to-draw-learning-to-learn/

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.

Crude pencil comic from Jan 1, 2015

I started out doing daily comics, just because Mel was also doing them. The first one was… not terribly great. It hadn’t even occurred to me to bump the contrast on this photo.

At this point I was vaguely aware of some extreme basics:

  • things are made of shapes
  • faces are two dots with a mouth under them
  • arms have some kinda little stubs at the end
  • you can do a squiggle to kind of make fur

I’ve had people tell me I was already drawing better than them here. I can see how I might’ve had a tiny bit of a head start: I do live with two artists, and clumsy attempts at web design have given me a slight appreciation for whitespace and composition. Still, I don’t think this is wildly beyond anyone’s ability.

The most important thing was probably the idea of daily comics, which got me to draw at least one thing a day — several, in fact, since they’re comics. I kept this up through the end of March, at which point I just plain ran out of ideas for comics. There are only so many ways to draw “I worked on computer stuff and also my cat does funny things”. But that’s still 90 days, times an average of at least two panels per comic, which is hundreds of drawings. My first insight is thus:

Do the thing. Do it a lot. No, don’t “practice”. “Practice” sounds rote and repetitive; even reading the word makes me feel pre-emptively bored. Just do it. Find an excuse to do it. Any excuse. You want to write embarrassing fanfiction? Do it. You want to make four-chords pop songs? Do it. You don’t need to do something high-brow or rigorous or chosen from a careful gradient of boring beginner exercises. You just need to something.

Even better, do something regularly and release it publicly (or at least to a moderate circle of people). It helps to have some light pressure, and posting something every day starts to feel like it’s expected of you, even if you’ve never explicitly promised anything.

If it starts to feel like too much of a drag, you can always drop it and try something else. You can take a break for a while, you can do some personal work, you can do whatever self-hack will help you keep doing something.

Digital painting of a landscape from an interesting angle from March 26, 2015

Mel’s birthday is March 26. On March 19, 2015, our roommate gave me his old drawing tablet. I spent most of the ensuing week on the above digital painting.

I’d only colored anything a couple things at this point, all of them basically flood-filled. I hadn’t tried shading, backgrounds, textures, colored lines, perspective.

Naturally, I tried all of them at once. Some of these experiments were, er, more successful than others. (Along similar lines, this year, I animated something for the first time.)

Regardless of the outcome, I’d now done my best at all of these things at least once, and learned a lot about each of them.

I’m reminded of every introductory beginner guide to anything ever, which introduces one concept at a time and carefully shields you from anything you haven’t seen yet. Or stories of programming teachers who will actually chide a student for using something they haven’t been taught yet.

Fuck that noise. Dive in; keep trying things you’ve never tried before. It’s how babies learn a language, which I think is pretty impressive, given that they didn’t already know one. Parents don’t restrict their speech to single-word sentences until the baby has caught on, and then start introducing nouns. They talk normally. The baby marinates in the language and picks it up over time by playing with it, starting with whatever’s most accessible.

And hey, this works for adults too. I’m pretty sure being dropped in a country where no one speaks your native tongue will have you picking up a second language much more quickly than taking night classes and having artificial conversations about dinner dates. The only real advantage a baby has is a complete lack of obligations, so they’re free to sit and listen to people talk all day.

Series of eight roughly increasingly better avatars

I figured another way to do the thing and dive in would be to finally draw my own avatar.

This took a few attempts.

The first two were in March, and I used the first one for a while. 3 through 5 were all done in June in an attempt to replace the first one with something better, but all went unused. Number 6 was the first real success, lasting through the end of the year with a few seasonal variations. 7 was an attempt to update it earlier this year, and the last one is only a few weeks old and is my current avatar.

Some of these are really bad, but I can look at them and tell exactly what I was trying to do.

  1. I didn’t even draw this; I made it with vectors, using the mouse, because I couldn’t draw well enough to make it otherwise.

  2. Drawn by hand with a tablet.

  3. The angle worked out really poorly last time, so I tried working around that by aiming from straight ahead. The ears are no longer solid blobs. There are eyebrows! The nose is shaped more like a nose. The previous colors kinda clashed, so this is more reddish overall.

  4. Straight-on didn’t work out and is hardly identifiable as anything, so back to angled. Still trying to work out pupils. Right ear is drawn behind the bow, so it doesn’t look like the bow is holding it on. I don’t understand mouths, so I’ll cheat and do a smirk instead.

  5. More angled, moved upwards to center the face. Shaded and colored the lines this time. Still trying to work out pupils. Around this time I was trying to figure out how ears on the far side of the head work, and something catastrophic happened here. I was waffling on whether the insides of the ears should have one line or two, so I tried compromising with one line plus a shadow. Bow has a bit of ribbon sticking out, as a hint that it’s tied on and not just glued there.

  6. Made the lines much thicker, so they wouldn’t vanish when shrunk down. Kept the shapes simple for the same reason. Pupils reduced to dots, which actually works just fine. Fluff details are bigger, which helps cohesion. Background color matches the bow color, which helps tremendously. Mouth finally works by being aligned with the bottom of the nose. Shape of the muzzle protrusion is, finally, big enough.

  7. More detailed bow shape. Bow is now clearly tied to the ear. Insides of ears are rendered again. Entire mouth line is shown. Some shading is present again. Pupils have expanded, but not too much, and have a glint again. Lines are colored again.

  8. Small fluff details made bigger again. Background is greener to avoid the clash from last time. Mouth is open and has the little corner crease. Lines rethickened. Dropped the shaded lines, since they didn’t work out last time, but kept the lines as mostly a single non-black color. Thickened the white double outline, which looked goofy in #6 when it was thinner than the regular outline.

In every case I was trying to improve on something that hadn’t gone well before. In every case I was trying to make the best avatar I had ever made. Sometimes that meant trying something I hadn’t tried before; sometimes that meant dropping something that hadn’t worked before; sometimes that meant resurrecting something and fiddling with it until it worked.

Always try to do the best work you’ve ever done. The key is that “best” is entirely subjective, and you can define it however you want! I was terrible at drawing digitigrade legs (like cats’ back legs) for the longest time, so for a while my definition of “best” was “has the best legs I’ve ever drawn”. Pick whatever axes you like. Vary them regularly, too — both to avoid burnout and to avoid concentrating on one thing over all else.

I had a high school teacher who liked to say that “practice makes perfect” is wrong; rather, “perfect practice makes perfect”. I don’t think that phrasing is any more illuminating, but I get his point: repeating exactly the same thing over and over will only make you better at that one thing. Incremental improvement is how you progress. (Hmm, I guess that’s not as catchy.)

There’s a catch to doing this effectively, which might as well be its own bolded quip.

Learn how to tell what’s wrong. This is a tricky muscle to exercise deliberately, but the better you get at it, the more (and more quickly) you can learn from your mistakes. Eventually you learn not to make them in the first place.

Are you a programmer? Spot the problems in this snippet of some C-like language:

if (won = true)
    print("You did it!");
    print("You failed!");
    print("Press any key to try again.");

They probably stick out to you like a sore thumb. You’ve seen and made these basic mistakes so many times that your eye has learned to recoil from the very shape of them. You’re far less likely to make them now, because the moment you make the mistake, your brain vomits a little.

Unfortunately, this is something that only comes with experience, so you’ll just have to slog through making the baby mistakes. Asking for expert advice helps a little, but I think it mostly helps you find the mistake in the first place, so you can notice it again yourself next time. Spotting your own fuckups engraves them into your brain much more effectively than having them pointed out to you.

The one hack I can think of is to drown yourself in good work. The best you can find. If you get a sense for what good work is like, you might at least get the sense that something is off about your own, which is a first step to figuring out what the problem is.

You know how some people are “naturally” talented at a thing? It just “clicks” for them? I strongly suspect their actual natural talent is more about understanding their own mistakes in a particular kind of work, which lets them skip over a lot of the boring beginner part where you fumble around uselessly.

Several pixel art landscapes

Know what’s possible. Every skill has its own toolbox, and part of learning the skill is learning what’s in the toolbox. Being familiar with image editing software has been hugely helpful for experimenting with art; for example, changing the color of your lines is trivial if you know how to use alpha lock. If you don’t know, will you even suspect it exists?

I recall a Doom Let’s Play with a conversation that went like this:

A: Ah, these textures are misaligned. It’s so easy to fix, too; you can just press A in Doom Builder to align everything across several walls.

B: Wait, really? I always do it manually.

A: What? Are you serious? So when you have a big curve made out of a lot of pieces—

B: That’s why I don’t make big curves out of a lot of pieces!

If you think something is impossible (or at least impractical), you cut yourself off from whole areas of experimentation.

Listen to more experienced people when they talk about how they work. Poke around your tools and see what all the buttons do. Come up with your own tricks — it sure worked for Bob Ross.

What does this have to do with pixel art? Not much. Pixel art relates to a rough converse of this, which is that sometimes, it’s nice to limit what’s possible. I’d never really given pixel art a try until I made these last month, and it turned out to be a really fun medium. With the drastically lower resolution and a pre-chosen fixed palette (made by someone else), I was forced to forget about how smooth my curves are or how to pick colors that work well together. Instead, I was free to play with the effects different colors have on each other, experiment with light and shading in a very simple way, and add in small details that I’d usually not think about.

Similarly, I’m now trying out the PICO-8 “fantasy console”, a tiny virtual video game system with some fairly severe restrictions. As a result, after a couple days of effort, I’m much closer to having a (graphical!) video game written than I ever have been before. I’m capable of making my own sprites now, and there can’t be too many of them anyway. Even the music editor is simple enough that I can make a passable tune. If I’d tried to make a little platformer in some massively-powerful general-purpose game engine, I’d have drowned in all the resources and code I’d need to find or create. Which has happened before. Probably more than once.

A blank canvas can be overwhelming sometimes; infinite possibilities are a lot to sift through. Cutting down on those options is freeing in its own way.

Pi Day comic, in 2015 and 2016

Step back and acknowledge your progress.

Learning a thing is frustrating sometimes. A lot of the time, even. Progress is slow and incremental, and on any given day, you won’t feel any better than you were the previous day.

Keep your old stuff around. Look at it from time to time so you can actually see how far you’ve come.

I drew these one year apart. I’m still not great — I immediately see half a dozen things in the more recent version that make me wince. But I’m better.

Illustration of a few critters at the circus

I think this is the most recent thing I’ve finished. It’s certainly a far cry from some pencil scribbles.

I hope I can get much better at this. Expressing ideas visually feels like a superpower — I can take vague images in my head and inject them directly into other people’s eyeballs. It keeps turning out to be useful, too: I’ve drawn myself avatars and banners, I drew the header for this site, I can draw sprites and illustrations for my own little games. It even taught me a few things that turned out to be useful for level design.

So, learn a lot of things. Try radically new things from time to time. Write a poem, bake a cake, make a video game. You’ll have experienced making something new, and you never know when that experience might come in handy. Doing rudimentary web design turned out to give me a head start at understanding color; who would’ve guessed?

I’m only writing this post now because I just realized that I hit a breakthrough point. I don’t really know how to explain it precisely in terms of art, so let me try language instead.

A very frustrating stage of learning a new (spoken) language is the late-beginner stage. You know the basic grammar and understand how the language is generally put together; you just don’t know many words. Learning resources are starting to dry up — everything’s always written for complete beginners — but you struggle to transition to learning from real native media, because you have to stop to look up every other word.

If you stick with it, you’ll eventually claw your way up to a kind of critical mass, where you know enough vocabulary that you can start to pick up the rest from context. You no longer need to spend ten minutes fishing through a dictionary just to understand what someone is talking about, and can instead focus on picking up nuance and idioms and more complex grammar. From there, you can accelerate.

I sense I’ve hit a similar kind of critical mass with drawing. I spent a long time fighting just to get my hand to draw the shapes I wanted, which got in the way of learning what shapes I should want in the first place. I realized only days ago that I don’t have this problem nearly so much any more.

That means I can now experiment with different kinds of shapes! It means I can play with line thickness and rely less on undo, because I don’t have to worry that I won’t be able to redraw a line. It means I can try painting more instead of always having a separate lineart layer. I can try more stuff without struggling with the basics.

It took a while to get here, but it’s paying off, and it’s been pretty cool to watch happen.

PulseAudio FUD

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/jeffrey-stedfast.html

Jeffrey Stedfast

Jeffrey Stedfast seems to have made it his new hobby
In a series of very negative blog postings he flamed my software and hence me
in best NotZed-like fashion. Particularly interesting in this case is the
fact that he apologized to me privately on IRC for this behaviour shortly
after his first posting when he was critizised on #gnome-hackers
only to continue flaming and bashing in more blog posts shortly after. Flaming
is very much part of the Free Software community I guess. A lot of people do
it from time to time (including me). But maybe there are better places for
this than Planet Gnome. And maybe doing it for days is not particularly nice.
And maybe flaming sucks in the first place anyway.

Regardless what I think about Jeffrey and his behaviour on Planet Gnome,
let’s have a look on his trophies, the five “bugs” he posted:

  1. Not directly related to PulseAudio itself. Also, finding errors in code that is related to esd is not exactly the most difficult thing in the world.
  2. The same theme.
  3. Fixed 3 months ago. It is certainly not my fault that this isn’t available in Jeffrey’s distro.
  4. A real, valid bug report. Fixed in git a while back, but not available in any released version. May only be triggered under heavy load or with a bad high-latency scheduler.
  5. A valid bug, but not really in PulseAudio. Mostly caused because the ALSA API and PA API don’t really match 100%.

OK, Jeffrey found a real bug, but I wouldn’t say this is really enough to make all the fuss about. Or is it?

Why PulseAudio?

Jeffrey wrote something about ‘solution looking for a problem‘ when
speaking of PulseAudio. While that was certainly not a nice thing to say it
however tells me one thing: I apparently didn’t manage to communicate well
enough why I am doing PulseAudio in the first place. So, why am I doing it then?

  • There’s so much more a good audio system needs to provide than just the
    most basic mixing functionality. Per-application volumes, moving streams
    between devices during playback, positional event sounds (i.e. click on the
    left side of the screen, have the sound event come out through the left
    speakers), secure session-switching support, monitoring of sound playback
    levels, rescuing playback streams to other audio devices on hot unplug,
    automatic hotplug configuration, automatic up/downmixing stereo/surround,
    high-quality resampling, network transparency, sound effects, simultaneous
    output to multiple sound devices are all features PA provides right now, and
    what you don’t get without it. It also provides the infrastructure for
    upcoming features like volume-follows-focus, automatic attenuation of music on
    signal on VoIP stream, UPnP media renderer support, Apple RAOP support,
    mixing/volume adjustments with dynamic range compression, adaptive volume of
    event sounds based on the volume of music streams, jack sensing, switching
    between stereo/surround/spdif during runtime, …
  • And even for the most basic mixing functionality plain ALSA/dmix is not
    really everlasting happiness. Due to the way it works all clients are forced
    to use the same buffering metrics all the time, that means all clients are
    limited in their wakeup/latency settings. You will burn more CPU than
    necessary this way, keep the risk of drop-outs unnecessarily high and still
    not be able to make clients with low-latency requirements happy. ‘Glitch-Free’
    fixes all this. Quite frankly I believe that ‘glitch-free’
    PulseAudio is the single most important killer feature that should be enough
    to convince everyone why PulseAudio is the right thing to do. Maybe people
    actually don’t know that they want this. But they absolutely do, especially
    the embedded people — if used properly it is a must for power-saving during
    audio playback. It’s a pity that how awesome this feature is you cannot
    directly see from the user interface.[1]
  • PulseAudio provides compatibility with a lot of sound systems/APIs that bare ALSA
    or bare OSS don’t provide.
  • And last but not least, I love breaking Jeffrey’s audio. It’s just soo much fun, you really have to try it! 😉

If you want to know more about why I think that PulseAudio is an important part of the modern Linux desktop audio stack, please read my slides from FOSS.in 2007.


Many people (like Jeffrey) wonder why have software mixing at all if you
have hardware mixing? The thing is, hardware mixing is a thing of the past,
modern soundcards don’t do it anymore. Precisely for doing things like mixing
in software SIMD CPU extensions like SSE have been invented. Modern sound
cards these days are kind of “dumbed” down, high-quality DACs. They don’t do
mixing anymore, many modern chips don’t even do volume control anymore.
Remember the days where having a Wavetable chip was a killer feature of a
sound card? Those days are gone, today wavetable synthesizing is done almost
exlcusively in software — and that’s exactly what happened to hardware mixing
too. And it is good that way. In software mixing is is much easier to do
fancier stuff like DRC which will increase quality of mixing. And modern CPUs provide
all the necessary SIMD command sets to implement this efficiently.

Other people believe that JACK would be a better solution for the problem.
This is nonsense. JACK has been designed for a very different purpose. It is
optimized for low latency inter-application communication. It requires
floating point samples, it knows nothing about channel mappings, it depends on
every client to behave correctly. And so on, and so on. It is a sound server
for audio production. For desktop applications it is however not well suited.
For a desktop saving power is very important, one application misbehaving
shouldn’t have an effect on other application’s playback; converting from/to
FP all the time is not going to help battery life either. Please understand
that for the purpose of pro audio you can make completely different
compromises than you can do on the desktop. For example, while having
‘glitch-free’ is great for embedded and desktop use, it makes no sense at all
for pro audio, and would only have a drawback on performance. So, please stop
bringing up JACK again and again. It’s just not the right tool for desktop
audio, and this opinion is shared by the JACK developers themselves.

Jeffrey thinks that audio mixing is nothing for userspace. Which is
basically what OSS4 tries to do: mixing in kernel space. However, the future
of PCM audio is floating points. Mixing them in kernel space is problematic because (at least on Linux) FP in kernel space is a no-no.
Also, the kernel people made clear more than once that maths/decoding/encoding like this
should happen in userspace. Quite honestly, doing the mixing in kernel space
is probably one of the primary reasons why I think that OSS4 is a bad idea.
The fancier your mixing gets (i.e. including resampling, upmixing, downmixing,
DRC, …) the more difficulties you will have to move such a complex,
time-intensive code into the kernel.

Not everytime your audio breaks it is alone PulseAudio’s fault. For
example, the original flame of Jeffrey’s was about the low volume that he
experienced when running PA. This is mostly due to the suckish way we
initialize the default volumes of ALSA sound cards. Most distributions have
simple scripts that initialize ALSA sound card volumes to fixed values like
75% of the available range, without understanding what the range or the
controls actually mean. This is actually a very bad thing to do. Integrated
USB speakers for example tend export the full amplification range via the
mixer controls. 75% for them is incredibly loud. For other hardware (like
apparently Jeffrey’s) it is too low in volume. How to fix this has been
discussed on the ALSA mailing list, but no final solution has been presented
yet. Nonetheless, the fact that the volume was too low, is completely
unrelated to PulseAudio.

PulseAudio interfaces with lower-level technologies like ALSA on one hand,
and with high-level applications on the other hand. Those systems are not
perfect. Especially closed-source applications tend to do very evil things
with the audio APIs (Flash!) that are very hard to support on virtualized
sound systems such as PulseAudio [2]. However, things are getting better. My list of issues I found in
is getting shorter. Many applications have already been fixed.

The reflex “my audio is broken it must be PulseAudio’s fault” is certainly
easy to come up with, but it certainly is not always right.

Also note that — like many areas in Free Software — development of the
desktop audio stack on Linux is a bit understaffed. AFAIK there are only two
people working on ALSA full-time and only me working on PulseAudio and other
userspace audio infrastructure, assisted by a few others who supply code and patches
from time to time, some more and some less.

More Breakage to Come

I now tried to explain why the audio experience on systems with PulseAudio
might not be as good as some people hoped, but what about the future? To be
frank: the next version of PulseAudio (0.9.11) will break even more things.
The ‘glitch-free’ stuff mentioned above uses quite a few features of the
underlying ALSA infrastructure that apparently noone has been using before —
and which just don’t work properly yet on all drivers. And there are quite a
few drivers around, and I only have a very limited set of hardware to test
with. Already I know that the some of the most popular drivers (USB and HDA)
do not work entirely correctly with ‘glitch-free’.

So you ask why I plan to release this code knowing that it will break
things? Well, it works on some hardware/drivers properly, and for the others I
know work-arounds to get things to work. And 0.9.11 has been delayed for too
long already. Also I need testing from a bigger audience. And it is not so
much 0.9.11 that is buggy, it is the code it is based on. ‘Glitch-free’ PA
0.9.11 is going to part of Fedora 10. Fedora has always been more bleeding
edge than other other distributions. Picking 0.9.11 just like that for an
‘LTS’ release might however be a not a good idea.

So, please bear with me when I release 0.9.11. Snapshots have already
been available in Rawhide for a while, and hell didn’t freeze over.

The Distributions’ Role in the Game

Some distributions did a better job adopting PulseAudio than others. On the
good side I certainly have to list Mandriva, Debian[3], and
Fedora[4]. OTOH Ubuntu didn’t exactly do a stellar job. They didn’t
do their homework. Adopting PA in a distribution is a fair amount of work,
given that it interfaces with so many different things at so many different
places. The integration with other systems is crucial. The information was all
out there, communicated on the wiki, the mailing lists and on the PA IRC
channel. But if you join and hang around on neither, then you won’t get the
memo. To my surprise when Ubuntu adopted PulseAudio they moved into one of their
‘LTS’ releases rightaway [5]. Which I guess can be called gutsy —
on the background that I work for Red Hat and PulseAudio is not part of RHEL
at this time. I get a lot of flak from Ubuntu users, and I am pretty sure the
vast amount of it is undeserving and not my fault.

Why Jeffrey’s distro of choice (SUSE?) didn’t package pavucontrol 0.9.6
although it has been released months ago I don’t know. But there’s certainly no reason to whine about
that to me
and bash me for it.

Having said all this — it’s easy to point to other software’s faults or
other people’s failures. So, admitting this, PulseAudio is certainly not
bug-free, far from that. It’s a relatively complex piece of software
(threading, real-time, lock-free, sensitive to timing, …), and every
software has its bugs. In some workloads they might be easier to find than it
others. And I am working on fixing those which are found. I won’t forget any
bug report, but the order and priority I work on them is still mostly up to me
I guess, right? There’s still a lot of work to do in desktop audio, it will
take some time to get things completely right and complete.

Calls for “audio should just work ™” are often heard. But if you don’t
want to stick with a sound system that was state of the art in the 90’s for
all times, then I fear things *will have* to break from time to time. And
Jeffrey, I have no idea what you are actually hacking on. Some people
mentioned something with Evolution. If that’s true, then quite honestly,
“email should just work”, too, shouldn’t it? Evolution is not exactly
famous for it’s legendary bug-freeness and stability, or did I miss something?
Maybe you should be the one to start with making things “just work”, especially since
Evolution has been around for much longer already.

Back to Work

Now that I responded to Jeffrey’s FUD I think we all can go back to work
and end this flamefest! I wish people would actually try to understand
things before writing an insulting rant — without the slightest clue — but
with words like “clusterfuck”. I’d like to thank all the people who commented
on Jeffrey’s blog and basically already said what I wrote here

So, and now I am off hacking a bit on PulseAudio a bit more — or should
I say in Jeffrey’s words: on my clusterfuck that is an epic fail and that no desktop user needs?


[1] BTW ‘glitch-free’ is nothing I invented, other OS have been doing something
like this for quite a while (Vista, Mac OS). On Linux however, PulseAudio is
the first and only implementation (at least to my knowledge).

[2] In fact, Flash 9 can not be made fully working on PulseAudio.
This is because the way Flash destructs it’s driver backends is racy.
Unfixably racy, from external code. Jeffrey complained about Flash instability
in his second post. This is unfair to PulseAudio, because I cannot fix this.
This is like complaining that X crashes when you use binary-only

[3] To Debian’s standards at least. Since development of Debian is
very distributed the integration of such a system as PulseAudio is much more
difficult since in touches so many different packages in the system that are
kind of private property by a lot of different maintainers with different
views on things.

[4] I maintain the Fedora stuff myself, so I might be a bit biased on this one… 😉

[5] I guess Ubuntu sees that this was a bit too much too early, too.
At least that’s how I understood my invitation to UDS in Prague. Since that
summit I haven’t heard anything from them anymore, though.