Get Info: #playdate

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

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.

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.

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.

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

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.

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

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.

Piskel for Playdate

by Matt Sephton — Wed, 10 May 2023 00:00:00 +0000

I just pushed some changes to my Playdate-centric fork of Piskel:

github.com/gingerbeardman/piskel-playdate/tree/dev-1047

This fork:

can be used to build desktop apps on latest operating systems
- updated to future-proof dependencies and build process
- builds for Windows, Linux, macOS
has Playdate-specific features
- get frame size from imagetable filename
has quality-of-life improvements
- save keyboard shortcut will export PNG
- ignore warnings preference
- turns off animated preview by default
- different window size and positioning
- stops nagging if run in WebKit
- modern macOS icon
adds useful community improvements
- Outliner tool
- Dither modifier keys
- Keyboard cursor
- Shift Palette Color Index Brush
adds new default Pencil tool
- draws in the opposite color to that of the start pixel

Apple silicon support

Check out the readme for details on how to quickly generate a new build without having to build nw.js from scratch. It’s very easy! Thanks to Ayushman Chhabra for help and hints.

Image Table support

Most of the time I load Piskel and drop an image table (a sort of sprite sheet) on it. Having to manually enter frame/cell size dimensions got old really fast, so this was my main motivation for doing a custom build. It’s a simple hack that checks the file name and parses out the cell dimensions. Slightly more tricky was trigger changes to the import panel so that everything looked and worked as it should.

Ignore Warnings

After editing an image in Piskel the majority of the time I export it and then quit the app. The app always nags twice: firstly to make sure you wanted to “leave the site?” - a leftover from the fact this is a web tool at heart - and a secondly to make sure you want to “abandon unsaved changes?”. An option to ignore these warnings is such a time saver.

I also took the opportunity to add some useful features developed by the community.

Outliner tool

Thanks to ElectricToy for this patch, it works like flood fill but only fills the outline of any pixels it hits. You can hold Cmd to do a slightly thicker outline including corners.

Dither modifier keys

Another one from ElectricToy, this gives you 25% ad 75% dither patterns by holding modifier keys, in addition to the standard 50% checkerboard dither pattern.

Keyboard cursor

I’m not sure how useful this really is, but I added it anyway. Thanks to juliandescottes for the patch. You can control the pixel cursor location using Alt+cursor, and space will activate the current tool at that location. I haven’t tried it but you could set up a game controller to use these keys and draw like Dan Malone did!

Shift Palette Color Index Brush

This tool allows you to do shading using neighbouring colours more easily. Thanks to blurymind.

And I even added a new tool myself!

Pencil tool (new default)

Classic Macintosh style Pencil. Draws in the opposite color than that of the pixel the stroke begins on. If the stroke begins on transparent, or the secondary color, it draws in the primary color. If the stroke begins on the primary color, it draws in the secondary color. This minimizes the need to switch between selected colors. To draw in a single color you won’t need to change colors or tools at all.

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!

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.

Aquaplus P/ECE: Game Reviews Vol. 2

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

If you’ve not yet read my review of the P/ECE hardware comparing it to Playdate, now is the time to catch up! It includes my 6 favourite games on the system.

Below I cover more of the interesting and unique games that I enjoy on the system.

Delta Star, by BLACK FTZ

A new game for P/ECE in 2021! Well, technically it’s a re-release but I’ll take what I can get after all these years. Especially for only 500¥ at BOOTH (pixiv account required).

At first glance you might think this is a simple Asteroids clone, but you’d be wrong. Whilst it does share much with that concept it adds in enough of its own ideas to make it unique.

First, the big differences: you can pass through enemies if you’re careful, and you can shoot down enemy bullets. That’s right, these aren’t lifeless hunks of rock floating around in space! There are multiple types of enemies some of which will fire either normal bullets or homing missiles. Your ship has forwards and reverse thrust, forward dash (a predictable and much more enjoyable equivalent of Asteroid’s teleport), sideways strafing (which I should use more often), and emergency braking. You can fire multiple shots at once, as expected, but they’re limited in number and have a short range of roughly a quarter of the width of the screen.

There are 52 levels, with 4 boss encounters, and continue points. Gameplay is against the clock with remaining time being converted into points. Extra lives are awarded at key point milestones and greeted with one of many great sound effects. The initial levels are easy and can be completed quickly, almost like a tutorial, and after that difficulty ramps up quite nicely. As an example, enemy bullets aren’t seen until level 9. And I adore for the motivational messages at the end of each level that let you know how you did “don’t mind, nobody is perfect”.

The game features smooth 60fps vector graphics with sub-pixel accuracy, plus some nice effects using multiple lines of different shades of grey. And amazing chip tunes. Listen to the high score entry tune at the end of the above video!

I’ve been playing the free “Gratuitous Version” which has only one boss type and lacks music, so I’m excited to spend more time with this fleshed out version now that it’s available once again. Awesome work by BLACK FTZ team, what a lovely surprise for 2021.

Speed Barricade, by Kenta Cho (ABA Games)

This was previously shown in my blog post comparing the P/ECE with Playdate, but I neglected to mention one cool thing…

Speed Barricade LIVE, by Kenta Cho (ABA Games)

If you play with your P/ECE connected using USB cable to your Windows PC you can use a special client app, Speed Barricade LIVE, to show real-time 3D footage of your game in full colour at high resolution! A true spectator sport.

Majang Project, by Hiroshi Makabe

This game came out of the first of two P/ECE Hand Books written by Hiroshi Makabe. The development of the game was outlined in the book and on an accompanying website. It has impressive greyscale graphics, nice animation, wonderful chip tune music, sampled voice clips, win/lose scenes, and hosts a nice VS CPU game of Mahjong. And that’s Riichi/Japanese Mahjong, not the Solitaire type you might associate with the name. I’d say this game is definitely of retail-release quality and was a good showcase for what is possible on the platform.

ALERT (アラート), by Jumpei Isshiki (HELLO WORLD PROJECT)

A nice little barrage shmup with procedurally generated boss fights! Prize winner in the Megastore Cup official contest. There’s a lot going on here, not just the bullets but also the gameplay logic and music. Remaining enemy bullets turn to points which offers an engaging risk/reward mechanic. Three game modes, Easy, Hard, and ENDLESS. Let’s go for the high score!

I read that there was once a port of this game to Dingux-based devices, and found it on a download site (I guessed “alert” was the password, how lucky!).

Delivery Bird, by Hafupon

This is a Sokoban that shifts the view to side-on rather than top-down, which allows for height and gravity to enter into the puzzles. As with many of the best games on P/ECE, it was entered into one of the official game development contests run by Aquaplus. This game won a runner-up prize.

There’s also a Windows version that expands on the concept.

Norito, by Gorujii

Another runner-up in the Megastore Cup official contest. A great looking game featuring fluid wire-frame 3D with dithering for distant objects. It’s a strange sort of shmup that makes me think of both Jumping Flash and Battlezone. Controls take some getting used to but after that score attack is quite a challenge. The game system and stages are intertwined with a story, and things like the “one-shot” fortune-telling add extra flair.

In the next volume of reviews I’ll cover the official bundled games in addition to some homebrew ports of popular games from other systems.

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

Aquaplus P/ECE (vs Panic Playdate)

by Matt Sephton — Thu, 19 Aug 2021 00:00:00 +0000

The P/ECE was a Japan-only handheld/mobile gaming console released in late-2001. It was created by Aquaplus, a company better known for visual novels, so it carries with it a certain oddball charm. After 20 years I find it heart-warming to see that the official website is still online!

What is it?

An early preview of the P/ECE referred to the P/ECE as a portable game console though the water was somewhat muddied by the fact that one of the built in apps, Picket, was a PIM (Personal Information Manager). This means it was often referred to as a PDA. It has a d-pad, start and select buttons, and you can play games on it—that makes it a console in my eyes. But a console where each unit could be used as a development device by connecting it to a desktop computer.

Looking back at the P/ECE it was ahead of its time in many ways. To get a feel for what was going on when it came out:

the most popular phone manufacturers were Nokia and Sony Ericsson
the battle between the PlayStation 2 and Dreamcast was ongoing
ICO was the latest PlayStation 2 game
Rez was the latest Dreamcast game
the iPod and Game Boy Advance had both just launched
YouTube and Facebook had yet to be created

…it really was a different era!

Discovery

I learned of the P/ECE several years ago when looking at the output of one of my favourite video game developers, Kuniake “kuni” Watanabe. He’s probably best known for Panekit, and open-world sandbox game on PlayStation. Though my favourite of his games is MaBoShi on Wii (and DS via download play) which is a razor sharp focussed set of three games that interact with each other in an innovative (and patented) way. I’d go so far as to say that Circle mode in MaBoShi is my favourite game concept of all time.

The same preview article I mentioned above also says “in terms of specs, (P/ECE) comes above the PocketStation and below the Game Boy” though I think that’s selling the P/ECE a little short. The CPU was quite fast and efficient for its time, and the fact that it had no specific graphics hardware meant that people had to get creative and optimise. Some of the results, seen below, would have been very tricky or impossible to achieve on the original Game Boy.

Over its short term of popularity the P/ECE platform had a vibrant homebrew scene and received ports or demakes of everything from Mitchell Corp’s masterpiece Polarium, through arcade gems like Flipull (aka Plotting), to console classics Panel de Pon (aka Tetris Attack) and more besides. It was home to proper Japanese RPGs and small arcade games and the number of games stretch into triple figures.

Selected Games by Kuniake Watanabe

Anyway! During his indie days, Kuni developed for a range of platforms and in a variety of languages and wrote several games for the P/ECE. Here are my favourites:

spout

A lunar lander style game where your thrust can destroy the scenery. Your task is to get as high as possible, though that is much easier said than done as the scenery becomes gradually more complex and time is always ticking away.

This is perhaps the most famous P/ECE game as it was released with source code for an SDL version and received ports to GP32 and related platforms. There’s a modern remake for iOS and Android by a different developer, though it keeps the same title.

edit: kuni’s game design notes

fencer

A snake type game where your head has momentum and your tail length depends on your speed, allowing fine and fluid movement. The goal is to avoid bombs and use your tail as a barrier that will destroy them. Chaining together multiple explosions is the key to high scores.

There was an official updated version for iOS, titled fencell, but it’s not longer on the App Store due to Apple removing all 32-bit games back in 2017. Yet the 20-year-old P/ECE version is still available for download. There’s a lesson for us all.

edit: kuni’s game design notes

interground

In this game you must use a rotating stick to push sand around in an attempt to bury the little people running on top of it. If the stick touches a moving enemy or you run out of time that means game over.

edit: kuni’s game design notes

Selected Games by Kenta Cho (ABA Games)

Whilst digging into P/ECE forgotten history, I also found several old games by Kenta Cho (then: Saba, now: ABA Games) who even today continues to crank out brilliant little games at an inspiring rate.

Barrage Reactor

A twin-stick shmup played with a d-pad and two buttons! The d-pad moves your ship around and the buttons rotate your aim as you fire automatically. Waves of enemies appear and a surprisingly tactical game ensues.

Speed Barricade

A 3D “Tron” light cycles game where the aim is to stay alive for as long as possible whilst outwitting an increasing number of computer controlled players. Quick reflexes are definitely needed for this one!

Re: W32/Badtrance

A 3D demake of Rez where the Microsoft Outlook(!) icon produces waves of enemies that need to be shot down as efficiently as possible by locking on to multiple enemies before firing your missiles. With the strap line “Gentlemen, open your Outlook. Go to Cyberterrorism.” maybe Kenta Cho was sick of email back in 2001?

If there’s enough interest I’ll feature more P/ECE games in a future blog post. Let me know on the comments link at the bottom of the page.

20 years later

Here we are in 2021 and Panic’s Playdate will soon be shipping. By now I’m sure you’ve spotted several similarities between the P/ECE and Playdate. The main one being that both devices offer immediate, unfettered access to developers wishing to make their own games, and those games can be side-loaded.

Of course, 20 years is a long time in technology so the Playdate has many improvements compared to what the P/ECE achieved in 2001. More storage, faster CPU, better connectivity, plus a bigger and better screen. Playdate offers cross-platform development using either C or Lua and, and you won’t need a device to develop for the platform. In contrast, P/ECE offered development only for Windows and only in C, plus you needed a device to test your code. A homebrew emulator was eventually released, which is what I’ve used for the screen recordings shown earlier.

Oh, and both devices have names that make web searches a bit tricky. 😅

Specifications Comparison

	Playdate	P/ECE
Manufacturer	Panic	Aquaplus
Release date	2021	2001
Battery (active)	8h	2h
Battery (standby)	2w	1w
Battery (type)	Rechargeable internal battery	1×AA
CPU (type)	STMicroelectronics STM32F746 (ARM Cortex-M7F)	EPSON S1C33209 (32-bit RISC)
CPU (speed)	180 MHz	24 Mhz
Storage (RAM)	16MB	256KB
Storage (Flash)	4GB (3.9GB usable)	512KB (348KB usable)
Device (colour)	Yellow	Silver
Device (dimensions)	76×74×9mm	101×65×17mm
Device (inputs)	D-pad, A, B, Menu, Sleep, Accelerometer, Crank	D-pad, A, B, Start, Select
Device (weight)	85g	92g
Data connection (wired)	USB-C to A	USB-B to A
Data connection (wireless)	Wi-Fi & Bluetooth	Infrared (IR)
Sound (type)	Software synthesis, Digital audio	Software synthesis
Sound (speaker)	Mono	Mono
Sound (headphone)	Stereo	Mono
Display (technology)	Sharp Memory LCD	FSTN LCD
Display (size)	59×35mm (2.7” diagonal)	45×31mm (2.15” diagonal)
Display (resolution)	400×240	128×88
Display (colours)	2 (1-bit)	4 (2-bit greyscale)
Display (rendering)	Software	Software
Software (bundled)	24	6
Software (SDK)	C & Lua	C
Launch price	$179 (¥19000)	¥11000 ($100)

Aquaplus P/ECE: Game Reviews Vol. 2

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.

Playdate 1-bit illustration postmortem

by Matt Sephton — Fri, 30 Jul 2021 00:00:00 +0000

Yesterday saw the opening of pre-orders for Playdate, a new handheld gaming device that I’m developing some games for. To celebrate the occasion I drew an illustration in 1-bit with dither patterns using Macintosh System 7.

This kind of style is most associated with HyperCard, which provides a bunch of great drawing tools and modes, and can be seen in many period pieces of interactive media, animations, art and video games.

I’ve been revisiting the artwork of Thoru Yamamoto recently, which I think influenced the style of this piece.

Toolbox

My tool of choice on System 7 is Deneba artWORKS because it supports multiple layers, a ton of external tools (plugins), and has a good workflow for vector and pixels. Plus, I use it on iPad Pro with Apple Pencil which makes the whole experience an absolute pleasure.

Some established Macintosh artists have questioned both my use of modern technology and my drawing techniques. Hopefully this post will give a little more insight into how I go about things.

Playdate

I first drew the body of the Playdate using Rounded Rectangles for the perimeter, screen, crank, d-pad, speaker grille and using Ovals for the buttons and corner screws. This was all done by eye, no measuring.

Afterwards I grouped all those shapes and used the Point Rotate external tool to rotate the group by an arbitrary amount until it looked like a fun enough jaunty angle.

Next, in the Layers Manager I set the shape layer to be greyed out and created a new layer to do some drawing. I used the Paintbrush tool with small circular brush to draw over the shapes by hand, erasing any mistakes and redrawing some sections of lines until I was happy.

Colouring

Given the nature of 1-bit there is no concept of colours only patterns of black and white to simulate different shades of grey. I could have drawn in colour and had the system convert to dither patterns, but I want to have manual control over the shades.

I first picked the dither pattern for the main “yellow” body and then picked the paler, more sparse, dither patterns for the steel crank handle, drop shadows and background. Fills were applied to closed areas using the Paint Can (flood fill) tool.

Details

I used the Paintbrush and Pencil tools to add in some details like the dots on the buttons and my hand-drawn version of the Playdate logo. The shadow was drawn freehand using the Paintbrush tool with a larger circular brush size. The background pattern is a simple sparse dither pattern applied using the Paint Can tool.

Party Up!

For pre-order day I thought it would be fun to add an extra layer to the illustration making it more celebratory. I had the idea to replicate the 🥳 emoji (Face with Party Horn and Party Hat) with the Playdate I’d already drawn.

Horn

This was drawn using a combination of freehand Brush tool and filled vector Polygons. Some extra shading is done using the Brush tool and a sparse dither pattern. I must have drawn a handful of different style horns, settling on the one that looked least like Playdate was smoking!

Hat

This was drawn as a vector path using the Polygon tool, and filled with a dithered pattern using the Gradient Fill tool. The frilly stuff on top of the hat is a handful of Arcs drawn in various directions, always starting from the tip.

Confetti

For the confetti I didn’t want to draw each one by hand, and I wanted them to be vectors rather than pixels so they remained as editable as possible. I found that drawing very short curved strokes using the Pressure Pen tool produced shapes that looked a lot like tiny squares of paper bent at some 3D angle. Using this tool without any pressure means it performs as a dynamic, vector calligraphic pen. A nice little trick!

Afterwards I applied one of the many standard fill patterns to each piece of confetti to give them a bit of individual flavour. Any confetti overlaying the Playdate body was duplicated, made white, and offset by a pixel or two to help make it stand out from the body. You can see this most clearly on the coil shape at the right side of the Playdate screen.

Jazz

The extra geometric shapes in amongst the confetti are my attempt at bringing a bit of 1980s Memphis Group design aesthetic to the illustration. I use a variety of different external tools for this: Spiral (length 2), Fractals (default wiggle and density), Coil and Resistor. The later two tools are meant for drawing electrical circuits! The moral of the story: know your tools and use them!

Positioning

After adding all the confetti and jazz, I adjusted the positions and sizes of many of the objects to produce what I thought was the most pleasing distribution. The benefits of all of these objects being vectors becomes clear at this point!

Motion

I used the Arc tool to add motion lines to the party horn and crank. Lastly I added some straight lines to imply that the light on the power button is flashing.

Pixel or Vector?

Looking at the objects that make up the drawing, I’d say that the split is around 75% vector to 25% pixel, which is the same across most of my drawings.

Pixels make up large freeform areas, filled vector shapes make up large defined areas. Small objects that will remain static use pixels, and those that I think will need to be moved or resized use vectors.

I tend to draw on the base layer with pixels and then use higher layers as rough groups for sets of vector shapes. For example, the confetti was all drawn on one layer.

Post-processing

I saved out the image as a GIF (another external tool provides this capability) and loaded it into DeBabelizer, or sometimes Photoshop 3.0. Here I resized using simple sampling to 990px square from the original size of 330px square.

Finally, I copied the file to BasiliskII emulator File Sharing drive at which point it became accessible in Files in iPadOS, and from here I sent it to my iPhone via AirDrop, after which I used the Twitter app to add the image to a tweet and hit send!

Job done.

Keyboard craving

I drew this late at night and was too lazy to go and find my Bluetooth keyboard. Next time I’ll definitely make the effort to find it. That way I can use my spare hand do keyboard shortcuts and to nudge positions using the cursor keys. I should really add cursor keys to the emulator’s custom keyboard.

Let me know your thoughts on Twitter using the comments link below.

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.

デイリードライバー

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.

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

Get Info: #playdate

Post-Playdate: One Year Later

Donating my Playdate earnings to The Cybersmile Foundation

Abandoned project: Band-kun/Beatnik for Playdate

The Idea

Challenge Accepted

Open Pitch: Band-kun

Season 2 Pitch: Beatnik

Go/no-go

Abandoned project: Soccer for Playdate

When Playdate Stopped Being Fun

Released Projects

Cancelled Projects

Notes

Old Codes, New Releases for Playdate

SHARK TURTLE

NEW WORLD

More games!

Bender 2: Bend Harder for Playdate

2012

2022

2023

2024

My other games for Playdate

Mouse Support for Playdate

How?

Why?

Installation

Demos

Notes

A year in the life of a Playdate game developer

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

A new edition for 2023

Extracting the original images

Implementing a viewer

Adjusting each screen

HyperCard look and feel

Chapters

Progress

Experiments with sound

Experiments with music

Optimising for size

The result

Credits

Further reading

Birthday blog post?

Dynamic music and sound techniques for video games

Dynamic BPM

Infinite Variations

Blending/Fading/Balance

Progressive Loops

Quantised Sounds

Further reading

Elsewhere

Easter egg emoji: converting pixels into particles

Pixels as code

Pixels as points

Pseudo-random?

Playdate particles

Further reading

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

Playdate?

But…why?

Reasons

Breakdown

Abandoned and removed features

Manual/Guide

Timeline

Credits

Further reading

Elsewhere

OpenSCAD to Sprite Sheet workflow

Post Processing

Benchmarks

Example Model

Example Output

The first colour Playdate game?

Abusing the system

Multi-colour?

Physical overlays