"Hide and Seek" is essentially a more retro version of an RPG maker horror game, including the setting being a high school in a vaguely anime-esque location.
It was designed to be played in one setting, but also has 2 endings, so I put in an option in the pause menu to skip to the branching part, which is about halfway through. The text can be gotten through pretty quickly if you keep pressing x or o, though. Also, on death, the player character is just placed at the entrance of the school with all progress still saved. I felt setting the player back at all wouldn't really be a good idea under the given constraints.
This is a port of my entry to the 4th Nokia phone jam last year. It's one of a couple games I've made in silly ways that I've been thinking would make more sense in pico-8, but that I wasn't sure until recently how to actually fit into pico-8's restrictions. The idea is that most of the entries were going to be light arcade-y stuff, so I felt like doing the polar opposite. I considered including more of the originally planned content that was cut during the jam, but I was already having trouble with how to fit all the images, so I decided not to. However, I did add a few quality of life stuff and rearrange the text to be easier to read.




I'll go ahead an @zep this, since it's something that isn't even addressed in the forum rules as far as I can tell.
1.Is it okay to post a cartridge that has full screen realistic-ish graphic violence of a disturbing nature?
2.Also, is it okay for a posted cartridge to have implied nudity in the form of a stick figure outline with hair and 2 dots for eyes, with no sexual overtones?
3.If not, what would be the best way give access to such a cartridge without posting it?
My general opinion on content restrictions is that any type of game that isn't intentionally spreading harmful misinformation or inciting real life violence should be okay to make, but that they should only be distributed through channels that reasonably ensure the recipients actually want and are allowed to have the kind of content being portrayed. This is relevant, because posting here in the forums also means giving access to any younger game dev students that might be learning through pico-8. Further, I haven't seen any way to block the posting of games to Splore nor any way to even make it clear how mature of content a game has.




I'm currently attempting to port a game from a very silly game jam to pico-8, since I feel like it'd fit better for the most part. However, while debugging I've discovered that all my images are being handled very slightly wrong.
The images in question are black and white, using every 4 bits to store 4 pixels, and they're loaded into data carts by copying strings of hexadecimal into pico-8 (the idea being to simplify the entire process by focusing on 1 hexadecimal digit as the base block of data). To then reduce the data size, any characters that are "0" or "F" (all white or a black pixels) is encoded with a runtime length using the next 8 bits.
The problem is that both the parts that draw the images and the parts that sample the images for use in collision detection are shifted 4 pixels to the left (wrapping).
This is the function that decodes them:
function image_load(addr, len) local im = {} local s = "" for i=addr,addr+len-1 do [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=124112#p) |


I felt like doing something easy (for me, specifically, since I've made platformers a lot in several engines). I tried to emphasize the feeling of a full adventure rather than any particularly innovative gameplay features. I also tried to minimize loading times as much as I could. The maps are loaded in from 2 other carts when the game starts up and so most of the map data is in the upper memory storage the entire time. This has the benefit that the code isn't minified, so a lot of it is readable (as much as my code would ever be anyway). The downside is that I had to be really picky about only using mechanics that could be coded simply.
The maps were made using Tiled map editor and using a separate script in standard Lua to convert to hexadecimal. From there, a cart for loading into memory was used for assembly. The map format is an RLE encoded terrain map along with a listing of game objects. This allowed me to put game objects on top of terrain more easily, such as the meta-objects that tell enemies when to turn around. Also it made the map sizes smaller. I think the average is about 700 bytes per map.



Made this using the assets from Toybox Jam 3. It's may preferred style of action-platformer, based on things like Momodora 4. The enemy behaviors and especially the bosses aren't as in-depth as I'd like, but I hit the token limit rather quickly. The goal is to just make it through the dungeon, which also requires killing the 4 bosses.
I tried to avoid the common aspects of 2d platformers that I don't like. In particular, enemies are physical objects that don't just magically hurt the player character on contact. At the very least, they have to be doing a ramming attack for their bodies to be hurtful. I also made the spikes on hurt if you actually fall on them.
The map is 185x99 tiles big and has 4 separate layers (background, foreground, geometry and tile palette), but the 4th one is barely used because I was having trouble compressing the map enough. The way the map is stored is slightly different in that the background and foreground are mixed with a separate "mask" map for separating though. This is so that the mask layer can be only 1's and 0's and thus easier to compress. The map was created externally using Tiled Map Editor, with some lua scripts to convert.


KiloKitty has business in the next town over (a special deal on yummy catfood), but the evil no-flight droids are attempting to shoot down anything that flies through the night sky after curfew. Worse, they all look like oranges! (which KiloKitty personally hates)
This game was made for the pico-1k jam. Its source code is only 1009 characters out of the allowed 1024. The cartridge made for this site is slightly different than the one I submitted to the jam, though, as the character count included comments. This version has the game title and my name at the top so they'd appear in the label. I unfortunately didn't have enough space to include a menu or automatic resetting after a game over, so instead the game freezes intentionally so at least the player can get to see how well they did.
I'm considering making an adventure game with fullscreen backgrounds stored as sets of instructions for drawing, so I tried making a flood fill algorithm in the scanline variety, but found it to be rather slow. Even after fiddling with methods, such as wasting memory to avoid management and making the algorithm twice as long to avoid ever checking a pixel twice, I could only get it down to %128 cpu usage for the test case. Most optimizations I tried saved less than %1 cpu. If told to fill the entire screen, it goes even further up to %267 cpu.
It's definitely fast enough for drawing images that don't need redrawing every frame, but it'd be nice if it were fast enough for real time usage. Anyone know a way to make it faster?


"Basement" is an exploration-based platformer in which the main threat is fall damage and the main challenge is finding safe paths through each section. I consider the quotation marks as part of the title. The game takes place in the caverns underneath a magical castle and includes several interconnected areas which can be explored in various orders. In addition, there are extra things to find that result in bonus dialogue.
I tried to design the game in such a way as to not need to explain how anything works. In addition, the difficulty curve is based on the idea of harder sections being harder to find. The ways to get to areas other than the first one all require some trick that the player can learn in a different area, thus forming a progression that is intended to be similar to a metroidvania, but with the upgrades occurring in the player rather than the player character.




I'm currently working on a game that uses strings to store maps, switching them out on the fly. I noticed during debugging that I'd forgotten to flag some of the sprites as walls, so I stopped the run to go fix that, then tried to resume. Upon using the "resume" command, I found the map had reverted to the one I currently have as default.
I put this in the "bugs" category because I didn't see a more appropriate one. I'm not sure if this is something that should be changed. However, it's not mentioned in the manual, nor on the wiki, and I think it should be mentioned in both.
If not too difficult, it would also be useful to allow specifying what behavior "resume" should have.
