99 Resumes
Ten months, roughly a hundred resumes, and one sentence from a friend that ended the search.
All Engine and No Game
Nine months on one game engine. 320×200, 256 colors, like it’s 1994. Still no game.
All Engine and No Game
Nine months on one game engine. 320×200, 256 colors, like it’s 1994. Still no game.
All Engine and No Game
Nine months on one game engine. 320×200, 256 colors, like it’s 1994. Still no game.
The BLIT386 logo on a very chunky low-res screen, wrapped in the TV Orava fullscreen glitch effect.
The BLIT386 logo on a very chunky low-res screen, wrapped in the TV Orava fullscreen glitch effect.
The BLIT386 logo on a very chunky low-res screen, wrapped in the TV Orava fullscreen glitch effect.
I wanted to draw pixel sprites and make a game along the way. Instead, I made a game engine, and the game is nowhere in sight. I had good reasons for starting. I no longer remember which one was the real one.
I made many games and even more intros and demos over the years. Often unfinished, forgotten, archived somewhere-who-knows-where, or not installable anymore, because you can’t easily have MS-DOS or Flash on your computer today.
I am not a player
I started in the late 80s, when Czechoslovak ZX Spectrum clones were a thing. Every little nerd wanted one, and a few actually had one. Other weird 8-bit computers sat in schools and offices (like the PMD 85, which was, in fact, the first computer I wrote code for). I never touched the IQ 151, which I remember mostly as a space heater. BASIC was what you learned at after-school clubs, but Z80 assembler was the hot party topic every girl wanted to hear about.
Then PCs became cheaper, and we moved to VGA mode 13h – 320×200, 256 colors – and the real fun began. Turbo Pascal first, then Watcom C, with the DOS/4GW banner everyone who played Doom remembers. A lot of optimizations and hand-tuned assembler: cryptic code on the left, comments on the right, so that next week you’d still know what you meant. It was fun.
Looking back, I took that web design job in 1997 only so I’d have money to drink beer, make scrollers, plasmas and starfields, and drink more beer. But it got a bit out of hand, and years passed. I’ve been in developer tools design and engineering for almost two decades, because I thought I knew exactly why developer tools sucked for the designer in me.
A few years ago, I finally went back to where I was in the 90s. I wanted that back, because I need more fun in my life. My friends Alex and Ant and I released a game on Steam. It’s called Laserboy, and it’s weird and fun, and it won’t take you long to finish. It didn’t pay the bills, but I already wrote about that:
I wanted to draw pixel sprites and make a game along the way. Instead, I made a game engine, and the game is nowhere in sight. I had good reasons for starting. I no longer remember which one was the real one.
I made many games and even more intros and demos over the years. Often unfinished, forgotten, archived somewhere-who-knows-where, or not installable anymore, because you can’t easily have MS-DOS or Flash on your computer today.
I am not a player
I started in the late 80s, when Czechoslovak ZX Spectrum clones were a thing. Every little nerd wanted one, and a few actually had one. Other weird 8-bit computers sat in schools and offices (like the PMD 85, which was, in fact, the first computer I wrote code for). I never touched the IQ 151, which I remember mostly as a space heater. BASIC was what you learned at after-school clubs, but Z80 assembler was the hot party topic every girl wanted to hear about.
Then PCs became cheaper, and we moved to VGA mode 13h – 320×200, 256 colors – and the real fun began. Turbo Pascal first, then Watcom C, with the DOS/4GW banner everyone who played Doom remembers. A lot of optimizations and hand-tuned assembler: cryptic code on the left, comments on the right, so that next week you’d still know what you meant. It was fun.
Looking back, I took that web design job in 1997 only so I’d have money to drink beer, make scrollers, plasmas and starfields, and drink more beer. But it got a bit out of hand, and years passed. I’ve been in developer tools design and engineering for almost two decades, because I thought I knew exactly why developer tools sucked for the designer in me.
A few years ago, I finally went back to where I was in the 90s. I wanted that back, because I need more fun in my life. My friends Alex and Ant and I released a game on Steam. It’s called Laserboy, and it’s weird and fun, and it won’t take you long to finish. It didn’t pay the bills, but I already wrote about that:
I wanted to draw pixel sprites and make a game along the way. Instead, I made a game engine, and the game is nowhere in sight. I had good reasons for starting. I no longer remember which one was the real one.
I made many games and even more intros and demos over the years. Often unfinished, forgotten, archived somewhere-who-knows-where, or not installable anymore, because you can’t easily have MS-DOS or Flash on your computer today.
I am not a player
I started in the late 80s, when Czechoslovak ZX Spectrum clones were a thing. Every little nerd wanted one, and a few actually had one. Other weird 8-bit computers sat in schools and offices (like the PMD 85, which was, in fact, the first computer I wrote code for). I never touched the IQ 151, which I remember mostly as a space heater. BASIC was what you learned at after-school clubs, but Z80 assembler was the hot party topic every girl wanted to hear about.
Then PCs became cheaper, and we moved to VGA mode 13h – 320×200, 256 colors – and the real fun began. Turbo Pascal first, then Watcom C, with the DOS/4GW banner everyone who played Doom remembers. A lot of optimizations and hand-tuned assembler: cryptic code on the left, comments on the right, so that next week you’d still know what you meant. It was fun.
Looking back, I took that web design job in 1997 only so I’d have money to drink beer, make scrollers, plasmas and starfields, and drink more beer. But it got a bit out of hand, and years passed. I’ve been in developer tools design and engineering for almost two decades, because I thought I knew exactly why developer tools sucked for the designer in me.
A few years ago, I finally went back to where I was in the 90s. I wanted that back, because I need more fun in my life. My friends Alex and Ant and I released a game on Steam. It’s called Laserboy, and it’s weird and fun, and it won’t take you long to finish. It didn’t pay the bills, but I already wrote about that:
Games. Frankly, I don’t play them (much). I can’t anymore. Whenever I play something, I see bugs. And I can spend half an hour appreciating a nice little raindrop shader while NPCs kill me over and over. I am not a player, and I don’t want to be unpaid QA for other people’s games either.
The engine that wasn’t there
When I found RetroBlit (a game engine by Martin Cietwierkowski), I didn’t know this was what I’d been looking for all those years. It is a no-bullshit game engine – you need to write everything from scratch, no visual editor to hold your hand. Pure C# joy (and tears). We almost shipped a game with RetroBlit. RetroBlit runs on Unity, so when Unity lost my trust over their famous runtime fee debacle, RetroBlit went with it.
I tried most of the existing engines and frameworks, but I didn’t find the fun. One almost made the cut for me: Defold. It’s ridiculously good and fast, but it’s not easy to make low-res games with it. And perhaps I can’t use Unity-like editors anymore – thank you, RetroBlit.
The problem is, to play a native game, you have to download it from a store and install it, or trust that some itch.io author’s binary is virus-free. What a roadblock! How many people would do that to play a stupid but funny game?
Everybody lives in the browser these days, and the browser lives on the phone. There’s no roadblock there. So if you don’t need to make money from your game (I know), the web is how you show it to friends and family.
I wanted the web as the platform, not as one more export target, which is how most engines treat it. I also wanted a low-resolution environment tuned to my own preferences (320×200 is what I like – my eyes are not getting younger). I decided to build my own engine, loosely inspired by RetroBlit. Everything as low-level as a browser on a phone could be (which isn’t much, but hey, why not).
I called it BLIT386. I mentioned it once before, in passing.
What you take away
You know what we had back in the 80s? Constraints everywhere. It’s why people still love PICO-8 and Playdate.
So there are constraints: 320×200 (which can be lower or higher), 256 indexed colors (which can’t go higher). Swap the palette and the whole scene recolors, no assets touched. Water flows, candles blink, blocks of gradients roll. Like it’s the 90s again and you push pixels in Deluxe Paint.
Games. Frankly, I don’t play them (much). I can’t anymore. Whenever I play something, I see bugs. And I can spend half an hour appreciating a nice little raindrop shader while NPCs kill me over and over. I am not a player, and I don’t want to be unpaid QA for other people’s games either.
The engine that wasn’t there
When I found RetroBlit (a game engine by Martin Cietwierkowski), I didn’t know this was what I’d been looking for all those years. It is a no-bullshit game engine – you need to write everything from scratch, no visual editor to hold your hand. Pure C# joy (and tears). We almost shipped a game with RetroBlit. RetroBlit runs on Unity, so when Unity lost my trust over their famous runtime fee debacle, RetroBlit went with it.
I tried most of the existing engines and frameworks, but I didn’t find the fun. One almost made the cut for me: Defold. It’s ridiculously good and fast, but it’s not easy to make low-res games with it. And perhaps I can’t use Unity-like editors anymore – thank you, RetroBlit.
The problem is, to play a native game, you have to download it from a store and install it, or trust that some itch.io author’s binary is virus-free. What a roadblock! How many people would do that to play a stupid but funny game?
Everybody lives in the browser these days, and the browser lives on the phone. There’s no roadblock there. So if you don’t need to make money from your game (I know), the web is how you show it to friends and family.
I wanted the web as the platform, not as one more export target, which is how most engines treat it. I also wanted a low-resolution environment tuned to my own preferences (320×200 is what I like – my eyes are not getting younger). I decided to build my own engine, loosely inspired by RetroBlit. Everything as low-level as a browser on a phone could be (which isn’t much, but hey, why not).
I called it BLIT386. I mentioned it once before, in passing.
What you take away
You know what we had back in the 80s? Constraints everywhere. It’s why people still love PICO-8 and Playdate.
So there are constraints: 320×200 (which can be lower or higher), 256 indexed colors (which can’t go higher). Swap the palette and the whole scene recolors, no assets touched. Water flows, candles blink, blocks of gradients roll. Like it’s the 90s again and you push pixels in Deluxe Paint.
Games. Frankly, I don’t play them (much). I can’t anymore. Whenever I play something, I see bugs. And I can spend half an hour appreciating a nice little raindrop shader while NPCs kill me over and over. I am not a player, and I don’t want to be unpaid QA for other people’s games either.
The engine that wasn’t there
When I found RetroBlit (a game engine by Martin Cietwierkowski), I didn’t know this was what I’d been looking for all those years. It is a no-bullshit game engine – you need to write everything from scratch, no visual editor to hold your hand. Pure C# joy (and tears). We almost shipped a game with RetroBlit. RetroBlit runs on Unity, so when Unity lost my trust over their famous runtime fee debacle, RetroBlit went with it.
I tried most of the existing engines and frameworks, but I didn’t find the fun. One almost made the cut for me: Defold. It’s ridiculously good and fast, but it’s not easy to make low-res games with it. And perhaps I can’t use Unity-like editors anymore – thank you, RetroBlit.
The problem is, to play a native game, you have to download it from a store and install it, or trust that some itch.io author’s binary is virus-free. What a roadblock! How many people would do that to play a stupid but funny game?
Everybody lives in the browser these days, and the browser lives on the phone. There’s no roadblock there. So if you don’t need to make money from your game (I know), the web is how you show it to friends and family.
I wanted the web as the platform, not as one more export target, which is how most engines treat it. I also wanted a low-resolution environment tuned to my own preferences (320×200 is what I like – my eyes are not getting younger). I decided to build my own engine, loosely inspired by RetroBlit. Everything as low-level as a browser on a phone could be (which isn’t much, but hey, why not).
I called it BLIT386. I mentioned it once before, in passing.
What you take away
You know what we had back in the 80s? Constraints everywhere. It’s why people still love PICO-8 and Playdate.
So there are constraints: 320×200 (which can be lower or higher), 256 indexed colors (which can’t go higher). Swap the palette and the whole scene recolors, no assets touched. Water flows, candles blink, blocks of gradients roll. Like it’s the 90s again and you push pixels in Deluxe Paint.
A Fez-style rotating tesseract: watch a four-dimensional cube turn on a 256×256 PICO-8 sized canvas.
A Fez-style rotating tesseract: watch a four-dimensional cube turn on a 256×256 PICO-8 sized canvas.
A Fez-style rotating tesseract: watch a four-dimensional cube turn on a 256×256 PICO-8 sized canvas.
The trick is that the picture and the colors are two separate things. A sprite doesn’t store red, it stores index 3, and the palette decides what 3 means today. Change that one entry and every pixel drawn with color 3 changes with it, at once, for about a kilobyte of upload. Doing the same thing in a modern engine means a shader, or a re-render, or tint state on every sprite that needs to know. RGBA everywhere is simpler to reason about, and it quietly gave up the one thing the old hardware was accidentally good at.
Which is just indirection, and I spend my days maintaining the same idea under a different name: you don’t repaint the buttons, you change what the token means.
There are three functions to use: init(), update(), render() (check out the docs). It’s called immediate mode, and you (or your agent) need to take care of everything. What you see is what you code, not what you click. There is no scene graph like in Unity or Unreal (or Defold), no game objects or components to wrap your messy behaviors inside. Just the framework and your little project.
Fair, it’s not for everyone. But if you remember how this used to work, or you want to make something in an afternoon, it’s easier. I guess if you know the demoscene, you can smell it.
One new feature makes me happy: the engine notices when someone has asked their OS for less motion, tells your game, and then stays out of it, because what less motion means is your call. A small thing that may bring your game to people who get dizzy from motion.
The trick is that the picture and the colors are two separate things. A sprite doesn’t store red, it stores index 3, and the palette decides what 3 means today. Change that one entry and every pixel drawn with color 3 changes with it, at once, for about a kilobyte of upload. Doing the same thing in a modern engine means a shader, or a re-render, or tint state on every sprite that needs to know. RGBA everywhere is simpler to reason about, and it quietly gave up the one thing the old hardware was accidentally good at.
Which is just indirection, and I spend my days maintaining the same idea under a different name: you don’t repaint the buttons, you change what the token means.
There are three functions to use: init(), update(), render() (check out the docs). It’s called immediate mode, and you (or your agent) need to take care of everything. What you see is what you code, not what you click. There is no scene graph like in Unity or Unreal (or Defold), no game objects or components to wrap your messy behaviors inside. Just the framework and your little project.
Fair, it’s not for everyone. But if you remember how this used to work, or you want to make something in an afternoon, it’s easier. I guess if you know the demoscene, you can smell it.
One new feature makes me happy: the engine notices when someone has asked their OS for less motion, tells your game, and then stays out of it, because what less motion means is your call. A small thing that may bring your game to people who get dizzy from motion.
The trick is that the picture and the colors are two separate things. A sprite doesn’t store red, it stores index 3, and the palette decides what 3 means today. Change that one entry and every pixel drawn with color 3 changes with it, at once, for about a kilobyte of upload. Doing the same thing in a modern engine means a shader, or a re-render, or tint state on every sprite that needs to know. RGBA everywhere is simpler to reason about, and it quietly gave up the one thing the old hardware was accidentally good at.
Which is just indirection, and I spend my days maintaining the same idea under a different name: you don’t repaint the buttons, you change what the token means.
There are three functions to use: init(), update(), render() (check out the docs). It’s called immediate mode, and you (or your agent) need to take care of everything. What you see is what you code, not what you click. There is no scene graph like in Unity or Unreal (or Defold), no game objects or components to wrap your messy behaviors inside. Just the framework and your little project.
Fair, it’s not for everyone. But if you remember how this used to work, or you want to make something in an afternoon, it’s easier. I guess if you know the demoscene, you can smell it.
One new feature makes me happy: the engine notices when someone has asked their OS for less motion, tells your game, and then stays out of it, because what less motion means is your call. A small thing that may bring your game to people who get dizzy from motion.
Reduced Motion: a warp starfield that damps itself when the viewer asks for less motion.
Reduced Motion: a warp starfield that damps itself when the viewer asks for less motion.
Reduced Motion: a warp starfield that damps itself when the viewer asks for less motion.
After-work work
I like how simple and how unforgiving BLIT386 is. My world is full of complex design systems – I needed the opposite. My day job is a long-haul flight. Nothing lands fast.
So I made an immediate-mode game engine that does everything in one frame. Sixty times a second.
People make games
Few things make me happier than watching other people build games with BLIT386. Frankly, I didn’t expect anyone to. Even people who told me they had no clue how to write a game. My friend Jiří made a basketball management game because, he told me, there isn’t a good one. My friend Chemix has already made a ton of games with his young son, who’s learning to code along the way.
Still no rot
My social network of choice is Mastodon. There, my feed is full of people who would hang AI on street lamps if they could, and one of their arguments is that AI code turns to slop and slowly rots. BLIT386 is my pet project, and yes, I use AI for a lot of things. I started last December, and one reason I do remember: I wanted to see when it would overflow with so much slop that it rotted. It hasn’t happened yet, which, honestly, surprised me.
In 1.7.0, nine months in, I went back into code I’d written months earlier – the renderer, the game loop – and reworked its hot paths from the inside. I could still read it, more or less. Nothing public had to change: existing games get the whole (and quite dramatic) speedup by upgrading and doing nothing else. The machines least equipped to run this engine got the biggest win.
Suspects
I have a few ideas why it still works. I use pipelines similar to the ones my team uses on Podman Desktop – my day job, and a project with five million downloads. What I learn on BLIT386, I apply to my PRs there (and in downstream projects), and vice versa.
BLIT386 is my sandbox. It’s where I test unsafe ideas, learn to write better TypeScript and better tests, and see how to make sure a big project doesn’t fall apart.
No warnings are tolerated: anything Biome doesn’t like is an error and gets fixed now. There’s an 80 percent coverage floor. A script fails the build when Claude and Copilot rule files drift apart.
There are a lot of agent skills and rules they follow. They know what to do and what to avoid. They remember what I forget. They shout at me when I do something wrong. I have built guardrails for my project to keep it alive, and me sane.
See, I like constraints, both in the design and in the code. They help me and my projects not to rot. They make my imagination go wild. They keep me grounded.
I have a list of features longer than this article. Still, maybe I should slow down and make a game instead. A small one.
After-work work
I like how simple and how unforgiving BLIT386 is. My world is full of complex design systems – I needed the opposite. My day job is a long-haul flight. Nothing lands fast.
So I made an immediate-mode game engine that does everything in one frame. Sixty times a second.
People make games
Few things make me happier than watching other people build games with BLIT386. Frankly, I didn’t expect anyone to. Even people who told me they had no clue how to write a game. My friend Jiří made a basketball management game because, he told me, there isn’t a good one. My friend Chemix has already made a ton of games with his young son, who’s learning to code along the way.
Still no rot
My social network of choice is Mastodon. There, my feed is full of people who would hang AI on street lamps if they could, and one of their arguments is that AI code turns to slop and slowly rots. BLIT386 is my pet project, and yes, I use AI for a lot of things. I started last December, and one reason I do remember: I wanted to see when it would overflow with so much slop that it rotted. It hasn’t happened yet, which, honestly, surprised me.
In 1.7.0, nine months in, I went back into code I’d written months earlier – the renderer, the game loop – and reworked its hot paths from the inside. I could still read it, more or less. Nothing public had to change: existing games get the whole (and quite dramatic) speedup by upgrading and doing nothing else. The machines least equipped to run this engine got the biggest win.
Suspects
I have a few ideas why it still works. I use pipelines similar to the ones my team uses on Podman Desktop – my day job, and a project with five million downloads. What I learn on BLIT386, I apply to my PRs there (and in downstream projects), and vice versa.
BLIT386 is my sandbox. It’s where I test unsafe ideas, learn to write better TypeScript and better tests, and see how to make sure a big project doesn’t fall apart.
No warnings are tolerated: anything Biome doesn’t like is an error and gets fixed now. There’s an 80 percent coverage floor. A script fails the build when Claude and Copilot rule files drift apart.
There are a lot of agent skills and rules they follow. They know what to do and what to avoid. They remember what I forget. They shout at me when I do something wrong. I have built guardrails for my project to keep it alive, and me sane.
See, I like constraints, both in the design and in the code. They help me and my projects not to rot. They make my imagination go wild. They keep me grounded.
I have a list of features longer than this article. Still, maybe I should slow down and make a game instead. A small one.
After-work work
I like how simple and how unforgiving BLIT386 is. My world is full of complex design systems – I needed the opposite. My day job is a long-haul flight. Nothing lands fast.
So I made an immediate-mode game engine that does everything in one frame. Sixty times a second.
People make games
Few things make me happier than watching other people build games with BLIT386. Frankly, I didn’t expect anyone to. Even people who told me they had no clue how to write a game. My friend Jiří made a basketball management game because, he told me, there isn’t a good one. My friend Chemix has already made a ton of games with his young son, who’s learning to code along the way.
Still no rot
My social network of choice is Mastodon. There, my feed is full of people who would hang AI on street lamps if they could, and one of their arguments is that AI code turns to slop and slowly rots. BLIT386 is my pet project, and yes, I use AI for a lot of things. I started last December, and one reason I do remember: I wanted to see when it would overflow with so much slop that it rotted. It hasn’t happened yet, which, honestly, surprised me.
In 1.7.0, nine months in, I went back into code I’d written months earlier – the renderer, the game loop – and reworked its hot paths from the inside. I could still read it, more or less. Nothing public had to change: existing games get the whole (and quite dramatic) speedup by upgrading and doing nothing else. The machines least equipped to run this engine got the biggest win.
Suspects
I have a few ideas why it still works. I use pipelines similar to the ones my team uses on Podman Desktop – my day job, and a project with five million downloads. What I learn on BLIT386, I apply to my PRs there (and in downstream projects), and vice versa.
BLIT386 is my sandbox. It’s where I test unsafe ideas, learn to write better TypeScript and better tests, and see how to make sure a big project doesn’t fall apart.
No warnings are tolerated: anything Biome doesn’t like is an error and gets fixed now. There’s an 80 percent coverage floor. A script fails the build when Claude and Copilot rule files drift apart.
There are a lot of agent skills and rules they follow. They know what to do and what to avoid. They remember what I forget. They shout at me when I do something wrong. I have built guardrails for my project to keep it alive, and me sane.
See, I like constraints, both in the design and in the code. They help me and my projects not to rot. They make my imagination go wild. They keep me grounded.
I have a list of features longer than this article. Still, maybe I should slow down and make a game instead. A small one.
Grab one of three bouncing balls, drag it, and release to throw it, with synthesized sound effects.
Grab one of three bouncing balls, drag it, and release to throw it, with synthesized sound effects.
Grab one of three bouncing balls, drag it, and release to throw it, with synthesized sound effects.
Make something
Try making a game. You don’t even need to know TypeScript or JavaScript. Just type:
npm create blit386@latest my-game
And talk to the AI agent you use. It will know what to do. Have a beer and enjoy the evening. Make a scroller. Make a starfield. Make the game I still haven’t.
See the BLIT386 website, and explore its demos.
Please show me what you make. I’ll be here, you’ll find me.
Make something
Try making a game. You don’t even need to know TypeScript or JavaScript. Just type:
npm create blit386@latest my-game
And talk to the AI agent you use. It will know what to do. Have a beer and enjoy the evening. Make a scroller. Make a starfield. Make the game I still haven’t.
See the BLIT386 website, and explore its demos.
Please show me what you make. I’ll be here, you’ll find me.
Make something
Try making a game. You don’t even need to know TypeScript or JavaScript. Just type:
npm create blit386@latest my-game
And talk to the AI agent you use. It will know what to do. Have a beer and enjoy the evening. Make a scroller. Make a starfield. Make the game I still haven’t.
See the BLIT386 website, and explore its demos.
Please show me what you make. I’ll be here, you’ll find me.