this is a remake of Grid Game by Mark James: https://jayisgames.com/review/gridgame.php
when the pieces rotate and join up with each other they cause chain reactions - the aim is to cause the longest chain reaction and get the most points! you can also click pieces to rotate them (including while a chain reaction is happening - maybe this is overpowered?).
also it's the first thing i've ever made in pico8 since i only installed it yesterday, but i like it a lot. maybe i'll use it for the upcoming ludum dare?
Woo! 1.0!
I really appreciate all of the feedback you guys have given me.
- Use bombs to destroy inactive beacons
- A beacon that is currently being used as a checkpoint cannot be destroyed. To destroy the last beacon, you'll need to use the checkpoint inside the ship's cockpit, which will deactivate all beacons.
- The "double jump" for the game is actually just an upwards attack (with a power up). It can be used in conjunction with the roll to clear pretty good sized gaps.
- Once you get the dodge-roll, you can use it to overcome some fall damage if you roll as soon as you hit the ground (parkour!)
Hope you like it! Any and all feedback is always welcome.










Hiya! Took me a little while to figure out how to read from a GPIO pin on a PocketCHIP, so thought I'd put my example code here in case anybody else comes looking for the same thing I was. It's not actually very complicated, but maybe the code and the notes will save someone some time.
This example uses GPIO 6 - to use a different pin, just change the pin value accordingly e.g. GPIO 5 would be 0x5f86.
Pico-8 reads hardware pins as digital, so you're not going to get a value from them other than 0 or 255. In this example I've called these two values "on" and "off".
You might need to run Pico-8 as root by opening Terminal from the PocketCHIP home screen and typing "sudo pico8".
This example won't do anything in browser.
The Bug:
I've been noticing lately that the cursor in Pico-8's code editor sometimes will get "stuck." It will suddenly start moving continuously to either the start or end of the current line, and even if I try to move the cursor it will just move itself directly back. Holding down the arrow key opposing the direction it's moving in will make it stay in place, a character away from the start/end of the line. For whatever reason, this never makes the cursor change lines, so it doesn't appear to be something as simple as a single input getting repeated unnecessarily. It also affects the cursor command line.
The Cause:
This bug does not appear to have a consistent cause that I can identify, though I think it most often happens when I'm hitting multiple keys at once.
Solutions:
As far as I'm aware, the only way to restore normal functioning is to closing and re-opening Pico-8.
Have other people have encountered this? Does anyone know of any other solutions to this issue?
(I'm using 0.1.11D, but it happened with earlier versions too.)


Hello! This is a quick little Lunar Lander clone made in the week following the PICO-8 Workshop Series through the Portland Indie Game Squad. It's based on one of the prototypes made during the workshop.
Features:
-1024 unique levels spread across 2 modes (selectable from options, 512 levels per mode) -32 unlockable lander sprites (including some fun surprises) |
Controls for the unfamiliar:
Z key - (o) button
X key - (x) button
Enter - Options, etc.
Arrow Keys - Move
Enjoy!
bluesky: @rewrking
Mastodon: https://mastodon.gamedev.place/@rewrking



I was playing Zelda: Link's Awakening and was surprised to find that there were platform game levels in some of the dungeons.
So I started playing around with pixels to see what this would look like on the Pico-8 -

However, Nintendo isn't known to be friendly to such fan projects :(
BTW, here is the original Gameboy version for comparison -






I made a mistake in a method and wrapped an entire logical expression in a flr() statement instead of just the number. Instead of an error message the pico-8 would just hang when I tried to run it.
if (flr(self.bottomPaneX == 17)) del(objects,self) spawnWindow() |
Above causes pico-8 to hang when you try and run the cart below doesn't
if (flr(self.bottomPaneX) == 17) del(objects,self) spawnWindow() |
In a smaller scale test I found that it didn't hang running the following
cls() test = {} test.var = 0x42 if(flr(test.var==0x42)) print("reached") |
Here is the code which can reproduce the error.
objects = {} window = {} function round(fract) if fract-flr(fract)>=0.5 then return flr(fract)+1 end return flr(fract) end function _init( ... ) spawnWindow() end function spawnWindow() local obj = {} --dimensions for drawing. there are lots so that they can be slightly altered for spooky animations obj.topPaneX,obj.topPaneY,obj.topPaneW,obj.topPaneH = 51,27,25,11 obj.bottomPaneX,obj.bottomPaneY,obj.bottomPaneW,obj.bottomPaneH = 51,30,25,10 obj.frameX,obj.frameY,obj.frameW,obj.frameH = 51,27,25,21 obj.colour = 12 --the object state controls which animation the object is in obj.state = 2 --update method for the object obj.update = function(self) if(self.state==1) then if(self.bottomPaneY < 37) self.bottomPaneY += 0x0.8 elseif self.state == 2 then self.topPaneX -= 0x1 self.frameX += 0x1 self.bottomPaneX -= 0x0.4 self.bottomPaneW += 0x0.8 self.bottomPaneY -= 0x0.4 self.bottomPaneH += 0x0.4 --This is the fated line top breaks bottom doesn't if (flr(self.bottomPaneX == 17)) del(objects,self) spawnWindow() if (flr(self.bottomPaneX) == 17) del(objects,self) spawnWindow() end end --draw method for the object obj.draw = function(self) --remember to save tokens we only need to delcare colour when we are drawing with a different colour to the last thing drawn --draw the frame rect(self.frameX,self.frameY,self.frameX + self.frameW,self.frameY + self.frameH,self.colour) --draw the top pane rect(self.topPaneX,self.topPaneY,self.topPaneX + self.topPaneW,self.topPaneY + self.topPaneH) line(self.topPaneX + round(self.topPaneW /2),self.topPaneY,self.topPaneX + round(self.topPaneW /2),self.topPaneY + self.topPaneH) --draw the bottom pane rect(self.bottomPaneX,self.bottomPaneY,self.bottomPaneX + self.bottomPaneW,self.bottomPaneY + self.bottomPaneH) line(self.bottomPaneX + round(self.bottomPaneW /2),self.bottomPaneY,self.bottomPaneX + round(self.bottomPaneW /2),self.bottomPaneY + self.bottomPaneH) end window = obj --adds the object to relevant tables add(objects,obj) end function _update( ... ) -- body for o in all(objects) do o:update() end end function _draw( ... ) -- body for o in all(objects) do o:draw() end end |

I made this modification of GA TASU (https://www.lexaloffle.com/bbs/?pid=46485#p46485) with my Pocket Chip. It changes many of the sprites to resemble Galaga instead of Gaplus. I made this because I've always loved the graphics of Galaga for their recognizable, colorful designs, and the gameplay of Gaplus for it's complexity, so why not combine them?
I cannot seem to get the F7 screenshot key to work correctly, so it has a garbled label. Sorry about that, trust me, I tried every variation of pressing F7 (with alt and FN and such). I don't know how to fix it :( I tried modifying the .p8.png image to include a manually edited label that looks like it could be a screenshot of the game (accurate sprites & such) but none of my programs seem to be able to save it with the original resolution or color density (that was 30 minutes of sprite editing down the drain). I still wanted to post it so I could play it outside of my Pocket Chip and to have something to show for my two hours of editing, hense the WIP section while I try to figure out how to get the thing to take a screenshot. If you have any ideas please let me know!



I made this for a 48-hour game jam hosted by Worcester Polytechnic Institute's Game Development Club. The theme was either tarot cards in general, or to take three specific tarot cards and design the game off of them. I opted for the latter, and ended up making a boss rush shmup.
Due to time limitations I wasn't able to add sounds or music, and backgrounds are basically nonexistent, but aside from that the game is pretty much completely done.
Can you defy your fate?
CONTROLS:
- Left + Right: Move
- Z/C: Shoot
- X: Dash


Hey, everybody. In the Toy Train tutorial in PicoZine 1, the first function created looks like this:
function move_segment(s,dir) spd=dir*2 if(s[2]==8) --TOP SIDE then if(s[ 1]==112) --top RIGHT then s[2]+=spd else s[ 1]+=spd end ... |
And on like that. There must be something I don't get about function arguments/parameters, because the whole function hinges on the relationships between spd, dir, and s - but spd and dir are never defined...! Just what is going on here? It really flies in the face of everything I've learned about code to this point. Where the hell is it getting any type of value? Dir isn't even used again in this entire cart. I'm so confused.
I've looked at several function tutorials, but haven't seen this explained... At least not in a way I'm able to understand. Clearly I'm not the brightest or most informed, but jeez louise this confounded me. Because I don't know what exactly this behavior is called, I don't know what I can search for to learn more about this behavior.
If anyone wants to look at the cart/entire body of code, here's the link.


The base game engine is pretty much complete. Some of the things I plan to finish in the next week is:
- saving the level you got to and score
- having a scoring system
- pretty backgrounds, and particle effects. I'm definitely going to use fillp(). That sounds legit.
- animation for game over
- lives need pics
- the tileset changes themes. (there will be a cloud theme, hell/fire theme, and earth theme, and maybe a space theme, who knows)
- temporary power-ups (jump booster, run booster, extra life, countdown/don't have the screen chase you for a bit)
- tutorial level and being able to pick your level based on the highest one you've gotten to at the title screen.
Snowball Sunday is a remake of the c64 classic game Snowball Sunday by Ash & Dave released in 1988 on the Commodore 64.
This remake version has up to two human players and two computer players.
Instructions
Throw snowballs at each other and have fun. That's it
Controls
Player One/Two - Left/Right to move. Down Cursor to Duck and Collect snow. Z, C, or N to throw snowball.
Player One/Two - Left/Right to move. Down Cursor to Duck and Collect snow. left Shift or Tab to throw snowball.
Credits
Original Programming, Graphics and Idea by Ash & Dave
Changes
Sounds - Done 0.1b
Scores - Done 0.1b
Any more comments/suggestions before I submit this as finished?




Picotool is a library and toolset for manipulating Pico-8 cart data, useful for build workflows, as well as cart generation and transformation experiments. Many Pico-8 devs use it for its code minification feature (p8tool luamin), which can be handy when your game's code is near the uncompressed character limit.
A more recent feature is "p8tool build", a tool to assemble carts from multiple files. This tool takes a cart and replaces a type of its data from another file. For example, you can copy the spritesheet from another cart like so, such as to collaborate with an artist working in a separate cart file:
% p8tool build mygame.p8.png --gfx sprites.p8.png |
You can pull in Lua code from a .lua file with the --lua argument:
% p8tool build mygame.p8.png --lua mygame.lua |
When you use --lua, you get an especially powerful feature: build-time support for Lua's require() statement. The main .lua file can call require() to include code from additional .lua files, such as reusable libraries. It supports several features of the official Lua require() statement, such as only including a module once, and module return values.
You can get Picotool from its Github repo, as well as file bug reports, here:


I noticed Pico-8 was missing one thing that isn't too major, but would be nice to have: a way to copy SFX between carts. Yes you can export the music as .wav files, but there is no way to import. I am quietly hoping that zep adds a way to import the .wav files or some format so that we can copy sfx between carts, but until we have that, here is a simple script that will accomplish just that. It just copies all the sfx from one cart and pastes it into another, not allowing for specific tracks yet (Though I may add that later to a separate script). All you have to is type
python sfxCopy.py <inputFile> <outputFile> |
and it will quickly copy the sfx from the input file to the output file. Link to the script on Github Gist is here. It is licensed under the CC 3.0 license, so do with it whatever you want. Happy coding!

