What it is
This was a Java simulation game about managing university life. The player moves around a campus map and tries to balance study, health, money, sleep, and social choices. Each decision affects more than one system, so the game becomes less about finding the perfect action and more about handling trade-offs.
It was built as a software engineering group project, which meant the codebase mattered as much as the final game. We had to show planning, collaboration, testing, and a structure another team could realistically pick up.
How it plays
The campus is split into useful places: lectures, the library, accommodation, the gym, food spots, social spaces, and events. Studying improves grades but can increase stress. Rest helps health but costs time. Social choices can improve morale, but they pull attention away from deadlines. The game is small, but those systems make it feel more alive than a simple checklist.
The map is tile based, with locations carrying metadata used by the simulation. A library tile can affect study efficiency. A gym tile can affect health. Events can be available only at certain times. That let us keep the visual map and the simulation logic connected without hard-coding every interaction into the renderer.
Technical build
Java architecture
The code was organised around object-oriented systems: a game engine, player state, time manager, map model, academic system, health system, and social system. The engine coordinates updates, while each subsystem owns its own rules. That separation made the project easier to split across a six-person team.
Testing and workflow
We used JIRA for sprint planning, GitHub for branching and review, and CI checks to catch problems before integration became painful. Unit tests covered the core rules around state changes, scoring, and system interactions. The biggest technical challenge was keeping the simulation understandable as the systems started to affect each other.
Result
The project won 42% of the cohort vote during peer evaluation. That was a good outcome, but the more useful result was learning how much architecture affects team speed. When the interfaces were clear, people could build in parallel. When they were vague, everything slowed down.