Remove the CPU cost of having memory and scale available memory akin to CPU
-
If it's just a documentation issue, sure. The documentation should be better organized.
It's not about gameplay benefits, at least not directly.
The way you structure your memory has an impact on its deserialization cost. That is reality. It is physics. You can't just handwave it away and say "well, I should get that for free!" You can store 1MB of data that doesn't cost very much to deserialize, or you can store 20KB that costs a huge amount to deserialize. If you don't pay that cost, then who? The servers have to deserialize your memory. It's either charged to you or it isn't, and if it isn't, well, then the players won't be aware of that cost, and they'll structure their memory in a suboptimal way, and we'll get 20 second ticks because no one understands what the true costs are.
The tutorial has you using at most... three? memory values. All I can recall is the state variable for the creep that controls whether it's dropping off. That's hardly leading you down a garden path, and a single value per creep is not going to work.
Look, I'd love to get 200KB of memory and a free deserialize step. But I know that's not going to happen because deserialization has a CPU cost and someone has to pay it. And it should be me that pays it, since I'm the one that decides what goes into it. Putting the responsibility on the players means that we all benefit from faster tick times.
-
"a single value per creep is not going to work" should be "a single value per creep is not going to be any sort of problem".
-
So while you agree that it doesn't benefit the game in any way, or at least can't come up with any reason how it does, you say that it should stay as it is anyway becuase in your guess otherwise the game will, I don't know what, financially collapse? Tick will become 18 seconds long? Either of this is a business issue, on which neither of us has competency or necessary knowledge to discuss with any merit (unless you are one of the devs and have access to business numbers), so let's stay at discussing what we can be certain about - gameplay.
But as much as I would like to, there is just nothing else for me to add in that regardas you didn't raise any gameplay points to tackle. Best I can do is reiterate that this is creating an uneccessary learning curve without apparent benefit which is not good for new players in any way shape or form.
-
The gameplay benefit is the same as the reason for limiting CPU. Your code has costs. You should be charged for those costs. You should optimize your code to reduce those costs. There's no reason to optimize for costs you can't see.
-
To reiterate what you said is: "we need to put the artificail cpu cost in that doesn't make sense from gameplay perspective but we do so for [business reasons]" and outside of devs we are not in position to make or suggest that call.
And if were to read the suggestion entirely, and the replies, no one is suggesting to remove limits on memory, quite the opposite - limit it more and make it scale with GCL.
-
It isn't an "artificial cost". It exists. It is a real cost. You can affect the cost through the way you use memory. Therefore you should pay the cost.
-
Can somebody please provide a link with a good and full explanation how object design affects JSON (de-)serialization times/load and how that can be minimized?
-
I don't have a link to a doc handy or anything. The short of it is that more objects cost more to deserialize.
So as a trivial example, storing a path as 50 RoomPosition objects, i.e. 200 discrete values (the object itself, as well as x, y, roomName) is less efficient than coming up with a way to encode that path as a single string.
Note that in that case you will still pay a cost when deserializing that path to its final form. The cost you're saving is the per-tick deserialize cost; you now have a new problem, of course, in writing an efficient mechanism for transforming that value back into something you can use. But you probably don't need every path you've cached, every tick, so even an inefficient algorithm for using the value is going to see a benefit over storing the raw RoomPositions in a large cache.
(I don't even bother with this yet, I just store the raw RoomPositions. But I'm aware that that won't scale.)
As for serialization, good news! That actually is free. It occurs after you return from your loop.
-
So the most performant approach would be to save it ALL as one large string and use something like an adress dictionary and areas having a fixed width or the like, just like hard drives are doing it .. !?
Sounds fun. Hardest question is how to manage that adress dictionary. In a performant and convenient way.
-
Yes! And if you go that far, you could use RawMemory and not even pretend to be using JSON.
