Connect the lights to the energy source rotating the electric plugs/pipes/whatever.
I saw this little puzzle game a long time ago as a web Flash minigame. This is the 2nd time I remake this game. I’m afraid the first one did the puzzle generation way better than this one, but quality is something that we can happily sacrifice when code size is so scarce.
All gfx were hand-made using Pico-8 excellent built-in sprite editor.
Puzzle board limited to 10x9 due to not being able to use 16x16 8bpp images from resource pack as tiles… Maybe a Pine-2K bug not fixed yet?
You always get the same puzzles as there’s no (documented) way to set a random seed based on milliseconds till first button press or something similar. I ran out of “progmem” so I can’t code other alt ways like waiting for first key press and then calling random() the number of ellapsed milliseconds. I could split the script in 2 (puzzle generation + gameplay) but I’m too lazy/busy atm.
I can’t access the new features of Pine-2K v1.4.0 as they’re not documented in the archive. Both language.md and readme.md have got Jul 19 as last modified date. It’s a pitty. In the past, I have given up using many dev tools due to poor documentation.
Pico-8 spritesheet editor, of course. The only problem working with spritesheets is having to break it up in 16+ image tiles for sw not supporting spritesheets… it’s a real pain.
It works for me, do you have an example? Are you sure the image you’re using is 8bpp?
I tried it on hardware and got a different puzzle each time. In the emulator, since there is no startup screen, milliseconds doesn’t serve as a very good source of entropy.
Other than some keys in the io function, both language.md and readme.md are mostly up-to-date. More documentation takes time and 1.4.0’s priority was fixing crashes that were getting in the way of current projects. I’m thinking of removing readme.md and just making a wiki, since that’s easier to maintain.
Yep, just uncomment the only tile() sentence in drawBoard() function and add // before the sprite equivalent:
tile( tx, ty, tLightImg[ v & 31 ] );
var xs = tx << 3;
var ys = ty << 3;
//sprite( xs, ys, tLightImg[ v & 31 ] );
This is what I get:
I have checked the bit depth and dimensions of every asset and only battery.png and energy.png were 8x8 4bpp but they’re not used for tiling, the rest (lightN.png) are 16x16 8bpp acording to IrfanView viewer/converter.
It’s a nice side effect that it runs on hw out of the box. I haven’t seen any of my creations running on hw yet. I’m mostly a sw guy, but I’d like to build a (more or less) compatible device driving a bigger & better display.
As for the emulator, we need more entropy! (and maybe optional v-sync to avoid ugly tearing).
Ok, I’ll just stick to what I already know, which is more than I need.
I’ll leave the advanced demo effects for the unfinished SBDL, which is way more powerful for graphics and designed for heavy lifting with low RAM footprint. Btw, SBDL is not bufferless as it requires you to provide a 16bpp RGB565 buffer with any number of rows to send to display, and it doesn’t allow direct mode. The main missing features in SBDL are the framebuffer, the infamous modes and the global palette, although you can add them at runtime if they’re needed for persistence or pixel by pixel tasks.
