Demonstration of Style

 What a bummer this sprint was! I wish I ended up doing more. I got off to a sluggish start, and that's entirely on me. What I did end up doing was something I was proud of, fundamentally. I love the idea of programming inventory systems. Really, the sort of logic and database management it requires is some of my favorite problems to work through.  Additionally, I finally prototyped traps and all that's left is for them to be deployable. I say 'all that's left' like it's an easy thing to do, and I fear that I put myself into kind of a bad spot with my programming. I know for a fact that the instances I made have to be deployable from the character's inventory, and along with that, there has to be an instance of pickups for them that can be added and dropped from the inventory with no major issue. There's a lot of moving parts for a simple inventory system and I fear that I'm overcomplicating it.      Traps as they work right now; enemies approach a t...

 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 ne...

   This sprint was a strange one; I had to do my absolute best to work out a system for enemies and an attack system at the last minute. I felt like I could've done better in sections; you can see in the gifs below that there's two major issues with enemy movement. Knockback on enemies looks ugly; it's just a backwards motion. I didn't want to use the Unity physics system because it sucks and encourages everything around it to break. However, for purely aesthetic purposes, it may be what I have to use. Transform.Translate just doesn't cut it. Enemy movement in general is something I wish I could've improved. As of right now, it's just so boring. They fall into a single file line, swarm into the nearest target, and then move onto the next one. While I could perhaps cope with the look of it resembling a pack of locusts descending on a field, I just can't sit with it in this state. I hope I get an opportunity to return to it in time to make it look better. ...

 This sprint was a successful first step, but I feel like we were limited by two distinct things.  One is that we didn't necessarily have a prepared backlog. This lead to us being assigned a minimum of work to do, and it took a while to get some wider context on the things we had to do. Second, a significant amount of our group got sick and it kind of limited the things we could really do. There was a huge pause on the programming side especially as I was left to focus mostly on enemy spawners. This was kind of a bummer, but I made some progress on it and I was proud of my coding. I've had a lot of trouble in the past with decoupling my code. It's just too easy for me to take shortcuts and create an architectural mess that just doesn't work out at all longer term. This time, I really took the time to learn from my mistakes and I worked to create an event-based system for spawning. That way, things can be tested without necessarily having everything in scene, and I doubl...