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.
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).
0 comments
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.
