Woop
Controls:
- Arrow keys to move
- X to dash
- C to aim
- Get all computers online
Lore:
You were sent to isolation in a lab, and the only way out is with the computers. You need to connect to the internet so you can be safe. Good luck on your mission!
About:
This game was made for the micro-jam 53. I had a blast making it, and I hope you have fun playing the game. Good luck :)
I made my first game!
I will admit i dont have much knowledge in Pico 8. but its a alright game id say!
:D
GAME INSTRUCTIONS CUZ THE BUILT IN ONES DONT SAY ENOUGH
touch cloud = die
touch heart = win
find the heart at the BOTTOM RIGHT corner.
(fyi you start in the top left)
THE CLOUDS CAN SOMETIMES SPAWN BELOW PLAYER, JS RESTART :D
changelog
v1.0 - release
v1.1 - map boundary added, thanks to thePixelXb_ for finding that :D
v1.2 - outlines to clouds and heart sprites

This is a very rudimentary prototype for a virtual pet game. You can feed the pet by giving it apples.
The food bar decreases by 1 unit every real world minute and fully depletes in about 2.5 days. This should remain consistent even when the game is closed (this was the goal of the prototype).
I can't say if I'll work on this more, but I wanted to showcase it regardless.
Heavily inspired by PowerQuest, I wanted something similar in Picotron to help build point and click style games. The code is very ugly, but it works. It can currently parse two types of commands from a flat script.txt file: Dialog and Actions (walkToPoint).
It uses Lua patterns to match parts of the text on each line. I plan on adding more features such as:
- other action types (Pick up, Talk to, etc.)
- simple scripting
- inventory management
- ...etc?
The current issue: When a Player character moves to a position, it doesn't release the hold and they can't move from there until the next line. Will ponder ways to address this.
Any suggestions on code clean up / refactoring is welcome.

Hello!
Anna: Chromatic is a work-in-progress mini-Metroidvania with a colour-based combat system. Play solo with an AI companion or team up with a friend in local 2-player co-op for fast-paced, action-oriented gameplay.
The core mechanic revolves around colour matching: Player 1 (red) and Player 2 (blue) must work together to take down color-coded enemies. Blue enemies pursue the blue player on sight, while red enemies hunt down the red player. Your projectiles deal much more damage to opposite-coloured foes (encouraging tactical positioning and teamwork).
Navigate interconnected environments, unlock new items and areas, and master the combat system as you progress through this cooperative mini-Metroidvania.

crazy carz
by kevin zhang
crazy carz is an arcade-style racer where you are (for some reason) driving into oncoming traffic on the highway. avoid obstacles like cars, trucks, oil spills, and even some strange things like chickens and aliens. collect coins to increase your score
controls
arrow keys to move
Z to toot the horn
about
this is my first ever pico-8 game. i made it over the course of a weekend. there are some things i'd like to iron out further (e.g. collision detection, some additional features) but i'm going to leave that for another day. thanks for playing!

Hello! This is a work in progress game called Wizard Duel. I’m calling it a micro RTS autobattler with roguelite elements.
Micro because a full run takes less than 30 minutes.
RTS because you choose where to summon monsters and can kind of control how they move.
Autobattler because the monsters clash and do the fighting themselves.
Roguelite because every run can play out a little differently.
I wanted to make a game I’ve always wanted to play, and so far it’s turning out great.
Right now, getting past level 12 is basically a win. You can keep playing after that if you want, but you won’t get any more items.
Every 2 levels you get an item that can change up your playstyle. There are 7 items right now, and I’m planning to add more.
The game itself is pretty simple. You pick a wizard, summon monsters, and sometimes cast spells to beat an evil wizard who gets stronger as the game goes on.
There are currently 4 playable wizards, each with different summons.
I have a small programming background, but this is the first game I’ve ever made. It’s also my first time using Lua.
I’m still learning pixel art and I’m not amazing at it yet.
I’ve never made music before either, but I think it turned out okay for a first try.
I’d love feedback on anything, balance, bugs, or even tutorials or resources I could learn from.
There is a known bug around floor 16 where the dark wizard summons nonstop and wipes you out.
Right now I’m working on adding more items. Ideally I’d like to reach 20, but I might stop at 10 for now.
I also want to rework the AI to make it more challenging as the game goes on.
And maybe add more playable wizards too.

Version 0.6 Final
100% working game, this will not change unless someone posts a bug.
4300 tokens to play with.
Romans vs Barbarians if you want to use it.
I was experimenting with a hex-grid setup and ended up with this small prototype. It started as hex movement + range highlighting, and it’s now grown into a simple “tactics loop” with turns, teams, stages, and a basic AI.
This is still meant to be read slowly and edited. If there’s anything you’d like to see added or explored further, feel free to suggest it.
Tech stuff
Today I just started getting a consistent export failure that I haven’t been able to resolve. When I try to export from within PICO-8 I get “no output file”.
version 0.2.7
I've been using PICO-8 for about a year, and I've exported dozens of times with no issues. Even yesterday I was exporting successfully.
I'm on an HP laptop running both Windows 10 and Ubuntu. Export is failing on both operating systems. (Windows has no internet access.)
I tried fresh downloads on both systems.
This is happening not only with my current project, but with older carts that previously exported fine, and with empty carts.
I'm exporting to normal (not shared) directories that worked fine before.
PICO-8 is running normally otherwise. Only export is failing.
Additional context
Earlier today before this issue started, I accidentally created a runaway write operation in PICO-8 and had to terminate the process using kill. I don’t know whether this is related, but I wanted to mention it in case it could have left behind a corrupted state, or caused some other problem.

a thing I'm making to facilitate exporting the cart in ram to a folder for use with external tools, and importing back that folder into ram, ignoring non-pico files.
-
save: copies the contents of /ram/cart to a subfolder of /cartons using the title of your cart. can't do it without a title! saves the cart to the working location first, for safety! doesn't overwrite files you might have added by external tools, like a git repo maybe idk
- load: copies the content of the folder in /cartons/ that corresponds to the cart in ram. can't do it without a cart in ram with a corresponding carton folder. also saves the cart to its working location first... for safety!
pretty wip, use at your own risk, I barely just got this working. put it in your toolbar.... see if i care...
needs to run unsandboxed, this freak writes to /ram/cart
if you dare use this, I will eagerly await your inevitable bug report
- le pi

Stackarta
Burn the hand. Build the land.
A deck-building tower defense roguelike. Defend your core for 10 waves using cards that can be played as towers or burned to permanently buff the map.
How to Play
Each round you get a hand of cards. You must use every card before the wave begins. For each card, choose:
- Build -- Place it on the grid as a tower or trap. Towers block enemy paths and auto-fire. Traps don't block paths but apply effects when enemies walk over them.
- Burn -- Sacrifice the card to permanently buff a tile. Burned cards are removed from your deck forever, but the tile keeps its buffs. Any tower placed on a buffed tile inherits those buffs.
This is the core decision: a card used now as a tower, or burned to make a tile stronger for the rest of the run?
Controls
Title Screen
- Left/Right: Select difficulty
- Z or X: Start game
Planning Phase
- D-pad: Move cursor on grid
- Z: Build selected card (empty tile) or Sell tower (occupied tile, requires confirmation)
- X: Burn selected card onto any tile
- Down at bottom edge: Cycle through cards in hand
Wave Phase
- Z + X together: Pause/unpause
Reward Screen
- Left/Right: Browse cards
- Z or X: Pick a card to add to your deck
Cards
Towers (block enemy paths, auto-fire)
- Sentry -- Balanced all-rounder
- L-Shot -- Long range, high damage, slow fire rate
- Shorty -- Short range, fast fire rate, cheap
- Blaster -- Area damage to all enemies in range
- Rapid -- Very fast fire rate
Traps (don't block paths)
- Slower -- Halves enemy speed in the tile
- Spike -- Deals damage once, then disappears
Boosts (burn only, can't be placed)
- Ovrclk -- Burn for +2 damage on a tile
- Expand -- Burn for +2 range on a tile
Tile Buffs and Heat
Burning a tower or trap card onto a tile gives +1 damage. Burning a boost card gives its stated bonus.
Each burn increases a tile's heat. Every 3 heat adds +1 to the placement cost of building on that tile. Stacking buffs is powerful but expensive.
Waves
- Waves 1-4: Normal enemies, scouts join at wave 2, tanks at wave 4
- Wave 5: Elite wave (tough yellow diamonds)
- Waves 6-9: Swarm enemies join the mix
- Wave 10: Boss fight
After each wave, pick 1 of 3 reward cards to add to your deck:
- Waves 1-3: Common rewards
- Waves 4-6: Rare rewards
- Waves 7-9: Legendary rewards
Survive wave 10 to win, or continue into endless mode.
Tips
- Burn boost cards onto tiles where you plan to build your strongest towers
- Towers on buffed tiles are much stronger than unbuffed towers -- plan your layout early
- Traps don't block paths, so place slowers on enemy routes without disrupting pathing
- Selling a tower refunds 1 energy -- useful if you need to reposition
- Burning thins your deck, meaning you see your best cards more often

Hi everyone
I'm running pico8_dyn flawlessly on a Raspberry Pi 4 / Bookworm (lite). However, I now would like to access the GPIOs from within PICO8, so I would like to run pico8_gpio. I installed Wiring Pi as described under WiringPI on Github but when I try to start pico8_gpio from the commandline, I get
toddd@arcade5(10.0.1.140):~/.lexaloffle/pico-8/carts:$ pico8_gpio -run gpio_sender.p8 pico8_gpio: error while loading shared libraries: libbcm_host.so: cannot open shared object file: No such file or directory |
Does anyone know how to make pico8_gpio find libbcm_host.so or get rid of the error?
Thank you very much,
Dani
PS: I get the same error when I run pico8. Pico 8 only runs smoothly when I use pico8_dyn. Does that make sense?

Intro & Theory:
I’ve been experimenting with procedural animation in PICO-8, and I loved the results so much that I wanted to share some notes on how it works. This is part 1 of the tutorial, where I introduce some basic uses of Verlet physics to create more natural-looking movement. Part 2 (currently in the making) will use the concepts explained here to create a spider like the one shown below.
Disclaimer: I'm not a physicist. I just like the look/feel of procedural animation and was doing some research on the easiest way to create it. This tutorial is also a place for me to organize my thoughts and for me to use it as a reference in the future.
Verlet Integration: A Shift in Mindset
While Euler integration asks how fast should this point accelerate?, Verlet integration asks where was this point, and where is it now?
Figuring out the exact acceleration needed to satisfy complex constraints (like a stiff rope or a locked joint) is often mathematically heavy. Verlet makes it simpler: if we know where a point was and where it is now, we can calculate its implicit velocity and predict where it’s going.
Euler's method is the "standard" way of simulating physics. Given a particular point in space at time t, its velocity and its acceleration, we compute where it will be at time t+1. This method is intuitive, but can be computationally expensive and unstable. In complex systems, objects often "drift" apart or vibrate wildly when they should be held together by constraints.
Verlet integration has the same goal, but it goes about it differently, only requiring the current position, previous position, and acceleration. It then infers velocity by the displacement of the points to compute the next position. This makes it much more stable and computationally cheaper, which is why it's great for games. It also handles constraints with far less jitter.
The role of acceleration also changes between the two:
- In Euler’s method, we use acceleration for almost every movement.
- In Verlet, we primarily use acceleration to simulate external forces (like gravity or wind).
The beauty of Verlet comes from the simplicity of handling internal constraints like keeping a specific distance between a spider's hip and its knee: we don't bother with forces at all. We simply move the points directly to where they belong and the simulation takes care of the rest.
Euler Example:
euler_p = {
x = 50, y = 20,
vx = 0, vy = 0,
ax = 0, ay = 0
}
function update_euler(p)
-- update velocity
p.vx += p.ax
p.vy += p.ay
p.vx *= 0.99
p.vy *= 0.99
-- update position
p.x += p.vx
p.y += p.vy
-- reset acceleration
p.ax = 0
p.ay = 0.1
-- to simulate gravity
end |
Verlet Example:
verlet_p = {
x = 80, y = 20,
px = 80, py = 20, -- px/py = previous x/y
ax = 0, ay = 0
}
function update_verlet(p)
-- calculate velocity implicitly
local vx = p.x - p.px
local vy = p.y - p.py
-- update previous position to current
p.px = p.x
p.py = p.y
-- calculate new position
p.x += vx * 0.99 + p.ax
p.y += vy * 0.99 + p.ay
-- reset acceleration
p.ax = 0
p.ay = 0.1
-- to simulate gravity
end |
Hi everyone,
I'm in the middle of making the menu/options/controls for my game and I'm wondering what'd be the best approach for this.
I'm unsure what exactly is available, so I figured it'd be nice to gather some informations.
I peek()ed the addresses mentioned in the manual to design my own button()s and got a rebinding tool to assign jump to whatever button on my controller
Steam (among others) expect us to provide the appropriate icons and naming according to controllers standard layouts.
Can we rely on SDL scancodes at all times to assign the right physical button to the right memory address in Picotron ?
(I mean have 0xXXXXX linked to square from playstation, X from xbox, Y from switch)
If so I guess I should associate either the sprite icons or the "button names" to each address ?
I'm ok if we cannot detect the brand we can still ask the player to tell us, but is it somewhat possible as of now ?
I've read something about stat(29) to detect if the controller is plugged, anybody has experience making this work to give steam the expected "controller unplugged" info ?
On a side note, I've read there are some issues with xbox controllers. Is it still the case ?
My controller (a lovely gamesir tangerine) shoulder left and right were not recognized.
Btn() returns nothing.
But peeking the appropriate address prove I could use them if I mapped them properly.
So maybe there is nothing to worry about here ?
Keys are hard coded.
keyp() delay resets and seems to be mainly design for text input, and not for control mapping.
stat(28,scancode) is apparently a dev tool.
And I can't find specific poke addresses for each key.
Should we use the same addresses than btn() use for keyboard controls ?
And stick to z,x,c,v... for now ?
Are they going to be assignable at some point ?
Btw I mostly got rid of btnp() because I was having troubles with double tap (I mention it in case it should be reported as a bug) : tapping left twice while holding right would trigger dash and it was not a wanted behaviour.
Maybe I was doing something wrong but it must be because they cancel each other.
Not sure if I thought of everything, feel free to add anything you think could help in this process.
Thanks a lot,
Have a great weekend

Controls
controller HIGHLY recommended
arrow keys: move
z: jump
x: flip gravity
This is my entry to the CSULB VGDA 5-Day Jam, where the theme is outer space! In this game, you must escape the planet Terrastus, home to an ancient civilization, and manipulate gravity to complete precision platforming levels.
Credits
Daniel Lippold: art, programming, sound effects
Meinbrandon: playtesting, QA
v1.1 Changelog
tweaked physics to be less slippery
added buffer for jumping and flipping gravity
added corner spikes
completely reworked some levels that were either too difficult or not well designed
de-cheesed some levels
-only for levels where cheese was significantly easier, faster, and more obvious than intended route
fixed a bug where moving blocks weren't being launched by springs properly, adjusted several levels to work with new physics
tweaked some levels either to make intended route more clear/easier or remove some confusion
added more particles
added indicator for when the player can use their gravity flip
v1.2 Changelog
corner spikes weren't working properly, fixed the hitboxes
moved level 12's second crystal slightly, and gave wider gap to hit springs
added a secret, per my friend's request






8 comments

