Hello everyone,

We are excited to share the developments and improvements we have made on Eternity since our last post.

We are working on a star map generation algorithm, where our proc gen of solar systems appears nicely distributed across the cosmos and eventually connected (or not) via jump gate. While these connections/relationships are implemented in the game since day 1 of the Solar System generation system, we didn’t had any way to represent them visually to players. 

As such, we started by organizing all systems in a grid. There are rules for player start and for the placement of the Eternity System. Then we had to represent all the connections in an interesting way. The most significant task here was regarding the path generation.

We took a step back from our initial A* implementation (which was the obvious approach given the grid and all) to embrace a different approach based on Depth-First Search (DFS). The reason for this was due to the unique nature of our game requirements. We needed our pathing system to be flexible, allowing us to generate various scenarios that maintain balance, diversity, and playability. The DFS approach was able to cater to our requirements perfectly. It provided a deterministic way to identify the longest path between the starting and the eternity systems, adding a greater level of complexity and exploration to our gameplay.

Additionally, we’ve added a set of new rules to further shape the starmap structure. To prevent clumping of connections, we’ve limited the number of connections a cell can have. We’ve also ensured the eternity system (end of the main path) has only one connection, adding a unique challenge for players to reach the end of the galaxy. Moreover, to avoid shaping the galaxy as a square and to promote more varied paths, we’ve introduced a rule where all cells next to a border or boundary can’t connect with each other.

We noticed a significant issue with redundant connections between systems, which often resulted in the creation of unnecessary loops and path redundancy. We addressed this by defining a MaxConnections() function, where the maximum number of connections a cell can have is dynamically adjusted based on its position within the grid. This approach allowed us to maintain the diversity of our starmap layout while avoiding over-connected systems.

However, implementing these changes wasn’t without challenges. During testing, we discovered that our changes led to occasional infinite loops. This turned out to be due to too restrictive conditions for building paths in the CreateSecondaryPath() function. We quickly addressed this by adding an escape condition to ensure we weren’t caught trying to find neighbours for cells with none available.

As we further developed the game, we realized the need for diagonal connections in our secondary paths. This introduced a new dynamic to the layout and allowed us to create more complex and interesting paths for the players to navigate. However, we had to be mindful not to allow these paths to overcrowd the edge of the grid. So, we implemented a rule to limit the number of cells that can be connected at the edge of the grid.

This iterative development process has been both exciting and challenging. We’re pleased with the results and we’re confident that these changes will greatly improve the gameplay experience. We are continuously working on refining these mechanics and introducing new ones to ensure a rich and varied experience each time you venture into the galaxy.

As always, we greatly appreciate your feedback and suggestions. They play a crucial role in shaping the game into something we all love.

Stay tuned for more updates, and keep reaching for the stars!