Technical Architecture - Game Programming Quirks

Hey Skaters! This is the second entry in our series of devlogs that take a deep dive into several aspects of Beat Skater’s development. In case you missed our last devlog, which discussed the game’s inspirational origins and the Game Director’s long term goals for Beat Skater, that can be found here. For this devlog our Programmer, Carter Costes, will be giving a brief overview on how development goes on a day-to-day basis as a full programmer in addition to discussing some of the unique code structuring methods that can lead to success when programming games. As a disclaimer beforehand, this discussion can get pretty technical with some specific terminology.

“Hey Skaters, my name is Carter Costes. I wear a lot of different metaphorical hats on the team but for this you can refer to me as the programmer. I’m here today to very excitedly give a brief overview of what exactly daily game development looks like for me and the specific, quirky methods I use when coding that result in successful/high quality code in a game environment. Well, the excitement wasn’t required but I’m more than happy to give it! Game development is a complicated casserole of skill sets, ideas, and technical achievements that spans over a long amount of time. Everywhere that game development happens, the formula on how to develop a game can vary greatly with examples of success from each method. This results from the modernity at which the field started, being only about 40ish years old in fact(which is easy to forget given its widespread cultural popularity). Keeping this all in mind, this is how I currently do game programming as a new developer to the industry. 

There’s plenty of lists, targets to reach, designs, art, and random scribbled down ideas but the magic all truly starts for me at this screen. If you’re a developer reading this, you’ll almost certainly recognize that this is the Unity game engine. Once this screen opens, the activity in development(henceforth referred to as “dev vibe”) switches from design to implementation. At this point, I’ll have a list of features that need to be implemented, bugs that need to be fixed, or a list of ideas that need to be prototyped. As an example, let’s go back a bit to when the challenge system was implemented. 

So, I look at my list of features to implement and at the top is a weekly/daily challenge system. That task comes with an accompanying document that details the criteria by which the system will be made. This includes, but is not limited to, names, descriptions, rewards, information that players need to see, all possible interactions that players will have with this system, ect. Before doing any coding or manipulating any objects in the editor, I’ll map out (on a piece of paper) every currently existing piece of code that this new feature will need to interact with and why. This is a relatively brief, but hugely significant step as programming in a game development environment requires significantly more cross-script communication and data passing than traditional software development. Connections between scripts should generally be as minimized as possible, but is an inevitability in the space so knowing and documenting where everything connects is MASSIVE in creating a successful long term code foundation. Looking at this example, the other systems being interacted with are: 

Main Menu System - (Claim/See challenges)

Player Save Data System - (Store challenge-related data)

Trick System - (Trigger challenge criteria)

Rhythm System - (Trigger challenge criteria)

Combo System - (Trigger challenge criteria)

Run Progress System - (Trigger challenge criteria)

Once these connections are established, I break down the feature into a hierarchy of scripts/objects which has a varying complexity on a feature-by-feature basis. The challenge system was pretty complex, as it touched a large amount of existing systems and would definitely be manipulating data objects, so it was broken up into the structure of:

Once the hierarchy is established, I then go in and detail all the data that each script will need to hold or access, and the functionality that each piece hopes to achieve. I won’t detail each script in this system, but the layout for how the challenge manager should roughly function is to the left. This narrowing continues until individual functions and individual pieces of held data are reached. 

For those who are technically savvy or experienced, the methodology behind this might be familiar, as starting from the macro level when programming and narrowing as much as possible until you’re in a single function in a single script is widely taught, often being proposed with the alternative of micro level programming. For the context of game programming, I’d say the macro approach is almost a necessity for anyone working in a large system. As mentioned before, the communication that happens across multiple systems in the game warrants an understanding of the larger game structure for implementation.”

Carter Costes

Game Programmer

Thanks for that Carter! That’s all we had planned for this devlog, but come back in two weeks for a brief dive into the evolution of Beat Skater’s art style throughout development and beyond! Please leave any questions or comments you have for Carter or the team overall below and we’ll respond! To keep updated on Beat Skater, make sure to follow our Twitter and Instagram. If you’re interested in trying the game, it can be downloaded for free on the Google Play Store or the Apple App Store. Thank you for the time and playing!