Why This Site Exists
Most portfolio sites are easy to understand within a few seconds. There is a hero section, a short biography, a grid of projects, maybe a list of posts, and a contact block at the bottom. That pattern works, but it also flattens the person behind the work. When everything is reduced to clean rectangles and startup-style marketing copy, the site stops feeling like a place and starts feeling like a template.
I did not want this site to feel like a template.
That is what led me to an unusual idea: build a portfolio and blog that behave like a pseudo Godot editor. Not a joke landing page. Not a novelty skin layered on top of a normal layout. An actual information architecture that borrows the language of an engine UI: tabs, inspector panels, a filesystem, output logs, and editor-like windows. Underneath, it is still a normal Hugo website. But on the surface, it feels closer to opening a project than visiting a brochure.
That tension is exactly what fascinated me.
Why Godot Made Sense
Godot is already part of how I think about software. It is not just a tool I use occasionally. It is part of my day-to-day vocabulary as a developer, and it sits close to several parts of my work: game development, tools, open-source contribution, and interface design. The Godot editor is also one of those rare pieces of software that many developers can recognize from a glance. Its panels and tabs immediately suggest that something is being built, inspected, and iterated on. That made it a surprisingly good frame for a portfolio site, because a portfolio is also a record of things built over time.
The interesting part was deciding how far to push the metaphor.
If the site copied the editor too literally, it would become cosplay. It would stop being useful. A real editor contains controls that only make sense inside the engine, and a normal visitor should not have to decode every UI joke just to find an About page. On the other hand, if the Godot inspiration was too subtle, the idea would lose its bite. It would become another dark-themed portfolio with a few decorative borders.
So the real challenge was not visual. It was structural.
Where the Metaphor Works
I had to decide which parts of the editor metaphor should remain functional and which parts should stay suggestive. The top navigation, for example, works because it translates surprisingly well. A portfolio homepage can sit where a scene view would be. An About page can live under a Script-like tab. A projects archive can borrow from the feeling of an asset library. Posts can sit naturally in the same system as a searchable content archive. Those choices make sense even if a visitor has never opened Godot before.
The filesystem sidebar needed even more care. At first, it behaved too literally, and that made it inconsistent across pages. That was a mistake. Once I treated it as navigation disguised as a filesystem, it became much more honest. It no longer pretended to be a real project tree. Instead, it became a stable interface pattern that suggests a project structure while still doing the simple job a sidebar should do: helping people move around the site without thinking too hard.
The same principle shaped the output console.
I like the output panel because it gives the site a sense of live process. Even though the site is static, the console hints that something is always being compiled, loaded, indexed, or linked. That small illusion changes the mood. The site feels active. It feels less like a stack of documents and more like a working environment. But this only works when the console stays restrained. If every panel animates too loudly or every message tries too hard to be clever, the whole thing collapses into gimmick. A little motion gives atmosphere. Too much motion turns into noise.
That balance came up again and again while building the design.
The Real Constraints
One consideration was accessibility. The original temptation with a pseudo-editor interface is to make everything dense and tiny because real tools often are. That works poorly on the web, especially on phones. The site still had to be readable, tappable, and understandable on mobile screens. So the design could borrow the personality of a desktop tool without inheriting all of its friction. Tabs needed to collapse sensibly. Panels needed mobile switching. Interactive areas needed clearer spacing than a real engine UI would usually allow.
Another consideration was honesty. I did not want the site to imply that it was actually running Godot in the browser. It is not. It is a static site, built with Hugo, using straightforward frontend techniques. The interesting part is not technical deception. The interesting part is interface translation: taking the emotional grammar of one kind of software and applying it to another without losing usability. In that sense, the site is less about mimicry and more about adaptation.
That is also why I think this kind of design is more than just visual fan service.
Why It Fits a Personal Site
A personal site should say something about how its owner thinks. In my case, that means several things living side by side: language learning tools, search-heavy educational products, open-source contributions, game development, and long-running experiments that do not fit cleanly into a single label. A pseudo Godot interface helps hold those threads together because it already suggests a workspace with multiple subsystems. It gives me a way to present projects, posts, credentials, and ecosystem work inside one coherent frame instead of scattering them across unrelated marketing sections.
I also like that it changes the tone of reading.
On a normal blog, a post is usually presented as a clean article page detached from the rest of the system. Here, a post still reads like a post, but it sits inside a workspace. There is a file tree nearby. There is metadata in an inspector. There is a sense that this text belongs to a larger body of work rather than floating by itself. That matters to me because writing, projects, and tools are not separate lanes in my work. They feed into each other.
The Standard I Kept Using
The broader lesson is that portfolios do not need to imitate software company landing pages in order to feel professional. They can be weird, as long as the weirdness is disciplined. The interface still has to respect navigation, content hierarchy, search, and readability. It still has to help people answer basic questions: who is this person, what have they built, what do they write about, and why should I trust their work? The visual concept only earns its place when it improves memory, identity, or coherence.
That is the standard I kept returning to while building this site. Every flourish had to justify itself. Every panel had to carry real content. Every borrowed idea from Godot had to become useful in a browser context. When that happened, the design stopped feeling like a skin and started feeling like a system.
That is why this approach still feels exciting to me.
Why It Still Feels Worth Doing
It sits in a space I like very much: halfway between interface design, frontend engineering, and personal worldbuilding. It is practical enough to use every day, but strange enough to be memorable. It lets a portfolio behave more like a tool, and it lets a tool-like interface carry biography, writing, and product history without flattening them into generic sections. For a personal site, that feels like the right kind of unconventional.