Long time ago I had a project of the demake of a specific game on retro hardware (this project is not dead yet, I just lack time to work on it)
And a few days ago, I crossed some data for that project and my brain told me
- Why not see if it's possible with Pico-8?
My answer was quite simple: - Challenge accepted!
It's not a game perse, but I'm currently more advanced than on the original project, there is no cartridge for now, as the code is a mess and it's basically just testing some of my original ideas, I have a lot of things to do before I could say "it's a playable game" right now I've just tested the level generation, so nothing really fancy for now.
So, I present you the first moving picture of PPPPPPPP:
(the starfield come from the same effect in the tweetjam, I used it to test the transparency)
One challenge with the original game is the world size. If you cut the world into 8x8 tiles, you have a tilemap of 800x600 tiles, which is just enormous, and without counting a specific area in that game.
800*600 = 480000, so it we use 1 byte per tile, we use ~470K of memory, just to store the complete tilemap :D
As said, the major issue on retro hardware is to be able to store the full map in the computer/gaming console memory.
(the pico8 version will not use the original map data due to screen size constrain, but I plan to make the map similar to the original)
The difficulty will be to store all the screen and music in the 64K size of a Pico-8 cart, but I'm pretty sure that with my level storage design (with some adaptation for Pico8) and some compression it will possible :))
For the map, you could split it into pages, compress the pages, and then load only the 4 necessary to draw what the character can see. You probably want pages larger than the screen, so you get some time between noticing the need to decompress and the time when you actually need the data. Or, if you can afford to decompress up to 3 pages in one frame (worst case is a diagonal move that crosses both x and y thresholds), you can just use screen-sized pages. The other option is to allow up to 9 pages to be loaded simultaneously, which costs more memory, but you do have 1MB of Lua mem, so that's not necessarily terrible.
As for compression, I think zep has sample code around here somewhere. Even plain old run-length encoding would work well, though, since the vast majority of your level is areas of the same tile repeated. Still, something able to copy out of already-decompressed data (LZSS, LZW, and I think zep's) will give much better ratios.
There is no scrolling in the original game, and I don't plan to add scrolling, so decoding a screen is not a real issue. No the real issue is really memory.
Even with Pico8, with 128x128 → 16x16 screens, as the original game had 20x20 screen (each screen are 40x30 tiles on the original game), that mean 16*20 = a square of 320x320 tiles → 102400 tiles references to store. so nearly the size of 2 pico8 cart
!
Of course this is for 1 byte per tile, which is non-sens of course for that project.
I'm using different technics to store the map in a way which use the less memory, and will also use compression, which has yet to be done.
The current image displayed is half generated on the fly, the map does not store all the information for a specific scene, I may explain a bit more about that later when I will release a playable demo, which is absolutely not the case right now
The other thing you might want to consider is having a map made of objects, a la Mario with blocks and pipes and stuff, so that your map is stored not so much as an array of tiles but of the method used to construct it from nothing, e.g. place a 3x12 pink pillar at 6,7 could be done with a byte token for the object type, two nybbles for the tile-wise dimensions (and only if it's a resizable object), and two nybbles for the tile-wise coords. That's 2 or 3 bytes replacing 36, and open space costs nothing.
If you do that, you can also make the loader smart about joins, such that adding a block at ground level adjusts the tiles so that the "edge" of the ground follows the new silhouette.
For reference, if you used such a constructive method, the level in your image might come in at 31 bytes, for 8 ground/floor rectangles @ 3 bytes, 3 single punchout blocks at 2 bytes per, and a terminator byte:
0100f0 010152 01030d 010e7f 014568 01c5f9 019bdf 01faff 0242 029b 02be 00
This is exactly what I was hoping this would be. :D
That's an interesting method Felice is describing, it sounds a lot like what I tried to use in Gentroid's world generation - at least the "between the walls content generation" part of it.
Really, you can just load the game one screen at a time, too; and just commit one screen in the map section to being a title screen and a second to being a map screen. You'll need a win condition screen and... I forget, but I know there's one more.
If you can crunch the level concepts down to the 7x4 screens remaining, but keep them fun, there you go. Bear in mind, The Tower is one vertical shaft that basically wraps back upon itself... so you can make the entrance to the left and the exit to the right of the same screen (so it'll dump you out across the map). The far right-hand side comes to mind. The starting area was connected to the part with the conveyor belts, so you could get away with making that part a screen or two bigger. And the others? You really just need about 5 screens apiece for those (one introduces the level concept, the others are the tests). Stick one shiny in each area, and you're golden. Oh, I guess you do need a one-screen home ship, huh?
Nothing really fancy here, I've just made some test for collision, and allow to move Viridian as expected
Don't expect anything fancy from the code, it's ugly and absolutely not for production, this is basically just a test cart for some idea, there is no acceleration at all in the movement, so Viridian is not sliding at all.
The colision test is sub-optimal too, but it allow basic move in this cart.
Be warned that if you fall or go outside the screen you will need to reset the cart... :D
Oh flipping is done using Z, and of course left/right allow you to go left and right...
It seems that the web player does not love left/right + Z combination, at least here, so it may be difficult to "play" in current version.
Check Celeste or Migli to see how they handle the button checking. I know they have no problem at all with left/right + Z, they're platformers so it's the whole premise of them! It may be your keyboard, if the directions and Z share the same vertical parameter, too.
That could be it. But then, I hear "0.1.9" is supposed to be focused on upgrading the web player and making that more consistent with the game. Maybe that alone will fix your issue! Here's hoping.
[Please log in to post a comment]
