Financial Reality

It is hard to really understand the financial reality of game development until your paycheck and livelihood are tied to it. I certainly didn't think about it much at all prior to becoming a game dev. While making and playing PlanetSide 2, I saw countless posts from players talking about how the devs were making money grabs here, rolling in cash there, and otherwise protesting any and every attempt to generate more revenue for the game. Those same players often wanted to see different features made entirely. I wanted to explain some of the background to that, and why those things are so very often misunderstood, and so very important to any game you love. As a player you often have selfish priorities but don't really see the big picture - when the game makes more money, you will generally get a better game and more development on it. And when it doesn't...it doesn't.

Wikipedia has a great article on game development that covers some of the financial aspects. If you're interested in details, I recommend that. But here's the short of it. Making a AAA game is usually very expensive. And since you don't typically make money until you ship that game, you need most of that money up front. Tens to hundreds of millions of dollars, depending on how many developers are on the game and for how long. That means a business loan. When you do ship the game, the folks that loaned you that money don't just forget about it. They are investing in the game, and they not only want their money back, they also want to see a return on that investment. That means that a good chunk of the money the game makes goes to paying off a massive loan and investor returns; it doesn't go to devs so they can buy golden Lamborghinis. Then you have operating costs of the game - the salaries of the devs still working on it, the hardware, the customer service, the office space lease, the coffee in the break room, etc. And you have future costs for the game paid in-advance - how much will it cost to run it for the next several years? How many devs? What sort of support? After the loan and future costs are paid off is typically when you would start to see royalties, assuming the game makes that much money to cover operating and future development of the game. During all that time, the dev team is usually on salary or hourly, just like most of the jobs out there. In a perfect world, the game makes good money, investors are happy, it continues to get funding, and after a while the dev team starts to get some royalties for their efforts. But even in a perfect world that takes time to happen.

But what about an imperfect world? What if the game doesn't make enough money to pay off its loan or cover operating costs? Typically the response to any product not being in the black is obvious. 1) increase revenue. 2) reduce costs. Games are no different.

To increase revenue, new features will go in to try to bump it directly or indirectly (new things in cash shop, better player retention, etc). Those features are not free, and may not be anticipated. That means to make those features happen, other features get postponed or cut in favor of the revenue-increasing ones. This is usually in addition to cost cutting measures, as you don't really know if the revenue increasing features will work and they take time to build. So costs are often also reduced.

The biggest cost to reduce in a game are its people. Can't really cut game servers, and building space is not easy to adjust. People (devs, testers, customer service, etc) are easy to adjust, and they are a significant cost. This is especially true if you factor in multiple years of future development.  Remove one dev and you've shaved several hundred thousand off the amount of money you need to sustain the game in its lifetime. When one dev is removed, so too are all of the features, ideas, improvements, assets, and bug fixes that dev would have created or contributed to the game. Really important features would be offloaded to other devs, which means some of the features they would have worked on get cut instead. Because of this, typically lesser paying more volatile jobs are cut first - customer service, testers, and non-critical (or not-as-critical) staff. Then as that process continues more and more significant staff gets reduced, and with them more significant feature reductions deleted from the future of the game. Also out the door goes some types of projects, which may no longer have the manpower to effectively create. The scope is reduced. While sometimes devs simply move to another project in the company, sometimes they are simply laid off. The loss of personnel has another effect - morale goes right down the shitter. Watching talented friends and colleagues who helped you build a game pack up their stuff and likely forever leave the project is soul crushing. It's much worse for them (obviously), but I want to focus on the effect it has on the game. All those things are very bad for the game.

Most players will never know all of the cool stuff that might have been. Few are observant enough to put the clues together. From the player angle, you don't see the cost reductions; they see the new features that don't necessarily make sense to them, and features they are excited about get postponed, sometimes indefinitely. Why are they doing all this player retention work? Why are they putting out more things to sell? We want X Y and Z!! The shallow thinker looks at this and incorrectly thinks money grabbing greedy bastards ignoring what the players want to add more lining their already gold-lined pockets. But what's really happening is the financial reality of the game is taking its toll - reduced feature set, re-prioritization of that set, and scope reduction for those features. Those devs aren't trying to nickel and dime those players; they are fighting to save the game those players love and their jobs.

The big takeaway for the average player should be to try to read between the lines, and give your dev team a little benefit of the doubt. If you see monetization features going into your favorite game instead of things you might have expected, don't think those devs are being greedy. They may have thought of a way to make the game more successful, bring in more revenue, and increase feature development. Or they could be in trouble. In either situation, it's in your best interest as a fan of the game to be helpful. Give feedback that would help those systems and features be successful. If they aren't successful, then the result is likely fewer features in the future. And if there are troubles that process will repeat until the numbers balance out or the game collapses. Neither of those outcomes is good for those who love the game. You should want the game to be successful, and help it be successful if you are able. Support it; encourage others to support it. Give feedback and ideas on how it could be more successful. Do you not like the monetization features? They are there for good reason. Instead of trashing them, try to offer ways they could make it be more acceptable. And most importantly - give the devs a break. They're normal people working under stressful conditions on volatile projects that have very little in the way of job security. However much you want the game to be successful, they have a much bigger investment in that outcome.

Don't Listen...

I wanted to share some great advice I got early on in my time on the PS2 team, from Thomas Schenck (@tomslick42), who is now on the H1Z1 team as the technical director, IIRC. It is applicable to players, devs, and really anyone who uses or develops any product.

In the crunch days before launch of PS2 and the many weeks that followed, we all spent long days and nights at the office making PS2 as great as it could be. During some of these late nights I would often chat with Tom about all sorts of design ideas - he had a lot of them, and also some game history to share. On top topic of feedback from the players, Tom had a great statement that stuck with me throughout my time as a designer. It still sticks with me, because I believe it applies to all forms of software and product development in general.

Don't listen to what they say;  

listen to what they're telling you.

When you work on a game, or any product, you gain knowledge into how that product is made, and more importantly why things are the way they are. You have requirements, insights, and information that is not available to consumers of that product (in this case, the players). They can never know all of the things you know, even if you try to tell them. So the context of the developer is fundamentally different from the context of a player. What a player might see as a problem may be an important part of a design for the developer, which the player wouldn't understand or value. So when a player gives feedback like "This thing sucks, remove it" the developer can't rarely ever take that feedback literally. Instead the developer must interpret that feedback as "This part of the product doesn't feel right" and try to get a better understanding of why the thing isn't working the way they had intended.

I had a similar experience recently with a friend working on a board game he and his buddies were designing. I helped play test the board game, and gave feedback. As I was giving feedback and suggestions, he was translating it into the source of the problem. When I said "it feels like I have nothing to do during this time" his response was "so you want more player interaction?" He had received that feedback before, had thought about it, and immediately recognized the underlying problem from the symptom I had given him. I had thought of ways to alleviate that problem, but his understanding of his game was far better than mine, such as how all the parts moved together. He had a very different response to my feedback than I expected, but it was correct because it took into account all of the history and requirements and other feedback of which I had little knowledge.

Takeaways

Players:

• Try to be as detailed as possible when describing problems, that helps devs frame the problem in their context. 
• Emotion and feel are great things to use, as that usually cuts to the root of an issue.
• Feel free to make suggestions, but expect that they will likely do something different because you don't have all the requirements.
• Lack of response or changes completely different from what you expect doesn't mean your feedback wasn't received - it can often mean a dev combined it with other context unbeknownst to you and arrived at a fix (or lack thereof) they believe is appropriate to all requirements.
• Sometimes they will agree with you, but may not change something for other reasons that override your feedback, or are awaiting other solutions that may address it.

Devs:

• Player feedback may lack context, but it's still giving you an angle that you may not see - their perspective. Just as your context is different, so is theirs.
• Even seemingly toxic feedback can be great. Matt often looked at 4chan and went out of his way to get every piece of feedback - good and bad - that he could to understand what people really thought of the game and how to best improve it.
• Dont' listen to what they say; listen to what they're telling you. :)

And thank you, Tom! You probably had no idea how much I took that to heart!

PS2 Origins: The Hex System

There's a type of blog entry I want to write which I will call PS2 Origins, where I want to discuss how certain things came to be in the game. The first topic is the Hex System, because I really think its important to understand the history of World Design to understand how world design arrived where it did.

Whenever I discuss of lattice and battle flow, as I did last week in Density, two things always come up: 1) The glorious days of the Hex system, and 2) Many bases don't handle lattice well, specifically small (single cap point) outposts. Then typically some suggestions follow. In this post, I'm not going to really push any point here, I just want to clarify history as best I remember it and inform readers how the overall continent flow and level design evolved from Beta through to the present.

I want to preface all of this. I was not on the team before Beta, though I have had many discussions with developers who were, and I played the game since Beta. I joined the team in late-Beta (October, 2012), where I learned a lot more about why things are the way they are, and how it came to be. I was then on the team for the following two years with a lot of knowledge about how and why the changes came about. Devs on the team are free to correct me of anything I may have wrong here. :)

The Hex System

Before we talk about the level design, you need to understand how the flow was expected to be, because the level design was built to support the flow. Knowing this is important to know why the bases are the way they are.

Early Hex

The original flow plan of PlanetSide 2 was known as the Hex System, because every territory was divided up into a cluster of hexagons that bordered one another. There was no lattice or any rules governing capture. You could capture any territory you could get to and interact with the capture point. However, the time it took to capture the territory depended on how many adjacent hexes you had. It was a ticket based capture system where adjacent territories awarded you a flat amount of tickets based on what % of the territory border was friendly. To get the remaining tickets, you had to sit on the capture point for possibly a long time, and/or go take other territories. You always had to sit on the capture point at least a little bit, even if you owned all territory around it.

Here's an image of the hex system from this time (I believe this is post-adjacency rule, which I'll discuss later):

Hex System on Indar - Beta -> May, 2013

A key part of this hex system is that players were free to attack whatever territory they wanted to, but places where they had no adjacency would take a lot longer to capture and be a lot quicker for the enemy to re-capture. This was intended to dissuade such capture, as it was not efficient. Also, territory not connected to your warpgate did not produce passive resources.  More on resources shortly...

The main flow objective of the Hex system was that all major large fighting occurred over the large facilities - the Tech Plants, Bio Labs, and Amp Stations. That's where the big fights were to be, and those facilities were large, with satellite spawns to help facilitate the battle. It was intended that these large structures would be the focal point of combat on the continent. That's one reason the structures were so massive - the size of the structure was intended to draw you to it, and to make it easy to locate from a distance so you know where the big battle was.

The small outposts were intended to be quickly-captured territories, fought over by smaller forces - half a squad, maybe two squads, but they weren't intended to be something hundreds of people fought at. Think of these like capture points in a Battlefield Conquest map - they're basically flag poles around a few buildings in the middle of nowhere. That's what a Small Outpost was originally intended to be. They had no spawn rooms. They had no vehicle terminals. They were a capture point with some small cover.

The Large outposts were meant to provide some medium-level fighting and be more resource rich, and be able to spawn vehicles to help with pushes. Along with the Satellites and the large facilities, these are the only places outside warpgates where you could get vehicles.

This is the context for how the Hex system was intended to work: big fights always happening at the large facilities, small skirmishes happening over the surrounding territories to assist in the capture of the big facility, and to provide resources for the empire. Large outposts served as sort of logistcal checkpoints between the large facilities meant to tide you over until you reached one of the satellites where you could further press into the big objective.

This was supported by Galaxies being spawn points. Newer Planetside players might be a bit bewildered by that concept, but in early Beta, the Galaxy was the mobile spawn, not the Sunderer. It was the intent of the Galaxy to skip over all the small outposts and initiate combat over the large facilities. Your galaxy would give you a spawn point, along with your squad beacon, at least until you could capture the satellite and then have a more stable spawn.

The final piece to this model is the motivation - why do players fight at the big facilities? Why do they take the small outposts, other than to make capture of other territories faster? The answer to that is Resources.

Resources

In the above picture you can also see Pre-Nanite resources in the far-right map panel, which are Aerospace, Mechanical, and Infantry resources  Each hex region had a resource value associated with it that, when captured and connected to a friendly warpgate, would grant the owning empire that amount of resoruces every N minutes (5 min, IIRC, but its not important). In addition, you also collected resources by fighting in a region. Every X or so XP you generated gave you Y resource of the type the region produced. The important takeaway is that if you wanted more aerospace resources, you go and fight in an Aerospace region, and/or you go capture more Aerospace resource regions to generate more of that resource passively. Same for the other resources.

The key thing to understand is that these resources were intended to be a big motivator to why people fight in particular areas. You take small territories around a big facility to gain more resources with which to wage war, and to help capture that facility and other nearby territories. You take the big territory to gain Auraxium.

Indar, PlanetSide2 Alpha, early 2012

Not many readers will remember Auraxium. There was once also a 4th resource called Auraxium that was supposed to be the currency used to unlock weapons and implants. This was later replaced with cert points to unlock. Auraxium was only obtained from the large facilities, but it was also gained passively like the others based on how many you owned. Auraxium was intended to be the reason why players would gravitate towards those large facilities. When Auraxium was removed, so was the main reason players would go for those facilities. They were supposed to be the only place you could get more Auraxium, and like other resources, you also got Auraxium from fighting at the facility. So you want more currency to unlock stuff? Fight at the big facilities to earn Auraxium, and capture/defend them in order to maintain passive Auraxium.

First Contact

On paper, this system actually seems pretty sound. I was fairly optimistic of it at the time, archived everything said about it, and even did a lot of analysis and math to try to figure out how it worked . That was 2012, long before we actually got to play Beta several months later. But even then I noticed some problems with it, illustrated in that post, which I then tried to solve. (Those posts and many others probably helped me get my job as a designer later that year. :)

But more interestingly, the system had some problems when beta came and we got to see it in action. Unfortunately beta forums were wiped long ago, so some of my feedback there is lost, but there were some significant issues.

Players were not drawn to the big bases. They fought there, but not because they were motivated, but because that was one of the few places there were spawn points. At the time, the only hard spawns were Large Outposts (towers), the big facilities and their satellites, and the warpgate. Other than that you had deployed galaxies and squad spawn beacons, which were both soft spawns (easily killed).

Resources felt passive, so actively going out and acquiring them or trying to deny them didn't work. I wrote a lot about this too.

The rich got richer & the poor got poorer. I saw this one coming, but there was no mitigation.The more resources you had, the less you cared about them, and the more vehicles you could spam, and the inverse was also true. Once you got pushed back you had so few resources you couldn't mount an effective counter-attack. This in itself pretty much rendered the resource motivator null.

It took alot of Auraxium to get anything, and Auraxium was later removed from the game and cert points used to purchase instead. It made sense - certs were more universally accessible, and Auraxium had a yuuuge fatal problem once Esamir came into existence, and that was its passive earning. Empires would ignore each other, capture a continent, and then sit on it and passively earn Auraxium from all of the facilities. That was a much easier way to earn Auraxium than actually fighting for it. It turned out that the resource motivator fell flat on its face when multiple continents were involved and it interacted with the Rich get Richer problem. For a time in Beta, Auraxium actually caused the game to grind to a very boring halt as two empires sat on Indar and Esamir and the third tried in futility to break into one of those (they were split of course and had no resources, so they couldn't push in). The game moved to a state of deadlock, and that caused Auraxium to be removed.

But with Auraxium's removal so too went one of the primary motivators to fight at the large facilities. Now you just needed certs to unlock things, and so you could fight anywhere and earn those. So you fought at the places that got you the most certs (i.e. The Crown). What started as a seemingly good idea on paper unraveled like a Christmas sweater.

Ghost-capping was rampant - every territory was under contest, by random guys flying around in aircraft capping and then leaving. You had to play whack-a-mole with empty bases to try to fight it, and that was just to hold your ticket count so you didn't lose the facility you were fighting at. It was extremely boring to try to deal with, and even more frustrating when it succeeded - you would go from winning a facility to instantly losing it when the tickets from adjacent territory losses kicked in. And if you were outnumbered, game over man. You didn't have the manpower to spare trying to capture territories 200-300m away all around you, so eventually you got enveloped and lost - not because you couldn't win the fight, but because you couldn't ghost cap fast enough all around you.

When players captured a territory, they didn't skip over to the next large facility, they moved to the next thing they saw, and then fought there, until they happened to come across another large facility. This is what created The Crown phenomena. It was the only hard spawn between Dahaka, Allatum, and Zurvan, it was defensible, and it was fun. People ignored everything else because a crown fight was actual fun. Go back and look at the first picture I posted in this blog. Look at the NC. They were losing every territory except one - the Crown, because the Crown was fun to fight at, and all the other stuff wasn't.  Whack-a-mole wasn't fun. But the Crown? Guaranteed fight!

The capture system was a reverse ticket race, meant to simulate a Battlefield Conquest-type situation where you have a ticket count and when it reaches a certain point, you win (instead of enemy losing when they hit 0). All it takes to start the race is one person to start a capture, and then the territory is locked into finishing the race. This was a frustrating mechanic, but all tied to the territory-around-you-helps-you-cap-faster system.

Defending territory could only happen at a large facility or large outpost because those had the spawn points, but even then you couldn't always spawn at every one of them, and it wasn't obvious when you needed to go defend.

And another big problem was the Galaxy. It was not a good spawn point for a sustained battle - too big of a target, too easily killed, and too expensive in resources to constantly supply a front. Worse, the nature of the flying galaxy basically meant all ground forces were obsolete. Tanks holding a choke point? No problem, just fly over it and capture the territory behind them.

When there was a decent sized force that came across another, unless it was The Crown, they basically skirmished for a few minutes and went another direction, gobbling up territory for the static 500 xp for a base capture, because that was perceived as the fastest and surest way to unlock certs. I remember standing around at a base with a ring of engineers all standing on each other's ammo boxes firing a pistol shot and reloading to generate more XP for certs while waiting for empty bases to capture. Yep, that was actually PlanetSide 2 for a while.

The original plan of the Hex system simply did not survive first contact with players, who moved from territory to territory seeking the path of least resistance, and only found meaningful fights at Towers. And in its worst form, you had fully captured continents with players sitting around doing nothing collecting Auraxium. To be fair to the devs, I dont' think anyone expected it could be that bad, but it was a disaster.

Adjustments to Hex

Of course they're not going to scrap the Hex system overnight. Too much was invested, too many systems were built around it, and they didn't have the manpower to change it, and the release deadlines were around the corner. There was no ability to build a new system, they had to first try to fix the existing one and make it work.

A great beta tester noticed the problem with the galaxy and wrote about how the spawn point would fit much better on a Sunderer than a Galaxy. The dev team agreed with that tester, and about halfway through Beta the Sunderer replaced the Galaxy as the primary deployable spawn vehicle. The results were incredible and very positive. Battles sprung up all over the place and they were much easier to sustain. More importantly, ground forces were now relevant, and terrain chokepoints became strategically useful. Apart from infiltrators hacking an equipment terminal and pulling out a sunderer, you could actually prevent the enemy from passing you, at least in significant numbers. There were of course ways around it, but it was a big step.

I also proposed a series of changes, many of which were actually implemented (I was still not a dev at this time, but it wasn't long after before I was). The most significant were the addition of Spawn Rooms to all Small Outposts, Vehicle Terminals to all small outposts, and the Adjacency rule.

Having spawn room at small outposts now made it possible to have a fight at a small outpost, rather than just a ghost cap. It meant you didn't need to have a galaxy or sunderer or squad spawn beacon to have any hope of defending one, and most importantly, it meant you could spawn into it to defend it when it was attacked. This was a hugely positive change, but the spawn rooms soon created another problem that already existed somewhat at some of the other bases, but was mitigated by having spawn rooms tied to capture points (that had its own problems too). In this new model, the spawn room stuck around so defenders could use it to respond and create or sustain a fight over a capture point. The problem then was that the attackers would swarm those spawn shacks and it was pretty brutal. Many were also in the open, easily camped by vehicles.

Vehicle terminals at the small outposts meant you could use them to pull Sunderers to initiate an attack or at least move to the next base rather than running on foot. All around good change. However, the tax on level design just with these two changes was pretty significant - a lot more thought needed to into a small outpost now. What was once just a flagpole and a few buildings now needed to have spawn protection, vehicle terminals in accessible locations, and protection against vehicle spam. Most outposts were not ready for this, and the manpower to make these adjustments was yuuuuuge.

The Adjacency rule was a simple rule that meant you couldn't capture territory unless you had a friendly adjacent territory to it. Just one edge of a hex of a region was enough, but it meant that the amount of territory vulnerable to capture shrunk dramatically. If you were reading the Density article from last week, you would recognize that reducing the vulnerable territory is a type of density increase. This helped stabilize the front lines quite a lot, and combined with the Sunderer and other changes above helped create actual battle lines in PS2. It wasn't great yet, but it was a lot better than it used to be.

With this also came the "reinforcements needed" spawn option, that helped players go to a friendly base that needed defenders. This helped fights grow rapidly. It was not without its own problems, but overall it was a great addition to the game and helped create, grow, and respond to fights.

All of these adjustments I would say saved the launch of PS2. If it had launched how it played in beta it would have absolutely cratered and been a complete disaster. These adjustments all together made PlanetSide 2 much more fun.

Legacy

The significant part of this is that through beta, the entire design of the Hex system was altered to adjust to how players actually played the game. Large Facilities were no longer the focal point because of Auraxium - they instead had large resource values attached to them. That really wasn't significant as long as you had one of each type. Small outposts gained in significance dramatically because that's how players tended to use them. Players didn't skip over huge chunks of territory to attack a large base, they instead flowed from one base to the next, fighting the enemy as they were encountered. And with adjacency the ghost capping problem was greatly reduced. This all had the effect of creating for the first time in PS2, a "front" where battle lines were drawn and the empires clashed.

It was not all great - I'd say it went from what was a '1' on a 10 scale to about a 4 or a 5, but as far as patching up an otherwise catastrophic failure goes, it was a pretty darn good job in a short time. As I recall this is about where PS2 was when it launched in November, 2012. There were many more changes to be had in World design in the following six months, but those are posts all their own.

This is the height of the Hex system, fondly remembered by many, and the system under which a great many players fought under for the better part of 6-months to a year (Indar's Hex ended the following May, with Esamir and Amerish following several months after).

Indar, Early 2013

Many players remember this era of PS2 fondly, because they felt they had the freedom to go just about anywhere and do just about anything. And that's an important feeling to remember, because Planetside 2 is a persistent open world game, and that's one of its big selling points. This system did play into that a bit more. However, that does not mean it was good for the gameplay of most players, which is ultimately why it was removed. But that is a tale for another day.

Density

I'm sure there's probably a more official "game design" term for this, but I like to call it Density, or how densely packed the players are in a play space. Almost every game has some aspect of this, Battlefield Conquest maps have larger areas, more outposts as player sizes increase.  A COD map has a much smaller area and typically more constant and consistent action. While it may seem insignificant on the surface, this actually shapes the moment-to-moment gameplay.

Massive Scale Brings Massive Challenges

This concept is particularly important to Open-World MMOs such as PlanetSide and PlanetSide 2. Lets assume you have a 8k x 8k area, with 1500 people somewhere in that area.

First, the density range is itself a problem. 1) That's about 23 players per square kilometer if they were evenly distributed - far larger than most FPS maps. 2) In the other direction, you can have 1500 players in a single square kilometer (or smaller) if they were to all gravitate to one area. For #1, your problem is players are too spread out and not interacting. For #2 your problem is that so many players in one spot grinds the server and framerates to a halt. So you can't have players too spread out, and you can't have players all together.

The density itself changes the gameplay. Some weapons become problems at high player counts in tight areas, like grenades. Some players like smaller fights; some want huge fights. Most just want any decent (i.e. reasonably balanced population-wise) fight.

There's also the problem of population & persistence. The population isn't fixed at 1500. Sometimes it may be maxed like at prime time; other times it may be very low, like at 4 in the morning where you may have 1/20th the population. Yet your map is still fixed. That is the fundamental challenge of a persistent world large-scale MMO - the map is fixed, but the player count isn't.

And finally you're up against Free Will. Players can go wherever they want. You have to convince them (willingly for the most part) to fight in the desired densities, and to do so in reasonably fair numbers, without them feeling "forced" to do things. Which is tough, because gamers always feel "forced" by the devs to do stuff. :)

And if that isn't enough - this is all further exacerbated when your primary content is PvP - you need players to interact in order to have a game experience. When players come in and don't find good interaction they will quickly get bored and leave.

All of this combines into a perfect storm of challenge to make a game like PlanetSide 2 actually function and be fun. And for all its faults, it's still going after 4 years when many other more traditional games have come and gone and didn't even last a month on our machines. I think it's important to remember that PS2 has outlasted a yuge number of games.

OK so hopefully I've got you thinking about something you hadn't considered before and I convinced you it is extremely important to get right. So now onto some of the macro approaches to stabilize density, make it flexible, and have a game that actually creates many of these experiences. You'll recognize a lot of them i'm sure.

Most games control density very simply - they fix the player size and fix the map size (they constrain it), and then use gameplay and objectives to focus the players into key areas to create/entice conflict. Things like power-ups, capture points, terrain bottlenecks, etc are all examples of ways to manipulate the density to create the conflict you want. And if its' too tight - make the map bigger. If it's too sparse, reduce the number of objectives, or reduce the map size, or both. Some games like RPGs us phasing tech to keep density from getting too high. A lot of that isn't easy for PS2 given the scale and fixed persistent maps, so we have to be more creative. Lets look at some of the tools PlanetSide 2 uses.


Continent Locking


When you have a massive open persistent world, your options on controlling density are a lot more restricted. You usually can't just cut down the active map space - you could have many places relevant, and that would ruin the whole point of the large scale.  In PS2, an example of cutting down the active map space is Continent Locking. If you lock a continent and another doesn't open up, you've closed the active map space and forced remaining players to converge to the remaining open continents. The important effect is that have increased density while also providing a intermediate victory condition to an endless war. If you have the right size and count of continents, this could be a very good way of handling population fluctuation and stabilizing density. That was largely how continent locking helped PS1; at prime time, 6-8 continents would be unlocked and decently active, and late night it typically converged down to 1-2.

This is the same function continent locking serves in PS2, however the map sizes are much bigger than PS1, and the continent count much smaller. It's less-granular, so there's higher density variability. Still, when you have very low pop, like on servers like Briggs where only one continent is open most of the time, we have effectively limited the active map to 25% of what it was before continent locking. That's a huge difference for Briggsers.

I've always thought that the PS2 continent locking approach wasn't aggressive enough. This is one area that could use more tuning.


Lattice

Another way to increase density without constraining the map space, is to reduce the number of actionable objectives. This is fundamentally what the lattice does at a macro-level. It takes what could be 90 different objectives and reduces it down to a much smaller amount. While the entire continent is being contested and is playable, only a subset of it is actually in play. This preserves the scale of the game and its large area while still serving to increase and stabilize the density.

Lattice serves a second purpose, and that is to also funnel and force conflict. Early on in PS2 there was no lattice, and players often skirted right around each other, even large zergs because there was nothing that forced them to fight over a territory - if it looked too tough or couldn't be steamrolled just ignore and go around. They had 3-4 other choices typically and would avoid each other for the path of least resistance. With the lattice, avoiding the enemy is much more difficult. When the feature first went in it was immediately obvious as the combat intensity increased quite significantly.

Number of links, or level of constraint int he lattice, is a key tuning knob. Too many links and the lattice loses a lot of it's density stabilizing properties. To few links and the game feels incredibly constrained. For PS2 this was largely a trial-and-error process and resulted in 3-4 links per territory typically. For PS1, with it's smaller continents, the lattice was very tight, typically 2-3 links at most facilities.

Lattice also has the effect of accenting persistence, because there's chunks of territory off-limits, and territory is not constantly changing hands all over the map. That makes the map more stable, and the feeling of conquest more meaningful than a fleeting capture that will flip another half dozen times in the next hour.


Player Mobility

A key impact of density is also player mobility. Players moving rapidly around the map destabilizes fights, and causes density to be highly variable, to the point where you can't actually get stable fights or a stable front. This can be mitigated somewhat with a more restricted lattice so there are fewer meaningful places to jump to, leading to more stability.

It is important to understand that the goal in controlling mobility is not to prevent players from going where they want to go; it is to encourage them, on the whole, to generally not bounce around in significant numbers in a short period of time and destabilize engagements. That means doing such rapid movement may not be easy or convenient, or it may take a few minutes to do.  While players often want to go where they want right at that instant, it isn't a good thing for the game when everyone can and does exactly that. A good philosophy is to let them do what they want to do, but have meaningful consequences for their choices. Stable density = easy & free, volatile density = difficult and expensive.

Features like reinforcements needed and instant action can provide mobility to players while stabilizing density (when they work correctly!). The idea is pretty simple - offer mobility, but limit the choices to places that help stabilize density. Of course when 50 players all use it simultaneously you have a problem. The never-built resource revamp had some means to address that.



Those familiar with my history in PS2 will notice a trend in these features - they are all features I worked on and tuned at some point in PS2's development. At the most fundamental level, density is what I consider the most important macro-scale element for a MMOFPS game such as PS2. It is what sets the stage for your entire game experience and shapes the success of the product.

With continent locking, lattice, and controlled mobility, you take a giant mess that is an open persistnat world with 75-100 objectives and turn it into a series of typically reasonably balanced fights. It's far from perfect, but PS2 is a pioneer in a largely uncharted genre. It takes time to get it right, and as with all innovation there's often a lot of failure before you find success.