I have been updating Star Explorers quite a lot recently. Ever since the Realms Deep event in 2020, I found there was more interest in Star Explorers than in my other game Paradox Vector, and it caused me to focus on improving and updating the game. You can see about a third of a second of Star Explorers around the 36 second mark in this Realms Deep trailer...
Aside from adding lots of new features, like an alien city, meteor strikes, tornadoes and other emergent systems, I have also wanted to invest some time in refactoring some of the old, foundational scripts that were written over 7 years ago. These systems were never really revisited, and some notable bugs would remind me every so often that the game was metaphorically sitting on a pile of horse manure.
A Two Week Trial
So, I finally put my thoughts together and decided to do a small experiment. I would start a fresh project and import only the game assets, like textures, 3D models and sounds, writing the actual script from scratch. I allotted myself two weeks to accomplish this task, and would decide on any long term changes after this two week period expired.
I did not expect to get very far in two weeks, but I felt that was enough time to figure out how things would go. Well, they went pretty well. I was able to rewrite many of the game's basic systems in a much more efficient way than I had 7 years ago. This highlighted to me many of the redundancies and problems that were plaguing my current script. It also gave me the confidence I needed to actually go in and change some of those scripts.
While this new version of Star Explorers will probably never be played by anyone, it has served an important purpose and will contribute greatly to the future of the game.
A Two Week Trial
So, I finally put my thoughts together and decided to do a small experiment. I would start a fresh project and import only the game assets, like textures, 3D models and sounds, writing the actual script from scratch. I allotted myself two weeks to accomplish this task, and would decide on any long term changes after this two week period expired.
I did not expect to get very far in two weeks, but I felt that was enough time to figure out how things would go. Well, they went pretty well. I was able to rewrite many of the game's basic systems in a much more efficient way than I had 7 years ago. This highlighted to me many of the redundancies and problems that were plaguing my current script. It also gave me the confidence I needed to actually go in and change some of those scripts.
While this new version of Star Explorers will probably never be played by anyone, it has served an important purpose and will contribute greatly to the future of the game.
Here is an image of the totally re-written version of Star Explorers
Back to Square One
Now I have returned to the current testing branch version of Star Explorers, and have completely rewritten the galaxy save and load functions, based on this new approach. It still uses a lot of the same scripts, but the core of how the game actually works is totally different. A player may not notice it at all of course, other than having less crashes and maybe a little shorter loading times in some cases.
Specifically, I have taken a very new approach to saving and updating the galaxy information. Previously, when a player started a new game, it would generate a new galaxy, and write that galaxy's data to a file. This file would then be used to reload the galaxy whenever the player loaded a saved game, or traveled from a planet's surface back to their spaceship. The galaxy file was never altered after it was initially written, so that forced me to come up with an elaborate system of other files which stored any information that may have changed in the galaxy. So any stars or planets that were scanned would have to write new files with scan information. Then, when reloading the galaxy, each star would have to access these additional files, in order to update their skills (skills are just entity specific variables in 3D Gamestudio). This was a constant headache for me, as the system was so complex and interdependent, that any changes to the game would easily cause problems and lead to unforeseen bugs.
The new system has the same basic output, but handles the data completely differently. It again creates a galaxy, and writes the information to a file. That file is accessed and used whenever the player loads a game, or returns to the spaceship. However, instead of the elaborate system of supporting files, the game simply rewrites the galaxy file every time the game is saved, so entity skills are always kept up to date in that one, simple file.
It seems like a no-brainer in terms of how to save game data. However, when I started this project seven years ago, I had no idea how any of this was going to work. I did not even know star information/skills would have to change or be updated, so these things were written incrementally on top of what was already there. Since my galaxy save and load script “worked” I would simply write new scripts around what was already in place. Only years later could I look back and see exactly how problematic the whole system had become.
Valuable Lessons for the Thoughtless Programmer
Ultimately, this experience taught me something many veteran programmers will say quite often, that you should plan out your scripts before writing them, This is why design documents are important, thinking through how a system will work very thoroughly will save you a lot of time and effort in the long run. I have a background in art, not programming, and I have tended to take a similar approach in making games. Getting an idea, and pursuing it is fun, and can be valuable. But if you want to make a game *other* people can enjoy, you have to really make the effort to ensure it is functioning properly.
I am nearing a point where the new version is just about ready for play-testing. I'm excited and kind of scared, as bugs do have a habit of reaching players when they may have evaded my attempts to discover them.
Now I have returned to the current testing branch version of Star Explorers, and have completely rewritten the galaxy save and load functions, based on this new approach. It still uses a lot of the same scripts, but the core of how the game actually works is totally different. A player may not notice it at all of course, other than having less crashes and maybe a little shorter loading times in some cases.
Specifically, I have taken a very new approach to saving and updating the galaxy information. Previously, when a player started a new game, it would generate a new galaxy, and write that galaxy's data to a file. This file would then be used to reload the galaxy whenever the player loaded a saved game, or traveled from a planet's surface back to their spaceship. The galaxy file was never altered after it was initially written, so that forced me to come up with an elaborate system of other files which stored any information that may have changed in the galaxy. So any stars or planets that were scanned would have to write new files with scan information. Then, when reloading the galaxy, each star would have to access these additional files, in order to update their skills (skills are just entity specific variables in 3D Gamestudio). This was a constant headache for me, as the system was so complex and interdependent, that any changes to the game would easily cause problems and lead to unforeseen bugs.
The new system has the same basic output, but handles the data completely differently. It again creates a galaxy, and writes the information to a file. That file is accessed and used whenever the player loads a game, or returns to the spaceship. However, instead of the elaborate system of supporting files, the game simply rewrites the galaxy file every time the game is saved, so entity skills are always kept up to date in that one, simple file.
It seems like a no-brainer in terms of how to save game data. However, when I started this project seven years ago, I had no idea how any of this was going to work. I did not even know star information/skills would have to change or be updated, so these things were written incrementally on top of what was already there. Since my galaxy save and load script “worked” I would simply write new scripts around what was already in place. Only years later could I look back and see exactly how problematic the whole system had become.
Valuable Lessons for the Thoughtless Programmer
Ultimately, this experience taught me something many veteran programmers will say quite often, that you should plan out your scripts before writing them, This is why design documents are important, thinking through how a system will work very thoroughly will save you a lot of time and effort in the long run. I have a background in art, not programming, and I have tended to take a similar approach in making games. Getting an idea, and pursuing it is fun, and can be valuable. But if you want to make a game *other* people can enjoy, you have to really make the effort to ensure it is functioning properly.
I am nearing a point where the new version is just about ready for play-testing. I'm excited and kind of scared, as bugs do have a habit of reaching players when they may have evaded my attempts to discover them.
Here is the current Star Chart, with recently added color coding on stars and planets
Next Steps: Revisiting the Star Chart
The next plan is to take another close look at the Star Chart. Again, the Star Chart was written by a younger version of myself. It took it's approach very literally. Instead of just looking at the galaxy file, and plotting stars and planets according to that, the game actually created a separate database of star and planet information when the player scanned each heavenly body. This approach seemed so logical at the time, especially when the galaxy file itself could not be updated, and was based on the same set of limitations I described above. But now, instead of dealing with a separate, complex set of files, the Star Chart could simply take existing galaxy file information and use that to display its data.
Once again, this seems so easy and logical. But tell that to a guy who, seven or eight years ago, decided to write a procedural galaxy generation script with no previous experience and no idea how to do it.
The next plan is to take another close look at the Star Chart. Again, the Star Chart was written by a younger version of myself. It took it's approach very literally. Instead of just looking at the galaxy file, and plotting stars and planets according to that, the game actually created a separate database of star and planet information when the player scanned each heavenly body. This approach seemed so logical at the time, especially when the galaxy file itself could not be updated, and was based on the same set of limitations I described above. But now, instead of dealing with a separate, complex set of files, the Star Chart could simply take existing galaxy file information and use that to display its data.
Once again, this seems so easy and logical. But tell that to a guy who, seven or eight years ago, decided to write a procedural galaxy generation script with no previous experience and no idea how to do it.
RSS Feed
