Homefront - Multiplayer Screenshot

Know what to Build: Assessing Impacts

In an earlier post I described some multiplayer game types and identified several clues about the server architecture required to build each type. Now I want to take a closer look at some of those clues to see how they can help us know what to build.

Architecture Clues Revisited

Recall our list of multiplayer game types, each with a short list of architecture clues:

TypeReference Problem StatementSelected Archtecture Clues
FPSCreate a multiplayer combat action supporting up to 256 players who see the world through the virtual eyes of the player's character. Real time 3D physics simulation and graphics rendering makes the player's experience immersive and realistic.
Up to 256 connected clients.
Real time 3D physics simulation
Projectile-based weapons
RTSCreate a multiplayer combat strategy game supporting up to 8 players controlling several hundred to a few thousand units each on a shared map.

High number of units per player
MMO
Create a multiplayer online game where several hundred to thousands of players interact in a large rich and dynamic environment.
Large number of players
Large shared world
Persistent character state
Text and voice chat features
MMORPGCreate an MMO where character development and and advancement is the central hub of all game play.
MMO features plus:
Unique character visuals
Items are important and ubiquitous
Persistent item state
Persistent mission state
Persistent alliances
MMORTSCreate an MMO where players establish bases, raise armies, and conquer territory through fast-paced strategic PVP combat in a large shared world.

MMO features plus:
AI assistance
Persistent player bases
Persistent alliances
Persistent global leader board
MMOFPSCreate an MMO where players can experience intense first-person combat in a vast virtual world using military style weapons and vehicles with realistic physics and movement.
MMO features plus:
Movement and physics
World geometry Items are important and ubiquitous
Persistent item state
In-world object interaction
Persistent global leader board

These are key game design features that seem likely to have a major impact on the each game’s server architecture. But let me take a step back for a minute. How did I decide that these features are worth looking at?

When building a software architecture, we need to understand the key engineering decisions and the areas most prone to mistakes. We should invest in getting these key decisions right so that our design is resilient to changes as we iterate. 1)Chapter 1: What Is Software Architecture?Microsoft Application Architecture Guide, 2nd Edition. Microsoft, Oct. 2009. Web. 9 Sept. 2015.

The features I listed as architectural “clues” are those most likely to involve key engineering decisions. That is, they involve the following:

  • Novel or complex technologies, such as real-time 3D physics simulation or AI assisted combat.
  • High performance requirements, such as large number of objects per player, or players in a shared world.
  • Complex data design and management requirements, such as persistent character, item, and other game state.
  • Cross-cutting concerns, such as ubiquity of items and general persistence.

Magnitude Matters

To understand the key engineering decisions, we need an idea of the relative impact each feature will have on the architecture. This affects the amount of thought, time, effort, and other resources we’ll have to apply to that feature.

For this, we’ll have to answer some questions about each of these features:

  • How big is it?
  • How complex is it?
  • How important is it?

Other questions might come up, but, these three are universal, and should be fine for our purposes. We can generalize the importance question to cover a lot of scenarios if needed.

We need to estimate the relative size, complexity, and importance of these design features. I’ll use an artificial metric, magnitude of impact, to help us do this. It’s a scale from 0-5, where 0 means no impact, 1 is low, 3 is medium and 5 is high. This is a crude, but useful model, and is easy to represent visually:

Feature Impact Example
Feature Impact Example

For each of our features, let’s think of some ways to apply these three questions, and rank the possible answers.

For example, our FPS game design specifies up to 256 players in combat at one time. That means we’ll have 256 clients connected to our game server. It’s likely that the more connected clients our game supports, the greater our engineering challenge and risk. From prior experience in playing and developing multiplayer games, we can infer that, in theory, the number of connected clients for a game could be from two to several thousand. We’ll map this range onto our size metric:

FeatureDimensionLowLow/MedMedMed/HighHigh
Connected ClientsSize2642565121024

Our target of 256 players falls in the middle of our range, so I’ll assign a size value of 3.

Intense multiplayer combat in Homefront by THQ.
flickr photo shared by THQ Insider under a Creative Commons ( BY-ND ) license.

For connected clients, the complexity metric might relate to the type of client. That is, whether it’s a web browser (hey, it could happen), mobile app, PC client (win/mac/linux), console (PS4, Xbone, etc.), or some combination. Each type of client may have unique requirements that the server has to honor. These will probably affect server complexity to some extent. For the sake of discussion, I’ll rank them like this:

FeatureDimensionLowLow/MedMedMed/HighHigh
Connected ClientsComplexityWebMobilePCConsoleMixed

Our game design states that we’ll target consoles first, and PCs later, so I’ll set our complexity as 4 on our scale.

Finally, we need to show the importance of this feature to the game. For an FPS game, the number of simultaneous players affects both performance and game play. If the game design calls for styles of combat and teamwork that need two teams of 128 players each, our server implementation better be able to handle it. Likewise, if we plan to promote our game as having the “most players of any FPS”, but our server handles only a total of 64 players, we will have failed.

Unlike size and complexity, our importance dimension doesn’t have any discrete buckets to be mapped onto our scale. I’ll assign it the value 5, because massive battles is very important to our game’s design.

Now, let’s take a look at our overall impact assessment for the feature of having 256 simultaneous players:

Feature Impact: Connected Clients
Feature Impact: Connected Clients

Alone, this doesn’t mean so much. It also doesn’t tell us much more than we might have inferred just from reading the game design. We’ll need to assess the combined impacts of all our features to give us the big picture for our game.

Feature Impacts and the Big Picture

Now let’s take a step back and look at all the features of a game. For this, we’ll use the MMORPG game design, because its reference problem statement is more detailed and gives us more features to look at:

TypeReference Problem StatementSelected Archtecture Clues
MMO
Create a multiplayer online game where several hundred to thousands of players interact in a large rich and dynamic environment.
Large number of players
Large shared world
Persistent character state
Text and voice chat features
MMORPGCreate an MMO where character development and and advancement is the central hub of all game play.
MMO features plus:
Unique character visuals
Items are important and ubiquitous
Persistent item state
Persistent mission state
Persistent alliances

I’ll take a stab at estimating the impact of each of the features listed in the architecture clues column. Because our design is very simple I’ll have to make some assumptions. That’s okay though. On a real project, we’d be doing this with incomplete information too. Again, we’re at the start of a project, assessing the architecture impacts of the game design as early as possible.

Feature Impacts Ranked by Total Impact

Now we have more to work with. I added a Total Impact bar to each feature, which is just the sum of the size, complexity, and importance bars. This lets me sort the features by their overall architectural impact, putting those with the greatest impact at the top. Recall that our goal here is to identify the key engineering decisions and technical risk items. This is a decent first pass at that.

Architecture Informs Design

Our ranked list also gives us a springboard for iterating with our design team. Until now, we’ve only had a theoretical design model to work from. Now, the design team can see early feedback from their decisions. Also, our producers and product management team can see which features will need the most attention, time, and resources.

If this ranking doesn’t match everyone’s expectations, we’ll need to adjust course. We iterate. The designers may need to re-scope or re-prioritize certain features to bring them into line. Or, they may need to collaborate more closely with programmers to better understand the constraints and communicate design details and goals.

flickr photo shared by Jovial Joystick under a Creative Commons ( BY ) license
flickr photo shared by Jovial Joystick under a Creative Commons ( BY ) license

For example, the Large Shared World and Persistent Item State features vie for the top spot in our impact list. Maybe our designers hadn’t expected the large world to be as complex as looks like it might be. Perhaps they also believe item state to be essential to their design goals, and they know it will take a lot of iteration on both the design and implementation to get it right. They may choose to relax some of their size or complexity expectations for Large Shared World to allow more attention to Persistent Item State.

We’ll also need to reconcile this ranking against design and technical dependencies, which we haven’t explored yet. If a top-ranked feature in our list has a hard dependency on a lower-ranked one, it will put pressure on our project time line or resources. Our product management team will want to consider this in planning and messaging to execs and marketing.

flickr photo shared by Mellicious under a Creative Commons ( BY-ND ) license
flickr photo shared by Mellicious under a Creative Commons ( BY-ND ) license

Consider again our top-ranked Persistent Item State feature. It’s likely to have some dependencies on the Persistent Character State feature. In terms of development order, we probably won’t be saving items until we’ve solidified character persistence somewhat. At the very least, we might need to work through several use cases that address character development, advancement, and combat before we think much about inventory. This may mean we have to defer working on our highest impact feature while we get the lower impact one figured out. This is just a risk of development; we may not be able to change it. However, it means a lot to be able to communicate it as early as possible.

Keeping it Simple

Architecture is about figuring out the big stuff. Early in our development cycle we can start to identify game features that are likely to have a high impact on our architecture.  We do this by focusing on those areas that involve key engineering decisions and technical risk. We can assess and rank the relative impacts of these features using a simple metric for sizecomplexity, and importance. This ranking is easy to visualize graphically to generate early technical feedback on design decisions and priorities. This allows the team to iterate on big concepts before we commit many resources to implementation.

What I’ve shown here is simple, but powerful. It’s a pragmatic approach for revealing key architecture concerns to help us know what to build for our game server. We need to keep it simple so that we can iterate quickly and not drill too deep too early.

In a future post, I’ll talk about deployment concerns in game server architecture. Deployment is more than just putting code into production. It determines the shape of our server architecture. Identifying our architecture’s deployment early is another important part of knowing what to build.

What do you think about this approach? Is it useful, or just too obvious to spend time on? What has your experience taught you about identifying architecture impacts early in development? Please feel free to share both your opinion and your wisdom with me here at Engines of Delight.

Leave a Reply

Your email address will not be published. Required fields are marked *

WordPress Anti-Spam by WP-SpamShield