Software is a solution to some problem. As I’ve already said, software architecture is the foundation on which we build our software. It’s at the core of the solution we offer in any software we build.
What’s Our Problem?
But to get to a useful solution, we must first define the problem. In traditional software development, this means identifying the business requirements for the system, or what we want the system to do. We start this by writing a problem statement. Here’s a simplified example for a boring old banking website:
Provide a system by which bank customers can view their account balance, transfer funds, and pay bills via the web, without help from a bank employee.
- Who is affected: bank customers (and possibly bank employees).
- What the system will do: view balances, transfer funds, and pay bills.
- The constraints imposed on the system: use the web, no help required.
This statement serves as the basis for more detailed analysis, which ultimately reveals specific requirements for the software. Those requirements tell us about the architecture we need to build.
In game development it’s the same, except that the “business requirements” are a lot more fun. Here, we express the requirements in terms of the game design. Again, the problem statement describes the problem at a high level, identifying the goals and constraints of the design. Schell, Jesse. “The Game Begins With An Idea.” The Art of Game Design, A Book of Lenses. Second ed. Pittsburgh: CRC, 2014. P 73. Print. Consider this example for a multiplayer game:
Create an intense, fast-action sci-fi shooting game where two teams of up to 32 players from all over the internet compete for points in timed matches. Teams earn points when their players kill opposing team members, assist in kills, or capture and defend strategic positions. Players compete for bragging rights via a global leader board that publishes their individual scores across all matches.
As with the boring bank example, this captures:
- Who is involved: players and teams.
- What the game will do: let players annihilate one another via projectile weapons in team-based combat.
- The constraints imposed on the system: 32 players per team, internet connection, timed matches.
While not detailed enough to write code from, this description clearly defines the scope of the game. It serves as a good starting point to flesh out the game design. That design is what informs us about the architecture that will support the game’s software.
What you should see from these examples is that they don’t dictate how to build the system. That is, they focus only on the problem, not the solution. Only when we understand the problem well enough can we start talking about the solution. It’s at that point when we can start thinking about the game’s architecture.
We’ve Seen This Before
The game industry is mature enough that most modern games, even great ones, incorporate design features invented in earlier games. As game developers, we stand on the shoulders of giants. Consistently fun and engaging designs reappear in new forms. Occasionally, we create something completely new, often delivered in a familiar package to make it more accessible and friendly.
We’ve got a great resource of existing work and experience from which to draw inspiration for new games. So that we can better understand and talk about this resource, we generalize important game characteristics and use them to classify games. This leads us use broad terms (or their abbreviations), such as first person shooter (FPS), role-playing game (RPG), real-time strategy game (RTS), and the like, as starting points for describing new designs.
Essentially, we have a kind of catalog of generalized, common, problem statements. We can use this catalog to help us learn about the server architectures used in the solutions to these common problems.
Multiplayer Game Types
Classifying multiplayer games into types seems straightforward at first. That work has already been done many times over, right? Not so much, it turns out. I’ve found several lists of games of one type or another, but no good list of game types. Anything I’ve found that gets close is incomplete for our purposes. So, I’ll just create one myself.
Wherever possible, I’ll draw from existing classifications and conventional wisdom. Where necessary, I’ll roll my own. Since it’s my list, I’ll add a reference problem statement for a fictitious game of each game type. I’ll keep these somewhat simple for the sake of brevity, but I’ll try to use realistic game features. Note that the problem statement for a given game type may not apply to all games of that type. It should do well enough for our purposes, though.
|Type||Reference Problem Statement||Game Examples|
|FPS||Create 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.||Quake 2
Call of Duty
|RTS||Create a multiplayer combat strategy game supporting up to 8 players controlling several hundred to a few thousand units each on a shared map. ||Command and Conquer
|MMO||Create a multiplayer online game where several hundred to thousands of players interact in a large rich and dynamic environment. ||Eve Online Eve Online describes itself as "an open-ended Massively Multiplayer Online Game (MMOG)." It does not fall cleanly into one of the more specific types below so we'll just call it an "MMO" for now - … Continue reading
See more specific MMO examples below.
|MMORPG||Create an MMO where character development and and advancement is the central hub of all game play. ||Ultima Online
World of Warcraft
Elder Scrolls Online
|MMORTS||Create an MMO where players establish bases, raise armies, and conquer territory through fast-paced strategic PVP combat in a large shared world.||Shattered Galaxy
|MMOFPS||Create 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.||Planetside
|MOBA||(Omitted for now: incomplete information.)||League of Legends
Defense of the Ancients
|Sandbox||(Omitted for now: incomplete information.)||Minecraft
|MMOS||(Omitted for now: incomplete information.)||Trove
Sorry about the incomplete entries near the end of the table. I decided that I’m not yet qualified to write problem statements for some those game types. I’ll leave them for another time. However, I still think it’s important to acknowledge them for now, because they’re within scope for this discussion. Oh, and you’re welcome to reply to this post with your own suggestions for the missing problem statements. In fact, I’d really appreciate that!
Game Design Drives Architecture
Each of the reference problem statements in our table is a starting point of a game design. Even though they’re written at a very high level of abstraction, they contain clues about the server architecture required to build that type of game. As with most aspects of software development, creating a software architecture requires an iterative approach. Discovering these clues is an early iteration in our process.
Take a look at the FPS game type example. In its problem statement, the sentence, “Real time 3D physics simulation and graphics rendering makes the player’s experience immersive and realistic,” calls for 3D physics and graphics computation. At Engines of Delight our focus is the server, so we can ignore the graphics requirement for now. But, think about the physics requirement. Do we need this on the server?
In a competitive multiplayer action game where movement is essential to game play, you bet we do. To have fair play, all players must interact with the same world geometry. An explosion that kills player A but only injures player B must have the same effect when viewed from either player’s client. It’s the server’s responsibility to make sure this happens.
Okay, but what makes this an architecture concern? Well, architecture is about “the big stuff”, the things that greatly impact implementation and are costly to change once put in place. Implementing a 3D physics simulation on the server qualifies for several reasons:
- Real-time 3D physics is complex and hard to get right. It will need a lot of testing and iteration at a number of levels throughout much of the game’s development process.
- A physics engine usually involves a build vs. buy decision. The right choice for a given game depends on several factors, such as features, performance, team experience level (build), vendor support (buy), and return on investment (build). It also brings architecture concerns like implementation language and compatibility with other libraries.
- At some point, simulation models must interact with game play models at runtime. Physics will constrain game play, game play will generate physics events, and the two models must agree. Early choices about how to do this will influence the design of both models.
Clearly, we should explore decisions about implementing the 3D physics simulation on the server early in development. Again, we’ll iterate on those decisions, but we’ll need to stabilize the physics engine fairly early because other game systems will depend on it.
For another example, check out our MMORPG game type. Its problem statement includes, “Players acquire items during play, from other players, or by creating them from raw materials found in the world. They use these items to enhance future play, or may sell or trade them. Virtual money exists as a medium of exchange and store of value.” This reveals several architecture concerns:
- Items are important to many aspects of game play. From this, we infer that the game must support a variety of item types and many item instances. It’s also reasonable to expect items to show behavior and change state as part of game play. This affects decisions about networking protocols, data serialization, and performance, to name a few.
- Many game systems will interact with items in some way. This requires clear interfaces and abstractions, and attention to separation of concerns. This drives decisions about the content creation pipeline and tools: specifying item properties and data-driven rules for item behavior. It also influences distributed processing choices. These may include assigning item-related responsibilities to specific servers and propagating item state updates between servers.
- Players acquire, or own, items. Because player state persists, item state must persist. This drives decisions about data storage technology and implementation. A relational table-based structure easily represents player characters alone. Yet, once you account for the various ways in which a player may refer to items, we quickly end up with an object graph. This type of data could drive us towards a NoSQL database, an object database, or perhaps serialized data (BLOB) storage.
Consider the examples in the next table a first pass at identifying potential architectural concerns. Have I overlooked anything? Leave a comment and let me know.
|Type||Selected Archtecture Clues|
|FPS||Up to 256 connected clients.
Real time 3D physics simulation
|RTS||High number of units per player
|MMO||Large number of players
Large shared world
Persistent character state
Text and voice chat features
|MMORPG||MMO features plus:
Unique character visuals
Items are important and ubiquitous
Persistent item state
Persistent mission state
|MMORTS||MMO features plus:
Persistent player bases
Persistent global leader board
|MMOFPS||MMO features plus:
Movement and physics
World geometry Items are important and ubiquitous
Persistent item state
In-world object interaction
Persistent global leader board
Coming up, I’ll drill down into some of these clues and talk more about the server architectures we’ll need for these different game types. In future posts I’ll cover various architectural patterns for solving some of these problems, and others that don’t work so well.
Once again, thanks for reading and for sticking it out with me as I “find my voice” with Engines of Delight. Remember, please leave feedback with suggestions, comments, corrections, or topics you’d like to see discussed in the future.