RickySpanish, on 10 May 2018 - 04:20 AM, said:
I can definitely get behind the sentiment of "kids nowadays!"

but I think the ideal solution lies somewhere in the middle. For most games, building your own engine is impractical. Look at the the evolution of textures in your modern graphics engine - in ~1998 they were 128x128 images packed into .wad files in Half-Life. Now, they are materials governed by real world properties, often made from several different textures each describing the exact value of a property at a per-pixel level of accuracy. You've also got the recent explosion of games onto anything with a screen and a processor, which all have their own APIs and hardware to develop for. Thus, it's not unreasonable for developers to glue blobs together to make their game. BUT! As you point out, you run the risk of not fully understanding the thing you have built or rather, its underlying technology. Unity definitely is an expedient development tool, but it has some serious downsides which can give your game that "Unity" feel. I do get that vibe from BT, and yeah I sorta wish UE had been used instead, but not everyone understands its beauty or cpp for that matter.
With all that said, have you *seen* the amount of json data in the game's streamingAssets folder? I do wonder if maybe someone is reloading portions of that more often than is needed, and perhaps that's contributing to the slow loading times...
were still using the s3tc formats that were supported by my voodoo card. new formats exist (smartphones use them), and they are far superior formats, but because the current ones are good enough and support is wider, they often get used instead. only real thing thats changed is the resolution and also the number of bitmaps used for a material. shader programs handle all the blending. its not even new technology, its actually matured a lot. you can throw memory at the problem until your game looks pretty. you can do a smart system where uncompressed textures are used and then compressed into whatever the best supported format is, cache them, and greatly reduce load times, or you can use the ones that have been around for an eternity and have pre-compressed textures and reduce load times.
how files are archived doesnt really matter. most games that use archives, you can get into them just changing their extension to zip (incidentally it works in mwo). wads were just simple container formats. ive done some quake modding so its not really that complex. they mostly do it for organization and to reduce size on disk (especially with smaller files which have to allocate one allocation unit which is many times larger than the actual content of the file) and load times when compressed files are used. for many formats the cpu can decompress files faster than they can be loaded. bt probibly rushed out the release before they had time to put a little spit and polish on their file system. ksp has gotten its load times down a lot, but theyve been working on it since 2013.
one of the things that bugs me is how a simple system, like ammo switching, cant be done because people dont understand the code. its not like you are writing collision detection code or a bone based animation system, or ik, or even ui code. and ui code can be a bloody nightmare. they can do that but cant fix a simple problem like ammo switching. all your doing is say make the weapon do x and use y ammunition if a user does z. its like they dont know how to write an if statement. it just screams "we completely mismanaged our code" at me.