On Wargaming: [Pt. 4] – Metagaming

In this post I’ll be discussing metagaming and its ramifications when playing computer game simulations. In a later post, I’ll discuss my personal experience with gaming, and then I’ll be applying this concept to some of the individual games.

Note: When I refer to a simulation as “high-fidelity” that means I’m referencing a simulation that models the detailed functions of a specific platform. For example, a high-fidelity flight simulator would model an aircraft’s entire cockpit to include the specific button presses and toggles required to operate the aircraft’s systems. Additionally, such a flight simulator would include a highly realistic flight model that simulates aerodynamics and the associated physics.

The term meta

We’ve probably all heard the term meta, as in, “that’s so meta.” As a prefix, it actually means beyond or about another thing. For example, the term metaphysics concerns that which is beyond our known physical realm. Similarly, in psychology and education, there’s the concept of metacognition which is when a person thinks about their own thought processes and learning styles. Today, the popular lexicon uses the term meta to broadly indicate when something becomes self-referential or self-aware. In the case of entertainment, a work becomes “meta” when it “breaks the fourth wall” (i.e. addresses the audience), or when it acknowledges the fact that it’s a work of fiction and exists within its own self-contained universe.

Metagaming & the “Game Mechanic Logic Test”

In gaming culture, “metagaming” is where players use their real-world knowledge to make decisions and/or gain an advantage against the more restrictive programming/rules of a game. The concept of metagaming can apply to virtually all aspects of a game. Broadly speaking, metagaming relies on the player having some degree of knowledge of a game’s strengths and limitations. It can even be as simple as the player taking a step back and pondering about what the game is and how it plays. For the sake of simplicity, let’s break down metagaming as applied to a game’s overall design, mechanics, and graphics. This is by no means an official or standard method of metagaming, but it’s just my own way of categorizing the information.

There’s a fair amount of academic literature that’s been written on game theory, game studies (ludology), and the relevant analysis of those topics and subtopics. I’m certainly no expert and I won’t attempt to provide a mathematical analysis of decision making processes. However, when it comes to video games, I’ve been a gamer for most of my life, so I’m pretty familiar with the subculture. That being said, I’ve never played a traditional tabletop war game/conflict simulation, apart from classic board games. Thus, my experience with realistic simulators and war games (apart from chess and the like) has been on digital platforms. Over time, one thing I began to critically examine was how games, specifically computer game simulators, are designed to portray certain facets of reality. What I didn’t realize, at the time, was that I was engaging in a type of metagaming (and the relevant analysis).

Metagaming game design

Every game has a certain classification with regard to how it was designed. In evaluating and metagaming a game’s design, we need to look at what the developers had in mind when building the game in the first place. More broadly speaking, we would be carefully defining what genre(s) and sub-genre(s) this game belongs to.

Recall in the post on the levels of war that different games simulate different levels of warfare. A tactical simulator may have operational and strategic elements in the gameplay, but it likely doesn’t simulate those elements to the same degree of fidelity as a strategic or operational game. A real-time strategy simulator doesn’t have the same level of tactical detail as a tactical simulator. There are plenty of examples out there of games that attempted to bridge the gap between the strategic, operational, and tactical levels of warfare. Most of them failed or were severely handicapped by the limitations of the engine. Anyone who remembers the mid-90s PC game, Battlecruiser 3000AD, will also recall that it was a very ambitious concept from Derek Smart that tried to blend more strategic/operational space combat elements aboard a large warship with tactical air combat and first-person shooter aspects on planets. Basically, the player commanded a large warship in which they could travel around the galaxy. In addition, they could jump into a one-man fighter for a dogfight, and eventually go ground-side and experience a more first-person style of play. The game had a long, troubled, and heavily scrutinized development. Ultimately, what we got was a buggy and unstable disaster. You’d be lucky if the game even ran properly. Yet, another instance of a game that promised a lot, but failed to deliver. In fact, that game has gone down in gaming history as an example of a development train wreck.

Defining the limits of a simulator is important because any game is subject to the limits of it’s programming. Sadly, we haven’t seen a simulator that models all levels of warfare and platforms with extreme high-fidelity. In reality, such a game doesn’t exist and would likely be too cost-prohibitive to develop, ridiculous in terms of the hardware requirements, and massive in terms of the disk space required. Games that have tried to implement such features usually end up simplifying many of the game mechanics. Other games fail completely. It would certainly be nice if there was a game that fully modeled everything, but at the end of the day, it’s a piece of software and no game can accurately simulate every possible aspect of reality. The blurring of the line between simulation and reality is a discussion for someone far more intelligent that me.

Here’s another analogy. Remember in high school physics when you were given projectile motion problems (e.g. a ball being thrown up in the air) and the instructions told you to ignore air resistance? Those mathematical equations are very simplistic and ignore all other variables except initial velocity and the gravitational constant. Yes, they simulate the basic concepts (at the high school level), but don’t account for any additional variables. Adding variables like air resistance would require further analysis. Similarly, recall that one of the main arguments against using simulators as analysis tools is that they’re inherently “representations” of reality. Since there are a multitude of variables that aren’t simulated, we should be wary of interpreting the results of the simulation as “representative” of reality.

Even in simulators that represent the tactical level of war, there are limitations based on their design. For example, we know that a tactical first-person shooter with an advanced ballistics model will not model ground, sea, or air vehicles as realistically as a dedicated vehicle simulator of their respective types. No doubt, sandbox games, like ARMA, have bridged the gap to some extent and have integrated various aspects of infantry, ground vehicle, and air combat together. However, a close examination reveals that such sandbox games don’t simulate every platform to a high degree of fidelity. Games like ARMA, DCS, Dangerous Waters, and Steel Beasts are all very different in terms of what platforms they simulate well, even though they contain aspects of each other. ARMA (as it has evolved over the years) is largely an infantry simulation with sandbox elements that includes the use of ground vehicles, boats, and aircraft. DCS simulates air combat with some ground vehicles and naval vessels modeled. Dangerous Waters models tactical submarine and anti-submarine warfare (from an Oliver Hazard Perry-class frigate, MH-60, and P-3 Orion). Steel Beasts focuses on tactical armored warfare with some mechanized elements. In essence, what we have are a variety of different tactical simulators that provide vastly different high-fidelity experiences. However, none of them cover all of the modeled land, sea, and air warfare platforms to a high degree of fidelity all in a single game.

The point here is that a simulator may model facets A, B, and C extremely well, but that’s because it’s specifically programmed to do that. The simulator may have some capability to also model facets X, Y, and Z, but not to the level of detail and accuracy that it models A, B, and C.

We must define the genre and broad capabilities of a simulator before making further assumptions about its design. We can’t expect a piece of software to simulate every minute detail of reality because that just wouldn’t be practical. There are limitations to the programming with regard to what the game designers intended to simulate.

Metagaming game mechanics

Once we’ve ascertained the genre and designed intent of the simulator, we can examine the mechanics more closely. As you play any video game (even high-fidelity simulators) more and more, you gain familiarity with it, begin to understand what the game’s engine is designed to do, and what it’s capabilities are. Eventually, you become so familiar with the game’s mechanics that you can predict what the game will do under certain circumstances because you know what features are programmed into the game, even if you don’t know the specifics of the game’s programming language and code. Thus, with this knowledge in mind, you can anticipate situations and be proactive to counter them. Informally, this type of metagaming, regarding the understanding of a game’s mechanics, is what I refer to as the “game mechanic logic test.”

There are many ways to apply the game mechanic logic test, but we’ll only be examining a few, which are identifying contrivances in game mechanics, learning a game engine’s limitations, and making reasonable assumptions about the game’s programming.

Perhaps the simplest example of the game mechanic logic test is when games introduce contrived mechanics or convoluted solutions to problems that would have simple solutions in real-life. No doubt, every gamer has experienced a frustrating time when they couldn’t implement a simple and logical solution to a problem. Much like how a Rube Goldberg device goes through many complicated steps to accomplish a single, yet simple task, a game can have overly complex mechanics in scenarios. Essentially, this is the video game version of cutting the Gordian Knot (or at least trying to). The classic example is what TVTropes refers to as the “Insurmountable Waist High Fence.” The Insurmountable Waist High Fence is, for whatever reason, a small barrier (such as a fallen log, a row of hedges, a shallow stream of water, etc.) that any able-bodied person (not to mention the physically adept player character) could easily step over, step through, jump over, crawl under, or scale in real-life. However, in the game it blocks the player from progressing any further. In some cases, it’s simply an invisible wall, and even if the player character can jump, they still can’t surmount the obstacle. This is usually done by game designers in an open area to demarcate the edges of a map. As if to sarcastically say, “no way could I simply stack up some of the boxes lying around and hop over this fence. No, that would just be too practical.” A similar example would be seemingly ordinary doors which require complex puzzle solutions to open, when in real-life, a solid kick to the door would probably suffice to break it down. This type of metagaming involving the game mechanics prohibiting seemingly simple real-life solutions points out contrivances in a game’s design. Yet, such mechanics were popular in many point-and-click adventure games in the 1990s which had complex puzzles to solve in order to progress.

With regard to the player gradually learning the game’s engine, the player might say to themselves, “the game is definitely going to spawn a new wave of enemies once I pass through this doorway because that’s what it always does.” Or, “the A.I. always gets stuck in doorways and can’t navigate tight spaces.” Or, “the enemies have a very limited cone of vision in front of them and they don’t notice their dead comrades, so it’ll be easy to sneak around and take them out one at a time.” In cases such as these, the player has learned how their actions will trigger certain game mechanics and understand the limitations of the game’s engine. Thus, the player can prepare themselves to face a new wave of enemies or exploit the limitations of the A.I. to stealthily move through an area. Metagaming that exploits weaknesses or oversights in a game’s A.I. is what TVTropes refers to as an “A.I. Breaker.”

Another facet of the game mechanic logic test is making assumptions about what mechanics would reasonably be programmed into a game given its genre and engine. Let’s examine an operations simulator like Command: Modern Operations (CMO) to provide us with some examples of this. CMO is designed to simulate air and naval operations. It’s not a high-fidelity tactical simulator on par with games like DCS or Dangerous Waters because the player doesn’t do any actual “trigger pulling.” As I noted in my War Games Series post, the developers of CMO are very much aware of the limitations of the game’s engine and note that:

Much of the “turning/burning” parts of air combat are abstracted by hit rates and crew proficiency. The part of the human element the player can control is getting the assets to the right place at the right time. …Even in scenarios intended to re-enact historical battles or wars, the results are frequently much different from the actual outcome. This is to be expected. While a bug report may be in order if the historical result is never obtained even once, variation is normal and good.

Command’s engine is intended to be able to simulate everything from 1940s broadside duels to futuristic satellite-cued ballistic missile strikes with a reasonable degree of success, not be incredibly accurate for any one conflict. To return to the Vietnam analogy, the performance of similar, and frequently the exact same aircraft and weapons varied widely by conflict. There was Vietnam, the Indo-Pakistan, and Arab-Israeli Wars in the same time period.

Attempting to model any one of these conflicts with one hundred percent razor-sharp accuracy would make any of the others less effective. One would be faced with either an ahistorically strong Egyptian/Syrian Air Force or an ahistorically weak North Vietnamese one if a strict model intended for one was used for the other.

In addition, real events can only happen once, while the simulator can be run many times. The real result may have been a one-in-a-hundred “outlier”, while the most common one have been quite different.

(WarfareSims.com, 2019, p. 257-258

Thus, CMO is designed as an operations war game and meant to simulate the movement and employment of units on a broader scale than your average “boots on the ground” perspective. In other words, the gameplay largely revolves around getting assets from point A to point B in an efficient manner to meet various threats. The tactics employed by the units are fairly rudimentary given the abstraction. Units will take appropriate evasive action, but you won’t see them being very tactically creative, and many historical tactics aren’t modeled. For example, CMO doesn’t show battle lines maneuvering to cross the T with the enemy battle line to concentrate their firepower. However, the player can manually change formations and maneuver units to do so. In other A.I.-ontrolled instances, the Thach Weave isn’t used by the F4F Wildcats to deal with the A6M Zero’s maneuverability. Operators at SAM sites don’t quickly turn the radars on and off to avoid giving away their position to SEAD forces. The list goes on. The A.I. in CMO isn’t programmed to use those tactics and it’s too tactically specific in a simulator designed for more broad-scale operations. The player won’t be able to replicate many unique tactics like they could in playing a combat flight simulator like DCS.

Effectively, the game mechanic logic test also applies to one-in-a-million instances where strange or remarkable events occurred. Such mechanics wouldn’t pass the test because they’re flukes and far too specific to expect a developer to program into the game.

On the other hand, a simulator that incorporates a surprising amount of detail with regard to what it models can be beneficial. Occasionally, we are surprised with game mechanics that wouldn’t seemingly be programmed into the game, but are, nonetheless. TVTropes refers to this as “Developers’ Foresight” which is where the game’s programmers seemingly thought of everything the player would do (or try to do) beforehand, and programmed it in. Although I mentioned that CMO is designed as an operations simulator with the appropriate mechanics, it still has a surprising amount to tactical veracity to it. In a non-simulator example, Metal Gear Solid 2 had a litany of details programmed into the game that served no purpose other than to add realism and immersion. To give some examples, shooting an ice bucket in the galley of the ship spilled the ice cubes which then slowly melted. From my understanding, the programmers literally created an algorithm to make the ice cubes melt. In other examples from the game, if the player looked up while standing underneath a flock of seagulls, bird poop would land on the camera. If the player was spotted and triggered an alert, tougher enemies would show up as the alert level became higher. The responding forces arrived more prepared and used accurate room-clearing tactics. Eventually, they came at you with shotguns, wearing body armor, and carrying ballistic shields. Working as fire teams, they stacked up prior to room entry, and used flashbangs and grenades to flush you out of hiding spots. There wasn’t much of a reason for many of these details to be included in the game, but they were there, and they demonstrated that the programmers put in a great deal of effort at getting many small details correct.

Therefore, when examining a specific game’s mechanics, it’s prudent to ask if certain mechanics make sense to be included in the game to begin with. Would a developer program in a certain mechanic even though it’s highly specific or has no evident reason to be modeled in the game? If a mechanic has shortcomings which proves artificial and allows the player (or computer) an unrealistic advantage, it may underscore limitations of the game’s engine or be superfluous to the game’s original design. If a mechanic enhances gameplay or adds detail, it can show effort made on the part of the developers, even if it doesn’t seemingly pass the game mechanic logic test.

Metagaming game graphics

Metagaming a game’s graphics is probably the easiest and least ambiguous of ways to transcend the game environment. It’s purely visual.

This type of metagaming can occur in various forms, such as knowing what objects the player can/can’t interact with. For example, all interactive doors sharing the same texture, objects with different shades of color than the background, objects being highlighted and clearly marked, or objects having higher/lower polygon counts which show more/less detail. Similarly, objects/enemies having the same graphical textures which allow for easy identification. In this way, the player can visually interpret more efficient methods of interacting with the game’s environment by ignoring objects which are non-essential to progress.

Another example of graphical metagaming can be seen with objects having binary states of existence. TVTropes refers to this as “Critical Existence Failure” where something works perfectly (and appears to be in perfect condition) until its hit points run out and then it’s totally destroyed (suddenly turning into a burning, black hulk). Alternatively, when the simplest of attacks causes the loss of a final health point, and suddenly the seemingly perfectly healthy character dies.

In terms of animations, graphical metagaming is evident when enemies telegraph their attacks. This is due to the same animations being used, but it allows the player to anticipate when attacks will occur.

Is metagaming good or bad?

All in all, these were just a few examples of how metagaming could be applied to video games and simulators. In reality, metagaming is a constant thing which occurs virtually anytime we play games or simulations. It even occurs if only for the fact that we know in our minds that what we’re doing is purely simulated and not reality. My experience in playing video games and simulators is always tempered by the fact that I’m really just sitting in front of a screen, using a controller, or pressing keyboard keys, and clicking the mouse buttons. Doing it for real would be a far different proposition. Thus, metagaming is somewhat inevitable.

The validity of metagaming depends on who you’re talking to. In traditional role-playing games, metagaming is generally frowned upon because it breaks with the character and game rules. However, when it comes to video games and simulators, I would contend that metagaming can be applied either positively or negatively. In a well-programmed game, it can bring attention to detail and forethought in the game’s design. However, in a game with many bugs or oversights, it serves to point out glaring omissions and errors in game design, mechanics, and/or graphics. This is apparent in simulators with regards to game features/mechanics that they’re supposed to simulate well, but in fact, don’t. You may find yourself asking, “why is this game so poor at simulating ____?” or, “shouldn’t ____ already be a feature in this game?” In those types of instances, the fault lies less with the player metagaming, and more with the game having issues with its development.

Ultimately, metagaming is simply the player comprehending the artificial limitations of a game and the artificiality of games themselves. All games and simulations require some degree of imagination and/or suspension of disbelief in order to function because they’re not reality. The degree to which the player may need to suspend their disbelief is arguably dependent on how immersive the game’s environment is and how well-programmed it is. Regardless, the limitations will become apparent to the player given enough time. Whether or not the player can take advantage of those limitations, be they due to the game’s design, mechanics, or graphics, is up to the player to decide.

References

WarfareSims.com. (2019). Game Manual Command: Modern Operations. Matrix Games.

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s