Scythe Terminal

Scythe Terminal logo
Category: Game Development / University Project Role: Lead Developer (Solo Project) Date: May 2026
Java Game Engine Algorithms JLine
View on GitHub →

Case Study: Scythe Terminal

01. The Overview

Scythe Terminal is a Java-based CLI implementation of the complex strategy board game Scythe. While professional digital versions exist, this project serves as a pioneer implementation within a terminal environment, combining economic engine-building with tactical combat. The engine manages 5 unique factions, a 47-tile hexagonal map, and an asymmetric economy.

  • Codebase Scale: 160+ source files and 24,000+ lines of code.
  • Tech Stack: Java 17, JLine 3 (for raw input and alternate buffers), and OpenCSV.
  • Core Philosophy: Prioritising modular architecture and “mise en place” code organisation to handle high-complexity state management.

02. The Challenge

The primary challenge was translating a high-fidelity board game into a medium that was never designed for graphical representation.

Key Constraints:

  • Terminal Limitations: Addressing 2:1 character aspect ratios, flickering cursors, and line-oriented interfaces.
  • Wide Characters: Emojis (used for resources and units) take two columns in a terminal but are treated as one character in Java, leading to UI “drifting”.
  • State Explosion: Managing “Bonus Chains” where a single player action triggers multiple cascading state changes.

03. Technical Implementation

Hexagonal Cube Coordinate System

To manage the 47-tile grid, I implemented Cube Coordinates (x, y, z) where x+y+z=0.

  • Why: This allows for O(1) efficiency in finding neighbours and calculating distances without complex branching logic.
  • Validation: The system uses parameter validation in the constructor to prevent logical errors during board generation.

The Wide-Character Buffer System

To solve the alignment issues caused by emojis, I developed a buffer system that detects wide characters.

  • The Logic: The system automatically reserves the adjacent terminal cell when a wide character is detected, preserving the horizontal alignment of the entire interface.

Dynamic Camera & Viewport

Because the full game map often exceeds standard terminal resolutions, I built a Camera Handler.

  • Implementation: The handler calculates X and Y offsets to allow real-time scrolling across the hexagonal grid using arrow keys.
  • UX Enhancement: Includes toggleable panels (U, P, O, I) to hide UI elements when the screen space is limited.

04. Engineering Beyond the Brief

This project exceeded the requirements of a standard academic assignment by implementing advanced architectural patterns.

  • Layered Manager Architecture: I transitioned from a simple game loop to a centralised system of managers (Bonus, Combat, UI, and Selection Managers) to separate concerns effectively.
  • Navigation Stack: Implemented a Stack-based navigation system that allows users to return to previous screens or menus, which was critical for a nested game state like Scythe.
  • Data-Driven Design: Map configurations, faction data, and action panels are loaded via CSV files, separating the data from the hard-coded logic.

05. Reflection & Lessons Learned

As noted in ADS Report 40514417 Part 2.docx, the project was an intensive problem-solving exercise in architectural stability.

Key Outcomes:

  • Efficiency: Utilised EnumMap and HashMap for O(1) access to player milestones and achievements.
  • Resilience: Developed a raw-mode input handler using JLine 3 to respond to real-time keypresses without requiring an Enter key.

Future Improvements: If I were to rebuild this system, I would implement a decoupled Observer Pattern for the Bonus Chain Manager. This would handle the cascading effects of Scythe’s rules more cleanly than the current heavy logic manager.