A secluded wanderer amongst the various game engines and programming languages, with a major interest in breaking game engines with game projects they weren't meant for.
"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.
This game uses 10 cartridges (1 for story sections, 5 for exploration sections, and 2 each for the upper memory image storage in each type of section). If anyone would like to see all of them, an offline pico-8 version (as well as the fake phone version) can be found on the original game page for the jam, here. The "p8.zip" version on that page also has the carts I used for storing the image data.
8 comments
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.
Reason for asking:
I just finished making a pico-8 port of a game I had lying around from a game jam. It's not at all the usual type of thing that gets made in pico-8 from what I've seen, so I feel like it'd be good to show it here in the forums. It's basically an RPG maker horror game, just in 2 colors with 64x64 resolution for everything but text. The problem is that it's got slightly higher than average gore and dark themes compared to most games from that genre. That was sort of what I was going for at the time, as I wanted to contrast the light-hearted arcade fare that most of the entries were going to be.
Besides showing off that pico-8 can be used for that genre (as well as more normal vns), this cartridge shows some technical things that might be of interest: a huge map accomplished with 32-bit indexing of a bitmap, collision detection via image sampling, an enemy with a node-graph ai so it can semi-believably stalk the halls of a building and open doors as it goes, procedurally populating a building using seeded random, use of off-screen rendering to achieve transitions, and generally the use of creative text drawing to help tell a more interesting story.
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
s=s..sub(tostr(@i,0x1),5,6)
end
local i=1
local step = 1>>16
local n=0
while i<#s do
local v=tonum(sub(s,i,i),0x1)
if v==0 then
i+=1
local r=tonum(sub(s,i,i),0x1)*16
i+=1
r+=tonum(sub(s,i,i),0x1)
for ii=1,r do
n+=step*4
end
elseif v==15 then
i+=1
local r=tonum(sub(s,i,i),0x1)*16
i+=1
r+=tonum(sub(s,i,i),0x1)
for ii=1,r do
im[n]=true
n+=step
im[n]=true
n+=step
im[n]=true
n+=step
im[n]=true
n+=step
end
else
local b=1
for ii=1,4 do
if v&b>0 then
im[n] = true
end
n+=step
b=b<<1
end
end
i+=1
end
return im
end |
The return value is thus a 1d array of true/nil values. nil is used for white pixels to save memory. The step of 1>>16 is used because the main map image used for most of the gameplay is too big to index with 16-bits, so 32 bits are used instead. The reason I repeated the interpretation of all black pixels instead of another loop is because this function is used in spots where speed somewhat matters, and I've noticed too many nested loops can quickly cause slowdown even with lua's optimization of for loops.
This is the simplest of the functions that uses the images:
function map_check(x,y) return currmap[(y>>16)*currmap.w+(x>>16)] end |
This is used for collision detection in the parts of the game where most of the black pixels will be walls (with the ones that aren't being stored separately rather than being part of the map).
I've spent quite a bit of time staring at this code, and I can't tell why the pixel data would be shifted 4 pixels. I've checked the cart data in the spots where the data is stored, and it matches original data perfectly. Can anyone else tell what's going wrong?
To be clear, I'm asking because I might use this again in the future, so I'd like to know what the error is. I can easily work around this for this game but just adding +(4>>16) to all the indices that sample the images, but that's not guaranteed to work in a future game.
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.
The music might be a bit uninspired. I made the world map theme using my normal music workflow and found it used a huge check of the space when converted. I don't mesh well with pico-8's music stuff, so I settled for just whatever I could dish out that didn't sound too terrible. It's mostly in a weird pentatonic scale (C,D,F,G,A) but with 2 tracks flattened to sound spooky (C,C#,E,F#,G#, and D# cause it fit a couple times).
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.
The cart and code are free to use. I just don't like putting things in creative commons because as far as I know that implies an expectation or requirement of attribution. Frankly I don't care about such things. The credits for the art and sound are listed on the jam page
Edit: Oh right, also, the code was minified, so here's where the actually readable version of the code can be found: https://kimiyoribaka.itch.io/deathsbog. It's labeled as "raw".
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.
The only controls are O to shoot and d-pad to move. I was going to have X be a slow-down button for easier dodging, but it turned out to be not useful enough.
The numbers at the top-left are the number of enemies left. It doesn't count enemies that left the area, since they don't come back afterward (they have only one volley worth of ammo). The other number is score, which is gained by lasting longer at 10 points per second.
I don't know how good the average pico-8 player is at bullet hell shooters, but if it's too easy or too hard, feel free to change the part in the code where it says "L=5" to give yourself however many hits you think you'd prefer. 5 is the point where I can barely win. If you want to swap the controls, find and change "I&C" to say either "I&32" or "I&P" (the latter being one of the ways I saved on characters).
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 would estimate about an hour to finish, with the minimum playtime being as low as 10 minutes. Just in case, though, there is a save system.
Edit:
Okay, a friend of my just tried playing this on an xbox controller. It turns out that playing on analog causes down to be triggered when it doesn't feel like it should. This screws up the ledge grab mechanic, because down is set to let go of the ledge. If you play on controller, I recommend grabbing ledges by holding the stick a little upward.
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.
