CAGD 377 Sprint 1

 I was out of town for the weekend, and with our delayed start for Sprint 1, I really had to hit the ground running. Despite this, I still pulled through and completed all my tasks for the sprint.

As the main programmer, most of what I did during the sprint was setting up the foundations for how the code will look going forwards. I discussed with our lead and decided that the best way forward would be to split up the main sections of the game into three main scripts: the PlayerManager, the ShopManger, and the GeneratorManager. 

The PlayerManager stores all of the player’s data in one script, so it’s easy to grab it and save it to a scriptable object. The ShopManager deals with purchasing new generators—checking the player has enough money, updating costs, and completing purchases. The GeneratorManager does all the calculations for money generated per second. I figured things could get laggy if this wasn’t standardized, so I made sure to keep it all in one place in a few functions to keep it under control.

To demonstrate their functionality, I got everything set up with the first generator in the game—the Spambots—and hooked it up to the appropriate scripts. As of the first sprint, the Spambots in their base form are already fully functional, and all it takes for the rest of the buildings to be in the game is a few copy+pastes. The basic data for the generators is stored in scriptable objects that get read by the shop and generator managers, so once that data is put in place and the UI is set up, we can already have all the generators in the game.

In my last game development project, I was a lead, so I had to think about how we were going to organize the production of all of the game’s features. This time I’m a programmer, so I’m given the features to create, and instead have to figure out the best way to organize the technical functionality of those features. 

One challenge for me is that most of my programming assignments up to this point were solo, so I could just code and organize it in a way that made sense to me. Of course, having good organization would be helpful and commenting my code to explain it to the graders was relevant, but I was still mostly held to the standard of “does it work?” This time though, I have to worry about my code and organization structure being understandable to the other members of my team. This is especially difficult since we’re making an idle game that’s mostly just a bunch of math—since my last project was a 3D platformer, it was easier to communicate what we were going for with the design. Now we’ve got spreadsheets.

Coming up next is going to be working on upgrades and items, and while I had a good idea of how to easily implement the generators, this might be a bit more of a challenge. I may have to do some research about good ways to implement upgrade and item systems, however I already have some ideas.

For the amount of generators owned, I made an array that abstracts all that data so it can be easily stored in a save file, and then I have a function in the player manager that knows how to read it. I figure that for upgrades I can do something similar, once I know how many should be in the game I can just make an array with a 1 or a 0 in each spot to mark if that upgrade is owned, and then number each upgrade with which spot it is in the list. While it’s an abstract system, it’s not very data intensive, and it can be explained to the other coders with comments.

On the other hand, the reading function for this may be more complicated since it’ll have to check every single number in the array. However, that may just be a product of there being a lot of upgrades—the only other way to do that would probably be a list of what upgrades are owned, and that would require a new scriptable object. However, if a made a scriptableObject “Upgrade” with a name, reference to what it should add to, and a multiplier, that could be more efficient in a list and easier for programmers to read and edit.