I talk about a lot of stuff without really filtering it. I kind of rely on Belghast to yell at me if a post devolves into jargon, but he’s been listening to me blather for so long that I think he’s developed an immunity. Someone commented recently that I didn’t consider most of the implementations of player housing to involve “gameplay”, and seemed quite upset about it. I thought I might share some of how I view games from a building-them perspective.
Gameplay and Feedback Loops
The word “gameplay” means a lot of things to a lot of people, but it has a fairly specific and reasonably well-defined meaning. Like a lot of things within the industry, it isn’t universally agreed on, so any attempt I make at pinning down a definition is tricky. I’ll need to draw the camera out a little bit.
To define gameplay, I need to touch on something called a “feedback loop”. Simply put, a feedback loop is what you, the player, are doing in any given three-to-ten-second window of time while in the game. It’s the smallest amount of time in which action can occur and you both experience the primary mechanics of the game and make decisions on how to use said mechanics.
In Mario, your feedback loops are jumping between platforms, or onto enemies. In Street Fighter, it’s an exchange of blows, or a combo, or a special move. In racing games, it’s the various inputs that make up actually driving the car. You can boil a game down to the most basic concepts, stuff like “when at edge of platform, press A to jump”, and that’s a feedback loop. Feedback loops are the building blocks of game design; and in almost every game they involve either movement or combat, because they’re the easiest things to abstract into button presses and build upon from there. Oversimplified, feedback loops are “when you are pressing buttons”.
Gameplay, then, is feedback loops strung together. It is the time when the player is actively involved in the game using the most developed mechanics available within the system (usually movement or combat or both).
What About The Rest of the Game?
My definition of gameplay above is pretty restrictive. Depending on the game, it excludes huge swathes of the overall time you spend, and often there’s overlap between gameplay and things that aren’t. Designers have a term for that: “experience”. The experience of a game is everything from the art, the music, sitting around roleplaying in chat, taking screenshots, watching cutscenes, fighting enemies, wandering around… everything. The term “player experience” is bandied about a lot, and there’s a lot of back and forth about how certain things things are presented, how the game communicates what the player is supposed to do (“messaging”), how the UI helps or hinders, and how that all interacts with gameplay.
When I mentioned that player housing didn’t involve gameplay, what I meant was that few player housing systems to date have involved the basic feedback loops that exist in the game. They are, without a doubt, a core (and dearly loved) part of the experience, but they aren’t gameplay.
To draw a bit of contrast, compare Minecraft to EQ2, in terms of housing. Minecraft has its basic feedback loops built around obtaining and processing material, as well as placing it in the world to fit your whims. Housing in Minecraft is centered around these feedback loops; it is gameplay. Belghast’s immediate excitement about a player housing system used a Minecraft reference, and the spark that came through when he mentioned it is precisely what I’m talking about when I say that player housing should involve gameplay.
Gameplay versus Experience
The sad reality of game design is that on every project, on every game that gets released, some features are cut, and some content doesn’t make it, and some things that might have been awesome die before seeing the light of day. It’s called “scoping”, and it’s insanely difficult to do. Sometimes these decisions are easy and popular. “Oh, we don’t have the art budget to have 30 player races, and so we’ll only have 8? Okay.” Somteimes they’re easy but unpopular. “Designing and balancing 25 unique classes is completely infeasible, so we’re cutting down to 10, and of the 15 that got cut were the favorites of half the staff? Ouch, but it has to be done.”
Mostly, though, the decisions are hard. Do you ship with 10 classes, or 6 well-balanced ones? Do you ship with 30 zones, some of which might not be complete or even have much if any content in them, or do you ship with 15 and try to make sure that every single one is fully complete? Do you craft a lot of side content for explorer-type players, or do you include less content but put more development time into it so that the experience is richer?
Almost always, these decisions will have gameplay as the dividing line. If it involves gameplay, it’s a lot less likely to get cut than something that doesn’t. The reason for this is that gameplay is the thing that absorbs the most programming time, the most tech, the most art, animation, worldbuilding, etc, and it’s the thing that engages players.
In the case of player housing, in order for it to justify its massive resource expense, it’s going to need to be inextricably linked to gameplay, so that the housing system doesn’t end up on the “easy and (un)popular” chopping block, when push comes to shove.
You know, kind of like Minecraft.