devtrackers.gg
about 1 year
ago -
Strange Loop Games
-
Direct link
| 0s | foreign |
|---|---|
| 3s | hello everyone welcome to another Friday |
| 6s | strange Loop games stream here |
| 9s | um my name is Jens working as a game |
| 11s | designer for strange Loop and to get |
| 14s | through here today we have Alex and |
| 17s | Casper |
| 18s | Alex do you want to introduce yourself |
| 22s | yeah I'm |
| 26s | the game developer in uh |
| 29s | uh so G and Morgan mostly on technical |
| 33s | stuff and |
| 36s | so last |
| 39s | few months of working on channel |
| 41s | improvements so like |
| 45s | uh reduce |
| 48s | rendering time for chunk increase number |
| 52s | of charts we can render repair time |
| 56s | optimize |
| 58s | different things related to uh |
| 62s | chunk related objects like plans and |
| 65s | shops something like that |
| 69s | and oh |
| 71s | kind of such stuff |
| 74s | yeah so |
| 75s | one of our cool guys behind some of the |
| 78s | big optimization changes and Casper know |
| 80s | you've been working |
| 82s | quite in depth in this field as well |
| 86s | um well yes I've recently moved from um |
| 88s | or several staff work to help Alex with |
| 92s | optimization I've been mostly focused on |
| 94s | optimizing plants lately trying to make |
| 97s | them more lightweight so we can deal |
| 99s | with the huge number of plants we have |
| 100s | in Nico |
| 103s | yeah and I think with that we'll kind of |
| 106s | kick start on what everything everyone |
| 109s | wants to see in that is fancy new |
| 112s | changes and optimizations to General |
| 114s | gameplay |
| 116s | cutting into |
| 118s | screen sharing here |
| 121s | um you can see that I got the |
| 123s | specifications for |
| 125s | Casper that is doing the screen sharing |
| 127s | right now |
| 129s | um up in the corner hopefully it's |
| 132s | legible |
| 134s | and you wanna go through the world a bit |
| 137s | and |
| 138s | I'm gonna show it off yeah |
| 140s | and you can see a brand new VPS counter |
| 144s | always in game |
| 145s | aspirated |
| 147s | for today's stream now |
| 150s | in game for the local version |
| 155s | yeah which was |
| 158s | one of the one of the things that we |
| 159s | cooked up to kind of be able to present |
| 161s | the frames on screen in game so now you |
| 164s | have a graphical option for that and |
| 167s | we'll all make it a little bit more |
| 168s | polished neat and tidy and then shrink |
| 170s | it a little bit so it doesn't |
| 172s | take up that much of us |
| 176s | that much screen space as a checkbox in |
| 178s | the graphic options too |
| 180s | yes but we wanted to make it visible now |
| 182s | since we are bragging about our |
| 184s | optimizations so we want everybody to |
| 186s | see their frame count and those are the |
| 189s | things I am playing with |
| 190s | mostly pretty low but they are kind of |
| 193s | matching my Hardware although the |
| 195s | rendering is set to 400 meters which I |
| 198s | think in the previous versions of Eco |
| 200s | wasn't even possible to Crank It Up |
| 202s | Crank It Up that high yeah we have that |
| 204s | limited to 200 previously so we have |
| 207s | essentially doubled with our big |
| 209s | optimization changes we have a goal part |
| 213s | of that was to push out so you can |
| 215s | really see further out |
| 218s | and |
| 220s | to do that we needed higher higher |
| 222s | viewing parameters which also meant that |
| 225s | we also needed to optimize it a lot more |
| 227s | to be able to to support this |
| 231s | um |
| 231s | which is really cool I'm just |
| 234s | getting so distracted by the fact that |
| 236s | it's working so smoothly now uh with |
| 238s | this new higher uh view camp |
| 244s | yes I guess what we want to show the |
| 246s | most was the track test |
| 248s | yes passed pretty well the last time we |
| 250s | tried |
| 252s | so to show just that we don't only get |
| 255s | the high frame count when we are |
| 256s | standing in one spot but we can actually |
| 258s | drive around travel around and as long |
| 261s | as we are not flying at some crazy |
| 263s | speeds in admin mode then everything |
| 265s | stays pretty smooth |
| 268s | yeah so we have all those trunks loading |
| 270s | and unloading around us |
| 275s | yeah and as you can see there's still |
| 276s | there's still a couple of things that we |
| 278s | do want to improve on as it dips closer |
| 281s | to around 60 range |
| 283s | um as as that is one of our goals to |
| 285s | kind of keep above regardless of the |
| 287s | situation |
| 289s | but that's also dependent on Hardware a |
| 291s | little bit |
| 293s | but we have we have some pretty pretty |
| 296s | significant other improvements that are |
| 298s | being looked at as well with |
| 300s | Alexis spearheading into |
| 304s | yeah so |
| 307s | it's still work in progress and |
| 310s | they expect more fixes and |
| 313s | yeah Casper I'm not sure if you use uh |
| 318s | uh default plans rendering or optimize |
| 321s | it |
| 322s | no I already switched to our new plant |
| 325s | rendering so they are all all those |
| 327s | lightweight entity objects that's |
| 329s | actually why we can't see the |
| 330s | interaction prompts yet because that's |
| 332s | something that I'm working on currently |
| 334s | well it's almost finished because that's |
| 336s | all though all those plants are real |
| 338s | actual objects they have all the data |
| 341s | and stuff except since we updated to |
| 343s | make them into more lightweight versions |
| 345s | and the interactions are not fully |
| 348s | stable yet so I'm working on that it's |
| 350s | almost finished but it still needs some |
| 352s | polishing especially the visual Parts |
| 354s | like highlighting but yes yes I'm |
| 358s | currently running on that new version |
| 360s | yeah so if you uh take attention to the |
| 365s | detail uh sir now |
| 370s | instant plan spawning so no more |
| 372s | situation when you already load the |
| 374s | chunks but still wait while all plans |
| 377s | loaded |
| 379s | so now they appears at the same time as |
| 381s | chunk |
| 385s | yeah and you don't have this destruction |
| 388s | in the game process and actually uh |
| 392s | so main idea behind all these |
| 395s | improvements to increase rendering |
| 398s | distance to 400 meters is to uh |
| 404s | make a game more immersive because so |
| 408s | you don't |
| 409s | feel uh balance of the world so it feels |
| 414s | really like |
| 416s | um |
| 418s | a world where you can travel in any |
| 420s | direction and don't see like uh chunks |
| 424s | loading or |
| 427s | like white space |
| 429s | on edge of |
| 431s | this scene so |
| 435s | yeah |
| 436s | and yeah and and actually it uh also |
| 441s | good for screenshots because a lot of |
| 444s | things |
| 445s | we was requested many times so when you |
| 448s | go to Mountain and |
| 450s | want to make a good screenshot |
| 453s | it's not possible because you see edge |
| 456s | of the world |
| 458s | and now this new distance uh |
| 461s | it will be less likely you have such |
| 463s | situation |
| 465s | yeah |
| 466s | chance and to and that's been that's |
| 470s | been a big drive for us we we do want to |
| 472s | eliminate that |
| 474s | that so-called fourth wall a little bit |
| 476s | in |
| 477s | you should feel like you're in a world |
| 480s | you would never feel that you're |
| 481s | confined within this digital space where |
| 483s | you see |
| 485s | kind of invisible borders all around you |
| 488s | a bit more about the fluid environment |
| 491s | and you see the greenery kind of span on |
| 492s | in in the horizon |
| 494s | you see these impressive buildings |
| 497s | um |
| 497s | and as due to the um I know a lot some |
| 501s | people might have some concerns in |
| 503s | regards to structures and buildings and |
| 506s | when things are you know civilized |
| 507s | around your industrialized we were |
| 511s | trying to get some worlds imported as |
| 513s | well but due to the changes at the |
| 515s | moment we don't really have fully |
| 517s | migration systems between 9.7 and 10 so |
| 521s | it was tricky to to get |
| 524s | a more built up world |
| 526s | ly imported for uh |
| 529s | for more kind of technical testing but |
| 530s | this is one of the worlds that QA is |
| 533s | having when they're testing out |
| 535s | performance changes where we have bigger |
| 537s | Fields as you can see on the left there |
| 540s | and where you have a lot a large density |
| 543s | of certain crops |
| 545s | gonna see what potential performance |
| 547s | changes happens when we do |
| 550s | graphical changes or textural changes to |
| 552s | them as well as changing algebra disease |
| 555s | on objects |
| 557s | doing all kinds of |
| 559s | all kinds of testing to see how they |
| 561s | impact |
| 564s | now Alex on the subject of vast vast |
| 570s | large worlds where you see things on the |
| 572s | horizon we |
| 573s | we talked about loading for a bit over |
| 576s | on Discord here and there but you want |
| 579s | to kind of go over the concept of |
| 581s | loading and as as a general kind of |
| 583s | brief summary of why it's important and |
| 585s | then |
| 585s | where we're using it then yeah sure uh |
| 589s | so as you can see there are no |
| 591s | noticeable difference between uh 200 |
| 594s | meters in uh |
| 596s | our release version and 400 meters in |
| 600s | developed so main challenge for us was |
| 603s | to |
| 604s | maintain same or higher VPS |
| 608s | uh with increase the distance because |
| 611s | you have much more |
| 614s | things to render in scene in that case |
| 617s | and so uh that I know different ways how |
| 622s | we improved it |
| 624s | and one of important things is using a |
| 629s | lot system and actually it's widely used |
| 633s | in |
| 636s | game development and it basically means |
| 639s | level of details and |
| 644s | concept of this technique is to use less |
| 647s | detailed uh |
| 650s | objects on distance it usually depends |
| 654s | on size of this object on screen |
| 657s | so like how much space on screen take |
| 660s | this object and so if it very small you |
| 664s | won't see uh significant details uh |
| 668s | insignificant details anyway so we can |
| 671s | meet these details and use less |
| 674s | resolution textures less detailed |
| 676s | polygons and so it all reduces impact on |
| 680s | GPU |
| 683s | and yes so but because in Echo we have |
| 690s | fully Dynamic world with everything you |
| 694s | can change with your hands so it |
| 697s | basically beats builds from data |
| 701s | and every block is just like |
| 704s | some number |
| 706s | and we need to do it all in runtime |
| 710s | so uh it's not like so for example for |
| 715s | plans or for word objects we use it |
| 720s | there's lots of a long time it's it's |
| 724s | very simple so we can just add |
| 727s | a few models at some settings and then |
| 730s | when you move for a distance it have to |
| 733s | automatically decides which version of |
| 735s | files this model to use but in case with |
| 738s | uh channels |
| 741s | which consists from blocks which builds |
| 743s | in runtime and you can't take them |
| 747s | into game how we |
| 750s | had to develop our own system for the |
| 755s | subjects loading so it basically uses a |
| 759s | different level of details for blocks |
| 761s | and like we have |
| 764s | are less detailed with less polygons |
| 768s | with simpler textures blocks on distance |
| 774s | and then we used just cubes |
| 778s | for very distant chunks and so we |
| 781s | dynamically built this different level |
| 785s | of chance |
| 786s | depending on on distance and then we |
| 790s | have system which on demand builds |
| 793s | missing levels so if |
| 796s | when you just enter to the world it just |
| 798s | builds uh |
| 800s | uh simplified measures for distance and |
| 805s | then when you get closer to the Chart |
| 807s | then in run time builds uh more detailed |
| 811s | version of this chunk |
| 813s | and when you move far away from your |
| 817s | initial points and it builds less |
| 819s | detailed so it all works uh this way is |
| 823s | a fully dynamic system |
| 825s | and yeah it |
| 828s | lets us to |
| 831s | render this uh huge world with high VPS |
| 836s | with a minimal impact on utpu Hardware |
| 840s | so |
| 843s | it was a big Improvement |
| 845s | and |
| 846s | yeah and |
| 849s | actually we don't |
| 852s | load objects |
| 855s | for distance more than 200 meters like |
| 859s | in old version but it not not this will |
| 863s | because you usually only see a ground |
| 866s | onward distance and so if you have like |
| 868s | a workbench |
| 872s | or a distance you won't see it |
| 875s | but if you get closer it will load and |
| 877s | unload if you move away so yeah |
| 882s | there is was uh different uh kind of |
| 886s | optimization with limiting loading range |
| 889s | with depending on |
| 891s | view distance depending call now |
| 896s | uh |
| 897s | yeah actually it's everything about laws |
| 901s | yeah I don't think we |
| 903s | got a couple of questions |
| 905s | um |
| 906s | so um they for instance if a hundred |
| 910s | players comes in with this kind of Chunk |
| 912s | rendering kind of cranked up to Max and |
| 914s | the server then has to provide the each |
| 916s | layer all the chunk data |
| 919s | um is this this the performance gonna be |
| 921s | impacted due to higher higher kind of |
| 924s | impact on the server because it needs to |
| 925s | transfer more more information to the |
| 928s | clients or |
| 930s | um uh yeah uh actually it's correct it |
| 935s | will need to transfer more information |
| 936s | than before but as part of optimization |
| 940s | we also are Factory at server code |
| 943s | so now it may group chunks |
| 948s | are together for different clients like |
| 951s | before it |
| 953s | had to |
| 955s | request chunks per client and now it has |
| 960s | a unified processing for all these |
| 961s | chunks so and optimize this system for |
| 965s | chant update subscribing for chart |
| 967s | updates delivery |
| 969s | so it if we just move this system to all |
| 975s | system it will improve rendering speed |
| 977s | but now it |
| 979s | much more optimize it for multiple |
| 982s | players so like it won't reduce same |
| 988s | operations for multiple clients but |
| 991s | instead it will process like chunk |
| 994s | update |
| 995s | once and send to all act players who can |
| 999s | see the Chuck in seat of doing kit for |
| 1003s | like 100 times |
| 1005s | SN card released version thanks |
| 1009s | and there is a kind of stretch question |
| 1011s | with have you or have we planned for dll |
| 1015s | dlls 3.0 |
| 1018s | yeah |
| 1020s | uh we didn't discuss it yet yeah but yet |
| 1025s | probably will be a good Improvement yeah |
| 1028s | it also depends on the unity support for |
| 1030s | this feature oh yeah yeah we are on on |
| 1033s | that subject for like mothers and |
| 1036s | everything |
| 1037s | um we are kind of transitioning through |
| 1039s | the unity versions as they become |
| 1041s | necessary part wise but also |
| 1045s | um where where they come into the point |
| 1046s | where they support the |
| 1048s | packages that we're using I know the |
| 1050s | entities was delayed for quite a |
| 1052s | significant time due to |
| 1054s | Unity hadn't really pushed any updates |
| 1057s | um in that regard to |
| 1059s | quite a significant time |
| 1062s | um but it's something that we were |
| 1064s | allowed to start on for uh when we moved |
| 1067s | up to 2021 Yeah Yeah we actually uh in |
| 1071s | process of unity upgrade |
| 1074s | new version so we can use more fishes |
| 1078s | yeah so that's something that's kinda |
| 1081s | partly limited by the way we have things |
| 1084s | set up but also partly by |
| 1087s | were hinged on unity in some areas to |
| 1091s | really stable versioning of these things |
| 1094s | or long-term support for them because we |
| 1096s | don't want to update to |
| 1098s | something that's still in preview or |
| 1100s | beta on their side just because it would |
| 1103s | improve it but those often ends up |
| 1106s | having to rewrite Code 4 to integrate |
| 1109s | with halfway through so |
| 1112s | it's things that we avoid to kind of not |
| 1114s | have to do double work in that record |
| 1117s | um we have another one for for loading |
| 1120s | in regards to the question for what |
| 1123s | about game objects but I'm assuming that |
| 1125s | he's referring to World objects |
| 1128s | in general so like all the crafting |
| 1131s | stations and all of that and I I think |
| 1133s | we have some plans for it but we haven't |
| 1135s | started yet |
| 1138s | yeah actually we already have lots of |
| 1141s | World objects for a long time |
| 1143s | so and for yeah probably not for all |
| 1148s | but it's not something we didn't use but |
| 1153s | yeah that is actually main issue with |
| 1156s | the chance as I described because a |
| 1159s | dynamic and we can't use standard into |
| 1161s | tools for loading |
| 1164s | yeah but with all other objects which is |
| 1168s | uh like static and oh |
| 1172s | shouldn't be regenerated |
| 1175s | we can use standard Unity tools and yeah |
| 1178s | it works fine for years actually in game |
| 1183s | and yeah and another Improvement we uh |
| 1187s | so |
| 1188s | actually another improvements we did for |
| 1191s | at a higher rendering distance |
| 1194s | this was related to trees |
| 1199s | and it's uh already in our list version |
| 1203s | but it was Planet 4 increases the |
| 1208s | rendering distance because trees are |
| 1211s | large objects |
| 1212s | and uh if as I said for volt objects we |
| 1216s | can just not render them on high |
| 1218s | distance except very large forward |
| 1220s | objects with trees we probably uh |
| 1224s | have to render them far away |
| 1226s | because |
| 1229s | they are big and if you want to see |
| 1232s | Forest on Horizon and it will be nuts |
| 1235s | well so |
| 1237s | we had to find a way how we can uh |
| 1241s | render trees faster because it uh I I |
| 1245s | know everyone who |
| 1248s | are seen a big Forest know about that |
| 1251s | problem it kills you PPS |
| 1254s | and especially if it's a player planted |
| 1258s | first with London every block we |
| 1263s | eventually fix it where to |
| 1266s | not allow you to place |
| 1269s | trees after each other but it's still |
| 1272s | high impact on VPS so |
| 1277s | with some improvements in nine seven we |
| 1282s | have much more simplified tree models |
| 1287s | and we have loading so instead of |
| 1290s | rendering full free with all branches |
| 1292s | which also procedure generated in our |
| 1295s | render are simplified single mesh model |
| 1298s | on distance |
| 1301s | yeah popping in there a little bit but |
| 1304s | on on the three things one of the |
| 1305s | reasons why we kind of added that |
| 1308s | restriction in part as well is that |
| 1312s | it's a bit of a Band-Aid for the three |
| 1315s | generation and the versus the tree |
| 1317s | planting where |
| 1319s | players would plant crazily amount of |
| 1321s | trees and they would just grow next to |
| 1323s | each other because the Eco simulation |
| 1325s | didn't actually kill them or manage them |
| 1327s | in a good manner and it requires it |
| 1330s | required a bit of a bigger rework so |
| 1333s | we decided it was in it was necessary |
| 1336s | enough because it was killing |
| 1339s | performance too much as well as it could |
| 1342s | also be used as a severe griefing method |
| 1344s | where people would excavate large |
| 1347s | underground tunnels and plant trees |
| 1349s | underground as well which then |
| 1352s | in a kill performance for anyone going |
| 1353s | nearby |
| 1355s | um |
| 1357s | yeah and there are also uh |
| 1360s | game mechanic uh motivation because |
| 1364s | plans in |
| 1367s | nature not user planted have some |
| 1371s | restriction for distance and so it was |
| 1375s | not fully correct to let plant more |
| 1380s | dance |
| 1381s | significantly more dense when it |
| 1383s | possible in normal simulation yeah |
| 1388s | on on the subject of optimizations |
| 1390s | that's the main that being the main |
| 1392s | topic of the stream |
| 1394s | um any improvements on in regards to |
| 1397s | loose objects like Rubble for instance |
| 1399s | that's always kind of |
| 1402s | causing issues when it comes to large |
| 1404s | quantities |
| 1406s | uh actually we didn't |
| 1410s | do anything in a bad Direction so we |
| 1413s | more focused on other tasks for now |
| 1418s | uh but yeah actually we probably can |
| 1422s | apply some improvements we did for |
| 1424s | plants variables in perspective but the |
| 1428s | main issue with physics attached about |
| 1432s | objects because for plants we really |
| 1436s | don't have physics for example |
| 1439s | it's only uh |
| 1441s | some |
| 1442s | trigger like physics when you move into |
| 1445s | plant or when you need to recast to |
| 1449s | interact with plant |
| 1451s | but it doesn't interact with rigid |
| 1455s | bodies like rubbles and so my issue is |
| 1460s | rubbles actually that's a rigid body |
| 1462s | attached to that object but we already |
| 1466s | have optimization in place when we uh |
| 1470s | disable this rigid body when our Rubble |
| 1473s | not moving so after initial movement |
| 1476s | phase uh they uh |
| 1481s | stay in place and basically Frozen with |
| 1485s | a simplified physics and so for such |
| 1487s | variables we can probably also apply |
| 1490s | some optimization which should let us |
| 1493s | significantly reduce impact on |
| 1496s | performance and on |
| 1499s | Unity engine for these objects because |
| 1502s | for plants we actually |
| 1506s | use it ecas approach |
| 1510s | V standard approach you have in the |
| 1514s | unity you need to create game object |
| 1517s | for every object you want to render in |
| 1519s | the world and with which you want to |
| 1522s | interact |
| 1523s | but it means we have |
| 1526s | uh thousands and thousands of such |
| 1529s | objects for every plant for every grass |
| 1532s | object |
| 1534s | because uh |
| 1536s | like with many things have already |
| 1539s | planned his own simulation so we can |
| 1542s | just uh |
| 1544s | like render it with the same object and |
| 1549s | with single Shader but instead we need |
| 1553s | to make this object because he affected |
| 1555s | by pollution is affected by age |
| 1558s | uh |
| 1559s | if Catherine or not |
| 1562s | um |
| 1563s | and every such object has its own |
| 1567s | rotation related by the scale things |
| 1571s | like that |
| 1572s | and previously we had game object for |
| 1575s | our research object for all these things |
| 1579s | but now with uh refactoring |
| 1584s | a Casper and we work it on |
| 1586s | we was able to fully convert this game |
| 1591s | objects to entities so entity is concept |
| 1594s | for ECS which led us to make |
| 1599s | uh instead of this complex object with |
| 1602s | many relations with companions such as |
| 1605s | the like |
| 1607s | a few bytes of data |
| 1610s | okay like 100 by 100 bytes of data per |
| 1613s | such object and use a system which |
| 1616s | processes as data and puts uh this data |
| 1622s | render sent it to the world |
| 1624s | so instead of like making complex |
| 1628s | hierarchy for every plant |
| 1630s | and to put pressure on memory management |
| 1634s | in unity |
| 1635s | which doesn't work well these objects we |
| 1639s | have this optimizes system which |
| 1641s | minimizes amount of data we need for |
| 1648s | object for such object Institution for |
| 1650s | plans and then we can just add such data |
| 1656s | into like structure into list and it |
| 1659s | appears on world so like creating entity |
| 1666s | nanoseconds but making an object it's |
| 1670s | something like a few milliseconds in |
| 1673s | worst case |
| 1674s | so we basically reduce time we need to |
| 1677s | process |
| 1679s | such a creation of such an entity in 100 |
| 1682s | or in Thousand types |
| 1685s | yeah and I think it's something that |
| 1688s | um it is a really |
| 1690s | really tricky field trade you have to |
| 1694s | know where to look and debugging these |
| 1696s | things and I also think that it's it's |
| 1699s | very hard to |
| 1701s | from an external point of view you see |
| 1704s | that these optimization things are kind |
| 1706s | of tricky to nail down |
| 1708s | um they're very system system dependent |
| 1710s | on where we're at in in terms of |
| 1712s | development |
| 1714s | um |
| 1716s | and it's you know we're talking about |
| 1720s | um we're talking about you know |
| 1722s | nanoseconds and milliseconds as like |
| 1725s | milliseconds being the high Count versus |
| 1726s | nanoseconds optimal count |
| 1729s | which might not sound a lot but when |
| 1731s | we're talking about you know hundreds of |
| 1733s | thousands of objects that needs to be |
| 1734s | processed very very quickly |
| 1737s | as it might be just one two three four |
| 1739s | seconds on your side |
| 1742s | um |
| 1742s | system wise it's quite a significant |
| 1745s | amount of calculations |
| 1748s | um |
| 1749s | and more importantly we can move these |
| 1753s | entities processing keep background |
| 1755s | threads so we can utilize utilize |
| 1758s | multiple cores more effectively yeah so |
| 1761s | like a logic runs in background while |
| 1765s | main thread can be buzzed with uh |
| 1768s | significant again things yeah |
| 1771s | um |
| 1772s | and on |
| 1774s | let's see here we got a couple of couple |
| 1776s | of other questions which is uh we got |
| 1778s | one here with what's the impact of |
| 1780s | rubbish internet connections on all of |
| 1782s | these chunk loading changes |
| 1786s | we're going to see any any higher like |
| 1788s | latency issues due to higher chunk |
| 1791s | accounts or |
| 1793s | they actually uh it of course will have |
| 1797s | some impact because uh |
| 1800s | yes because it took small time for our |
| 1805s | package traveling |
| 1807s | Network |
| 1808s | and yeah we have some mechanisms which |
| 1812s | prevents clients from overspamming with |
| 1816s | chunks so if uh |
| 1819s | client doesn't keep alive uh fast enough |
| 1825s | then it may have some delays for |
| 1827s | delivery because there were like sense |
| 1831s | uh 200 chunks to client and weights |
| 1835s | while client confirm uh it's ready to |
| 1839s | receive more chunks |
| 1840s | and so you may uh |
| 1844s | see a slowest chunk loading |
| 1848s | in what case |
| 1851s | also yeah it's uh Definitely Maybe an |
| 1854s | issue but uh |
| 1858s | you probably will suffer from it for |
| 1862s | really poor connection and yeah we |
| 1865s | probably may think about some |
| 1868s | improvements like on client you can |
| 1871s | set how much chunks you're ready to |
| 1874s | receive |
| 1877s | before server stops sending new chunks |
| 1879s | to you so in that case |
| 1882s | you will have some buffer |
| 1885s | yeah and it's actually easy to fix and |
| 1888s | maybe maybe it's unconfigurable yeah I |
| 1891s | think something like that will probably |
| 1892s | go into |
| 1894s | into an option config or a couple of |
| 1897s | presets like um |
| 1899s | like Network traffic or like Network |
| 1902s | options where you can select between low |
| 1903s | medium High |
| 1905s | um like you know slow medium faster or |
| 1907s | something in the lines |
| 1910s | um well since we are giving more control |
| 1912s | now to the client over the amount all |
| 1915s | and which tanks are being sent so that |
| 1918s | will also go well with this kind of |
| 1920s | similar to what we did with tooltips |
| 1921s | recently which was adding caching and |
| 1923s | trying to |
| 1925s | sort of take care of those highlighters |
| 1927s | connections where we would have to wait |
| 1931s | for several seconds to open even a |
| 1933s | tooltip and now most of them should show |
| 1935s | up quicker because they are being cached |
| 1937s | and we are trying to reduce the amount |
| 1939s | of traffic so it should probably take a |
| 1941s | similar turn in that case |
| 1944s | yeah that's a good point um we have with |
| 1946s | the changes to that went into 9.7 which |
| 1949s | was a large volume of what we were |
| 1952s | working on towards 10 is in a client |
| 1956s | mitigate things more so they're not as |
| 1958s | reliant on the server for processing |
| 1960s | which means that |
| 1963s | your uh your local performance is what |
| 1967s | is the determining factors you don't get |
| 1969s | slowed down on the client side due to |
| 1972s | processing communication between the |
| 1974s | client and server |
| 1976s | yeah and also another thing we're |
| 1979s | working on it's not yet implemented uh |
| 1982s | but uh |
| 1984s | we have plans for it is to |
| 1987s | move control over uh Chan clothing to |
| 1992s | client |
| 1993s | so main benefit of this approach we can |
| 1997s | uh |
| 1998s | decide on client which chunks we prefer |
| 2002s | to load |
| 2004s | and at which speed and also we can use |
| 2007s | client cache both in memory and this |
| 2010s | cache so like if you |
| 2013s | enter into the world it may load all |
| 2016s | this chunk this data from server then |
| 2019s | save to you this cache |
| 2021s | and when you enter to the world next |
| 2023s | time it will not wait from surfaces |
| 2027s | chunks but instead render uh chunks from |
| 2031s | this cache and ask server for updates if |
| 2035s | needed so if it's like mostly static |
| 2039s | Terrain in that case uh you will have |
| 2043s | only very few chunks received from |
| 2045s | server in that case and even if |
| 2048s | you're not yet received you will see how |
| 2051s | data outdated version of this train but |
| 2054s | it will be updated like in |
| 2056s | uh |
| 2058s | depending on your pink |
| 2060s | like 10 or 20 milliseconds |
| 2065s | so it will be still fine and yeah it uh |
| 2068s | sir prioritizes uh closest chunks so |
| 2071s | yeah like on Horizon you may see audited |
| 2074s | chunks which will be sync it |
| 2076s | in few seconds but our chance close to |
| 2080s | you will be likely up to date in that |
| 2083s | case but yeah you can uh have much |
| 2089s | faster rendering and less dependent on |
| 2091s | PING |
| 2092s | and yeah so if you move between two |
| 2096s | points like from City to your house |
| 2099s | and then it may preserve this chance in |
| 2103s | memory cache and it will remove |
| 2107s | measures because they consumes memory |
| 2111s | but chunk data is a |
| 2115s | actually relatively small |
| 2117s | so I'd like |
| 2121s | uh 2 000 bytes to kilobytes per shot |
| 2124s | something like that |
| 2126s | yeah and yeah so you can save them in |
| 2130s | memory at least for some probably maybe |
| 2135s | also configurable option and so if you |
| 2137s | move between two points and you may have |
| 2140s | experience much much faster |
| 2143s | channeling and less request to server |
| 2146s | and less delays and less dependent on |
| 2149s | pink |
| 2151s | um we have just a couple more questions |
| 2154s | which |
| 2156s | one of them being that it seems like FPS |
| 2159s | is going down the higher the character |
| 2161s | gets so are you not loading chunks if |
| 2163s | they're within the 400 limit but below |
| 2165s | the horizon |
| 2167s | um |
| 2170s | essentially like if you're moving |
| 2172s | vertically |
| 2173s | you're not seeing as far down |
| 2176s | so are they still loaded in or are they |
| 2178s | getting unloaded because you're gonna |
| 2181s | reaching the span on it of course the |
| 2183s | loading and viewing distance all the |
| 2185s | same on an even plane |
| 2189s | uh you are loading distance doesn't |
| 2193s | depend on you |
| 2197s | vertical position so it's uh |
| 2200s | okay previously it actually depended on |
| 2203s | your vertical position |
| 2206s | but now it renders uh |
| 2211s | columns so it sends we after less |
| 2215s | refactoring it allows full column |
| 2219s | and only depends on your horizontal |
| 2222s | position so like |
| 2224s | XZ not degree |
| 2228s | and yeah it's for the performance is |
| 2232s | probably just from the amount of stuff |
| 2233s | that I actually have to render because |
| 2235s | it still impacts my HP also when I get |
| 2238s | higher I actually see more stuff and all |
| 2240s | the plans that actually need to be drawn |
| 2242s | whereas when I'm lower than a lot of |
| 2244s | stuff is just obstructed and there is |
| 2246s | just isn't that much stuff to process |
| 2248s | yeah so actually we also have occlusion |
| 2252s | cooling thing which prevents rendering |
| 2254s | of objects behind |
| 2257s | like mountains so if they obscure it by |
| 2262s | some object you |
| 2264s | say we'll skip it from rendering |
| 2266s | but if you own uh in the air |
| 2270s | then you will see everything and so |
| 2273s | there are less |
| 2275s | optimizable in that case |
| 2278s | yeah |
| 2279s | um also with with the changes and the |
| 2282s | new distance will the game keep using up |
| 2284s | more RAM to keep everything loaded or |
| 2289s | data wise nothing really |
| 2291s | we haven't really compressed that much |
| 2293s | data wise other than the entities answer |
| 2295s | that but |
| 2297s | General like sized RAM usage |
| 2300s | overall concern |
| 2303s | uh actually uh |
| 2306s | it's oblivious but we render more |
| 2312s | higher higher distance and we render |
| 2314s | more ground meshes |
| 2317s | so most impact on memory is from meshes |
| 2321s | and this measures will mostly impact |
| 2325s | your GPU memory |
| 2327s | so you don't if you don't have enough |
| 2330s | vram then probably you need to use lower |
| 2334s | rendering distance |
| 2337s | about four chunks itself as I said |
| 2342s | they relatively small so like few |
| 2344s | kilobytes per chunk |
| 2347s | and so that it shouldn't be to be |
| 2350s | compact on memory usage these chunks but |
| 2353s | yeah we still need more testing yeah and |
| 2356s | I think if anyone's still confused as to |
| 2358s | what we're referring to with the chunks |
| 2360s | it's every and the world is built up in |
| 2363s | chunks which is essentially pillars and |
| 2366s | they're redefined by the server size so |
| 2369s | the default one being 72 by 72 and each |
| 2373s | chunk consists of a 10 by 10 |
| 2376s | surface area of |
| 2379s | plots so essentially it's two claims |
| 2381s | wide two claims |
| 2384s | right |
| 2385s | um |
| 2386s | and that kind of composes aishank and |
| 2388s | then |
| 2389s | these chunks is the the squares that |
| 2391s | keeps being loaded in that you've seen |
| 2393s | before when you're running up through a |
| 2394s | new area quickly |
| 2396s | um and that's what we're hoping to you |
| 2398s | know |
| 2399s | eliminate and mitigate where you could |
| 2401s | you don't really see that happening |
| 2405s | okay so it's just convenient way for us |
| 2408s | to render blocks in groups |
| 2412s | yeah like |
| 2414s | and update |
| 2415s | also instead of sending pair block which |
| 2420s | will have lot of our head so because we |
| 2423s | need to send position for every block we |
| 2427s | group them together in by 10 by 10. |
| 2432s | blog group and so if you update such a |
| 2436s | group then we send the whole group and |
| 2438s | render this whole group |
| 2445s | a general kind of generalization |
| 2448s | question in regards to optimization |
| 2450s | progress and |
| 2452s | where we're at now where we've been and |
| 2454s | where we're moving forward with is it |
| 2456s | possible objectively to know kind of the |
| 2458s | percentage rate of improvements in |
| 2460s | performing |
| 2461s | um say in upcoming years and then |
| 2463s | through Eco development or is it always |
| 2465s | kind of a leap into the unknown of how |
| 2467s | much how much we cut down in memory |
| 2470s | costs and |
| 2472s | um |
| 2472s | performance and general |
| 2476s | yeah it's actually a performance theme |
| 2478s | which is hard to predict because so |
| 2482s | usually it's like iterative process when |
| 2484s | you |
| 2486s | are |
| 2487s | do profiling so you specialize a tool to |
| 2491s | understand uh how fast parts of your |
| 2495s | system works and how much memory it |
| 2497s | consumes |
| 2499s | and then you start looking into code and |
| 2502s | trying to understand problem trying to |
| 2505s | fight solution |
| 2506s | and so it's not like |
| 2510s | you may uh |
| 2512s | predict such thing so sometimes you have |
| 2517s | idea but even for some brilliant ideas |
| 2520s | say not always works |
| 2522s | and it's not always possible to predict |
| 2525s | outcome of |
| 2527s | are a change so it's like most science |
| 2531s | and programming when you have some |
| 2534s | theories which which you need to check |
| 2537s | yeah I think it it's a very it's a very |
| 2540s | tricky thing to answer because it's so |
| 2542s | much trial and error very much the the |
| 2546s | scientific the scientific method |
| 2548s | approach to it where we see that |
| 2551s | something could potentially be an issue |
| 2553s | like the plants for instance where we |
| 2555s | knew that changing these out to entities |
| 2558s | that would have a potential significant |
| 2560s | Improvement but it's always hard to |
| 2563s | gauge how much of an improvement it |
| 2566s | would have |
| 2568s | um where we know that it's valuable to |
| 2570s | do it and we you know we do it because |
| 2572s | it's a good way to find optimization |
| 2575s | sourcing and |
| 2577s | and on the subject with the rubble we |
| 2579s | knew that they would be physically heavy |
| 2583s | um which also would result in |
| 2585s | in a source of big performance impact |
| 2588s | where we make them static once they've |
| 2590s | been sitting idle or they've been |
| 2591s | uploaded so that reduces the amount of |
| 2594s | drain on the system |
| 2596s | the loads being an important part as |
| 2598s | well so there's a lot of these key |
| 2600s | factors where we know |
| 2602s | changing these out and spending the time |
| 2604s | to improve them we know we'll have a |
| 2606s | substantial Improvement |
| 2607s | but then there's also points where there |
| 2610s | could be |
| 2611s | very small things and steps in between |
| 2614s | where we see these as we do profiling |
| 2617s | and that's something that's also |
| 2620s | requested by players that run into |
| 2622s | issues with memory handling or if you |
| 2624s | see that your system is using a lot more |
| 2626s | memory wise |
| 2627s | or dunks out in in frames and drops |
| 2630s | somewhere we can often request |
| 2633s | um |
| 2633s | profiling data which you can get from |
| 2636s | apart from the F2 menu in game |
| 2640s | um |
| 2640s | as per can probably show up where you |
| 2642s | can find some of that data here |
| 2645s | so on F2 we have a menu enabling for |
| 2649s | seeing how the game is using resources |
| 2652s | and what it's spending those on |
| 2655s | um in different categories both Network |
| 2657s | performance |
| 2658s | um extra streaming and kind of where |
| 2660s | where things are going how how long time |
| 2662s | it's taking the process and one of these |
| 2665s | Pages some transforms and the yellow one |
| 2669s | for hitting f11 takes a memory snapshot |
| 2672s | so that |
| 2673s | kind of makes a pool of |
| 2675s | uh |
| 2678s | kind of the data shorts over what's |
| 2680s | being used and I think Alex can probably |
| 2682s | playing that a little bit more |
| 2686s | yeah actually you're you're on the |
| 2689s | receiving end of these snapshots and and |
| 2691s | these memory yeah actually actually as |
| 2693s | you can see on these uh can you return |
| 2695s | to chance page |
| 2702s | as per can you please return the |
| 2703s | channels page I know there is some some |
| 2706s | black I can probably close down the chat |
| 2708s | there as well too yeah okay so as you |
| 2711s | can see on this screen there are Chan |
| 2712s | groups it's like so for optimized |
| 2716s | rendering we group chunks together in |
| 2719s | another groups are like three by three |
| 2721s | by three so it's in total 30 by 30 by |
| 2725s | 30. blocks it's to reduce number of draw |
| 2729s | calls to GPU |
| 2731s | but yeah I probably don't need to go to |
| 2735s | much into details but on this screen you |
| 2737s | can see uh |
| 2739s | number of load zero load one and Lot 2 |
| 2744s | meshes |
| 2746s | for chunks so it's like 65 lot zero so |
| 2750s | higher detail and 71 for all that one |
| 2755s | and Lot 2 is uh |
| 2759s | much much higher number which is just |
| 2762s | the uh blocks |
| 2765s | cubes blocks like Minecraft Style |
| 2769s | but on distance you can't see them so |
| 2773s | there are big Improvement in using such |
| 2775s | simplified meshes which basically led us |
| 2779s | to have so high VPS |
| 2783s | so big distance because with every |
| 2785s | matter you increase radius of your world |
| 2788s | you adds more chunks where for previous |
| 2791s | increasement because |
| 2796s | length of circle is increasing keys with |
| 2799s | its radius |
| 2802s | so it's actually uh 200 meters and 400 |
| 2806s | meters uh it's not like two times more |
| 2809s | chunks |
| 2811s | so okay I I I can complete it it my mind |
| 2816s | but like in three or four times more |
| 2818s | chunks |
| 2820s | yeah when for 200 meters so it's like |
| 2822s | not a linear dependency |
| 2825s | yeah the wider the circle the |
| 2827s | exponential increase you have because |
| 2830s | yeah you're not increasing by a static |
| 2832s | amount you're increasing but |
| 2834s | so this uh load two |
| 2837s | which uh is just cubes as I say let us |
| 2840s | to render this chance very fast and uh |
| 2847s | load GPU very low with uh so simple |
| 2850s | meshes |
| 2853s | and yeah I actually didn't finish about |
| 2856s | troubles so I just wanted to say so for |
| 2860s | Rebels we can actually use same |
| 2862s | approaches for plants because we tried |
| 2864s | this approach with entities for plants |
| 2866s | and it uh |
| 2868s | works very good |
| 2870s | and I think chance with them are on his |
| 2873s | uh |
| 2874s | top PC configuration |
| 2879s | how good it works uh yeah and and may |
| 2884s | describe his impressions |
| 2887s | uh but yeah so for Rebels we're using |
| 2891s | similar rendering system as for plants |
| 2894s | which helps us to minimize surrendering |
| 2897s | calls |
| 2898s | this objects and actually we can |
| 2901s | Implement system which let us |
| 2905s | materialize these troubles into physics |
| 2908s | objects when they interacts and converts |
| 2912s | them to entities |
| 2915s | without game objects very lightweight |
| 2917s | like we have plans right now so it will |
| 2920s | help with big piles of rubbles to Fork |
| 2925s | really fast |
| 2928s | and it probably will fix this problem |
| 2933s | yeah we had we had a couple of |
| 2937s | a couple of interesting ones I think |
| 2939s | this one is a bit hard to answer with |
| 2941s | how far how far can the new cameras Zoom |
| 2943s | with viewing distance and everything and |
| 2945s | if the plants like the the loading |
| 2947s | impact on the cameras and I think that's |
| 2949s | something that we're we haven't really |
| 2952s | dove into too deeply because |
| 2956s | um |
| 2957s | they're relatively new and |
| 2960s | loading system is also |
| 2962s | gonna |
| 2964s | being worked on at the moment heavily |
| 2967s | um |
| 2968s | that one's probably hard to answer I |
| 2970s | think it's something that warrants a |
| 2971s | more |
| 2973s | detailed checkup but it's a very good |
| 2975s | question |
| 2979s | that's that's probably I don't know if |
| 2981s | you want to touch on that |
| 2985s | yeah I actually see a question let's |
| 2987s | chat if is there any consideration to |
| 2990s | the range and which buildings will load |
| 2991s | independent on size uh |
| 2994s | they're actually buildings uh Elsa |
| 2998s | chunks so they part of terrain so every |
| 3001s | building block |
| 3002s | just like a regular terrain block like |
| 3006s | round it also uses this block system |
| 3010s | like stockpiles as well so you will see |
| 3014s | buildings no matter of which size on |
| 3017s | same distance as you can see chunks so |
| 3019s | it basically max distance you said |
| 3023s | no |
| 3030s | another couple |
| 3032s | uh on the data transfer thing uh or on |
| 3035s | on the kind of reporting and |
| 3037s | snapshotting that with can can the |
| 3039s | community help you further by sharing |
| 3041s | more data and I believe you have the |
| 3043s | snapshot there on f11 |
| 3046s | um |
| 3047s | and I believe there's also well not even |
| 3049s | can I do a quick pass on |
| 3052s | just why it's why it's really helpful |
| 3055s | information |
| 3057s | get it and how to send it |
| 3060s | the data dumps in the snapshot system |
| 3064s | uh yeah actually uh |
| 3067s | when we're working on task we usually go |
| 3071s | through steps so like first we collect |
| 3073s | data from users if it's something which |
| 3076s | happens for Ev but what is not easy to |
| 3080s | reply to use in |
| 3082s | development environment |
| 3084s | and then from analysis of the snapshots |
| 3088s | we make some theories we need to check |
| 3091s | and uh so we try to fix it and work with |
| 3095s | users together to test this fixes |
| 3099s | and uh yeah and we actually added new |
| 3104s | Improvement which led us to build |
| 3106s | development version of game for released |
| 3110s | version and also include some fixes so |
| 3113s | it will be easier to test out theories |
| 3116s | uh these custom builds |
| 3120s | but right now I think uh yeah so we we |
| 3125s | know about problem with memory leaks in |
| 3128s | 97 release and I'm working on this issue |
| 3131s | right now |
| 3133s | not right now but |
| 3135s | okay |
| 3136s | issue here |
| 3139s | it's probably issue for me so I'm |
| 3141s | obvious racing I have some ideas |
| 3144s | as usual to check and so probably we'll |
| 3147s | see some improvements to it and the next |
| 3150s | patch |
| 3153s | but yeah I think when |
| 3156s | we release uh final patch for nine seven |
| 3162s | we will soon start uh public test for |
| 3168s | version 10. and then we probably will |
| 3174s | need help from users |
| 3176s | on the immigrated worlds to collect some |
| 3179s | data about sense which suffers in |
| 3183s | performance mostly and focus on fixes as |
| 3187s | issues |
| 3191s | yeah I think |
| 3193s | I think that kind of summarizes where |
| 3196s | we're at in in terms of |
| 3199s | General optimization progression to 10 |
| 3202s | but also how we how we approach |
| 3205s | optimization and the fact that it is |
| 3207s | unfortunately it is it is very hard to |
| 3211s | find |
| 3213s | big big gains for very little work in |
| 3216s | essence where optimizations is generally |
| 3219s | a very |
| 3220s | long hard use process going over a lot |
| 3223s | of data to try to eliminate points pain |
| 3227s | pain points |
| 3228s | um where week throughs can be gained |
| 3230s | at the same time we're also finally |
| 3232s | balancing you know adding more content |
| 3235s | into the game adding more systems and |
| 3237s | expanding the game |
| 3239s | um yet still kind of fighting |
| 3242s | increased increased things into the game |
| 3244s | increases requirements of the game so |
| 3247s | we're trying to battle optimizations to |
| 3250s | kind of scale that out so we're not |
| 3251s | overly increasing requirements yet we're |
| 3254s | still you know |
| 3256s | fleshing out and adding things |
| 3259s | it's a it's a constant battle that we |
| 3261s | have a couple of really good guys that |
| 3263s | are |
| 3264s | spending a lot of time and and making |
| 3266s | sure that that happens and |
| 3269s | quite significant progresses with 97 and |
| 3271s | 10. |
| 3273s | hoping that we keep doing these |
| 3276s | amazing |
| 3278s | bumps along the way forward as well |
| 3283s | and that's a couple of devs has stated |
| 3285s | optimization in general when it comes to |
| 3287s | game development is often not one thing |
| 3290s | that needs extra two things that needs |
| 3292s | to be fixed it's |
| 3293s | uh |
| 3294s | frame rate death by a million cuts |
| 3298s | where there's a lot of a lot of small |
| 3300s | things that always needs to be improved |
| 3302s | and all fixed or reworked to better use |
| 3305s | newer Technologies or |
| 3307s | come up with better creative ways to you |
| 3310s | to have the same kind of system and |
| 3312s | operability |
| 3313s | um you get gain small on small |
| 3315s | percentages in |
| 3317s | performance |
| 3322s | uh yeah |
| 3324s | I think |
| 3325s | that's probably it uh |
| 3329s | question was if we wanted to show off if |
| 3332s | I bump in on on me to |
| 3334s | be seen |
| 3336s | Casper's uh |
| 3338s | Jasper's performance on his |
| 3340s | 1660. |
| 3342s | um |
| 3343s | I think we probably did I'll do |
| 3345s | I'll possibly do like a general gameplay |
| 3348s | stream |
| 3350s | uh one of these days here we also got a |
| 3352s | couple of streams for |
| 3354s | coming up next Friday and Friday after |
| 3356s | that the settlements one is going to be |
| 3357s | a big one to kind of show off where we |
| 3359s | have more more things going on and more |
| 3362s | things being calculated to really show |
| 3364s | the the changes in Performance Off |
| 3368s | um really looking forward to that and |
| 3371s | I think we can probably call it the |
| 3373s | night here |
| 3374s | I know it's getting late for you Alex |
| 3376s | yes versus the same as well I'm still on |
| 3379s | getting into the night but |
| 3383s | different time zone for different people |
| 3385s | here in the company and there's always |
| 3386s | someone working every day every hour of |
| 3388s | the day this |
| 3391s | quite a fun experience you're always |
| 3393s | having someone to look at when you need |
| 3395s | help with something or |
| 3396s | found a critical issue that needs fixing |
| 3399s | right away or |
| 3403s | users are always super helpful |
| 3405s | and I guide us and see where where |
| 3408s | specific Hardware is having issues or |
| 3411s | you know they found something that's |
| 3412s | really exploding and cause problems and |
| 3414s | then we usually |
| 3415s | prioritize pipeline it to Alex and then |
| 3418s | he emergency fixes it magically |
| 3420s | overnight |
| 3422s | uh he is a bit of a tech wizard |
| 3427s | um so yeah thank you Casper for coming |
| 3429s | here now tonight and thank you Alex |
| 3432s | and |
| 3433s | close out and |
| 3437s | see you all next Friday thanks everyone |
| 3441s | thanks for joining |