I've been hitting the PICO8 website for years now but just recently I noticed that the "Forum" link in the PICO8 site menu takes you to the Cartridges/Releases sub-forum and NOT the main forum...and that's not good.
Shouldn't the main menu link take you to the forum landing page?
I've just assumed that clicking the main menu link takes me to the starting point and I drill down from there...not that it has done some drilling for me already.
Now that I've paid attention to this, I'm seeing A TON of threads I never saw before that I'm interested in. One challenge forums have is duplicate and buried posts but if the site makes it hard to see all posts in the first place, it doesn't help.
This is the forum start page: https://www.lexaloffle.com/bbs/?cat=7
This is the where the "Forum" main menu link goes: https://www.lexaloffle.com/bbs/?cat=7#sub=2

This might be too broad of a question...but how do you create and manage timelines for actors in your game?
A lot of my games involve waves of enemies coming onto the screen, a la shmups and runners. I've made several games at this point that need these types of timelines but I feel like I have to create a new system each game. I haven't come up with a method/process/flow that I feel is reusable and that bothers me :)
A common pattern I use is a delimited string that gets parsed into an array that outlines which actors should appear and when based on timing (spawn after X seconds). It works okay but that giant string often requires external tools to create and often ends being very specific for the game - which isn't bad per se, just clunky.
I guess I don't have a problem to solve here...just looking for insight as to how others handle it or have dealt with it in their own games.

I've found that even with my small collection of gamepad/controllers being hooked up to various devices, that the default mappings on gamepads differ widely. It made it hard to me to know which button to label as which in my games.
So if you just plug in your gamepad and boot up PICO8, which buttons map to which keys?
Naturally, it's gonna vary but based on my own controllers and a very unscientific survey on Twitter, I've come to accept that the B button on a gamepad maps to Z on keyboard, and A button maps to X on keyboard.
Like so:
Obviously, you can remap the buttons and all that jazz but out of the box, this seems to be the common config. This is how my Buffalo gamepad is when plugged into my Windows machine...and gotta say, it makes sense. The B button is left of the A button, just like the Z key is left of the X key on my keyboard.
What have you found with your various controllers and gamepads? Maybe this thread can serve as an index of controllers and how they map to PICO8 by default. Just make sure to outline the brand of controller and the device you're using it with.
I'm working on a bullet pattern function that shoots out bullets in a direction, at a speed, etc...nothing fancy and nothing new to me, all my games have bullets! BUT this time some bullets are magically moving mid-stream and I can't figure out why.
See here...
I've narrowed it down to happening when bullets from the line ahead of it get deleted from the table. When a bullet goes off screen, I'm removing it from the table so as to not get overloaded and so on. Normal stuff. But when that deletion happens, the next bullet in the table magically moves out of line yet all the rest follow orders.
If there are 15 bullets in every line, why would the 16th bullet move when the ones ahead of it get deleted? Is it something to do with table order? Or some process not happening due to deletion time?
It's like the addition math gets skipped at that moment. Very weird...but also something I'm sure that is very simple I'm overlooking. Lord knows I've spent way too much time on whittling this down the simplest version and I'm not sure how to refactor any more. A man can only bang his head so much :)
Any thoughts, insights, or suggestions are appreciated.
Code for the example above.
function add_bullet(x,y,a,s)
local dx=cos(a)*s
local dy=sin(a)*s
add(bullets,{x=x,y=y,dx=dx,dy=dy})
end
function bullet_update()
for k,o in pairs(bullets) do
o.x+=o.dx
o.y+=o.dy
if o.x>130 or o.x<-5 or o.y>130 or o.y<-60 then del(bullets,o) end
end
end
function bullet_draw()
for k,o in pairs(bullets) do
rectfill(o.x,o.y,o.x+1,o.y+1,8)
end
end
function _init()
fr=0
bullets={}
end
function _update60()
bullet_update()
fr+=1
if fr==50 then -- this is here to repeating demo only
for i=1,15 do
add_bullet(120,10+3*i,.5,1)
end
fr=0
end
end
function _draw()
cls()
bullet_draw()
end |

There's been a lot of drama recently surrounding PICO-8 games being turned into NFTs and then being sold on the GameStop NFT market...all without permission from the creators. One of my games got caught up in the mix and it's a shitty scenario across the board.
Ars Technica published a feature this morning highlighting the whole ordeal. It's a good overview of the drama with interviews from @zep and other creators that had their games hijacked. Worth a read for everyone that makes games here and something to keep an eye out for in the future.
Zep has been working hard deal with a lot of it and helping to get them off the GameStop market. Huge thanks to him for all his effort on this situation. It's not fun for anyone but he's certainly taken a lead role.
I've helped out where I could in regards to dealing with this problem but I chose not to get too involved otherwise. It's shitty that someone took my work and cashed in on it, but at the end of the day it's not taking any bread off of my table. I'm not going after legal action or anything that hardcore so I'm squarely on the "it's the principle of the thing" side of the coin.
This is not a thing and it will continue to be a thing, I'm guessing. Someone has proven you can turn our games into NFTs and cash in. Expect more and keep your eyes out.
Play above, search Splore for "helitack" or use LOAD #HELITACK from your PICO-8 commandline.
Only you can help...
Budgets are tight and staff is short so we're looking for volunteers to help keep our parks safe and beautiful.
Your job is to partol the park and rescue lost hikers and contain any forest fires that might get started. If you can keep things under control for 3 shifts, you can become a full-time helitack ranger.
Your helicopter is equipped with all the gear you need to get the job done. Stay focused, stay calm, and do your best.
We also recommend reading the handbook. It might just save a life.


Does anyone have an example of a horizontal directional compass in a game?
The type of compass that is just a strip and moves left/right as the character rotates on screen? So like facing .25 in rotation would be North and so on from there. I don't need waypoints indicated, just have the direction be in the middle when the character is facing that direction.
Example:
I'm working to figure it out as we speak but this time I remembered to poll the community before I do a bunch of work, lol.
I think my struggle is how to turn the rotation of the character in speed for the horizontal compass and so the compass letters line up when a cardinal direction is hit.
Any ideas to approach or pointers, tips, examples are appreciated.

I put a completely unscientific research poll up on Twitter asking folks where they usually play PICO-8 games and the majority said they primarily play using the desktop client.
- Desktop App: 56.7%
- Desktop web browser: 23.3%
- Phone web browser: 16.7%
- Handheld App (non-phone): 3.3%
I put up the poll because PICO-8 is in a unique spot where it can be played various ways on various platforms, and yet we're not able to design games to account for one or the other. This has always been a point of ponder for me and having this data helps me think about it better.
However, the audience that saw my tweet is probably regular PICO-8 players and devs anyway, so it's not the casual gaming public that most certainly plays through the web on Itch.io and whatnot. But, still interesting to see the results.
What does this tell us? I mean, not much, I guess, but to me it says the laptop/desktop is the device (and environment) where we're mostly playing. It's not on your phone or on a handheld like the RG351. It also means Splore is likely a primary source of access/finding of games. We might also be able to infer that the game is being seen on a rather larger display, not phone or handheld sized...so worry about sprites being "too small" could be less so.

I'm trying go back into my game Destructopillar to try add/remove some things but see I am at token limit. I've done some basic refactoring and stripping out unneeded functions that are now part of the core but it's not enough.
I was looking over the manual to see what functions are available now and was reminded about coroutines. The problem is, I never really understood how to apply coroutines. I get the concept and I think I understand the gains (like saving tokens), but just can't figure out where in the game it would benefit from coroutines, if at all.
Please check out the Destructopillar game below real quick, even just the first stage and you'll get the gist. Then please call out the places where you could see coroutines being useful.
I'm not looking for cart code analysis or digging into what's there right now. Just looking at the game on the surface...the actors, the actions, the scenes...would coroutines possibly make sense anywhere?
And the answer could really be they wouldn't help in this type of game. And that's okay...because I just don't know. I sense that coroutines could help and make things better and save me some token trouble but maybe not.
The Agony and Ecstasy of the PocketCHIP
I arrived at PICO-8 because I bought a PocketCHIP back in 2016. The PocketCHIP came pre-loaded with PICO-8 and prior I had no concept of a "fantasy" console, but I was excited to make games again. Unfortunately, the PocketCHIP was a beautiful-yet-awful piece of hardware.
Essentially, the PocketCHIP was a Raspberry Pi-like mini computer wrapped in a case with a touchscreen and keyboard. On the surface, the PocketCHIP was a pretty raw looking piece of hardware...but I dug the style and was excited when it arrived. Yet I quickly found out that the experience of the PocketCHIP was something to be desired.
All bark and no bite
The keyboard was awful and despite coming with PICO-8 -- a game hub -- playing games was very unsatisfying. I needed a new bezel with a built in d-pad just to make playing games tolerable. I even had to put nail polish on keys to know what did what. In short, it was not fun to play on. But it did lead me to PICO-8 and for that I'm thankful.
TLDR: This is a game that I started years ago and didn't finish. I went back to it on a whim and got it playable. You can download it. But really this is a story about returning to game design and PICO-8 and the joy it brought.
Don't call it comeback
Hello. I'm Brian aka @morningtoast. I jumped on the PICO-8 bandwagon back in 2016 and made a handful of games. For those that remember and played my games, thank you! For everyone else, please check out my old carts - they're still fun. But after a few years of pumping out games, I got a little burned out. I ran out of creative juice, got frustrated, and just had other things to do so I left the gamedev scene.
Scoot ahead a few years and I get an alert that someone commented on an old cart post here in the forum. It felt great seeing someone had played (and enjoyed) an old game. It reminded me a) why I make things, and b) games live beyond their release date...it's all about who finds them.
But that was enough for me to crack open my PICO-8 folder and revisit some of old work. What I found was a treasure trove of unfinished games, a few of which were honestly near-complete that I just never pushed across the finish line. Not sure why...but I decided to try and make one of them at least playable and release as a "lost cart" or something like that.

I'm really struggling with this one...I'm trying to vertical scroll a map (shooter style) and wall tiles in that map collide with the player stop them BUT ALSO push the player down if appropriate.
I got the mget() and fget() stuff kinda of working as I'd hoped but detection seems wishy washy.
I have code for map collisions that works well when the map isn't scrolling, and I tried to translate that over but with the map moving, it didn't work well at all. Especially when it comes to pushing the player down off screen if they are blocked by a wall tile.
I'm hoping someone might have made a cart that uses this type of technique or a snippet that I can reference.
My fallback (as always) is just using a bunch of objects and move them individually (to get the scrolling) but I'm trying not to do that so a) I learn something, and b) because moving a bunch of objects in sync never works and always looks choppy.
Any thoughts, examples, or similar shared stories is appreciated.

This is a late entry for the Tweet Tweet Jam from last week. I know, I know...but hey, I had a marathon of meetings at work so I made good use of the time.
Nonetheless, here it is. A simple little game inspired by the Tank & Plane LCD game I had as kid. Try to get the people from one side into the house while avoiding the Evil Cat Lord's love. But mind the gate, it blocks you until it goes down. See how many people you can save before you're hit (or get stuck).
Believe it or not, this is my first tweetcart (or close to it). I see the tweetcarts fly by on Twitter all day long but never really bothered to try one myself. I guess all the "art" carts aren't really my jam and I find myself at a loss when it comes to the math and magic behind making them.

I'm sort of at a loss right now on trying to get my snake to not be so wiggly when it's drawn. You can see the red head of the snake is fine...and nice clean draw no matter which way it's heading.
Press Z to add a segment and you'll see that each following segment is very wiggly when its draw, not clean at all...and I don't know why.
I don't know if it's just the way it's gonna be or if I'm drawing things wrong or just doing my calculations wrong for where segments are positioned. Or a little bit of everything wrong.
Any help, insight or suggestions are appreciated.

I'm wanting to make a big play area in my game with several cities in it. I made a sprite map of the city (see below) and I want to draw that map in several places. This is working great using map() drawing several times but when you make a change to a map using mset(), it changes it in every location that map is drawn...and that makes sense.
Sooo...is there a way to have a map, duplicate that map, and draw it to be treated as a separate entity/instance in conjunction with mset()
City A, City B, and City C all use the same sprite map but when I use mset() on City A, I don't want it to change B or C.
I'm probably complicating things way more than I need, but I thought using map() + mset() would be better/faster/efficient than managing an object and draw for each building in the city.


In order to save on some tokens, I put configuration number values into a string and then parsed that string. I then tried to use one of the values as a table key and it barfed on me.
Turns out, even though math functions recognize a string number as a number, using it as a table key will fail. You need to convert that string number into a integer for it work as a table key. My solution was to just add zero to number and it turned out okay.
t={"apple","orange","line"}
a="1"
printh(a+10) -- good, returns 11 (integer)
printh(t[a]) -- bad, returns FALSE
a+=0
printh(t[a]) -- good, returns "apple" as expected |
All in all, it makes sense but I had never come across this before somehow. But seems kind of weird that Lua will let you be lazy with numbers for math but not for other things.

It's been a while since I've made a game so I'm running into questions I probably had answers previously...my apologies if this is a rerun.
I typically use a table for each type of object - enemies, bullets, powerups, etc. - and then loop over each table checking to see if the collide or whatever. Something like...
for bk,b in pairs(bullets) do
for ek,e in pairs(enemies) do
if collide(e,b) then ...do something... end
end
end
|
And then there could be several of these depending on which objects interact with each other.
But I've also seen where you use one table for all objects and then check object types to see if they should interact.
for bk,b in pairs(bigtable) do
for ek,e in pairs(bigtable) do
if e.type==1 and b.type==2 then
...do something...
end
if e.type==3 and b.type==4 then
...do something...
end
end
end
|
I'm trying to get P8 to run in a window on my Linux Windows install on my Raspberry Pi, so I can have it and my editor up on the same desktop (like I do in real Windows). But by default, P8 runs fullscreen. I've tried launching it from terminal with the flags outlined in the docs and even by editing the config file, but none of that is working, it's still going fullscreen.
Anyone else tried to run it windowed on Linux (RPi)? ..and got it working? Or is all that windowed stuff for "real" Windows only.

Sorry for the vague subject line...I don't know how to best describe what I'm seeing. That probably means this issue is certainly something I'm doing wrong but just don't know what. I swear I've done it in the past without problems so it has me wondering if it's a new P8 version thing or if I'm just crazy...anyway...
I have something like this...
pool={
{name="Jerry"},
{name="Tom"}
}
list={}
function mybutt(myx)
local obj=pool[1]
obj.x=myx
obj.y=20
add(list, obj)
end
mybutt(10)
mybutt(64)
mybutt(82)
|
And the problem is that when I loop through 'list' every value of 'x' is the last value added via the function, so in this example, 82.
But when I do rewrite as below it works as I think it should above...
pool={
{name="Jerry"},
{name="Tom"}
}
list={}
function mybutt(myx)
local tmp=pool[1] -- This is the part that feels wrong
local obj={}
obj.name=tmp.name
obj.x=myx
obj.y=20
add(list, obj)
end
mybutt(10)
mybutt(64)
mybutt(82)
|

I'm looking for some help or snippet on how to create a path for an object that gives an arc between 2 coordinates.
I have code/examples for waves and orbiting in a circle, but I haven't needed to make an arc between 2 explicit points before. I'm not making an Angry Birds game but need that type of physics arc created that then allows a object to follow that path.
Ideally, something that lets you increase the gravity/friction/whatever that will slow the object down the further it gets away from the source point.
Although...I guess I could just trial-n-error it from the source point, messing with the variables until the thing lands where I need it. But having a 2-point method would probably be more helpful in the long run (for everyone).
Even if you have a cart that has something similar, I'm happy to code surf for things and learn.






3 comments