I've watched every single one of these going back 4 years or whatever, and honestly I turned this one off.
This Power Point presentation gave me "This meeting could have been an email" vibes. I know that what gets people excited to buy or play a game is gameplay, core mechanics, etc. Of course people will be happy if you crack the server meshing thing and I do appreciate that it's a bear to figure out and all the work that's gone into it.
I just don't need to know how the sausage is made.
Bottom line is while informative and mildly interesting to me I tend to agree with MissionCreep: "I just don't need to know how the sausage is made."
I trust the team to bring a stable, quality product to market. If I didn't I wouldn't be dropping $2k to upgrade my (admittedly long overdue) computer equipment.
HEYA!
I would like to extend my heartfelt thanks for the wonderful content. I want to congratulate the entire AOC team for their exceptional work. I LOVED IT!
I'm concerned about adding more and more servers when many players are in the same spot. Where are those new servers coming from? I suppose it can end up being really expensive...
As a workaround maybe you could think also about releasing servers by merging adjacent cells into only one server. It could be done when those cells were almost empty (if many players are grouped in one place, for sure there will be almost-empty zones at that moment).
That could be a way of reducing the number of concurrent servers needed.
I'm concerned about adding more and more servers when many players are in the same spot. Where are those new servers coming from? I suppose it can end up being really expensive...
As a workaround maybe you could think also about releasing servers by merging adjacent cells into only one server. It could be done when those cells were almost empty (if many players are grouped in one place, for sure there will be almost-empty zones at that moment).
That could be a way of reducing the number of concurrent servers needed.
That is something that will happen dynamically. Just like there's an upper bound for the number of servers the game world will be divided across, there will also be a lower bound. Basically they'll scale in and out dynamically, within limits, to match the demands needed by player count and distribution
The new servers will just be provisioned dynamically in AWS. What they're doing in that regard is something cloud providers have offered for years. I've never used GameLift so I'm not sure how the specifics work for scaling in and out using that service. I would suspect that Intrepid is at least considering, if not actively pursuing, a custom contract with Amazon.
I am for one very excited for this new technology and I hope for its success. Because not only would this help Ashes but has the opportunity for Intrepid to lease or give access to this tech. However, my biggest corner for any game is fairness. Someone with a stronger connection should not had a advantage compared to another person with an average connection. Assuming both are stable. If the execution of this tech after being fully fleshed out does not resolve issues between players interactions I would say scrape it and take another approach. The risk and rewards of events and tasks in the game should only be weighted on the in game risks and rewards and not the outside factors. I.E doing a major group event in less busy game periods to ensure its success and not system failure.
I loved the showcase and the details, if possible for something like this before giving a preview of simple cases having the showcase and tech ready for a large scale, not the max case, a case that does truly solidifies, not perfectly but provides a great confidence, the tech can do its job. In the case of meshing versus older network tech showing how smooth or not this new system runs in comparison. The slides and examples looked good but did not show properly its ability to handle X number of players in a small zone, active server sizes being re-scaled etc.
I am for one very excited for this new technology and I hope for its success. Because not only would this help Ashes but has the opportunity for Intrepid to lease or give access to this tech. However, my biggest corner for any game is fairness. Someone with a stronger connection should not had a advantage compared to another person with an average connection. Assuming both are stable. If the execution of this tech after being fully fleshed out does not resolve issues between players interactions I would say scrape it and take another approach. The risk and rewards of events and tasks in the game should only be weighted on the in game risks and rewards and not the outside factors. I.E doing a major group event in less busy game periods to ensure its success and not system failure.
I loved the showcase and the details, if possible for something like this before giving a preview of simple cases having the showcase and tech ready for a large scale, not the max case, a case that does truly solidifies, not perfectly but provides a great confidence, the tech can do its job. In the case of meshing versus older network tech showing how smooth or not this new system runs in comparison. The slides and examples looked good but did not show properly its ability to handle X number of players in a small zone, active server sizes being re-scaled etc.
Server meshing will not give anyone an advantage for having faster internet and will not affect the fairness of the game for anyone.
Played a few games that went the route of splitting the world up in to smaller sections that you load back and forth into and out of and it caused so many issues. Would be really interesting if this is the next evolution of that tech and it ends up working good but we shall see. Here are a few major issues I have ran into that may or may not have been thought about.
1. If there is any kind of player cap on one of the tiles/servers whatever you call them. One large group of players will fill up the tile/server so that basically no enemy force can every really get in because its always full.
2. There was always ways in game or out of game add ons to track every player that came into and out of a tile/server. It took the fun out of things knowing exactly how many people and who were in the zone/tile/server with you.
3. Any force large or small usually lags the tile/server when they come in or go out of the tile/server
Apologies if this is a silly question: in the video, the servers are shown in a grid, and a decent amount of time is spent discussing how to reduce artifacts amongst neighboring servers. Yet perplexingly, a perfectly aligned square grid was shown for the server "tiling geometry". This choice wasn't discussed in the video, and intuitively it doesn't make sense. There are many tilings with fewer tiles at any vertex, including one where you restrict yourself to squares; see attached example.
Why would you intentionally create points where 4 servers have to communicate proxy information to one another when you can just as easily tile the game grid with servers that never come to more than 3 at a point? Is there a technical reason for this? What about servers of different sizes for that matter?
This almost looks like its considered during the "Dynamic Gridding" portion of the video, but I don't see any reason why you couldn't do Dynamic Gridding with the "brick-layering" geometry shown above.
If you really wanted to, you could create long thin servers at different game "latitudes" that span the entire globe, reducing the number of adjacent servers at any point to 2. (But that involves different server areas which may not be supportable given the game's size)
During the Spatial Grid Bucket, the number of servers is directly referenced as the reason for a performance boost, using 3 adjacent squares looking towards a corner. Again, if you glide half of the servers (as above), you would always be using 2 adjacent squares.
i had a similar idea to this, but i got my idea thinking about the flower of life from sacred geometry. however instead of circles, create partitions out of triangles then create hexagonal regions.
FYI im not well versed in coding, and only started my game dev journey last year. but as i understand it, the system handles triangles easier because they are a much simpler shape compared to squares.
anyway following the schematic of the flower of life, you would have the world mapped with a triangle partition grid, they'll all controlled by overlapping hexagons. so each triangle partition would have 3 hexagons hosting it simultaneously.
this would also help with the issue of server crashes, instead of isolating a region where there is a servers crash or need maintenance. you can isolate a hexagon to have work done to it, and reintroduce it later updating the neighboring regions that have those partitions hosted.
as for the dynamic server meshing. as well as scaling down when needed. the servers easily merge hexagons into larger hexagons.1 hexagon of 6 Triangles can merge with the other intersecting 6 Hexagons, having 24 triangle partitions hosted on a server. or combine with the next 12 hexagons that sit on its border to host a total of 54 triangles.
however instead of merging with the next 18 hexagons that sit on THAT ones border, the grid would divide into 7 large hexagons each hosting 24 triangles.
i attached a couple visuals to help understand.
the outer white hexagon in this next image is where the 12 hexagons/56 triangles switch into 7 large hexagons hosting 24 triangles each.
the reason why i wouldn't let the hexagons keep merging is because if enough players accumulate the dynamic server meshing may trip over itself creating the hexagon regions that host on different servers.
but i may be overcautious, its not like anyone has ever tried triangle partitions.. as far as i know.
Comments
Bottom line is while informative and mildly interesting to me I tend to agree with MissionCreep: "I just don't need to know how the sausage is made."
I trust the team to bring a stable, quality product to market. If I didn't I wouldn't be dropping $2k to upgrade my (admittedly long overdue) computer equipment.
I would like to extend my heartfelt thanks for the wonderful content. I want to congratulate the entire AOC team for their exceptional work. I LOVED IT!
As a workaround maybe you could think also about releasing servers by merging adjacent cells into only one server. It could be done when those cells were almost empty (if many players are grouped in one place, for sure there will be almost-empty zones at that moment).
That could be a way of reducing the number of concurrent servers needed.
That is something that will happen dynamically. Just like there's an upper bound for the number of servers the game world will be divided across, there will also be a lower bound. Basically they'll scale in and out dynamically, within limits, to match the demands needed by player count and distribution
The new servers will just be provisioned dynamically in AWS. What they're doing in that regard is something cloud providers have offered for years. I've never used GameLift so I'm not sure how the specifics work for scaling in and out using that service. I would suspect that Intrepid is at least considering, if not actively pursuing, a custom contract with Amazon.
I loved the showcase and the details, if possible for something like this before giving a preview of simple cases having the showcase and tech ready for a large scale, not the max case, a case that does truly solidifies, not perfectly but provides a great confidence, the tech can do its job. In the case of meshing versus older network tech showing how smooth or not this new system runs in comparison. The slides and examples looked good but did not show properly its ability to handle X number of players in a small zone, active server sizes being re-scaled etc.
Server meshing will not give anyone an advantage for having faster internet and will not affect the fairness of the game for anyone.
Intrepid !! // this word now has three clear meanings, all are relevent
I look forward to diving into Alpha2!
xoxo
LFG: Open World, tight knit coordination, multiple roles, will travel.
1. If there is any kind of player cap on one of the tiles/servers whatever you call them. One large group of players will fill up the tile/server so that basically no enemy force can every really get in because its always full.
2. There was always ways in game or out of game add ons to track every player that came into and out of a tile/server. It took the fun out of things knowing exactly how many people and who were in the zone/tile/server with you.
3. Any force large or small usually lags the tile/server when they come in or go out of the tile/server
i had a similar idea to this, but i got my idea thinking about the flower of life from sacred geometry. however instead of circles, create partitions out of triangles then create hexagonal regions.
FYI im not well versed in coding, and only started my game dev journey last year. but as i understand it, the system handles triangles easier because they are a much simpler shape compared to squares.
anyway following the schematic of the flower of life, you would have the world mapped with a triangle partition grid, they'll all controlled by overlapping hexagons. so each triangle partition would have 3 hexagons hosting it simultaneously.
this would also help with the issue of server crashes, instead of isolating a region where there is a servers crash or need maintenance. you can isolate a hexagon to have work done to it, and reintroduce it later updating the neighboring regions that have those partitions hosted.
as for the dynamic server meshing. as well as scaling down when needed. the servers easily merge hexagons into larger hexagons.1 hexagon of 6 Triangles can merge with the other intersecting 6 Hexagons, having 24 triangle partitions hosted on a server. or combine with the next 12 hexagons that sit on its border to host a total of 54 triangles.
however instead of merging with the next 18 hexagons that sit on THAT ones border, the grid would divide into 7 large hexagons each hosting 24 triangles.
i attached a couple visuals to help understand.
the outer white hexagon in this next image is where the 12 hexagons/56 triangles switch into 7 large hexagons hosting 24 triangles each.
the reason why i wouldn't let the hexagons keep merging is because if enough players accumulate the dynamic server meshing may trip over itself creating the hexagon regions that host on different servers.
but i may be overcautious, its not like anyone has ever tried triangle partitions.. as far as i know.
They are aggressive about it as well. A couple of them do concede that there might be two servers, a PvP server and a PvE Server.
That last part is even worse. No chance of separating PvP and PvE with the systems implemented.