Optimize the web apps, or build a better solution - Under Study

#1 Eingetragen von Kaetemi vor 3 Jahren [en]

Based on my measurements, your web apps take between 1 and 2 seconds on every page load. This is an unacceptable latency, especially in gaming.

Studies have shown that for every 100ms of action delay, sales will drop by 7%. (See https://web.archive.org/web/20200507112031/https://www.akamai.com /uk/en/about/news/press/2017-press/akamai-releases-spring-2017-st ate-of-online-retail-performance-report.jsp.) Though, I suppose the proof is in the pudding.

---

Kaetemi

#2 Eingetragen von Ulukyn vor 3 Jahren

{translate}

Please send us your measurements and the conditions under which they were taken so that we can see how to improve them.

For the link, be careful, it is not a reliable study, Akamai is a company that provides fast hosting and simply says that it can lower by 7% but without proving it. It is purely marketing

#3 Eingetragen von Sinvaders vor 3 Jahren [en]

{translate}

Just open any ARK related thing in-game, and you'll see that is slow, no need for any measurements to notice it.
Example: marauder teleport crystal.

#4 Eingetragen von Kaetemi vor 3 Jahren [en]

{translate}

Eh, these are well-known facts in the industry. Especially in games, any responsiveness delay above 300ms will lose you players. Web apps are a bad strategy if you can't ghost the interaction locally.

Here's another article. There are many more similar studies.

https://www.forbes.com/sites/steveolenski/2016/11/10/why-brands-a re-fighting-over-milliseconds/

Research suggests that 25% of people will abandon a website that takes longer than 4 seconds to load. Amazon found that just 100 milliseconds of extra load time cost them 1% in sales. Those statistics, as profound as they are, pale in comparison to video buffering.

Users hate video buffering. Just one instance of buffering decreases video consumption by 39%. This is a real problem for companies in the video distribution space. And since all brands are media companies today this pretty much applies to everyone.

I'm on a 250 Mbps fiber connection. With 5ms ping to Cloudflare, and 250ms ping to the Ryzom server. You've got plenty of milliseconds left to stick below 300ms. Hell, even sticking below 500 ms would be a massive improvement.

4 mal geändert | Zuletzt geändert von Kaetemi (vor 3 Jahren)

---

Kaetemi

#5 Eingetragen von Ulukyn vor 3 Jahren [en]

{translate}

The game engine itself has major optimization issues. You can be killed several meters away from a monster because of the latency. Long texts take forever to reach the client, while web apps display the same content in 30x less time. Not to mention the fact that each player runs at different speeds depending on their internet connection.

All these problems are part of the Ryzom Core engine and you never worry about them, although you will agree that it is much more annoying than a webapp that takes 500ms to display. Of course, this does not mean that we should do nothing. Just that we use webapps in contexts where latency is less important than in a combat session.
Moreover we use more and more lua code to reduce the reaction time of the interface of the new webapps

#6 Eingetragen von Kaetemi vor 3 Jahren [en]

{translate}

Ulukyn

Long texts take forever to reach the client, while web apps display the same content in 30x less time. Not to mention the fact that each player runs at different speeds depending on their internet connection.

All these problems are part of the Ryzom Core engine and you never worry about them

No, there is a ticket for it.
https://github.com/ryzom/ryzomcore/issues/628

(Besides, I am more focused on getting RC in the hands of more developers at this point. Lower the time to get a dev shard running. Not in the business of trying to do everything by myself.)

The running speed is already fixed in the latest Core, but it's a breaking change, so excluded from the merged batch. The server was attaching server timestamps to client positions, which caused jittery player movement under the right conditions.

3 mal geändert | Zuletzt geändert von Kaetemi (vor 3 Jahren)

---

Kaetemi

#7 Eingetragen von Ulukyn vor 3 Jahren [en]

{translate}

Cool :)

The ticket is not associated with any commit. Can we have the list of associated commits to see if we can apply it?

#8 Eingetragen von Kaetemi vor 3 Jahren [en]

{translate}

Ulukyn

Cool :)

The ticket is not associated with any commit. Can we have the list of associated commits to see if we can apply it?

For the additional protocol? No implementation yet. (As I said, other priorities.) It's just a ticket. It's fairly easy to implement, though.

For the running speed:
4407fc29708aaffb451e9d578263f163f874863c
92bfb0aafbd5fbc93d157eb0f521fdc36190b65e
d07e2194395b4bcbaacff817fc616153c07cfa64
20ed0a4412437fc7d2013e781eabce02b1abbb9e
5b22e0950a65d9080dd48aa69c52542c94278ca2

Zuletzt geändert von Kaetemi (vor 3 Jahren)

---

Kaetemi

#9 Eingetragen von Kaetemi vor 3 Jahren [en]

{translate}

Ulukyn

You can be killed several meters away from a monster because of the latency.

This is because the LCT is flat (1s), regardless of distance, and is tuned for the refresh rate of any (read: far) mobs. It's a lousy flaw, but doesn't affect action/attack latency itself. Action response time is not really affected here.

Two potential options to investigate, though. Move to a smooth radial gradient for the client-side LCT on positions (assuming the peak update interval is consistent by distance). Or estimate the client-side distance on the server-side when mobs attack (less interesting, because it'll become too easy to run away).

---

Kaetemi