I was thinking, what if there was an underpowered handheld spinoff console from the makers of the PICO 8? Sure, it's not as beefy as the original console, but oh the portability!
So this is a really rough prototype: I've built up the PICO JR console as the core game loop of the cartridge, processing input into thumb movement and some really sketchily modeled instinctive controller swerving, with the bulk of the code stuck down below and the actual code for the little in-game game up top in the cart.
My gut take on the specs for this:
- 48*48 pixel four-tone greyscale graphics (so, colors 0, 5, 6, and 7 in the PICO 8 palette)
- 2 channel sound
- dpad and one button (other button could be reserved for meta-game/menu stuff)
- 1 page of sprite sheet
- standard sprite size of 6x6 pixels
- dodgy slow-refresh LCD screen (could simulate this by checking screen buffer every frame and only allowing pixels to move one shade of grey toward whatever the target is)
Right now the tiny little Jump Guy game is just implemented for the screen and palette and sound limitations by me keeping myself honest, but I think the right way to go to do this right would be to write wrapper functions for all the standard PICO 8 calls that do appropriate constraining and sanity checks on the PICO JR specs. (So e.g. pj_sfx() and pj_music() would only accept as valid channels 0 and 1, spr() would only read off the allowed sprite page and would count by 6*6 blocks, etc.)
Among various thoughts: the current implementation of handheld bob-and-weave is really naive, and I'd like to more accurately model the way that it tends to vary with actual game intensity by e.g. tracking the level of button activity over the last few seconds and use that as a multiplier/threshold for really jerking the thing around rather than the occasional mild nudge. If you're really hammering on the buttons, that's when you're probably most into it and most vulnerable to sympathetic movements of the device itself as you lean into the game.
now you need to implement the pico-jr's coding engine
I only heard this from a friend of a cousin of a friend, but it sounds plausible: the PICO JR dev kit was actually just literally the extant PICO 8 devkit, but with an alternate API that reimplemented many of the standard functions to scale them appropriately to the reduced hardware capabilities of the portable system.
Bug report!
Will fix! (Jump Guy was notoriously rushed to market for the 198X holiday season, which given the enormous pre-release hype certainly didn't help sales momentum after the initial rush.)
Josh Millard, you just gameceptioned the entire world.
just a quick note to link this thread to LRP's extension of Pico Jr, "wrapper functions for all the standard PICO 8 calls that do appropriate constraining and sanity checks on the PICO JR specs.":
Pico Junior Devkit
[Please log in to post a comment]
