A 15-month solo survival game project built before my formal software engineering training.
Stellarium is a personal Unreal Engine project I built alone over roughly 15 months before my BUT in computer science. I do not present it as a code-quality reference, but as proof that I could already sustain a large scope, learn autonomously, and push an ambitious idea to a playable state.
The value of Stellarium in this portfolio is not clean architecture. The code and structure are below my current standards, and that should be stated plainly. What matters is that before formal training, I carried a long solo project across multiple planets, survival systems, creatures, construction, ships, bosses, and a final trailer. It is a strong signal of persistence, self-teaching, and early exposure to real complexity.
Duration
15 months solo
Positioning
Before formal training
Outcome
Playable prototype
What it proves
Autonomy + persistence
15 months of solo work before formal software training
Playable prototype with planets, creatures, construction, and progression
Concrete proof of long-form iteration and autonomous learning
Useful today as a mindset project, not as a code showcase
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.
Each world is reached through the space zone. This graph uses real in-game screenshots instead of concept art to show the playable planets documented in the project.
Space Zone
Travel hub between worlds
Earth
Starting world
Miraju
Desert survival planet
Mitsurin
Forest world
Funka
Volcanic planet
Kagami
Ice world
Vesus
Late-game antimatter world
Travel moves through a dedicated space zone before reaching each world
Every planet adds a distinct biome and progression step
The planet screenshots come from the GitHub project documentation, not from concept art
This graph is intentionally product-facing: it shows playable scope rather than internal code structure
The right story for the portfolio is world scale, persistence, and iteration
The project remains useful because it reached a real playable state despite weak engineering structure
Creatures are a core gameplay system in Stellarium rather than simple enemies. Depending on the species, they can become mounts, combat allies, utility companions, or breeding lines with mutations and inherited stats.
Araneoide
A giant nocturnal spider-like creature that launches sticky traps to slow its targets.
Salavamandre
A volcanic salamander that climbs walls and fires burning lava projectiles.
Hazer
A deceptive wolf-like creature that creates illusions with blizzards to confuse enemies.
Open the full creature roster shown as a graph of real in-game screenshots and short descriptions from the game design document.
Complete creature set documented with real in-game screenshots. This graph intentionally has no links: it is a visual roster, not a system diagram.
Wolf
Pack predator from forests and mountains. Not mountable.
Bear
Territorial omnivore that hits harder at low health. Mountable.
Sheep
Peaceful plains creature used for wool and light travel.
Tardigramorph
Almost indestructible giant with glide and temporary invincibility.
Slawormon
Cowardly giant that launches enemies with sand shockwaves.
Muddy
Huge herbivore that weakens enemies and buffs allies with sandstorms.
Golem
Stone giant that turns deadly once provoked and hurls boulders.
Araneoide
Aggressive nocturnal spider that throws sticky slowing traps.
Sower
Plant creature that drains life with seed clouds.
Cerval
Fast bipedal deer using sleep mist for crowd control. Mountable.
Vicilis
Toxic battlefield controller that traps enemies with vines.
Bibou
Peaceful giant herbivore useful for breeding and mutation chances.
Salavamandre
Wall-climbing lava salamander that fires burning projectiles.
Chrysomancer
Fast flying fire creature that crashes into enemies explosively.
Erudon
Massive fire-immune predator that creates explosive lava craters.
Snow-Saurus
Snow combat brute with ice breath and knockback. Mountable.
Reaper
Ice creature with long-range claws and strong crowd control.
Hazer
Illusion-based wolf that uses blizzards to confuse enemies.
Dazzle
Massive beast that blinds and disorients targets. Mountable.
Tronvoide
Night-active ambusher that teleports behind enemies.
Stormvoker
Vesus colossus that summons deadly lightning storms.
Negatron
Humanoid antimatter user with teleporting area damage.
Hyppoglow
Peaceful mount that reveals ore veins and rejuvenates allies.
Items are unlocked through engrams and crafted from gathered materials. The system spans combat gear, armor, building modules, starship propulsion, utilities, and consumables used for survival, traversal, or creature management. When a category did not have a strong dedicated screenshot, it stays text-first instead of reusing a generic inventory image.
The item system spans weapons, armor, building pieces, ship parts, utilities, and consumables unlocked through engrams and crafted from gathered resources.
Weapons
Pistols, rifles, launchers, elemental guns and tranquilizer gear
Building
Modular walls, materials and dome structures for base construction
Engines
Thermal, nuclear and antimatter propulsion for starships
Utilities
Storage, portals, cloner, control panel and ship support tools
Weapons include melee, firearms, elemental rifles, tranquilizer gear, and late-game antimatter weapons.
Armor progresses from metal and platinum sets to Tek and cosmic armor, with upgrades for oxygen, climate resistance, fall damage, and movement. This category is described directly because I did not have a clean dedicated screenshot for it.
Building items use modular pieces and materials with different durability and weight, plus large domes for advanced bases.
Starship engines scale from thermal to antimatter reactors, which changes how interplanetary travel feels.
Utilities cover storage, portals, turrets, cloners, ship controls, and other support systems.
Consumables and tools include healing potions, strength boosts, cryopods, teleport devices, and mining tools. This one also stays text-first instead of forcing a weak visual.
Beyond the planets and creature systems, Stellarium also pushed dungeon content, boss fights, inventory management, progression, and a broader survival loop.
Base construction
Base building was already part of the project scope, with modular construction pieces and a broader survival loop around placement, materials, and shelter.
Starship construction
Ship building mattered because interplanetary travel was not just decorative: it was tied to progression, engines, and how planets were actually reached.
Dungeon content
A concrete example of additional gameplay scope layered on top of survival and exploration.
Inventory
The inventory gives a clearer view of the amount of gear, tools, consumables, and progression items the project tried to support.
Final boss
The boss screenshot works as a strong proof of endgame ambition and gives a concrete close to the visual story of the project.
The trailers are embedded directly in the page so the project can be watched without leaving the portfolio.
Trailer 1
Shorter trailer integrated directly into the page so the project can be watched without leaving the portfolio.
Trailer 2
A second direct-play trailer to show more of the game without forcing an external navigation flow.
Final trailer
The full seven-minute trailer is still available inline for people who want the complete proof of what was shipped.
This project proves persistence and autonomy more than engineering quality.
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.
The strongest lesson came from living through complexity, not from perfect implementation.
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.
I would keep the ambition, but rebuild the structure from the start.
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.