use arrow keys to jump along the lily pads!
if you are fast you can jump twice on lily pads :-)
this game has 22 stages, you can beat them all if you try!
(created for Mini Jam 106 on itch.io)
1 comment
This is just a proof of concept/work-in-progress to see how much interest I have in continuing to work on it and how much (or little) interest other people might have in using it.
Here's a quick little gif demo. No sound obviously but imagine each note playing as it's entered and also on playback:
Try it out:
Controls and (current lack of) Features
Like I said, this is currently just a proof of concept and not (yet?) a useful tool so don't expect too much from it. All input is currently via keyboard.
At the start you'll be prompted for a title, bpm and time signature. None of these matter at the moment. You're locked into 4/4 at 150bpm.
Note Entry
Note Values
The top right corner shows you what note value will be inserted next. You can change this with number keys 1-5:
- 1 - whole notes
- 2 - half notes
- 3 - quarter notes
- 4 - eighth notes
- 5 - sixteenth notes
Pitches
To insert actual notes of the selected value use the bottom row, keys z-m, just like entering notes in the tracker with 'z' being C and 'm' being B. At the moment it's just the bottom row/white keys but I'd obviously include the sharps/flats as well in a real tool.
It's a bit awkward at the moment because the notes go up until F and then drops down to G. I did that because I didn't want to mess around with ledger lines at the moment and this way everything stays on the staff. In reality I'd have the notes all going up in a particular octave and then using the up/down arrow keys—or something else—to change which octave you're in.
I'm not using the top rows for the higher octave like the tracker does because I want to reserve those keys for additional functionality like saving, adding instruments, etc.
Playback
At any time while you're entering notes press space to play the whole song from the start. When it's done you'll be back in note entry mode.
Future Development
So that's all it does at the moment. Currently there's no way to save the song, edit notes, add rests or...anything else. But here's a probably incomplete list of things I'd probably like to add at some point in no particular order.
- Save/load songs to memory and/or another cart
- Octaves for a full range of notes as mentioned above
- Clefs. As is the staff is in treble clef. Adding, at least, bass clef would be useful
- Actually allow you to enter tempo and time signature
- Bar lines
- Allow up to 4 voices and ability to switch around between them
- Allow all the pico-8 instruments and custom instruments
- Dynamics (p, f, mf, pp, crescendos, etc.)
- Repeat symbols and voltas
- Effects/articulations (tremolo, etc.)
- Maybe a mode specifically for notating drum parts
- A way to load and play the songs in carts
- Possibly the ability to convert to/from the pico-8 tracker format
- Joining notes when possible (connected 8th notes, for instance)
- Ties and slurs
- Add rests
- Select/edit/delete note(s)
- key signatures
That's what I've got off the top of my head. Suggestions welcome.
not a game. spinning triangle cart.
how to play: 🅾️ or ❎ to eat. 🅾️❎ to burp. or quit.
inspired: play "alone in pico" cart, tried to render triangle and made this.
Answer: Quite a few! But you probably have better options.
I've previously seen PICO-8 decoders for hex and base-64 strings. Recently I was curious: which base is most efficient? There are a lot more possibilities than just 16 or 64, and I knew PICO-8's code compression would affect the actual efficiency.
So I ran an experiment.
The experiment: I wrote a script to generate a bunch of .p8 files containing random data, and I exported them all through PICO-8 v0.2.2c to see how long the random data could get before PICO-8 would complain. The random data was in the form of strings in a given base: e.g., for base 16, the cart's entire program was x="(random hex string)". I generated these carts from base 2 (just "0" and "1") up to base 92 (almost every printable ASCII character). I ran several trials for each base because using random strings causes some variation in the measurements. I then counted the theoretical information content of each string (e.g., log-base-2 of the alphabet size) and converted the average for each base to kilobytes.
My initial hypothesis: There would be a few different sweet spots where the size of the alphabet would play better with PICO-8's code compression. Specifically, I had my metaphorical money on base 48 because the indexes 0-47 work well with PICO-8's move-to-front encoding.
The actual result: There are no clear sweet spots! Small bases are less efficient, but efficiency plateaus around base 16. And if you go much higher than base 64, you get a gradual linear increase in efficiency.
So what's going on here?
It turns out that PICO-8 does a surprisingly good job of compressing strings. Even with a random hex string, you still get quite a few 4-digit substrings that occur multiple times in the data, just by chance (something something birthday paradox). PICO-8 can encode these repetitions efficiently (yay compression!), so even though a hex digit carries fewer bits of information than a base-64 digit, PICO-8 can store proportionally more of them.
(Note that this doesn't break any laws of data compression! PICO-8 is compressing random hex digits to around 5.38 bits/digit, whereas the theoretical minimum is 4 bits. PICO-8 isn't beating the universe. It's just beating its own move-to-front encoding, which can do hex digits at 6 bits/digit.)
The plateau happens because as the base increases, the data gets harder to compress. Each digits carries more bits, but the string cannot be as long because PICO-8 can't compress it as well, and the two factors cancel out each other.
The linear section after base 64 happens, I suspect, because when PICO-8 can't compress a section of the data, it falls back to encoding raw bytes for that section. So at that point, the base of the string doesn't matter -- it always costs 8 bits to encode each digit, no matter what the base is. I haven't tested it, but I suspect base-128 would work well if you had to stuff a whole lot of data into a string.
All that said, a lot of this isn't very pragmatic for actually making carts. There are better places to store binary data (e.g., the map section of the cart) and there are better ways to encode specific types of data (e.g., PX9 for images). But I had fun doing running this experiment, and I haven't seen any other discussions like this, so I figured I'd share the results in case anyone else was pondering similar things.
Saving a project with save @url at https://www.pico-8-edu.com/ does not include the map.
Steps to reproduce
- Open https://www.pico-8-edu.com/
- Type
load - Select a cartridge with a map, for example
- Type
save @url - Copy the URL in the browser and open in a new tab. (URL in my case)
- Observe that the map data is missing (code and sprites are not missing)
Expected result
In 6, I expect the map data to be present like in the original cartridge and in step 3.
I was doing some table comparing logic like so:
local a,b = {},{}
local t = a
if not t==b then
?"!",7
end |
And using the not operator can trip you up cause it's not testing against the whole bool==bool (I think..?)
but instead (not bool)==bool!
Anyways I was stuck on this problem for hours and I wanted to let other's be aware if they're not.
Thanks to @pancelor for figuring it out and helping me.
(it turns out I just wanted to do
if t~=b then -- ... end |
)
Made in 1 hour for the 1 hour animation challenge
Press the Z button to jump!
1houranim
Hello!
I have had PICO-8 a while, but never really used it until I watched aarthificial's YouTube video about pixel art. I wanted to try around with a bit of pixel art myself, so I did my 16x8 sized version of the heroine in the sprite editor. Then I remembered playing "Bionic Commando" on my friend's Amiga as a kid, and a long love of Portal means that I started work on this game over the last few evenings.
The basic functionality is all there (running, collision, hooking, pulling, switches, pressure pads, launchers) and I've had a go with music and graphics, but I'm no level designer, it turns out! So this is a work-in-progress job to get feedback on those core mechanics, and ideas for how to extend the game out!
I put a completely unscientific research poll up on Twitter asking folks where they usually play PICO-8 games and the majority said they primarily play using the desktop client.
- Desktop App: 56.7%
- Desktop web browser: 23.3%
- Phone web browser: 16.7%
- Handheld App (non-phone): 3.3%
I put up the poll because PICO-8 is in a unique spot where it can be played various ways on various platforms, and yet we're not able to design games to account for one or the other. This has always been a point of ponder for me and having this data helps me think about it better.
However, the audience that saw my tweet is probably regular PICO-8 players and devs anyway, so it's not the casual gaming public that most certainly plays through the web on Itch.io and whatnot. But, still interesting to see the results.
What does this tell us? I mean, not much, I guess, but to me it says the laptop/desktop is the device (and environment) where we're mostly playing. It's not on your phone or on a handheld like the RG351. It also means Splore is likely a primary source of access/finding of games. We might also be able to infer that the game is being seen on a rather larger display, not phone or handheld sized...so worry about sprites being "too small" could be less so.
Again, not a deep dive or anything like that but some interesting data all the same. Use it for good, not evil.
Vec-Rhytm is a game similar to vib-ribbon. Your goal is to dodge
the obstacles that appear as the music is playing.
There are only 2 songs. This is more of a tech demo than a real game,
I wanted to see if drawing lots of triangles would be viable, It was!
The music titled "Into the belt" was taken from Pico-8 Tunes Vol.2
which can be found here
https://www.lexaloffle.com/bbs/?pid=62911
just a little demo game that has movement and dashing
to dash just use X and O (x,z)
Give my pong game a try. It has AI.
Tetris with Hexagons
Ever wonder what Tetris would be like if it used hexagons instead of squares? It would look like this! Tetrahex plays like Tetris, but uses tetrahexes instead of tetronimoes.
Options
Title Screen
- Level - Starting Level. Each level goes slightly faster, but scores more points.
- Speed - Changes the speed of all levels. Each change either doubles or halves the speed.
- Controls - Left and Right always moves pieces the same direction, but you may choose what each other button does. Chose between
Hold - Swap the current piece for what is in the hold place. May only be done once per piece (you can't swap back and forth). First time swaps for the next piece.
Soft Drop - Drop the piece one hex down.
Hard Drop - Drop the piece as far down as it will go.
Spin Left - Rotate the piece 60 degrees counter clockwise
Spin Right - Rotate the piece 60 degrees clockwise - Randomizer
Type
Shuffle - The 10 possible pieces will be shuffled then added to the sequence. Once all 10 have appeared another 10 will be shuffled. This ensures you will never get a piece 3 times in a row, and a piece will have at most 18 pieces between apppearances.
Original - Each piece in the sequence is picked randomly, independent of other pieces in the sequence.
Seed - You may set a seed for the random generator so that you always get the same sequence of pieces. Use this to master a sequence, or challenge a friend to beat your score on an equivalent game.
Generate Seed - randomly generate a seed
Clear Seed - reset the seed to none
Pause Menu
- Ghost - Choose whether the ghost (the preview of where the current piece will land)
appears or not - Stripes - Turn on or off alternating background colors for each line
- Style - Choose between 4 styles of appearance
- Music - Choose between 3 background songs or turn music off
Updates
v1.1 - Added 🅾️+❎ control option
v1.2 - Added Tetronimo mode!
