Introducing the Lead Programmer

Hello everyone!  My name is Kyle Bolton, and I'm currently a senior at SCAD-Atlanta.  I'm helping Angelica and David as the lead programmer and assistant designer for Bala.

Technically speaking, I'm not a part of the class that Bala is being developed for.  You can think of me as an independent contractor, so to speak.  Last year, I worked on Prisma for SCAD-Atlanta's senior studio, which is where I cut my teeth on game programming and Unity development.

Because of that experience, I will be the driving force behind Bala's programming and level design. For this blog post, I'll discuss my methodology in building the "framework" for Bala's codebase.

Managing a Team

In the past, I've only ever worked with, at most, one other programmer.  For Bala, I will be working with two:  Khoa Nguyen and Daniel Jones.  Theoretically, this means that Bala's programmers will be able to move swiftly; however, there is also the risk of the project's codebase becoming bloated or inconsistent.  As lead programer, my goal is to ensure that all three programmers pattern their code in a similar manner.

For this to happen, I had to do two things:

1. Write a programming style guide.
2. Set up a rudimentary framework for programmers to work with.

The Style Savvy Programming Guide

For those not familiar, a programming style guide is an instructional document that is designed to encourage consistent code across a team of diverse individuals.  Much like traditional writing, each programmer has their personal style.  There's nothing inherently wrong with this; when one is working on a solo project they should author their code in a manner that works best for them.

However, for collaborative efforts to work well a standard should be set.  Everything from white space, naming conventions, the placement of curly braces, and more need to be defined by the lead.  This ensures that the project's codebase is immediately readable for every programmer on the team, which makes debugging issues a process of logic instead of syntax.

"Framework," for Lack of a Better Word

After setting up the style guide, my next task was to set up a framework of methods and members for the rest of the team to work with.  I quickly realized that giving the team assignments without any sort of example was going to lead to a disjointed amalgamation of different implementation methods.  For this process to proceed smoothly, anything that is remotely similar needs to behave in a similar method.

To solve this problem, I began implementing features on my own and setting up a framework that predominately relies on a common object-oriented programming trope:  polymorphism, or the occurrence of something in several different forms.

Wait...Polywhatism?

Polymorphism.  Basically, I define an action, and a programmer can make that action have different consequences depending on the feature being implemented.  A perfect example of this is how we are handling bullets:

Every bullet must be able to do at least one thing:  collide with colliders and trigger volumes, and send messages to said colliders and trigger volumes.  After that, a bullet can be pretty much whatever the designers want.

While this may be very confusing to non-technical types, the point I'm making here is that the action - a bullet colliding with something - is written once, and only once.  Bala's three programmers should not waste time writing three different collision methods.  Instead, they should be focused on the consequence - the logic that occurs once an action has initiated.

What's the Point?

As I said earlier, the point to all of this is I want to allow the programming team to be focused on implementing gameplay.  So far, this process seems to be working fairly well, as I was able to put together a fairly extensive demo that featured four different bullet types and four different enemy types.

Moving forward, I'm going to try to give Khoa and Daniel more freedom so that I can focus on design.  The next time overlord Angelica deems it necessary for me to ramble, I'll talk a bit more about the design philosophy behind Bala (which is still being ironed out).

Until then, look forward to next week's blog post, in which David will show the concept art he has been working on.