SOSGame — SOS Grid Game
(C#, AvaloniaUI, xUnit)

SOSGame is a graded software engineering project centered on the classic “S-O-S” grid game. Two players compete to form the sequence on an (n × n) board through a graphical user interface.

The project supports Human vs Human, Player vs Computer, and Computer vs Computer play, and ships with three game modes: Simple, General, and an intentionally Vulnerable mode designed for security education.

$ gh repo clone kimbrow-slice/SOSGame
$ cd SOSGame

Core Game Mechanics

This section defines the foundational game loop: board initialization, turn order, input validation, and detection of the “S-O-S” sequence.

This is the baseline: rules, state transitions, and the core game loop.

The game is simple to describe and deceptively rich to implement: a grid, turn order, input constraints, scoring logic, end conditions, and a UI that makes the state obvious without hand-holding.

The goal isn’t just “make it run.” It’s make it observable. A good game loop behaves like a clean system: deterministic when it should be, explainable when it fails, and stable across edge cases.

This section is complete when board handling, turns, and win/score detection are reliable under normal play.

return sosgame.core

Game Modes & Player Types

This section covers gameplay variation through configurable modes and opponent types.

The “Simple Game” resolves immediately on the first completed SOS. The “General Game” becomes a scoring system where each player’s total sequences determine the outcome. These modes force clean boundaries between UI, gameplay rules, and scoring logic.

Beyond the rules, the focus is testability: validated inputs, explicit state transitions, and consistent automated play across board sizes.

Once the core loop stabilized, extensibility became the priority.

• Mode switching becomes configuration, not a rewrite.
• The GUI reflects state clearly (turn, score, end condition) without guessing.
• Player types (Human/Computer) become interchangeable components, not special cases.

commit sosgame.loop --message="core loop stable under all modes"

Architecture & Testing

At this stage, the project transitions from “a working game” to a structured system with clear architectural boundaries.

Architecture matters here: the GUI should present, the logic layer should decide, and tests should verify. When those boundaries are respected, features don’t multiply complexity—they reuse structure.

This phase is also where the deliverable becomes repeatable: unit tests validate scoring, win detection, and edge cases; the game loop becomes predictable under both human input and automated play.

In other words: the project becomes explainable. Not because it’s small, but because it’s composed.

The Vulnerable Game mode is an educational branch where “logic conditions” act as triggers and behavior changes are intentional and observable.

Here, the output isn’t “more features.” It’s controlled behavior used to teach how trusted workflows can be abused when assumptions are embedded in execution paths.

merge sosgame.architecture --strategy=composition

Vulnerable Game (Educational Security Demo)

The Vulnerable Game mode intentionally demonstrates a crafted execution path using a trusted Windows binary (mshta.exe).

When a specific logic condition is met (gridSize == 13), AES- and RSA-wrapped resources are decrypted, written to %TEMP%, and executed via mshta.exe. This simulates real-world code execution techniques commonly observed in red team operations.

The included RSA and AES keys are left in place strictly for educational purposes.

This mode is included to support security learning and controlled demonstration, not to provide operational instructions.

checkout phase3.0.2 --mode=learning // END PHASE 3.0.2 

git add . commit -m "sosgame architecture finalized"

Conclusion

SOSGame demonstrates how a familiar game can be used to teach software architecture, testing discipline, and security reasoning within a single, coherent project.

Acknowledgments

This project was completed as a graded academic assignment and reviewed and accepted as submitted.

The framing and presentation here do not alter the original intent or scope of the work.

In gratitude to [Professor_Name]—for approving the assignment scope and validating the final submission.