Academic Team ProjectPersonal / Game Dev

RenovIUT

Godot 4 serious game about campus renovation, budget tradeoffs, and educational governance.

RenovIUT is a team-built serious game where the player acts as the director of the IUT Robert Schuman and manages campus renovation, staffing, heating, budget pressure, and stakeholder satisfaction across several scenarios.

Godot 4GDScriptSQLiteMVC / Observer

Overview

Academic serious game with a management and simulation focus.

Godot 4 project mixing a 3D campus view with 2D management panels

Player decisions affect building condition, heating, staffing, budget, attractiveness, and academic outcomes

Several scenarios: reelection, full campus renovation, and academic excellence

Quarterly simulation structured around MVC, Observer, and SQLite-backed game data

RenovIUT main gameplay view showing the campus, HUD, and building action panel

Engine

Godot 4 + GDScript

Architecture

MVC + Observer

Data

SQLite-backed simulation data

Modes

3 scenarios + tutorial

Technical Challenges

Readable Management Simulation

Budget, satisfaction, staffing, heating, and building condition had to stay understandable without turning the game into a wall of raw numbers.

3D / 2D Coordination

The project had to connect a navigable campus model with fixed management panels, notifications, and action controls that remained usable during play.

Pedagogical Goals as Systems

The team had to translate educational goals about governance, renovation, and tradeoffs into mechanics the player could actually feel through scenarios and consequences.

Simulation Architecture

Simulation loop

RenovIUT follows a simple four-step loop: the player acts through the visible UI, controllers apply simulation rules, game state changes, then the persistent data layer stores what the simulation relies on.

Player

Acts as the director of the IUT and advances the simulation

Transitions
observe: Player -> 3D campus view
adjust: Player -> 2D management panels

3D campus view

Camera movement, building selection, visible renovation state

2D management panels

Budget, staffing, heating, notifications, scenario feedback

Transitions
trigger: 3D campus view -> Simulation controllers
command: 2D management panels -> Simulation controllers

Simulation controllers

Scenario, budget, teaching, buildings, timeline rules

Game state

Buildings, populations, notifications, and global indicators

Transitions
persist: Game state -> SQLite data

SQLite data

Students, teachers, and notification tables

Godot mixes a 3D campus scene with 2D management panels so decisions stay grounded in the visible campus state.

RenovIUTApp and the facade layer bootstrap the scenario and route actions instead of letting the UI own game rules directly.

Controllers separate budget, teaching, building management, and timeline logic so the simulation stays understandable as it grows.

Game state remains explicit around buildings, populations, notifications, and global indicators rather than being hidden inside views.

SQLite persists the student, teacher, and notification data that the simulation and reports rely on.

Player-Facing Systems

The most useful visuals are the campus management surface, seasonal camera states, onboarding, and the feedback UI that explains consequences to the player.

Winter gameplay view showing a building under renovation in RenovIUT

Campus state and seasonal context

The same campus surface carries building condition, active renovation work, season changes, and the right-side decision panel.

RenovIUT notification history panel showing reports and semester outcomes

Notification history and reports

Bills, exam summaries, and scenario feedback are kept visible through a dedicated history view instead of disappearing after a single popup.

RenovIUT bankruptcy risk popup over the main campus scene

Urgency feedback in context

Warnings are layered over the main scene so the player keeps the campus context while the game communicates risk and pressure.

RenovIUT start screen with scenario selection and tutorial option

Scenario entry point

The run starts with explicit scenario selection and an optional tutorial instead of hiding the simulation behind a single fixed mode.

Deep Dive

Why It Belongs In The Portfolio

A useful team project because it shows simulation structure, not just visuals.

+

I do not present RenovIUT as a solo build. Its value is that it exposed me to a team project where gameplay, architecture, and pedagogical goals all had to line up.

It broadens the portfolio beyond web products by showing that I also worked on stateful simulation logic, a game-oriented UI surface, and a more explicit event-and-consequence loop.

What It Shows Technically

The strongest signal is the explicit structure behind the simulation.

+

The project uses a clear split between views, controllers, and models, then adds observer-style updates so UI surfaces react when building state, date, budget, or population metrics change.

That matters because the game is not just decorative 3D. Decisions about staffing, heating, renovations, and budget need to propagate through simulation rules and come back as visible feedback.

Tradeoffs And Limits

An ambitious academic prototype, not a commercial production.

+

The project aims first at a playable serious-game prototype, so some systems stay deliberately simplified. The trimester-based loop keeps the simulation readable and manageable instead of chasing a denser but harder-to-follow model.

That tradeoff is reasonable for the context. It keeps the game explainable, ties decisions to visible consequences, and still leaves enough architecture behind the scenes to make the project worth showing.