Implement the Power-up and Buff components to complete our Hits and Stats system.

These components are mostly for the passive items you can buy from the shop but could also be used to quickly give enemies different boosts, too. (The regular power ups could technically use these, too.)

Characters with a Power-up bar are able to use Buffs to boost/reduce their stats.

The Power Up Bar should:

• communicate with the UI and other components so stats may be adjusted and displayed

Buffs should:

• contain info for the Power Up Bar to use: icons/images, stat to change, amount to change, and a short description
• buffs that display in the store should also include price info

Just so I know....

• verify the contents of the export folders
• discover firsthand what the issue is w/ exported projects and this mode 😆

• cleanup the new engine/class notes I have
• review older dev notes and update them
• research any missing information/resources
• "lock" vault in read-only mode
• #36

I didn't notice until a quick test today... so now I'm not sure what broke.

(Automated tests would be great, huh? How do you do that for a double jump animation, though...)

Component that can be placed in the level or added as part of an enemy.

The spawner can:

• spawn blocks in a given area
• spawn blocks along a path
• set the color and "health" of a block
• determine how many blocks to spawn
• determine if blocks spawned on a path should move along the path or not
• bonus: spawn blocks at given time intervals

• step 1 - learn the basics
• step 2 - get some free sounds to use
• step 3 - add some effects (i'll make a list of things below)

Because it's where I got my start with sprite art and it'd be cool to have 'em.

I can make a clean collection of some of the moves rather than converting the whole sheet.

• Sonic
• Tails

Alternate controls for:

• Menus/UI
• Movement
• Actions (?)

• Move text files (place outside zip and as part of other credits files)
• update structure of pixel adventure
• remove unused kenney particle files.
• rename files and folders to match recommended style

I wish I added the assets folder to the .gitignore before I uploaded this but we're already here 😅

Add visual detail and any remaining functionality to our UI screens.

Best if completed after #12.

A stat gauge should:

• represent the stat it's listening to in the form of a bar

This is just for the logic side of things.

Task overview:

• Verify the paddle moves as expected and collisions are in place (the ball should ricochet off paddles, blocks, characters, and walls.)
• When the player deflects an enemy ball with their paddle, it is pacified
• When an enemy deflects the player's ball, it becomes dangerous
• The ball maintains its speed and super status during the "team switch"

Break items out into separate issues as needed.

For the enemy one: you may have to test with a that isn't attached to anything or wait until the enemies are upgraded. (Or fake it: put the paddle in front of the enemy while testing.)

Was removed from the lineup in favor of Booster Foods. If we have extra time, we could look into this again.

Adding this movement touches a couple areas:

• Levels: Need narrow lanes for wall jumping
• Player: new animations and logic (states, inputs, collision detections, etc...)

Things to add to or improve this aspect of the game. We might not need all of them, but they're generally pretty simple. These items don't exactly need it, but if I have time to look into custom tile data, I can.

• Coyote Time (cleaner jump mechanics)
• Checkpoints (restores balls if all of them get lost)
• Pass-thru platforms (fall down through one-way platforms)
• Crumbling platforms
• Falling platforms
• Spikes and Fire
• Pits (Z-kill)
• Moving Platform

Physics-based:

• Blackhole
• Water
• Bounce Pad

There's a chance I'd have to implement the responses myself... thus blowing the size of this up...

Bonus:

• #24

We've got three enemy types (and might not be able to get to all of them.) These behaviors may also change depending on the sprite art we have available.

Flyguy

• zips between any two points in the air (can be dangerous idc - he doesn't either)
  • this might need pathfinding or I can hack something together...
• balls ricochet off him (deals damage)
• drops candy upon defeat
• poofs if you collide with him (but does not count as a defeat)

Chomper

• spawns in corridors, on stable/safe grounds
• sits around with mouth wide open for a while
• eats any balls that cross his open mouth
• mouth closed? balls ricochet off him (deals damage)
• drops coins upon defeat

Sword Guy (with Beef)

• spawns in arenas on stable/safe grounds
• 'parries' and fires the ball at random...
• balls ricochet off him (deals damage if it's not his paddle/sword)
  • can take a few hits
• drops LOTS of candy and coins upon defeat (no treasures rn)
• deals damage if he hits you with paddle or ball or self

It might have to do w/ the Area node (or not cuz I'm using the body_entered signal) but the audio doesn't play when the player picks up a collectible. It works for an enemy though.

Keep it as bare-bones as possible - anything that needs a state machine or features of it can just build on top of it.

• State Machine class
• State class

Setup the minimum features available for each type:

• wanders around their area
• attacks when player is near (If they have attack animations, some might just have idle/run/hit)
• receives damage when player jumps on head (or hit with something.)
• drops an item (candy a/o coins) when defeated

Visuals should be handled by each enemy type itself, so this can be a starter class to inherit.

There's an "upgrade" list in the docs.

Flyguy:

• can spawn with blocks around him
• when near a block spawner the player is messing with, it triggers blocks to respawn

Chomper:

• wanders around the corridor
• can chase balls or the player

Sword Guy:

• Chases the ball and the player
• parries/fires the ball with a little intelligence

IDK why I can't seem to consistently replicate the conditions in which this should work... but as someone on borrowed time, we'll have to research that some other day. The hours of googling and scrapping together ideas hasn't amounted to much. Most of the examples of interactions between two CharacterBody2D classes involve a projectile using move_and_collide. I imagine the same principles would apply, but they don't seem to.

Layers and Masks are also configured in what seems to be correct... so I'm at a loss.

For now: everything gets a hitbox. Because those have been consistent.

Need some skeleton scenes to start with. Might need some additional research. Start with mouse interaction for now.

Screens:

• Title (start, might have a credits button?)
• Main Menu (Play, Shop, Settings, Credits, Exit)
• Shop
• Settings (overlay or screen?)
• In-game HUD (coins, candy bar, "salad bar", ball status)
• Pause menu: pressing pause should freeze gameplay

Take everything, stuff it in the Word Doc, ensure the headings are correct, then hit export.

Should be easy but we you know how it goes--

• step 1 - learn the basics
• step 2 - get some more textures to use
• step 3 - add some effects (i'll make a list of things below)

🚨 Not sure what the difference between the sandbox where I prototyped the paddle behavior and this new file, but things don't work like they did.

Clicking to fire a ball doesn't send it away in the right direction at certain angles on the path. Rather than firing perpendicularly (which is how the marker is oriented and how it works in the sandbox) it might be affected by skew, like the bar sprite was. It could also be something else entirely, considering I managed to clean up sprite skewing a bit anyway...

Not sure how to go about debugging the marker yet, but we unfortunately don't have time to for this item. Leaving this as a "bonus" fix while I try something else out so we can finish this prototype.

See: #1 (comment)

The math doesn't seem to be mathing. (the divisions aren't quite correct.)

Tool mode runs constantly so it needs to be updated for interactivity. (Ghosts get left behind in the editor. Not good.)

The size says "large" but with all the building blocks done, it shouldn't be so bad. We just want to verify we have all the pieces and can put together the logic for an actual level. (With objectives for clearing and everything.)

"When the player's candy bar is full, they enter Sugar Rush mode (super)"

Update the game to implement new behaviors:

• when the player nabs a coin or coin bubble, it's added to their overall total for the game (when they complete the level)
• ❌ when the player nabs a power bubble, the next ball to be launched becomes super they become invincible (super)
• when the player picks up candy, their candy bar increases
• #33
• when a ball hits a block or character (of the opposite team), it deals its attack power as damage to the others health stat

For coin collecting: I can either leave a "level complete" toggle on while testing or wait until I've set that part up...

We need a game manager that will:

• transition between game states and their related scenes
• persist game data between scenes (coins, booster foods, etc.)
• save and load that game data (#2)

Implement the base of the Hitbox and Stat Gauge components.
"Medium" size as I think I might have to do some extra research or fiddling.

Here's what the hitbox should do:

• detect when its parent is hit
• send any information (collisions, damage, object IDs, whathaveyou) to other components. (mostly the stat gauge)

A stat gauge should:

Would be nice... but not required for the workshop since we won't have time to actually build in class. It'd be great to do more than just mention that part, though.

Because the paddle is BROKEN.

Despair not, though. Maybe a Gravity Shield will do the trick.... and be more interesting, too. The idea:

• press (shield key) to activate it; can either be toggled or a press-and-hold situation.
• if the ball is outside the shield when activated, it bounces off (reverse gravity maybe)
• if the ball is inside when activated, it can be captured

Visual changes to accompany the features of #4:

• Enemy balls are visually distinct from the player's
• super balls are visually distinct from the standard kind.
• balls destroyed on-screen also have some sort of visual indicator

Guess this is issue no. 2 now lol.

Bonus item but shouldn't be too difficult to implement with Godot's Resources. It's more like a nice-to-have for this sort of project - especially since there's a "store."

Move the working bits to a clean project file and record the steps for the handout.

• Project and Engine Settings
• Art assets, Project Structure
• basic Player setup
• basic (sandbox) level setup
  ❌ basic brick breaking mechanics (Affected by #27 so we're skipping this part.)