There is no perfect university day
Study for the exam and lose sleep. Take a shift and gain money but miss a social event. Rest now and let a deadline get closer. Our Java simulation turns an ordinary university day into a network of competing needs, where a sensible decision in one system creates pressure in another.
Six people built the project together, so the codebase was part of the outcome. We needed rules that felt connected to the player while remaining separate enough for teammates to design, test, and integrate in parallel.
The home screen introduces the campus simulation and its competing priorities.
Java architecture
The game engine coordinates updates across player state, time, map, academic, health, and social systems. Each subsystem owns its rules and communicates through defined interfaces. The separation was practical rather than academic: clear boundaries meant one person could change health logic without rewriting the map.
The map-building workflow separates location data from the rules that use it.
The campus is the interface
Lectures, the library, accommodation, the gym, food, and social spaces are placed on a tile-based campus. Locations do more than move the character: each carries metadata used by the simulation. A library changes study efficiency; a gym affects health; an event may exist only at a particular time.
Connecting map data to system rules kept the world legible. It also stopped us hard-coding every interaction into the renderer, which would have made the game brittle as six contributors added features.
Locations such as the gym connect the campus map to changes in player state.
Testing and workflow
JIRA supported sprint planning; GitHub supported branches and review; continuous-integration checks caught problems before they reached the shared build. Unit tests concentrated on state changes, scoring, and interactions between systems—the exact places where a small rule could have an unexpected effect elsewhere.
What the result taught us
The project received 42% of the cohort vote in peer evaluation. More useful than the ranking was a concrete lesson about team speed: when interfaces were precise, work happened in parallel; when responsibilities were vague, coordination became the bottleneck.