The first challenge this sprint was one of communication: I needed to make a guide for my teammates on how to implement the rest of the generators using the tools I created. Since the hard part was mainly connecting objects together in the Unity editor, I figured communication would be the most straightforward with a video tutorial, lasting only 9 minutes. With this, my teammates could finish the rest of the generators so I could focus on other features.
And for this sprint, that was the upgrades. I programmed the framework for basically the entire upgrade system. Previously my main two ideas were an array of id values to store the data of which upgrades were owned, and a set of upgrade ScriptableObjects that contain all the relevant information for the upgrade objects.
Ultimately I realized that the best solution was to marry these ideas together: the saveData stores an array of integers that are 1 or 0 to mark if an upgrade is owned or unowned, and each upgrade is a scriptable object with one of its datum being an id number that tells the upgradeManager which int in the array corresponds to it. So basically, the upgradeManager reads the saveData, if there’s a 1 at a certain array index, it checks the upgrades for the one with that id number, and turns it on.
One other challenge to note was whether to make the upgrades additive or multiplicative: ie, should a 2x multiplier and then 4x result in 6x, or 8x? With my current system, multiplicative was far easier, so that’s what we decided to go with (also because it gives more power to the player).
Definitely my biggest misstep with this system was organizing upgrades into “upgrade sets”, since some upgrades come in a linear progression: ie, Tier 1, Tier 2, Tier 3 of a certain upgrade. Doing this ensures that players can’t get the tier 2 upgrade before tier 1, but adds a lot of complexity and noise to the code, since now we’re sorting through an array of arrays.
A better way to have achieved the same goal–which I’ll probably switch to as soon as I can–is for each upgrade to have a “prerequisite id” integer that points to the upgrade that is required as a prerequisite, if one exists.
Making this system was the majority of my work for the sprint, but it’s a super important system, and with it working, that’s two of our big three features done (generators, upgrades, and items). My next challenge is getting the UI for upgrades working, since I’ll need a queue of upgrades available for purchase on the left side of the screen.
I haven’t worked with UI elements as much so this will be more of a challenge for me, but I don’t think it should be too hard, since we’d just need a list of upgrades available for purchase, and once one has its requirements met, it should be added to the list and go to the front of the queue.
One other change I discussed with the lead was whether we’re sticking with 2D UI or if we want to make 3D buttons. If we eventually go for 3D, that may substantially change how this system would work, so maybe the next step is testing out clickable 3D buttons.
As I see it, the biggest challenge is going to be a concise and readable way for players to see upgrade descriptions–adding a string for them to the upgrade data is easy, but finding a spot for it to display in the ui could be challenging. We can cross that bridge when we get to it though.
Overall working with data engineering (is that an appropriate term? For finding the most efficient way to store and retrieve data) has been a satisfying experience for me.
No comments:
Post a Comment