Stellarium

A large part of the difficulty was simply duration. This was not a short experiment but a project I kept pushing alone over a long period, while still learning how to organize my work.

That matters in the portfolio because it shows persistence and follow-through, even if the code quality itself is not what I would accept today.

I was learning while shipping, not after the fact. That means many systems were built with a very exploratory mindset, which helped me progress fast but also created structural weaknesses.

The important point is not that the implementation was perfect, but that I was able to turn self-teaching into a concrete playable result.

A real technical problem was performance. With that many planets, creatures, and systems, the project could easily have become too heavy to run properly.

I did manage to make it work, but honestly through a lot of pragmatic fixes and hand-tuned adjustments rather than a clean optimization architecture. It was bricolage, but it taught me a lot about where performance pressure appears in a game project.

This project gave me a first real collision with technical debt. As more features were added, every change became harder because systems were not separated clearly enough.

That lesson is one of the main reasons I care so much more today about architecture, modularity, and maintainability.

Stellarium was built before my formal software engineering training, so it should not be read as a benchmark for architecture or maintainability. I include it because it shows that even at that stage, I was already capable of carrying a project on my own for a long period.

Fifteen months of solo execution, multiple systems, documented iterations, and a playable result are the real signals here. It is evidence of discipline, curiosity, and the ability to keep building when a project stops being easy.

Presented this way, Stellarium strengthens the portfolio instead of weakening it: it shows where my builder mindset started, while my more recent projects show how much my engineering level has improved since then.

This project taught me what it means to sustain a long scope alone: defining iterations, keeping motivation, and moving an idea forward even when the system becomes messy.

It also gave me an early, concrete understanding of technical debt. When structures are weak and responsibilities are unclear, every new feature becomes more expensive. That lesson matters a lot because I learned it by hitting the wall myself, not by reading about it.

A big part of my current engineering discipline comes from that contrast. Stellarium is the kind of project that makes later architectural rigor feel necessary, not theoretical.

With my current level, I would split systems much more clearly, define boundaries earlier, and reduce the amount of complexity that accumulates invisibly between iterations.

I would also be stricter about maintainability, especially around how gameplay systems, progression, creatures, and world content evolve together over time.

That is exactly why the project remains useful in the portfolio: it does not represent my current standards, but it explains why I now care so much about them.