Get Info: #dailydriver

DREAM RIDE for Sega Dreamcast (and emulators)

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

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

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

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

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

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

Download

gingerbeardman.itch.io/dream-ride

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

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

Video

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

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.

Daily Driver: Club GTi

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

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

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

Daily Driver: Teaser Artwork

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

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

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

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

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

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

Daily Driver: How big is a sprite sheet?

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

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

Code changes

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

Rendering changes

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

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

How high?

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

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

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

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

Selected results

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

Stats

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

Charts

Implications

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

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

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

Rendering time
File size
Memory usage
Performance in-game

Rendering time

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

File size

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

Memory usage

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

Performance in-game

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

Final choice?

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

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

Daily Driver: To GIF and Back

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

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

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

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

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

Problem

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

Thinking

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

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

Solution

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

Convert image table to Animated GIF

Convert Animated GIF to image table

Daily Driver: Teaser Trailer

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

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

Daily Driver: Channelling RGB into 1-bit

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

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

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

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

Channels

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

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

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

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

Overall, I did a few more tricks:

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

And the process worked a treat!

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

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

Elsewhere

2021-06-06—Hacker News

Daily Driver: Pseudo-HDR

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

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

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

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

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

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

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

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

Daily Driver: Makefile

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

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

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

rendering
stitching
post-processing
copying
cleaning

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

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

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

Daily Driver: Pre-rendering Ranger

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

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

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

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

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

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

Result!

Daily Driver: Happy New Year!

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

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

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

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

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

デイリードライバー

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