Untitled Game Project
An ongoing Godot project exploring 2D game development through a small fantasy library concept, playable systems, environments and iterative prototypes
- Year
- 2025–
- Status
- In development
- Role
- Game design and development
- Technologies
- Godot, GDScript, Pixel art, Systems design, UI
Game development / Project stage
Why this project exists
This project began as a way of learning game development through something more meaningful than disconnected tutorials. Rather than building small exercises with no relationship to one another, I wanted one evolving project that could give each new system, tool and experiment a practical purpose.
The game itself is still taking shape. Mechanics, story ideas and even parts of its identity may change considerably as development continues. What has remained consistent is the central setting: a small, systems-driven 2D game built around restoring and operating a neglected fantasy library.
Because of that, the project has two goals running in parallel. One is gradually discovering what the game should become. The other is learning how games are actually constructed inside Godot.
The core fantasy
The central idea is to make the library itself the heart of the game. Instead of functioning as scenery or as a menu for upgrades, it should be a physical place the player gradually understands, repairs and changes.
Early ideas revolve around recovering damaged books, repairing and cataloguing them, restoring rooms and furniture, researching what has been found, and using that progress to unlock new tools, workspaces, characters and areas of the building.
The appeal is in beginning with mundane work and allowing it to lead somewhere larger. Repairing an ordinary book might eventually reveal a forgotten manuscript. Restoring a room could uncover an archive. Organising records could expose information connected to a character, location or wider mystery.
Making the library the game
One of the main design questions is how to make everyday library work interact with the rest of the game rather than exist as a collection of unrelated mechanics.
Exploration outside the library should feed back into restoration and research. A ruin might contain a damaged manuscript. Restoring it could reveal information about another place or character. That discovery might unlock a new research path, crafting possibility or section of the library.
This creates an interconnected design in which systems reinforce one another. The world does not need to be enormous if the places within it have a reason to exist and discoveries continue changing what the player can do back at the library.
Learning through systems
The project also acts as the structure for learning Godot itself. Movement, collisions, interaction, inventories, dialogue, saving, NPC behaviour, time systems, quests and world transitions can be approached as real problems required by the game rather than isolated tutorial exercises.
Development therefore does not need to follow the order in which the final game will eventually be played. One character moving around a test room can teach movement and collision. One interactable bookshelf can establish the basis of a reusable interaction system. One NPC following a schedule can become the foundation for much more later.
Each small prototype is useful even when it is temporary. Some systems will survive, others will be rewritten, and some will disappear completely. Learning why that happens is part of the project.
Developing the visual language
The visual direction is developing alongside the code. The current idea is a top-down 2D presentation built around tile-based environments and pixel-art or pixel-inspired assets, with an emphasis on readable spaces and a strong sense of atmosphere inside the library.
Environment experiments have included room layouts, furniture placement, tile proportions and the relationship between character scale and interior spaces. These tests are as much about understanding how game environments function as they are about producing finished artwork.
The goal is not to reproduce the appearance of the games that inspired the project. The visual identity is another part of the learning process and will continue changing as the art workflow improves.
Scope is part of the design
Build small before building broad — one room, one interaction or one functioning system is more useful than designing an entire game that cannot yet be tested.
Let systems grow from actual needs — mechanics should be introduced because the game requires them, not simply because similar games usually contain them.
Treat rewriting as part of development — prototypes can be temporary, ideas can be discarded, and early architecture does not need to survive unchanged.
Keep ambition separate from immediate scope — the long-term idea can contain libraries, towns, NPC schedules, exploration and larger mysteries while the current task remains one character, one room and one working interaction.
Where the project stands
The project is in active development, but it is still much closer to a learning and design laboratory than a finished game. Foundational systems, environment experiments and visual work are being developed incrementally while the larger concept continues to evolve.
There is no fixed final design document that every prototype must follow. Part of the purpose of the project is discovering which ideas deserve to survive once they have to work in practice.
For now, progress is measured less by how much of the imagined game exists and more by whether each experiment leaves behind a better understanding of Godot, game architecture, systems design or which design directions remain valuable once tested in practice.