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.

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.

Comments

  • This is something that worries me as well. Especially with a high-end engine such as Unreal Engine 4. I really wonder if my current GTX 760 can handle a solo roaming let alone massive sieges.

    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.
  • I would love to see more on this, but I believe it will come later. They are most likely editing large portions of the UE4 engine to compensate for the fact it will be an MMO. Networking will need a pretty big overhaul.
  • Agreed this will be a major headache that many creators simply never managed to resolve. As you very clearly pointed out.

    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.
  • ArchivedUserArchivedUser Guest
    edited October 2018
    Thought I would dig this up with the siege testing around the corner.

    How many people do you think a siege should involve?

    I mean in the case of Castles they are owned by a single guild which has a maximum of 300 people(rn) but the devs have mentioned in livestreams that there could be more than one guild attacking / defending when guild alliances come into play. So in the case of a castle siege I don't think it's outlandish to think that 300 vs 300 would be a good number this with an alliance having a Maximum of 1200 players with current information.

    so I ask the question do you think guildies should be locked out from participating due to engine limitations? Or should the game be optimized in a way to support a full 1200 vs 1200 people war?

    As for nodes I would think it will depend on the level of the node, but in a metropolis stage I think this would be a lot larger than that of a castle siege and will happen a lot less often.

    So the same as with castles Do you think citizens should be locked out of defending their home node to keep numbers manageable?

    What do you think will happen? How will the sieges be handled? There is so much optimization that can be done and those numbers seem mind numbingly large.

    PD: I can already see nagash's "Holy mother fo necro" coming hehe.
  • Santy182 said:

    PD: I can already see nagash's "Holy mother fo necro" coming hehe.

  • Santy182 Zeke asked at pax, and the "goal" is 500 vs 500 for Castle Sieges

    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.






  • Also Jeffrey has said that they are looking at a 5 year legacy window. Meaning they make sure that the game will run on hardware that is 5 years old or less. So if your stuff is older than 2015, you may not have full potential.
  • Siege, lag is a MAJOR concern of mine.CU has spend enormous amounts of time and money creating their own engine to avoid this issue. Are there any positive comments that would indicate this should not be a problem( a very big problem) for this game ?
  • Siege, lag is a MAJOR concern of mine.CU has spend enormous amounts of time and money creating their own engine to avoid this issue. Are there any positive comments that would indicate this should not be a problem( a very big problem) for this game ?
    They are currently in stress testing and working on those issues after creating their own backend in UE4 to support their vision. Every test gets better and better and lag issues are not being reported by those in the current region. Once testing on regional EU servers takes place, those will have better rates, but the NA people are saying every test gets better and better. Currently they are running 100 person BR for load and server testing. By the time we get to castle sieges the goal is for them to eventually reach 500 vs 500 just for testing purposes but we will see how long that takes for them to lock down. All said and done things are proceeding apace. You will be able to see for yourself probably next week once the NDA is lifted for everyone and streams go crazy.
Sign In or Register to comment.