namelessWrench

The Only Rotten Dollhart Webring

A hideous fruit, disgracing itself.

Allo-Aro



eniko
@eniko

then click read more!


so an "item" in your inventory is just a named enum member, because then i can save/load the inventory by just casting those to/from int. then each enum maps to an InventoryItemProps instance which knows what sprite it uses and animates the sprite, and also has an OnUse delegate that takes a player and returns bool whether it was successful or not. the jank part is that's the same method signature as power up entities use when the player touches em so when i instantiate the item props i create an instance of the power up, then pass that power up's function to the props like

new PowerUpAir(0, null, Vector2.Zero).PickedUp

then when i use an item in the inventory, it calls a function on the current game mode and passes the item props to that. right now only the overworld mode has that implemented. the overworld mode has a clone of the player object that's used for the player preview (so you can see what power up you have like the super mario in the top left of the screen of SMW), and instead of applying the fake power up to the actual player object (which is on the map) it applies it to the clone instead. this works because the player state is global (for historical reasons) which is very bad but also i am never going to change it

except now the player's power up routine spawns a power up cloud particle in a random spot on the map so to fix that every frame i find out what the in-world position would be to match up with the player clone preview in the UI so that when the clone's power up routine spawns the particle it'll spawn it in the right area to overlay the GUI

except! the GUI is rendered after the world and its particles so i took the particles out of that render pass and gave them their own render pass so that the power up particle renders over the player preview window

its horrible

oh and all of this returns true if the player clone could actually utilize the power up (so if there's no change it returns false) so that eventually when everything's done the inventory knows whether or not to remove the power up from the player's inventory


You must log in to comment.

in reply to @eniko's post:

👍 and that's its own kind of perfect. good that you have the guts to push it even if it looks bad. that's something i struggle with immensely to the point of not being able to do it unless heavily pressured by external commitments, and sometimes, not even that 😅

so while in a level, you use inventory items from the overworld? or the overworld is running the background during the level?

Pretty fantastic, I love how all our attempts to consolidate concerns and modularize ultimately just lead us to huge duct tape pieces and spinning plates when things need to talk to each other 😅 Next game every piece of game data is going to be one global struct.

Remember: It's not horrible if it works!

oh the actual power ups you wind up using from the inventory don't live anywhere, really. the closest is that they live inside the item definition, but the item definition doesn't keep a reference to the instance, only the one function it needs, so they're really just kind of mostly-disembodied items floating in nothingness with a peripheral tendril extending out to do the powering up.

so if you're inside a level and power up from the inventory, you're still using the same disembodied ghost power up, although at least this time it gets applied directly to the entity you're actually inhabiting as the player rather than some weird clone that only exists to satisfy GUI requirements >_>

ah yeah its just that i haven't implemented it for the in-game mode yet. theoretically any mode could have its own implementation for "hey the inventory would like to use this item on something player shaped"

normally you'd consolidate that into a single function but because of how the overworld works i couldn't do that