The primary goal with Explore the Universe 2175 is to create a fully immersive space simulation game. I wanted to be able to create environments with gravity, planetary conquest, and simulations of strange celestial objects and their behaviors. The procedurally generated galaxy is a major part of that idea, with stars, planets, moons, nebulae, black holes, factions, and other objects becoming part of a much larger simulated environment.
During the three years that I’ve been working on my game, I’ve gotten quite a bit better at developing and working with integrations. Explore the Universe’s Steam integration will make the game more fun with friends; Co-operative survival gameplay is going to be a part of the first Alpha Demo release and the game is now very integrated with Steam, so you should be able to invite your Steam friends to come play with you in Co-Op in the game when the demo comes out.
The game is currently available through the Explore the Universe 2175 Steam Playtest, where I have been gradually pushing more of these systems toward an actual playable release. These will probably be the kinds of bugs that I spend the week of the demo release fixing.
A.I. Coding Assistance and Mentoring
Throughout the process of creating a game from scratch, there were a lot of topics that I had to learn and expose myself to in order to create the game that I wanted.
At first, I limited myself to only 2D to keep the scope down; it decreases the computational complexity by quite a bit when you only have two dimensions to compute in the rendering engine, which I have built from scratch as well. I’ve written previously about some of the larger architecture behind the project in my Explore the Universe 2175 development log.
Some of my first self-appointed lessons were in object or entity management in a game. A space environment should have many objects as well as enemies, potential friends, space stations, asteroids, planets, projectiles, and other celestial objects.
There was a lot of architecture to plan in order to have the amount of units that I wanted on the screen and still make it a real-time shooter/strategy game. The galaxy itself contains many different types of objects with different behaviors and physical properties.
When I first started developing the game, I didn’t even know what a roguelike was! However, most of my gaming experience centered around one game, World of Warcraft, which contains some concepts that were already familiar to me even though the structure of Explore the Universe is very different.
The game has gradually become a combination of open-world space exploration, real-time combat, strategy, procedural generation, and simulation.
How A.I. Taught Me About Hash Tables, Spatial Grids, and Coordinate Management in Games
About four years ago, I guess, is when ChatGPT came out. Three years ago is about when I found out about it, when my buddy Kyle was showing it to me in Hawaii.
He told me:
“Just ask it questions about things you are curious about.”
Now, to be totally fair to myself, I had owned a website/blog for several years at this point, so I did this all the time with Google.
It was actually a big part of the end of my education. I took a research methods class for psychology — let me tell you, psychology research is a shit-show and I love it — and it kind of forged the extreme data skeptic in me that later became a product manager at Compete.
I am just really good at analyzing data.
So it was pretty obvious when I started using ChatGPT that it was an extremely powerful research, programming, and analytical tool and that it could help me investigate subjects much faster than I could manually.
There was this feature called Deep Research, and I used it to research black holes, astrophysics, and exotic environments. Those subjects eventually became closely connected to the environments I was creating inside Explore the Universe.
You can see some of that evolution in my article about the procedural galaxy in Explore the Universe 2175, where black holes, neutron stars, magnetars, nebulae, stars, planets, and moons all become interactive parts of the game world.
The physics side of the project also overlaps heavily with my work on Parker’s Physics. I wrote more about the relationship between the two projects in Computer Programming with Codex and Claude: Building Parker’s Physics and Explore the Universe 2175.
A lot of the ideas I investigate as scientific simulations can eventually inspire mechanics, environments, or physical behavior inside Explore the Universe.
So I began using AI as a teacher about three years ago and have continued learning computer science, software engineering, physics, and development with it.
I’ve used tools including ChatGPT, Codex, Claude, Cursor, and GitHub throughout that process. I wrote more about that workflow and how it changed my development process in my article about programming Explore the Universe and Parker’s Physics with AI.
I still prefer ChatGPT for certain kinds of teaching and exploratory research, although Claude has become particularly useful to me for hard facts and coding, so I generally use Claude Code extensively now.
Simulating Thousands of Objects Without Destroying Performance
Once you learn about hash tables, spatial partitioning, and coordinate indexing, real-time gameplay performance becomes a much more manageable problem.
Instead of asking every object in the universe about every other object, you can organize objects by where they exist in space.
In my case, spatial grids allow the engine to rapidly identify which objects are actually relevant to a particular region of game space.
That means I can get extremely fast lookups for objects occupying particular cells or coordinates instead of repeatedly searching through the entire object population.
This is also one of the things that makes an open world practical in Explore the Universe.
The only objects that need the highest-frequency simulation are generally the objects interacting with the player or existing around the ship during gameplay.
This includes:
- ships
- enemies
- projectiles
- collisions
- movement
- stations
- asteroids
- local celestial objects
- effects
- nearby AI
I discuss several of these systems in more detail in Creating Realistic Space Flight Simulations in Explore the Universe 2175, including the game’s custom weapon and projectile systems.
A galaxy simulation is easy when nothing is happening. It becomes much harder when thousands of ships, weapons, particles, asteroids, and AI agents become active simultaneously.
I have yet to put the whole galaxy into active orbit around the central black holes, but I’m not even sure current computers could handle that level of complexity at full simulation fidelity for the visible screen, let alone continuously in the background.
There are roughly 25,000 objects created in each new game, which means the important challenge isn’t simply creating them.
It’s deciding which objects actually need to be simulated at any particular moment.
That distinction is fundamental to the architecture of Explore the Universe.
Python, ECS, and Rust Acceleration
Explore the Universe originally grew from object-oriented Python and gradually moved toward an Entity Component System architecture as the number of objects and behaviors increased.
I’ve written more about that transition in my Explore the Universe 2175 development overview.
Python remains extremely useful for quickly developing gameplay systems, but some of the computationally expensive systems can benefit enormously from Rust.
Rust acceleration is particularly useful for:
- high-performance systems
- memory safety
- parallel processing
- entity simulation
- physics
- collision calculations
- projectile systems
- spatial queries
- simulation loops
- large entity counts
The combination lets me keep the development flexibility of Python while moving computationally expensive systems into Rust when they become bottlenecks.
That architecture is already being used in systems such as the game’s spaceflight, weapons, projectile, and physics simulations.
Four Layers of Simulation in Explore the Universe 2175
One of the big architectural ideas I’m working toward is separating the universe into different levels of simulation.
Not every object needs to receive the same amount of computational attention.
A laser flying toward your ship needs to be simulated very differently from a civilization fighting a war ten star systems away.
Level 1 — Immediate Gameplay
Ships, weapons, collision, movement, dialogue, interactions, docking, and UI elements are the primary elements that require compute during immediate gameplay.
The action bar is particularly lightweight and powerful. I’m also proud of the usability of the defense matrix, although the visuals still need some more polish.
Cyl, the player’s Lumari crystal companion, is also on screen frequently and has her own combat, scanning, defensive, healing, targeting, and movement systems.
Cyl isn’t simply decorative. Her systems include autonomous targeting, projectile interception calculations, scanning, support abilities, and independent decision-making.
Stations are another important piece of the immediate gameplay environment because they connect combat, exploration, trading, docking, and faction interactions.
The goal is for this layer to feel responsive regardless of how complicated the larger galaxy becomes.
Level 2 — Local System Simulation
Fleets, mining, stations, trade, exploration, and local conflicts are all brought forward from a zone-oriented simulation layer.
The galaxy is divided into a number of major regions containing different civilizations and environments. You can explore many of the currently planned civilizations on the Explore the Universe 2175 factions page.
Different factions are intended to behave differently rather than simply acting as cosmetic variations of one underlying enemy.
For example:
- the Mycelari operate as a fungal swarm
- the Machine Empire revolves around machines and Megabot
- the Wild use biological growth and terrain
- aquatic civilizations specialize in water worlds
- other civilizations occupy very different environmental niches
Creating a layer of information evolution ancillary to visible gameplay — one that connects larger civilization movements and behaviors to local trading, encounters, combat, and interaction — is a substantial architectural challenge.
I am still working on this system, but a lot of it currently revolves around triggers, timers, state transitions, and events that initiate gameplay encounters.
Level 3 — Civilization Simulation
This is where things get substantially larger.
The civilization layer includes systems for:
- population
- production
- territory
- diplomacy
- relationships
- event-oriented memory
- planned attacks
- civilization expansion
- warfare
- invasions
- trade routes
- deteriorating diplomatic relationships
- faction alliances
- faction hostility
The player will become an active faction within this system.
Players can ally with or become hostile to civilizations they encounter throughout the galaxy.
That forms part of the basis for the game’s strategy mode, where the player will eventually be able to begin alongside an allied civilization of their choice after discovering that race’s homeworld through Survival gameplay.
This is where the growing roster of ETU civilizations and factions becomes much more than worldbuilding.
Their existence needs to influence the simulation itself.
Level 4 — Galactic Simulation
At the highest level are:
- faction expansion
- wars
- resource movement
- galactic territory
- civilization collapse
- invasions
- major events
- long-term history
One of the most important events is the invasion of the Evil Machines and Mechas at the behest of MEGABOT, the Galactic Machine Overlord.
Megabot is becoming one of the most important characters and simulation systems in the game.
Rather than being designed purely as a scripted boss, Megabot is being developed around adaptive behavior, persistent memory, modular forms, and the larger expansion of the Machine Empire.
The conflict between the machines and other civilizations provides a mechanism for creating galactic-scale change while the player explores.
The world and faction structure of Explore the Universe 2175 is probably the best indicator of the ambition behind this aspect of the project.
There is no reason this universe can’t continue expanding and improving over the course of a decade or two.
New civilizations can be introduced.
New stars and celestial objects can be simulated.
New mechanics can influence the economy.
New wars can reshape the galaxy.
And improvements in computing power can allow increasingly complex parts of the universe to become active simulations rather than static background information.
Building a Living Universe
This is really the long-term goal behind Explore the Universe 2175.
I don’t just want to create a large map.
I want to build a universe consisting of interacting systems:
physics → objects → ships → factions → civilizations → wars → history
The player exists inside that simulation rather than simply moving through a collection of scripted levels.
That is also why projects like Parker’s Physics and Explore the Universe have developed alongside each other.
The more I learn about real celestial systems, simulation science, computer architecture, AI, and physics, the more ideas there are to experiment with inside the game.
You can read more about the project through:
- Explore the Universe 2175 — Official Site
- Explore the Universe 2175 Development Log
- The Procedural Galaxy in Explore the Universe 2175
- Creating Realistic Space Flight Simulations
- Programming with Codex and Claude: Parker’s Physics and ETU
- Explore the Universe 2175 Factions
- Cyl — Companion AI
- MEGABOT — Enemy of the Universe
- Elliot’s Projects
Follow the development of Explore the Universe 2175 as I continue building, testing, breaking, and improving these systems.
And if you want to help the project grow, –> wishlist Explore the Universe 2175 on Steam.
