Not so much a game as a tribute to the fishing minigame in Deadly Premonition. I mean, technically you could try to go for a high score, but you probably won't want to.
Fire 1/Z to cast your fishing rod and stop the roulette once you catch something.
As of Pico-8 0.1.0, the intro screen is subject to this bug. If you're running the cartridge in the native version of Pico-8, pressing Esc while the logo is scrolling off the screen will crash the entire program.
I'm working on a tune that features a lot of quick arpeggios, so I had to sequence it with double the intended speed so I could squeeze in all the note data. This uses up sfx slots fairly quickly, which wouldn't be such a problem if sound effects past no. 32 were usable as tracks in the music editor.
In case this isn't feasible, it would be nice if the documentation at least noted this limitation. I ended up using only two channels for one of the tunes in Let's Karate, since I had already used up some of the first 32 sfx slots for game sounds.
I figured that I should probably do this since there's a cover of Megablast for practically every sound chip ever. I think it's a law or something, and I don't want zep to get in trouble with the computer police.
A toy that pokes the sfx RAM full of random garbage and lets you play the results on multiple channels. It'll mostly sound like generic computer ambience from an old educational film.
The randomly generated sounds will be stored in the ROM on startup, so comment out the cstore() at the end of the _init() function if you want to save your sounds for posterity's sake.
Disabling a single channel should technically stop playback on that channel, but it occasionally won't. This might be due to the weird looping points that the program generates for each sfx.
Might as well call this the finished version, since barring optimization and cleanup I'm out of space.
-There wasn't really much point in moving away from your opponent, so backward movement has been replaced with a longer backstep that can be used to avoid attacks
-Tweaked a few pixels
-2 new backgrounds (chosen randomly for each round)
-Randomly generated character appearances (loser's character gets replaced after each round)
-Characters now have shadows
-1 new music track
-Options menu to change/disable the music and choose between 3 CPU difficulty levels
-Player 2 could still go slightly outside the screen's bounds
-There's a certain set of inputs that will prevent a character from going into the win pose after knocking an opponent out, thus being able to move around freely and preventing the round from ending. I have no idea how to do it apart from buttonmashing. The CPU will occasionally manage to do this, since technically it's constantly buttonmashing. Don't think of it as a bug, think of it as the ultimate victory celebration!
-CPU opponent with rudimentary AI
-Rudimentary main menu to select between 1P and 2P modes
-Attack inputs wouldn't register at a certain point after moving
-It was previously possible to press both attack buttons while blocking to perform a 100% sure counter
-Characters walking outside the bounds of the screen
One-on-one fighting game inspired by International Karate and the Hiryu no Ken series. Two player only at this point. Absolutely no testing or balancing done.
Left and right to move
Fire 1 to punch
Fire 2 to kick
Punch and kick while holding up/down to hit high/low
Up to block high
Down to block low
Backwards or stay still to block middle
You can perform a ludicrous counter move by performing a successful block and then pressing the same attack button your opponent used. E.g., press punch after blocking a punch to counter.
I wanted to see if using the sprite drawing functions would be any faster than using lines and rectfills, so I made a single reference sprite containing all the 2x2 pixel configurations and used that to draw the image. There's really no noticeable change in performance, but now I can change the reference sprite into random garbage and get weird distorted mosaic effects. Press X to check them out!
Also added some comments to my code, fixed a bug that caused the background color to extend one horizontal pixel too far, and added the option of drawing the image's background color as transparent if a negative number is given as the function's background color argument.
The sprite memory in PICO-8 can get a bit cramped, so I wanted to try and see if I could implement 1bpp sprites. The idea is basically that each pixel color corresponds to a specific 2x2 pixel configuration. It's not very well optimized, as it more or less draws each pixel out individually. Furthermore, it would probably need another tool to convert hand-drawn single-color sprites into the proper format (I plotted the test image in by hand, because I am legit dumb. It's a screenshot from Tetsuo: The Iron Man.)
Arrow keys to pan the camera around.
Fire 1/Z to crop the image into a random size.
I mostly implemented these to see how it would run at different sizes.
Here are the pixel configurations that each color value represents.