Greetings, glorious testers!
Check out Alpha Two Announcements here to see the latest news on Alpha Two.
Check out general Announcements here to see the latest news on Ashes of Creation & Intrepid Studios.
To get the quickest updates regarding Alpha Two, connect your Discord and Intrepid accounts here.
Check out Alpha Two Announcements here to see the latest news on Alpha Two.
Check out general Announcements here to see the latest news on Ashes of Creation & Intrepid Studios.
To get the quickest updates regarding Alpha Two, connect your Discord and Intrepid accounts here.
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.
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?