What is Project Atlas?
Atlas was a third-person extraction shooter by EVE Online developer CCP Games to which I contributed as one of four senior game designers. It was intended as the successor to their popular Playstation title Dust 514, and took inspiration from games like Escape From Tarkov and Scavengers.
Players deployed to semi-persistent planets in squads of up to three, completed assigned missions, collected equipment, and then needed to reach and briefly defend an extraction point in order to keep their hard-earned loot.
They were sorted into factions upon deployment, with mild incentives to collaborate along faction lines. Friendly fire was always on, however, and everything a player carried could be looted by others. This meant that collaboration was risky, trust hard-earned, and betrayal common.
The project was briefly closed before eventually releasing as EVE Vanguard, but its Creative Director (Gerard Lehiany) left me a LinkedIn recommendation referencing it, stating: I specifically remember saying one day, as Dylan was presenting his latest work to the design team and myself, "that's a decade I haven't heard such a refreshing design and approach to solving a problem using player agency as the solution.”
This is the presentation for that work, adjusted for a wider audience.
Design Goals
I was tasked with designing a mission system: the overarching feature that defined what mission content consisted of as well as how it was distributed to players and sat within the context of the game as a whole. Before beginning, I identified five key goals of the design. There were other objectives and design constraints defined by the product and surrounding features, and some will be mentioned briefly here as they become relevant.
Inspire group play and connections with strangers
Atlas was intended to be a social PvP game, with clans and other key systems. Those communities, however, need to be served by gameplay that facilitates connections.
Enable a viable and affordable MVP content set
Mission content takes time to produce. The missions system needed to be functional and effective with minimal content work.
Engage player throughout the product’s life cycle
The system needed to either provide enough unique content that a player never ran out, or needed to provide sufficiently replayable content.
Facilitate skill & equipment goal-setting
Missions provide short-term goals, but the real hook is the long-term character progression chase. Missions should support that.
Create engaging gameplay experiences
At the end of the day, if the game’s core objective system does not engage the players, it has failed.
Overview: Missions as map objectives
Missions exist as objectives on the match map, rather than assignments to a specific squad.
Their availability is dynamic, based upon the map state meeting certain criteria.
Objectives are available to an entire faction at once.
Players will have multiple objectives available to them at any time.
Objectives often entail two or more factions engaged in competing goals.
Objectives provide a variety of incentives to complete them beyond their explicit rewards.
Missions are one part of an ecosystem
-
When starting a match, I choose the map and the faction I am deploying with.
I start with only the group that I have manually made myself. Matchmaking does not match squads nor assign missions during deployment.
Deployment matchmaking’s primary objective is keep an active map full, with an even balance of players between factions.
After deployment, I can flag to join nearby squads of the same faction and later opt to leave one of those squads.
This dynamic “looking for group” squad system eases the weight on our matchmaking and social systems, while letting players maintain their numbers advantage and sense of personal agency.
This was very important, because the matchmaking folks had been struggling to identify a system that would both support balanced matches of players and ensure that squads were served missions that none of them had completed. This design effectively solved that problem for them, resulting in a cheaper, more efficient matchmaking system.
-
My faction determines the amount of time I can spend on the surface (ie, in a match), as well as the objectives that may become available.
I am only paid a fraction of my earnings if I do not extract successfully. This is framed as an extraction bonus, rather than a death punishment.
Objectives are dynamically unlocked through play and can be designed to create map-wide match progression.
-
When I am selecting my equipment before deployment, I know what to expect with:
Weather and environmental damage types on the selected map.
Engagement distances, cover, and line of sight common on the map.
Likely objectives and type of playstyle preferred by my faction.
This is the information most important and relevant to this choice, but even mistakes (or unforeseen circumstances, such as hidden content) can be mitigated or adjusted on-world by either hot-swapping gear mid-session or selecting a different task from a set of varied objectives.
-
Either as explicit rewards, or as part of their execution, each mission provides a selection of the following progression items:
ISK (in-game currency)
Faction Reputation
Skillpoints (experience points)
Equipment
Crafting resources
Selections of map and faction — and specific objectives during deployment — can be made to intentionally further self-given progression goals.
Mission Selection Process
As objectives appear, they are offered to player squads. The following slides show the flow of how this process works.
Defining Mission Objectives
What exactly are these objectives, though? The following slides detail a proposed initial set of five(-ish) mission objectives. These are archetypes - underlying mechanics without a narrative wrapper. Examples of these archetypes wrapped are included to demonstrate them in use.
Prerequisites create
organic dynamics
Objectives are not always available, but rather come and go based upon pre-requisites that must be met by the map state and match history. Additionally, not all objectives are advertised, leaving room for discoverable or opportunity-based tasks.
These two elements combine to create an organic and emergent flow to both the individual user’s journey and the match’s entirety.
A mission does not necessarily need to have every prerequisite attached to it, but providing mission designers with this kind of palette and tool is the difference between a very repetitive “game mode” experience and living, semi-persistent space that reinforces a player’s suspension of disbelief.
Example Prerequisites
The list that follows is a base-line set of prerequisites. Ideally, this would be expanded upon during live-servicing as we observed holes and opportunities for improved narrative arcs.
Geography & Location
Is [MISSION] offered on this map?
Is [ITEM] currently on the map?
Is [ITEM] currently in any player’s inventory?
Are [COUNT] players of [FACTION] on this map?
Are [COUNT] players of [FACTION] within [DISTANCE] of [LOCATION]?
Mission History
Has [MISSION] been completed during this match?
Has [MISSION] been completed within [TIME]?
Has [MISSION] been failed within [TIME]?
Has [MISSION] been offered within [TIME]?
Is a group currently working on [MISSION]?
User Story: Dynamic missions in action
Emergent systems can be very difficult for many people to fully grasp how they fit together. For this reason, user stories are extremely effective ways of communicating the intended experience from the player’s perspective - after all, elegant systems are completely useless if they don’t create the correct user experience.
The slides below are the user story I created in order to fully convey to my team and to leadership what the design should truly feel like.
It should be noted that “user story” is a name I have found affixed to a number of different document types. This is not even the first kind of “user story” I became aware of as a design professional. So, while I am aware that this may not fit everyone’s idea of user story, it does what it does very effectively: communicate and keep designers (including myself) focused on the user’s experience.
Macro Implications: Seasons, Texture, & Segmentation
Map objectives and their results could be tracked and fed into a macro, persistent narrative loop governed by a live-ops design team. The story could be easily updated with asset and spawn swaps, letting designers tell an environmental narrative that evolves season to season based upon player activity.
This macro loop could also feed a leaderboards system, and tie into clan-based play by allowing player organizations to “employ” their own players (as a faction) for clan-wide incentives.
Small actions contribute to Live-ops & macro meta-narratives
On a map, no two factions would offer the same set of objectives. This differentiation allows designers to tell the story of a map and the factions pursuing their individual interests there.
By tying all of this into faction-specific codes of conduct (an ancillary system that added additional incentives for following optional gameplay restrictions), designers have a strong capacity to breathe lots of life into these groups in meaningful ways.
Assymetrical Objectives Feed Faction Definitions
Assymetrical Objectives Support Player segmentation
This also creates a unique set of objectives for each faction that determine its playstyle and the player archetype it best serves. The inter-relatedness of the dynamic objectives means that, upon creation, not only does an objective archetype need to be considered, but also its relation to other players and objectives.
Objectives can therefore be organized into four categories to help identify the player archetypes that they best serve.
Why a Dynamic Sandbox?
A better player experience
The risk of narrative dissonance with multiplayer is lower than when engaging with recognizable, bespoke missions, where a mission may be perfect for one player, already completed by another, and make no narrative sense for the third.
By directly reflecting their actions, player agency is also increased - and not at the cost of user directive in group play.
Finally, the structure of a match both individually and across the entire map is easier to attain in a way that is meaningful and engaging for every player.
A healthier Live-Service Foundation
Objectives form an economy of gameplay emergence that can be added to during the live-cycle should things start to feel stale. Even minor changes to existing objectives could have major impacts to the meta and overall gameplay experience.
If properly supported by tooling, these objectives should inexpensive to produce, while providing strong repeatable gameplay potential.
A healthier New Eden MMO Foundation
Atlas wasn’t intended to exist in a vacuum, but rather to integrate directly into New Eden — the universe of EVE Online. As such, there are expectations imposed by the IP itself, as well as intentions to eventually grow into an MMO in its own right.
This kind of sandbox gameplay would deliver on the promise of the IP’s fantasy much better than traditional RPG mission systems, and would aid in the building of social and player-driven communities.
Cheaper and Faster development
One of the most pressing issues we faced with mission content was budgetary. We had a multiplication problem: leadership initially wanted multiple missions for multiple factions on every map, and for there to be enough that players could reliably go the length of a season without being served a mission that they had already completed.
I had recently been working on content for EVE Online, and referenced my experience there to present the stark reality of the dev cost of such an endeavor. The numbers I presented, as I had suspected, were untenable.
Dynamic sandbox missions, by contrast, are designed to be a system that can ship in its infancy if needed, but also expand into a sprawling ecosystem of content and emergent narrative with minimal dev time and cost.
Focusing on emergent designs, rather than prescriptive, enables the same piece of content to provide a vast array of experiences by allowing/encouraging the context of the experience (environment, other players, competing considerations, etc.) to be dynamic and changing. This system is designed to offer missions whenever a set of requirements are met, rather than randomly or according to a branching linear narrative (as leadership had initially suggested). The missions are crafted as repeatable elements that can be shuffled into a wide variety of experiences.
This enables a system that can start small, without broken narratives, and be built up with whatever budget that remains, easily and seamlessly moving from minimalist “map as scenario” to the ideal “dynamic, emergent narrative of the world” as pace and budget allows. This achieves minimum shippable faster, requires a smaller content set to successfully meet MVP requirements, and leaves room for infinite expansion with what time is left and through live-service development.
A narrative foundation
Should they be desired later, linear or branching narratives are easily created within this system by manipulating simple rules, preserving that kind of future content without putting any part of the project at risk.
It also leaves space for organic, environmental narrative, letting designers tell stories through observable detail that players may piece together only through repeated play.
Stronger Retention Foundation
The longer a player is retained, the more likely they are to spend, and social groups retain better than solitary players.
By letting me organically form and dissolve squads, I will encounter more players. By forming squads around shared objectives, I have an increased chance of forming a connection to other players, and letting me leave a squad at will enables me to quickly extricate myself from unsatisfactory social situations — effectively increasing the quality of my social interactions, minimizing toxicity, and aiding in the formation of stronger, healthier social bonds between players.