Show HN: Driftmania – an open source PICO-8 racing game (frenchie14.itch.io)
I've been spending a lot of my spare time over the last year creating this little racing game. It's built in PICO-8, which is a really fun “fantasy retro console” that's been mentioned on HN several times. The console has strict limits and I wanted to see how far I could push them
The source code for the game is over here: https://github.com/maxbize/PICO-8/tree/master/Driftmania. It's a bit of a mess, but I'm happy to answer any questions on it or development of the game. Cheers!
EDIT: For those not familiar with PICO-8, there's only a few inputs: arrow keys, Z/C/N, and X/V/M
70 comments
[ 4.5 ms ] story [ 157 ms ] threadFor those not familiar with PICO-8:
> PICO-8 is a virtual machine and game engine created by Lexaloffle Games. It is a fantasy video game console[1] that mimics the limited graphical and sound capabilities of 8-bit systems of the 1980s to encourage creativity and ingenuity in producing games without being overwhelmed with the many possibilities of modern tools and machines."[1]
[1] https://en.wikipedia.org/wiki/PICO-8
As for the game, it's satisfying to ratchet down to the 39 second threshold for the gold medal by figuring our drifting. I realize I was overdrifting and easily beat 39 seconds once I stopped drifting much sooner along the turn.
I usually just hit the "i" button to enter insert mode.
Does that one work better with vimium?
I just figure HN is the only place where someone might commiserate with me for the self-inflicted pain of using a half-baked Vim keybinding plugin for the browser.
It's nice to have the BBS link so I could star it though. :)
https://github.com/kitao/pyxel
TIC-80 is probably the closest open source thing to PICO-8. The browser builds ran 10% slower than the desktop app last I tried. It doesn't have a "CPU budget," so it's possible to write inefficient code that works fine on powerful machines but not slower ones.
https://gondolaprime.pw/games/starfield/index.html
Developer console shows approx ~7MB transferred. Still more than I would have expected for literally just a small looping animation but a bit better than 30MB at least.
Maybe there's been some progress on this front.
Thanks for the TIC-80 recommendation - I really like that it supports multiple langs (Lua, JS, Python, etc) - that's some great flexibility.
EDIT: It looks like TIC-80 games pull a tic80.wasm file which is approximately ~6MB in size. I'd say Pyxel and TIC-80 are roughly comparable at least with respect to bundle size.
https://tic80.com/js/1.1.2837/tic80.wasm
Bytes transferred over the wire don't equal actual file size (due to gzipping, etc). Your page actually weighs 21MB.
EDIT: Just to be clear since I can't edit the older comment - instead of bundle size it would have been better to say that the "network transfer size" is roughly comparable.
I find it way easier/faster than using the built-in IDE for the code part itself. Then just use the built-in IDE for assets/music.
https://powkiddy.com/products/pre-sale-powkiddy-rgb30-rk3566...
Non affiliated with the company, I get nothing from saying this, it's just a decent device all around. The 1:1 aspect ratio on the screen really does PICO-8 games justice, along with MAME and other popular platforms. The greatest thing is these devices are super cheap and easy to come by if you're patient.
Here's a video review of it by a youtuber whose opinion I've come to respect https://www.youtube.com/watch?v=LIMepWAzUuw
To be clear, I'm ultimately glad I bought it, and it's germane to this discussion that the release of the RGB30 is what got me interested in PICO-8 in the first place (I had apparently purchased a license years ago as part of the Bundle for Racial Justice and Equality on itch.io and didn't even realize it until late last year). Also, the 720p 1:1 display is one of those developments that in retrospect feels so perfect for this form factor it ought to have been obvious, but it was a weird move at the time and they deserve full credit for taking the risk.
Having said that, I want to love this thing, but I just can't. Mainly because the D-pad sucks. It's not unusable, but it's worse than my Miyoo Mini and Anbernic devices, worse by a mile than my 8BitDo controllers, worse still than my Hori Fighting Commander, worse than even my Steam Decks (which have sort of weird D-pads themselves)... you get the point. It's annoying that the device on which I would prefer to play 8 & 16 bit games at a 1:1/8:7 resolution has—out of everything I own—by far the worst controller for exactly those games.
The ergonomics also leave a bit to be desired. Again, like the D-pad, it's not so uncomfortable as to be unusable, though I much prefer pairing it with a 3D printed grip I bought from ComfortGrips on Etsy¹. That obviously makes it a much less pocketable device, which isn't a big deal for me, but might be for others.
Finally, I hesitate to critique the software experience, because on the whole I'm incredibly impressed with how much improvement I've seen (both in terms of quality and frequency of updates) to JELOS in the nearly five months I've owned the RGB30. But the fact remains that that confusing preference conflicts, occasional crashes, frequent sleep/wake flakiness, ridiculously bad battery drain when asleep or even fully powered off (which thankfully has been cleaned up in recent updates)... they're all just facts of life with the RGB30. It was honestly kind of shocking coming from OnionOS on the Miyoo Mini which is absolutely rock solid in comparison. But that's obviously a less powerful device with a completely different form factor.
Anyway, as lagniappe correctly pointed out, PowKiddy makes budget devices, which means they're generally inexpensive enough to take a flyer on despite their limitations, and the RGB30 is arguably the best thing they've ever made.
1. <https://www.etsy.com/listing/1602072205/powkiddy-rgb30-comfo...>
==========
A good PICO-8 handheld has one absolutely mandatory quality, it must be able to run PICO-8. That may seem ridiculously obvious, but it's important to note that there is no Android port of PICO-8, and therefore most Retroid, AYN, and AYANEO offerings, as well as many Anbernic devices (as well as any other Android-based retro handhelds) can't run PICO-8 natively. While emulation is technically possible, it's incredibly complicated and only barely works³. (Sidenote: other than the RGB30, the only 1:1 720p retro handheld in development that I'm aware of is the ZPG A1 Unicorn⁴. Regrettably, it will run Android, which is a huge bummer.) This issue is even more pronounced on FPGA-based devices like the Analogue Pocket. The Pocket's 1600x1440 screen is nearly perfect for 1:1 content, but PICO-8 obviously doesn't have any native hardware to be emulated (or whatever terminology you prefer to use, I don't want to get drawn into the FPGA holy wars). Theoretically someone could develop a powerful enough x86 Pocket core to run an OS that you could maybe run the PICO-8 runtime and its Lua interpreter inside... but that's so convoluted it hardly merits discussion.
In short, you need a Linux-based handheld, which is a good start, because there are lots of them, and plenty of custom OSs/frontends under development like EmuELEC, ArkOS, JELOS, MinUI, OnionOS/GarlicOS etc. Only some of these will run the PICO-8 binary natively, but as is the case with so many retro handheld topics, Retro Game Corps has a guide that can be useful for sorting out the specific details for each device and OS⁵.
Next, it would stand to reason that for the best PICO-8 experience you'd want a handheld with a square-ish display. However, I'd argue that aspect ratio doesn't actually matter very much, and what you're really looking for is something with enough vertical pixels to get you clean integer scaling of the PICO-8's native 128x128 output with minimal black bars at the top and bottom of the screen. The black bars on the left and right don't matter very much, in my opinion. Shaun Inman's Console to Screen tool⁶ is very useful for visualizing these details. Using that tool, if you set the console to PICO-8, enable integer scaling, and select any of the devices with a 640x480 resolution, you'll see that the top and bottom black bars are mostly responsible for the PICO-8's square output looking like a postage stamp when it isn't utilizing enough of the screen. In contrast, devices like the RGB30 and Steam Deck can reach 5x and 6x integer scaling respectively, while sacrificing very few vertical pixels. Impressively (and somewhat inexplicably), the Anbernic RG552 features a 1920x1152 IPS display, which accommodates 9x integer scaling without a single wasted vertical pixel, but that was an expensive device with some serious warts when it came out over two years ago. Its price-to-performance ratio was bad then, and it's even more difficult to recommend in 2024. Having said that, Russ from Retro Game Corps loves it⁷, and I could imagine the RG552 filling a very specific role for someone who owns several gami...
In comparison, Anbernic and Retroid sell devices with better build quality and slightly better QC.
[1]: https://yewtu.be/watch?v=axsaC04jc98
[2]: https://littlelimit.net/bad_apple_2_5.htm
Do others expect the car be lined up to go right?
Is this a cultural expectation? I come from a LtR writing culture so I was wondering if others were surprised at the car going left at the start.
Will definitely check this out..
https://twitter.com/MaxBize
I have been looking for some sort of project to help pass the days and scratch my just build something dummy!-itch that had developed now that no one will hire me and I can work on anything that floats my boat.
This looks just perfect as far as 1] how cool the final output is 2] how complex the code is and 3] potential access to the original dev (well, we will see won't we? lol).
I already have a couple of ideas for some PICO-8 level games so I'm really excited about getting started...thank you very much for posting this!
I’ve been prototyping an f-zero type game and so far have:
- pressing forward increases thrust
- thrust makes vehicle accelerate forward
- friction is higher for the component of velocity perpendicular to tires
- vehicle turns faster when it is moving faster (I don’t actually simulate tire direction)
- as a hack to make it feel a bit like drifting, make the vehicle visually turn more than it is actually turning
Any simple thing I should add?
- Wheel modifiers (which wheels are on road, grass, boost tiles, etc)
- Control loss when airborne
- Slow turning when at low speed (a bit different from yours since the impact drops to zero very quickly)
- Speed / accel penalty when hitting a wall
- Visually rotating the car (this is what happens when a player presses the turn key but the actual velocity rotation is handled separately)
- Boost handling
- Nudge the car to the side a little if it's trying to turn but is blocked by a wall
- Acceleration, friction, breaking, and drift-breaking
- Corrective side force (basically an extra friction perpendicular to velocity like you have)
- Artificial speed limit (alternatively, you can include a drag component which applies a force proportional to the square of speed, but I've found it hard to get this feeling good in the past)
- Velocity rotation to align velocity direction and visual direction. This is a minor effect - it's mostly handled by the other physics
- Gravity
- Out of bounds checks
I think you've got the main pieces already. What's more important is understanding what you want your game to feel like and continuously tweaking until you get there
[1] https://github.com/maxbize/PICO-8/blob/master/Driftmania/dri...