Space Pirates Took My Pancreas gave me a lot of opportunities to flex my programming muscles, as it had me figuring out ways to efficiently move around a lot of data. I’ll go over an overview of what each sprint looked like for me and give my thoughts on the takeaways.
In Sprint 1, I actually completed some of the most important core gameplay features. This was a super productive sprint for me where I implemented the basic player data, the “clicker” button, and a template generator that eventually implemented them all. I got the UI working, as well as the save data. Ultimately I think that developing the critical elements right away was super important in the long run, and definitely gave me a lot of optimism at the start of the project.
In Sprint 2, I made a lot of important framework, and had some experiments with communication of development. I wrote all of the backend code for upgrades, which were something that definitely seemed super intimidating at first. I also made a class map for the various scripts being used. On one hand, I think it was nice to have, but I wonder if it would’ve been better to make sooner in development. On the other hand, we didn’t always know what our script structure was going to look like until we tackled the next problem. I think updating it as the project went along though would’ve been beneficial, especially in regards to the implementation of items.
Additionally, I had the generator template in the game, but I needed a way to communicate to my team members who were going to be using the template to add the rest of the generators. I decided to make a video tutorial as a demonstration. For this project, this was super successful, and my teammates both greatly appreciated it. While it was highly successful here, I wonder how well it would work at a larger studio. One element I kept in mind was to try to keep it short, and it was about 9 minutes long in total.
In Sprint 3, I focused entirely on the user-end of upgrades. That proved to be quite a bit more challenging than the data side. It involved a lot of communication between multiple different scripts, including the buttons, the button manager, and the upgrade manager. The buttons are a prefab that get instantiated with a certain upgrade, and on click, tell the button manager that they were clicked. The button manager checks what upgrade they were, and passes it to the upgrade manager. The upgrade manager checks if the player has enough money against the price for that upgrade, and if so, buys the upgrade and removes the button. This was a great example of how using multiple communicating managers made for coherent code.
Once it was working, I input all the data for the rest of the upgrades. In one foul swoop, I got all the planned upgrades implemented. This sprint was spent hard focusing on one large task.
During the middle Sprints of 4 and 5 I definitely felt like we were in a slump and didn’t have as much direction. I worked on a couple assorted tasks, including a few new upgrades, but as far as I was aware items weren’t making progress. The more complex upgrades required some special functions, which required some testing, but didn’t change much of the framework.
Around the start of Sprint 6 I decided that the three things we needed for the game to be finished were: getting the mobile UI scaling working, getting the art assets in the game, and getting the item system implemented. So in sprint 6, I focused on getting the UI scaling working. I also worked on some tie-in elements with items, such as upgrades that increase the discovery chance, and having the generator manager (which runs the game clock) pass to the item manager what item to discover.
By Sprint 7, just about all the programming tasks were complete, so I was tasked with some polish features, such as implementing an “are you sure?” button after the “wipe save” button is pressed.
Overall, looking back at this summary of the project, I can tell that most of my work was during sprints 2 and 3. I’m proud of the way my plans for the game’s infrastructure panned out in those elements. I think that things could have turned out better in the later sprints if I stepped forwards more with a plan for how items should be implemented. Perhaps taking more initiative to get documentation going for the more complicated parts of code (ie, a base for the items) would have helped avoid the confusion that occurred towards the end of the project.
