Did a bunch more work on the clone loops and their trails.
Clones get their own trails and both the particles and the trail itself fade out.
Still some niggles. The start of the loop sometimes gets an ugly little knot like the one the topmost clone is approaching. Also you can see the error in that clone is quite high. It’s old trail is off by a handful of pixels in just one iteration.
I’m leaving that as-is for now.
Let’s work on buffs.
Which key to use to activate the buff? Well, here are the Risk of Rain 2 controls…
Tab - info Space - Jump E - interact Q - equipment Ctrl - toggle sprint Shift - utility skill R - special skill
I’ll use Q for now. Space will probably be a dash.
Now. The player and player clone will have a BuffZone component. It’ll have an Area2D. When another player or clone enters the area, call that character’s method to add a buff. When a body leaves the area, call that character’s method to remove the buff (the character should start a short timer to remove it).
I’m giving buffs IDs to prevent double buffing.
I’ll need a Buff Resource as well to hold the actual information about what the buff does. The character can apply these.
Right now Player and PlayerClone retrieve necessary values from PlayerStats. Can I add buffs there? I have a comment in that class explicitly telling myself not to, lol.
Pro: it’s already storing upgrades. Con: I don’t want clones to inherit the buffs directly from the player. Pro: it can (continue to) be single source of truth for getting all player stats.
I think that note from my former self was because I was storing the values from the PlayerState when the Player or Clone was instantiated. That is no longer the case so I can safely remove it. I’ll add a method to clear the buffs.
Huh. Really, what’s the difference between a Buff resource and an Upgrade resource? I can use the same class but store it differently and I think that’ll be okay.
Oh right. Countdown timer. That’s a pretty big difference. It would definitely be nice if I can call PlayerStats.add_buff(...) then when the buff has expired it’ll remove itself and the stats will automagically update.
…
Another interesting tidbit.
Gun cooldowns and equipment cooldowns need to behave differently, I think.
For gun cooldowns, the primary fire button will be held down and we just want to shoot the gun whenever possible.
For the equipment cooldown we just want to trigger it at the same moment (relative to the loop start) that it was triggered the first time. So if the player spams the equipment button a bunch of times before the cooldown is up, then closes the loop it should never go off. I don’t think I’ll have a buff that reduces the cooldown for equipment use… because equipment use is more about having it trigger at the correct time, right?
I guess that’s a question for playtesting. I’ll implement it the way that I’m thinking—the way that’s intuitive for me—first, and then we’ll see.
