This is a little fire experiment I've started playing with. It uses basically the same lookup table setup as https://hackernoon.com/pico-8-lighting-part-1-thin-dark-line-8ea15d21fed7 , although that may not have turned out to be absolutely neccessary.
What I'm happy with:
- controls
- performance
- overall look
What could use work:
- sound could respond to player actions
- smoke could drift a little more interestingly
What might be fun to add:
- setting other things on fire
- scorch marks or some other permanent trace
Thoughts are more than welcome!
Hello, all! Here's my entry for Ludum Dare 38! I'm glad that PICO-8 makes it so easy to iterate on little game ideas like this.
This is a game about cells and cell masses. Ride the currents to eat other cells, or just enjoy life as a floating, amorphous blob. Enjoy this as a maze game or just as a screensaver.
Use arrows to shift weight in current, or to traverse walls when stuck to them.
Move away from walls or press Z to dislodge yourself into the current.
This game is also posted here on Itch.io.
My game for Ludum Dare 38.
You can find the game page on the LD website here.
Controls:
Left and right: move the player (the little blue line)
Up and down: select things to build (show in the bottom left)
X: Place what you have selected
You have been tasked with colonising a barren planet. Arriving with limited resources you must build and reap the land to survive.
Your workers will go back to their homes to sleep and to a farm to eat when they require it.
Tips:
Build a house first with a farm next to it.





Hey all,
I was doing Ludum Dare 38 this weekend but I hated the theme and my mechanics weren't coming together so I decided to submit a mapscale function I figured out instead in case it was useful to someone.
It's basically identical to the map() function, except it takes a scale parameter also, similar to sspr (although it doesn't scale width separately from height, though you could add that with only a few quick adjustments if you wanted it). It uses sspr under the hood which is probably not super performant, but it seems to work well enough and I doubt there's a much faster way to scale a full screen worth of sprites anyways if that's what you need to do. It can be zoomed down past 1x or as high up as you want.
To try the demo just hit Z to zoom out. It does 4x,3x,2x,1x in order and then loops back to the beginning again twice as slow each loop so you can inspect how the pixels are getting smooshed if you like. It could probably be improved as when it's slow the scaling is a bit ugly, but it looks fine if you do it quickly.
Below is the code, I tried to add comments to make it a little clearer and I took as much code as I could out of the inner loop for performance. You might be able to optimize the code further, I didn't spend much time on optimization, but I think this is pretty reasonable as is. If you're scaling a full screen of sprites you probably aren't jonesing for performance anyways. I left a parameter for specifying layers but I didn't implement it, shouldn't be hard though it already pulls up the sprite id.
function ceil(num) return -flr(-num) end function map_scaled(cell_x,cell_y,sx,sy,cell_w,cell_h,layer,scale) local sprite_id local drawx,drawy,draww,drawh local spritex,spritey,spritew,spriteh local lcell,rcell,bcell,tcell,wcell,hcell local cell_x_current,cell_y_current for offsetx=0,flr(cell_w)+1 do cell_x_current = cell_x+offsetx --x pointing to current iterated cell -- these are the most i could move out of the y for loop -- makes it a bit confusing but otherwise lots of wasted calculations --these take into account a cell getting cut off lcell=max(cell_x,flr(cell_x_current)) --left bound of current cell rcell=min(flr(cell_x_current)+1,cell_x+cell_w) --right bound of current cell wcell=rcell-lcell --width of current cell spritew=wcell*8 --width of sprite, taking cutoff into account draww = wcell*scale*8 --width of rectangle to draw sprite in drawx=flr(sx+offsetx*8*scale)-(cell_x_current-lcell)*8*scale --x to draw rectangle at for offsety=0,flr(cell_h)+1 do cell_y_current = cell_y+offsety --y pointing to current iterated cell sprite_id = mget(cell_x_current,cell_y_current) --sprite id corresponding to current iterated cell spritex=(sprite_id%16)*8+(lcell%1)*8 --x of sprite (if the sprite gets cut off, it's the left bound of the cutoff) --these take into account a cell getting cut off bcell=max(cell_y,flr(cell_y_current)) --bottom of the cell is technically top of the screen. ie, lowest y tcell=min(flr(cell_y_current)+1,cell_y+cell_h) --top bound of current cell, highest y hcell=tcell-bcell --cell height spritey=flr(sprite_id/16)*8+(bcell%1)*8 --y of sprite (if it gets cut off, it's the lower y bound of the cutoff) spriteh=hcell*8 --height of sprite, taking cutoff into account drawh = hcell*scale*8 --height of rectangle to draw for current sprite drawy=flr(sy+offsety*8*scale)-(cell_y_current-bcell)*8*scale --y to draw rectangle at if draww > 0 and drawh > 0 then --skip if there's nothing to draw sspr(spritex,spritey,spritew,spriteh,drawx,drawy,ceil(draww),ceil(drawh)) --round width/height up so there are no gaps end end end end |


Use Arrow Keys to change dungeon size
Press Z to make new dungeon
This is a dungeon created by using binary space partitioning (as described on roguebasin here: http://www.roguebasin.com/index.php?title=Basic_BSP_Dungeon_generation)
MIT Licensed




Genetic Olympics is a simulation based game that mimics Olympic Competitors competing in various events.
Important Note: After you are done playing this game. If you have the time, it would be very helpful if you could answer a couple of questions that are related to this.
>>Click here when you want to answer the questions<<
By answering these questions you are aiding us in our research about these kinds of programs. We are currently working on a bachelor thesis and we are trying to gather as much data as possible from users.
So what is there to do?
[u]You are completely free when it comes to using this program.

Hello Pico-8'ers!
I've been wanting to be able to make a game in which you explore a large game world that is bigger than the available map space in Pico-8 for some time now but I can't see an easy way of doing this. I've seen people using bits of the sprite space but I'm still not sure how they achieve this.
I'd like to be able to have a giant game world similar in size to that of 'Duck Duck on the Loose'
If anyone knows of ways to do this i'd love to here your ideas!






Hi,
I was listening to Amiga music the other day and fell on "Vaxine", a game I played on those days for quite some hours. You ran on a flat matrix, shooting at viruses that kept trying to gather. "That would be a cool game to make in Pico 8", I thought, and voilà! Just the beginning of course. Never made anything in 3D, and well this is neither, as it's just a bunch of factors thown together to bring fake 3D. But it looks cool imo so let's see how far this can go this way.
I still have my "WhoDares" to finish though, that takes all my spare time (update very soon), so Antidote is not in a rush for now.




Here's a silly thing that came out of another thread where I was contemplating parsing game content out of strings, and just how far to take the idea. Eventually configuration/data formats always end up becoming programming languages (heck that's how Lua got its start), so why not just make it a full programming language from the start? Get a jump on Greenspun's 10th rule.
So, I implemented lisp-8, a small lisp dialect intended to be used in pico-8 carts. The core code is about 1400 tokens after some fairly aggressive (ugly) optimizations. I could cut it down by about 200 tokens if pico-8 ever exposed Lua's _G
variable.
And of course, once you've got a scripting language embedded in your game, why not allow your players to type in code and make a full programming game out of it?
Of course, it might take a week to type in your program with the limited input available on pico-8. So if you don't want to type in code yourself, hit tab to cycle through some sample lisp statements.





So my 6-year-old son loves PICO-8 and it sort of accidentally ended up being his introduction to programming. Yay! BUT after we really got into PICO-8, the Splore command was introduced and now there's this totally new vector for him to receive content that is not vetted to be kid friendly.
I totally see why everyone loves Splore and it's great for basically everybody but my family, so I was wondering if there was any way to prevent our install of PICO-8 from downloading remote carts. If that existed, I could create a whitelist of sorts by downloading appropriate carts and sticking them in his carts folder. Alternatively, if we could somehow disable the Splore command in our install, that would also work. The least desirable alternative (but still preferable to the current state of affairs) would be obtaining a pre-Splore version of PICO-8 and the manual.txt for that version.
Are any of these sorts of things possible?





