BLORB LIKES CANS. GET CANS!
- DPAD / Cursors to Move
- Hold X to Grab / Retract
- Retract all the way back to the portal to collect a can.
- You only get 1 life ~ CTRL-R to restart if you crash (or open the menu with ENTER).
- There is no sound in space (I mean .. there is no space for sound)
Good luck!
This is a game made in 1024 bytes for PICO-1k Jam 2024, co-designed and pixelled by @castpixel (twitter). It is our third production as POD Design; you can find the first two here and here. BLORB is also up on itch and has a PICO-1K entry page. Thanks as always to @Liquidream for running this great jam, and @thisismypassword for the invaluable Shrinko8!
blorb.p8.rom as a hexdump because it looks good:
There are comments in the source code of blorb-1 (use the "Code" pulldown under the cart player above). For the minified 1024 byte version: > LOAD BLORB-0
Technical Notes
As usual, to get this to fit in 1k some entertaining hackery and ugly code was required:
-
A single loop is used to draw the nebula, stars and to decode the gfx from a string. The nebula lines are sometimes drawn over stars, making them twinkle -- a happy accident.
-
One more loop is used to draw both the spacejunk and the chain segments. So the chain can never be longer than the maximum number of rocks / aliens.
-
The eye of each alien is just the last drawn foot duplicated 10 pixels higher.
-
A pixel under the player is sampled for colissions (colours 8~15). There are no "Objects" -- aliens only exist as drawn pixels.
-
The same pixel is also tested when adding a new chain segment. If it is already the colour of the chain (4), the add() is skipped. So the shape of the segment character determines how frequently segments are added, and the retraction speed.
-
The graphics are stored as a 320 character string, where each byte encodes 2 bytes in the spritesheet; bits 0xff are split into bits 0x3333. 44 is added to each encoded byte to get it to compress better. Less escape codes like \0 are needed in the string, and +44 happens to give a distribution of values that compress better with the surrounding code. Mistakes in the decoder produced many beautifully grotesque results like this one:
-
The portal radius (pr) has many meanings: it is used for the chain colour so that it fades out as the portal opens and closes, and is used to determine the state of the game (large == playing, 0 == finished level, 0.1 == died). The player sprite colours are also set to the portal radius when colliding, so that it looks like it is getting sucked in and then eventually becomes hidden. Some alternative portals with varying byte costs:
Wow, an impressive entry followed-up by an equally impressive write-up.
It's still a form of sourcery, but at least we all now know the ingredients
(...sort of! 😅)
You are most welcome @zep - always a pleasure, nay honour to have you submit such coding treats to a Jam I'm running ❤️
It's unfortunate that the camera doesn't follow the player when they move all the way to the far right or left.
[Please log in to post a comment]