Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Planet Search Overhaul (07/13/24)

Pages: 1 [2]

Author Topic: Game engine optimization  (Read 2766 times)

Wyvern

  • Admiral
  • *****
  • Posts: 3835
    • View Profile
Re: Game engine optimization
« Reply #15 on: April 12, 2023, 08:20:48 AM »

The other thing I'd want to note is that mod quality can have a significant effect on game stability. There are some mods that I generally trust - LazyLib and Console Commands, Interstellar Imperium, Diable Avionics, Nexerelin... And there are some mods that I have had consistent issues with and eventually stopped using because they tended to break things and/or crash the game. (Or, in one case, the mod literally had "added malware" in its change log, and I'm sorry, but no.)

So if you've jumped directly from 'base game' to 'all the mods', it's possible that part of your problems are due to one or two specific mods that are messing things up. (Figuring out which mod or mods are giving you trouble can be tricky though.)
Logged
Wyvern is 100% correct about the math.

basileus

  • Commander
  • ***
  • Posts: 163
    • View Profile
Re: Game engine optimization
« Reply #16 on: April 12, 2023, 11:04:23 AM »

The excessive time to be ready at the title screen does sound like it could be down to JIT script compilation, but the excessive time to save the game does sound like either a Serialization / Compression issue or the documented memory leak from Java7.  Did you follow the instructions to upgrade to Java8?

I have to say that I've never understood why video game developers seem stuck on traditional saving and "save files."  Keep everything in memory and then pause everything to perform very expensive serialization for the entire Model when saving / autosaving.

I suppose a small subset of players appreciate the human readable XML save files so that they can edit them with a common text editor.

If it were me, I would convert my Model to an in-memory database that I kept sync'd with a persistent database.  When the player called for a manual save, I would detach the sync, copy the persistent database in another thread to establish a save point, and then replicate the changes from the in-memory database to the primary persistent database.  Eventual Consistency in the parlance of databases.  There would be no need for complex and adjustable autosaving rules because the game would be able to restore itself to almost the exact point of a crash simply by loading the primary database.  Saving would be instant from the perspective of the player.

Databases tend to be vastly more performant at I/O than JSON/XML serialization, so loading times would be faster, too.  The proliferation of NoSQL databases and SDKs makes it far more approachable than it might have been a decade ago.  A Document database, for instance, wouldn't be particularly difficult to reason about and is flexible in terms of schema as a game evolves.
« Last Edit: April 12, 2023, 11:06:36 AM by basileus »
Logged

Schwartz

  • Admiral
  • *****
  • Posts: 1454
    • View Profile
Re: Game engine optimization
« Reply #17 on: April 12, 2023, 11:19:29 AM »

SS shovels a lot of data to and from the system Temp folder if I remember right, which accounts for some of the time. And this is proportional to the size and number of mods you have also. I noticed this when symlinking the Temp folder to a regular HDD one time to try and reduce SSD writes, and Starsector took suddenly a good deal longer to start up.

Generally the game is decently optimized, but you're stressing a system with dozens of mods (some of which can be performance nightmares in their own right) and it's not fair to judge the game on those grounds. By the way, I played heavily modded games and they were "fine", talking 8 faction mods, GraphicsLib, a dozen utility mods and so on. There was an issue with lingering debris fields & lag that was fixed, and there may be possible performance holes in a particular mod you're using as well.
Logged

Euphytose

  • Captain
  • ****
  • Posts: 478
    • View Profile
Re: Game engine optimization
« Reply #18 on: April 13, 2023, 10:53:23 AM »

I played with like 15 mods at most and the game took slightly longer to load and save but that was it.

Played with a few faction mods but not THAT many I guess.

And I only have 8gb of RAM.
Logged

Wispborne

  • Captain
  • ****
  • Posts: 482
  • Discord: wispborne
    • View Profile
Re: Game engine optimization
« Reply #19 on: April 14, 2023, 09:26:16 AM »

OP still hasn't said what mods they're using or how many. "A few mods" could be 15 or it could be 70.

Did you do everything in this guide? https://fractalsoftworks.com/forum/index.php?topic=25974.0

Yes, as i stated in my post, all done.

You said "I followed the optimization guides (edited vmparams)".
The optimization guide has two steps; editing vmparams is only one of them.


As Alex suggested, most of the game's loading time is typically loading textures (ships/weapons), which is mostly single-thread CPU bottlenecked, unless your memory/hard drive is very slow.
Mods that add lots of ships/weapons/icons have an outsized effect on loading time, compared to something like a pure-code QoL mod.


If it were me, I would convert my Model to an in-memory database that I kept sync'd with a persistent database.  When the player called for a manual save, I would detach the sync, copy the persistent database in another thread to establish a save point, and then replicate the changes from the in-memory database to the primary persistent database.  Eventual Consistency in the parlance of databases.  There would be no need for complex and adjustable autosaving rules because the game would be able to restore itself to almost the exact point of a crash simply by loading the primary database.  Saving would be instant from the perspective of the player.

Not saying this wouldn't be an improvement, but it also uses more RAM (and many players are already scraping the ceiling of their systems) and is far more complicated, which means more bugs and more dev time.

At least, I assume it'd use more RAM. The current system only uses what's needed and dumps the serialized stream into a file without having anything duplicated in memory. I'd absolutely be in favor of your system, games with async saving are fantastic, but it certainly has downsides over the brutal simplicity of the current system.

I suppose a small subset of players appreciate the human readable XML save files so that they can edit them with a common text editor.

I've saved my own and others' saves from being bricked by mods by being able to edit these files, so yeah, this is a huge upside.
« Last Edit: April 14, 2023, 09:27:48 AM by Wispborne »
Logged
Mod Managers: TriOS & SMOL | Mod: Persean Chronicles | Tool: VRAM Estimator | Tool: Forum+Discord Mod Database | If I'm inactive for 3 months, anyone can use any of my work for anything (except selling it or its derivatives).

Schwartz

  • Admiral
  • *****
  • Posts: 1454
    • View Profile
Re: Game engine optimization
« Reply #20 on: April 14, 2023, 12:57:37 PM »

Readable save is very useful for cutting out unwanted mods that can't otherwise be removed, if you're willing to invest the time. Also, SS doesn't use *that* much memory. It's usually happy with 4GB heap even with a ton of content mods.
Logged

Zordiark Darkeater

  • Ensign
  • *
  • Posts: 38
    • View Profile
Re: Game engine optimization
« Reply #21 on: April 15, 2023, 02:12:58 AM »

Readable save is very useful for cutting out unwanted mods that can't otherwise be removed, if you're willing to invest the time. Also, SS doesn't use *that* much memory. It's usually happy with 4GB heap even with a ton of content mods.

Im playing with 115+ mods had to set my Vmparam to a minimum 12gb to not have issues.
The game has a LONG loading time after the game starts arround 2.5-3 mins. but after that 0 issues. can play for like 6+ hours and still works fine lol
Logged
Pages: 1 [2]