Important note: Due to the multi-cart nature of this game, do not use the "reset cart" menu option. All that will do is corrupt the data loaded from another cartridge and make the whole system crash.
A massively multi-cart Mario Party type of game. Currently an early proof-of-concept tech-demo type of thing and not actually "playable".
The character select can be huge because every character exists in its own "sprite blueprint" cart and gets chainloaded compressed into RAM when the game starts, followed by the game board or game mode (eg. a minigame select free-play menu) cart which drives the rest of play. The board/mode itself (and any minigames it loads into) decompress only the specific sprites they need into the active sprite sheet for use in play. Some minigames might only use the sideways character sprites because they're 2D. Some might use tiny Jelpi-style sprites for players. Some might opt to use player portraits instead of world sprites. And so on.
The sprite blueprint system supports multi-part sprites (in this case Nora's head is separated from her body in all but the portrait sprites) made of parts which are independently offset, vertically and horizontally flipped, and palette-remapped (including primary and secondary "special colors" which might be remapped for duplicate players or special events), and all that data is transferred between carts so the sprites, colors, and character names are consistently recreated.
This is all the character-specific data for Nora. Including: Character name, sprite segments (body parts), palette remaps, and which colors should be remappable in-game and what their defaults are. Since I want Nora's mouth/tongue (visible in portrait) to always be red regardless of her hair/fur color, I made her primary remappable color actually pink and just set it to default to red, instead.
When loaded, the cart reads where it should load itself into RAM from the parameter it was loaded with, and then either loads the next cart also specified in the parameter or tries to follow the breadcrumb back to the previous cart. If there is no parameter, it just shows you the static label screen instead.
This is the cart that gets loaded after all of the characters to drive the game.
At the moment it is little more than a texture atlasing test and my current development sandbox for the Nora Party API that'll be shared across all mode/board and minigame carts for the purposes of decompressing and rendering player sprites.
This cart contains no character sprites of its own, so selecting different characters from the base cart will cause it to render very differently.
If you're doing sprite compression anyway, then your sprite data is at some point being serialized or similar. Meaning that for each pixel, it's being stored as it's data, in this case it's color.
So instead, you could just index groups of "parts" that share a color, for instance, all her fur could be indexed to equal 2 or "2a" or whatever data form you want, then her tongue/mouth could be "3" and her hair could be "5" then you could set 2, and 5 to equal pink, and 3 to equal red.
This way you can swap pallets manually instead of just using pico pallet swaps. Giving you full control over what you swap and when.
This is the second playable character for Nora Party Pico. The character API is almost stable now, I'm considering a few late additions like character-specific "symbols" or "favorite items" and sound effects, but none of this is futureproofed... I also need to consider adding an active sprite/animation viewer component to the runnable program, to aid character development.
Even though Numo's colors are vastly different from Nora's, I like the idea of colors E and F being reserved for the translatable primary and secondary colors, and the rest of Pico-8s colors being used for transparency and remappings.
Some development progress on the 4 player board game (or "party board") game mode. Dialog boxes, dice to roll, and dramatic gridless map layouts, oh my~
The dialog box comes with automatic word-wrapping (as the GIF itself states), which supports breaking after hyphens, turning whitespace into newlines, and breaking lines with neither of those characters arbitrarily as needed. It even reduces the number of characters allowed in a line specifically to make room for the little continuation blinker, only for lines which have that pause on it.
The second image is showing the un-rolled dice resting on character heads, waiting to be thrown. The actual throwing animation isn't ready yet, but all of the digits have been rendered. For some reason, instead of adding support for proper "attachment points" in character data like I had originally intended, I just threw in a minor "character height" adjustment setting that ranges from 12 to 19. Here Nora is marked 13 pixels tall, and Numo is 14 pixels tall. This makes the dice rest nicely on their heads. I sure hope Nina isn't actually something like only 10 or 11 pixels tall, when I get around to porting her in...
The lines between board spaces are the exact path a character will move along to traverse the board, including branching paths and non-space nodes. They will be hidden when a proper background is put into place with much more visible lines of travel.
Also the fade to white is accomplished this time by shoving the palettes for it into the very bottom of the sprite bank (in the shared sprite/map memory that I often use as dynamic memory, since its usefulness is more limited during development) and then reload-ing it from ROM directly into the draw state, setting all 16 colors at once and not using any Lua memory nor Pico-8 RAM to store it. I'm kinda proud of that for some reason. That's efficient enough that it's basically free, outside of the four sprite slots it eats. (Due to Pico-8's draw state palette being double-wide for the sake of the single transparency flag, every other pixel must be black.)
Edit 2018-11-03: Updated with dice-rolling animations.
[Please log in to post a comment]