4 ms·

Should mention Kerbal Space Program in this context. Rather than deal with complicated IO, moving data between disks and ram, the devs just loaded absolutely ev

Should mention Kerbal Space Program in this context. Rather than deal with complicated IO, moving data between disks and ram, the devs just loaded absolutely everything into memory at program start. This had all sorts of trickle-down benefits. In my experience, many Linux versions of that huge game were more stable than basic office software.

badpun 4y ago
That's pretty standard approach in games. This negates problems with loads during gameplay potentially making game choppy, and also makes you aware of your total maximum memory budget (important esp. for consoles) - whereas, with dynamic loads and mallocs, you'll only find that out via extensive testing.
- sandworm101 4y ago
  Not unless your game is less than a few gigs in total size. The average size of a 3d simulation game is much larger than the 8/16gb of memory on typical gaming rigs. KSP loaded literally everything, every texture, at startup. The only time the drive was touched after that was for saves.
z3t4 4y ago
KSP (the original) use the Unity engine. When the original devs quit, the game got more and more buggy, to the point it was unplayable, kept crashing every other hour or so... I played without quicksaving for a more tense experience - and the crashes ruined that.
- LtdJorge 4y ago
  AFAIK it still uses Unity
  - ceejayoz 4y ago
    It's pretty rock-solid on my M1 Macbook these days, too.
    - subw00f 4y ago
      Never had a crash with my M1 (8gb RAM), although it's pretty choppy even with nothing else open, especially if I go into maneuver mode zoomed out to show other planets.
p_l 4y ago
It also made lack of 64bit version a very thorny problem for a long time
- yellowapple 4y ago
  Not for us Linux users, who had a 64-bit version since pretty much day 1.
Cthulhu_ 4y ago
I would have assumed that video game engines would have solved the problem of loading assets dynamically / on demand already, I guess not. It reminds me of Cyberpunk's bad PS4 / xbone release and issues, where a famous clip on the internet shows assets not having loaded yet during a cutscene; again, I would've thought loading assets was a solved problem.
- hotpotamus 4y ago
  There's a talk by one of the developers of Crash Bandicoot of all the hacky (and brilliant) things they had to do to get the game to load quickly off the (2X?) CD-ROM into the very limited RAM of the Playstation 1. https://www.youtube.com/watch?v=izxXGuVL21o https://www.youtube.com/watch?v=izxXGuVL21o
- dj_mc_merlin 4y ago
  Loading assets in a simple, naive way is indeed solved. If you want "next-gen graphics", you need to push against the limit of your system, much as always. That is always tricky, new techniques are being developed every day, game studios have departments dedicated to finding new and better ways to stream data to-and-fro as needed.
- WorldMaker 4y ago
  In large part, while a "solved problem" in aggregate, every engine has different solutions in play. In part, because of trade-offs baked into engine assumptions. It's certainly possible no two engines will ever agree on asset loading due to such tradeoffs and how engines themselves are built/optimized. In part, because there's still not much coordination between different game companies and few shared libraries/middleware/"content/asset pipelines". Think about how many bundlers there are in JS today that we know of because of open source (and HN headlines about them) and multiply that by how proprietary most game companies still see every bit of their code in 2022 and generally avoid HN headlines about low level details of their tech stacks (for "competitive advantage").
throw0101a 4y ago
> Rather than deal with complicated IO, moving data between disks and ram, the devs just loaded absolutely everything into memory at program start. Don't most games do this at some level? That's what the whole "loading screen" is for: bring in all the bits for the level (or whatever) in questions so there's less chance of a I/O hiccup during gameplay.

badpun 4y ago

That's pretty standard approach in games. This negates problems with loads during gameplay potentially making game choppy, and also makes you aware of your total maximum memory budget (important esp. for consoles) - whereas, with dynamic loads and mallocs, you'll only find that out via extensive testing.

sandworm101 4y ago
Not unless your game is less than a few gigs in total size. The average size of a 3d simulation game is much larger than the 8/16gb of memory on typical gaming rigs. KSP loaded literally everything, every texture, at startup. The only time the drive was touched after that was for saves.

z3t4 4y ago

KSP (the original) use the Unity engine. When the original devs quit, the game got more and more buggy, to the point it was unplayable, kept crashing every other hour or so... I played without quicksaving for a more tense experience - and the crashes ruined that.

LtdJorge 4y ago
AFAIK it still uses Unity
- ceejayoz 4y ago
  It's pretty rock-solid on my M1 Macbook these days, too.
  - subw00f 4y ago
    Never had a crash with my M1 (8gb RAM), although it's pretty choppy even with nothing else open, especially if I go into maneuver mode zoomed out to show other planets.

p_l 4y ago

It also made lack of 64bit version a very thorny problem for a long time

yellowapple 4y ago
Not for us Linux users, who had a 64-bit version since pretty much day 1.

Cthulhu_ 4y ago

I would have assumed that video game engines would have solved the problem of loading assets dynamically / on demand already, I guess not. It reminds me of Cyberpunk's bad PS4 / xbone release and issues, where a famous clip on the internet shows assets not having loaded yet during a cutscene; again, I would've thought loading assets was a solved problem.

hotpotamus 4y ago
There's a talk by one of the developers of Crash Bandicoot of all the hacky (and brilliant) things they had to do to get the game to load quickly off the (2X?) CD-ROM into the very limited RAM of the Playstation 1. https://www.youtube.com/watch?v=izxXGuVL21o https://www.youtube.com/watch?v=izxXGuVL21o
dj_mc_merlin 4y ago
Loading assets in a simple, naive way is indeed solved. If you want "next-gen graphics", you need to push against the limit of your system, much as always. That is always tricky, new techniques are being developed every day, game studios have departments dedicated to finding new and better ways to stream data to-and-fro as needed.
WorldMaker 4y ago
In large part, while a "solved problem" in aggregate, every engine has different solutions in play. In part, because of trade-offs baked into engine assumptions. It's certainly possible no two engines will ever agree on asset loading due to such tradeoffs and how engines themselves are built/optimized. In part, because there's still not much coordination between different game companies and few shared libraries/middleware/"content/asset pipelines". Think about how many bundlers there are in JS today that we know of because of open source (and HN headlines about them) and multiply that by how proprietary most game companies still see every bit of their code in 2022 and generally avoid HN headlines about low level details of their tech stacks (for "competitive advantage").

throw0101a 4y ago

> Rather than deal with complicated IO, moving data between disks and ram, the devs just loaded absolutely everything into memory at program start. Don't most games do this at some level? That's what the whole "loading screen" is for: bring in all the bits for the level (or whatever) in questions so there's less chance of a I/O hiccup during gameplay.