CAGD 377 Sprint 6

At the start of Sprint 6, I made a list of the three most important tasks that needed to be done for the game to be ready: getting the aspect ratio nailed down, getting items implemented, and getting the art assets in the game.

So my first exploit was getting the UI scaling to work. The task was pretty easy, but required a search for what to do. I set Unity to the Samsung phone simulator and reorganized the UI, scaling everything appropriately and making room for the art assets to be included. After some tinkering with the camera, I got the scale to change properly, and did some testing.

With the UI scaling locked in, I moved to finishing up items. While I had done some work with items in the main scene, and our lead had done some work with items in the inventory scene, we were yet to tie the two together.

First, that required some bug fixing. I added a quick fix to ensure that save data was retained on scene transfer, and a hooking function to the scam button to make sure it can always attach to the PlayerManager after the scene has been unloaded and loaded again.

Now that we had a library of our items, I gave the GeneratorManager a reference to it so it knows what the items are. That way, after it activates discovering an item, it can decide what the item will be. Based on the generator type, it will pull one from one of four pools of four items each.

One major challenge is that the item discovery and the item management happen in different scenes, which makes it difficult for the scripts to communicate with each other. To solve this problem, and solve the other question of how to save the game, both scripts write to and read from the save file. So, the GeneratorManager checks if there’s space to add another item to the storage in the save data, and in the inventory scene, the ItemManager checks what items are in the save data and loads them up. 

One other addition I made to the code was a variable that factors into the player’s income that can be affected by items. The main challenge with this is that the UI has a copy of the calculations for UI display purposes, so for optimization and organization, I merged them into one float-returning function that other scripts can use to get a value for the income per second.

Besides those important tasks, we also realized an issue with the gameplay: after the first few minutes, there’s no reason for the player to interact with the scam button. To fix this, my last task was to add three new upgrades to the game that increase the amount of money earned when the player clicks the scam button.

Each upgrade makes the money earned get increased by 1%, 2%, then 3% of the player’s income. This makes it somewhat effective at all stages of the game, and increases how effective it is by the number of upgrades the player has. These upgrades also don’t have any exterior thresholds, which means they’re always there as a goal for the player to get. The only requirement is owning one building, which seems like a good time for upgrades to be introduced to the player.

Since this was a new upgrade type, I had to make a new function to handle it, but it was as simple as giving the PlayerManager a new variable that factors into the “money earned on click” function.