Scythe Terminal
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
EnumMapandHashMapfor 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.