Age of Strategy Forums

Funny we are working on moving in-code units to jsons and i open a topic to turn jsons to java code lol.

reason:
- jsons are needed for modding, and some mechanics only work on json coded units.
- drawback: it makes loading the game slow, as parsing all jsons (as there are getting many) takes time (actually much time)

So i thought of a java method that calls
- (existing method) the loading of all units from json
- (existing method) makes the generated java objects (units/techs)
- (new method) creates a .java file that contains all object variable fillups (setting booleans, setting integers, strings, setting arrays) like it were an "init" code for all units.

As a result it will generate a .java code i can put into the app code, so on loadup it will cost to load (many hundreds of units) only in a few secs - now it is much slower 40-80 secs (depending on device and game alternative, slowest if AOF since it has the most jsons)

the logic would only load units from json code that
a) is not exists in this "generated" code,
b) the generation time is older than the json file date to be parsed.
so it will be enough to generate occassionally when gets slow again on the many changes

This is nice task for any java code learners - feel free to volunteer - iwould be very happy - thanks!

daniel

Hey, I've a better idea. A way to optimize the game even better. Let's load only some "most" used units at the start and the rest before the campaign/map loading screen. It'll reduce the time significantly.
Eg: I'm playing "x" map
The creator has used only 20 types of unit.
So only that many units will be loaded at the loading screen of that map.

This will not only remove the long time to open the game on start but rather it won't take much time to load and open a map. The game will only cache units which are necessary and that won't be too much.

For multiplayer
It can be the same

For map-editor
Here is where we'll have to compromise. We'll have to cache all units as soon as we click the map editor button and then display a loading screen.

And to save some time for map-editors.
We'll only cache some basic units which are used the most.


This way the game will be heavily optimized and it can be a permanent solution. Will require lot of your coding though.
I'm sorry but I dunno much about Java, any C related work then I'm in.

not good as ai will chose from any units.
also upgrades section also needs all units.

pleasae keep this thread on my original idea.

thanks.

Are You sure it's really that long?
It takes me 28 seconds to load AoF.
~7 s initializing finished
~19 s unit definitions finished
~24 s loading units finished
~28 s the game loads (images, sounds, help finished)
Initialization - ~7s
Loading unit jsons ~12s
Processing units (is it creating bonus lists etc?) ~5s
Loading graphics, sounds ~4s

Well, whatever loading time could still use some boost.

To speed things up by preprocessing I always thought tabular form would be most efficient.
Any json, xml, ini reader first needs to read file, split it by meaningful text special characters, create list of fields names with value, assign to correct class Field, cast value to correct type.
As reading it takes much time i wonder if lists of fields values won't be faster.
So instead of 3 files each with:
"hp":"someHPValueX",
"power":"somePowerValueX",
"speed":"someSpeedValueX";
We have one (possibly binary) file with:
someHPValue1,someHPValue2,someHPValue3
somePowerValue1,somePowerValue2,somePowerValue3
someSpeedValue1,someSpeedValue2,someSpeedValue3
Without field names or with them as first column, but with purely code generated file it's always in the same format, so field names are not needed.

sure but that case modders will fail to edit them as files - so we will need to make a stt "editor" too.
and a code generation will always be faster than any kind of file structure.

I was not thinking of leaving the json structure entirely. Just gave an opinion (which by the way is pretty bad for java, as I read something about it).

Isn't what You are talking about already in some libraries like this: jsonschema2pojo ?

no, i need something like this:
json:
to be like this for each json:

About the link - Sorry, I haven't read it carefully enough (though it could generate object definitions too, not only classes).

About the code sample -isn't it complete going back to previous state?
I don't really know what this repeated condition stands for, nor where it's used.
Wouldn't it be better to just generate object definitions like that?
SomeKindOfListOfObjects.add(
new Object(){
attribname = value;
attribname2 = value2;
}
)

sure, that is also very good. moreover: better

to be more specific, we need filename-obj pairs:

Do unit class fields have getters?
Is there some other values returned from unit class?

If it was purely neaningful parameters, then beans could be used. It has methods to list field values.

they (mostly) have getters.
some other values returned from unit class - what do u mean?

Unit object would need to be properly serializable.
So any additional fields which are not supposed to be serialized needs to be moved to child class.

for jsoning the whole class is already needed to be serializable. so it is ok.