Notes on my experiments, newest first. 100% honest: what worked, what collapsed, what I learned. Two threads end up in here: the games for period machines, from the Commodore 64 to the Game Boy Advance, and the software, the tools I write to work with and that now and then are worth handing to someone else. Fair warning: I work on all of this in my spare time, late at night, once the kids are in bed. The pace is what it is.
· Commodore 64
Ruote Fumanti 1.1: ten seconds to take out the police
Two versions in two days, and they really change the game.
1.1 redoes the whole end of the stage. Before, the police car turned up, leaned on you for seven seconds and left: too soft, and the players told me so. Now the road empties, the message HIT POLICE 3 TIMES AND RUN AWAY! appears and you have ten seconds. Leaning isn't enough: the police car has to be charged. It flashes red and swerves at you; dodge it and it skids, and that's your moment. Three hits and it's wrecked, and only then does the finish line appear. Fail and they catch you, and you lose a car.
1.1.1, the day after, taught the traffic to stay on the road. Testers said the other cars kept crashing on their own, and they were right: they picked lanes at random, blind to the narrowings, and at that speed one wheel on the grass was enough. Now they look at the road ahead, slow down before tight curves and stop in front of water. The number is clear: cars that wrecked themselves went from 76 out of 167 to 12 out of 189.
There's an NTSC version too, for North American machines: the game used to run twenty per cent too fast there, with the music out of tune.
A question that comes up often when talking about Ruote Fumanti: do you write it on a Commodore 64? No. Today a C64 game is written on the Mac, tested in an emulator, and the real C64, if there is one, is the final check. The tools needed are few, free, and nearly all install with a single command. I've lined them up in a new tutorial: how to make a Commodore 64 game on a Mac.
It's split into three levels. To start, four things are enough: VS Code to write, ACME to assemble, Exomizer to crunch and VICE to test. For a real game you add Python to generate data, make and Git, and editors for sprites, characters and music. To know it works, and not just that it seems to, you need a 6502 CPU running inside Python, a script-driven emulator that plays the game and counts dropped frames, and finally a second emulator and a real C64.
The screenshots are the real ones from working on Ruote Fumanti: the source open at the routine that scrolls the road, the build where 61 KB of game become a 24 KB file, the jump sprites in Spritemate, the automated tests of the keys and engines, and VICE's monitor halting the game mid-race.
In Ruote Fumanti the road moves down pixel by pixel fifty times a second and never shakes. It looks like the simplest thing in the game, and it's the one that took the most ingenuity, because the Commodore 64 has nothing ready-made for it. I've told it in full in a new tutorial, how the road scrolls, and this time with the real pieces of the program, original comments included.
Inside there's the seven-pixel trick, sliding the whole screen for seven frames and copying the road only on the eighth; the two screens used as a flip book, one visible and one being worked on; the track that doesn't exist in memory and gets composed row by row from blocks and tiles; and the moment, in the bottom border, when the page is turned without a visible tear.
And there's the part I like best, because it was found by measuring, not reasoning: two instructions moved from line 32 to right after the frame is delivered gave the game forty lines in which the processor used to wait, and dropped frames went from 1.93% down to 0.11%.
Meanwhile the game has moved to 1.0.1: while racing, M turns off the music and F the effects, each on its own, and with the music off you hear the engines, yours rising with speed and the one of the car passing you.
A new game for the Commodore 64, and this time it's neither a test nor a demo: it's finished, version 1.0.0. It's called Ruote Fumanti, a top-down driving game in eight stages, written in 6510 assembly for a stock PAL C64 with no expansions.
The cover illustration. It isn't a screenshot: the C64 has sixteen colours and 320×200 pixels, and the real screens are below.
The inspiration comes from a classic arcade game that everyone will surely recognise, with a few things done differently. Traffic won't move aside for you: you overtake it, you hit it, or you land on it. Fords can't be driven round, they're jumped, and taking off needs ninety-five miles an hour. In the ravines, if you don't make it, the car plunges and shrinks. And in the last stretch of every stage the traffic vanishes and a police car arrives: seven seconds one on one, jumping disabled, and the only way out is to hold your line or push it off the road yourself, which also pays more than anything else in the game.
The number I'm proud of isn't how many stages there are, it's how often the machine fails to keep up with the game. I measured it in VICE with fixed, repeatable inputs, across all eight stages, 9600 frames: it drops 0.1%, and six stages out of eight drop none. Each frame's work usually finishes halfway down the screen, at line 143, and for the rest of the time the machine waits for the next frame.
The game page has clips of the fords, the ravines and the chase, the controls and the PRG to download.
Off schedule, and for once it isn't my own stuff. Matteo85 is just starting out with Commodore 64 graphics and sent me two drawings: a SUV and a frog. The question behind them was a concrete one, do these work?, and that kind of question is answered faster by running the drawings than by discussing them.
So in a couple of hours, in the gaps of a Sunday, I put them on the road. Out came an endless run: you drive, you avoid the frogs, a frog you pass alive is worth points and one you flatten costs a life, and you get three. You accelerate, you brake, you sound the horn, and the horn scatters the frogs for a second. There's no finish line. The name, Save The Frogs, is his.
The interesting part, though, isn't the game, it's what it was there to explain. A sprite on this machine is understood far sooner by watching one move than by reading its definition, so I wrote it out properly: C64 sprites, explained by putting them on the road. Eight drawings the video chip moves on its own with the CPU redrawing nothing, the 24 by 21 grid, one colour of your own plus two borrowed from every other sprite, the 63 bytes used inside a 64-byte block, the shadow that isn't drawn but computed by four lines of code, the ninth-bit trap that teleports your object halfway across the screen, and the thing that matters most: why the road isn't a sprite.
The tutorial also has an eight-minute video telling the whole path, from pixels to game, with Italian subtitles, plus the PRG to load in VICE or on a real machine.
Same twelve rooms, same puzzles, same file. What changed is the thing you do between the puzzles: walking. A tester put it plainly: the robot didn't weigh anything.
It's the kind of criticism that sounds vague at first and turns out to be the most concrete of all, because once you go and measure you find it has a precise numeric cause. Three of them, actually.
He was running the whole time. Two points per frame, for a figure twenty-eight points tall, is four and a half body heights a second. That isn't a walk, it's a sprint. At that speed his foot hit the floor ten times a second, and no drawing and no sound can make ten footfalls a second feel heavy: whatever stride you draw, what you see is a patter. On the ground he now does 1.25 points per frame. Six footfalls a second instead of ten.
The jump I didn't touch at all. In the air the ceiling is still two points per frame, and anyone who jumps while walking launches at the full speed. That isn't a flourish, it's a requirement: four blocks of jump is the measurement half the rooms are built on, and if the leap got shorter the levels would stop working. It also happens to be right to look at: a heavy thing doesn't go from a step to a flight, it gathers itself and throws.
The knee isn't drawn any more, it's found. The old leg had a fixed length: the ankle sat five points below the knee and stayed there, always. With that constraint the foot could never leave the ground and the knee had no reason to bend, so what was left was a torso sliding forward with its thighs moving slightly.
Now the leg is two bones, and what I move is the foot, not the angles. For half the cycle the foot is nailed to the floor while the body passes over it; for the other half it flies forward and lifts, with the heel leaving before the toe. The knee isn't a number I write: of the two possible positions it's the one a real knee would use, the one pointing forward, and it bends by however much is needed because the leg cannot stretch. The body sinks two points when the feet are far apart, which is also what lets the leg reach that far, and is what a heavy thing does where it puts its weight down.
And the feet no longer skate. This was the real fault, and it was measurable: the drawn stride opened to six points, while the game advanced the cycle as if it were thirteen. Those seven points of difference at every step came out of somewhere, and they came out of the planted foot sliding along the floor.
The fix isn't retouching the drawings: it's changing what drives the cycle. Now it's driven by distance travelled and not by time, so the drawn stride and the travelled stride are the same number, and the foot stays where it was put at any speed.
And now you can hear him. Landing used to be completely silent: you could leap half a room and touch down with nothing, no sound, nothing moving. A thing that lands in silence weighs nothing. There are footsteps now, on the two frames where the heel actually plants, so the sound tells you which drawing you're looking at; and the two feet don't sound the same, because nobody puts both feet down with the same weight, and above all because two identical noises six times a second are a rattle, while two different ones are a gait. There's a thud on landing, the same noise held much lower and much longer: the weight arriving all at once instead of half at a time. The window jolts and settles over six frames: the thud says he landed, the jolt says how much he weighs. And he takes the hit: for two frames after landing the figure is drawn one point lower. One point reads as legs absorbing; two would already read as feet sinking into the floor.
Three things fixed.Outside the room there was nothing: with the window jolting a few points past the edge, a black band would have appeared along one side, so now the map is filled with wall as far as it goes, and the wall simply carries on. It costs nothing, because the whole map ships in the cartridge anyway. A shot that hits something that isn't a panel now says so: it throws a spark, in the colour of the portal you were trying to place, and it tells you two things at once, that the gun fired and that it doesn't stick there. Room 4 has panels again: the acid can still be crossed by waiting for the shuttle, the way the room teaches, or you can drop into the portal on the lip and come out of the far wall, already across.
A clean run of all twelve is now about two minutes fifty. It was two thirty. The extra twenty seconds are all walking, which is exactly what they were supposed to be.
VECTOR v0.43: the camera moves, and there's THE TOWER
Same demo, new build. There are still twelve rooms, but they aren't the ones from before: all twelve have been rebuilt, and the engine grew a camera.
The look around: you walk in, and the window goes to see the far end before it hands you the controls.
The camera. Rooms used to be exactly one screen, 15 blocks by 10: the whole room was in front of you from the first frame, and so was its answer. Now the background is 512 by 512 instead of 512 by 256, the window follows you, every room is two screens wide and the last one is also two screens tall. A room can no longer be read from the doorway: you have to walk into it.
The window never cuts. When a portal throws you across the room the view slides after you, braking as it arrives, and it never lets you leave the frame. That sounds like a detail and it isn't: a hard cut on a teleport makes you lose where you are, every single time.
The look around. Widening the rooms created a problem I hadn't seen coming: you walk in and half the room is behind you. The door, the button, the waterfall: you can't know they're there. So now, as you enter, the camera goes to look: the window sweeps to the far end, holds a beat, and comes back to you; in the tall room it goes up as well. It takes a little over two seconds and the buttons are dead until it's done, because otherwise you start walking blind and you're in the acid before you've seen anything. It doesn't replay when you die: you've already seen the room, and watching it again on every mistake would be a punishment, not a help.
THE TOWER. The last room is 30 blocks by 20, the first in the game taller than the screen. A drain at the very top pours a waterfall that falls the whole height and crosses both floors: for most of the room it's the only thing you can see from both.
The whole tower, the one that doesn't fit on screen: two floors, the waterfall crossing them, and the mezzanine with the gap to plug.
On the ground there's a tub, dry, fifteen blocks from where the water lands. Portal on the ground where the water falls, portal in the ceiling above the tub, and the water crosses the tower. The full tub is the switch that never comes back up: it opens the door upstairs and raises the lift that plugs the gap in the mezzanine, two things that happen off-screen and that you find out about on the way up. Upstairs the door sits on a shelf four blocks above the floor, out of reach of any jump: and it's the same two portals doing it again, the panel in the left wall taken at an angle from below, then the panel in the floor shot at your own feet. You fall upwards. The first time the portals move the water, the second time they move you.
And the first six rooms are no longer the tutorial they were. They teach the same six things in the same order, but each now has a second problem hanging off the first. In the portal room the acid is twelve blocks wide and only one good wall is left, at the far end: the other portal has to go on the floor. You drop in and come out of the wall, already on the far side. That's the rule the whole game is built on, and there it gets said out loud. In the cube room you go through the floor, come out of the ceiling and steer while falling, because the shelf is only reachable by holding right on the way down. In the turret room the cube is both your shield and your only weapon, and you can't use it as both at once.
A clean run of all twelve is now about two and a half minutes. It was one minute thirty-eight before.
Three things fixed, and the first is the most instructive. The waterfall used to stop in mid-air: the jet was built from seven sprites, covering 224 pixels, exactly enough for a room one screen tall. In the tower the fall is 288, and the water simply ended, with air underneath. Now that number is measured against the tallest room in the game instead of the most common one. Ivy grew in the clean rooms: the empty slot in the plant table was marked -1, and the game only skipped slots below -100, so every tidy room quietly stacked fourteen creepers against its left wall, and at a glance they even looked like they belonged. The moving bridge used to walk you off its own edge: it has a wider deck and a parapet now, and you can hold forward for the whole ride.
The updated cartridge is below. It runs on emulators and on real hardware with a flashcart, and the build number is written at the bottom left of the title screen, so it can never be a hand-typed lie.
Since then 0.44.0 has come out, which doesn't touch the puzzles but redoes the walk: it's told here. What you download is always the latest build.
Twelve rooms: the second half is the same place, years later
From the six rooms I wrote about yesterday we've got to twelve, and the interesting part isn't the number: it's that the second half isn't a new world. It's the same facility, seen years later.
The game is split in two, and each half introduces itself with a card. The first one: "everything still works here. The doors open. The water runs. The machines wait for orders."
The first six are the facility in working order. Cubes to carry and drop onto buttons, doors that open on approach, turrets that see you and shoot, beams to break with a cube, moving platforms and lifts. They're the ones that teach the rules, one per room.
First part: clean concrete, lights on, and machines that answer to orders.
The last six are the same place, abandoned. Collapsed walls, moss and vines over the concrete, daylight coming in through the holes. It isn't a change of set dressing to show off other colours: it's the same facility, and you recognise it.
And in there are three things that don't exist in the first half:
Glass. It stops your body but not your shots: portals go through it, you don't.
Wall sentries. They can't be shot down: they're destroyed by throwing a cube at them.
Control consoles. You stand on one and drive a machine you can only watch, through the glass, on the other side of the room.
Second part: the same concrete, but with ivy over it and water coming down from a broken drain.
At the end there's a closing screen, because this is still a demo and it keeps saying so. Twelve rooms and an ending are a public starting point, not a finish line: the rooms will keep growing.
In July I wrote that something big was cooking and that I wasn't saying on which machine. Here it is: the Game Boy Advance. And not empty-handed, because a game came out of it along the way: VECTOR, a tribute to Portal, written from scratch for that hardware.
The cover illustration. It is not a screenshot: the GBA has sixteen colours per palette and 240×160 pixels, and the real screens are below.
The rooms built so far, all together. Each teaches a single thing and asks for it once: walking and jumping, the portals, the cube on the plate, the turret, the beam, the moving machines.
Let's say it up front: it's a demo. The rooms built so far were there to get me on speaking terms with the processor and see what came out: they're a beginning, not a finish line, and more are coming. It isn't a finished game and doesn't pretend to be one. But it runs, it plays, and the cartridge fits in a hundred and six thousand bytes.
The idea is Portal's, and nothing else: the gun doesn't fire bullets but portals, two of them, one warm and one cold, and they only stick to the pale panels. Go in one, come out of the other, and keep your speed: fall from high up into a portal and you come out of the other one fast. Nothing from the original was used, no art and no sound: the tribute is declared inside the game, on the INFO page, with the name of the original and of who made it, because a tribute that doesn't name the original isn't a tribute.
The beam kills, stops at the first obstacle, and can be plugged with the cube. The lift has no buttons: it rises while you stand on it and comes down when you step off.
The machine. After the 8-bit 6502 and the 16-bit 68000, down here there's a 32-bit ARM at 16.8 MHz, and for the first time raw power isn't the main constraint. The constraint is elsewhere: 240 by 160 pixels, sixteen colours per palette, and above all how many colours you can fit inside an eight-by-eight tile. The craft is all in there. And the processor can't divide, so every cycle and every ramp is a power of two: not an affectation, but the fact that an arbitrary division becomes a call into a library that isn't here, and the program stops linking.
No bitmaps, as always. The graphics aren't drawn in a paint program: they're generated. Thirty-two JavaScript tools produce tiles, palettes, maps and tables as C files, and the rooms live in a text file with an editor that shows them drawn while you edit and recompiles the cartridge on save. The character too is generated part by part, and the walk poses come from a curve instead of numbers set by eye.
The two most instructive walls are told in full, because that's the part that really counts: the light that cast a shadow, that is how this machine blends colours and why a brown cone darkens the wall instead of lighting it; and it compiles, it runs, it doesn't work, five faults that raise no error at all, starting with a variable that lived in ROM and never changed.
The ROM for this build was 0.25.0, and it ran on emulators and on real hardware with a flashcart.
Update: the game has moved on quite a bit since, and what you download is always the latest build. Twelve rooms and a scrolling camera arrived, and then the rebuilt walk. This piece stays as it was, because it's the account of that day.
No assembly and no pixels today: this comes off the other workbench. Remote SFTP/FTP is a Visual Studio Code extension, I use it every day, and from today it's downloadable from here.
For years I've been moving files onto remote servers while developing, and for years it's been the same scene: you open the file with an FTP client, edit it in an editor that isn't the one you're using for the project, save, reload. Or you install one of the extensions that do the same thing, and discover that your production password ended up in clear text inside a JSON file in the project folder, one "git add ." away from the repository. I wrote it to get that off my desk, and since it works, I'm giving it away for free.
What it does. You configure the connection once, SFTP over SSH or FTP and FTPS, and the remote folder tree appears in the sidebar. You click a file, it opens; you hit Save, and the file is written back to the server. No local copy that two days later you can't tell is newer or older than the remote one, no sync job to launch and remember. A remote folder can even become the workspace root.
On SSH connections there's the remote terminal, and here's a detail I care about: the shell opens on the same connection already used for the files. No second login, no second password. The feature I use most, though, is search: you pick which folder to start from and what to look for, and if the SSH account has a shell the search runs directly on the server, with grep and find. Only the list of results crosses the network, not the files. You click a result and the file opens at the right line. On FTP, where no shell exists, the extension scans the folders from the client: slower, but it works. Then there's drag and drop, even between two different connections to copy from one server to another: in that case the data goes from one stream into the other without touching disk or memory, so a few-hundred-megabyte file is not a problem.
The three things I'm proudest of can't be seen, and they're the reason I wrote it. Passwords live in the system keychain, not in a file inside the project. The server key is verified against your known_hosts exactly the way ssh does it: if the host is new it shows you the fingerprint and asks, and if the key has changed it warns you explicitly, because that can be a legitimate rotation or someone in the middle. And saving doesn't overwrite behind your back: if a colleague touched that file after you opened it, the save stops before writing and you can compare the two versions.
A few limits, said up front. It's tested on macOS and Linux; not on Windows. Files over 16 megabytes don't open in the editor, and that's a VS Code constraint, it receives remote files as a single block: for those, use the download instead. An open SSH terminal doesn't survive a dropped connection and has to be reopened. And content search over FTP, as I said, is slower.
The licence is free for any use, commercial and inside companies included, with no registration and no limits on time or seats. It is not open source. The only thing I ask is that you don't redistribute the file elsewhere: link the page, so whoever installs it always gets the current version. Step-by-step install instructions are on the tool page. If you try it and something doesn't work, write to me.
That said: no, this isn't the surprise promised for September. That one is about the other workbench entirely, and it still holds.
A small honest truth, for once with no trap: something big is cooking for the coming weeks. I won't say what, I won't say on which machine, but if you've followed this far you can feel the jump coming. Let's say that this time the floor actually holds.
There's one obstacle, though, that no assembler can dodge: the family needs to be taken to the sea, then up to the mountains. So the workbench closes for a while, and the big reveal moves to September. It's not a vague "soon": it's right there on the calendar, written in sand.
Meanwhile the two builds, C64 and Mega Drive, stay right here, downloadable, to pass the time. And keep an eye on this space: a clue or two might surface even before September, whenever the beach (or mountain) wifi allows. Stay tuned.
· Commodore 64
C64: the V2 campaign lands on the breadbin too
What I built on the Mega Drive is starting to come down to the Commodore 64. The C64 v0.0.11 build is the conversion of the V2 campaign: the first two levels for now, with the gun, the enemies and the stars to collect, rewritten in 6502 assembly. Same game, same idea, another machine, and half a century less computing power.
1-2 "Rhythm and Lead" on the C64: the same scene as on the Mega Drive, gun in hand and the promise up top: "they don't shoot. For now."
The updated PRG is below, for emulators and real hardware.
In a few builds the Mega Drive test grew quite a bit: from a test level to a small campaign, "V2". The six screens have been reworked, a few adversaries appeared, there's a whole new presentation and a good deal of graphic polish. The game logic stays faithful to the original. The rest is better discovered by playing.
The idea, really, is a design experiment: I'm trying to throw in a bit of every classic platformer ingredient, the ones the genre has shown a thousand times, and see how they blend together. Not to reinvent the wheel, but to find out what happens when you knead them all into the same game.
1-2 "Rhythm and Lead", a stone world at dusk, gun in hand, a few robots and a planet on the horizon. 2-2 "One of them lies", a steel world at night, among moon, drones and platforms that light up.
Gameplay. All six screens have been redone into a small fixed-screen campaign: you collect stars to unlock the flag, and there's more vertical layout. A gun showed up, and once picked up it stays for the whole run, and with it the first enemies, to shoot down or dodge. There are lives and a game over, but the first lying flag doesn't cost one: that's the free lesson. World access codes are back, along with intro cards for each world and the usual wry lines scattered here and there.
Presentation. A short silent opening cutscene, which can be skipped, opens the game; then a graphic title screen, with a big logo and a language choice.
Graphics and animation. Each world now has its own character: a warm stone one against a cold, lit metal one, each with different backdrops, sky, planets and stars. The spikes are bigger and clearer, the fake blocks crumble with a bit of drama, the lights come on softly, and the animations of the character, the stars and the flag are more polished. The figure and the gun were redrawn too.
Audio. A few new sound effects for shots and pickups; the music stays as it was. And as always, the C64 version keeps running intact alongside.
Below, the updated ROM: it runs on emulators and flashcarts.
Change of course: the prototype moves to the Mega Drive
The HTML prototype did exactly the job I built it for: locking down the rules of the game. Physics, jump feel, the worlds' betrayals, the rhythm. All decided there, where trying an idea costs ten minutes. Now I'm shelving it: it stays online, playable as it is, but I'll stop growing it. Its turn is over, and it served me well.
The reason is a surprise: I feel at home on the Mega Drive, far more than I expected. The 68000 with C gives me enough room to prototype directly there, no more detour through the web. And there's a bonus: on the Mega Drive I can make two versions of the same game. One on a fixed screen, the old way, one board at a time; and later one with scrolling, the world sliding by. Two ways to tell the same design.
So I'm starting over right there, on 1988 iron: two good, meaty levels, built properly, no longer drafts. Then, from that solid base, the port to the C64. The web brought us this far; the rest of the journey I'll make on the real machines.
Mega Drive: the first level runs, and the ROM is here
It wasn't supposed to be its turn, but the prototype was sitting right there. The first Mega Drive ROM is downloadable: World 1's first level in a 256KB .gen file that boots in emulators and should boot on flashcarts. Inside is the recipe from the July 9 post: startup, vectors and title screen in 68k assembly, game logic and rendering in C compiled for the 68000. The logic is the same as the prototype, so the gameplay is right; what I can't verify from here is real iron. If you own a Mega Drive and a flashcart, the hardware test is yours: write me what happens. Now back to the C64, which was left holding the joystick.
· C64
The SID stopped slapping me around: the music is in
Two days ago I wrote the SID was slapping me around. Update: we made peace. The player now runs inside the raster interrupt without blowing the frame budget, and the music is in the PRG: title theme and in-game tune, two voices for melody and bass, the third kept free for sound effects, which take priority (in a game where floors collapse, you need to hear the collapse). It's not demoscene material yet, the envelopes are simple and I'm barely touching the filter, but it's real music coming out of a real SID. The first time the theme played all the way through, at 11:50pm, I turned the volume up a notch. Then I remembered the kids and turned it back down. The assembler journey sends its first postcard. The best bug from this battle, the phantom crackle, is told with code in the behind the scenes.
· C64
Build 1: 2 levels, 6 screens, a PRG to download
The first downloadable build of the C64 test is online: the first 2 levels of World 1, 6 screens in total, in a 17KB PRG that boots in VICE and should boot on real hardware. "Should" is the key word: fake-floor collision needs checking screen by screen, and the trembling timing (a tenth of a second, which is 5 frames on PAL) is currently tuned by eye in emulation, not on a real C64. If you run it on real iron and something weird happens, write me: it's part of the experiment. Actually, that IS the experiment. The build was compiled at 11:40pm, like everything in this project: work happens when the kids are asleep.
· C64
The SID is tough (and it's slapping me around)
Confession: music is the hardest part of the whole C64 test. The SID is not a beeper, it's a real synthesizer: 3 voices, ADSR envelopes, analog filters, and zero mercy for someone coming from WebAudio, where a note is one line of JavaScript. Here a note is a 16-bit frequency register to compute, an envelope to program, and a player to write in assembly inside the raster interrupt without blowing the frame budget. For now the build has sound effects only: jump, death, flag. Music will come, at its own pace: doing the SID justice is a craft of its own, and I'm still an apprentice. With an aggravating factor, the setup: barely an hour a night, kids asleep, volume near zero so I don't wake them. Learning a synthesizer on tiptoe.
· HTML5
All 10 worlds exist. Now the real work: polishing them
Milestone: all 10 FIDATI. worlds are playable start to finish, Inferno included, rising lava included. But "playable" and "done" are two different words. It is all still a draft: even the first 6 will need another pass, and the last 4 are the roughest: the Jungle has toothed platforms that bite with too little warning, the Futuristic City teleporters sometimes lie too much even by this game's standards, the Alien City signage needs to lie with more elegance, and Inferno needs balancing screen by screen, because every lie at once is a lot even for the person who wrote them. The worlds get polished one at a time, as they survive playtesting. Which, for a project made of evening scraps after the kids' bedtime, is not a bad place to be.
· HTML5
Saturn: rings that can't hold your weight
Moving platforms were the engine's last big feature, and I didn't want the usual ones. The extra rule: while you stand on a ring it sinks, 18 pixels per second, and only recovers when you step off. When it's about to give, the edge flashes red. Rings become transport, not real estate: hesitate and you sink. The world's third level has my favorite detail: a robot calmly patrols an island whose center is a fake floor. It walks it safely, because the floor only betrays you.
· HTML5
Venus needed more cruelty
Venus' first cut was too kind: telegraphed gusts and little else. Playtesting was merciless ("too easy"), so the world got acid rain (drops swelling under the clouds before falling, desynced per column) and queen wasps: two hits to down, and the first one makes them furious. My favorite touch is ballistic: the wind bends your bullets too. Shooting a wasp in a crosswind isn't aiming, it's artillery.
· Mega Drive
Mega Drive: assembly where needed, C where it counts
The Mega Drive build uses no SGDK, no libraries, but it's not all assembly, and that's a deliberate choice. Startup and vectors are 68k assembly (crt0.s), the title screen is pure asm; game logic and rendering are C (game_logic.c, main.c), compiled by gcc into 68000 machine code that goes into the ROM. Why C? First: it's standard 16-bit era practice. The 68000 was designed with compilers in mind, and loads of commercial Mega Drive games were C with assembly only in the hot spots. It's not a modern shortcut. Second: it's the trick that makes the port verifiable. I don't have a 68000 emulator to test the logic with, but the exact same C source also compiles natively on the Mac, where I play it frame by frame against the reference model: that's where the bit-exact guarantee across 1583 frames comes from. In pure 68k assembly I could only write code and hope. I watched the fake floor crumble by counting vanishing purple pixels: 4756, 4592, 4428. That's where the satisfaction lives. The dual-target method, and the other Mega Drive bugs, are in the behind the scenes.
· C64
A C64 test, in sweat and 6502
Porting FIDATI. to the C64 was a humbling experience. The engine (fixed-point physics, coyote time included, because feel is non-negotiable even in 1982) worked almost immediately. The graphics didn't: writing charsets as raw bytes without seeing them produces exactly what you imagine. The turning point was a preview pipeline: every byte of art gets rendered and looked at before it enters the PRG. Fun fact: the 20×12 grid of 16px tiles maps exactly onto the C64's 40×24 character screen, as if the game was born there. Maybe it partly was.
· design
Jump feel: 4 invisible details
A platformer lives or dies on its jump, and the difference is four details players never see but always feel. Coyote time: you can still jump a few frames after leaving a ledge, or jumps feel "stolen". Jump buffering: press slightly before landing and the jump still fires. Variable jump: release early, jump short. Squash & stretch: the character squashes on landing, stretches on takeoff. All three FIDATI. versions share them, identical: 4-5 coyote frames, 6-7 buffer frames, from the browser down to the 6502.
· design
Passwords like it's 1991
FIDATI. uses 4-letter codes to access worlds: LUCE, CIMA, ROSS, VENT, ANEL... It's not just nostalgia: web portals don't guarantee saves across sessions, and 90s password systems solved exactly that. The code shows up when you reach a new world, you write it down, and you outlast any cloud. The tenth code is LAVA. Do the math.
· HTML5
Mars: the gun changes everything (that's why you earn it)
Mars brought two dangerous things: half gravity and the gun. Gravity was the easy part: you float across twelve tiles and every jump you learned in the first three worlds becomes a lie your muscle memory tells you, which is exactly the point of the game. The gun was a design risk: a rage platformer where you shoot can turn into just another run and gun. The solution: it isn't found, it's earned, ammo is scarce, and the robots guarding it are immune to jumps. Want the weapon? Learn to dodge first. It's the most honest deal in the whole game, so of course I hid it in the most deceitful world. Balancing the robots in one-hour sessions a night, with the house asleep, took a week of evenings: spare time is slow, but it makes you meticulous.
· HTML5
Chiptune in WebAudio: a soundtrack with no files
No mp3s, no assets: all of FIDATI.'s music is synthesized in real time with WebAudio. Square and triangle waves for the voices, filtered noise for percussion, a forty-line sequencer reading patterns written as strings. Each world has its theme: Geometric Space is almost cheerful (it's the tutorial, it has to fool you), Mars is in a minor key, Inferno is a bassline rising a semitone every bar, like the lava. The practical win: the game stays a single HTML file under 50KB. What WebAudio gave me in simplicity, the SID is now making me pay back with interest. But that's another story, further up this devlog.
· HTML5
One file, zero assets: the foundations
Rule number one, set on day one: the whole game in a single HTML file, no external assets. Sprites, tiles and levels drawn in code on the canvas, synthesized sounds, levels described as character strings where # is a wall, ^ is a spike and F is the flag (one of the two, anyway). It sounds like masochism, it's a practical choice: a single file loads anywhere, travels well, has no dependencies to rot. And it has a side effect I'd only discover a week later: levels made of characters move to a character-based machine, say a certain 1982 breadbin, with suspicious ease.
· design
Why FIDATI. (and why it lies)
It all started as a weekend prototype, or rather: two evenings of that weekend, from 9:30pm on, kids asleep. A canvas, an orange square, hand-written physics. The first fake floor was born by accident: a collision bug made a random tile vanish underfoot, and dying there was strangely fun. Instead of fixing it, I promoted it to a mechanic. From there, the concept: a platformer that lies to you, but with honest rules. Every lie can be learned, every betrayal has a warning, even if it's a tenth of a second: the game doesn't cheat, it deceives, which is different. The title arrived on its own: FIDATI. (Italian for "trust me"), with the period. The way liars say it.
· Commodore 64
· Game Boy Advance
· software
· Mega Drive
· HTML5