
Chris Lambertz Digital Products Assistant |

Discussion thread for new blog entry Goblinworks Blog: Unity'd States

![]() |

Liking what I see so far with the environment Experience.
Just two question:
*Is there a way to cursor lock so that the cursor doesn't leave the screen? Having two monitors makes moving around a bit wierd.
*What rendering is it doing this in? DirectX 9? DirectX 11? WebGL?
Really like how the tower's stone areas (have to wander outside a bit to find) is tessellated (if that is the right word).

![]() |

Just two question:
*Is there a way to cursor lock so that the cursor doesn't leave the screen? Having two monitors makes moving around a bit wierd.
*What rendering is it doing this in? DirectX 9? DirectX 11? WebGL?
The controls offered with the browser plug-in are limited; we noticed that two-monitor issue, but don't know that we can do anything to address it (aside from having you temporarily disable the second monitor.)
I know Unity has DirectX 11 support, but I don't know for sure if that's used by the plug-in.

![]() |

Thanks Mark Kalmes. GREAT to hear this:
but we will need to have a team of engineers working on server-side tools. That actually plays to our team's strengths: Goblinworks CTO Mark Kalmes developed the server-side technology that Cryptic uses for its games, so this is a problem domain he understands at least as well as anyone in the industry.
Any insights into how the server-side is going to be specifically designed for the design input of Pathfinder Online:
1. Large numbers of players in battles (& formations?)
2. Each Hex changeable state
3. Settlements are going to have instanced buildings?
4. Single-server world
Netcode gets mentioned a lot as pivotal to MMOs especially for large battles, any further discussion on this?
I know next to nothing about networking. So all info is interesting.

![]() |
1 person marked this as a favorite. |

I'm not an expert but I pay attention pretty well.
The netcode is what handles the data between server and client is my understanding. They have to keep much of the data on both boxes: your client and the server, but it also has to correlate your position, for example, with the position of othr players and ingame assets. Now where there is a big difference between where your client thinks you are and where the server says you are you get what is called 'rubberbanding' and/or latency, also 'lag'. It also hs to reconcile your client position info with everyone else' too.
You can see how this would get pretty complicated in a crowded bar brawl, right?
Well Our Mark Kalmes is reputed to be one of the top guys, and he is in our corner, and he has his hands on what is best in his hands.
So that's all a good thing.

![]() |
1 person marked this as a favorite. |

For curiosity's sake I'll link an article on Massively that sheds some light on Eve Online's server architecture. I'm not saying that PFO will work on the same principles.
However, PFO is envisioned to be a very similar system (a single server, persistent world) so I believe the article gives broad lines on what's involved :)

![]() |

You guys are the best. Thanks.
Edit: I had read this oddly enough! Seem to remember sql being a potential problem further down the line? But what really resonated:
You could be forgiven for thinking that an MMO's server model doesn't affect its gameplay significantly but EVE Online has proven this wrong for five years running. Putting all players together in one server drastically increases the opportunity for PvP. Instead of the MMO norm of less than 5,000 potential players for you to interact with and barely 1000 online at peak hours, EVE's server houses over 300,000 players with a peak concurrent user record of over 40,000. Additionally, since there's only one server for all players, there's no option to sign up to a non-pvp version of the game.

![]() |

It was a question asked previously: What sort of system is used for the Hexes (all 256); it will be similar to EVE's:
Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together...
When a solar system is depleted of resources, is becoming overcrowded or is being camped by pirates, there is no second instance of the system to switch to. The ability to pursue attackers from system to system successfully or to lock down a star system and prevent your enemy from passing through allows for piracy and very real territorial control that just isn't possible with another server model. Conflict over resources and space arises as a natural consequence of gameplay and not from a developer-defined game mechanic. Real player alliances are forged and broken every week in EVE with complex politics behind them.
And what sort of player numbers are expected in each hex: 000's?

![]() |

An oblique response to something we cannot know is to suggest that the initial 256 hexes is unlikely to remain fixed. But until they know what the server load will be like at 256 hexes they cannot usefully project when they will increment or by how many hexes, and this is likely the driver behind their stated intention to admit only so many new players at a time at a probable sequence of intervals. Commensurately I expect that the frequency and timing of admission will be governed by how quickly additional areas can be built well/tested.
Once they do increase the 256 starting area they will have to take metrics on how that affects the population in the origianal area and how quickly the added area fills up.
So I would look for an incremental increase in the environment just like we expect an incremental increase in the number of players.

Valandur |

It was a question asked previously: What sort of system is used for the Hexes (all 256); it will be similar to EVE's:
Massively wrote:And what sort of player numbers are expected in each hex: 000's?Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together...
When a solar system is depleted of resources, is becoming overcrowded or is being camped by pirates, there is no second instance of the system to switch to. The ability to pursue attackers from system to system successfully or to lock down a star system and prevent your enemy from passing through allows for piracy and very real territorial control that just isn't possible with another server model. Conflict over resources and space arises as a natural consequence of gameplay and not from a developer-defined game mechanic. Real player alliances are forged and broken every week in EVE with complex politics behind them.
I think Eve caps the population at 2500 per system.

![]() |

Yes, that's true certain hexes will be added over time along with the size of the playerbase: The "world density" it was called.
2,500 per Hex sounds pretty awesome if they are all waging war atst! Obviously the landscape must make it harder than EVE's space for these total number of players possible per hex, however? Though the numbers (don't know anything about the zoning/instances) of Wargaming's World of Tanks above sounds impressive on terra firma.

![]() |
1 person marked this as a favorite. |

Some info from Ryan
EVE can support about 1,000 active players in the same virtual space without major performance problems on the server or network (client lag is the biggest problem at this scale, primarily due to video card issues). It can get up to about 2,000 active players in the same virtual space without crashing the server, but performance degrades badly on the server.
EVE has 7,500 star systems. Each system can be hosted on its own node (called a Sol server), although in practice most systems are hosted on shared Sol Servers because they do not generate enough traffic volume to require dedicated hardware.
Within each system, virtual spaces called "grids" by the players are created for each active player, and are shared by active players within a certain range (which is dynamically resized). It is possible to have those 1,000 active players scattered all over the system, or concentrated in one grid - the load on the server is effectively the same, although the network load goes up as a function of N^2, where N = number of active objects being tracked by the server. So 1,000 active players in 1,000 grids would be less taxing on the system than 1,000 active players on one grid.
When a player is in a station, that player is not considered an "active player" in the system's virtual space - so the total population of a system could be much, much higher than 1,000 without causing performance problems.
EVE's system would be infinitely scalable to the point (at least) where each grid could be run on its own hardware except for one problem. The game's core logic is written in Stackless Python, which is one of the reasons EVE was able to grow to the size it was, but now has become a limiting factor. Stackless Python cannot be run across multiple cores. It has a programmatic object (called the GIL) that doesn't enable it to spawn multi-core processes. Long before I left CCP there was work underway to address this issue, but until the problem is solved, there likely are hardware limits to the growth that EVE can maintain within a single virtual space. (The interested can watch this talk: http://blip.tv/carlfk/mindblowing-python-gil-2243379) (And you can see some of how CCP is dealing with this here: http://www.eveonline.com/devblog.asp?a=blog&bid=925)
The idea that a modern "massively" multiplayer online game should have a PCU in the 3,500-5,000 range (I'm looking at you, WoW & WoW clones) is ridiculous. WoW was designed in the early part of the 2000s. It's been nearly 10 years since its network topology and database systems were devised, 10 years which have seen the rise of all sorts of better solutions for transaction processors (look into CouchDB, for one example). But since Theme Park MMOs don't gain much value from having large simultaneous server populations or large virtual space population, most of the theme park segment hasn't bothered to try and come up with a better solution. In fact, they're actively developed to avoid large concentrations of players. Can you imagine what some of the shared spaces in WoW would be like if 1,000 characters were all in the same virtual space? They feel excessively crowded with just a few dozen!

![]() |

Oh I can imagine...
Burn Jita only in Stormwind. Horde raid on Stormwind full on PvP with 3,000+ people. Burn Stormwind, burn!

![]() |

I think Eve caps the population at 2500 per system.
Most EVE zones run on virtual hosts enabling one server to host many zones. Zones with commonly heavy loads and zones expecting heavy loads temporarily are put on dedicated servers.
It may no longer be true, but my understanding was that EVE's legacy server software and database design made it difficult for CCP Games to deploy a single zone across multiple servers that would enable scaling for much higher zone density.
Hopefully, Goblinworks will not have this same limitation.
Notes:
- please correct me, if you have current knowledge of the EVE's zone-limit scaling issues.
- EVE remains a pioneering leader in engineering overall world density.