Greetings, glorious adventurers! If you're joining in our Alpha One spot testing, please follow the steps here to see all the latest test info on our forums and Discord!
Options
Sieges and Lag
One of the cool features that AOC will have is castle sieges. I've played many MMOs so I'm no stranger to castle sieges. I'm just wondering what Intrepid has in mind to minimise the lag and ensure the game is still fun and playable during these sieges.
Let's look at what other games with similar mechanics have done. Archeage has siege, but they limit the number of players on each side to approx. 70 players. So you've got a siege witt a maximum of 140 players. Granted, Archeage uses CryEngine which by default may not be best suited for this type of content but at least limiting the player numbers in sieges works.
In GW2, they have several WvW maps that can be fought over and each of them have a player limit. I think it was around 400 per map.. but even then, if every player showed up at 1 fortress, it would become a lagfest.
In ESO, very similar to GW2 in a way except they have several Alliance War campaigns that players can join. Players can see the population status for each of these campaigns and decide which one to join. Now the nice thing about Cyrodil in ESO is that it's freaking huge. So even if there's a lot of players in there, it's unlikely that they will all find themselves at the same castle at the same time.
Lineage II and Aion are well known for their siege mechanics and similar to what AOC has in mind, these sieges would often include server wide population.. which is where the problem of crazy lagfest can occurs. If a node gets a declaration of war in AoC the server will have some time for prep and will likely have a huge number of players show up as it's in most players interest to either defend the node, or attack it. When you have events in a game that attracts this kind of server participation, as amazing as it sounds, they usually end up being played at 7 Frames per second on the average player's PC. I remember that Aion even had an option to completely disable other players on screen, allowing you to see only their names and the players would only appear if you targeted them.
Chamelot unchained has large sieges as well and next to no lag.. but they also use graphics from 20 years ago. Let's be honest guys. Vanilla WoW has better graphics than Camelot unchained.. so that combined with a great engine is probably how they can accomplish these large sieges with relatively no lag.
The Unreal 4 Engine has some pretty sweet looking graphics. I'm just wondering what Intrepid will do to mitigate lag in these large server events so that they can be enjoyable and not a slide show for most players.
Let's look at what other games with similar mechanics have done. Archeage has siege, but they limit the number of players on each side to approx. 70 players. So you've got a siege witt a maximum of 140 players. Granted, Archeage uses CryEngine which by default may not be best suited for this type of content but at least limiting the player numbers in sieges works.
In GW2, they have several WvW maps that can be fought over and each of them have a player limit. I think it was around 400 per map.. but even then, if every player showed up at 1 fortress, it would become a lagfest.
In ESO, very similar to GW2 in a way except they have several Alliance War campaigns that players can join. Players can see the population status for each of these campaigns and decide which one to join. Now the nice thing about Cyrodil in ESO is that it's freaking huge. So even if there's a lot of players in there, it's unlikely that they will all find themselves at the same castle at the same time.
Lineage II and Aion are well known for their siege mechanics and similar to what AOC has in mind, these sieges would often include server wide population.. which is where the problem of crazy lagfest can occurs. If a node gets a declaration of war in AoC the server will have some time for prep and will likely have a huge number of players show up as it's in most players interest to either defend the node, or attack it. When you have events in a game that attracts this kind of server participation, as amazing as it sounds, they usually end up being played at 7 Frames per second on the average player's PC. I remember that Aion even had an option to completely disable other players on screen, allowing you to see only their names and the players would only appear if you targeted them.
Chamelot unchained has large sieges as well and next to no lag.. but they also use graphics from 20 years ago. Let's be honest guys. Vanilla WoW has better graphics than Camelot unchained.. so that combined with a great engine is probably how they can accomplish these large sieges with relatively no lag.
The Unreal 4 Engine has some pretty sweet looking graphics. I'm just wondering what Intrepid will do to mitigate lag in these large server events so that they can be enjoyable and not a slide show for most players.
0
Comments
ArcheAge's sieges are limited to 200 players btw. But that doesn't change much, no matter what kind of PC you have you will always be stuck at 12-18 fps during a siege in AA.
I remember fighting nametags in GW2, let's not go there :P
Didn't really play the other games you talked about so no comments on that. I hope that UE4 will have "Optimization Mode" similar to BDO's settings. I don't really care about how the game looks during an important fight such as siege. Having a smooth gaming experience is what matters.
1. Client server model creates a bottleneck... but peer peer has security risks. IMHO a monitored peer-peer network is the best option. Leaving the players on one side of a vlan and the company on another via multiple localised gateways that straddle both. This way you keep the players as virtually and physically localised as possible and eliminate network latency. ie logical areas are mapped to physical geographic areas and can be served by a local game network gateway. The further away from home you are in the game map, the worse the ping will be.
2. AoE caps. An endless topic of furious debate. Some say dead people dont create traffic and load. So killing off as many as possible is the answer. The problem is this assumes one side cant defend. In reality you just end up with a storm of activity with everyone hitting everyone at the same time, increasing traffic and load to the nth degree. Lowering the TTK to allow high AoE caps doesnt really encourage large tactical warfare but creates a FPS game instead. Not that we know what kind of combat the creators envisage and will support.
3. Parallel execution and data access. This is the real problem that often rears its ugly head. Players vs. server cores on the execution side. Queueing up for service. Then multiple players trying to update a write locked players record that was hit by multiple people at the same time. Player Attribute fragmentation in a database (fragmented value pairs) and summing the attribute changes is the only way to work around the write locking. Thats one hell of lots of records to manage though. At the end of the day the AoE cap should not exceed the amount of fragments to allow uncontested 'parallel' data access. Wont help if 1000 people share one core on a server.
4. Group size isolation. By preventing small groups from attacking medium or large groups (and vice versa), you not only eliminate the problem of the swarm taking over the server/realm, but you also massively reduce the amount of calculations that need to take place in localised large scale warfare. Special effects aside. But if you are separating damage by group size anyway, you could pipeline the priority of the special effects. ie Make large group special effects a low priority for small/small group warfare.
I am more concerned about the effect of cheat engine and such. But the suggested fragmented memory and data pairs can defeat that if done properly anyway. It lends itself to cyphers and encryption and validity tests.
AeonAuron - They have shown footage on a GTX970. Your GTX 760 has a release date of June 2013. By the time game launches that will be a 6.5 year old GPU. While it does meet the minimum UE4 specs, it may not handle large content very well if it is the 2 Gig model. You might be ok at low settings, but its all a crapshoot until we get the game in Alpha 1 Phase 2 Q2 2019.