During the months of March, April and May 2019, I worked with three peers on a game that digitalized a board game we created before Christmas of last year. This assignment was unique as we were tasked with including networking within the game. This was the third of three assignments in the “Low-Level Programming” module in the Games Technology course at UWE.
After the assignment was set, the first objective was to write up the GDD and TDD for the project. The GDD was already done when developing the initial board game, but it was enhanced and improved to include changes and small additions we were planning to make for the digital version. There were plenty of constraints we discovered when making the physical board game that we knew we could easily fix with the game being digitalized, such as the abundance of resources that needed to be kept track of which could be done instantly with the computer. The TDD was written up as well so we would have documentation on how the game would be coded.
My initial task was to add the Market class, which fittingly enough was one of my ideas when creating the board game in the first place. The process was a simple one and only involved creating a function that would randomize a string between twelve values which could be called at the start of every turn, but it was good starter.
This game also required a class that would allow workers to be bought. There are two types of workers, so I chose to place them in two separate arrays that tracked the type of worker as well as how many of each the players had. Doing so this way would make the system flexible meaning more types of workers could be added if needed. A function that would add the Workers was done by allowing the cost of a worker and the worker type to be passed into the function. The function would then loop through every type of worker before it finds the worker type that was passed in, where it would then check if the player had enough money before buying the worker and doing all the appropriate money calculations.
While adding the workers was successful, each type has unique functionality that had to be programmed. The second type of worker, the artist, was relatively simple and only required adding 2 to an income value. The first type of worker, the Programmer, has similar functionality, but can add between 1-3 randomly. I added RNG by using the
I added foundations for classes that would keep track of and do calculations such as money, but decided to scrap these after deciding they would fit better in the Player class. Because of this, I helped set up synergy with the Player class by adding several getters and setters that would allow workers bought in the Workers class to appropriately alter values in the Player class.
Following from my work on the Workers class, I began adding functionality to the Powerups class. Powerups are similar to workers in the sense that they are brought, but are unique in that their usage can be toggled on and off with their usage then being done at the end of a player’s turn once they’ve reached their decisions. This was done by calling a function that passes in a value that represents the powerup on an array. Upon doing so, it will loop until this inputted value is found and use an array of booleans to set that same value to either true or false, whatever is the opposite of its current status. Additionally, if it’s setting a value to true, it will deduct currency from the player and give that currency back if they change their mind and deselect that powerup. This has the advantage of stopping players from buying more powerups than they can afford.
Integration with the rest of the game was done soon after. This involved adding the appropriate functions with the interface created so everything would be called at the right time. For example, the toggle for powerups would only be called when a powerup button is selected, that button value allowing the function to understand what powerup to toggle.
The game was approaching the latter stages as this point and my work involved fixing bugs and adding minor, but important features. For example, the calculations needed to add the player’s earned money to the bank were added, in addition to checks that would allow the player to earn awards which are required to beat the game.
As a post-mortem, digitalizing the board game was a process that went well, but did have its fair share of problems along the way.
One thing I have learned is the importance of keeping code quality consistent between all every member of the team and keeping them up to date at all times with what you are doing. This is importance so they can begin preparing for your own code, which was especially important for me as most of my contributions were a lot of background work and calculations. There were a case where a member of the team wrote up code that served the same purpose as code I had already written because I didn’t communicate properly that I had added that feature.