Sprint 2: The Inventory is freaking me out

 I'm putting the GitHub bitching here before everything else so anyone with a pulse can ignore it:

We had our first major github pile-on over the course of this sprint and most of it was completely avoidable. In the very least, we understood what went wrong, and the first time it happened, we were able to merge in a way that got everyone's up to date work into merge. The second time, people had to re-upload things which sucked. This was caused by people not pulling changes from merge into their projects at the start, or not putting their changes into origin and causing later problems.  Now that we know better, I'm stressing the need for people to explain what they're working on and when they've pushed whenever it's a file with heavy traffic. Whenever we were all working on the UI layout, toes were stepped on, and now that we're approaching a deliverable, we can't have that happen again.


Otherwise, this sprint was very acceptable; we did slightly go underneath what we did for sprint 1, but this was expected; everyone was entirely devoted to coding tasks, including designers who were mostly interested in modeling tasks. There was a lot of time spent blocked, and a lot of time spent asking for advice and clarification, but we still pulled through, and a fluctuation of only a couple points doesn't matter much.

For my personal work, I wish I did more. I allowed choice paralysis to completely screw over my workload for this sprint; I got so anxious over how to implement the inventory system that what I did put in fails to be impressive compared to other people's achievements this print. The information I found for grid inventories would have such wide-ranging implications for both object design and coding that it was hard to wrap my head around, and I came to the conclusion I would have to find another way of doing things that wasn't super complicated for the sake of an extremely strict inventory system. 

 

I had no idea what I was doing; so I thought it could be a 2D array in the base item template that we could instantiate cubes over to indicate inventory space and oh god I'm dry heaving thinking about it HELL no.

The grid inventory system feels unfeasible for this project; or at least it felt unfeasible for the sake of accomplishing within the realm of a two week sprint from zero experience. Additionally, when I thought about it more, it just didn't seem fun. It felt like too many rules and conditions for the inventory system in my head, and obsessing over the minutiae of what a player can't do over what a player can do is a recipe for failure. I decided to think looser, and Milo basically handed me a solution in the form of using raycasting to create a sticky board of inventory objects. Testing it mad eme realize how much more fun this would be over a grid inventory. Size and space still matters, but we're given so much more freedom in terms of object manipulation and what we can do with items in the inventory since we don't have to work off a strict grid. Additionally, expanding the inventory or shrinking it for playtesting is as simple as adjusting the scale. It also created an extremely holistic method of identifying where an object was in space; simply by moving an item to a different tagged board, we could create different states and make different things happen to it. 

 

End result tests of the inventory system. I was massively impressed by how smooth it felt!

I also made an item discovery spreadsheet to track what the ideal timing and gameplay loop would be for items. The ideal is to have a player pick up an item once every couple of play sessions from the start and slowly ramp up, and I think I found a growth rate for item discovery per generator that makes that happen. We'll have to test it and actually see how fast players are accumulating generators, but it's exciting to see all of this come together. I'm proud of my group, and I'm proud of myself.