Get Info: #gamedev

New (Old) 3D Golf: porting PC-9801 & Virtual Boy to Mega Drive

by Matt Sephton — Fri, 19 Jun 2026 16:26:00 +0000

The Japanese Mega Drive ports of T&E SOFT’s New 3D Golf Simulation series are my favourite golf games, and recently I’ve been living inside their ROMs.

As with all the craziest ideas, it began with a “I wonder if I could”… In the early hours of one April morning I managed to pull a single course out of the game—its terrain and flyby data—and reimplement it in a viewer of my own, written in Three.js. Over the following week or so of continued reverse engineering, that viewer quietly grew into something resembling a 3D golf game running in the browser. Finding the data had some big clues: we know that there are 18 holes, the distances of each hole and their sequence order, and I’d read the courses were made of ~256 points, so adding all these heuristics together meant it was much easier to find the data than finding a needle in a haystack.

Understanding the data that well meant I could go the other way, too—back into the original Mega Drive games themselves. First I added a terrain modifier. To test it I flattened the entire course like a pancake to confirm my understanding was correct, and then cranked it up to 11 into a sort of “Hyperactive Terrain Mode” that warps the fairways into something wild. Both worked well.

An early attempt changed its mind on every run; turned out I was seeding it from an uninitialised memory location. 🤦 With no debugger console to hand, I’d been hunting bugs like this the crude way—scribbling values into the cartridge’s SRAM (its battery-backed save memory) and reading them back out, a poor man’s printf. So it wasn’t exactly straightforward.

Once that was sorted, I gave the 32-year-old game some brand new, custom user interface to match.

Next I wondered if the course data was the same across all of the four Mega Drive games, could it be the same across the games on other platforms? The answer is yes: the same course data format turns out to be used right across the series, from the original PC-9801 games (and almost certainly X68000 and FM Towns) through to the Mega Drive and even the Virtual Boy. If my (little-endian) maths is correct that’s a total of 7 unique courses, all sharing one format. There’s some reformatting that needs to be done, but the data structure is the same. And since I could already read the courses, I could write them too—patching the games to pick a course at random, or to load one that was never available on the Mega Drive in the first place. PC-9801 to Mega Drive required sorting the polygons to match how they were expected to be stored.

But I guess T&E SOFT used the same POLYSYS-CAD software to design all the courses over several years? I love how such a tool could have that sort of longevity.

That last part is the really fun bit. (Can this even be more fun?)

Here are three courses running on the Mega Drive for the first time:

T&E Selection

Extracted from the NEC PC-9801 add-on course disk:

This course is somewhat unique as it has messages spelled using coloured topology:
the 1st has “GO!” by the tee position; the 18th has “T&E” just beyond the final green

Eight Lakes G.C.

Also extracted from NEC PC-9801 add-on course disk:

A fact perhaps only I care about: during development, prior to Feb 1990, it was Seven Lakes G.C.

Papillon C.C.

Extracted from the Nintendo Virtual Boy game T&E Virtual Golf:

It’s called Papillon—the French word for butterfly—because the course holes were laid out in the shape of a butterfly. Which was surely a nod to the shape of the Virtual Boy controller.

That last one needed a little extra work. T&E Golf on Virtual Boy doesn’t have a hole flyby, so I had to generate the camera path myself: a bezier curve from tee to pin, nudged towards the centre point of the visible course as it appears on the mini-map. The flyby path in this video was about half way to my final solution.

Playing these courses on Mega Drive is truly special and the effort was very much worthwhile. 🥰

A few things I learned along the way

Living inside the disassembly for weeks, I kept tripping over the little decisions T&E SOFT made all those years ago. Some are clever, some are quietly bonkers, and all of them made me grin:

The hole is three times too big. The cup grabs any ball within ~6.7 inches—triple a real hole’s radius—so balls drop from further out than they look. A fudge for the 320×224 screen, where ball and cup were both sub-pixel.
The polygons pre-sort themselves. No depth buffer on the Mega Drive, so the draw order is baked into the course data, back-to-front (the painter’s algorithm). The giveaway: it doesn’t match the original PC-9801 CAD order.
Backspin can reverse a putt. Spin isn’t cosmetic: it’s fed back into the roll and can make the ball check up and trickle backwards. Real ballistic physics in a 1993 cartridge. Love it!
Water isn’t a hazard—just very sticky. There’s no “in the water” state; water polygons carry friction so high it kills the ball in one frame. The penalty falls out of the ordinary maths.
Wind is a real force, not an aim fudge. It becomes a horizontal acceleration applied every frame of flight, exactly like gravity.
Augusta’s wind never actually changes. The direction is never written—only strength varies. The arrow only seems to swing because it’s drawn relative to the camera.
Bunkers plug, cart paths kick. Every surface has its own bounce coefficient. The fairway hands back a healthy ~40% of the ball’s speed; a bunker returns only ~10%, so the ball plugs where it lands; a cart path or rock fires it back at ~75% for that horrible hard skip.
Your lie quietly rolls the dice. On every stroke the game picks a random number from a per-(lie, club) range and folds it into your swing power. A clean fairway lie uses a narrow range; a bad lie widens it—so the rough genuinely makes your shots less predictable. The ranges live in a 17×17 table, one entry per lie-and-club combination.

Four volumes, one evolving engine

It’s tempting to treat the four Mega Drive games as a single engine with interchangeable courses. They’re not, and the very first line of the cross-volume notes I kept is a warning to myself: ⚠️ never assume all four ROMs share code or data layouts. T&E SOFT kept tinkering release to release, and you only catch it by dumping the same region in all four disassemblies and diffing.

The ROM headers number them New 3D Golf Simulation Vol.1–4, and each header also carries a build date stamped in YYYY.MMM form. Here’s the curiosity: the volume numbers track the build dates, not the retail release dates. Vol.2 Devil’s Course was finished a month before Vol.3 Augusta—but reached the shops a month after it:

Vol	Title	Japanese	ROM build	Retail release
1	Pebble Beach no Hatou	ペブルビーチの波濤	1993-07	1993-10-29
2	Devil’s Course	デビルズコース	1993-08	1994-01-28
3	Harukanaru Augusta	遙かなるオーガスタ	1993-09	1993-12-17
4	Waialae no Kiseki	ワイアラエの奇蹟	1993-09	1994-02-25

A couple of header quirks fell out of this. Pebble’s stamp reads 1993.JLY—Sega’s own oddball abbreviation for July. And while three of the carts credit SEGA, Augusta credits T&E Soft’s Sega licensee code T-114 instead—a clue that it alone was self-published by T&E SOFT rather than by Sega. The boxes agree: Augusta’s isn’t Sega-branded either.

Two places they genuinely diverge, each confirmed by dumping the same region in all four:

Colour isn’t a plain palette lookup—and the recipe is per-game. A surface byte runs through a little chain of lookup tables before it becomes a pen colour, and those tables aren’t shared: Pebble grades several surfaces differently and even reorders two entries, while Devil’s Course carries its own darker, redder palette. Waialae, charmingly, reuses a single palette three times where its siblings have three distinct ones.
A decoder bug only Pebble could trigger. In the polygon stream, vertex indices are single bytes, with 0xFF acting as an escape prefix—the byte after it encodes a higher index (0xE0 + xx), so a hole can point past the ~254 vertices a lone byte can name. My extractor mishandled that escaped range, but only Pebble’s holes are dense enough to actually use it—so the bug sailed through the other three games and only fell over when I reached Pebble. Same encoding in every cart; one course’s data was all it took to expose the flaw in my reader.

There’s also the US release, Pebble Beach Golf Links (header stamped 1993-11, likely on shelves 1994-04): the same course data on a larger ROM, with English strings present where the Japanese Vol.1 zeroed them. That parallel made a useful “Rosetta Stone” for decoding menus and text.

Inside Waialae

Waialae was my primary reference—1,572,864 bytes, header NEW 3D GOLF SIMULATION Vol.4 Waialae C.C., serial GM G-5529.

Each hole is reached through four ROM pointers, one per data block, and they’re wildly different sizes. Block 0 is the vertex list—244 XYZ points, the ~256-point mesh, about 1.5 KB. Block 1 is the bulk of it: sixteen view-order streams (one draw order per camera angle) that bake in the back-to-front sorting—around 5.5 KB, bigger than the geometry it orders. Block 2 holds the mesh and sprites themselves (230 polygons plus 54 sprites), ~1.8 KB. Block 3 is just the flyby keyframes, a slim ~0.7 KB. For Waialae’s first hole that comes to about 9.2 KB, split like this:

A couple more structural quirks:

A spatial grid, decades early. Immediately after the vertex pool sits a count followed by count × 16 word offsets into the face section—a two-level spatial grid (cell → faces) so the engine can look up the relevant polygons from the ball’s (x, z) without walking the whole hole.
Why the SRAM debugging hurt. Waialae’s battery-backed save RAM is odd-lane only, from $200001. Byte writes have to land on odd Mega Drive addresses; even-address writes to $200000 simply disappear. That’s the real reason scribbling values into SRAM as a printf substitute was so finicky—half my early writes were going into the void. (BlastEm helpfully flushes SRAM to disk on quit, so I could read it back from the host.)

Variable zoom

The shared course format is what let me move holes between platforms, but each machine scales the world differently. The proven case: Waialae hole 1 from the PC-9801 drops into the Mega Drive after a fixed 1.6× rescale on X and Z (Y untouched), plus a little-endian → big-endian flip on the flyby path records.

Lining those transplanted polygons up against the stock Mega Drive ones is also what proved the rendering trick I mentioned earlier: the Mega Drive packs faces in descending max-Z order—back to front, the painter’s algorithm—and the original PC-9801 face id survives the journey as the Mega Drive’s attr1 byte.

Two deeper cuts

The flyby camera, decoded by statistics. Each flyby keyframe carries two mystery bytes. With no documentation, I histogrammed 4,723 of them across every hole and the shape gave it away: one byte is an 8-bit angle (256 units = 360°) for yaw, the other a signed pitch clamped to about ±40, positive meaning the camera looks down. Educated guessing, with visuals.
The Virtual Boy world is built at a different scale. The Virtual Boy stores its courses at 32 raw units per yard, where the Mega Drive works in 17—so Papillon has to be shrunk by exactly 17/32 (0.53) to sit correctly on the Mega Drive, otherwise every club hits too short for the hole. (My first attempt used the wrong unit and reported hole 1 as 321 yards instead of its true 360.) It’s the same idea as the 1.6× I needed coming the other way from the PC-9801—one shared format, but every machine measures its yards differently.

The whole thing ran on rizin and vasmm68k with BlastEm for execution—though frame-time profiling had to move to Genesis Plus GX, because BlastEm freezes the VDP’s HV counter during the long rendering routines I was trying to measure.

What the old magazines turned up

Reverse engineering only tells you what the games do; for the why, I went digging through a stack of Japanese computer magazines from the era, OCRing the scans to pull out the text. A 1989 developer interview about Harukanaru Augusta (遙かなるオーガスタ)—the PC-9801 original that kicked off the series—turned out to be a goldmine:

The 3D engine came first. T&E’s POLYSYS pre-dated the golf games by a couple of years, already appearing—only in the 3D intro logos, as far as I can tell—in DAIVA STORY 7: Light of Kali Yuga and Psy-O-Blade.
Trees were nearly real 3D. They tried modelling trees as polygons, leaves and all—but one tree took as long to draw as a whole screen. So scaled sprites were used instead.
The first game had no hills. T&E’s 3-D Golf Simulation, written in BASIC six years earlier, had no terrain undulation at all—and on the Sharp X1, 18 holes took half a day to play through.
POLYSYS was meant to be general-purpose: swap the data and it renders anything. T&E planned an RPG and a shooter on it and intended to license it to other software houses.
One programmer, mostly: Eiji Kato (加藤英治).

And the Augusta course itself came with a wonderful backstory:

They licensed the real thing. An official contract with Augusta National, working from the club’s blueprints. Staff visited, didn’t play, but “rubbed their cheeks on the grass.”
Augusta sent back ~60 corrections: eg. pine trees too short and too spread out, flowers too pink, bunker sand the wrong colour.
No do-overs, by design. You could save mid-round, but loading erased the save data—so no replaying holes to pad your score.
Best of all: the dev build’s four caddies were all women. Augusta’s are all men, so the final game swapped them. The ladies returned in the expansion courses and Mega Drive games.
The T&E Selection caddies are real people: four women who worked at Brother Industries—whose TAKERU software vending machines sold these add-on course disks.

What Next?

There’s an extra bit of hacking I’m working on but am unsure if it will lead to anything, but if it does it will need a post all of its own. Hold your thumbs. Fingers crossed. 🤞

It would be possible to release a small script which given both original games would do the extraction and patching, but for now I don’t feel comfortable doing that. I still need to figure out the correct tree mapping for each game, decide which of the four Mega Drive games is most suited to each of the three new courses, add new title screens and a few more bits of detail work.

I’d love to see these ported courses released officially some day—the series IP is now owned and managed by D4 Enterprise—so if you know anybody there please hook us up! If you are an employee of D4 Enterprise then please check my request to license the IP. 🙏

There are more period games in the series that I’d like to take a look at to see if they use the same data format, or modify it in any specific way. SNES and 3DO seem to be the most interesting. 🧐

But for now it’s just me, a pile of disassembly files, rizin and vasmm68k, the BlastEm emulator, and a soft spot for blue skies and FM synth — still trying to get the ball in the hole. ⛳️🏌️‍♂️

Serenity: zen gliding to the sound of procedurally generated music

by Matt Sephton — Thu, 12 Feb 2026 17:53:00 +0000

Today I’m releasing a demo of my new game: Serenity.

It’s available for both Mac and Windows, and the final game will also support Linux.

Download: store.steampowered.com/app/4309910/Serenity_Demo/

The Universe Provides

The story of this game is a strange one, so perhaps worth telling. I was about to add online play to a different game project and wanted a smaller game to test PlayroomKit, the solution I had chosen. As Thanksgiving 2025 approached I wondered what personal project I could do over the break that might be a quick way to prove the online concept. I’d been working in 3D using Three.js for a while, so my mind wandered to all of my favourite 3D game experiences. I wondered how difficult it would be to create something along the lines of an old favourite of mine: Tranquility.

Later that day I was emailing the musicians I was working with, Nova Sphere, and when I returned to my inbox—filtered with the search term “sphere”—there was an email I had been waiting on for something like 20 years: it was from Bill Romanowski, the creator of Tranquility. This was a sign that the Universe really does provide, so I set to work.

The Demo

From that point on I put all my spare time into the game and by Boxing Day I had finished what I would consider the MVP, vertical slice, or whatever you want to call it. That’s essentially what this demo is. You can read a sort of director’s commentary of the game development and my philosophy in a thread on Bluesky. I signed up to Steam, paid my fee, and submitted to Steam Next Fest: February 2026 Edition. I thought it would be fun to release the demo ahead of that event because I’m travelling to Japan for the Tokyo Design Forum between now and then.

This demo is a snapshot from early January and the game has been refined and improved in countless ways since. So, please go easy on the demo and look forward to the final version. Visually, it’s obviously inspired by Tranquility but given that I was creating it with little more than a memory of how that game felt to play back in the day, it contains a lot more. Depending on your point of view, it might strike you as a 3D Electroplankton, Jumping Flash! crossed with Zarch, Tiny Wings in space, Proteus without the trees, or Journey set in the Matrix. My list of influences is wide and varied—not just for the game but also for the procedurally generated levels and music. And of course there is a lot of what I like to think only I can bring to the table. I hope you enjoy it.

The Inspirations

Alpha Waves (1990)
Electroplankton (2005)
Flower (2009)
Journey (2012)
Jumping Flash! (1995)
Panekit (1999)
Proteus (2013)
Tiny Wings (2011)
Tranquility (1992)
Zarch (1987)

The Future

I’m still working hard on the final game, which will release later in 2026. I’m currently courting publishers, so if you like what you see please get in touch. I’d love to get this onto consoles.

I’ll be sure to write more about the game as it gets closer to the finish line, but the current development version has better onboarding, improved music, even higher performance (the demo is 60fps, but the final version is more adaptive). There’s a lot to talk about, but if you’re hungry for more, check out my director’s commentary thread.

In the short term I’ll be showing Serenity at Tokyo Indies on 18th February. I’d love to see you there.

The Trailer

WebGL CRT Shader

by Matt Sephton — Sun, 04 Jan 2026 17:44:00 +0000

I’m releasing my WebGL CRT Shader as open source.

It creates a CRT/vintage TV effect so could be used in games, emulators, apps, demos, visuals, etc. It’s not a simulator just something that gives the same general old school vibe.

As a WebGL shader, it runs on the device’s hardware GPU in the browser and renders to a <canvas> (or offscreen canvas). I currently use it with Three.js, and the demo below uses just a 2D canvas.

It’s optimised to run well on low power devices as far back as iPhone XS, though I’m certain it can be optimised even further. PRs welcome! The easiest personal optimisation you might make would be removing processing of unused parameters.

Is it scientifically correct? Hell no. Does it look good? Yes. Does it give you the feels? Absolutely.

github.com/gingerbeardman/webgl-crt-shader/

History

It began as a shader for Love2D at the beginning of 2025 (here’s a gist of that one) and by the end of 2025 I had ported it to GLSL for a personal work-in-progress web game.

Live Demo

Reach for the sliders!

(You can scroll the demo horizontally on mobile)

![screenshot](https://cdn.gingerbeardman.com/images/posts/glsl-web-crt-shader.png)

^ Screenshot is Pico-8 classic Worm Nom Nom by Tic Tac Toad (kometbomb + iLKke) 🌸🍏🎩🐛💩

Post-Playdate: One Year Later

by Matt Sephton — Wed, 29 Oct 2025 12:12:00 +0000

It’s been a year since October 2024, when I released my last game on the Playdate Catalog. Over the course of that month, I became increasingly concerned about an undercurrent of threatening and antisocial behaviour from one particular developer in the community—my frequent reports of which went unanswered. Eventually—exactly a year ago today—that tension surfaced as a campaign of targeted harassment. I was assured something would be done about it, but sadly, nothing ever was.

So I left the Playdate community. Over the following months, I faced various forms of harassment: doxxing, unsavoury DMs, spam campaigns targeting my email, cell phone, and social media accounts, unfounded accusations—the list goes on. I can tell you, this is not my idea of a fun time.

You might think that after a year this would be old news. Sadly, it’s not. I’ve long since moved on with my life and kept creating—for platforms as exotic as the Sega Dreamcast and as familiar as the web. I’m proud of what I’ve achieved, and of the choices that allow me to keep doing what I do best, regardless of the people who try to put barriers in my way.

While I continued creating award-winning games, the chance to build the game of my dreams came along—made easier by being an employee at a company that would handle funding, marketing, and the practicalities, freeing me to focus on doing my best work. It was a decision I didn’t take lightly, both because of potential ethical concerns and the fear of further harassment. I sought advice from close friends and had thoughtful discussions with several of them. One friend in particular told me they hadn’t heard of the company, so we didn’t discuss it further. That was back in May.

I announced my first work with the company in July—again, this friend said nothing. Then, in mid-October, I announced my new permanent position, and that same friend suddenly went off the deep end. I asked what had changed since May, when they hadn’t heard of the company, and why nothing was said in July, when I first went public with my new work—yet now, in October, they were suddenly so angry. Their reply:

“One of my friends saw your post and sent it to me saying ‘oh no,’ which is how I found out. And then another friend (who you also know) also said ‘oh nooooooo.’”

So, essentially, this friend had been incited into anger by others—the same social dynamic that fuelled the harassment a year ago. And the worst part? Those two mutual friends are key figures in the Playdate scene—the very people who once promised to address the harassment are now perpetuating it, a year on. I need to find a stronger word than disappointing, but that will have to do for now.

At this point, I’m letting things run their course and will continue to do what I do best: make games. I’m looking forward to you being able to play the next one.

Plus ça change—the more things change, the more they stay the same.

Have fun,
matt

Wormhole for Perplexity Comet

by Matt Sephton — Thu, 21 Aug 2025 16:00:00 +0000

Surprise! My latest game, Wormhole, is included in the Comet web browser from Perplexity. It started as an idea to replace the Chrome Dino game and grew into something a bit more sophisticated and fun, and a lot more on brand.

Big love to Henry Modisett and the great team over at Perplexity.

And to Soleio for the hookup—thanks sensei! 🙌

The development of this game was very typical for me and my process: rapid prototyping, careful scoping, and focus on the central mechanic. Let’s dive in!

Prototype 1

This took the brief very literally and replaced Chrome Dino in size and scope. It fitted in the same area of the page and had a similar one button interaction. So, it was a simple game where you controlled the speed of a comet and had to avoid incoming space debris for as long as possible by using a dash mechanic. You could chain dashes and therefore control your acceleration and deceleration whilst balancing risk and reward. It was fun, but the team had bigger ideas. Video of first prototype.

Prototype 2

Multiple members of the team independently proposed the idea of space golf/billiards, or snooker as I called it which raised a few eyebrows, by which time I had already prototyped it. The initial version proved to be fun, so it was full steam ahead.

I set out to refine the game feel and figure out game progress. I’d been reading about procedural generation in Elite (thanks Mark Moxon) and Mario Kart World (thanks Nintendo) and created something similar for my game. A whole universe of galaxies and planets to conquer! It worked well, but the traversal between galaxies and the overall structure didn’t add anything to the game. Zooming through the universe looked super cool! Video of second prototype.

Prototype 3

So, I started the galaxy generation again from scratch. At this point I had the feeling of existential dread that all developers are probably familiar with. I wanted to trash it all and start again, but instead I went out for dinner and talked it over with a close friend and fellow developer (thanks Dave).

Eventually I calmed down and settled on a never-ending belt of galaxies. The transitions became much shorter and sweeter, and the game feel was better than ever. At this point I think I was still coding in love2d. Things were locked down, so I ported the game to JavaScript using the LittleJS framework. According to my notes the prototype was about 300 lines of code before I began the hard work of rounding it out into a game. Video of third prototype.

Procedurally generated

Without giving too much away, the galaxies are procedurally generated with a handful of galaxy types and several other parameters and properties dictating the layout, rotating in a multi-layer but deterministic sequence. It was really fun to think through and implement.

Planets can either attract and repel, gravity varies, slingshots are possible, trick shots are possible, hole-in-one is possible. Wormholes can help or hinder.

The deterministic nature of the game means that everybody plays the same series of galaxies but at their own pace. And you can watch a replay of your shot if you get a suitably amazing black-hole-in-one, with a quick press of the R key (thanks Sensible Soccer). The game is theoretically never-ending, and the difficulty comes with carefully balanced stepped progression and cyclical repeating of the various game properties (thanks Steve Reich).

Never quite made it

If you’ve followed any of my developments you’ll know I’m quite happy to throw code away as quick as I can create it. I attach myself to the idea and execution rather than the code itself.

So it’s fun to mention some things that never made it. As well as the realistic universe, there were some additional obstacle types that fell by the wayside, and the ability to export a video recording of your replay for sharing.

Finishing touches

During prototyping I use geometric shapes: circles, rectangles, lines, and so on. The team at Perplexity then worked up visual designs (thanks Erin) and I implemented them as a combination of bitmaps, SVG for noise texture, CSS for round rects, and there are still arcs, circles, lines, and various fill types punching well above their weight. LittleJS (thanks Frank) is a fantastic and very well optimised framework that I encourage all game devs to check out.

Sound was initially synthesised using ZzFX (thanks again Frank), given LittleJS has built-in support, but they were eventually replaced with digital audio and music (thanks neso).

The Comet launch page was designed by Escha Diol, product designer on Comet, who has been very supportive during this project. She’s a pleasure to work alongside.

There are lots of details and a high level of polish in the game that are easily overlooked but are essential to the final feel: particles, parallax, keyboard control, replay, and more.

Have fun with it!

Donating my Playdate earnings to The Cybersmile Foundation

by Matt Sephton — Sat, 02 Aug 2025 11:18:00 +0000

I’ve decided to donate all of my Playdate earnings (my personal take-home, after Panic and payment processor fees) to The Cybersmile Foundation, starting July 2025.

Cybersmile is a multi-award-winning nonprofit dedicated to digital wellbeing and combating all forms of cyberbullying and online abuse. It’s registered as a charity in the UK and as a 501(c)3 nonprofit organization in the US.

Having experienced online abuse myself—and received so little support that it ultimately drove me away from Playdate as a platform—this feels like the most constructive and meaningful way to turn that experience into something positive. I’d love to donate the full amount these games generate, but I can only give what actually reaches me.

Be excellent to each other.

Peace and love,
matt

Abandoned project: Band-kun/Beatnik for Playdate

by Matt Sephton — Sun, 11 May 2025 16:58:00 +0000

Back in November 2020 I was exploring the PC-98 back catalog, and stumbled across a strange game called Band-kun. Strange in that it’s a 1-bit black and white game on a platform that was capable of colour, and also because it’s a hybrid adventure/management/music/rhythm game. I was smitten.

The Idea

I was already developing for the Playdate, a modern 1-bit platform, and it struck me as the perfect opportunity to create a remaster of the game. So, I set my sights on securing the licence. The original title was developed by Koei—Japan’s equivalent to Electronic Arts—a giant now known as Koei Tecmo, whose owners are worth hundreds of billions. The game itself is credited to one of those owners: Yoichi Erikawa, who used the pen name Ko Shibusawa. I had a feeling this wasn’t going to be easy.

I published a thread about the game and my prototype on Twitter, introducing the game to the West, which remains my most popular post and thread of all-time (~20 years, for me) at over 450K impressions. I also mirrored the thread as a blog post which is no doubt an easier read.

The idea for the remaster was to not remake the original game at all, but rather to take the vibe and bring it into the modern era. So there were no plans to use the original music, or perhaps even the original graphics. I would leverage modern device capabilities and input methods to create a totally new experience a million miles away from the limited original game from 1990.

Challenge Accepted

A couple of days later, 18th December 2020, Cabel Sasser of Panic reached out:

“Hey Matt, I love a good challenge—do you want me to actually try to make contact with someone at Koei? Regarding Band-Kun? (Philosophically, the idea of reviving a long-forgotten PC Koei title is just enormously interesting to me ahhahah)”.

By 25th December 2020—thanks Santa!—Panic’s guy in Japan, Noby, had a breakthrough finding contact details and sent an email to Koei. Their reply came quickly on 27th December 2020 when a lovely person in Koei’s IP management department replied:

they knew of the Playdate and were waiting patiently to pre-order
they had the licence for the Band-kun game (music to my ears!)
there was an outstanding question about the music rights
and some remaining business questions for Panic to answer

The project then became in need of a budget to be set: for both the licence and for me to build it. Even with this discussion happening in late December 2020, it was suggested that the game could feature in Season 2. And that, unfortunately, was the last I heard of it. Sad, and surprising, but true.

Not one to give up so easily I submitted the game twice, kind of, in pitches to Panic.

Open Pitch: Band-kun

June 2022
to reignite the licence discussion
a reimagining of the original game for a modern device
as a team effort with musician and tools programmers; to hit a deadline
suggested budget was included
pitch pdf (191 KB)

On 1st May 2024 I sent a message to Panic stating that I was still interested in making the game and to check the status of the project, but never received a reply.

Season 2 Pitch: Beatnik

July 2024
an all-new game
let’s forget about the IP
completely revised and redesigned
as a solo endeavour; I was confident I could complete the new scope myself
no budget was required
pitch pdf (185 KB)

Go/no-go

Neither of the pitches were successful. There was no further discussion of the licence from 2020.

Regardless, I decided that I would continue working on the game and release it myself. This was the big project I was working on pretty much exclusively from May 2024 to October 2024. You can see elements of it in my New World and Band-o-matic tech demos.

In August 2024, I took a two-week break from working on Beatnik to develop Bender 2: Bend Harder, an expanded version of a game I originally made in 2012. As part of that project, I integrated some of the tooling and library code I had built for Beatnik to test and validate a few of the technologies and concepts. And that was the end of that.

Atari/Jeff Minter game jam results, Llamasoft, and ST Format

by Matt Sephton — Fri, 09 May 2025 17:03:00 +0000

So, my game HERD NERD is a winner in the “I, REBEL” game jam, hosted by Atari and Jeff Minter.

We are delighted to let you know after hours of play and deliberation - Jeff Minter himself chose your game as THIRD PLACE WINNER

Your game stood out in all the right ways: creative, clever, weird and totally nailing the theme. The team (and the judges!) were blown away by your take on the theme and your execution.

✨ What an honour! ✨

All three winners receive the same prize, but honestly I am more excited to hear why Jeff, Giles, and Jason liked my game. So many nice words to spur me on!

The Results

You can hear more about the game jam and the winning games on the latest Atari podcast episode on YouTube or your favourite podcast listening point. You’ll also learn a bit about the famous Superlambanana sculpture and the infamous Sven Bømwøllen video game. You have been warned!

HERD NERD

You can download and play HERD NERD for free/PWYC on Mac and PC. So check it out! Have fun.

Back in the day

It’s July 1991 and I’ve just walked back from Lewis Meeson’s newsagent to my family home clutching the latest monthly ST FORMAT, issue 24. I’d browsed the magazine in-store to make sure it was worth £2.95 of my hard-earned pocket money, and was eager to try out the software included on the 3.5” floppy disk. This was pre-internet and that was the easiest way of getting hold of a selection of new software. The same thing applied to Amiga, Macintosh, PC, and more.

Today I dug out my actual magazine from storage and my nostalgia dial went all the way up to 11.

Llamatron was my first encounter with Jeff Minter and his weird and wonderful type of game. I played it a lot, mostly in 2-player with the droid or other members of my family. Enemies like sentient cans of cola or screaming Mandelbrot patterns are scorched into my memory forever more.

But it wasn’t just Llamatron that was so great in this issue, I also remember using the Revenge document displayer (with no internet we used to read a lot of text files that were included on the disks, like the Llamatron manual and readme about it being distributed in a new-fangled way known as Shareware). And also Little Green Selector which replaced the standard file selector with one that had fully-featured file manager functionality, though eventually I migrated to the even more amazing Universal Item Selector III which was one of many such replacements. It really was a different era.

Elsewhere in the magazine is a list of Jeff’s favourite games of all time (as of mid-1991). I love that he put his own game at number 1. And then to also include 2 more of his games. What a rock star! Click the image to zoom. Below you’ll find a full list of games with links to read more.

A yak’s favourite games (of all time), 1991

Abandoned project: Soccer for Playdate

by Matt Sephton — Thu, 01 May 2025 14:34:00 +0000

On September 30th, 2023, I was sitting in the cinema waiting for an anniversary screening of Talking Heads “Stop Making Sense” to begin when I got a message from Panic. They asked if I was familiar with Sensible Soccer. Naturally, I was—I’ve played it since its release in 1992, as man and boy. Back in 2000, I’d even made my own arcade-style take on it called Simple Soccer, and in 2002 I designed an official Sensible Soccer T-shirt that was sold on the high street. Panic had no idea about any of this, but luck works in funny ways sometimes.

Panic’s idea was to make a soccer game for Playdate, tied in as a promotional companion to the soccer-infused first-person slice-of-life game Despelote (out today—1st May, 2025). Very cool.

I was super keen, as you’d imagine, and quickly got to work on a prototype (download at the link). It let you move around the pitch, zoom in and out, and switch between different pitch surfaces. I sent it off and asked for a budget and scope. With the expectation set that the project was going forwards and while waiting for a reply, I kept going: I got the ball moving (using the same sort of ball movement trick I first solved 25 years ago and more recently reused for Fore! Track), and had two AI-controlled teams running around the pitch, tracking the ball using the classic Sensible Soccer grid system.

But I never heard back about the budget. So I stopped—just before adding goal-scoring. It would’ve been so cool.

Lesson learned. I now always ask for a contract upfront and of course don’t do spec work. If a client wants me to build something, they need to commit—and at the very least, meet me on the halfway line.

Abandoned project: firework builder puzzle game

by Matt Sephton — Wed, 23 Apr 2025 21:39:00 +0000

I plan to occasionally list abandoned projects that I’ve decided not to take any further.

This one is a prototype for a “firework builder” puzzle game. I was calling it Hanabi, the Japanese word for firework, but I’m not sure I would have stuck with that for the final name.

It’s a visual programming-based puzzle video game along the lines of Human Resource Machine and influenced by block-based visual programming language Scratch.

I submitted it to the Draknek New Voices Puzzle Grant 2024, but was not selected. At the time of submission the core game logic had been proven, with a dozen or so block types supported, and I was learning how to program shaders as I had a very specific way I wanted to present the final firework animation. You can see the paper texture that I was generating using a shader in the video below. I had a dozen or so puzzles designed, including a heart shape which takes some thinking and combining of logic blocks to achieve!

Whilst the prototype was an iOS app—mostly to benefit from rapid prototyping using SwiftUI and to get touch control and easy list management for free—the final game could have been on any platform. The challenge would be user interface, followed by puzzles and visual design.

I gave up on the idea for a number of reasons, including but not limited to harassment.

Video Demonstration

Below is the video I submitted with my entry, dated 2024-10-07. I narrate and run through the concept, complete example puzzles, and talk about the “woodblock print” style of fireworks I was planning and in the process of implementing.

When Playdate Stopped Being Fun

by Matt Sephton — Tue, 15 Apr 2025 21:00:00 +0000

For almost six years, Playdate (a little handheld gaming device with a crank input and 1-bit screen) was a space where I did some of my most creative and personal work. I embraced its quirks, shipped over twenty releases, and explored what a tiny, constrained device could do. It brought me joy, challenge, and a sense of purpose.

But over time, that feeling changed. Following a difficult incident in October 2024 involving targeted harassment—admitted to by the developer responsible, but met with no meaningful follow-up from the community moderators and no reply at the time of writing from Panic—I began to feel increasingly disconnected from the scene. I gave it time, hoped things might shift, but ultimately the silence made it hard to keep building with the same heart.

So, I’m stepping back. Not dramatically—just with clarity. Right now, this isn’t the environment I can thrive in. If that changes, I’d be happy to return. For now, I want to leave a record of what I made. I’m proud of all of it. I’ll continue as a full-time indie developer, but in another castle.

Be excellent to each other. And have fun.

Released Projects

2022-03 Today (the first Playdate thing sold on itch.io)
2022-04 Horse Race
2022-04 Audition
2022-04 Prototypes multi-pack
2022-04 Daily Driver (tech demo)
2022-05 Circular
2022-05 ST-DIN and Supermini fonts
2023-04 Sparrow Solitaire (with Mac Vogelsang)
2023-05 Piskel for Playdate (desktop pixel art app)
2023-07 Mandala
2023-08 Strategies
2023-08 DateDiff
2023-08 YOYOZO (“Best Games of 2023”, Ars Technica)
2023-10 Kye (with Jan Martinek)
2023-10 Super ICARUS
2023-12 Fore! Track
2023-12 See the Sky (with Thoru Yamamoto)
2024-05 Rorschach (featuring mouse control)
2024-10 Bender 2: Bend Harder
2025-03 Shark Turtle, originally created 2023-06

Cancelled Projects

Aero Club—Flight school simulation inspired by Mode 7 and Pilotwings
Beatnik—Rhythm game with interactive music and beat-matched dynamic visuals
Cosmic Trash—Arcade action puzzle with realtime ray-traced graphics
Daily Driver—60fps arcade racing with pre-rendered graphics (reborn as Dream Ride)
Koatari—Pachinko-style arcade game with pinball-inspired visuals, running up to 120fps
Mole Hole—A modern remake of Thoru Yamamoto’s escape-maze concept

Notes

Daily Driver won “Outstanding Technical Achievement (SDK)” at the 2022 Community Awards
Sparrow Solitaire won “Best Puzzle Game” at the 2023 Community Awards
YOYOZO won “Best Arcade Game” at the 2023 Community Awards
YOYOZO was named one of the “Best Games of 2023” by Ars Technica
Bender 2: Bend Harder was nominated for “Best Arcade Game” at the 2024 Community Awards

Thanks to JM, JS, MR, PP, SC for feedback on versions of this post.
Panic were sent a draft of this post ahead of publication.

Shark Turtle: a modern version of SameGame/MaciGame

by Matt Sephton — Tue, 01 Apr 2025 18:44:00 +0000

I’m releasing an expanded version of my game Shark Turtle for macOS and Windows. Grab it at itch: gingerbeardman.itch.io/shark-turtle-desktop/

The result is a feature-rich, native desktop version of SameGame with fast calculation, animated block removal, mouse/keyboard control, incremental scoring, variable grid sizes each with their own high score table, multi-level undo, lots of options, and great music. It’s a lot of fun and ideal to play little-by-little when you have a spare moment, as you dictate the pace of the game turn-by-turn.

About the icon

I couldn’t find the exact licence for Google’s Emoji Kitchen, it’s either SIL as part of the Noto font or CC BY 4.0. But I did find a comment by a Google staffer saying that it would be a good idea to draw a custom version that was less generic—I read that as unique and yours—so that’s exactly what I did. There was no choice but to do this, as I needed a vector version to generate an 1024×1024px icon. I like to think that with the raised eyebrow and slight smirk there’s a bit more personality in my version.

What’s in a name?

This concept was originally released as Chain Shot! in 1985 by 森辺訓章 Kuniaki Moribe “Morisuke” and went on to become very popular, mostly through a version known as さめがめ SameGame. The game was at one time more popular than Tetris in Japan and even made its way onto consoles like the Super Famicom and even as recent as Wii.

In English we pronounce the name as it is spelled: same game. But in Japanese it sounds just like the words “same” さめ (shark) and “game” がめ (sea turtle). A short leap from SameGame to Shark Turtle.

Perhaps the most well known version of the concept, MaciGame まきがめ also riffed on this. I’m not sure of the exact meaning, but I like to think it’s a clever double meaning of something cool in Japanese and it also being a game for Macintosh.

Recovering tile sets

I’d previously recovered a range of tile sets for a download pack I uploaded to Macintosh Garden, but that was done in the Classic Macintosh environment so I needed to redo it on modern macOS to be able to extract the images easily.

MaciGame supported custom tile sets in three formats:

SameGameFormat (160×64, from the PC-98 version of the game)
SameGameFormat2 (192×64, includes additional background tiles)
MaruSameFormat (256×65, includes connected variations and alternate palettes)

These tile sets were popular user created content for 1990s Macintosh fans, given how easy it was to load up a paint app or ResEdit. They were made available for free download at online repositories like NIFTY-Serve, Info-Mac, and on magazine cover mounted media around the world. I found several unique tile sets in my Macintosh Magazine Media archive of vintage CD-ROMs.

The main online source of these is at: vector.co.jp/vpack/filearea/osx/game/puzzle/makigame/ and I automated the clicking of the download buttons using a temporary user script (gist) to redirect to the download page and then click the button. I use PageExtender for such things. I could have gone one level deeper by automating the clicking of all the items on the list page, but I quite like clicking through long lists.

user script at gist.github.com

We can expand these esoteric archives with The Unarchiver. I needed to confirm MacOS Japanese encoding for the filenames that it was unable to heuristically determine. Read more about the madness of classic Macintosh text encodings in the pre-Unicode age.

Next we can convert the PICT resources we’re after with deark. Deark doesn’t have a recursive mode, so we need to wrap it in a one-liner:

find . -type f -print0 | xargs -0 -I {} deark {} -k -od /destination/

I verified those and found some others using DiscMaster. A few stranglers found on the web brought the grand total to 320 tile sets.

De-duplicating

It was obvious that there were some duplicates, so what to do? My first thought was to optimise all images equally, I used ect command line tool for this purpose. After that, still on the command line, we can do a quick de-dupe using the fdupes tool. This helped me get rid of a bunch, but there were still some hanging around.

I wanted to compare files at a pixel level, so wrapped imagemagick in a shell script (gist). We compare each image with every other image. I tried adding pre-checks to the script but they slowed it down and removed the ability for it to run in parallel. Keep it simple wins again.

shell script at gist.github.com

Organising

For organisation sake I wanted to verify and categorise the dimensions of each image. I created a shell script to tag images of specific sizes with Finder colours (gist). I noticed that some converted images were one pixel wider than expected, it turns out that this is a quirk in how those specific image were composed. So I coloured them red and edited them by hand after the fact.

shell script at gist.github.com

All tile sets

Here’s a video of my 5 tile sets plus the 320 classic user created tile sets. Gotta catch ‘em all!

Playdate

I originally wrote a version of Shark Turtle for Playdate back in 2023 and released it earlier this month. The desktop version of the game is expanded and enhanced in the way that desktop apps can be. Those features took a bunch more work and I’ve undoubtedly been working on the platform specific stuff far more than I did on the core of the game.

Buyers of the Shark Turtle for Playdate get the desktop version for free! Head to this bundle.

Enhanced sfxr for Love2D

by Matt Sephton — Tue, 11 Mar 2025 18:23:00 +0000

I’ve made a bunch of usability and quality of life changes to the sfxr.lua demo app.

fix: getDirectoryItems (from a PR)
fix: off by one sample length error (from a PR)
fix: space bar was not playing the sound
fix: selected wave form was being ignored (sounds were always square wave)
fix: loaded wave form not updating the interface (but sound was playing correctly)
add: clone method added to sfxr.lua
add: history form with list of previous sounds, save current, and undo/redo
add: “play on changes” so that any time you adjust a sound it plays automatically
add: keyboard navigation in file picker (A–Z: jump to files, Enter: choose, Esc: close picker)
add: window title reflects the most recent loaded/saved file
add: window title and filename reflects last operation
add: file selector shows data directory path
add: unified save directory across platforms

You can get it at: gingerbeardman.itch.io/enhanced-sfxr-for-love2d

At some point I’ll fork the project on GitHub and file some PRs with my changes, but the repo for it seems very dead so I’ll wait until I hear back from the owner. Source code is at the above link.

Old Codes, New Releases for Playdate

by Matt Sephton — Tue, 11 Mar 2025 16:24:00 +0000

As I sadly move away from game dev on Playdate, I’ve released a couple of interesting old things…

SHARK TURTLE

This is a version of SameGame (さめがめ) originally released under the name CHAIN SHOT in 1985 by Kuniaki “Morisuke” Moribe for Fujitsu FM-8 home computer. The concept is as old as Tetris, perhaps even older, and at one time SameGame in its many guises was more popular than Tetris in Japan. One version had an active modding scene and some had strategy guide books.

It was submitted and rejected in the first wave of submissions to Playdate Catalog. At one point the plan was to wrap this in a theme/concept and give it the same sort of love that resulted in the great experiences of my other games like YOYOZO, Fore! Track, Bender 2: Bend Harder, but for one reason or another it never happened.

What is here is a fully-playable, feature-rich, albeit “no frills” version of SameGame with fast updates, solid controls, and great music. It’s a lot of fun and great to play little-by-little when you have a spare moment, as you dictate the pace and progress of the game turn-by-turn.

gingerbeardman.itch.io/shark-turtle

NEW WORLD

This is an interactive music track where you’re the DJ. You control various instruments and vocals, doing live mixing of the track. It’s really fun to play with!

It is a technology demo that was put together as part of a pitch for a game. Whilst the game never came to be, an improved version of this technology went on to be used in Bender 2: Bend Harder for the dynamic background patterns that animate to the beat of the music.

gingerbeardman.itch.io/new-world

More games!

All my Playdate games:

YOYOZO
- read about it being a GOTY 2023
Sparrow Solitaire
- read the making of
Bender 2: Bend Harder
- read the making of
Fore! Track
- read the making of
Super ICARUS
- read about its dynamic music

Making games on iPhone/iPad using Lua & Love2D

by Matt Sephton — Thu, 20 Feb 2025 07:37:00 +0000

I wondered how feasible it is to make Love2D games “on the go” (on a train, in bed, etc). Often I want to try a quick sketch, work up a prototype, or simply verify an algorithm. I’m happy to say it’s possible!

Runners

Love2D Studio

Available since Jan 2024
Free apps.apple.com/gb/app/love2d-studio/id6474188075
this allows you to manage love files and run them on iPhone
Love2D errors can even be copied to the clipboard!

Love2D Game Maker

Available since March 2024
Paid apps.apple.com/gb/app/love2d-game-maker/id6476174098
TestFlight testflight.apple.com/join/bCLmQKfQ
from the creator of LuaLu (see below)
comes bundled with a handful of demo games
Pong tutorial

Editors

Textastic (since 2010)

Paid apps.apple.com/gb/app/textastic-code-editor/id1049254261
text editor with autocomplete and function picker

Kodex (since 2017)

Free apps.apple.com/gb/app/kodex/id1038574481
text editor with minimap

GoCoEdit (since 2016)

Paid apps.apple.com/gb/app/gocoedit-code-text-editor/id869346854
text editor with autocomplete

Runestone (since 2022)

Free, limited apps.apple.com/gb/app/runestone-text-editor/id1548193893
text editor with clean user interface

Lua IDE (since Feb 2021)

Free apps.apple.com/gb/app/lua-ide/id1549382090
this app provides QuickLook support for Lua files
at some point you’ll need to check the contents of a Lua file in Files app
it also features the full Lua docs (though I use a self-built version of Dash doc viewer)

LuaLu (since Apr 2013)

Free apps.apple.com/gb/app/lualu-repl-learn-lua-coding/id638219114
sometimes you just need a Lua REPL prompt to figure out a formula or do a quick experiment
features solid debugging support

Other Lua IDE

If you’re into Lua but not into Love2D then you might try Codea for iPad.

DREAM RIDE for Sega Dreamcast (and emulators)

by Matt Sephton — Sun, 05 Jan 2025 23:59:00 +0000

Over the Christmas break I had a spare week after a trip to Ireland was cancelled. What should I do with the time? I was already aware of the upcoming DreamDisc ‘24 game jam and had done some reading a couple of months back scoping out a Lua-based SDK called ANTIRUINS Engine that looked familiar enough to me with my experience of LÖVE (love2d) and Playdate SDK. But what should I make with it?

If I could get something fun up and running as quickly as possible it would prove the point and keep me motivated. Sounds like a plan. Also, it’s easier to make something that has already been planned out, so all the effort goes on implementation rather than design. I remembered my unreleased game Daily Driver…maybe I could get those little cars moving around the screen? But what would make it more Dreamcast? Simultaneous 4-player action and CPU opponents! OK, let’s do this!

It took a bit of effort to get the build process setup, but after that I hit the ground running. I got the physics and 4-player control working pretty quickly. Then the sprites went in, albeit in the wrong colours. Physics equation and sprites are the only two things shared with Daily Driver. Next I added a variety of game modes, power-ups, new sounds, all within a few days. Then I picked at it over the next week to polish it as much as possible before the game jam deadline. I thrive on deadlines.

Many thanks to Bertholet, author of ANTIRUINS Engine, who has done a great job and was very gracious with his time helping me through the initial hurdles.

I’ll do a full post-mortem and “what’s next” after the game jam results are announced. But I’m really happy with how it turned out. The cars look great in colour, and even with 8 of them on screen things are a rock solid 60fps, I really need to see how far I can push things.

Download

gingerbeardman.itch.io/dream-ride

Play DREAM RIDE on real hardware (tested on my original imported NTSC-U Sega Dreamcast from 1999, fitted with a GDEMU) or in an emulator on your favourite console or handheld (tested with Flycast on macOS, GameForce Chi, Powkiddy RGB30, TrimUI Brick, and a modded Nintendo Switch).

Future versions of the game with improvements and new modes will require payment, after all I’m a full-time indie developer and my caffeine intake needs to be maintained. Thanks for your support!

Video

Below is a video where I forgot to switch audio source so it recorded audio through my Mac’s mic. 😅

Bender 2: Bend Harder for Playdate

by Matt Sephton — Tue, 08 Oct 2024 17:00:00 +0000

Back in 2012 I wanted to make a quick game for the AGBIC game jam (A Game By Its Cover; make a game inspired by the imaginary cover art from the Famicase exhibition). There’s only one rule for this game jam, which is taken very seriously: respect the wishes of the original artists, and don’t appropriate their designs without consent. Otherwise you’re free to do what you want. And you can choose a cover as inspiration for your game from the entire archive of Famicase entries, so every year there are more and more great covers to be inspired by.

2012

I had a browse of the Famicase entries and picked artwork titled Bender, by 清水昭利 Akitoshi Shimizu, from the 2011 submissions, and set to work… thinking. One morning I had the crazy idea to impose severe constraints to help my ideation: I should make the game using only CSS transitions (and some simple JavaScript logic to control the game state and flow). I have no idea why this seemed like a good idea, but it worked!

The result of two days work was a web game called Bender released 12th July 2012. It was fun to make and devilishly addictive. The web game still works today, on desktop and mobile, though the controls are prone to getting stuck from time to time for reasons I’ve not looked into.

2022

Fast forward 10 years and I decided to do a pretty straight port of the web game to the Playdate handheld, that was 20th May 2022. I coded it from memory/feel, just for kicks, not that I had any choice as the available technologies are so different. It was a very bare bones game, with no music and messy code, but it was a test to see if I could release a game in a day. I did.

Seeing as original Bender web game used CSS for all graphics and animation, and a little JavaScript to control the game flow, I had wondered how I would build Bender with the Playdate SDK? I settled on using only primitives and dither patterns to draw all the elements, an approach that I have continued to refine in subsequent games such as my GOTY 2023 accolade and award winner YOYOZO, the detailed rendered look of Fore! Track, or the stark minimalism of Super ICARUS.

Each side of the bar is a thick line, with “butt” cap-style. To give the illusion of the bar bending I draw a circle at the origin or common point of both lines. A little bit of trigonometry was all that was needed to get the lines bending correctly. The benefits to this approach are many, such as: no images, no sprites, always smooth edges, better performance. Animation also does not use the Playdate SDK, but rather I track the positions of screen elements and move them based on some rules and algorithms.

I use dithering to provide visual effects: animation of snapping and motion blur of the moving line. There’s also a zen mode that disables visual effects and the toasting words (which are randomised from large lists).

2023

I submitted Bender for consideration for Playdate Catalog when the service launched, but it was rejected for being “too simple”. After some lengthy contemplation my takeaway from the rejection was that it meant there was not enough meat on the bones of the game, rather than anything specific against the central gameplay mechanic which is beautifully simple.

Fair point. Though I did say I would expand the game, add music and so on, I learned that it’s difficult for people to imagine how you’re going to expand on a simple concept. You need to show them. It took many months—about a year and a half—for me to find the time and energy to revisit Bender.

2024

The end result is Bender 2: Bend Harder. The new game has been remade, from scratch, right down to the fonts. And it’s packed with new things: friendlier gameplay, more obvious goals, multiple game modes, a deeper scoring system, awards/achievements, multiple secrets/easter eggs, online score boards, improved graphics, dynamic music and sound including elements that react to the beat of the music, an imaginary scenario to provide a bit of world-building, and much more besides! At ~2000 lines the source code is over 4 times the length of the first version’s ~500 lines, just to give you an idea of how much more logic there is in the new game. Not that lines of code is a good metric, but you get my point. There is much new!

There are elements to the game that I would usually disclose the technical details of—my process, tooling—but I’m currently doing my utmost to protect my “vibe” so that won’t happen today. This is why we can’t have nice things. Maybe at some point in the future, but no promises.

Anyway, I’m really happy how this game has turned out. Can’t wait to see some activity on the leaderboards! Get it at play.date/games/bender-2-bend-harder/ and I’ll see you in the high scores!

As usual, promo artwork is by vxcl with 1-bit equivalents drawn by me.

“If at first you don’t succeed, try, try again.”

My other games for Playdate

This brings my total of games on Playdate Catalog to 5, the others being:

YOYOZO
- Best Games of 2023 (Ars Technica)
- Best Arcade Game (Playdate Community Awards 2023)
Sparrow Solitaire
- Best Puzzle Game (Playdate Community Awards 2023)
Fore! Track
- the first colour Playdate game?
Super ICARUS
- an innovative hybrid survival-racing game

I also have a bunch of other games at gingerbeardman.itch.io for both Playdate and Mac/Windows.

A haze of inspiration

by Matt Sephton — Sat, 28 Sep 2024 17:46:00 +0000

A long time ago in a galaxy far, far away I had to give an impromptu presentation about something I didn’t know much about. The goal of the task was to see how well we could ad-lib a presentation under pressure. Everybody in the room had to think of a topic whilst waiting for our turn. The person next to me couldn’t think of anything and asked me what I had thought of, I said “the off-side rule” (it’s a football/soccer thing, don’t worry about it). Then that person was called before me and proceeded to give a presentation about… the off-side rule. I was mortified, and when my turn came I was still so shell shocked that I can’t remember what other topic I picked was, or even how the rest of the day went. Afterwards I chatted with the person—at the time we were good friends and continue to be to this day—who told me when their name was called “a haze of inspiration” came over them and the only thing they could think about was the topic I’d just mentioned. And so it was.

From whence it came

Just as a haze obscures clear vision, the creative process can blur the lines between our own ideas and those we’ve encountered. We can be inspired by everything around us, in an unconscious way. I’d venture to say that this is the most common form of inspiration, you’re just existing and soaking up as much as you can. In some ways it is automatic and unavoidable. As a result, we share a lot of common experiences and so this sort of natural inspiration can lead to the Zeitgeist, with similar ideas emerging simultaneously in different places. A sort of opposite to this is the concept of incremental innovation, where small changes happen to existing ideas that are occasionally enough for it to feel new. And then there are the types of new ideas that can’t be easily found elsewhere, that are provably innovative and totally new. By definition the haze of inspiration is a very grey space, difficult to navigate, and open to interpretation. There’s no absolute right or wrong, unless you are in a position to flex legal muscles. Below is my own interpretation of how I see things, it’s expected that you won’t agree with all of it.

Navigating the haze

I often pause and examine my own creative process. This serves a number of purposes: it helps me notice opportunities for improvement that might otherwise be missed along the way. If my head is down, I might not notice that I can save time by refining my workflow, or gain new understanding by looking at a problem from a different angle or through a different lens.

Tracking or keeping a record of things you find inspiring is very useful. Some might use Pinterest, bookmark managers, scrap books, print outs, notebooks, folders of saved files. Whatever works for you, really.

At this point I feel it’s worth mentioning the challenge of distinguishing between inspiration and imitation. We can all be inspired by something, but how we choose to act on the inspiration can be a challenge. How much you take away from the inspiration might mean you cross the line into imitation. The difference between the two is open to interpretation, and legally it’s a very grey area, so it requires understanding of our own moral compass. More on that later. But for me the difference can be summarised by how comfortable I am in the knowledge that I put enough of myself into the idea, then I’m inspired. If I don’t put enough of myself into the idea, then I would call it imitation.

Original thinking

Thinking can be difficult, and coming up with original thoughts is even more difficult. One could ask if it’s even possible at all to have an original thought? I think it is, though it’s often said that “everything is a remix”. My personal feeling is that an original thoughts can only come when you take yourself out of the equation. Famous artists used drugs, alcohol, and more. Karl Wallinger of the band World Party (check out the album “Goodbye Jumbo”) famously “never worked straight” (~25:30), he would always smoke a joint with the idea being “to get yourself out the fucking way”. John Lennon, too, though perhaps with harder stuff.

On the other hand Quincy Jones used a technique where he would get himself into what he called “the alpha state”, a kind of liminal space between being asleep and awake, where he would routinely have all of his best ideas. Miles Davis used improvisation. Salvador Dalí used a technique he called “paranoiac-critical method” to access his subconscious through fear. David Lynch uses meditation. Brian Eno used a deck of cards called “Oblique Strategies” to add constraints to the creative process. David Bowie used a “cut-up technique” (also called découpé), adapted from one used by William S. Burroughs but with much older origins, where existing works were cut up and rearranged into new works. My current favourite pop star, Lo Lauren, creates songs in 10 minutes over a found beat using three suggested words to focus the topic of the lyrics. It’s encouraging to realise that there is more than one method and that you can most likely find one that works for you.

My own method is to recede into the haze itself, into darkness. The simple act of laying down in a quiet room, and closing my eyes for a few minutes is usually enough for me to navigate through the haze and come out with an original idea, solution to a problem, name of a new product, or whatever.

Research

For me, outside of the actual act of creation, this is most fun part of the creative endeavour. The world is literally your oyster. Given that 99% of stuff happened in the past, I prefer to consult historic sources. Old magazines, books, interviews, and of course the video games and music I grew up with are now old enough to qualify. Ha! The most important thing here is to look outside your field of view. It’s easy to be inspired by the things right in front of you, but more difficult—and more rewarding—to be inspired by things further afield. Reach deeper, go further, get outside your comfort zone, take the road less travelled.

Once inspired, or locked on to an idea, it’s important to do some due diligence to check that it’s unique, or not protected by any laws or copyright, or even just to check that a name is free enough to be used. Domain names can be taken, hashtags can be already used. My funniest example is when I was originally calling my hit game YOYOZO by another name: YOYOZORA, which is a combination of the words YOYO (the toy) and YOZORA (the Japanese word for night sky). I quickly changed plans when a hashtag search revealed somebody posting dick pics.

It’s worth noting that some creators intentionally avoid external influences during their creative process, believing this leads to more original work. Nick Cave, for instance, avoids listening to music while writing to prevent unconscious imitation. Filmmaker Jim Jarmusch tries not to watch other films, or even the scenes he has already shot, while working on a project to maintain his unique vision. Even in tech, Steve Jobs was known for his “not invented here” syndrome, often preferring to develop ideas from scratch. This approach isn’t about ignoring the world entirely, but about creating a space where your own ideas can flourish without immediate external influence. It’s a delicate balance – you want to be informed, but not overly swayed by what’s already out there.

Attribution

By now you’ll know in your heart if what you’re dealing with is imitation or inspiration. What next? Methods of attribution might include: direct credit, “inspired by”, footnotes, a mention, etc. Or if the inspiration is barely visible at all there might be no attribution needed. There’s that moral compass again.

Attribution can add value to your work, as it shows not only are you compassionate and considerate, but that you value the creativity of other people. In some fields, like music and visual arts it’s perhaps more difficult to do some forms of attribution. You can’t put a list of credits on a painting or in an audio recording, but you can put them in supporting material. There’s always a way.

I won’t spend much time on the topic of “AI”, or to be more precise “generative tools”, but it’s worth mentioning them briefly at this point as they lack any method of attribution which of course is a problem. How big a problem depends on how much originality is in the result and that is a very difficult thing to measure, though I would say not impossible at least regarding the series of prompts that led to the output. Anyway, the results from the use of such tools is also open to interpretation and perhaps this is even more of a grey area than the haze of inspiration itself.

Communication

So how do you figure out how best to attribute? By reaching out and having a conversation. But that’s easier said than done, I think.

I’ve never gone so far as to write a formal letter or anything like that, I’ve been more casual about it. I’ve written to game developers whose games I wanted to port. Having something for them to see is always good—a prototype—and explaining the expectations and reach of the agreement will make everybody feel comfortable. There will surely be some anxiety and reticence for an idea to be taken by somebody else. In my experience I try to frame it in as positive a way as possible. Answer the questions they might have before they even have a chance to think them.

Timing is always key. I always make such an approach as soon as possible. With my game Fore! Track, I contacted the developer whose game I was inspired by as soon as I had a prototype up and running. At that point, if they’d have objected to the idea I wouldn’t have lost much time. If I’d have contacted them with a finished game, it might not have made much difference to their decision making process, but I would have had more invested in it and more to lose. Contacting somebody with only an idea for me feels like the wrong way to go about it, as ideas are relatively easy and execution is everything.

With such discussions it’s important to have open conversations, which will can lead to mutual understanding and respect. Leave your ego at the door and bring truthfulness, compassion, open-mindedness and you will be rewarded. Misunderstandings will inevitably happen through the course of the conversation, but by being open both parties can rest assured that there will only be movement towards resolution rather than escalation.

By far the best outcome of such open discussions is the fact that two heads are better than one so the solution is almost always better than the original idea or approach. This means it’s in your own interests to have these sorts of conversations as often as possible. They might lead to better ideas, collaboration, partnerships, refinement, suggestions you would never have thought of, about turns, and of course rejection.

Rejections are always hard to take, but I’m a firm believer that with time, and enough water under the bridge, that newer and stronger ideas will emerge. For me that can take weeks, months, even years. But every time it happens I think “the Universe provides” and smile.

Ethical considerations

So, about that moral compass I keep mentioning. Ideas are more than a feeling, especially when executed and turned into something that can be seen, heard, played. They turn from intangible to tangible, and this process is guided by your moral compass.

When it comes to that “haze of inspiration”, intellectual integrity is the needle on your moral compass. It helps you navigate through the fog without stepping on anyone’s toes. It’s about asking yourself not whether you could use an idea, but whether you should. It’s about being upfront about what inspired you, maybe asking for a thumbs-up if you’re borrowing heavily from someone else’s work, and generally just being a decent human in the creative playground. By sticking to these principles, you’re not just keeping your own nose clean. You’re helping to create an environment where ideas can bounce around freely, where people aren’t afraid to share their cool thoughts, and where everyone gets their due credit. It’s like keeping the idea ecosystem healthy, you know?

Intellectual integrity is really just about not being a jerk with other people’s ideas. It’s about giving credit where it’s due, trying to get your facts straight, and not twisting things to fit your narrative. It’s also about owning your work, warts and all. If you messed up or your info isn’t 100% solid, just say so. Nobody’s perfect, right? And here’s an important addition: be open to other viewpoints. Just because someone disagrees with you doesn’t mean they’re wrong (even if you really, really think they are).

All ideas build on previous work. I subscribe to the idea that everything is a remix, and I also know that being cool, kind, and considerate costs nothing. Being uncool, unkind, or inconsiderate can cost you more energy in the long run. Time teaches that particular lesson, so consider it being mentioned here a free power-up. We are lucky enough to be able to stand on the shoulders of giants, so it’s important to not make a mess whilst we’re up there.

Personal growth

Growing is hard and with it come a lot of pains. Road blocks, wrong turns, bad luck, but hopefully it will trend towards progress.

One key aspect of growth is synthesis. Plants turn light energy into chemical energy through photosynthesis. The output is vastly different to the input. I think this is a useful lens through which to look at techniques for turning influences into something truly novel. You can look at the The Great Wave and print your own version of it if the goal is to imitate it as closely as possible (as David Bull has done), or you might choose to draw it instead and replace the crests of the wave with bunny rabbits (as kozyndan did), or you might sculpt it from digital clay and add some mahjong tiles to it (like vxcl did for my game Sparrow Solitaire).

I like to think of this synthesis as a road—you can turn off at any point but the further you go the more wonderful the sights will be. I’d like to make a short detour to mention constraints and how they can foster creativity. Whilst the road might be long, it’s not sprawling but a single direction. Navigating a complex road system would be much more difficult, so I encourage you to impose additional constraints if there don’t seem to be enough, or if the way forward isn’t clear.

Any period of not creating that you end up in is just as important as a period of intense creativity that you might rather be in. My favourite quote about this (by BT, the musician; I’m paraphrasing) is that creativity comes in waves, sometimes you’re in the doldrums and not much is happening but there is no doubt that the next wave will arrive at some point, so you just have to be ready to jump on and ride it when it does!

It’s a fine balance between being influenced and being derivative. Sadly your moral compass is not fitted with a warning alarm of any sort, so you’ll have to rely on your heart, head, and those of others to give you guidance here. Having respect for others’ ideas can be considered a constraint in and of itself and can actually push you to be more innovative. Being derivative is a trap to be avoided, not only would you not gain as much personally from the endeavour but you might also inadvertently dilute the idea, brand, vibe of the originator. You should instead consider the person who has inspired you as a mentor, supporter, team mate, power-up, voice of reason, or even shoulder to cry on. The important take-away is that they are there to help because, hey, they were there first.

Embracing the future

With enough searching, or metaphorical travelling, you’ll be able to find your own voice, style, brand, or “vibe” as I prefer to call it. I’m a bit of a hippie at heart. The ultimate goal is to find that rug that really ties the room together. Then cherish it, feed it, sculpt it, even defend it if the need arises. You’ll have the ideas, make a dent in the universe, and develop a vibe that other people will be influenced by, and hopefully they will take the right path and be inspired by it rather than choose to imitate it. Perhaps that’s the ultimate goal? It’s your turn to set a good example for those that come after you.

Excerpt from The Big Lebowski (Ethan & Joel Coen, 1998)

This behavior is by design

by Matt Sephton — Wed, 28 Aug 2024 21:46:00 +0000

Back in the mid-1990s I was using Windows 95/98 and running up against bugs, problems, driver issues, unexpected things happening. I would often end up on the Microsoft Knowledge Base support web pages, where the issue would often be accompanied by the line “This behavior is by design”, which remains in use to this very day.

This mantra has stuck with me over the years, and it came to light in a recent discussion about the design of Lucas Pope’s Mars After Midnight for the Playdate handheld game console. It has a black interstitial screen between some scenes, which was enough to get me thinking about the intent behind the design of a screen that contains …nothing at all.

To be or not to be

I’m as guilty as anybody in wondering why certain things are how they are in the software, apps, or games I’m using. It’s a fundamental truth about software development that often goes unnoticed by end users: every aspect of computer software is the result of deliberate human decisions, from the broadest feature sets right down to the placement of individual pixels.

This intentionality in software design has profound implications. It means that the user experience—whether frustrating or delightful—stems from choices made by developers, designers, product managers, and perhaps even the users themselves. How enjoyable or not the software is to use, the accessibility (or lack thereof) of user interfaces, and even the bugs and glitches we encounter are all products of the human decision-making process. This perspective challenges the notion that technology is impersonal, as there are human minds and motivations behind every aspect.

However, it’s worth noting that while every element is designed, not all design decisions are made with equal deliberation or foresight. Some choices are carefully considered and tested, while others might be rushed, overlooked, or based on flawed assumptions. Additionally, the complexity of modern software means that interactions between different design choices can sometimes lead to unintended consequences. More on that later.

Examples

Given that we could go on forever with examples, here are 10 off the top of my head:

whether or not there’s a black screen between scenes in a game
size of padding or border around the edge of a dialog box
radius of a rounded rectangle
spacing or kerning between specific letters of a font
aliasing or anti-aliasing around the edge of a circle
speed at which an object moves across the screen
what happens when you press a button or do an action
wording on a menu item or dialog box
order of two competing buttons that mean cancel or proceed
the number of digits used to represent a high score

Making a game involves deciding on thousands upon thousands of tiny things like this. I love it.

Happy accidents

While most aspects of software are meticulously planned, sometimes unintended behaviors or glitches lead to serendipitous discoveries. These “happy accidents” might result in a breakthrough in design and can become beloved features if developers choose to keep them.

A famous example is the “creeper” in Minecraft, which resulted from a coding error while creating pigs. The game’s creator, Markus Persson, liked the mistaken entity so much that he decided to keep and refine it, turning it into one of the game’s most iconic elements. Similarly, the wavedash technique in Super Smash Bros. Melee was an unintended consequence of the game’s physics engine, but it became a crucial part of high-level play after creator Masahiro Sakurai opted to leave it in. These instances remind us that even in a world of intentional design, there’s room for the unexpected—and the human decision to embrace and incorporate these accidents can lead to some of the most innovative and engaging aspects of software.

Deciding by not deciding

Some might argue that you don’t make a choice when you accept the default settings, like the white background and font in a Word document. Or you might make the same argument about using an existing framework, package, template, or SDK in your software. However, I would argue that by using the defaults you are implicitly agreeing with the designers’ choices. As a user you become complicit in the design decisions simply by not changing them.

This tacit agreement with default settings is another aspect of design that often goes unnoticed, yet it plays a significant role in shaping the end product. Somebody at Microsoft decided that with Office 2007 the default font would become Calibri, replacing Times New Roman which had been the default since forever. There’s no better example of the implications and reach of a single human decision.

Thinking about the future

At the end of the day, computers do only what we direct them to do, so every aspect of software has been touched by the hand of a human. With the rise of machine learning and “AI” coding assistants, that human touch may become increasingly abstracted from view. However, rest assured it is still there. Even in systems that utilize artificial intelligence, humans are designing the algorithms, curating and creating the training data, and making decisions about how to implement and apply these tools. The fundamental truth remains: behind every line of code, every pixel, and every feature, there are human decisions shaping our experiences.

Pitching a game based on the CICLOPE 2016 Opening Film

by Matt Sephton — Sat, 01 Jun 2024 14:30:00 +0000

A little over a year ago I wrote a screenplay/pitch for a video game based on an animated short film created by THE LINE Animation Studio: the opening film from the CICLOPE Festival in 2016.

I’d like to make this game but I need support to do so. Until then I figured I’d post it here for all to read.

CICLOPE

Think of this as the game trailer. Watch it before or after reading.

More information on the making of the animation at thelineanimation.com/work/ciclope/

Game Overview

Our task is to transport the package to its destination.

We start the game not knowing what, why, or how.

The story would involve the environment and its occupants, across many scenarios. We would work together to overcome problems and allow the drone to complete its journey.

The overarching theme of the game is that we could and should all live in harmony together, make use of what we have around us, treat each other and the Earth with respect, and live a happy life.

The experience is not a walking simulator, it is more than that. It is a truly interactive, guided story, with puzzles and multiple paths.

Scenarios

These are the scenarios shown in the film and story boards. I’m giving them names here, but I do not see them being named in the game as it will strive to use as little text as possible.

Delta

We first see the drone flying above an River delta at low tide, arriving from an unknown location. We are immediately tasked with flying the drone, following the strand of river that we are on. The camera angle is locked to point only down. We do not see that we are carrying a package.

On subsequent play-throughs we would fly low to pick up some “gold dust” on the package we are carrying for a special bonus in the ending sequence.

After a while everywhere starts to look the same, every tree looks the same, every bit of riverbed looks the same. The small river we have been following starts to disappear, eventually branching into another which does the same. We realise that we are lost.

Picking up clues from the environment, we figure out that the best course of action is to follow the direction in which the water is flowing, eventually reaching the open sea.

River deltas have proven to be important throughout human civilisation, as they are major agricultural and population centres. They could be considered the cradle of civilisation.

We cross the open sea only to encounter an electric fence, we have to seek the help of animals to find the hole in the fence and continue our journey. Near the hole in the fence we find a small satellite dish and overhear some broken comms/broadcast that we cannot understand.

We see our reflection for the first time in the water and see a label stencilled on our housing: D3174 (“Delta”).

we see: beautiful landscapes, ourselves
we feel: found, lost, new beginnings, purpose

Opening Credits

This acts as a tidy segue between river delta and desert, showing star-filled sky and sun-bleached-sky signifying that much time has passed and distance has been covered.

Here it is revealed for the first time that we are carrying a package.

we see: the vast expanse, the wide world, stars, sun, endless vistas
we feel: excited, inquisitive, small, ill-equipped

Desert

After flying through the desert for a while, exploring structures, a sand storm approaches and we are forced to take shelter in a small hut at the base of a felled pylon. Here we are taught first hand how we can drop the package if we need to (but only on places where X marks the spot) and how we can pick up and combine items. We learn how to craft new objects with the things we find around us.

After the storm has passed (coincidentally as soon as we have completed the tutorial objectives) we are allowed to go back outside. We discover lots of new things: a partially covered megalithic monument where we are able to find a replacement battery, and a satellite dish and broadcasting station.

Similar partially covered monuments are visible in all locations, and are a reference to technology and discoveries that have been forgotten in the name of progress.

We need to use our new crafting ability to reconnect the equipment. We then receive our first communication/broadcast. But what form does it take?

One idea would be for it to be famous radio broadcasts in foreign languages, celebratiing technological breakthroughs related to the current scenario. eg. the desert could be Africa, and the radio broadcast could be about, say, CT scan etc.

We are also given our first new ability, an Augmented Reality (AR) overlay on our camera view allowing us to see certain invisible things in the environment such as hot air drafts.

we see: sand storm, crafting, invisible stuff
we feel: accomplished, empowered

Oasis

The transition out of the desert takes the form of an encounter with an oasis.

This gives us the opportunity to have a flash-back or flash-forward, somewhat acid trip sort of interjection in the story. Half through our AR glasses and half through the scene. We see elements of what has happened on Earth to leave the landscape in such a ravaged state. It is not Nuclear war, or AI, but simply a result of our over-use of Earth’s resources.

We are left wondering… what was real and what was imaginary?

we see: psychedelic, trippy, quick-cut flashes from another time
we feel: confused, lost, humbled

Solar Farm

We see something on the horizon, something that looks like a city. Perhaps our experience at the oasis had foreshadowed this? We instinctively head in that direction, and it turns out to be much closer than it looked because it is much less tall than it looked at a distance.

We have encountered a solar farm, with panels stretching as far as the eye can see in every direction.

In fact the game makes sure it is impossible to fly away from them, see Notes section at the end of this document.

After our ordeal in the desert we have a problem with our battery and solar panel.

We need to figure out where in the solar farm we have to go, maybe there is something here we can use to craft a solution. Racing against daylight and the approaching shadows of nightfall we are forced in a certain direction. We realise we can follow the cables on the ground much like we followed the rivers at the delta. We end up at a hut somewhere in the solar farm.

We immediately find a new battery, but replacing our solar panel will be more difficult. Another satellite comes online and we receive more comms. We see signs of a power source radar, we have to find it and pick it up. But how?

We need to build a Rube Goldberg-style contraption involving: a fragment of our existing solar panel, the reflection of the sun to concentrate light/heat, the water tower, and of course the drone. The water tower ruptures and water floods onto the land and down a previously unseen drainage system. We fly through the pipes into an underground facility where we find a replacement solar panel and our power source radar.

we see: signs of sustainable technology, signs of an advanced human race
we feel: empowered, less small, hopeful

Coastline

We see the megalithic monuments for the first time.

Our radar picks up its first sign of power, but we cannot reach it.

We need to fly to top of the tower, in stages as we do not have the power to fly at once. When we get to the top we realise we are low on battery. The only things up there are a rock and a small plank of wood. We have to position the wood on the rock and then land on it like a see saw. The wood then flips over and lands on top of us, interlocking with our frame to create wings.

We dive from the top of one monument and glide over to the other monument, to sunlight and safety, and a replacement power source.

The gliding in this stage is reminiscent of hang-gliding in Pilotwings (SNES, N64, DS) where you need to fly through rings of dots and catch updrafts. These can be see thanks to the item we obtained in the desert.

we see: strange monuments to lost technology
we feel: mysterious, capable, resourceful

Cut Scene

The transition from coastline takes the form of an introduction to our Augmented Reality camera.

We see AR overlays of ravaged landscape showing aspects of how it used to be.

Volcanic

We use two abilities of our AR camera in this tricky scenario. We need to find a path through the steam that avoids heat, and use updrafts to reach difficult heights.

We reach a set of six communications towers but they are offline. One of the six towers is broken and we need to fix it.

We need to find some metal, smelt it in the heat, pick it up when safe to do so, find wire and a way to cut it, and all to fashion a replacement resistor. We also need to find, untie and otherwise free various wires, and eventually re-plug them to get the system powered up.

We get the system online and hear more comms.

we see: heat haze, AR views
we feel: relieved, capable, hot!

Mountains: valley

We see the broken monorail. In the distance we can hear the sound of cattle bells.

We pick up a power signal and after some effort removing a rock fall, we enter a tunnel and find a small monorail cart. It’s a close cousin of the drone, for the purposes of delivery and operated by the same company. But it’s much older, from the days before drones.

We have to go through the waterfall to collect the battery. Now we have two options, we can leave the area with the battery we have found, or we can go back to monorail cart and give it the battery.

By donating the battery the monorail cart bursts into action and we discover that it is part of a much larger system. The various parts all come to life and start to reconnect the monorail track. This results in a special bonus in the ending sequence.

We are also given a new ability for our kindness: language translation which will allow us to understand the contents of all the broadcasts in the game. These abilities can be kept for New Game+ allowing us to see the contents of the earlier broadcasts which add an extra level of depth to the story line on second playthrough.

After the task is complete we feel as big as the mountains and capable of anything.

we see: the bigger picture, traces of other useful technology
we feel: huge, helpful, part of something bigger

Storm

This scenario not only shows some fancy weather effects, but also shows us that we can save battery power by switching off our light and by not using our other abilities.

We manage to locate a hole in the electrified fence. Once we fly through the storm abates. We are low on power but pick up a radar signal locating a power source. We fly towards it but our battery is depleted giving us no choice but to crash land. The music has been building all this time, becoming more somber, but now it falls completely silent. We hear the strained whine of motors that do not have enough power.

The image fades to black, and we think it might be game over.

A short while later the scene comes back and it is day time. We are in the opening of a cliff-side cave. We see ancient murals depicting a peaceful world.

We can photograph these with our AR camera to get a special bonus in the ending sequence.

Enough sun has entered the cave to recharge our battery enough for us to continue our journey. From our current vantage point we can see we are almost at the peak of a mountain range. The only way is up!

we see: rain, lightning, the end?
we feel: relieved, born again, recharged

Mountains: peak

We are now far off route, but the top of the mountain has been calling us.

We encounter indigenous people who have perhaps never seen a drone. Or maybe they are trying to take the package? We keep our distance and notice they seem preoccupied by something else.

There are markings on the rocks, including our familiar X marks the spot the recurring theme showing the place where we can set down our package and it will be safe.

The people are looking for their pet. They understand that the drone might be able to help them and they shout in a language the drone does not recognise, but the new ability gained at the Valley means that we can understand them. We can see the pet stranded on a high peak.

If we fly directly there we will be in too much shadow and our battery will deplete. We figure out that we need to fly between crepuscular rays and avoid shadows. So with some aerial acrobatics and some picking up and dropping things to help the animal come closer, we are able to rescue pick it up and carry it back to the people. They reward us by interpreting the photo we took earlier and show us which way we need to go.

we see: people, animals, the path forward
we feel: helpful, helped, oneness

Forest

We fly down the far side of the mountain. The scenery changes from snow covered peaks to lush forests. Never have we been able to fly so freely.

Flying below tree canopy means less direct sun light and makes parts of this scenario more difficult. Imagine the Star Wars speedbike sequence.

We are receiving radar signals for multiple power sources. One by one they drop off the radar, by going out of range, leaving us with only one. Little do we know that this is our last waypoint.

We are hit by a catapulted projectile and crash to the ground. We see the crashed drone, open package, and the child picking up and using the music box.

we see: a human, a child
we feel: useful, happy, complete
we hear: the music box

FIN

The end sequence is similar to the opening sequence, with the addition of humans. We see each location that we encountered in the game, but they are changed because the world is rebuilding. There are many drones, monorail systems and power source to be seen.

Delta: is once again the cradle of civilisation, busy with people and agriculture
Desert: is back online, populated and a hub of activity
Solar Farm: is now fully functional and even larger than before
Coastline: offshore wind farm, the monuments have been converted into windmills
Volcanic: we are harnessing the volcano heat and steam for power
Valley: we see a busy monorail system, and the waterfall and river is a power source
Storm: in daylight we see the electrified fence is another way of harnessing power
Peak: we see the indigenous people using technology to make their lives easier
Oasis: this turns out to be the home of the child, we see the drone being played with

That’s all, folks.

we see: everything
we feel: happy and content
we hear: rearranged main theme

Post Credits

The child is seen saving the sum total knowledge of her civilisation to a small magneto optical disc, inserting it into the music box, and loading it into the repaired drone. With great delight, she throws the drone into the air. Its next adventure begins.

Notes

If it’s an open world can’t we just keep on flying?

it is not an open world but a guided experience
each location is a limited dimensions and if we keep flying in one direction it will wrap around
this also help reduce backtracking if the map was wide open
travel between areas is guided but there is free movement within each area

Who is flying this thing?

we are
slowly we will earn about other people in the world and we will be helped on our way by many of them, in a wide range of languages
with an ability gathered mid-game we can understand the languages
hearing all the messages will require a second play-through
messages that initially appeared angry take on other meanings

How do we segue between locations?

music & animated sequence almost like a music visualiser
- like the star-filled sky @1:38
- and the sun-bleached sky @1:48
we have to rest (sleep) in some locations to progress from night to day

Influences

Panekit (1999, PS1)
Rime (2017, PS4)
Journey (2021, PS3)
Proteus (2013, PC)
Ico (2001, PS2)
Hunter (1991, Atari ST)

Mouse Support for Playdate

by Matt Sephton — Sat, 11 May 2024 10:52:00 +0000

Since some of my first prototypes with Playdate I’ve wanted there to be a way to interact with the device using a mouse. Well, today is that day!

No doubt you have some questions? How are you doing this? What’s the weather like? etc.

How?

A custom Hammerspoon script monitors mouse coordinates and sends them to the Playdate over serial connection. The game receives those messages through the recently added API playdate.serialMessageReceived(message), parses them, and acts accordingly.

Currently the script sends messages such as:

msg mouse on
msg 0,0
msg -19,84
msg mouse off

I use those to trigger on screen notifications, reset the game state, and move the cursor.

Note: use of serial means you can’t have the Playdate Simulator or Mirror open when trying this. If you invoke the script and it can’t open the serial connection for any reason it will sound an error beep.

Why?

Originally, back in 2020, I wanted to be able to position items in the in-game level editor of my game Daily Driver more directly, using a mouse rather than typing co-ordinates into a file. Then I forgot about it for a while. Then in Playdate SDK 2.4.0 (March 1, 2024) a new API was added that made me wonder if it was now possible.

I knew the Uncrank’d Game Jam was in progress and was thinking about what to do, and then the mouse control idea came back to me. I first put together the bare bones of an app that drew a dot to the screen, mirrored both horizontally and vertically. Then I set about proving I could forward mouse events, which resulted in a small Hammerspoon script.

After that, I built out the drawing app and that’s how Rorschach came to be. It was originally built to showcase the mouse control, but has since evolved into a lovely little toy of its own. I thought a drawing app would be an easy-to-understand visual showcase for this innovation. But, really, the possibilities for its use are endless.

Developers can use it to speed up and simplify development, add finer control to their in-game level editors, and generally make their lives easier. There’s nothing stopping you giving users access to it in a game.

Installation

Make sure you’re running Rorschach or Mouse Demo on your device
Attach your Playdate over USB and unlock the device
Install Hammerspoon automation tool for macOS
Install mouse_to_playdate.lua (instructions in the file)
Press the hotkey (defaults to F13)
The guide window (virtual trackpad?) appears so you can gauge Playdate screen size
Move your mouse pointer and watch the drawing appear!

I’ve tested this on a MBP running Sonoma with a mouse and a trackpad. There’s very little lag, it’s really quite usable. The video has substantial lag as I was capturing through QuickTime and my phone camera. Anyway, it’s super cool!

Demos

Rorschach drawing app is at: gingerbeardman.itch.io/rorschach
An example project with source code is at: github.com/gingerbeardman/playdate-mouse-support

Notes

This is a technical proof of concept, so it can be improved
It was created to show that this can be done. It is not a final version or the most robust way of doing this. And, yes, sorry, it’s only available for macOS
My dream scenario would be for Playdate Simulator and Mirror to have this feature built-in, so you can enable the feature and then interact with the virtual screen to forward mouse events to Playdate
If that can’t happen, then maybe a more native mouse forwarding client can be created for each of macOS, Windows, and Linux
On macOS it would be cool if it supported Apple Pencil via an iPad/Sidecar

A year in the life of a Playdate game developer

by Matt Sephton — Thu, 07 Mar 2024 19:44:00 +0000

This week sees the first Anniversary Sale of Catalog, the official store for Playdate games. This means it’s almost the anniversary of the release Sparrow Solitaire, which was the first Playdate work I did in 2023 after taking an enforced break.

So I thought it would be interesting to look back and take stock of the last year of me making stuff for Playdate. What did I finish? What did I abandon? What is still to come?

After Sparrow Solitaire (a huge game that took around a year of development time split between myself and Mac Vogelsang), it took me a few months to figure out the right sort of size and scope that would allow me to make a game every month or two, whilst minimising the risk of not selling enough. By September I was well and truly in the zone and created YOYOZO which went on to receive a commendation from Ars Technica as one of the “Best Games of 2023”. And at the 2023 Playdate Community Awards, presented on 8th March 2024, Sparrow Solitaire won Best Puzzle Game and YOYOZO won Best Arcade Game.

Somebody asked me if this is my full-time job? My answer is: yes, this is my only job and I do it as often as I’m able. It’s certainly more complicated, due to various life stuff, but that’s the gist of things. Over the last twelve months, I would say I’ve been productive for around half my time.

Recently I saw somebody say “Be careful with scope and look what you can do in a year!”, about the wonderful Johan Peitz, and I think that addage can also be applied to my output this year.

Summary: 22 projects, 10 of which were released, and 5 are still to come. I’m pretty happy with that!

I also managed to squeeze in a couple of non-Playdate projects: my first real Love2D game Portrait Curling, modifications to vintage pixel art app JINZO Paint, and I’m always blogging.

Don’t forget to check out my Playdate games in the Catalog Sale! And my other Playdate blog posts.

Month	Project	Genre	Status	Store	Blog	Made With
2023-03	Sparrow Solitaire	Puzzle	Released	Catalog	Read	vogelscript
2023-04	Shark Turtle	Puzzle	Unreleased
2023-05	Radical	Adventure	Abandoned
2023-05	Carton	Puzzle	On hold
2023-06	Heno Heno	Puzzle	On hold
2023-06	Fore! Track	Sports	Released	Catalog	Read
2023-07	Mandala	Toy	Released	GitHub
2023-08	Strategies	App	Released	Itch
2023-08	DateDiff	App	Released	Itch
2023-08	Fortress	Puzzle	Abandoned
2023-08	Mole Hole	Adventure	Unreleased			thoruman
2023-09	Rink	Sports	Tutorial
2023-09	Kye	Puzzle	Released	Itch		mouflon cloud
2023-09	YOYOZO	Action	Released	Catalog	Read
2023-10	Pararena	Sports	Abandoned
2023-10	Soccer	Sports	Prototype
2023-10	Super ICARUS	Action	Released	Catalog
2023-11	Boing	Action	Prototype
2023-11	Cranxious	Action	Prototype
2023-12	See The Sky	Storybook	Released	Itch	Read	thoruman
2024-01	Rocket Man	Simulation	On hold
2024-02	Eggdog	Action	Prototype

Interview: Kenta Cho (Japanese indie game developer)

by Matt Sephton — Sat, 10 Feb 2024 21:46:00 +0000

Kenta Cho is a Japanese indie game developer, who has been active since the 1980s. He became well-known in the West in the early 2000s with a series of bullet hell shoot-em-ups. In 2021 he created a total 139 games, which is one hell of a lockdown project. In early 2024 his game Paku Paku went viral, as “1D Pac-Man”, a year after it was made.

I reached out to him with some questions and he was gracious enough to answer them candidly, from one game developer to another.

After studying information science at university, I joined a manufacturing company in an IT-related research position. Currently, I work as a manager in system development. I have never worked in the gaming industry.

Wow! You’re a true indie in that you’ve never worked at a game studio! Well, let’s start at the beginning: what was your earliest experience with video games?

It was Nintendo’s Game & Watch. Around that time, I lived in an apartment, and I used to exchange and play various Game & Watch games with my friends who lived there. Titles like Fire, Manhole, Helmet, Parachute, and Octopus were simple yet extremely exciting. The simple gameplay of Game & Watch has become my foundational experience in gaming, significantly influencing the small games I make now.

Also, at that time, game arcades were more adult-oriented, making it difficult for children to visit, so arcade games were objects of longing that I couldn’t actually play. Instead, there were various LSI/FL games (in the West we usually refer to such games as LCD games or handheld electronic games) that ported those arcade games, which I also played with friends. Games like Heiankyo Alien and Frisky Tom, ported to machines with specs far inferior to arcade games, were almost different games, but their core gameplay was well-designed, and I loved playing them. The LSI game version of Pac-Man, released by multiple manufacturers, was interesting because each one had its unique arrangement. It was enlightening to realize that depending on the arrangement, a variety of variations could be created from the base gameplay, which greatly influenced my game development.

List of Game & Watch games at Wikipedia
Handheld Games Museum

So even in these early days you were captivated by simple and effective gameplay. Was it at this point that you began programming computers?

I was about ten years old when I saw a TV educational program called マイコン入門 “Mycom Nyumon” (Introduction to Microcomputers). “Mycom” is another name for microcomputer, which was the term used during the dawn of personal computers in Japan. At that time, it was very rare for households to own a personal computer, hence the microcomputer was colloquially called “Mycom”, short for “My-computer”. “Mycom Nyumon” was a program aimed at complete beginners to computers, explaining things like programming. Watching how computers could perform various calculations and control the screen, I thought they were like magical boxes and was utterly fascinated.

Later, my father bought a SHARP PC-1500, a pocket computer, and brought it home. That was my first experience with programming in BASIC, and I thought it had potential unlike any machine I had seen before.

マイコン入門 (Introduction to Microcomputers) at Wikipedia (Japanese)
ポケットコンピュータ (Pocket computer) at Wikipedia (Japanese)
Pocket Computer Manufacturers Database

Despite the limitation of the single line display on those pocket computers they were host to many great games. I can see their influence in your games today. At what point did you decide to create your own game?

The next microcomputer we got was the NEC PC-6001. This was a type that connected to a TV. It was a fresh experience to turn the TV, usually just for watching shows, into something interactive that could be operated with keystrokes and programming. At first, I created games in BASIC, but I was dissatisfied with the processing speed for action games, so I learned to hand-assemble for the Z-80 and began creating games in machine language.

In Japan, there was a magazine called マイコンBASICマガジン “Mycom BASIC Magazine” that accepted submissions of game programs from readers and published them. Each game in the magazine had several pages of source code, which you would enter manually to play the game. These games, despite their compact source code, were full of originality. There were action games about making hamburgers as ordered, race games combined with Pac-Man’s power pellets, puzzle games incorporating rock-paper-scissors, etc. Inspired by how such diverse games could be created depending on the idea, I wanted to make such games too.

I tried submitting some games I made to “Mycom BASIC Magazine”, but it was tough to get them accepted. Only one got published – METEORITE - a game where you shoot down meteors falling from the sky. The game had a unique control where the position of the keys on the keyboard was linked to the attack position on the screen, and you determined the attack location by pressing the keyboard with a clenched fist.

Mycom BASIC Magazine at Wikipedia (Japanese)
Mycom BASIC Magazine at Internet Archive
METEORITE—source code in the 1989-09 issue of Mycom BASIC Magazine
METEORITE—tape file for use with a PC-6001 emulator

Thanks to Dustin Hubbard (Hubz) at Gaming Alexandria for transforming the magazine source code listing into a tape image. This was done using specialist Japanese software ProgamListOCR and DumpListEditor that are tailor-made for getting old source code off the page and into the computer, so thanks also to the authors of those applications. Video game preservation is a worldwide effort.

Your formative years coincided with the “golden age of video games” period from the late 1970s to the early 1980s. What inspired you at that time?

It was Namco’s arcade games. In the 1980s arcade games, I felt that the ideas in games released by Namco were particularly excellent. Dig Dug’s one-shot reversal reward using rocks and the risk of being crushed by them, Xevious’ beautiful graphics and well-crafted enemy flight curves, Gaplus’ super-fast enemy movements yet fair game balance, and New Rally-X and Bosconian’s combination of all-direction scrolling and radar screens requiring complex situational judgment – Namco kept releasing games with very innovative mechanisms. A lot of my belief in the importance of novel mechanisms in game production comes from encountering Namco’s arcade games during this era.

List of Namco arcade games at Wikipedia

I apologise for this next question, as it’s almost impossibly difficult, but I’m keen to learn more about you from the games you like to play. So… what are five of your favourite video games, and what aspects make them special to you?

Transport Tycoon—it’s a railway management simulator, released by MicroProse. I also liked its predecessor, Railroad Tycoon, but I played Transport Tycoon for a longer time. A major difference between the two is that in Transport Tycoon, there are rival companies laying tracks on the same map. It was fun to strategize and lay tracks aggressively to important cities to beat rivals. It’s my favorite game in the city development simulation genre. The isometric beautiful graphics and lively BGM (background music) were great too.

Dodonpachi—the first title in CAVE’s famous Dodonpachi series of bullet hell vertical scrolling shooters, following its progenitor, Donpachi. A fun aspect of bullet hell shooters is the technique called “cutback”. It involves rapidly moving the player to one screen edge to create gaps in bullet patterns, then escaping in the opposite direction through these gaps. Dodonpachi’s stage 5 offers the best experience of this, influencing the shooting games I would create later.

Ikaruga—a vertical scrolling shooter with a unique system where both the player and enemy bullets have black and white attributes, and bullets of the same attribute can be absorbed. This system provided a gameplay experience quite different from previous shooters. Although released as an arcade game, perhaps thinking it too different for ordinary players to accept as is, the first stage offered an “infinite lives trial game” mode. At first, I had no idea when to switch attributes and was helplessly defeated many times. But once I understood which enemies to attack with which attribute and when, the game became addictively charming. The chain combo for defeating three enemies of the same attribute in succession and the complex attack patterns of stage 4’s so-called “Rafflesia” added to its depth. The groundbreaking game system offered an artistic playing experience, impressing me with the high potential of gaming.

THE ATLAS—a PC exploration game set during the Age of Discovery, released by ArtDink. Its feature was a procedurally generated coastline, different in each game. The player dispatches a captain from Lisbon to survey coastlines and ports. Upon the captain’s return, you can choose to “believe” or “disbelieve” their report. Disbelieving discards the survey results, but here comes the twist with the procedural generation. If the captain reports an endlessly long, supply-challenged coastline, or a closed one preventing further survey, disbelieving it could generate a more advantageous coastline in the next survey. The game skilfully integrated procedural mechanics with the game system, deeply enlightening me about the benefits of incorporating procedural elements into games.

Rez—a 3D shooter with abstract wireframe graphics and techno music synchronized with sound effects. The immersion provided by this game was unique, supported by the excellence of its visuals and music. Especially, the sound effects being quantized to match the background music’s rhythm and beat, making game operations and actions feel like playing an instrument, was brilliant. I have incorporated a similar quantization mechanism in the games I’m creating now.

I see a nice balance of gameplay systems and skill in all of those games. That brings to mind the types of games you create. Now, if you could have developed any existing game, which one would you choose, and why?

That’s Herzog. It’s a real-time strategy game released by Technosoft for personal computers. Overseas, the sequel Herzog Zwei, which was released for the Sega Mega Drive, is more famous, and the original Herzog might not be as well-known. It’s an action game where you control a robot that can move both in the air and on the ground. The battlefield is a vertically long strip, with enemy and ally bases located at each end. Players could produce units like infantry, tanks, and anti-aircraft guns at these bases and dispatch them towards the opponent’s base. At that time, it was quite rare to have a game where you could produce allies other than the player and fight together. I was very impressed by this game, where you could fight as part of an army against enemy forces.

Later, I even created a game similar to Herzog for the PC-9801. I made the screen 3D and added an arrangement where you could freely board any friendly unit on the battlefield, intending to make the game even more enjoyable.

Herzog (MSX) longplay on YouTube

At that time, I often played bullet hell shooters released by CAVE at game arcades, especially loving Progear no Arashi. Progear’s bullet patterns were very complex compared to earlier CAVE games, like fan-shaped bullets shot in nine directions, slowly decelerating, and then five straight bullets targeting the player. I wanted to replicate such complex bullet movements in a simple way and developed the BulletML language.

With BulletML, I developed Noiz2sa, aiming to achieve the fun of bullet hell dodging with the immersion of games like Rez. In rRootage, I used BulletML for procedural generation of bullet patterns, aiming to create infinite attack patterns. After developing a technology called Bulletsmorph and extensive balancing, I finally released it. It was challenging to achieve patterns that were fair and challenging without reducing variation, but I think it worked out well. Among my shooting games often featuring auto-generated levels, TUMIKI Fighters, where levels were manually designed, was somewhat unique. But this was simply because I found Namco’s Katamari Damacy so enjoyable that I wanted to combine it with a shooting game. Attaching enemies to your ship until it occupies more than half the screen, this kind of shooting game is still quite rare, so I think it turned out to be a game with originality.

Also, during this period, I entered various game contests with my games. Games for the WonderSwan on WonderWitch, games for Xbox 360 on XNA, and games for contests on P/ECE. Fortunately, some games won awards. I had opportunities to present my games to judges, which was enjoyable. Playing my games on these consumer devices was a fresh experience for an amateur developer. Also, optimizing for each device’s characteristics provided many interesting development experiences.

In the following years I continued to follow your work and noticed a move towards the web browser as your platform of choice. More recently, I was wowed by your prolific output, particularly the 139 games you made in 2021! I’m wondering, what motivates you? And can you outline your creative process?

Around 2008, I realized I could make browser-playable games by implementing them in ActionScript3, a programming language for Flash. I knew about Flash, but I thought of it more as a platform for creating animations than games. However, ActionScript3 was a sophisticated language with diverse features, allowing me to create games using just code. Browser games are more accessible than conventional games, so I started making many small action games that could be played intuitively in a short time.

Through this process, I realized that making lots of small games was ideal for trying out various game ideas and mechanics. Since then, I’ve been experimenting with how to make games enjoyable by thinking about mechanisms that haven’t been seen much in previous games and trying to turn them into fun games. This has become my basic process for game development.

Kenta Cho’s browser games

Already you’ve mentioned multiple programming languages in this interview. What factors do you consider when selecting programming languages, platforms, and technologies for game development?

I flexibly switch programming languages depending on the target device for the game. For the PC-6001 or MSX, Z-80 assembler; for PC-9801, Borland’s Turbo C; for Windows, Delphi or GCC; for XNA, C#; for browsers, ActionScript3 or JavaScript, and so on.

But I don’t just use commonly used programming languages; I also look for languages that are easier to use and equipped with new technologies. For example, the D language as a replacement for C, offering object orientation without the complexity of C++ and faster build speed; Haxe, superior to ActionScript3 with features like Mixins and Enums; TypeScript for type-checking JavaScript, allowing proper error detection and code recommendations. I actively use them even if they are slightly less mature or have weaker ecosystems than traditional languages if they can improve development speed.

I really appreciate how technology agnostic you are. It’s noticeable that the game is the number one priority and the choice of technologies is not so important. This is similar to how I work, in that I’m happiest when the technologies fade away and I can concentrate on the game design and implementation details. Could you tell us more about your approach to game development?

As I mentioned earlier, I think about game mechanisms that haven’t been seen in previous games. However, it’s challenging to conceive completely new mechanisms. Instead, I often borrow and arrange parts of mechanisms from old arcade games or submission magazines like “Mycom BASIC Magazine”. Old games focused more on the novelty of rules and mechanics than on content like scenarios, which is very informative for game development.

I also create games driven by specific technologies. I’ve incorporated procedural content generation and physics calculations into shooting games. Before Windows, I implemented 3D drawing logic and software-based screen rotation, scaling, and shrinking. Recently, I’ve been experimenting with whether everything from game idea conception to programming can be procedurally generated.

I’m also interested in this aspect of game development, it’s a deep well with a lot of opportunity. I can see its influence in many of the games you’ve created using your Crisp Game Lib. What was the thinking behind your framework?

The goal of Crisp Game Lib is to enable the creation of innovative games within a three-hour timeframe. For this, I made it easy to implement collision detection, which is typically challenging. I particularly focused on making collision detection easy for geometric shapes like lines and arcs, allowing the inclusion of geometric shapes as terrain, obstacles, players, and enemies. This makes it easier to create games different from traditional sprite-based 2D games.

It also includes features for procedurally generating background music and sound effects. Automatically generated background music and quantized sound effects make it possible to create enjoyable games even within a short development period.

Your recent games use quite simple scoring systems, especially when compared with arcade or pinball scoring systems. What are your thoughts on scoring?

In a simple scoring system, it’s important to reward the player’s risky actions with high scores. Assigning high scores or multipliers for actions like attracting and defeating many enemies at once, narrowly avoiding enemy attacks, or collecting hard-to-reach items can add depth to the gameplay. Additionally, I make it a point to clearly display the acquired score and multipliers on the screen, making it easy for players to understand how to earn high scores.

The gameplay concepts in your recent games are also beautiful in their simplicity, but at the same time they have depth. How do you approach the difficulty curve to ensure your game is enjoyable for as many people as possible?

I often use the traditional Game & Watch era mechanic of increasing difficulty as time goes on from the start of the game. In such cases, I consciously choose between a linearly increasing difficulty (difficulty = time) and one that gradually becomes milder, using the square root function (difficulty = sqrt(time)). Linear is usually fine, but for parameters like enemy size, which could become unreasonably difficult if too large, I use square root to maintain game balance over time.

As mentioned in the previous answer, rewarding risky actions is closely related to appropriate difficulty settings. Increasing difficulty over time means to achieve high scores, players need to take risky actions and score high from the early, easier parts of the game. This avoids boredom in the early stages, making the game enjoyable from the start.

In January 2024, your game Paku Paku went viral after being featured on Hacker News. It was picked up by various bloggers and news outlets, and was even ported by fans to multiple systems. Were you surprised by this turn of events, and why do you think the game garnered such attention?

When I released Paku Paku a year ago, it was fairly well-received among Japanese players, but I was surprised that it gained attention from international players a year later. Many articles described Paku Paku as a ‘1D Pac-Man’, which likely sparked curiosity about how a 1D version of Pac-Man could be realized. Paku Paku was an example of the demakes and minimalization I often do when making small games. Successfully balancing it as a good game within the strong constraint of 1D might be why it became popular. My experiences with games I made and played during the pocket computer era were very helpful in developing a 1D game.

Play Paku Paku in your browser “…just one more go…”

Paku Paku could be considered the essence of Kenta Cho: from the single-line display pocket computers, through Namco’s arcade titles like Pac-Man, to his love for modern programming languages and the web browser as a platform.

Many thanks to Kenta Cho for this interview. Now go play some of his games!

See the sky: Thoru Yamamoto’s Christmas story, for Playdate

by Matt Sephton — Sat, 16 Dec 2023 00:00:00 +0000

Thoru Yamamoto (Japanese: 山本徹 or とーるやまもと), born 1955, is a Japanese multimedia artist. Over the years he has released work in many formats including, but not limited to: magazine illustrations, HyperCard decks, interactive CD-ROMs, printed books, websites, digital stickers, and videos. He is perhaps best known for his story books distributed as HyperCard stacks and his unique 1-bit art taking advantage of the limitation imposed by early Apple Macintosh computers.

See the sky is one such story book, a Christmas present released in October 1992 as a series of HyperCard stacks. In 1996 it was re-released in a remastered form: as an interactive CD-ROM, produced using Macromedia Director, which added ambient music and navigation to the original images. Also released in 1996 was a printed book of the story, presented as 3 images per page. Finally, in 1999 a CD-R of the combined HyperCard stacks was released.

A new edition for 2023

I’ve created a new version of See the sky for Playdate. The remastering/remaking/porting process was quite involved, so I’d like to detail it in this blog post.

Extracting the original images

I used HyperCardPreview to export the assets from the original HyperCard stack. I did this back in October 2022, and had to use an old MacBook Pro running Mojave to do it.

Just today, whilst writing this blog post, I figured out that HyperCardPreview will refuse to open stacks if the app Stacksmith is also present on your Mac!? As soon as I deleted Stacksmith, HyperCardPreview opened the files just fine. It seems to be some sort of issue with them competing for control of the com.apple.hypercard.stack uti. Weird.

Anyway, See the sky consists of just over 500 full screen card images. For other stacks, you might get a combination of background images and card images that would need re-compositing - it really depends on the stack.

Thoru told me that when he first started out with HyperCard he wasn’t aware of the benefits of using a common background card and different foreground cards, which is why See the sky consists of only foreground cards. For this reason it was very difficult for him to upload the files, which were rather large for the time. Later productions would make more effective use of background cards to keep the file size as small as possible.

Implementing a viewer

My way of developing is to think of the goal as clearly as possible, then get something up and working as quickly as possible, and after that iterate and refine until I reach the goal. So it was easy to create a sort of slideshow viewer for the images, keeping track of the current image and allowing navigation forwards and backwards with A and B buttons, loading the next/previous image as required. Pretty quickly it became apparent that I could not simply display each screen centred as important content would frequently be out of view.

Adjusting each screen

So I added a table to store offsets for each screen. But defining these manually would be very time consuming so I set about creating an interactive way to do this. I added a debug mode in which I map the d-pad (cursor keys) to move the current image up/down/left/right, along with the ability to save the offsets table to a file. This was a huge productivity boost! But I was still finding it quite a repetitive task, so I added further key mappings so I could use the numbers on the numeric pad of my keyboard to quickly set the offsets for a screen to each of the 8 compass directions, or centred. This increased productivity even more. At this point I found myself setting the same offsets for a screen as the previous screen, so I added to more keys to copy the offset from the previous/following screen. All in all this made setting offsets for 500 screens quick and easy. When I was happy I copied the offset table into the code and that became the default values.

This is all to say that whilst the original Macintosh resolution of 512×342 does not match the Playdate’s resolution of 400×240, See the sky still works on Playdate because every screen has been manually repositioned to keep the important elements in view, a process similar to the “pan and scan” adaptation of movies for 4:3 TVs.

HyperCard look and feel

The most recognisable feature of many HyperCard stacks are the crossfades between screens. This was essential to the experience. Thoru even took advantage of the crossfade in certain scenes by changing only small elements from screen to screen so that the crossfade turned into a sort of stop-motion animation effect.

To achieve the crossfade on Playdate I do the following:

Before the transition I capture the current screen using playdate.graphics.getWorkingImage()
Next I make this image into an overlay, in my case I’m assigning it to a “fade” sprite
Behind the fade image/sprite I load in the requested next/previous image
Finally I use playdate.graphics.image:fadedImage(alpha, Bayer8x8) to fade out the overlay, which happens over several frames and results in the image becoming more and more transparent, eventually disappearing completely

So the crossfade is simply one image fading away and the image behind it slowly being revealed. Magic.

I also added the ability to have slower or faster crossfades depending on your preference. I do this by adjusting the refresh/frame rate of the game itself, rather than skipping any of the fade.

The only other feature I needed to add was a flashing capability. This happens at a handful of places in the story to various degrees, mostly there are a few flashes in places but in one places there are 10 flashes. Given that people with photosensitive epilepsy won’t want to see the screen flash I honour the Playdate “reduce flashing” system setting. If the user has that toggled on the story will only flash once at each instance. The speed of the flashing is quite slow, and not tied to the speed of the crossfade.

Page turn sounds are recordings of the sounds defined in the original HyperCard stack, another essential part of the experience. Thoru describes these sounds as “pipo papo” and that’s how I label it in the settings. I also provide the option to use a more realistic page turn sound, or switch off page turn sounds entirely.

Chapters

I added chapter navigation which unlocks as you go through the story, in a similar way to the 1996 CD-ROM release of See the sky. This means you can revisit any previous chapter, and once you’ve reached the end of the story you’ll have access to all chapters. If you want to reset that progress, for example to let somebody else enjoy the story from the beginning and remove any temptation for them to skip ahead, you can delete the “game data” through Playdate Settings. Chapter title cards are only shown when using the chapter navigation, and not whilst going through the story, I do this by injecting temporary images into the crossfade system.

Progress

I also added a progress bar, shown when you bring up the menu. It’s a vertical bar drawn in the centre of the screen between the menu and faded game image. The bar itself is dithered at 50%, and onto it I draw white markers for each chapter position. The current position is shown by drawing a solid white bar from the bottom of the screen to the current position. This means that the bar “fills” with white from the bottom as you progress through the story.

Experiments with sound

The 1996 CD-ROM release of See the sky has ambient music, but Thoru and myself couldn’t figure out the rights to this so it could not be used. I had done the work, just in case, so I’ll mention it here.

I extracted the audio from the Director files using a technique I’ve previously blogged about. I then converted the audio files to 44.1KHz 16-bit WAV files, and used Ocen Audio to remove the base noise from those files. Basically, you select a part of the audio that contains only noise and it removes this from the entire audio file. Doing this without first upsampling the audio meant it did not work as well or at all. After the de-noising, I converted to ADPCM using adpcm-xq which gave files half the original size at higher quality and with lower noise levels.

Experiments with music

After we realised we would not be able to use the ambient music, I looked at using completely different music, turning to the catalogue of watson @ MusMus. I found a piece of music for each chapter of the story and extracted loops using PyMusicLooper. I then tweaked the loops by adjusting their start point by moving a section of audio from one end to the other so the loop began with the part of the audio I thought sounded best. I use TwistedWave for most sound editing like this. Thoru really liked the music itself but was of the opinion that no music would be more honest to the original release. I can’t argue with that reasoning. Feel free to play your own choice of music whilst experiencing the story.

Optimising for size

The final app binary is tiny but the images are adding up to about 3MB. That’s fine, but I wondered how I might be able to optimise them. I used imagemagick’s montage command to stitch the images together into a grid. In Playdate land we call this an image table, but you might refer to it as a sprite sheet. This reduced the size of 500 separate card images from 3MB to a single image of just 2MB. A nice saving!

The 500 screen image table occupies 10.5MB RAM, so about two thirds of the available RAM on Playdate. Side-effects of bundling 500 screens as single file are a short delay on loading for users, a short delay on building for me as a developer, and the need to regenerate the single image if any of the images it contains are changed.

At this point, I could have stopped. I should have stopped. But, of course, I didn’t.

I’ve often wondered how the dimensions of a sprite sheet grid affect the file size when saved as a compressed format such as PNG. The extreme examples in this case would be having a tall grid of 1×504 or a wide grid of 504×1, and in between we have some exact multiples. I generated one sprite sheet for each grid size and here found that for this set of images a grid of 42×12 resulted in the smallest image file size a saving of a further 4% or so. The savings are similar when converted to the Playdate pdt image format. Note that this sort of optimisation only works for solid images, not for images with any alpha/transparency.

And that’s it. The final size of this new version is smaller than the original, mostly due to the image optimisation. I could make it even smaller by exporting all the final crops of the screen images, create a new image table of those, displaying them with zero offset. But I decided to not go there!

The result

You can download See the sky for Playdate from my page on itch.io, and it is a free download. A present from Thoru and myself. With best wishes for a Merry Christmas.

gingerbeardman.itch.io/see-the-sky

500 screens
10 chapters
~ 1 hour experience
Quick navigation menu unlocked as you go
Position is remembered between launches
Settings for sound and crossfade speed

Credits

Created by Thoru Yamamoto
Edited by Matt Sephton
© 1992 Thoru Yamamoto

Birthday blog post?

Check out my other #birthday blog posts.

Dynamic music and sound techniques for video games

by Matt Sephton — Sat, 09 Dec 2023 01:22:00 +0000

The only aspect of game development I’ve not attempted myself is the music. I mostly use royalty free music of Japanese origin (just because I dig their vibe, man) as in the case of Sparrow Solitaire or Fore! Track or in rare cases I pay friends (like the amazing Jamie Hamshere) to write music specifically for a game as in the case of YOYOZO. Maybe one day that will change, but until then I’m enjoying gaining more understanding and control of the music in my games. Whilst I develop games for Playdate these techniques are general enough to apply anywhere.

The main way I make the music into more than a static track is to apply a dynamic, reactive, or adaptive effect in one way or another. In this blog post I’ll go into how I’ve achieved this. Please note this is by no means an exhaustive list, rather it’s just the ones I have personally used.

Dynamic BPM

I use this method in YOYOZO because it uses “chip tune” music data representing songs composed by my friend Jamie Hamshere using Playdate Pulp. A playback engine for this data, written by Pulp creator Shaun Inman, works beautifully when integrated into games written using Lua and the Playdate SDK. I added hook to allow me to set the BPM at any point to any value. The end result is that the BPM of the music scales from 130 to 135 as your score increases. As you improve at the game you’ll notice the music speed up ever so slightly along with an increase in tension and anxiety.

Of course, it’s possible to do this in a pre-recorded song stored as a digital music file, but it’s much more difficult for that to respond to the what the player does in the game. An example that takes an interesting approach to this is the track “Sunny Day” from the game Vib Ribbon, and indeed the rest of its soundtrack, where tempo changes over the duration of each song.

Infinite Variations

Another technique I use in YOYOZO, again made possible because I can modify the music data and playback parameters in real time. With this one I cycle the values for the instrument voices pseudo-randomly so that the track plays once as it was programmed and then morphs slightly for each subsequent playback. The track is quite minimal and repetitive in Steve Reich, Philip Glass or John Adams sort of way, so there are automated variations wandering around the original arrangement work really well. Perhaps the ultimate implementation of this approach is Wii Play’s Tanks game.

For sound effects, I vary the playback sample rate to change the pitch of sound effects. This prevents the same sound effect becoming monotonous. Two examples might be Lara Croft in the first Tomb Raider game, groaning the same way every time she climbs up a platform compared with the rich variety of sounds when Mario walks on different surfaces.

Blending/Fading/Balance

Another idea I had was to fade or blend two tracks as the player makes progress in the game. But how to find two tracks that can be cross-faded in a way that always makes sense? Of course you can have them composed, but what about in music that already exists? If only there was an easy way to find such tracks!

There is: stereo pairs! You’d be surprised at how different the left and right channels can sound whilst obviously being the same tune. Of course this means that are output audio will be mono but for me on Playdate that’s just fine. I use this method in Fore! Track.

The idea is to adjust the balance of the two parts of the audio, at once point you’re playing just the left audio across both outputs, then you adjust the balance to play a mix of both, at the other end of the scale you’d be playing just the right audio. Unfortunately the Playdate SDK currently has no API to easily adjust balance, so I had to program a method myself. First, I convert to the destination format which is for me ADPCM using adpcm-xq. Once the files are in this format I split the stereo pair into two files, one for the left channel and one for the right channel. Converting to the destination format before splitting ensures that the two are exactly the same length in terms of samples/bytes.

In the game I fade between the two as the score/chain increases, which has the effect of subtly changing the instrumentation of the tune. It’s one of those things that most people wouldn’t notice, but that once you know about it you can’t miss it. Sadly, I don’t have an easy way to demo this in a video or sound file.

For sound effects, you might consider panning to increase immersion and guide the players visual focus through use of audio. In YOYOZO I pan certain sounds relative to the location of the ball, certain other sounds relative to the location of the player, and there are global sound effects that are not panned at all.

Progressive Loops

Digital audio is a different beast. I always try to find a time that fits the game, going so far as to audition many hundreds of tracks and creating playlist of songs far ahead of ever making a game or even having and idea for a game. I try to find tracks that will loop well and not get annoying, which is easier said than done. If I can’t find a track that loops well, there’s another way.

You can use PyMusicLooper to analyse a digital audio track and spit out information about ranges that loop nicely, along with a percentage indicating how good it considers the loop. In other words you can identify and extract a loop from digital audio files that sound like they could loop. Of course, can’t identify loops in tracks that aren’t repetitive or consistent in their structure. You might get PyMusicLooper to split the file into into three sections (intro, loop, outro) or just export the loop information as a text file to use in your game. Which I choose depends on how much of the file I want to use.

For an example, in my game Super ICARUS I’m using a file that gives the vibe I wanted in the game and sounded like it contained some loops even though it was not provided as a looping song. PyMusicLooper reported that it contains tens of possible loops of varying quality.

loop	start	end	duration	match
0	3.437	30.755	27.318	94.87%
1	0.023	27.341	27.318	94.79%
2	7.279	34.598	27.319	94.63%
3	6.850	34.168	27.318	93.95%
4	8.127	35.445	27.318	93.92%
5	22.221	52.953	30.732	93.80%
6	25.635	56.366	30.731	93.23%
7	11.970	39.288	27.318	93.17%
8	6.850	35.875	29.025	92.13%
9	6.850	54.660	47.810	91.98%
10	20.515	52.953	32.438	91.54%
11	10.263	37.581	27.318	91.26%
12	22.221	54.660	32.439	91.11%
13	23.928	68.325	44.397	90.92%
14	39.300	70.031	30.731	90.82%
15	12.399	70.449	58.050	90.78%

My goal was to find three loops of increasing length and with a high percentage loop quality. After some experimentation and listening, I decided on loops 0, 9, and 15 (table only shows the top 15 loops from this track, even though their percentage loop match are not 100% they still sound like good loops, so selecting these loops was a case of finding three of suitable length and content. PyMusicLooper will let you audition the loops directly, so there’s no need to use an audio editor.

Using the Playdate SDK I can do setRange() on the audio track to change the playback range and the music will loop between those new points when the playhead reaches the end of the range. For this reason, this method does not provide immediate results so is better used to signify a large change in progress as the delay until the change is noticed will be an unknown amount of time. But when the change does kick in it’s a really nice surprise!

The final result sees the game start by playing loop 1 (synth and drums) and then as the player gets makes some good progress I switch to loop 2 (synth, drums, guitar licks), and finally as they pass a certain threshold I switch to loop 3 (synth, drums, guitar licks into guitar solo). This provides music that sounds very dynamic with little effort. You could even drop back to the shorter loops if the player lost a life, missed a target, and so on. Again, there’s no real way of me demoing this as it’s something that will become apparent through play, and the final result is just one long dynamic song!

For sound effects I use the same approach as above. As an example, in Fore! Track there is a clapping sound effect after the player gets the ball in a hole. This is a long sound effect but I play three increasingly long sections of it as the player’s chain increases (number of successive holes-in-one). It starts off as a short clap, increases to a longer more enthusiastic clap, and finally it begins with a whoop and continues to enthusiastic clap. I have a separate sound effect for the end game cheer that plays over the top of the full clap, resulting in a raucous end of game celebration.

Quantised Sounds

In Super ICARUS created certain game event sounds from small sections of the music track. I then adjust playback rate/speed/pitch. The result is that the sounds appear to be quantised or matched to the music. I’m not sure how to describe this phenomenon accurately in musical/technical terms.

I’d love to hear about other methods of achieving dynamic music and sound in video games. Feel free to reach out to me on social media!

Elsewhere

2023-11-22—Hacker News
2023-11-22—Tildes

Easter egg emoji: converting pixels into particles

by Matt Sephton — Sun, 26 Nov 2023 20:41:00 +0000

I’m fascinated with Moai so I always try to squeeze an appearance into my games. Moai in video games is a meme, or easter egg, going all the way back to 1983. But my game YOYOZO (out now for the Playdate handheld) is about capturing stars in space using a yoyo, so how could I get a Moai in it?

The source of my inspiration was a trip to Japan back in 2004 (my only one, so far). Visiting in August meant that one of the things we did was go to an annual hanabi fireworks festival, where I saw katamono for the first time. These are fireworks that explode in the shapes of drawings, like a smiley face or a magic 8-ball. I was amazed and the experience has stuck with me for over 20 years. Maybe I could add Moai into YOYOZO by making the explosions appear like the katamono?

I started off by coding the patterns by hand, as a test, but my calculations weren’t precise enough and the whole endeavour quickly grew too complicated to manage by hand. I needed a better, more automated way. The method that I arrived at is what I’ll document in this post.

Pixels as code

Instead of plotting values by hand in code I figured that it would make more sense if I could draw the patterns and then somehow convert them into coordinates. I use Piskel as my Playdate-centric graphics editor. It’s a really useful tool. So I drew a few emoji-like patterns, keeping in mind that they would be converted into a cluster of points and exploded from an origin. This took a bit of experimentation but I ended up with a sort of already exploded look.

To get the pixel data out of Piskel in text form I make use of its “export as a C file” feature. This results in code definitions similar to the below. (I use a script that does some simple regex search/replace to reformat these definitions to be a little more succinct and readable in my Lua code.)

#include <stdint.h>

#define EMOJI-TABLE-11-11_FRAME_COUNT 3
#define EMOJI-TABLE-11-11_FRAME_WIDTH 11
#define EMOJI-TABLE-11-11_FRAME_HEIGHT 11

/* Piskel data for "emoji-table-11-11" */

static const uint32_t emoji-table-11-11_data[3][121] = {
{
0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 
0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 
0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 
0xff, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0xff, 
0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 
0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 
0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 
0x00, 0xff, 0x00, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00, 0xff, 0x00, 
0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00
},
...

Pixels as points

With this data in hand, my plan was to convert them into points expressed as an angle and distance from an origin. This way of expressing points is the polar coordinate system so there was no need to invent anything, I just needed to code a function that would take a grid of pixels expressed as (x, y) and convert them to a series of distances and angles expressed as (r, θ).

The way I do this is to read the point data in from a grid of pixels, offsetting that data by half the width and height of the odd-sized grid so that the centre of the grid (0, 0) is the middle of the centre pixel. And finally I convert those adjusted (x, y) values to polar (r, θ) coordinates. This worked really well!

Below is a work-in-progress GIF captured on 14 September 2023, shortly after getting the feature working. This animation also shows an early version of the HUD and debug values for ball size and the length of the beam.

The finishing touches (not shown in the above animation) were to add some small amount of pseudo-randomisation to the initial rotation of the emoji, the initial “colour” of each particle, and changing the coordinates of each point slightly so they appear more organic and move at slightly different speeds. I eventually settled on over a dozen such pixel patterns in the game (how many have you spotted?). Once your score is higher than 50M points every explosion is an emoji! Check out the game manual.

Pseudo-random?

I try to limit my use math.random values if I can help it, or at least use it in controlled way. I already use that for the positions of the stars, so if I also used it for explosions that would mean it would become far less controlled. Controlling the use of random is important in making a game system deterministic, if you want it to react the same way every time.

If you’re wondering how you can get pseudo-random values, the main method I use is a trick I learned from the old arcade game Flicky (1984, SEGA) which is a game I own as a physical cabinet. Anyway, in Flicky there is a diamond that appears under seemingly random conditions.

One of the MAME programmers was kind enough reverse engineer Flicky on my behalf and figured out what makes the diamond appear. It turns out the diamond will appear only if you knock out an enemy cat and it disappears outside of the centre third of the play area and if the x coordinate at which the cat finally comes to rest is even. So, about 50% chance but only if you position the screen correctly during play.

So, taking a cue from that wonderful Flicky logic, I use modulus—which returns the remainder of a division—as my main mechanism of generating pseudo-random values. It ensures a value in the range [0,n-1]. They key thing to note is that if you base it on values in your game system that are constantly changing you can get seemingly random values that have the benefit of being deterministic if the player is skilled enough at repeating their inputs. The deterministic thing is how pretty much all the old school arcade games operated from Pac-Man to Flicky and more.

Common game variables I use are: game tick (my alternative to timer), x-coordinate, y-coordinate, speed, angle, or combinations of more than one of these. I also used this approach in YOYOZO for the starfield particles, and in Sparrow Solitaire for the falling particles that make up the weather effects.

Playdate particles

There are one or more libraries available that can be used to manage particles in a performant way on Playdate. Though I tend to code my own system that is bespoke to the game I’m working on at the time (I start each game from a blank file and use minimal libraries, force of habit). But the important thing for such limited platforms, especially when using Lua, is to use a pool of particles so that you’re not constantly creating and destroying particles which would wreak havoc on performance through overuse of Lua’a garbage collector.

YOYOZO (or, how I made a Playdate game in 39KB)

by Matt Sephton — Tue, 21 Nov 2023 23:59:00 +0000

2023-12-27—Ars Technica: YOYOZO wins GOTY accolade! almost unbelievable to be listed alongside such games as: Chants of Sennaar, Cocoon, Dave the Diver, Humanity, The Legend of Zelda: Tears of the Kingdom, Pikmin 4, Puzzmo, Super Mario Bros. Wonder, Venba and Viewfinder.

A game I made for the Playdate handheld was released today! Go buy it and then come back to read this blog post.

It’s called YOYOZO and in it you control a space yo-yo and have to collect stars in a sort of cosmic ballet. Well, at first it might feel a little like being on a fairground ride, but eventually you’ll become good enough for it to feel like ballet. The concept is based on my memory of a game called Pendulumania that I played 20 years ago.

The most amazing thing about this game, for me, is that launch version weighs in at a file size of only 39KiB. I’m using the KiB unit of measurement which equates to 1024 bytes. I still find it hard to believe as the game contains so much! In this blog post I’ll go into some of the nerdy details.

Playdate?

Playdate is a handheld gaming system with a unique crank input method. I don’t use the crank in this game, but I have done in the past and will do again in the future.

If you own a Playdate you can buy the game now at play.date/games/yoyozo/. If you don’t own a Playdate, well, what are you waiting for?

But…why?

The drive to produce a small game started after I sent the first playable version to testers. Steve at Scenic Route Software, purveyor of quality video games, commented how tiny the game was. At that point it was 18KiB, but had no music or sound effects or polish. There was a long way to go.

Even so, I wondered how doable it would be to build the game out with an eye on keeping file size “low”. I thought back to the days of my youth where whole games would fit on a single floppy disk, with room to spare. If they could do it, shouldn’t I give it a try?

It’s worth noting that even with this mindset, I didn’t make a huge sustained effort to meet the goal. On the contrary, it was just something I simply kept in mind as development proceeded. For that reason, I’m sure there are more ways the game could be made even smaller than it is, with the exact same code and content. For example, I never tried finding the most optimal format for things like music and particle data which are the two largest sets of embedded data.

Finally, this is not a challenge, or me throwing down the gauntlet in any way. It’s easy enough to make a smaller game, be it similar or entirely different, you’d just have to make different choices along the way. This was just me doing something nerdy as an additional constraint on top of the already enjoyable constraints of developing for Playdate.

That said, I think every game developer should regularly make a point of writing code for an underpowered device as part of their own personal development—there are so many lessons to learn.

Reasons

The main reason for the small file size is the fact that the game does not use any digital sound files, and very few bitmap images (the launch card and animation have to be bitmaps, and in-game only the logo and fonts are bitmaps). Game graphics are all drawn using only shapes (lines, rects, circles) and fills (black, white, and dither patterns).
A second reason is that whilst I use the base Playdate Lua SDK, I don’t use any of the additional “CoreLibs”. The only extra graphics functions I needed were for drawing outlined or filled circles, so I use two of my own wrapper functions that are similar to those from CoreLibs/graphics but mine are smaller and more specific. For timers, I use a simple frame/tick system, an approach which has pros and cons, but it’s good enough for me.
A third reason is that I made the tough decision to reduce system assets, which means there is no animated launcher card. This was a tough one, but it added so much to the file size I decided against it.
Finally, I noticed that including data inside your game code often trumps how well you can compress it and store it externally. For example I tried compressing the music data and storing it in an external file, but the game final file size was larger than if I embedded the data in my Lua code. Plus, it’s faster as it doesn’t need to load an additional external file.

Breakdown

I thought it would be cool to outline the main features and how each contributes to the total file size. Note that the sizes are expressed as quantities of the compiled binary, rather than uncompiled source code. It’s also worth noting that a blank project with an empty update function results in a compiled binary of only 147 bytes. Playdate compiles to Lua bytecode.

Content	Kilobytes	%
Main code	19	49
Two music tracks	5.5	14
Three bitmap fonts	2.5	6
Synthesized sound effects	2.5	6
Custom particle system	2.0	5
Animated system icon	2.0	5
Animated system card	2.0	5
Pulp music engine (modified)	1.5	4
Online scoring system	0.5	1.25
How to play instructions	0.4	1
Custom soundtrack capability	0.1	0.25

“Main code” contains: physics simulation, game structure and state management, multi-layered scoring and bonus system, score/stat tracking, loading and saving stats and settings, path recording and playback, animated introduction, plus the following dynamic systems: scrolling starfield, screen shake, music system, sound effects system. All running at 40fps.

Abandoned and removed features

I tried a bunch of stuff during development. Such as asteroid fields or meteor showers that introduced obstacles that needed to be avoided, and black holes that would magnetically attract the ball. But I felt they detracted from the pureness of the concept, so I didn’t go any further with them.
The positions of stars are randomly generated, but I have implemented a fixed “daily” layout in the game, which is really fun. It’s a different experience to be able to play the same layout over and over, improving your execution of the same moves and eking out higher and higher scores. I did plan to reintroduce that option when Playdate Catalog got score boards that reset daily, but by the time that happened I was no longer developing Playdate.

Manual/Guide

I really loved the manuals that came with games in the 8-bit and 16-bit era. So I thought it would be fun to write a manual/player’s guide in the old-school style. I love reading those sorts of manuals, where the developer gives you a little glimpse behind the curtain so you get an understanding of how the game works, with some small hints and tips littered throughout—for the most inquisitive players! If that sounds like your thing, download the manual from the game page.

Timeline

I worked on YOYOZO from September 5th to 27th, submitting it to Catalog on 21st and polishing it for the final week after that. After the game was approved I added online score boards one evening just prior to launch. It was in review and waiting for release longer than it was in development!

The purpose of this section is not to say that developing a game quickly is better than developing one slowly, or vice versa, but rather to show the importance of scoping a game well and then sticking to the plan.

2023-09-05—initial prototype
2023-09-07—playable prototype (3 days)
2023-09-07—quick progress (3 days)
2023-09-09—came up with the name (5 days)
2023-09-14—polishing and balancing (10 days)
2023-09-20—revelatory physics tweak (16 days)
2023-09-21—addicted to my own game (17 days)
2023-09-21—submitted to Catalog (17 days)
2023-09-23—game over replay (19 days)
2023-09-26—layout design using spreadsheet (22 days)
2023-09-26—game over stats screen (22 days)
2023-09-27—final version (23 days)

…and then some waiting until:

2023-10-10—approved for Catalog (36 days)
2023-11-19—added online scoreboards (76 days)
2023-11-21—released on Catalog (78 days)

…so that is 78 days (11 weeks) from initial prototype to being live on the Catalog store!

Credits

YOYOZO is a game by Matt Sephton, with music by Jamie Hamshere.

Thanks to CANO-Lab and Testers.

Elsewhere

2024-10-16—Game Republic 2024 Awards: Best Indie Game Made in the North of England
2024-03-08—Playdate Community Awards 2023: Best Arcade Game
2023-12-27—Ars Technica: YOYOZO wins GOTY accolade!
2023-11-30—Ars Technica
2023-11-24—Hacker Newsletter
2023-11-23—Time Extension
2023-11-22—Hacker News
2023-11-22—Tildes

OpenSCAD to Sprite Sheet workflow

by Matt Sephton — Wed, 04 Oct 2023 15:19:00 +0000

I just released the “OpenSCAD to Spritesheet” workflow I created for Daily Driver:

github.com/gingerbeardman/openscad-spritesheet

It’s a Frankenstein mish-mash of a Makefile and several shell scripts that evolved over many months/years. Initial rendering is done using OpenSCAD, and post-processing is done using ImageMagick. Model poses and rendering variations are controlled by variables in either the shell script or passed through to the model. The whole process is optimised to do as much in parallel as I could figure. More info at the link above! 🚗💨

Post Processing

After exporting all frames there is some image magick work to process the files as follows:

stitch frames together into a single sprite sheet
split sprite sheet into RGBA channels
process channels to recolour and dither as required
recombine processed channels into new sprite sheet image

You can read about that in a previous blog post.

Benchmarks

A full build of 36 cars is as follows:

3GHz 6-core Intel Mac mini 32GB
- 100% CPU for ~26 minutes
M1 Pro 10-core MacBook Pro 16GB
- 70% CPU for ~9 mins
- about 3x speedup
- approx 16 seconds per car

That’s parallel 3D rendering, PNG writing & compositing & processing, and copying of ~140K files (which takes up ~0.5GB of disk space).

Example Model

Not to scale! Sizes of features are exagerated to allow for them to appear correct when rendered at a very small size.

Example Output

990 frames each for car and shadow, total of 1980 frames per sprite sheet. Each sprite sheet takes up about ~400KB of RAM on Playdate, and only one is loaded at a time.

The first colour Playdate game?

by Matt Sephton — Sun, 09 Jul 2023 12:59:00 +0000

This blog post assumes some familiarity with Playdate (a handheld game console with a cool crank control scheme), Playdate SDK and the Lua programming language.

During the development of my forthcoming Playdate game Ball und Panzer Golf (tentative title), I wanted to be able to draw to the debug layer from anywhere in my code. The SDK allows you to draw to the debug layer only from the drawDebug function.

After filing a feature request I thought about it some more and came up with a workaround:

1. (on initialisation) create a full screen opaque image

local gfx <const> = playdate.graphics
local disp <const> = playdate.display

overlay = gfx.image.new(disp.getWidth(), disp.getHeight(), gfx.kColorBlack)

2. (anywhere in your code) draw into that using pushContext (or lockFocus)

gfx.pushContext(overlay)
    gfx.setColor(gfx.kColorWhite)
    gfx.setLineWidth(2)
    gfx.drawCircleAtPoint(x,y,r) -- draw some debug stuff into our overlay image
gfx.popContext()

3. (in debugDraw function) draw the single image of our collected debug drawing

function playdate.debugDraw()
    overlay:draw(0,0) -- draw our overlay image containing all debug draws
    overlay:clear(gfx.kColorBlack) -- blank overlay ready for the next update
end

This means I can draw debug info about a thing from the same code and logic responsible for that thing. For me, with this game, that makes a lot of sense.

Abusing the system

After debugging the positions of everything during my collision logic, it occurred to me that I could abuse this system to give the game a colour overlay.

I do this by using the debug draw in the opposite way to how it’s supposed to be used. Instead of drawing just the debug information, I set the hole screen to draw in colour and then—in the same way as above—at various points in my code I punch out areas of the screen I do not want drawn in colour.

I’m not quite drawing everything twice, as the areas that are punched out are simple shapes approximating the elements in my game. Plus, this is made easier for me because everything in the game is already being drawn only with filled shapes.

One interesting thing about this technique is that changing the contrast (dither pattern opacity) of the golf greens only when running in “colour mode” on the Simulator made things look better. That’s to say that adding colour also adds an extra complexity with regards to contrast. I think that’s the only change to the graphics I’ve done so far but there is opportunity for more.

When I sent a build out to testers I put a cryptic note in the changelog “added: chartreuse tinted glasses mode” but only one tester figured out what it was referring to. I had asked ChatGPT to suggest a colour that sounds like a shade of red, but is actually a shade of green: it suggested chartreuse (and so I use the “proper” chartreuse hex colour for the base colour of my green layer).

Multi-colour?

This approach could be taken further if the Playdate SDK allowed multiple colours to be used for debug drawing, keep an eye on this feature request.

Physical overlays

Back in October 2021 I bought transparency film in a range of colours to make a physical screen overlay, inspired by early arcade games like Space Invaders and the Vectrex gaming system, which worked but is obviously more hassle as the transparency picks up lint and gets dirty really quickly. This split of blue/green was for sky/grass in a 3D golf game.

Ball und Panzer Golf: making a Playdate game in a week

by Matt Sephton — Mon, 26 Jun 2023 22:11:00 +0000

I’ve been following the X68000 Z mini computer since it’s announcement in the hope that it will bring new activity to the X68000 scene and it seems to be having that effect. In one video from the recent 「68の日」(“68 Day”, named after the date written in Japanese order, 6-8, that’s 8th June the most special day of the year for X68000 fans) I spotted a interesting looking single screen golf game:

Hello kata68k

It was Ball und Panzer Golf an indie/doujin game by @kata68k for the Sharp X68000 series of Japanese personal computers and the recent Zuiki X68000 Z mini system, a new emulator based reimagining of the original classic computer. The name is a pun on the anime series Girls und Panzer and its shortened version is BuPG which I assume is a pun on PUBG.

kata68k’s game, as the name implies, is golf but with a tank. It was created in May 2023 and fine tuned for a few weeks, released in time for “68 Day”. It’s a single player game where you use the tank to shoot holes-in-one on a golf course and try to destroy all flags. All this to say it plays like golf, kinda, but with a focus on high scores.

Aside: my favourite source of X68000 content is the PipitanTV YouTube channel, run by @pipixvi, which has a longer, screen capture video of Ball und Panzer Golf.

I played Ball und Panzer Golf v0.94 using an X68000 emulator and was instantly hooked, by the strange mashup concept and also by the scoring mechanisms that were involved. Kata’s game design values and methods align with my own to a surprising degree. kata68k grew up with the X68000 much like I grew up with another Motorola 68000-based computer: the Atari ST. We’re roughly the same age and have similar interests in many ways.

Anyway, I had great fun figuring out the different types of shots and opportunities to increase my scoring ability during my few plays of the game. Once I’d figured them out, it became a task of improving my skill controlling the tank and the shot power. The shot mechanism itself is worthy of a mention: there is no real charging of the shot and the ball starts to move immediately. What you do control is the moment the ball starts to come back down to Earth. It’s a very strange way of controlling the ball, but oddly satisfying. It’s reminiscent of the two tap system that sets power in most golf games, but at the same time feels completely alien.

Enter Playdate

I currently spend my time creating games for Playdate, a handheld gaming system with a black and white screen and a unique crank control that can be used as a method of input. Whilst on a walk in the park I couldn’t stop thinking of kata68k’s game and how it might work on Playdate. When I got back to my computer I wrote a little bit of Lua code to draw an elliptical golf green on screen, then added a hole, a flag pole, and a flag with a number on it. Then I added a loop to generate random positions and drew 18 holes, adjusting the size so they all fitted a bit better. It might just work.

After a quick dinner, it was time to draw the tank. I really didn’t want to slow down my pace of progress so I decided to keep drawing the graphical elements in code using filled shapes rather then have to draw a tank in pixels. Another option would have been to use one of the cars from my game Daily Driver, but the path of least resistance was to draw a filled ellipse along with a line to show the turret position.

Day 1

That first day everything fell into place perfectly, with little friction and no refactoring. I started from a blank file and wrote just under 400 lines of code. The two most complicated elements were the randomised background and limiting the tank to its circular area, but I’d done similar things before so there was no problem solving involved, just pure implementation. In fact, a lot of this quick prototype made use of tricks and techniques I’d figured out over the past few years of Playdate development, in particular during the development of my game Daily Driver.

At the end of the first day you could drive the tank around the screen, fire the ball at an angle selected using the crank or d-pad, and when you run out of balls it would trigger game over. What it didn’t have is any logic that would collide the ball with the holes, point scoring, or any sort of win state. For some reason at this point I thought it would be cool to have a black tank with three wheels.

Day 1: Timeline

Time	Event
15:40	draw a single “hole”: flag, hole, green
16:00	loop to draw 18 holes
17:00	(dinner)
18:00	draw tank
18:20	(ask permission from kata68k)
19:00	background (interesting use of Perlin and random)
20:00	add controls to tank
20:10	(send update to kata68k)
21:00	limit tank to circular area (tricky but fun)
22:00	ball moving
22:10	(kata68k confirms he’s OK with my version)
22:30	add game states
23:00	add ball height capability
23:45	(send update to kata68k)
00:26	tweet about it

Week 1

The following day I added a first draft of collisions and scoring. There was slower progress, but it was still very steady with no problems encountered. I was keenly aware that the collision and scoring were very naïve and that I would have to refine and improve them going forward. But, regardless, at the end of the second day it was possible to play a complete round of tank golf!

The next two days consisted of fine tuning, polishing, play testing, bug fixing, adding sound effects, and so on. I even managed to record a GIF where I got all 18 flags …my first speed run!? I also received some great early encouragement and feedback from Playdate Squad community members: Donald @Guv_Bubbs, Steve @ScenicSoftware, Atsu @SquidGodDev, Neven @neven and of course @kata68k himself! The game was shaping up nicely and coming together very quickly.

Opportune timing meant that I could get the game in the hands of some testers on a live stream, over at IGDA Twin Cities (MN, USA) as part of their monthly Playtest. Thanks to Mark LaCroix for sorting that out! It was great to watch them play the game for the first time as they discovered the details of gameplay, mechanics, controls, and scoring! I even spotted a bug.

For the rest of the week I polished and played, addressing areas that I thought could be improved. I added accessibility improvements, more opportunities to score, better hole randomisation, even wind effects, and so much more besides.

For the last couple of days of the week I kept release notes, as I felt the pace of progress slowing down towards the end of my self-imposed deadline of one week. I would categorise most changes in those final days as either quality of life improvements or minor bug fixes.

I had not optimised any of the code and was targeting the default 30 frames per second. On the final evening I optimised all text drawing in my main update path, as I could see that was responsible for a huge portion of where my game was spending its time, with the CPU pegged at 100% and the frame rate not able to hit the target 30fps. So the flags with numbers on were pre-rendered as images during initialisation, and the HUD is drawn only when its contents change, and the image is cached for use at other times. These two small and quick optimisations reduced the CPU usage by 20% and put me at a solid 30fps.

There are many more optimisations to be made but this is not the time to do them. There’s too much still to do and I don’t want to lose focus. But for example: I’m not currently using the Playdate SDK Sprite system and am instead doing things the traditional way of drawing everything every update, so I’m positive I can get some good gains by drawing to a few different sprite layers. There are also some functions I call regularly, such as one that counts remaining holes, that can be optimised or avoided by improving my game logic. I’m confident I can get the CPU time down a good bit more. There’s no real need to do so, but I figure anything that will help reduce power usage or is good for the player is a honourable responsibility for a developer with a conscience to take on. If that goes well I may even increase the frame rate for smoother ball movement.

Shaping up

All the graphics are still composed with filled ellipses, rectangles and lines, varying their dithering patterns to provide different textures. I really leaned into this and over the course of the week fine tuned the tank from a three-wheeled blob to a high contrast, detailed, carefully animated sprite that you might think has been rendered externally. Maybe in a forthcoming post I can put together an exploded diagram of how it’s drawn?

What’s next?

The only things I didn’t manage to fit in in my week sprint were a couple of animations I think will help make the game feel even higher quality and that will increase players ability to read/understand what is happening on screen. I need to make some more changes to the wind feature and the way the flag flaps in the wind. Currently the flag direction is correct but I’d like the length and frequency to be relative to the strength of the wind.

Pretty much all of the maths in this game is high school algebra and trigonometry, wrapped up in some smoke and mirrors to make it feel magical.

Also on the task list are a couple more sound effects, with the goal being one sound effect for each important event or action in the game. I feel that sounds cues are as important as visual cues and players could pick up on one or the other so there should ideally be parity.

I can’t keep up the insanely fast pace of development from this first week, not only because of the physical and mental toll it would take but also because the quick wins of the prototype phase are now gone. To add the animations I previously mentioned, the first serious refactoring of part of the code will be needed. So there is no choice but for progress to be slower from this point at least for a while.

The big remaining task that will take a lot longer than a week is game structure and progression. I have ideas of how I can package the structure of the game now into a short experience with increasing difficulty level and unlimited replay-ability.

But the bigger question is do I want it to be bigger than that? There are no shortage of ideas how how to mashup to concept of tanks and golf, only a shortage of time and budget to make it happen. I could even add a mini-golf type of experience where you’re playing a round of single screen holes with additional hazards pulled from both the golf and tank world.

Launched!

My version of Ball und Panzer Golf was renamed Fore! Track and is available for Playdate via Catalog play.date/games/fore-track/ or on itch where there’s a bargain offline version.

Sparrow Solitaire Tile Workshop

by Matt Sephton — Mon, 01 May 2023 00:00:00 +0000

A little known feature of Sparrow Solitaire is its ability to load user-generated content from files copied onto the Playdate. One day I thought it would be cool to combine two tile sets, so I built a web app to do it!

A wild tile set builder appears! sparrowsolitaire.com/workshop/

3-in-1

As well as allowing you to cherry pick tiles from existing sets (and sharing that selection data with people), you can also load your own image data into the “user” row. This is done using the Pasteboard text area, which accepts a few different types of data.

First it accepts a PNG URL which will be loaded into the user row and must be the correct dimensions.

Secondly it accepts data:image (recommended & most versatile) which can be of any dimension. You can easily copy data:image straight out of the Piskel pixel art web app. You can also generate it on the command line, using the small script below, or using an Alfred workflow or similar automation.

Thirdly, and finally, if you’d rather create a full tile set of your own, you can do it all in Piskel and save it online as a GIF. Paste this URL into Tile Workshop and you can save it straight to an image format suitable for use on your Playdate.

Please do get in touch if you create any tile sets of your own!

Sparrow Solitaire for Playdate

by Matt Sephton — Thu, 13 Apr 2023 00:00:00 +0000

I’ve previously written about the Playdate game Sparrow Solitaire, when we released the Early Access version of the game. That was almost 9 months ago and a lot has changed!

This week the hugely expanded full version of the game released on itch.io, where it’s been for sale for a while, and on Playdate Catalog the new on-device store. It even got its own website!

This post is a continuation of the history of the development of the game, going into the conceptual decisions and visual inspiration.

Mahjong or not Mahjong, that is the question?

This type of game is commonly called Mahjong Solitaire, because it uses mahjong tiles to form the layouts and it’s usually a single-player game. But the traditional tiles are somewhat inscrutable to newcomers. They are from a totally different game that goes by the name of Mahjong, which further confuses the situation. For this reason most Mahjong Solitaire games use alternative, more recognisable and approachable tile patterns.

Whilst reading about the history of mahjong, I discovered that in Chinese the game was originally called 麻雀 (pinyin: máquè)—meaning sparrow. This seemed like a nice alternative name for the game, allowing me to use alliteration, and avoiding the complexity that comes with the traditional mahjong tiles, and of course having cultural sensitivity top of mind.

A brief history of Mahjong Solitaire

Mahjong Solitaire is widely considered a Western invention in much the same way as French-suited playing cards and their related Patience/Solitaire games, but both have their origins in China.

Computer game Mahjong Solitaire was originally created by Brodie Lockard in 1981 on the PLATO system and named Mah-Jongg after the game that uses the same tiles for play. Lockard claimed that it was based on a centuries-old Chinese game called “the Turtle” that he had been shown whilst in hospital after a serious accident that left him paralysed from the neck down.

Not only did Brodie create the PLATO version in 1981 using only his mouth to type the code and draw the graphics, but he went on to make the Apple Macintosh version which was published in 1986 by Activision, as Shanghai, which sold millions of copies. Shanghai II came in 1989 and a whole new genre of games was born.

Wherefore art thou Macintosh?

An interesting point about the first two versions of the computer game: they both had monochrome displays (also referred to as 1-bit). PLATO was orange on black, and Macintosh was black on white. Funnily enough Playdate is also monochrome: dark grey on pale grey. Upon seeing the Sharp Memory LCD display that is used in the Playdate I was instantly reminded of the original Apple Macintosh. I mean, I still use System 7 on an iPad Pro and have a 1991 Macintosh Classic at home so it did not take much to remind me, but it did.

My initial explorations around 1-bit graphics happened on Macintosh, long before I had ever held a Playdate in my hands. I explored fill patterns, dithering algorithms (eventually discovering and popularising a little known algorithm), old drawing software optimised for 1-bit graphics, and diving head first into old clip art collections. Sparrow Solitaire could be considered the culmination of all of this exploration and gathered knowledge presented in a single game.

Once I got hold of a Playdate I started thinking about implementation details. Coding prototypes, figuring out sizes, textures, shadows, frame rate, tricks, optimisations, but with no particular game in mind. Just sailing free across a sea of ideas.

I struck upon a novel way to generate patterns of dots. Instead of using organised Beyer dither patterns, I used error diffusion dithering and fed it a solid colour. When a shade of grey is run through Burkes dithering algorithm it produces organic-looking patterns of dots that are ever so pleasing to the eye. Interestingly, other dithering algorithms don’t exhibit the same result. This image became a catalyst and the core of Sparrow Solitaire.

After this I drew the traditional Chinese mahjong tile set, and figured out a tile size that would allow the standard Mahjong Solitaire layouts to fit fully on screen. Unlike the PLATO and Macintosh games, which used border thickness to denote the height of a tile in the layout, I offset the tiles in a sort of isometric view and added a repeating shadow dither pattern. After this I drew regional variations for Japan, Europe and America. I drew tile sets inspired by the original late-90s Japanese Emoji set, others based on Egyptian and Toki Pona heiroglyphs, and an alphanumeric tile set I thought might be easiest for newcomers. I even recorded sounds of my own mahjong tiles.

Sunset

I found (and promptly forgot about until just now!) royalty free sound effects of sparrows, rain, button presses, confirmation tones. During all of this, amongst my normal music listening, I stumbled across a song that I thought sounded really great: it was the track “Starry Dish” by Yuyake Monster a Japanese music producer. The track is a sort of bouncy low-fi video-game hip-hop and piano thing. I wanted to hear more by this musician, so I clicked on their profile and listened to the next track. It was “Herbal Remedies” and I liked it even more! It featured plucked strings and a melodic bass line and… about half way through… bird song! And these tunes were already tagged as royalty free, so it was meant to be. When I reached out to Yuyake Monster they were super happy to have their music used in a game.

It was at this point that I released a prototype with graphics, sounds and animation of the layout dealing. I quickly realised that it would take a lot of time and effort to finish the game, so I made the difficult decision to abandon it. But work resumed later on with the help of Mac Vogelsang, as you can read about in my earlier blog post.

One vision

Mac had taken on the majority of the programming, slowly eroding what remained of my prototype code and refactoring things into a more solid foundation. I was concentrating on graphics and animation. We shared game design decisions. By this point we had both played a ton of mahjong solitaire games from the original Shanghai on Macintosh, through versions on almost every home console, handheld and home computer platform, to versions on the latest Nintendo consoles. We had a thorough understanding of things that worked well with a mouse, what did not work so well with a game controller, what worked best on screen and what limitations these old platforms imposed on the games.

Comparing Playdate to the best handhelds from the 90s it became obvious that we were working with a much more capable device, in terms of both CPU power and graphical fidelity. We could lean into the strengths of the device and provide a tailored experience that made use of the Playdate’s unique control mechanism - the crank - as well as its excellent sound and graphics hardware. I hope Mac will write more about getting the most out of the device, writing code that made the most of Playdate performance to do things that have never been done before in a mahjong solitaire game. Sparrow Solitaire has truly ground-breaking features some of which are only possible on Playdate.

Meanwhile, with the prompting and encouragement of Mac, I researched classic Chinese and Japanese painting techniques and drew some Eurasian tree sparrows and cherry blossom in the classic ink and watercolour style.

These illustrations were used to create the game’s launch animation. I started to create the animation the traditional way, but quickly changed tact and created it programatically instead.

Content matters

For the full version of the game I created additional backgrounds, cursors, grids, animations, tools to aid development and more besides. I created several fonts, all carefully kerned and tweaked to look their best on the Playdate. I’d created a popular font in my teens and it was fun to get back to that. More backgrounds, more tile sets including my favourite “zen”. Even now, when I see this tile set in the game, I often shake my head in disbelief. How was I capable of drawing these symbols so well at such a small size? My Susan Kare moment, if you will. If ever there was a lesson that you should believe in your own abilities, this was it for me.

Hidden in plain sight

The influence of the Macintosh and the nostalgia in the final look and feel of the game is something I wear proudly. Sparrow Solitaire is the sum total of all my passions and interests, wrapped up in a neat little game that will provide hundreds of hours of fun and relaxation.

But what about if you look a little deeper? You will find brush/fill patterns from MacPaint, Atkinson dithering as first seen in ThunderScan, elements drawn in UltraPaint, pixels generated using DeBabelizer, and so much more. Heck, we even use Garamond as our brand typeface which is the same one Apple used in their classic Macintosh advertising, the most well known of which is the “Think different” campaign. Sparrow Solitaire is my love letter to the Macintosh, but runs on a device that fits in the palm of your hand.

One of my favourite “Easter Eggs” in Sparrow Solitaire is some clip art from the Scroll collections, published in 1986/87 by Japanese Macintosh specialists Enzan-Hoshigumi. Specifically I have used a border for the manual/credits overlay, and several sections of artwork for our patterned backgrounds. These sections of artwork were not bundled as brushes/fills, but are nevertheless easy to cut out and use as a repeating fill in an image editor. They are based on repeating elements that are much larger than the 16x16 pixel patterns of MacPaint, so they allow for patterns that are not as garish and easier on the eyes. Plus, I love the fact that in 2023 Enzan-Hoshigumi finally have their first video game credit, almost 40 years after working on their first video game.

The Great Wave of Mahjong

Finally, to come full circle back to the image seen in the trailer at the top of the page: “The Great Wave of Mahjong”. I came up with the concept for the image and commissioned the wonderful Vxcl to create it, leaving them free to interpret the brief. They pretty much nailed it first time, and there were only a handful of small notes from me - in the form of screen grabs with coloured highlighter markup - to tweak the alignment of details of a few elements. This is the second such render I’ve commissioned, a look inspired by 1980s Japanese PC/game mags.

You can download a high resolution version of this image at itch.io to use as PC/phone wallpaper.

Update!

Less than two weeks after version 1.0 we released an update to address a few small issues and add a bunch more content! It features dynamic weather effects, three new tile sets and more cool stuff. You can read about version 1.1 in this Twitter thread.

Elsewhere

2024-03-08—Playdate Community Awards 2023: Best Puzzle Game

Sparrow Solitaire for Playdate (Early Access)

by Matt Sephton — Wed, 13 Jul 2022 00:00:00 +0000

This post is a history of Sparrow Solitaire, my latest game for Playdate. It started out as a prototype and was later taken on by Mac Vogelsang. We’re working together to make the best ever mahjong solitaire game.

2021, January 10th

I’m really into Hanafuda (Japanese flower cards) and found that the 1991 Macintosh game Shanghai featured tiles based on Hanafuda. I booted it up at Internet Archive and had a quick play.

For the next week or so I went down the Shanghai rabbit hole. Its history is quite interesting and fraught with drama so I won’t repeat it here.

2021, January 19th

This is the date on the first screenshot I captured of my prototype mahjong solitaire game for Playdate.

I tested different size tiles until I found the sweet spot that could fit a whole layout on the Playdate’s 400x240 screen.

The following day I drew a set of tiles and it started to look like a real game! I called it Sparrow Solitaire because the sound of mahjong tiles rubbing together is said to sound like sparrows chirping. In fact, the original Chinese name for mahjong reused the word for sparrow. So this thing had a name at least!

I spent the next month or so, on-and-off, programming object-oriented Lua to manage the game state, tiles, layout, dealing, sound effects and I drew a handful more tile sets.

Daily Driver was my focus and this little puzzle game was supposed to be a short palate cleanser to keep things interesting. When it turned out to be more involved I lost momentum and abandoned it. My todo list at that time was as follows:

Todo
[ ] calc free data per half position
[ ] sound based on free data
[ ] controls to move prev/next tiles
[ ] controls to select tiles
[ ] match tiles
[ ] face down all tiles
[ ] face up free tiles
[ ] editor
[ ] optimise animations

Done
[X] sound effects
[X] define layouts to fill screen
[X] animate tiles
[X] multi-dimension array (as autotable)
[X] ability to reinit table

What an optimistically short set of todo items! That’s game programmers for you.

2022, April 15th

When Playdate launched I bundled the game in my pack of Prototypes and tried to forget about it.

2022, May 12th

I couldn’t stop thinking about the game and it seemed a shame that I had put so much effort into it and then abandoned it. But I’m a realist and I knew that I would never finish it myself. So I thought it would be fun to offer it out to any interested developers and see if they wanted to finish it. No replies to this tweet, but the same message on the Playdate Squad Discord server had some responses. I decided to hand over to Mac Vogelsang (@vogelscript) as I had really enjoyed his Bird and Beans game. So a few days later he began work “finishing off” my programming. What an understatement.

2022, July 13th

For the last two months Mac has worked his magic on the game and I’ve tagged along for the ride. Having worked on my own for so long I wondered what it would be like working with somebody else. It was more fun and productive than I ever could have expected! Mac brought the best out of me, pushing me to achieve better results than I would have otherwise been happy with. Mac also pushed himself, creating what I believe to be a world-first method of cursor control in a mahjong solitaire game, made possible by two properties of Playdate: its fast processing speed and its lack of touch screen!

Out of this partnership not only comes a great game, but some new offshoot projects like an Animation tool (from me), a board game (from Mac), and a Game Options class (Mac’s magic reworking of one of my old classes) and several new fonts some of which are used in Sparrow Solitaire. These projects should all release in the near future.

At this point Sparrow Solitaire is really Mac’s game, albeit one that happens to have my graphics and some of my programming DNA in it, so it’s fitting that it will live on his itch.io page.

Launch Animation

Download

Update, April 2023: the full version of Sparrow Solitaire for Playdate is available now on itch.io and you can also read about what to went into the full game.

Circular for Playdate

by Matt Sephton — Mon, 30 May 2022 00:00:00 +0000

This concept was a typical prototype: the core action came together quickly but then making that into a game took a while.

At some point soon I’ll write a devlog about the problems, solutions, questions and answers involved in its development.

I’m really proud of this little gem. It’s my first time putting a lot of effort into score balancing in the style of my favourite Japanese arcade games, and I hope you have fun trying to reach 1 million points. There are sure to be some surprises along the way.

Download

Circular for Playdate is available now on itch.io.

Have fun!

Wire Hang Redux for 64-bit macOS

by Matt Sephton — Sat, 23 Apr 2022 15:40:00 +0000

I just uploaded a 64-bit macOS version of my 2004 game Wire Hang Redux that I had forgotten all about. So now you can play it on your 64-bit Mac. This version built using BlitzMax. I’ll try to build it for Apple Silicon some time this decade, but no promises!

Read more about the game in the original blog post.

Download: gingerbeardman.itch.io/wire-hang-redux

Daily Driver: Club GTi

by Matt Sephton — Tue, 08 Mar 2022 12:32:00 +0000

My GTi Club: Supermini Festa! obsession has bled into my game Daily Driver… the “Club GTi” car features smaller wheels than the standard size, more roll during turning, and lots of detail and decoration to show off the rendering workflow I spent so many hours on. A good choice for the autotesting/motorkhana/gymkhana stages.

Here’s the 3D model, created in OpenSCAD.

Daily Driver: Teaser Artwork

by Matt Sephton — Mon, 23 Aug 2021 00:00:00 +0000

I commissioned the talented @vxclhd to create a clay-style diorama of Daily Driver!

There are a few things in this scene that I’ve not yet shown in game footage. Imagine this is a box shot teaser in a game magazine, while you wait for the Playdate and its game to release.

“Please understand”, as Satoru Iwata used to say.

It's inspired by a style of plasticine modelling I often see in old 1980s Japanese computer/games promotional art.

Examples that come to mind: box art on some of the Fujitsu FM-Towns Free Software Collection and select covers of MSX•FAN, but there are too many to mention. pic.twitter.com/aAdSEVL4yA
— Matt Sephton🎴 (@gingerbeardman) August 20, 2021

Daily Driver: How big is a sprite sheet?

by Matt Sephton — Sat, 07 Aug 2021 00:00:00 +0000

Since the early days of the project I’ve been generating the car sprites by rotating the 3D model 360 degrees in a sequence of 32 steps. It works well and I hadn’t given it much thought. Until over on the unofficial Playdate Discord server user Jono showed of a hot-dog trick rendered using 64 steps which looked super smooth! This got me thinking about increasing the number of rotation steps used in my workflow for Daily Driver.

Code changes

I had to do a bit of code changing as I had used the value 32, or the angular equivalent of 11.25 (degrees), in a few places throughout my code. Once I’d changed those to refer to a single variable I was set. I can now run the game with sprites of any number of steps.

Rendering changes

Similar changes were also needed in my rendering workflow, moving any hardcoded steps or angle values into a variable. After replacing hard-coded magic numbers with variables, I spent way too long figuring out why angles were being rounded down to the nearest integer. Eventually I realised that in shell scripts the calculation $( 360/64 ) gives an integer result of 5, whereas $( 360.0/64 ) gives the more accurate floating point result of 5.625.

Interestingly, I also needed to increase my filename pattern from %03d to %04d as there are now thousands of images being processed.

How high?

After making the necessary changes to my workflow it is very easy to render a new set of sprites. But what number of steps to use? My immediate thought was to simply double it to 64, which is higher than the frame rate I’m using and the result was definitely smoother.

After this Neven Mrgan asked if I’d explored whether there was a performance limit or upper boundary? I hadn’t but it sounded like a fun thing to explore.

But why go higher? Well, even if we have more frames of animation that than refresh rate, we can still gain in terms of accuracy. The more steps there are the more discrete angles we can show the car pointing. That was good enough reason for me to try it out.

I spent some time exporting a sprite at 32, 64, 90, 128, 180, 256, 360-steps to compare not only the smoothness of the animation but also other related implications.

Selected results

Most modern browsers are well-behaved enough to only play an Animated GIF if it is on the page. So you’ll probably need to force reload the page (hold shift and click reload) to synchronise one or more of the below animations.

Stats

steps #	render time Secs	frames #	width PX	pixels W×H	png KB	pdt KB	ram Bytes	ram MB
32	30s	704	1216	1016576	48	39	147404	0.15
64	59s	1408	2432	2033152	64	78	294807	0.29
90	82s	1980	3420	2859120	111	107	414572	0.41
128	114s	2816	4864	4066304	143	140	589614	0.59
180	159s	3960	6840	5718240	174	188	829145	0.83
256	192s	5632	9728	8132608	209	227	1179228	1.18
360	285s	7920	13680	11436480	240	264	1658290	1.66

Charts

Implications

The increase from 32-steps to 360-steps is echoed by an increase of around a factor of ten across each of rendering time, number of frames and memory usage.

In the above table we can see that related stats increase pretty much linearly, with a slight downward trend for file sizes and a slight upward trend for everything else.

The increased smoothness is great, and very easy to notice. The benefits of the increased smoothness becomes less noticeable with each increase in step count. However, it’s important to remember there are other implications:

Rendering time
File size
Memory usage
Performance in-game

Rendering time

This increases from what I would call a quick 30 seconds per render at 32-steps, to an extremely slow 284 seconds (4m45s) at 360-steps. For a full set of renders it’s not as easy as multiplying that number, there is some overhead that goes with it. This means a real world increase from ~20 minutes to multiple hours, which could be a problem. Cars aren’t generally re-rendered very frequently but when I do render them I do it many times as I make minor tweaks. So, at this point all numbers of steps are on the table but with a preference for those with shorter rendering times.

File size

Playdate’s compiled image format is very similar in file size to an optimised PNG. The file size increases by slightly more than double as the number of steps is doubled. Even the largest size at 360-steps is only 264KB (0.26MB) which seems OK in the grand scheme of things. All numbers of steps are on the table.

Memory usage

As we can see by the table below, memory usage is quite optimised on Playdate. The system is clever enough to trim transparent areas from cells of sprite sheets and store the offset of the image instead of the complete raw bitmap data. For this example sprite memory usage is roughly (W×H÷8)*1.16 rather than the expected (W×H÷8)*2.0. The car sprite is my largest occupier of memory. Only one is loaded at a time and even at 360-steps it fits comfortably in the Playdate’s 16MB RAM. All numbers of steps are on the table.

Performance in-game

I’m targeting a refresh rate of 60fps on the device, so it’s important for me to check that any changes to rendering don’t have an adverse effect on performance. At 32-steps the car sprite was changed roughly every second update, with 64-steps and higher the car sprite will be changed every update. Looking at performance in broad terms, there does seem to be a small hit when using the large numbers of steps. It doesn’t prevent me hitting 60fps, but it does leave me less time to do other things I have planned.

Final choice?

If you’ve read this far you’re probably wanting to know my choice. How many steps did I choose? Well, the jury is out. This is the sort of thing I’ll have to live with for a while before I settle on a choice.

I’ll probably end up going somewhere in the middle with a choice that gives increased smoothness and accuracy, renders fairly quickly and doesn’t affect performance in-game.

Daily Driver: To GIF and Back

by Matt Sephton — Wed, 14 Jul 2021 00:00:00 +0000

When rendering my vehicles I generate a single PNG containing all frames. Playdate SDK calls these image tables, or more specifically matrix image tables. You could also call them sprite-sheets, with the one qualification that every sprite has the same dimensions.

Given that these are plain old images they can be viewed easily. Showing a grid on top of the image makes the layout obvious. You can edit the image as a whole easily enough, but what if you want to adjust the size of every cell? Then we have a problem.

There are a few apps that can load image tables, asking for the cell size during loading. My favourite such app is Piskel which has good options for import, editing, and export.

However there is another type of image that consists of multiple frames of the same dimensions: the Animated GIF. There are far more apps that can deal with this format, such as Acorn or Adobe Photoshop.

Problem

How can we convert a matrix image table to Animated GIF, and back again?

Thinking

We could use Piskel, but its GUI isn’t the most straightforward so using it twice at separate points in the conversion process gets old fast.

So I had the idea of writing a couple of small shell scripts that leverage imagemagick and can be run from my Makefile, the command-line, macOS context menu, or all of the above.

Solution

Below are both scripts, be sure to grab the Gist versions as they have error checking and “help” usage display.

Convert image table to Animated GIF

Convert Animated GIF to image table

Daily Driver: Teaser Trailer

by Matt Sephton — Tue, 08 Jun 2021 00:00:00 +0000

To celebrate today’s Playdate update video here is a Daily Driver teaser trailer. Yay!

Daily Driver: Channelling RGB into 1-bit

by Matt Sephton — Sat, 05 Jun 2021 00:00:00 +0000

After successfully splitting out dark and light elements of the sprites and rendering them in a HDR style, I figured: why stop there? Maybe I could squeeze another colour into the render - some specific shade of grey - that I could treat in a different way to introduce dithered areas to the sprite.

This came together very quickly but it resulted in my Makefile, yet again, becoming too complicated. So I decided to rethink my approach.

If only there was a way to encode information about three different colours in a single bitmap image. Hang on a minute, there already is: RGB!

Channels

So my new idea was to use red, green and blue as the colours for my render, then split the image into those colour channels and process each individually to get separate light, dark and dithered elements.

Using imagemagick it is easy to separate a single channel from an image:

magick render.png -channel G -separate green.png

From this simple start things quickly become more complex. I always find building imagemagick commands a very time consuming process. Indeed, it took me a long time to arrive at a workflow that was just right. But I think of it as time well-spent as it will result in much quicker and easier iterations when designing vehicles.

Overall, I did a few more tricks:

threshold convert the channels to 1-bit colour
apply a dither pattern to the green channel
composite select layers back together as the final image

And the process worked a treat!

The resulting workflow takes half as long to execute as my previous workflow, with all vehicles rendering in ~8 minutes compared to ~16 minutes before that.

Here are some example hi-res images showing the journey from initial render to final composite:

Elsewhere

2021-06-06—Hacker News

Daily Driver: Pseudo-HDR

by Matt Sephton — Fri, 21 May 2021 00:00:00 +0000

I love OpenSCAD “the programmer’s solid 3D CAD modeller”, despite its idiosyncrasies. One of the quirks that causes me most pain is the lack of controls for scene lighting in the Preview render. Unfortunately, I use that very Preview render as my main output!

This lighting issue manifests as shadows cast on the model. As I rotate the car some white “highlight” elements become darker. At this point the model is made up of many more shades of grey than I’d like.

The problem escalates when I take the Preview renders and convert them to 1-bit (black and white) ready for display on Playdate. I use a simple threshold conversion where any pixels darker than the threshold value become black, and any lighter become white. The highlight elements that have been cast in shadow are now grey and in many cases after the threshold conversion they end up as black pixels when they should be white. The net visual result is a loss of detail as well as flashing elements as they disappearing on certain frames.

My first attempt at solving this problem was to set model-specific threshold levels. This worked to a degree but there were still elements that would flash on and off as the car rotated, with headlights being the most noticeable. Whilst I lived with the issue for a long time it always bothered me as it did make the sprite feel buggy. Deep down I knew that the results could be better. However, looking at the OpenSCAD development roadmap made it clear that any improvements would have to come from me.

One day, out of the blue, I realised that if black pixels are more reliably rendered then why don’t I take advantage of that and render the model in opposite colours so that the highlights are now black. After rendering I could simply negate the colours in the resulting image and the highlights would become white again. I tried a quick test and the results were good!

Of course this means an additional render stage is added to my workflow, but that’s of little consequence since the Makefile is doing all the hard work. I also had to make some changes to my render scripts so that the normal and negative images are composited together into the final image. The resulting sprites have no flashing elements, maintain more fine detail, and appear a lot more solid as a result. Excellent!

Afterwards it struck me that this process is similar to HDR photography where multiple photographs are combined to increase the dynamic range in the final image. So, just for kicks, I’m referring to this technique as HDR 1-bit rendering.

Daily Driver: Makefile

by Matt Sephton — Wed, 19 May 2021 00:00:00 +0000

During the shadow rendering changes I was generating new sprites quite frequently, and I quickly realised that my mess of shell scripts just wasn’t a good enough system to be used in anger. I would have to call my scripts manually, with a variety of parameters, and remember a bunch of stuff unique to each script.

So I spent a day converting the script system into a Makefile, with rules for:

rendering
stitching
post-processing
copying
cleaning

I also improved the scripts to make them touch all their output files with the last-modified timestamp of the original 3D model, meaning the scripts could become self-aware and know which output files are up-to-date and which need re-rendering.

With this system I can generate a full set of renders of all vehicles in ~minutes, or render just a single car in ~seconds. This is such a huge time saver and has enabled me to iterate on car designs more quickly and easily than ever before. I’m already seeing the gains in much better sprites.

Believe it or not this was the first Makefile I’ve ever needed to write from scratch. I knew enough about them to know that they would be a good fit for this task, and it was fun to learn more about something I only knew in passing.

Daily Driver: Pre-rendering Ranger

by Matt Sephton — Tue, 18 May 2021 00:00:00 +0000

Since very early on shadows in Daily Driver have just been simple rectangles: one size fits all, rendered from a single 3D model, and post-processed to add dithering. MVP, you know? Over time I decided to do multiple shadows, one each for short cars and long cars.

Sometime later I threw caution to the wind and decided to render per-car shadows. However, the OpenSCAD projection() command that I was using was so slow! In fact it zapped my desire to finish implementing the feature. Instead, I let it sit for many months.

Recently, I picked things up again to get the a new trailer and demo out. And then it hit me, that if I flatten a car on the z-axis—as if Looney Tunes dropped a heavy weight on it—then that flat thing will be a close enough equivalent of a shadow for my use. So I did just that and the results were great, and more importantly very quick to render!

So I went all in and decided to not only render one shadow per-car but to render shadows for each individual frame. So now the direction of the front wheels and details of the body shape are reflected in the shadow. It might sound like a small thing but it really makes a big difference. You can see old vs new shadows in the image carousel below.

It’s in situations like these that I’m really proud I put a ton of early effort into the tooling and build process that generates my sprites.

Result!

Daily Driver: Happy New Year!

by Matt Sephton — Sat, 09 Jan 2021 00:00:00 +0000

I hope you’re safe and well and wish you a great 2021. I’m back at it, and am confident this year will be the year of Daily Driver and more besides!

Recent work on the game includes improvements to the physics of in-game objects and creation of yet more vehicles and levels.

“The car’s the star”, as they say, so I have sunk untold hours into both the physics and graphics of many different cars to ensure that the depth of control and animation is enough to hold a players interest for the time I hope they will spend with my game. There’s no final vehicle line-up, as often some cars don’t look unique enough after the first rough model is tested in the game. But these two are keepers!

Interestingly, both these vehicles show off one aspect of the game that I’ve not really talked about so far: reference and nods to classic games. Here we can see an RC car (whose antenna wobbles!) that is a nod to games like Re-volt, RC Revenge, Smash Cars, RC de Go!, Excite Truck, RC Pro-Am etc. And the forklift is a nod to Shenmue and the infamous New Yokosuka Harbor District.

Band-kun バンドくん musician simulator (1990, KOEI)

by Matt Sephton — Wed, 16 Dec 2020 00:00:00 +0000

I’ve been playing an old (1990, KOEI Co Ltd) Japanese NEC PC-9801 game バンドくん [Band-kun; Mr. Band; Band Man] where you start a band and have to recruit members, make some recordings and live a life of sex, drugs and rock’n’roll. It was also available for the Fujitsu FM Towns and Sharp X68000 Japanese personal computers.

Band-what?

Band-kun is a hybrid simulation/adventure/rhythm game. You explore a fictional city taking to various inhabitants, learning about the music and the music industry, recruiting band members and performing and recording music. You perform the music using mouse gestures, so it’s possible to ad-lib and receive better/worse results a little like playing a musical instrument. After recording you need mix the song in a studio, then get your friend Bob Marley to sell your CDs on the street corner, or figure out how to get the music played on the local radio station which is, of course, broadcasting from a zeppelin riding high above the city.

You need to work dead-end jobs to pay your way, and repeat the recording/gigging process to work your way up through soul-destroying small club gigs to a big arena gig, and allegedly you can even die from the excess partying.

Playdate version?

It’s originally B&W so I figured it would look great on Playdate, so I made a little proof of concept.

Band-kun required a MIDI-capable sound card PLUS an external MIDI sound module - a very expensive 30,000JPY piece of equipment back in 1990. So it wasn’t a success and was forgotten about. But it eventually led to Guitaroo Man and the birth of the music game genre on PlayStation.

Anyway! I’d love to licence Band-kun and re-release it on a modern device that can do the original concept justice. The Playdate crank and accelerometer could be used to perform the music!

I wondered if anybody knows KOEI founder Youichi Erikawa (aka “Kou Shibusawa”)? Hook a brother up! バンドを組んでメンバーを集め、レコーディングをして、セックスとドラッグとロックンロールの生活を送るという昔（1990年、KOEI）のPC-9801のゲーム「バンドくん」をプレイしています。@koeitecmogames からライセンスしたいので、襟川陽一に協力をお願いします。

Edit: since I originally wrote this twitter thread and blog post, contact has been made with KOEI’s licensing department. 🤞

Period reviews

Detailed review from the 1991-01 issue of #マイコンBASIC micomBASIC

Courtesy of a scan at Internet Archive.

Super Soft Hot Information: Band-kun #バンドくん in #micomBASIC1990/12

Courtesy of a scan at Internet Archive.

“SLG in which you form a band, gain experience through practice and live house performances, and aim to win a contest. After winning, the game turns into a highly flexible session software. MIDI compatible.”

Review of Band-kun #バンドくん in Technopolis #テクノポリス 1991/01

Courtesy of a scan at Internet Archive.

“We borrowed a studio and practiced hard with our friends to win the contest. Hone your skills!”

“In the city, you’ll try to win a fight against a band member. It’s hard to get them to play with you at first.”

Translation (WIP)

I’ve been poking around in the Band-kun game files.

Everything is stored uncompressed in very simple structures across a few files. I’ve not figured them all out, yet, but can see graphics (done), dialogue (partial), music (to-do). Band-kun ships with Scenario 1 “ZAP CITY 1991” and is able to play additional scenarios, but none were released.

Regardless: it should be easy to create a translated version of the included scenario. And maybe even create a new scenario (varying difficulty depending on changes).

User Manual

A scanned PDF for Band-kun #バンドくん is available with thanks to the Neo Kobe project archive.org/details/band-kun-manual

Promotional leaflet

Download the game

Get the disk image at Internet Arcchive for PC-9801 or FM-Towns

All the faces

Here are all 120 “famous” faces, extracted from PC-9801 Band-kun, thanks to @fukui_keeekn on Twitter.

Birthday blog post?

Check out my other #birthday blog posts.

デイリードライバー

by Matt Sephton — Mon, 14 Dec 2020 00:00:00 +0000

The last couple of months have been tough going for a couple of reasons.

Firstly, a new version of the Playdate SDK broke my game in a couple of important ways: my method of targeting 60fps stopped working, and more seriously the controls stopped working. The workaround for both of these issues was long and drawn out, but here’s a quick summary:

Until this point I was waiting for the next frame update using the SDK wait() function: one line of code that waits for a required amount of time. A change in how this works meant I was stuck. My workaround was do it in a more naïve way - just constantly checking the system timestamp to see if the allowed time for the current frame has passed. Keep it simple, I guess.

The overhead of idling the CPU—the time it takes for it to wind down, do the wait, and then wind back up—is actually quite substantial when it takes a few milliseconds and you only have sixteen of them for each update!

The end result is that the game is now running… better than ever. Even after these issues were resolved at a higher level by the Playdate SDK team, I have kept using my workarounds as the game runs faster. So, silver linings and all that!

Secondly, an important issue that remains unresolved is exactly how—and when—Daily Driver will be released. I’m hopeful that will be as part of a Playdate Season, where games are delivered to the device on a schedule and you don’t know what game you’ll be playing until you see the light flash and you pick up and wake up your device. That’s the magic I want my players to have a piece of. That might turn out to be later rather than sooner, so we’ll have to be patient.

Anyway, other news: I’ve been trying to decide how to render the name of the game in Japanese. The English title uses Futura Bold Oblique which is a style that does not translate directly into non-Roman typefaces. I had found some bold Japanese fonts, with a little bit of character, but they seemed too cute and not geometric enough. After much investigation and many mockups I opted to draw the necessary katakana characters by hand, on a grid, and it’s turned out rather well. I’d love to expand this into a full typeface, but that’s a project for another time.

Doing this sort of graphics work, or car design/rendering, are my goto procrastination tasks when I don’t have enough mojo to dive into the code and tackle the remaining work. So I’m sort of treading water on the final push of work needed to get the game over the line.

Daily Driver: Automation Improvements

by Matt Sephton — Fri, 09 Oct 2020 00:00:00 +0000

The recent automation was really just help with organisation. As soon as I started looking at running OpenSCAD from the shell/command-line it became obvious that I could do the rendering and organisation in one step without having to use external apps like Hazel.

So, that’s now done. I render all the frames, with more sensible filenames, to a single folder.

If I run all the renders one after the other, maxing out a single CPU core (99% CPU usage), time taken:

~17 seconds 🐢

But, using the & directive and wait command, I can run the renders in parallel (well, technically it’s one process each; and batches of 32 works best) using all 6 CPU cores (~485% CPU usage), time taken:

~10 seconds 🐇

…the beauty of the command line!

Note to self: don’t publish a post about an automation breakthrough until the dust has settled.

Daily Driver: Automation

by Matt Sephton — Wed, 07 Oct 2020 00:00:00 +0000

In preparation for regenerating my many cars with x3 the number of sprites, I thought I’d try to sort the rendered frames automatically into named folders because this is fiddly manual work I really don’t enjoy, and a bit of a bottleneck in my asset generation. For each pose I have to render the frames then group the new image files into a folder that describes that pose, as these multiple folders are later be used for batch processing.

I could use macOS Folder Actions for this, but I’ve been using an app called Hazel for many years to do this sort of thing, so that was my first choice.

The hard work is done with a shell script, as I’m quite comfortable writing those.

Flow

get most recently saved .scad file
parse filename to capture car name
parse file contents for left/right/forward/backward tilt values
concatenate all this information as our new folder name
create new folder
move matching file into new folder

This means that the folder name will change based on the render settings in the file—perfect!

I still have to make 9 small sets of manual text changes to render each car pose, so that’s the next thing I’ll try to automate by running OpenSCAD from the command line.

Daily Driver: Weight Transfer

by Matt Sephton — Sat, 03 Oct 2020 00:00:00 +0000

I’ve been playing old Japanese PlayStation game Touge Max G and besides this having a gymkhana mode similar to aspects of Daily Driver, it also has a realistic handling model. One of the things that struck me about that was how the car rocks back and forth when accelerating and braking/reversing. One of the other games in the Touge series also has a school mode that talks you through this concept of weight transfer. It’s realistic and adds some level of dynamics to the car, making it feel less like a solid block sliding around.

So I’ve added this effect to Daily Driver and will be refining it going forward. I find it breathes extra life into the car just as it does in other games with full 3D physics modelling. It requires 3x the number of car sprites but because I render them from 3D it’s not much extra work and I think it’s well worth the effort.

Found whilst backing up an old PC

by Matt Sephton — Sat, 03 Oct 2020 00:00:00 +0000

Backed up a very old laptop and found a bunch of cool old stuff from 15-20 years ago! #thread

2003-04-25: Custom Fruit Labels for a Zelda: Wind Waker competition (I think in Official Nintendo Magazine?) I sent them a fake plastic pear with one of these these stuck on.

2005-01-18: grid-based music puzzle game called BEAT HIT

2004-12-24: game mockup “Katamari Christmasy” 2D side-scroller

2004-07-11: reverse engineering “Mini Golf” JAVA cell phone game to make custom levels. w/ hyphz

2004-03-10: Atari arcade game Super Sprint themed T-shirt

2004-07-22: source code (Blitz Basic, Windows PC) for my game Wire Hang Redux, which you can still grab and play for free at (gingerbeardman.itch.io/wire-hang-redux)

2004-12-21: various themes for Sony Ericsson K700i cell phone

2002-01-15: source code for my Futurama-themed Robotron clone “Bendertron”

2001-04-24: WIP Mode 7 style kart game “Manga Kart”

2002-03-04: source code for Pang style bouncing ball physics

2003-07-02: beach-themed QIX clone “QUARTZ”

2003-07-02: source code for rainbow block matching puzzler “ROY” - it’s not balanced, or much fun, but it’s still downloadable at (gingerbeardman.com/archive/roy/)

2000-2003: source code for my Sensible Soccer clone “Simple Soccer” (gingerbeardman.com/archive/soccer/)

2002-09-17: source code for aborted attempt at bringing @armyoftrolls mockup “Space Squad 5” to life

2002-08-23: source code for my entry into the BlitzCoder Stupidest Game competition, Summer 2002. “Terra Firma” still available to download and play at (gingerbeardman.com/archive/terraf…)

2002-08-24: source code for my kayaking simulator “yaking”

hurrah! was hoping i’d find this. will rinstate working download ASAP at (gingerbeardman.com/archive/yaking/)

2000-06-10: photos from my first digital camera (a Fujifilm FinePix 1400 Zoom) including some of my first car (a 1972 FIAT 500)

1995-1998: my University Comp Sci directory photos (I was age 18-21)

2002-05-23: original artwork for my Sensible Soccer T-shirt that was sold in River Island stores across the UK (still a shame they didn’t print the lines on the neck and shoulders!)

2000-08-06: email attachment ATT09176.jpeg a photo of forest fire. (Bitterroot National Forest, Montana, on Aug. 6, 2000) (earthobservatory.nasa.gov/images/843/bit…)

…plus tons of work files, game screenshots and ROMs, failed prototypes, and random stuff I found interesting. Which goes to show that half a lifetime ago I was exactly the same person I am today. Phew. #end

OK, a couple more…

2003-06-29: me taking photos of a big old widescreen CRT showing the Samsung N504 Virtual Light Machine (VLM-2) - still got it the NUON - no it’s not for sale ;)

2005-09-05: my favourite game at the time was a Japanese skill game called “Pendulumania” (version 1.3 A) still downloadable from (vector.co.jp/magazine/softn…)

2000-10-16: the original Fontographer .fog .fon .ttf files for my font BLOCKOUT (inspired by The Designers Republic but - contrary to their threatening legal letter - actually designed on a completely different grid system!) (flickr.com/photos/emsef/5…)

Daily Driver: Social Update

by Matt Sephton — Sat, 05 Sep 2020 00:00:00 +0000

The launch of this Patreon for Daily Driver also sees the game’s topic on TIGSource Forums as the first Playdate game!

And also on IndieDB as perhaps the first Playdate game? Though I do see fellow devs and Patreon Creators RNG Party are already listed but they are yet to add their current Playdate game.

Daily Driver: Cannonball Run

by Matt Sephton — Mon, 31 Aug 2020 00:00:00 +0000

Accidental new game mode discovered?

“Cannonball Run”

Collect stuff whilst a barrage of heavy things bounce around the screen!

This was a result of my continued work implementing different surface frictions, and I mistakenly set the cones to not be affected by friction and thus never slow down. Hitting them a few times was enough to get them moving at a good speed, and then I drove around the screen.

What I didn’t appreciate is that my collision model uses elastic collision, which allows the car to knock stuff over in a quite pleasing way where the car takes a little bit of a knock. But if those things are moving fast enough, as the cones are here, then any collision will also affect the car to a larger degree. You can see the car being pushed around by the out of control traffic cones.

Daily Driver: One Shade of Grey?

by Matt Sephton — Wed, 19 Aug 2020 00:00:00 +0000

Since I am targeting 60fps one of the things I can do is flash a black sprite every other frame to get a shade of grey. Yes! Grey on a black and white screen.

It only works at high frame rates (note: 50fps isn’t high enough!) because the screen is so damned good that flashing at a slower rate simply looks like… an image flashing. The effects is also visible on device for the same reason.

So I’m not sure I’ll use it, as all other shadows are dithered and flashing them all will hit the frame rate. But it was fun to try! One for another game, perhaps?

I believe this technique was used on other systems with limited colours, such as Game Boy and Palm (to get 4 shades), certain Commodore 64 games (eg. Creatures 2) did it to get never-before-seen colours, and of course old arcade and video games often did exactly my trick to get their semi-opaque shadows.

Daily Driver: Eight-Six

by Matt Sephton — Tue, 18 Aug 2020 00:00:00 +0000

When you get a crazy idea that you’ll probably never be able to use, but you do it anyway, just to scratch the itch.

Daily Driver: Playable Demo

by Matt Sephton — Sat, 15 Aug 2020 00:00:00 +0000

A made a demo build of Daily Driver. It is based on code a couple weeks old (dated 30 July 2020) so whilst not representative of where I am right now with the game it does show my progress since the last build I shared at the start of June.

Controls

any combination of d-pad, A/B, Crank
d-pad U/D, or A/B = accelerate/brake
d-pad L/R, or Crank = steer left/right

Notes

runs at 60fps on device (50fps in Simulator)
pressing Menu twice will reset the current stage layout
pressing Menu then Options will load the next stage
19 different stages (all cone layouts in this build)
includes level editor!

Debug Keys for game (simulator only):

E = open level editor
F = toggle fps indicator
J = jump!
L = list all sprites
N = next stage
P = play replay data
R = print replay data to console
T = toggle telemetry
U = toggle frame limiter

Controls for editor (simulator only):

d-pad = move cursor
A = place an object or increment object under the cursor
B = toggle precision mode
- cursor moves in smaller increments (5px vs 20px)
- drag/move item under cursor
- A = delete item under cursor

Debug Keys for editor (simulator only):

B = new blank stage
D = dump stage JSON to console (for copy and pasting)
E = exit level editor
O = output stage as “m-edited.json” in game Sandbox directory
Z = undo (deletes last item placed)

Daily Driver: Post-processing workflow

by Matt Sephton — Mon, 10 Aug 2020 00:00:00 +0000

My post-processing to 1-bit is fairly simple. I use a bespoke tool that allows me to have “live” (realtime) manual control over a bunch of image filters so I can see the results immediately.

But essentially it’s:

convert to greyscale, using one of many algorithms
reduce colours to 1-bit, decide on dithering or threshold level on case-by-case basis

The grey shades that I applied to my model in OpenSCAD give an element of control during this conversion process. Greys can be pushed either way, towards black or white, depending on my need with the specific model I am working on.

In this instance I desaturated the greys which blows them out to nearer white. And then I chose to threshold to reduce to b/w.

I also have the wheels as a separate finished image so I don’t have to worry if their detail is lost during this phase, I can just paste over the accurate/finished wheels.

Final result, unedited:

I would later touch up the sprite by hand to reinforce any details I think have been lost. I use Piskel for edited sprites because it has really nice sprite sheet support, drag and drop loading, and quick and versatile exporting.

Aside: 32 is a number that is a leftover from a different prototype and it’s stuck. I guess it should really be 36? or 24? or 18?. But it’s too late now! Actually it would be relatively easy to change but I have bigger fish to fry.

The animations alone could run at 99fps—it’s anything that causes more drawing which slow things down. Collisions, not because they are computationally heavy, but because they cause a lot of sprite updates - which means drawing moving things - to happen. I’m working hard to maintain 60fps on device (50fps in simulator for… reasons) and am excited I’ve managed to get here.

Daily Driver: Retrobatch workflow

by Matt Sephton — Sun, 09 Aug 2020 00:00:00 +0000

Retrobatch

process dumped frames x 32
- once each for left, right and straight directions
stitch processed frames together as sprite-sheets x 3
- we end up with three long images
stitch 3x sprite-sheets together
- we end up with our final image ready for post-processing

Edit, August 2020: since writing this post I’ve been able to condense this process into 1 single workflow that executes much faster. See image 4. Thanks to Gus, maker of Retrobatch!

Edit, June 2021: I replaced my all uses of Retrobatch with imagemagick commands.

Daily Driver: OpenSCAD workflow

by Matt Sephton — Sat, 08 Aug 2020 00:00:00 +0000

I took the plunge and upgraded to a Mac mini and 4K display so had to migrate my setup and then figure out why my workflow was broken (spoiler: retina!) compared to my old rMBP with non-retina display.

So, my workflow uses the following apps:

OpenSCAD “The Programmers Solid 3D CAD Modeller”
Retrobatch “a unique application for automating actions on multiple images at the same time”
post-processing “greyscale and dithering tool” (I use my own realtime tool, but any image editor would do it to a degree, see this other thread)

This is so I can re-run a workflow at any point (maybe in a make file) which I often do during development. These become executable assets, of sorts, in my project.

OpenSCAD

define 3D models (I get a feeling like coding CSS in a strange way)
animate the model spinning through one 360-degree rotation
dump frames out as PNG files

Here’s the model definition to try out:

I love building 3D this way, it’s kind of like LEGO. I use basic geometric building blocks (cube, sphere, cylinder, polygon, etc) and some boolean operations (difference, intersection, union). There are some other cool things (hull, minkowski). I have the commands in Dash.appalongside the Playdate SDK docs.

In the image 2 you can see what the model looks like with all the blocks I have used to make it visible at once.

My particular approach is subtractive— kind of like sculpting—I start with large blocks and cut away at them using other shapes and the difference function. When finding the exact placement for a block I use the # precedent which makes the blocks show up as semi-opaque red blocks. See main image.

I colour each block in a one or two shades of grey, black and white. This is to help with the conversion to 1-bit later on. It’s not so obvious here as the lighting makes the colours look many different shades - for example the wheels are black with white centre but look grey here. See image 3.

Using some simple programming constructs and variables I can add booleans to trigger different states, I use this for angled front wheels and tilted car body. See image 4.

And also to set the distance and rotation of the camera relative to the model when in animation mode. In this mode I enter a speed (doesn’t matter but higher the better) number of frames = 32, and the tick the box to dump the images. The tick disappears when the images are all done. See image 5.

I also rendered the skid marks, car shadow, and some other elements.

There is a lot that is annoying about this app

not retina-optimised (so I run it in Low Resolution, set using Get Info on the app)
runs maxed out on a single core
doesn’t have configurable lighting (I’d prefer uniform or no lighting)
Qt Framework app, so not really macOS-native
etc

…but I still use it! I am not aware of anything else quite like it.

Daily Driver: Shine Get!

by Matt Sephton — Tue, 21 Jul 2020 00:00:00 +0000

Added steering assist, which locks your final steering direction to one of 16 directions, rather than allowing any angle. This prevents over steer when trying to turn to the specific directions required in a level. Of course this is optional; it is variable and can be switched off if the player does not want it.

25 July 2020. I added another type of object, one that disappears upon collision meaning that it is collectable. It’s a kind of coin with a coin-collecting sound effect.

No changes to physics have been made in a long time, but I guess on this level there are no collisions so the car is mostly at full throttle and so seems a bit more responsive than previously?

I’ve already done multiple car types with different handling and sprites. Still more to do though.

Daily Driver: Instant Replay

by Matt Sephton — Fri, 17 Jul 2020 00:00:00 +0000

I guess this looks like a looped GIF, but it’s not!

I added some quite simple code to record every button press and the tick time at which it happened. The beauty of this approach is that most frames there are no button presses so the recorded data is very small. The work I’ve previously put in structuring the game in an Object-Oriented way really paid off.

The game engine is completely deterministic—it has no random elements—so playing back the data is also very simple and the result is an exact frame by frame replay.

Seeing this for the first time felt like magic. This is why I love developing games!

Daily Driver: High Frame Rates are Best Frame Rates

by Matt Sephton — Tue, 14 Jul 2020 00:00:00 +0000

Over the course of development I’d been unhappy with the game running at 30fps, as it did not feel responsive enough. I’m a big believer that if a gamer features fast action gameplay and requires quick reactions then higher frame rates and lower response time are what is needed.

Over the lifetime of the project I had beeb experimenting with running the game at a higher frame rate, as the maximum frame rate supported by Playdate SDK is 50fps. When I wrote my physics I did so in a way that it was not tied to one specific frame rate. Actually, it’s more correct to say that it is tied to the highest frame rate of 50fps but is done so in a way that it can be adapted to any frame rate.

Anyway, after a round of optimisations and general improvements to the way I did both the skid marks (draw direct to background image rather as sprites) and sound effects (not attaching the whole sound engine to each object!) my game was running at max frame rate.

So, I decided to see how high the game would run if I removed the frame limiter (which the SDK allows) and to my surprise my hame was running between 60 and 75fps. At this point I had the crazy idea of running my game at 60fps, because… why not? I wrote my own simple frame limiter (which would be more precise if the SDK allowed finer grained time reporting) and now the game runs faster and smoother than games should on Playdate.

One interesting thing I noticed was that if I used my frame limiter code to limit the game to 50fps, I actually had a bunch more time, ~3ms, to do stuff per frame update than if I used the SDK frame limiter! I can only assume that every frame update the SDK frame limiter is doing something I am not doing.

So, writing my own frame limiter clawed back some time from the SDK and also allowed me to go harder, better, faster, stronger. Double win!

Daily Driver: Showreel

by Matt Sephton — Sat, 04 Jul 2020 00:00:00 +0000

Trying out some different things: a grab bag of scenarios.

This long GIF shows several scenarios, different physics, and more! Essential viewing.

Daily Driver: Chequered Flag

by Matt Sephton — Wed, 24 Jun 2020 00:00:00 +0000

Bit of fun at lunch today.

Daily Driver: Influences

by Matt Sephton — Thu, 18 Jun 2020 00:00:00 +0000

Some fellow Playdate developers commented that at this point the game reminded them of Ivan “Ironman” Stewart’s Super Off Road, Super Sprint and even Rocket League.

A few of my influences for vibe:

Atari’s Sprint series, including Badlands
Ivan “Ironman” Stewart’s Super Off Road
Wild Wheels (a car soccer game that pre-dates Rocket League by ~20 years)

And for gameplay:

ExciteBots: Trick Racing
Mario Kart DS/Wii
Power Drive
Richard Burns Rally
The Italian Job: LA Heist
Pro Rally
Runabout series
GTi Club series
1080° series

…so many more, some of which are not even driving games!

Daily Driver: Off Road

by Matt Sephton — Sat, 06 Jun 2020 00:00:00 +0000

6 June 2020. Finally found and fixed a bug in my collision code - needed to use math.abs() in one place to avoid some double negatives messing up collision rebound direction. D’oh!

And now it’s time to Play Ball! I added a lap timer and a cool little LCD font.

9 June 2020. The core flow of the game has been decided: there will be daily driving challenges with online leaderboards. So the game has found a name: Daily Driver.

12 June 2020. Video of gameplay footage and sound effects: www.youtube.com/watch?v=I57JxBp4kBM

Daily Driver: Gameplay

by Matt Sephton — Sun, 31 May 2020 00:00:00 +0000

I have redone the collision/rebound physics, and car visual and steering is now affected when colliding - makes collisions feel really physical. Tyres and Cone obstacles have different collision properties so they feel different when you hit them. It’s a lot of fun to simply drive around and knock into things, which makes me confident I’m onto something good here.

1 June 2020. I’m now happy enough with the handling, time to get some gameplay in here. At this point the game is running at the Playdate SDK default of 30fps.

First playable demo released to Playdate Developer Preview group!

“Fastest Time Challenge”

hit all 8 cones as quickly as possible
obstacles getting stuck under your car will slow you down!

Daily Driver: Obstacles

by Matt Sephton — Sat, 30 May 2020 00:00:00 +0000

At this point I have three rows of rotated cars in the sprite sheet: each has wheels pointing in different directions.

I’m currently doing the skid marks as sprites (which is why they disappear over time) partly because it was easy to get going, and partly to try to figure out some performance limits (~350 sprites in the GIF below, 25 of which are collidable and have my custom physics applied). Will be drawing skids marks straight to screen at some point in the future.

Short term goal is to have some lap races/time-trials, plus a “driving test” or “stunt driving” mode which is what you’re seeing here.

Codename is currently: Crank Turismo

At this point you can’t hear my great synth-powered car engine and skidding sfx!

Daily Driver: from 3D to 2D

by Matt Sephton — Wed, 27 May 2020 00:00:00 +0000

At this point, the only thing that remained of the prototype was the car sprite so I wondered about creating a new one myself. It uses 32 different images of the car with different rotations, making for smooth animation and movement on screen.

Whilst I could draw all those frames by hand, I decided to go down a path that could produce assets on demand. That way if I change my mind I can reprocess the assets whenever I feel like it. The initial process was easy to setup, but I’ve been taking and simplifying the automation process ever since.

I’d previously used OpenSCAD to create 3D models, so it was a natural and easy choice. Also, it’s the only 3D app I’ve ever used—not even Blender! Models are created using a definition language (think of it as a bit like CSS) where you can define shapes and how they interact. I also use the animation function to set the viewpoint and rotate the car whilst automatically saving the images.

In OpenSCAD I lock the view angle and zoom. I tie rotation to the animation value $t. Then I run the animation and click a box to have the app spit out all the rotated images for me.

The output images need a little post-processing, so I use a single Retrobatch workflow to: crop, add transparency, invert, a few other things, and finally stitch the 32 images into one long sprite sheet. (On Windows you can use Photobat)

Finally, I run the sprite sheet through a bespoke dithering tool that allows for “live” manual tweaking to convert the greyscale images to 1-bit.

That’s good enough for my current requirements. Later on I would want extra detail in the renders, either through texturing or by hand.

29 May 2020. Soon after I would start rendering the wheels turning and after that the body so it rocks from side to side.

Daily Driver: Physics

by Matt Sephton — Sun, 24 May 2020 00:00:00 +0000

Now that I was convinced that a driving game could be fun, I was unhappy with the controls and very rudimentary “physics” that the car had. It just didn’t feel very real or compelling; there wasn’t enough depth to the control scheme.

So I used Marco Monster’s Car Physics article (and looked at source code for various implementations of his technique) to implement more realistic car physics including drifting and skid marks. This was a bit of a watershed moment: this was the game I wanted to spend all my time on.

Daily Driver: Racer

by Matt Sephton — Wed, 20 May 2020 00:00:00 +0000

The Collector prototype didn’t end up being as fun as I had hoped, but I thought it was interestingly that it felt a little like driving. So I wondered whether it would change the feeling by putting some different graphics on top of it. I ripped some temporary graphics from the Atari arcade game Badlands and added one simple collision detection rule and there it was! The first recognisable driving game that would serve as the basis for Daily Driver.

Racer

Uses off screen collision map
Crank or buttons to steer
Buttons to accelerate
Variable maximum speeds
Lap counter with checkpoints

Daily Driver: The Beginning

by Matt Sephton — Fri, 01 May 2020 00:00:00 +0000

After receiving access to the Playdate SDK I took a while to read the docs, and play around with small code samples, eventually starting to create my own prototypes in April and May 2020. One prototype in particular was the genesis of Daily Driver.

Collector

Everything is drawn using graphics primitives (circle, rect, line)
Pattern fills rather than pixel dithering
Crank or buttons to aim

Game Archaeology: No Man’s Sky

by Matt Sephton — Fri, 19 Aug 2016 00:00:00 +0000

Video game news outlets are currently abuzz with articles about No Man’s Sky, one of the most eagerly awaited and massively hyped games in recent years. The game sees you dropped somewhere in space with the goals of exploration, resource management, trading and combat.

The dubious matter of how closely the released game resembles the one that was hyped over the past few years will no doubt be hotly debated for many months or years to come.

Regardless, I think the premise of the game is worth talking about because of its influences. Let’s take a trip back through space and time…

Merchant of Venus (1982)

The oldest space trading game I know of, this took the form of a menu driven interface where you could buy your first ship and then transport and trade cargo at a number of different spaceports. Very much a resource management game, but with manual landings akin to Lunar Lander (1979) that were drawn on screen using groups and combinations of letters from the character set. You can play Merchant of Venus online now or read more about it.

Elite (1984)

The grandfather of space exploration games: Elite. This featured 3D graphics, a whole procedurally generated Universe (8 galaxies, each containing 256 planets), exploration, trading, combat, hyperspace jumps, manual docking to refuel, missions, multiple ship types and space pirates. All in 32KB of RAM!

But there was no landing on the surface of planets. Also, somewhat bizarrely, the cassette version lacks the preset missions and has fewer types of ships. You can’t have everything, I suppose.

Read more about the game.

Explorer (1986)

We now come to a game that allows exploration on land, thanks to its scenario of crash-landing on an unknown, unexplored planet. The game features an overhead map and procedurally generated screens as you explore the surface, where you make contact with alien species and are able to open portals to get around more easily.

The graphics were quite impressive for the time, though the fact you’re on one planet was a cunning way to get around the limitations of the procedural generation and the similarities between screens of the various land types. Still worth playing.

Read more about the game.

Starflight (1986)

Whilst Explorer was being released in the UK, over in the USA a development studio called Binary Systems were releasing an all-encompasing space exploration, trading and combat game called Starflight. Arguably even more comprehensive than Elite, it offered exploration, trading, combat but graphically was missing 3D graphics instead going for a hybrid menu-based system with panels of 2D animated graphics to give context to the current objective.

It was released on a range of 8-bit and 16-bit home computers, and also the Sega Genesis/Mega Drive. Game designer Greg Johnson went on to co-create the cult ToeJam & Earl series of games. But, for me, Starflight is his magnum opus. It’s easy to play the game (and its sequel) today on PC thanks to a re-release by GOG or read more about it.

Starglider 2 (1988)

Argonaut Games, a studio best known for creating Star Fox and the Super FX coprocessor chip with/for Nintendo, have an interesting part to play in this story. They’d forged ahead with software-driven 3D engines on computers that had very limited processing power, culminating in Starglider 2 for the Amiga, Atari ST and PC. A tour de force of cutting edge technology, the game allowed exploration of a solar system, planetary surfaces and everywhere in between. Whilst it was set in an open world, the game featured a plot and overall goal for the player: to collect the parts of a neutron bomb and use it to blow up an enemy space station.

Read more about the game.

Hunter (1991)

The final game I want to mention doesn’t involve space, but it does involve a huge open world to be explored and a mission to complete. Hunter was the perfect example of an open world game where you could use many different types of transport to get around the world, from bicycles to boats and helicopters. You could enter buildings, amass an inventory of collected items that can be used to solve puzzles and progress towards your ultimate goal.

The game had three modes: Hunter (a long story-based mission), Missions (a series of smaller missions), and Action (against the clock search and destroy around the map). The game was the most convincing depiction of a real world I had seen at that point, and remained that way for some years until the often compared Grand Theft Auto series of games.

Read more about the game.

No Man’s Sky (2016)

My hopes for No Man’s Sky were that it would combine the best features of all the space exploration games that went before it. It could take the Universe, trading, combat and missions from Elite; procedural generation from Explorer; plot-driven goal from Starglider 2; the land exploration and variety of vehicles in Hunter. Heck, maybe it would just be Starflight with a veneer of wonderful 3D graphics.

But the released version of No Man’s Sky is different. Whilst it has all the trappings of a great game, it falls short in several key areas: balance, plot and—most importantly of all—gameplay. So, in a lot of ways the game is actually no more advanced than the 30-or-so year old games I’ve mentioned.

Stylistically, of course, No Man’s Sky is light years ahead. Gameplay wise it’s no better than Elite or Starglider 2, in fact it could be described as being worse. It appears to be rushed, hurried, incomplete, unbalanced.

Most interestingly, the released game lacks a host of features that had been repeatedly mentioned to the press and shown to the public over the last several years. It almost seems as if they’ve chopped huge important chunks off the game in the last few months.

The Gameplay is in Another Galaxy

So what happens next? In my experience it’s uncommon for such deficiencies in the game to be patched or updated after a few initial patches that correct serious bugs and game-breaking features.

To that end, I wouldn’t be surprised if Hello Games and Sony roll out a different—more and capable—version of No Man’s Sky for the soon to be revealed PlayStation 4 Neo.

In a funny way that would make the game even closer to Elite with a different game depending on the platform you choose to play it on.

Game Archaeology: Rocket League

by Matt Sephton — Fri, 01 Jul 2016 00:00:00 +0000

One of the most successful console games of 2016 has been Rocket League. It features cars playing football (soccer) rather than people. Cool!

Some would say it’s both a surprise hit, apparently coming out of nowhere, and also a novel concept. A while go I was chatting with Simon Hade, COO and Co-Founder of Space Ape Games, who made exactly these observations. At this point the game librarian in me couldn’t help but correct him, so I mentioned that it wasn’t novel at all. 😱

During my formative years I had played a game called Wild Wheels on my teenage crush computer—the Atari ST—some time around 1990, and I’d also played Konami’s GTi Club on my Wii in 2010. Both of these games offer a take on car soccer, and I was sure there had to be even more car soccer games I wasn’t aware of.

On my way home I put together a list. I do love lists.

www.mobygames.com/game-group/ball-sports-with-vehicles

We can see that Rocket League is the latest in a long line of car soccer games, and the sequel of Supersonic Acrobatic Rocket-Powered Battle-Cars from seven years prior. The earliest game of this type is from 1977 and there are at least a couple of dozen others between then and Rocket League.

The Secret of Success

So what made Rocket League a success in light of all the preceding games? Perhaps it was a well executed online mode? But you could then argue that half of the games in the list also had online play.

The most important differentiator is that Rocket League was released on the right platforms to target the right users. The trifecta of PS4/PC/Xbox One means every platform that is home to those “hardcore” gamers who play online seriously. In that respect I think of Rocket League as being more similar to FIFA than you might first expect.

Apparently there are signs of life outside of mobile after all.

Game Critique: Frantic Architect

by Matt Sephton — Fri, 10 Jun 2016 00:00:00 +0000

Frantic Architect for iOS and Android is a great casual game by Will Kwan/BulkyPix in which you have to build as tall a tower as possible, with the kicker being that you have limited control of where exactly the next building block will go. A video will help explain better:

The game has a high degree of polish and the user interface design and screen layout is excellent. However, play of more than a few minutes will lead to frustration, which is something that really needs to be managed by the developer. Too much frustration and the player will go away and never open the game again.

I think there’s one change that could be made that would make the game easier and less frustrating to play:

The block should lock into place on the “touch up” event, rather than on the “touch down” event as it is now.

This simple change would enable the player to reduce their reaction time by keeping their finger on the screen until they exact moment they want to lock a block in place.

The physical movement of lifting the finger off the screen is a lot faster than the the double movement of first touching the screen followed by lifting the finger off again.

Game Critique: Hill Racer 2

by Matt Sephton — Thu, 09 Jun 2016 00:00:00 +0000

From time to time I’ll be posting critique of video games in this way. It’s meant as constrictive criticsm in the nicest possible way. It also goes to show the type of feedback I give to developers when asked to test or review their games.

Recently I’ve been playing a fair bit of Hill Racer 2 on my Apple TV. It’s kind of like Tiny Wings, but with cars. Right up my street! Check it out:

It’s quite well done, but there are a few small details that the developers could look at to easily improve both user experience and engagement.

Game over, man!

When you run out of gas (or petrol as we say in the UK) the game ends immediately. This is quite jarring, and it would be much better if the accelerator stopped working and the car could then slowly come to a halt under its own moment. The benefit of this would be twofold:

the experience would be smoother and less jarring for the player,
the player stands a chance of reclaiming their game as they might be able to reach the next checkpoint even when they have run out of fuel. I have fond memories of clinching victory from the jaws of defeat like this in SEGA’s arcade classic Out Run.

Caught in a trap

Once you upgrade your car a few times you’ll have quite a decent top speed. This should be a good thing, but in fact it’s not. This is because the car body moves about a bit and can actually get stuck in bridges as you drive across them. This should be an easy fix by adjusting the collision of bridges against the car body only whilst the wheels are touching it.

Grinder

You can tell that the game is an iOS port, as it’s built around grinding, in this case that’s earning in-game currency to be able to upgrade your car or buy a new one. On iOS this keeps users in the game and means that the developer can run more ads, and earn more money. On Apple TV ads in games are not an option, so I think the developer should have rebalanced the game to favour less grinding. This last one is a judgment call, though, as it would mean the game would be different across platforms.

Game Analysis: Boom Dots

by Matt Sephton — Wed, 01 Jun 2016 00:00:00 +0000

One thing I occasionally do is a sort of third-person-post-mortem of a game I’ve been playing a lot of. I think about how it might have been put together from a game design and programming perspective. Of course this sort of analysis is just my opinion, but I do try to think things through far enough to prove my point. Often I go so far as to recreate the core game mechanic as a rapid prototype, just to be sure that my thinking is correct.

Boom Dots by Umbrella Games is a great minimalist, arcade-style game that has enjoyed continued success on the App Store. What struck me about the game—other than how well it has been put together—was how simple and elegant the concept is. I see it as a simplified version of Space Invaders. The developer has sucessfully reduced an already simple concept to its bare essentials, doing away with both player movement and enemy formation in the process. You might think that removing those two keys elements would remove the fun, but you’d be wrong. I think it actually amplifies the fun!

Anyway, I was playing Boom Dots, marvelling at the elegance of the concept and wishing I’d come up with it first, and I began to think about how it might be put together. That’s either a blessing or a curse, but I can’t help but think about games in that way after they get a hold of me. Boom Dots is a great game with which to start this occasional series of posts, as it’s a very simple mechanic.

There’s an Enemy Dot. And there’s a Player Dot.

The Player Dot can be released at which point it will move upwards. Meanwhile the Enemy Dot is moving back and forth across the screen.

If the Dots collide, you score and a new Enemy Dot appears. If you miss, it’s Game Over.

Testing whether the two dots, or circles, overlap is as easy as testing whether the distance between their centre points is less than the sum of their respective radiuses. A little bit of trigonometry is required. Easy.

Tapping the Player Dot gives it some velocity to it, and sends it on its way. Super easy.

Now to the Enemy Dot. The way this comes on the screen is really nice: such a smooth curve! And the way it moves back and forth: so smooth! Surely this is difficult to replicate? Well, yes, if you’re doing it from scratch. But absolutely not if you have the ability to perform tweening animations, which I tend to do using a set of tried and tested Easing functions.

Easing functions allow you to specify a curve that the speed of the animation should follow on its way from the start value to the end value. Normally it would move at a constant speed from start to end: Linear. But by adjusting the how fast we go using a mathematical formula, we can make the animation play at a different speeds depending on how far along between we are.

Perfect.

Types of curves that can be applied in this way are: Quadratic, Cubic, Quartic, Quintic, Sinusoidal, Exponential and Circular. Then there’s even Elastic and Bounce, which add a bit of wobble to proceedings.

Easings are easier to understand by looking at interactive visualisations.

So, back to the Enemy Dot moving side to side. We want the animation to start slowly, speed up, then slow down. Looking at the visualisations we see that easeInOutSine will do that, and it’s not as severe as some of the others so it’d be a good one to try first. By applying the easeInOutSine Easing function to the Enemy Dot as it travels back and forth we can get just the effect we require. We can apply a similar function to animate the dot as it comes down onto the screen. When both animations happen at once a smooth curve emerges—mathematics is great!

At its core Boom Dots is as easy as that: two tweens, some velocity on tap, and a simple collision detection check. Cool, huh?

That’s all well and good, but there’s only one way to really know if the analysis is correct: to make a game that way. So that’s what I did.

Play the game right now in your browser or watch a short video of it.

I chose the Phaser JavaScript framework for this particular prototype. I’d been reading its documentation and it looked well suited to the task at hand. For example, it has the Easing functions that I wanted to use to get the dots moving smoothly. SpriteKit, to contrast, doesn’t have built-in Easing functions—though of course you could write your own or port some code across if you wanted to do this natively on iOS. I tend to experiment with a variety of frameworks and tools just to keep things interesting.

Phaser is great because it takes care of the dull boilerplate work enabling you to concentrate on the actual game. It uses WebGL or the HTML Canvas depending on what is best for the device it is running on, and also provides some useful shortcuts for loading of assets, managing game states, easily adding physics and lots more. Explosions, for another example, also come for free. I used a small plugin to add the “screen shake” effect. The circle-to-circle collision I talked about earlier is also made even easier using Phaser:

Is the distance between the two centre points less than the sum of the two radiuses?

The prototype took me a few hours from start to finish, with another few the following day balancing, polishing and adding high score saving. I tend to do these reconstructions a few times a year, mostly on Bank Holidays.

The complete source code for my version of Boom Dots is on GitHub.

Of course, Boom Dots goes a lot further than the core simple mechanic. It has a thick layer of presentation varnish. It tracks every bit of gameplay and uses them to give a steady stream of meta challenges to the player. These “missions” encourage the player to approach the game in different ways; to achieve certain goals in the gameplay such as getting a perfect hit, or surviving for a certain amount of time. It also introduces graphical themes that can be unlocked with extended play. These things keep the player in the game and the developer earning money through ads and in-app purchases.

The developer, Sven Magnus, certainly knows how to juice up a game. That’s a topic for another post.

Boom Matt

by Matt Sephton — Sat, 14 Mar 2015 23:59:00 +0000

This is my version of the mobile game Boom Dots by Umbrella Games, made this one Saturday evening in 2015 using Phaser HTML5 game framework just to see what it was like.

Works on mobile, of course.

Play in your browser: gingerbeardman.itch.io/boom-matt

Wire Hang Redux: update

by Matt Sephton — Mon, 12 Dec 2011 14:54:00 +0000

An update to Wire Hang Redux my version of the Java game Wire Hang, with improved controls and graphics. This version was built using BlitzMax.

Read more about the game in the original blog post.

Download: gingerbeardman.itch.io/wire-hang-redux

Wire Hang Redux

by Matt Sephton — Sun, 20 Jun 2004 00:34:00 +0000

I made a new game! It’s a from-scratch remake of an original Java game, Wire Hang, by Masaki Kobayashi (D2AC) who went on to become part of the Gran Turismo team.

I had a pretty underpowered laptop at the time, and writing my own version of the game was the only way I was able to play it comfortably.

My version of the game, Wire Hang Redux—made with Kobayshi-san’s blessing—went onto to receive over one million downloads from early download sites like Tucows, Version Tracker, Download.com, Mac Update, Home of the Underdogs, Game Hippo, Hyper Jeff, Windows Forest (Japan), and even a little website called Apple.com—back when it had a download section! It was featured in computer magazines all around the world.

Archived web page: gingerbeardman.com/archive/wirehang/

Download: gingerbeardman.itch.io/wire-hang-redux

Circuit Heat

by Matt Sephton — Thu, 23 Jan 2003 12:00:00 +0000

I made a prototype of a game called Circuit Heat. It is a version of the classic network completion puzzle (aka Pipes, FreeNet, Net, NetWalk, etc). The graphics remind me a little of the Atari Lynx classic puzzler Chip’s Challenge.

Notes:

At this time, long before iPhone, I was playing Java games on a (Sagem?) cell phone so many of my concepts around this time were targeted at that sort of platform
The game was was later featured on PC Format 161 (May 2004) cover disc

Screenshots

Terra Firma

by Matt Sephton — Fri, 23 Aug 2002 11:00:00 +0000

This is my entry into the BlitzCoder Stupidest Game Competition, 2002. You need to guide a sky diver—whose parachute has failed—past obstacles and attempt to land on a cow. Fun!

It was written using BlitzBasic and later recompiled in BlitzPlus.

This is the game that made me realise I could make games.

Archived web page: gingerbeardman.com/archive/terrafirma/

Download: gingerbeardman.itch.io/terra-firma

Yaking

by Matt Sephton — Wed, 27 Mar 2002 12:00:00 +0000

A small prototype for a kayak/canoe “simulator” game, featuring water currents, a gate to paddle through, and somewhat unique paddling controls (press left/right alternately).

Made using BlitzBasic and targetting Game Boy Advance resolution of 240×160.

Archived web page: gingerbeardman.com/archive/yaking/

Download: gingerbeardman.itch.io/yaking

Bendertron

by Matt Sephton — Wed, 14 Feb 2001 14:11:00 +0000

This is my Futurama-themed fan-game inspired a little by the Williams arcade classic Robotron and a lot by Jeff Minter’s Llamatron. Written in BlitzBasic for Windows 9x.

Created in Feb/Mar 2001 during the dot-com boom and released in Jan 2002 after the bubble burst!

Explosion animation by the wonderful Alex Amelines
Sounds and graphics ripped from the TV show
It’s a 25-year-old free fan-game, you know?

Play it on an old install of Windows, or on modern Windows using DxWnd.

Free Download: gingerbeardman.itch.io/bendertron

Simple Soccer

by Matt Sephton — Fri, 29 Sep 2000 11:00:00 +0000

Simple Soccer is my take on the classic Sensible Soccer. It was written in BlitzBasic and ran at 800×600 under Windows 9x.

I built multiple parts—player control, dribbling, cpu and formation, goalkeeper behaviour—but never managed to combine it all in a finished game. Still, I count it as my first real game.

Archived web page: gingerbeardman.com/archive/soccer/