Print

[keeperofstars]

As I am testing various parts of the seamless world setup, one thing I have ran into is the "zone" line issue where when a player crosses into another area via seamless link, targeting is lost, and with the default example combat you can select the person but are unable to fire a fireball at them. Knowing this means we will need to account for the player crossing the seamless zone line. Question becomes though is passing the data between the area's more of a bandwidth load / resource load versus having a larger area defined. I know that at some points there won't be anything that can be done but to deal with passing data between the areas.

Question becomes is there a balance between area size vs the added work load of passing data between the areas. What I am trying to avoid is fighting where people learn where the zone lines are and then fight on each other side cause they know crossing the line screws up being able to attack the player.

Also comes the question of pathing and NPCs and are they likely to stop pathing at the zone line of the area, and would I need to account for that issue and spawn / push the npc / mob over the area line.

Note: my goal is to create a pvp game, so these are key things I need to get a grasp of while working to design the combat system and all the key parts that will become the system.

I know it's best to keep areas to 256 by 256, but that will likely mean 7 concurrently loaded areas that will need to constantly have data between the areas passed between them to keep the players "state" and to keep the clients / players from exploiting the barrier. A group of 10 people fighting all dancing over a 4 corners area would in my mind draw a bunch of bandwidth to contantly persist the character data between the areas.


Thanks for any help.

[JoshHalls]

If you haven't already, you might want to check out the proxy node section.

http://hewiki.heroengine.com/wiki/Proxy

The clean engine isn't setup I believe to allow the basic combat handler they have setup to work across a seamless zone (and the data probably isn't setup to be proxy aware either).  You can fix this of course so you can target and attack across a seamless boundry and you will probably want to.  The only other option is to use larger zones, but it will just increase the load on the zone with more players in it. 

As far as NPCs, the answer is yes.  You would have to have a mechanism to move them from one zone to another.  We currently do it with our vehicles so it is possible (haven't moved on to pathed NPCs yet though).

--Josh

[Legacy]

As far as I know, this is the issue of the default combat system. You can (should) write your own that takes this into account. You should start by looking at 'proxyLocal' and 'proxyForward' topics on the wiki. This also answers the question about passing data between areas - which identifier you use specifies where will the execution take place. It really depends on what you need to do in your specific code.

As for the question with players fighting along seams - it is never good idea to make your world out of a grid of terrains where players can move freely in any direction. Is sounds good on paper, but will bring you only pain in development. It has been discussed here a lot and usually the resolution was that it is best to use bigger gameplay areas where your players quest, fight etc and smaller areas to connect those (pretty much like  Seamless 1.0 basically). Not saying you cannot go with the grid, but you have to make your combat system suited for it. And your NPC system also, as the default one fails badly when it comes to NPCs crossing area borders...

[keeperofstars]

Yeah I don't want to grid the area up at all if I thought the server(s) could handle it for my main PvP area, but for the size / scale i'm going with I know it wouldn't be wise to run massive areas, noting though the PvP area will be mainly just for fighting and such with low poly / slightly poorer terrain meshes to help smooth resource requirements. Then my PvE areas would be broken into smaller linked areas that aren't grids especially in town areas, player housing areas etc.

I'll dig into the proxy stuff in more detail. It's all just a balancing act, but one that becomes a fun challenge, as you almost have to build out an entire game, do live alpha / beta testing with it, then go back and make tweaks and hope you got most of it right. Just a matter of balancing things out.

trying to draw on experiences others have had, to try and save me some of that rework with map dimensions vs seamless etc.

Thanks for the information.

[keeperofstars]

so looking at the proxy pieces I see how the transfer data between areas, but that seems almost resource redundant. What is the advantage to have the 3 areas, and then have the proxy which is basically a copy of the Gom making writs to the proxies and the area GOM (source as well). I'm having trouble grasping the hardware advantage here, versus just having the base area being larger. I did more digging and it seems an area gets spun into a single process, reading the wiki it appears this becomes a cpu thread and thus hurts possible performance as the clustering power becomes less effective. (please correct me if I am mis-understanding)

so by using a larger area you are locking in the processing power, (limiting the clustering options by having set thread) which can become overloaded and cause performance hits.

Then shortly after that the wiki brings up the notion of using system areas to manage taxing systems, like chat, guild management, quests assignments, and even possibly combat systems. It goes on to say that many instances of system areas can be spawned thus taking full advantage of any available hardware. With that in mind would it make sense to look to putting PVP based combat for large scale into a system area setup to manage the combat between players. However the systems area wiki points out that the systems area aren't 100% synched with the data so have to check for consistancy and in a high paced combat system would that pose a problem of often non-synched data and the extra verifying would create more lag than having area managed combat. Since the players won't be leaving the pvp area though with this setup, the characters area is likely to not be different, just their location and actions in the area.


I know can use instances etc, but trying to keep them out of PvP as it's large faction based PvP. Can't spin up instances when territory control is in place. Can't have two instances of a guild city being sieged. I have some freedom with the map to break up super heavy areas with less heavy areas in an attempt to spin down areas not in use, but for the pvp area that wouldn't happen often.

I can set a queue on PvP but with me having guild ownership, goign to suck for players to lose their castle cause they were locked out in a queue. Not to mention GW2 has made people hate the queue once again. lol

So I'm trying to get my head wrapped around the differences between areas how they tie to hardware consumption / threading, and how maintain seamless combat. If using the proxy system is the best method and then just use moderately sized areas for the combat, then that is fine. Concern there is I have no control over how many people would potentially walk into an area and if that area is bound to only 1 thread / processor that could be a nightmare, where the system area could spin up more instances to deal with the load.

Or am i completely off on my understanding of how the areas tie out to the hardware. etc.

oh and anyone give me detail on instance slices.

     Instance Slices - an instance slice is an area instance spun up to distribute load for a specific region of geometry by dividing players between the slices and proxying information between them so that players can interact with each other. Each slice is a play instance of the same area. (not to be confused with area instances for different areas connected seamlessly together).

Seems like it provides a middle ground where you get multiple instances thus multiple threads but the characters are all proxied to the same source, and thus can interact. So while playerX is at areaPvp(instance1) and playerQ is at areaPvp(instance3) they both can see and interact with each other and the engine will proxy the data (or i script it to proxy). If I thought is correct then wouldn't this make most sense? Run a large area that uses instance slices. The slices can spin up instances which grabs server resources and spreads the work across the server cluster, but then has a single point of proxy that lets everyone stay synched, without the overhead of having to keep a system area validated for being in synch with the area server.

[Legacy]

I think you are overthinking it a little bit there More areas loaded == more resources need to be stored in client PC's memory (and more can be rendered at one time, but that depends). Basically, if you see 100 players around you, it does not so much matter if they are all in one big area or in four smaller seamlessly linked together. The seamless might have a little overhead but the main problem is still

a. The amount of content rendered (client-side lag)
b. The amount of players in awareness range (network-side lag)

You can avoid the former by making simpler areas with more complicated terrain and use of rooms (limit visibility). The later is somehow beyond your control, at least if you plan a very open system. If there are 100 players around you, all 100 still have to receive your updates (position etc) and you have to receive their data as well. So it's up to your design to handle this. Some suggestions may include creating PvP zones with objectives spread all around that trigger at the same time according to population density, thus dividing the playerbase onto different physical spots (and thus different areas).

For the combat system, if you go for a fast paced combat then forgot system areas and most remote calls all together. What you want is responsiveness to a maximum degree which means you will have to do a lot of simulation on client and have good prediction algorithms to cope with the sync issues. Simple systems that do not require lots of data work best. We are using a system where we are doing all the calculations we can on client and predicting results right there. For example, if I hit a player and I can calculate the damage right on client (not just sending some generic HitPlayer() call to the server and waiting for result), I can then compare the damage with that player's health. If I see it will drop below zero, I can initiate the death sequence immediately, not waiting for the network. Sure, the opponent may have been healed by someone in the last fraction of second and if so, the server will send me a notice so that I can interrupt the death sequence (which basically means just blending in another animation). In maybe 5% of cases this may look a little weird, but in those remaining 95% it will give your combat that immediate reaction needed for it to feel "right".

Others will surely add some more details, I got to go to catch my bus Cheers

[keeperofstars]

I appreciate the feedback, and understand calculating some things client, but outside of super simple combat, you going to need back and forth chatting with server, IE the opponents dex which affects his chance to mitigate your damage values. But I agree calculating the individuals damage amount, and having the enemy player's mitigation values pre-calculated with nextsave updates to those values based on buffs etc saves a bunch off the server.

I think my low level core basic question though is.....

Does having a single area limit the amount of physical hardware that is supporting the area.

For example I have PvParea1 its a large area is that PvParea1 limited to a single cpu core, the ram on the server and the 1 nic card. OR does that one large single area have the ability to spread it's load across all the processors in the server cluster, and the various network cards?

That is the piece I can't get a solid grasp on once I have that I will be set with my build out plans.
Thanks

[Dragorth]

They are using virtual machines, hosted by other companies, such as Amazon, to host each of the worlds. You get a certain amount of processing power to deal with, and no more.

Your full world will use multiple virtual machines, but individual areas do not. In fact, my surmise is that each of the areas is its own virtual machine, running the physics server, the database system, and all calculations.

(I can't speak for IF, but different hosting providers have levels of VMs, with less or more ram and processing for different price tiers. They may already be using the highest level for each of these. If not, you may be able to contact them and renegotiate, or not, their choice.)

The big point is that you should have to worry about the VMs as little as possible, unless you are planning on a source licence.

[HE-Cooper]

None of the cloud clusters are located on Amazon colos, but that's neither here nor there. The ease of the HeroCloud is that each area is a discrete unit of simulation.

[Dragorth]

I merely used Amazon as an example, since Amazon is a well known name in that space. I also said that the best part of the HeroEngine was not having to think in those terms.

[keeperofstars]

I have to worry about how the engine manages threading and network card allocations. A server cluster could have 10 network cards, but if the engine deems an area a unit of simulation and that means it gets threaded to only utilize one of the virtual machines in the cluster, then I have instantly locked my resource availability.

Example: Lets say there is a cluster with 3 physical servers that basically create 1 virtual machine. Each run quad core cpus at 2 Ghz with a 100mb network card and 8 gig of ram. ( I know not beefy servers but work for example here).

Basically that becomes a server with
24 ghz processing
24 gig of ram
300mb network stream

Using just for reference. http://hewiki.heroengine.com/wiki/Sizing_for_production
You get roughly 1,000 users per
10ghz
5 gig of ram
130 mb network

the vm machine cluster can handle about 2,000 users in general
if I have a large pvp area and 2,000 people decide to be in it (not all at same  coordinate location but inside the 1 massive area spread out and around) at the same time. IE a few zerg guilds fighting over different areas in the map.

The server in general can handle it assuming the pvpArea can use all of the VMs resources. However if an area which is a "unit of simulation" can only run on 1 of the physical hardware pieces in the vm's cluster due to cpu threading, ram management, and network routing by the engine. Then the most I can have is about 800 users in my pvparea at any one given time. So I need to plan for that, build in some system to manage pvp player volumes, in my case really forced into a queue system that I would rather not use, build a system to kick inactives faster in the pvp than maybe in pve, and much more. I would probably also look at breaking the area up possibly into different areas and see if I could use some mount ranges, deep trenches etc to cut down on touching grids to help keep concurrently loaded areas down.

OR if an area isn't locked to 1 piece of hardware, and can use any of the 12 cores, 3 network cards, etc all at the same time, then all i have to worry about is making 1 large pvparea, spread the fighting out in that area to take advantage of the systems spatial awareness, etc. Cap my server worlds to 2,000 people, make use of areas with low traffic having possiblity to spin down, allowing the main pvpArea more resources. And just to be clear I would still build in the in-active timers, etc just wouldn't have to worry about queue systems, and having to build out for proxy node based combat system.

so depending on what a unit of simulation actually means when it comes to ability to utilize resources greatly alters how the entire game is built, managed, and advertised. Thus why I am here being the annoying newbie. I know there are a ton of different things, how combat is coded, how this and that. The base question still remains, when a single area is running does it consume resources from all physcial machines making up the overall VM OR does it get tied into a single physical machine that is part of that clustered VM?

Sorry to keep digging at this, but it's so important to the whole game design, that I can't really finalize world design till I get it nailed down.

Thank you all who put up with my walls of text and I appreciate all the help.

[WorldWideZ]

think you might be asking for trade secrets the whole point of the "cloud" is that it provides a adaptive environment. with the discrete areas being small during peak use they can be thrown more resources

a "large" area would be tempered with Rooms and SAS meaning even if there were 2000 players in your area you dont need to have have many updating each other

the point , and something only your own team can solve, is that your trying to find the most efficient way to make the engine do what you want it to do

[Warded]

a "large" area would be tempered with Rooms and SAS meaning even if there were 2000 players in your area you dont need to have have many updating each other

I understand that, I can code the system to make sure it's within where I want my clientside GPU, CPU, RAM, HD and Bandwidth useage to be. I can do this whether it's a small area or a large area. My problem persists in the fact that in a large area (which I would much perfer to use with my game design) the server side still needs to keep track of all the clients. To use a single large area would mean we would need to use more server side CPU, Ram and Bandwidth. So the question is can multiple VMs support a single large area and can the network keep up with a single large area.

[HE-ANDY]

How much network traffic do you expect to fill for 2000 players?  Keep in mind your players will likely be 100+ milliseconds away in round-trip time and that replication takes care to do bandwidth management. 

[keeperofstars]

as simple as I can ask it.

does 1 single area get locked into 1 piece of hardware or does it spread it's load out across all servers that are part of the cluster / vm?