Blogs

Previously, the initial areas of factions were evenly distributed by count. Now, as you might have guessed, it’s done through an algorithm that, based on the current terrain, calculates the areas that look most like factions.

Thus, the initial areas of each faction will differ, and the number of factions may also vary with the terrain. For example, in the image below, there is a very small minor faction on the right.

The number of NPC factions in the central area will also vary. Sometimes there may be a single super-large faction, or it may be split into four factions as shown here.

The aim is to bring more varied reincarnation experiences. Stay tuned!

Greetings, universe conquerors.

The universe generation in SSW1 was decent, but it was not algorithm-based, purely random.
Since the server engine has been switched to Python, it’s time to leverage its capabilities.

Currently, the universe generation for the reset version is half done. Let me introduce the progress and changes.

Galaxy Distribution

Previously, star systems (the points on the map) were placed “randomly”, but to reduce computational load, some predictable prerequisites were added, and the single-layer randomness resulted in insufficient map variation.

Now the galaxy will be fully algorithmically randomized, with ever-changing positions and forms. “Storm zones” have been added, creating large empty areas similar to mountains that block movement, forming terrain.

Star System Clusters

Star systems will be more clustered algorithmically, forming areas similar to island ore fields, but spread throughout the entire galaxy. These serve as important corridor pathways.

More Natural and Unpredictable Star Gates

Star gates are no longer simply connected to their surroundings; instead, algorithms create more natural connections. The picture may be more intuitive.

Previously, star gates were somewhat regular, but now they are harder to predict.

Varied Generation Modes

Of course, the above modes can be combined or canceled. The server will automatically generate them, forming various map modes.

This is the current progress. Under Python, it’s very flexible. There may be more changes in the future, so stay tuned.

In the past, online game payment methods were not widespread enough, so they had to operate under a free-to-play model, forming the current commercial free-to-play model where whoever spends more wins. It cannot be said that this model is not fun, but for gamers other than the whales, the experience is not very good.

Since the remastered version of SSW is not for commercial development, we can innovate by eliminating microtransactions. The primary consideration for the game is multi-accounting. Previously, using a CD-key-like method to limit multi-accounting was the most effective. Also, we don’t want to be like those gacha games where players endlessly compare how much they spend.

So currently, the best approach seems to be a CD-key-like monthly card system with a seasonal buyout model. The game itself has no pay-to-win features. The difference between free players and buyout players lies in some functional restrictions (similar to the current command boosts in SSW) and some daily resources. Free players should not be able to participate in PvP content to prevent multi-accounting; the specifics are to be determined.

The buyout also has an entry-level price, mainly to prevent multi-accounting, similar to a season pass. I hope this design can bring a better gaming experience, reduce frustration, and lower the barrier to entry.

Previously, the server was written in C, which required a lot of work to update and add features, and the server was prone to crashes.

This time, I focused on rewriting the server engine in Python, which will make future updates much easier.

At the same time, Python allows adding more algorithms, which is especially suitable for SSW.

Soliciting feedback now. Please visit the new forum:

https://bbs.xyz-soft.com/topic/50381/%E9%87%8D%E5%88%B6%E6%94%B9%E8%BF%9B%E6%84%8F%E8%A7%81%E9%9B%86%E4%B8%AD%E8%B4%B4/58