Take on the role of humanitarian rebel Jehanne Butler in an all-out war against the intelligent machines that seek to mold and ennslave their organic creators! Armed only with a slow-charging Holtzman shield/displacement belt, use your wits to pit the robots against one another and defeat the machine-mind scourge!
Controls:
- arrows + z to move to an adjacent tile
- z to wait (and activate shield if in danger)
- x to displace to a random tile on the board
Instructions:
- Clear each board of robots by tricking them into colliding with one another or with the remains of already-destroyed machines.
- Watch your shield power! It's invaluable but scarce, and an emergency shield after teleporting will drain power more quickly than using it when standing still.

So a thing I distinctly remember from back in the day was games coming on multiple CDs. Usually adventure games, and the like.
Now, is this possible with Pico-8? My assumption was being able to have a "huge" map by splitting the areas on different carts, and having a "load screen" that asks you to change the cart.
I know it's possible to load other carts from within a cart and other funky stuff, but that's a liiittle different. I'd like it to feel a bit more physical than that, hence asking the player to load the next cartridge.
The problem therein, though, is that base ram is copied from cart rom whenever the editor is closed. Does that include the prompt? I'd love to try to test this out, but...uh, I really have no idea where to start.
Also, this'll probably be a neater trick to pull when the persistent save data is out.

This is my first cartridge, and basically my first game. It's based off some really old cribbage AI that I wrote years ago. Ported it over to pico-8 for fun.
It's a bit rushed and some of the logic is sloppy. Still missing a few rules and needs some cleanup on some of the timing but the core is there at least.
My goal was to try and make some AI that was difficult to beat.
I'm a web application developer by day.

Can anyone suggest some resources for a rank newcomer to game coding? I've got enough understanding from playing with c++ in college to understand most of the syntax when I read Pico-8 carts, but it's tough for me to understand what's going in in the more complex parts of the carts. Even jelpi is over my head.
I was hoping I'd learn how to do some basic game mechanics like collision detection, but I'm just going in circles here!

So, one of my carts is counting code in characters instead of tokens. I have no idea what I did to start that.
Here is the cart. I'm pretty stumped.

Can be combined with global palette to create objects that can only be seen in close promixity.
Somewhat bearable performance-wise.
Haxe source: https://gist.github.com/anonymous/c885964ca61431a8e90a
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.)

Because every console needs a (few) Pong port(s).
This is my first Pico-8 project. I've got a lot more ideas for it, and it's not done yet.
Future Plans
- Powerups if a match goes on long enough? Honestly, not sure if this needs it.
- Music
Known Issues
- The AI is occasionally too good at the game.
- Sometimes the ball goes too fast to catch.
Changelog
v4
- Goal sound.
- AI tweaks.
- Ball speedup changes.
v3 - Made the court pretty
- Added a score display
- Made the AI a little easier by making the ball go faster over time.
v2 - Updated the splash screen.
v1






14 comments










