Hey I wouldn't worry about that. 'Game starting delay' is the last opportunity I get to sip my tea before it goes cold with that nasty white froth floating on it nine hours later.

If I may ask, what is the expectation of load times in a worse case on single core?

I should think that a close generalization should be possible, or lacking that, the goal of how long they would like to see it take in a worse case on single core. I do take your meaning though.

Get rid of ALL tiles. I only use the cloth map anyway.

Seriously, the tiles CAN be delayed until later, and you can use the cloth map until they are available.

Amen!!! We'll deal with the loading times!!! Just put some info worth reading on the loading screens and I don't think anyone will mind.

The question is not load time of the vanilla version of the game as a binary would be generated only when the game will be updated but rather load time for "mod & modding intensive players".

Will the binary be "wholly" re-generated every time we launch a new game after changing our mods and/or mods option?

Thanks.

But how do you generate a random map with stuff on it if you don't know what the "stuff" can be?

The tiles aren't just graphical, they contain things that can affect gamplay. It's data that other parts of the game will need. Even the cloth map has to know that I modded in a "Tower of Infinite Pwnage" so you can see that something is there on the map.

If there's some things that aren't needed right away you could try to do lazy initialization, but for something like this it's going to be a lot more complicated then simply caching the parsed XML result as a binary. The second load will be just reading in the binary, which is blazing fast even on a slow PC.

So if you don't mod, you'll only have to worry about the delay after updates. Downloading a mod will make you worry about it more often, and actually writing a mod will give you more frequent delays. 

But! The game could cache the core XML files anyway, then always load mod XML files uncached and combine them in memory. That would still be a significant performance boost, and you wouldn't see large delays due to the core game XML being reparsed just because you added a mod. (Can you tell I deal with this stuff a bit at work? )

Frogboy, why isn't this an option?

https://forums.elementalgame.com/390597

I don't know what your setup is but it seems like the obvious thing to do to fix the load time?

removing content (apart from really unnecessary/redundant stuff, which I assume frogboy is talking about) now does seem kind of pointless when the game is aimed to be moddable and thus should get more content very soon.

that leaves only optimization. as for xml parsing speed, don't blame xml. At work we parsed around 100mb of xml in under half a minute (5 files, each 18mb). and this was using the standard xml deserialization from .net, not some super-parser

so my guess would be its good old windows filesystem.. fat and ntfs are notorious for being ultra slow, in my experience especially for reading lots of small files. so one BIG xml with everything in it possibly would be way faster (just try a 'cat * -R > bigfile.xml' if you have cygwin or a linux box and parse that).

if the difference is as large as I assume, binary serialization would make a huge difference (less files, less data and faster parsing).

MAYBE just zipping the xml files together in one zip would even be faster (despite having to unzip on load) if the real bottleneck is I/O and not parsing

or you could just use profiling to find the real bottlenecks instead of just trying what helps

and loading just a random amount seems a bit.. cheap. I think the game should be capable of loading at least the threefold the current data within a sane amount of time - if not, the game should be optimized, not content just add limits.

One thing I have always thought was needed is a simple progress bar. I do not care if loading/world building takes a while BUT it there is no feedback you start wondering if the game has simply hung.

So loading screen should have some visible method of showing me that its doing something. Then if it takes a minute at least I do not start to think something has gone wrong.

FKN

William

This is what's needed I think. Simple, easy, and it lets people know the game hasn't hung.

I strongly disagree with your opinion:

the community wants moddable games. the easier modding is, the better the community content gets (as more people will have the skills to create something). proprietary formats where widely used in the past when space (1.44 mb, 750mb, 4.4 gb) where hard limits and no modding was planned. adding modding, the need for easily understandable, standardized formats arises, also to allow users to create their own tools, editors whatever. modding with proprietary formats is possible but very limited as everybody just has to stick to the given tools (which often aren't very user friendly). this essentially removes a large part of the community as prospective modders.

xml is by far the easiest, most standardized data storage to be used by a modding community. the only real cons are speed and size, and only the first is really a concern nowadays. so instead of suggesting to throw everything (all the advantages and the few minor disadvantages) out of the window and start building good old static games, I'd prefer they stick with xml and learn to optimize its speed or use some caching function (which can be used by every new game). This will not diminish the flexibility of the game as your suggestion most probably would.

ora

+1 For this idea.  Show me the cool stuff you are doing and I will wait for it.

Sammual