This is Lucy Loves Pebbles, a game in 559 characters where you feed Lucy Miu with her favorite pellet-based food. #TweetTweetJam
Press X to flip the flippers and try to fling the pebbles into the cat's mouth. If she eats enough, she'll be happy - otherwise, well, nothing happens.
I'd never tried to minify game code before - only demos for #tweetcart. As it turned out, I made two choices that would make this one very difficult to minify: I spent a stupid number of characters drawing the cat head exactly as I wanted (instead of picking cheaper graphics for it) and I chose game mechanics that were really much more complex than I ought to have chosen.
The implementation was fairly straightforward: the left side of the screen (i.e., the cat's face and rail/flipper) are drawn with primitives, then memcpy/spr-flipped to the other side. I use the distance to center to determine what happens when the flippers are pressed, and the height to determine if it makes it in the cat's mouth.
For minifying, I wrote a small python script that would read a less-minified cartridge and output the one I've uploaded. Essentially, it strips indents, some whitespace, and comments, and allows me to use comments to decorate which lines' newline characters can be deleted.
Yes, this may be my worst cartridge, but it was a fun weekend!
0 comments
The Falling Sand game has been around a long time, but I didn't see a Pico-8 port.
The reason for that is: it's really hard to get a decent-sized grid to run at full speed on the Pico. This implementation runs a little slower than 15FPS (when running the simulation) on my machine, so it isn't quite as smooth as I'd like, but still pretty playable. In the future, I'd love to post a faster version, but I've hit a bit of a wall with the Lua optimizations I'm already aware of.
If you're not familiar with Falling Sand, the basic idea is that you're simulating a bunch of elements in a grid, where different elements react in different ways - oil floats on water, fire burns wood, plants grow when watered, and so on. It's fun to play around and build things, but there's no goals or progression, really.
Have fun!
This cartridge doesn't have a very impressive test, but the code might be useful to some of you.
This is an implementation of the LZW compression and decompression routines with variable-width coding, commonly used in a few image formats. I've nibble-aligned the codec, and I provide an interface where you can give addresses for compression/decompression.
The way I envision using this is: construct rooms in map #1, then when you're finished, compress them to map #2 or elsewhere in map #1, then store them to the cartridge. When you're finished building rooms, you only need to include the emit/read symbol functions and decomp, which total to about 340 tokens. You can make a table of addresses for loading these rooms during runtime, and it's pretty fast, all things considered.
As for compression ratio, this demo shows a case where it's pretty bad - you could conceivably end up with bigger data than you started with if your data was sufficiently random, but for maps this is often not the case. If you build a table (as described above), you could mix entries for compressed data and entries for "literal" data to only compress when it helps.
In the future, I might provide an interface for compressing sub-rectangles of the map to avoid having to compress empty space (even though, in theory, this will be highly compressible).
Hope you find it useful!
New to the Pico-8, which is already starting to feel like home.
When I was a kid, I remember playing these awful Game Gear sports games we got at a garage sale. This is my take: working your way up through the local semi-pro ladder, you can get a chance to unseat the seemingly-invincible Jeremy Mondo (I hear he's got a sponsor now!).
No particular advantage to choosing any of the characters, and some of the opponents you face early on are pretty bad - the characters are inspired by folks I've played (much less fun) games of racquetball with back in my hometown.
