• Next pieces come from a shuffled bag
• Bag could include:
  • all tetrominos
  • one triomino
  • one domino if implemented
  • one monomino
  • two pentominos from a separate pentomino bag

We need less than 8 fruits to avoid spending all the available sprites. To avoid them being locked out, they need to expire after some time

We need to render shadows for the blocks, with these conditions:

• shadows must be rendered where the blocks are going to fall
• they depend on the distance of the piece to the ground
• they shouldn't render where they would be occluded by the block

Render placed blocks as marshmallow, with a short animation

They should stop animating when the game is paused

Board::render has a loop setting the board's attributes, but the attributes are already correctly set from the nametable data. Unfortunately, removing the loop causes the code to not link.

Player-fruit collision is "exact", so with the new movement code the player can walk past the fruits

• maybe a predefined maze saying "Ludum Dare"
• maybe a maze full of horizontal lines (idem vertical)

Instead of lack of energy:

• failure to place blocks
• failure to meet stage's goal (?)
• being trapped

Maybe make a separate bag for 1-2-3-minos, pick one of them per main bag serving

• try to make them less confusing
• update with new polyomino controls

(and fix stuff if it doesn't)

For example, 3 blocks in a diagonal

If we render the uni before the snacks, because of its background priority, it may make part of the snack disappear (reversing the other will only result in the same problem on the opposite direction). We need to render the uni and the snacks in reverse-y order (i.e. first the snacks that are on rows below the uni, then the uni, then the snacks on rows above it).

(snacks won't interact with each other because (after #75 ) they will never be next to each other)

Allow player to pause/quit during gameplay

M-Tee:

-Swapping controls (visually, I was thinking maybe we deliberately flash the unicorn and the active block a few times, in an alternating fashion; like:

Both visible.
(Press select on either controller)

1. Uni off; Block on
2. Block off; Uni on
3. Uni off; Block on
4. Block off; Uni on
5. Both on.
   (So maybe some kind of back and forth sound?)

Like, up for hard drop, down for soft drop, holding left/right repeats movement

By M-Tee:

• It might be nice if the fruit spawns at intervals that results in the bobbing animation to be offset from each other (i.e, whilte one fruit is on high, the other is on low?)
• I think fruit should spawn frequently enough that there are often 2 fruits on screen.
• If the player is at 0 energy, should we influence the location of every other fruit spawned to be closer to the player?
• a reminder that, if we haven't already, make sure that active fruits don't spawn on the same row, for scanline conservation.
• when fruit disappears from not being picked up in time, it should flash on/off first, I guess at the same rate we use for the energy bar (on, (off, on, off, on,) off)

(preferably one where it fits)

Otherwise minotaur seems unresponsive due to the grid movement

We need to prevent snacks from appearing on the same scanline - either on the same row or on consecutive rows

An idea: since we have at most 2 snacks, make one spawn on rows (1,5,9) and the other on rows (3,7), this way they'll never meet.

By M-Tee:

Energy Bar

4 separate bars, each with a fidelity of 3. (So, energy max points of 12).

I can do this with 6 sprites. (3 in pink, and 3 in white for some transitional animations, similar to what I pitched for 5-star’s)

At first, I was thinking we could do a solid 30-point bar, with 1-pixel fidelity and display the value by altering the H-position of the rightmost visible sprite. (with a masking sprite on the left when displaying a count less than 8)

But, I think having the 4 separate bars is easier for a player to see and know exactly how much they have left to make the decision of whether to charge or not, or how soon to prioritize getting fruit, whatever.

Anyway, with a max of 12 points, I’m thinking…

We start the player with 9.
Fruit adds 3 points.
Charging costs 1 point.
Getting hit by Miroh costs 3

I’m not sure about decay rate (fairly slow to encourage charging though).

----

I'm thinking every change of the energy bar should use the following transition (the same flashing animation I had said we'd use often for 5-Star)

Current State
(action occurs)
Next State (4 frames)
Prior State (4 frames)
Next State (4 frames)
Prior State (4 frames)
-----
Next State

So in this animation, the player charges (-3). Then picks up a fruit (+3). Then decays thrice (-1), (-1), (-1), then picks up another fruit (+3). Each transition, even the decay, I think should use this animation, to draw the player's eye to it when it's happening.

...However, with the decay, I think the flashing should precede the decay (like a warning). That way, if the player picks up a fruit while the decay animation is occurring, the increase from the fruit is more impactful (for example, as the energy bar is decreasing from 6 to 5 points, picking up fruit would increase to 9 because the energy bar hasn't yet decreased to 5 until that 16-frame transition animation has completed).

Energy Bar sprites should use TileIDs $31, $32, or $33 for 1, 2, or 3 points respectively, should use subpal 0 (the same as the player). and should be lined up to the nametable grid, 8px apart from each other.

Also, by having the energy bar segmented like this, we could still bring in some kind of multiplier/effect on score from it if we so wanted to.

Energy bar code keeps track of old value; we need to reset this old value between runs.

Add sleeping state and animation

People are already skipping "Controls" anyway. Let's go with:

• Start, Options
• Help, Credits

Up button should instantly drop piece instead of just moving it faster

By M-Tee:

Implementation:

Rainfalling:
Metasprite RainShadowA should be displayed at the fruit spawning location (shown in the preview in red).
The raindrop should spawn and start falling from the top of screen.
The raindrop's TileID is $B1. Its horizontal position, in relation to its cell is indicated in the first attached image. (Red is the RainShadow metasprite)

If possible, I'd love for the falling rate to start slow, but increase with each passing frame. (I tested +1 with every frame, i.e., 1 pixel lower, 2 pixels lower the next frame, 3 pixels lower the next one and it seemed too slow. I also tested +2 every frame, and it felt too fast. Maybe you can come up something better/more elegant. We have to be careful about overshooting its destination though, I think.

Anyway, when the raindrop is within... I dunno, 48-ish(*) pixels of its shadow, change the randrop tile ID to $B2 and the RainShadow metasprite to RainShadowB.

Maybe choose this number based on the rain's falling speed, so that if the fruit is spawned in the bottom-most row, RainshadowB is displayed for at least one frame.

Splash
When the raindrop would reach the shadow, stop displaying the raindrop, and play Splash1 through Splash17 metasprites, with a duration (I think) of 3 frames each. (that's the speed of the GIF at least)

Fruit Spawning
During animation frames Splash14 and Splash15, display FruitHigh metasprite as well.

Starting on frame Splash16, change to FruitLow, and begin whatever the normal rate of bobbing animation is from there.

Dunno if it's reeeally a bug, but we say "Press start" instead of "Press (some platform dependent button)"

Allow two players to control the game at once: in this mode, one of the players control the minotaur/unicorn while the other controls the blocks. Instead of selecting a proper mode, we just let both controls work for the same character.

When completing multiple lines at once, the board drops only one row, resulting in a floating island of blocks.

Otherwise high score is meaningless, they each have different difficulty levels.

Even with coroutines, at some point one call took more than 50k cycles

Ensure a fruit is placed somewhere random, even when the board is almost full. As of now the algorithm may give up early on the randomness.

Maybe if we're clever with the animation frames we can make the blocks jiggle when they fall after a line clearing

M-Tee:

I'm now using the word Charge to refer to the transition into the roll. Roll is what I plan on calling the move itself.

• When pressing either A or B buttons, and there is energy remaining:

  • Play the Charge1 and Charge 2 transition animation
  • Check the destination of the roll (i.e, if the player is at cell A, cell B is empty, but cell C is occupied by an obstacle (by a wall, block (or Miroh) , then cell B is the destination.
  • If cell B is occupied, the destination is the same as the departure point.

• Play the appropriate number of Roll frames.

  • If the destination is D, all 4 roll frames play.
  • If the desination is C, B, or A, then play 3, 2, or 1 frames respectively.
  • Each metasprite is positioned so that its origin point is the top-left of the cell listed in the spreadsheet image.

• Play either the Bounce or Landing animation

  • If the player traverses the full length of the roll (i.e., the destination is D), then, at the destination cell, display Charge 2 metasprite for 18 frames as a landing animation before reverting to idle.
  • If the destination is A, B, or C, then play the two-frame Impact animation followed by the 4-frame bounce animation, with the durations given.

• Update the Block if the obstacle had been a block

  • I'll write up these tileIDs and whatnot now.
    
    

(spreadsheet info is on the Scratchpad tab within the Miroh Reference sheet, btw)
https://docs.google.com/spreadsheets/d/1y3Wj9RCPxEcwti-aSnyKvCnHKhh8RiEyY9B8nBxoJR4/edit#gid=81873905
(these metasprites, btw)

Replace old music with Raftronaut's new ftm

Player position must be fixed within OAM - then we need to change each botom sprite priority flag depending on vertical position and presence of nearby walls. After the player comes the fruits (max 2), then the piece, which must be shuffled on a block basis. Below the piece there will be a shadow, also shuffled.

Generate preview pieces using 4x4 blocks instead of 8x8.

Currently the maze is regenerated every time