Documentation

Documentation is everything around the code that explains how the code actually works — class hierarchies, in-line comments, README walkthroughs, and the running examples themselves. For CS 111, the clearest documentation is the project itself: PirateMegaGame, where every CS 111 concept shows up in a real, runnable place.

☠️🦜 Play PirateMegaGame →

Game Object Class Overview

Here's how each major game object slots into the engine's class hierarchy.

Game Object

Class

Role

McArchie

Player extends Character

Player-controlled character

Pirate

Pirate extends Character

"Enemy" NPC with reaction logic

Map

Background extends GameObject

Layered scrolling environment

Shields

Barrier extends GameObject

Collision boundaries

Concepts in Practice

Click any topic to see where it shows up in the codebase.

🧬 Object-Oriented Programming

Inheritance GameObject → Character → Player / Pirate

Writing Classes Custom subclasses like Player and Pirate

Method Overriding Custom update(), draw(), handleCollision()

Constructor Chaining super(data, gameEnv) ensures engine initialization

🔁 Control Structures

Iteration forEach loops in update + cleanup passes

Conditionals Collision checks, AI decisions, state transitions

Nested Conditions NPC type → proximity → inventory (3 layers)

🔢 Data Types

Numbers x, y, velocity, score

Strings Names, sprite paths, game states

Booleans isPaused, isJumping, isVulnerable

Arrays gameObjects[], level arrays

JSON Objects NPC config + GameLevel setup

➗ Operators

Math Ops +=, *, Math.pow()

String Ops Template literals for sprite paths

Boolean Expressions &&, ||, !

🎨 Input / Output

Canvas Rendering draw() via requestAnimationFrame

Keyboard Events keydown / keyup for movement

GameEnv Config Object literal world configuration

🧪 Software Engineering Practices

Single Responsibility Each method handles one behavior

Data-Driven Design GameBuilder uses Object Literals

Instantiation Level config spawns all objects

Documentation Inline comments throughout

Testing Objects validated before merge

SDLC Practices Kanban, feature branches, selective PRs

Key Things to Remember

• Class hierarchies are easier to read at a glance than walls of comments — naming the relationship in code (extends) doubles as documentation.
• The game itself is the most honest documentation. If you want to know what a class actually does, run the code and watch it.
• Inline comments should explain why something is done a certain way, not what the code is literally doing.
• Naming does most of the heavy lifting — good variable and method names cut the number of comments you need by half.