BRENNAN SULLIVAN

TEAM LEAD

PROGRAMMER

A Long Journey

Hello, I'm Brennan Sullivan. I've had a bit of a long journey to bring me here, and I'm certainly not done with it. This team has great potential to grow even more, and I was so grateful for the chance to work with and lead them. I am very proud of everything we have been able to accomplish.

I was one of the two main programmers for this project, and we certainly had our work cut out for us. We knew going in that creating a game like this was going to be a big undertaking with only two programmers. We had to decide pretty early on whether or not to create a multiplayer game or code a balanced AI opponent. As hard as net code was going to be, we decided we would be able to make the game more to our vision by making it multiplayer.

Player Interaction

While Jacob Coleman tackled creating the core systems of nodes, map generation, score-keeping, and syncing systems, I was in charge of creating the systems the player would use to interact with and play the game. This job had me working closely with our UI designer, Tristan Vetra, to decide how and in what way we wanted to display different information. Turns out, there is a lot of information in a resource management game.

Player

Probably my biggest undertaking was the player itself. This would end up being a hub for all kinds of different pieces of information and communication in the background of the game. Jacob and I would end up having to write a lot of code into this. This was the script where settlements, units, and node selection would happen. Score and resource tracking would also be kept here. It would control and update most parts of the UI. Many other scripts would end up having to reference back the the player for information as they we instantiated in. I think one of our biggest hurdles with the player class was switching it from something that would issue commands based on input from a human or AI, to something that was completely designed for human interaction and synced properly across all the different clients. We also had issues with making the player only cast physical raycasts when we wanted it to.

Camera

The camera system was redone fairly late into the project by Chapin Reil when we decided to switch over to Cinemachine Virtual Cameras. In the beginning of the project I set up the camera, methods, and controls, for moving it. Not all of these methods stayed to the final version of the game, but my scripting was what Chapin transferred to the new Cinemachine cameras when we switched to that.

Settlements

The settlements didn't end up being too bad to get set up, especially in comparison to the units. We had some trouble in the beginning getting them synced properly between clients, but once that was done, settlements became fairly simple. They are a container for buildings and they gather resources from each tile around them when asked at the start of a player's turn. These resources are then altered based on the buildings present in the settlement. They select the correct model for their upgrade tier and color, and they also carry out functions of buildings, like the Village, Town Hall, and City Center, when told to do so.

Units

Units ended up being a can of worms when it came to getting them synced via networking. The movement of the units had to be refactored to account for the layout of the node system. After resolving these issues however, I was pretty easily able to set them up to use the correct models and move according to the rules of play.

We are hoping to include an update with three more unit types in the future, but we didn't have time to include, test, and balance them in the current release.

Buildings

Buildings were really just a set of scriptable object that were set up and specified based on what we wanted each building to accomplish. This information did not end up getting used for everything I intended because much of the building information was stored in the research tree. These lists of objects were still needed for the functions within settlement to check for the presence of different buildings and to use that information to set up the building icons.

Building/ Unit UI Interface

The unit and building UI functions were one of my most successful and proudest parts of the game. I was very happy with how well the new class was able to be set up to properly display the information of units and buildings on the selected node. I was also very happy how well I was able to have the icons react properly to different actions, such as being selected or having their different actions used. Though I had a good time with this part, Tristan Vetra created the assets that made the UI.

I set up the functions and assembled all of the UI besides the score and chat panels. Jacob played a large part in creating the research tree.

Trade

One of the particular pieces of UI that needed revision was the trade panel. We had a few different issues we ran into with it where buttons could be clicked improperly, but overall it ended up working very well. Eventually we decided the design was confusing and overhauled it to the current form.

Sound Control

Jonathan was responsible for creating the amazing sounds and music in game. I, on the other hand, was the person who set up the sound control UI, the background scripts, and mixers to control the different sounds.

A side note, I also voiced the story narrator.

Tutorial

I did my best to implement a tutorial, but know from feedback that there are further optimizations that can be done. I hope to have more time to refine it in the future.

It uses a simple system of covering the screen with an invisible button, so that any click will bring the player to the next page of the tutorial. The different tutorial parts themselves are kept in a series of arrays that are activated when needed to display the correct panels.