One of the things that most annoys me in a number of games is when I have a great idea that should work, but the game doesn’t have any special coding for the idea and so my great idea is null and void. One expects this if you’ve come up with a convoluted idea that would only work in The Incredible Machine, but when it’s as simple as, “I have a knife and I want to cut that string, but no matter how I try I can’t cut the string with the knife,” is when it gets frustrating and takes you out of the game. Most modern games don’t quite have it this bad, but there are still some situations in modern games where this happens and you start thinking in terms of gaming, rather than terms of existing. The phrase “Of course it won’t let me do that” comes to mind. When players utter this or similar phrases, we are now talking about the game as a separate entity, distancing ourselves from the immersion set up by the game.
Of course, there is a problem here. The game designers who make a game have no idea who their players will be as an individual. They can only fathom just so many combinations of possible actions. This is where emergent gameplay comes from, as players discover unexpected ways to use the actions created by the designers. Emergent gameplay is generally considered a good thing, but it points at the problem. As the designers cannot predict everything that a player may want to do, they will unintentionally close off actions that, to the players, seem like a perfectly viable thing to do. This is only natural. If a game designer tried to make every combination of actions possible for every situation, games would never get made. It would be unrealistic to expect a game to do everything that a player would want it to do, as the vast number of permutations would not only delay the making of the game, but also make it less accessible (owing to the games increasingly larger size on a hard disc). This unfortunately causes a gap between the player, the game and the game designer.
My solution to close this gap (not simply to fill it) is to lessen the work of the designer, while allowing the designer to account for more potential actions. I’m going to call this attributive gameplay. First I’ll describe this non-technically, and then I will launch into a brief, slightly more technical description that might be accessible to designers or programmers. What I mean by attributive gameplay is that gameplay elements have attributes and that games should react based on those attributes. In our example, we have a knife that should, by normal logic be able to cut a string. Knives are sharp; strings are cuttable. If anything that is sharp can cut anything that is cuttable, then all that is needed is to allow the case of cutting something that is cuttable.
In programming, there are objects and these objects are of something called a type. A type houses any number of common values (in some programming languages, these are called attributes). Multiple objects can be of the same type and new types can be made based on other types, inheriting all the values of the base type. As these new types are derived from another type, an object can be used as both the type it explicitly is and any types it is derives from. As an example, say we want to make a knife. To make the knife, we might want to use three types. The first type would be a generic type that contains all the values that every other object in the game would commonly share (position, for example). Then we might derive from that type another called inventory, which would house all the values that would be commonly shared by anything the player may pick up (e.g., how heavy it is). Finally, a third type, called sharp, derived from the inventory type. This type would have all the values common to anything sharp (the degree to which it is sharp, for example). We could then make an object, called knife and give it the type of sharp. It could still be used as an inventory object, and as a generic object, but it has the added designation of being sharp. We could do the same with a string object, so that the string could be of the type cuttable. Then, as a programmer, we would only have to write the code for the interactions between a cuttable object and a sharp object. After that, we could make an axe, a pair of scissors and even a different kind of knife and make them all of the sharp type, and we wouldn’t have to worry about writing any extra code for each object to interact with a cuttable object.
This is only one way to do it, and there are probably many better ways, but I think this way best describes what I’m trying to get at. Overall, I want to try to have the programmer write less, but still catch more possible actions. The key is to reduce things to their qualities, their attributes, and have the qualities interact with each other. This is what I’m hoping to achieve with my project “Now We Are Twenty-Three,” which I mentioned last time. Will this mean that people will do a lot of things I don’t expect them to in the game, sure. I welcome this prospect. It is my hope that there won’t be a single action they try that will simply be met with a message like, “You can’t do that.” I’m sure to fail a little, as players are crafty, but I should, at least, be able to close the gap just a little.