470 Sprint 4

 Well, items are now almost fleshed out. Every aspect of it infuriates me, but it performs every task required by Robert within the GDD to near-exact specifications. I feel like I coded it like an absolute ape, and it's something that I'm going to fix up in time. As of right now, they work as such:

Items are represented by pickups on the ground, which, when interacted with by the player, spawn an instance of the inventory item which contains its viewmodel, the effects, and what to do with it inside the player inventory and attached to the player as a parent. The items as they exist in the players inventory can be dropped, spawning a pickup, used, which depletes their quantity and removes them from the inventory, or switched between, which replaces one item with another. 

I was genuinely beside myself when I got the inventory, viewmodel, and everything to update and be able to drop the trap without any bizarre circumstances. This broke after we migrated prefabs.

 It's a neat system held together by toothpicks and glue. If I could tell you how any of it worked in confidence I'd be lying. I ended up doing the one thing I never, ever, wanted to do over the course of this sprint, which was just writing things line by line until they accomplished the card objectives and then shrugging it off with zero regard for architecture. I got what I needed to get done finished, but I understand that it comes with a heavy amount of infrastructure debt I'll have to pay at some point. In general, I just don't like it. Too much of it relies on hooking up a bunch of prefabs in an extremely precise way that I know for an absolute fact that I'm not going to remember because I forgot the second I got it working. 

This in specific is a complete abomination. This is an inventory instance that creates a secondary instance of a trap with a special material attached that lets the player know when it's colliding and prevents the player from placing it while colliding. It sucks.

 But,  I did end up getting my deliverables in. We have a working inventory system, we have traps that do the things you expect them to do, and architecture to create more traps. The items are 'modular' in the sense that I could probably create template prefabs for them if I had half a clue, but it's proving to be messy already. One of the most annoying things about this sprint was that just after it, I had been tearing my hair out trying to find a solution for what I felt was an obviously unacceptable amount of bloat. I knew there was a way to do what I had wanted, but I assumed it came from some arcane object oriented programming principle that I was unable to get working in Unity. Turns out I was half right; this was unfortunately one of those things that was so obvious that it made any google search a complete pain because for everyone who knew it required no documentation. Why I had forgotten about interfaces until I was embarrassed enough by Robert to develop a system for interactable objects is beyond me. 

 

 Throwables required diving even deeper into the Input System, it was completely disgusting what I had to do, but I was proud of how much I could modify it. Now we have projectiles that stick to surfaces when thrown or launched, reminding me of arrows from games like Oblivion.

 So, for now, what we have is a small script that simply confirms an object is interactable combined with a script that performs an action upon that interaction. What initially required an absolutely disgusting coupling of scripts in order to work was solved within a half-empty function. I believe I sounded almost in complete disbelief as I was explaining it to Robert, who seemed to want to know if there was anything else to it. I had nothing I could say other than "No, that's it."

 The path I have to take to fix the inventory system is obvious, and in an upcoming sprint where I have to juggle it with weapons and other things, it's going to be downright necessary. I'll see how many cards I can complete before I'm finally irritated enough to implement such a fix and stall development time in order to deal with how dissatisfied I am with the codebase.