The Redcoat App: Part 1

This is Part 1 of a series of posts I intend to write, in which I plan, and ultimately comment on, an educational game about British Light Infantry in the American Revolution.

When I started learning to code, I began with Harvard’s CS50 online course. Due to Covid, there was a big push by the Ivy League to make online classes free so people recently out of work could do something productive. For the first project in that class, I had to use Scratch to create a basic game. A quick aside about me: I am a Revolutionary War reenactor who portrays a soldier of the Light Company of the British 4th “King’s Own” Regiment of Foot. I care deeply about the educational aspect of that hobby, and teaching people about the 18th century British Army is a passion of mine. So, I decided my game would allow a user to “command” a company of British Light Infantry, issuing orders and learning about how the British Lights fought.

The game was a mess, to be expected of my first project, but I plan on rewriting it in a more “mature” language and eventually deploying it to my reenacting group’s website. For now, I want to talk through, in pseudocode, how that might be done.

Since Light Infantry was relatively independent, the building block for the company must be the soldier. Each soldier of the company will have certain methods/functions in common, and it makes sense to write the app in an Object Oriented language to allow inheritance. Every “soldier” will need to know how to load and fire their musket, how to turn left or right, and how to take a step. In Scratch, each of these behaviors meant adjusting or moving the sprite, or causing the sprite to display words to provide a visual cue as to their status. By making a Soldier parent class, the soldier instances (each sprite) can inherit these shared behaviors. Child classes will allow more specific behaviors for each individual, however.

The “company” as a whole, which is to say around 30–40 sprites if we are going for a 1 to 1 scale with a historical company, needs certain coordinated behaviors. In my scratch implementation, there was a “sergeant” sprite which, upon certain user inputs, issued “orders”, broadcasts which the other sprites picked up and responded to. This may not be the most efficient code, however, and came from my desire to emulate the actual “chain of command” of a company. It might be more effective in the future to have sprites respond to user input directly. Here is where child classes come in, as the behavior of each soldier instance depends on their location in the line, and whether they are front rank or rear rank. The soldiers will also need to be paired in “files” (to use the historical term, not to be confused with computer filed), allowing behavior like file pairs covering each other while the other loads.

So, as we begin thinking about this all, we might get pseudocode which looks like:

class Soldier(data) {
   constructor() {
      id, //a unique id for each instance
      file partner, //a reference id for the instance they are
      paired with
   }
   function fire() {
      //instructions to represent firing and reloading the musket
   }
   function leftFace() {
      //instructions to represent turning left, or rotating counter
      clockwise
   }
   function rightFace() {
      //instructions to represent turning right, or rotating
      clockwise
   }
   function step() {
      //instructions for moving some distance in the direction
      the sprite is facing
      //the intention will be to repeat #step until some condition
      is met, or a certain number of times
   }
   ...//possibly other functions to be added later
}
class frontRank extends Soldier{
   //functions with front rank specific behaviors, broadcasting a status to the rear rank, and listening to status updates.
   //by putting this in a new class, we don't have to check for the
   the value of a rank variable for each action
}
class rearRank extends Soldier {
   //similar to frontRank, but reversed on things like order to fire
}

I haven’t decided if this will be a weekly series, or less frequent with posts about other topics interspersed. For now, it might depend on my mood over time. The goal is to “whiteboard” much of the app in pseudocode, and then begin writing about the process of actually putting it into real code.

I hope you find this interesting, and that you want to follow along. If you have any thoughts on how to implement such a program, feel free to leave a response!