Glorious Alpha Two Testers!

Phase I of Alpha Two testing will occur on weekends. Each weekend is scheduled to start on Fridays at 10 AM PT and end on Sundays at 10 PM PT. Find out more here.

Check out Alpha Two Announcements here to see the latest Alpha Two news and update notes.

Our quickest Alpha Two updates are in Discord. Testers with Alpha Two access can chat in Alpha Two channels by connecting your Discord and Intrepid accounts here.

[Feedback Request] Alpha Two Server Meshing Technology Preview Shown in June Livestream

1235»

Comments

  • 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.
  • XluxorXluxor Member
    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!
  • powlampowlam Member, Alpha Two
    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.
  • patrick68794patrick68794 Member, Alpha Two
    edited July 16
    powlam wrote: »
    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.

  • patrick68794patrick68794 Member, Alpha Two
    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.
  • murdergroupiemurdergroupie Member, Alpha Two
    Above and beyond!
    Intrepid !! // this word now has three clear meanings, all are relevent
    I look forward to diving into Alpha2!
    xoxo
    Casually Serious.
    LFG: Open World, tight knit coordination, multiple roles, will travel.
  • Chuck ZittoChuck Zitto Member, Alpha One, Alpha Two, Early Alpha Two
    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
  • Balrog21Balrog21 Member, Alpha One, Alpha Two, Early Alpha Two
    Great live stream. Techy but explained in a very digestible way. Much kudos and RESPECT to the team!
  • KyCygni wrote: »
    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?
    25lh1k8skbeo.png
    ttu5bvso1aci.png

    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.
    v3aerqs8fzs2.png

    the outer white hexagon in this next image is where the 12 hexagons/56 triangles switch into 7 large hexagons hosting 24 triangles each.
    orbv42mkzmjj.png

    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.
  • Swifty00Swifty00 Member
    edited August 6
    There are a disturbing number of people that think that this technology means that everybody is going to be on the same server/realm.

    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.
  • DolyemDolyem Member, Alpha Two, Early Alpha Two
    Swifty00 wrote: »
    There are a disturbing number of people that think that this technology means that everybody is going to be on the same server/realm.

    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.
    GJjUGHx.gif
  • AshtorianAshtorian Member, Alpha Two
    I loved your Server Meshing Tech video... A big thumbs up for that!

    I like it so much i wanted to try and build something like that for myself, so I did. It's not dynamic, but it does server handover and so on. While implementing I came across some questions/issues:

    In the video you talk about proxies and that a neighbor server has a proxy of an actor. This is then replicated to it's clients. So the replication path is as follows (if I understood correctly):
    - owning server -> neighbor (creates proxy)
    - neighbor server -> client
    assuming this is done on ticks/each frame and the servers are running with their frames roughly in sync, it takes two ticks to sync to final client. When the (proxied) actor/player moves to the neigbor server, this is reduced to one tick (new owning server -> client). This shift also works in reverse (when moving to a neigbor server. This shift is noticable on the client with a small stutter during the movement, right?

    What I did to solve this: each server replicates its own actors to relevant clients. So if a client approaches a server border, it gets a message that it should also connect to server2. It does and that server stars replicating (relevant) actors to the client. To make interaction (player -> actors) work across boundaries, servers also replicate relevant actors across a border zone. This solves the issue of the stutter.

    Actually, moving across a server boundary is nothing more than switching the primary/secondary connection for the client. For the servers it's promoting/demoting the proxy. If the players move away from the server border, the secondary connection is dropped.

    Isn't this a much simpler solution?



Sign In or Register to comment.