Thinking of games as databases
There are serious aesthetic ramifications for running with the idea of games (and especially game rules) as being primarily composed of databases.<p>Specifically, at least in my experience, foregrounding database thinking when making game rules tends to make it easier for designers to add more rules and rule variations, or a lot more &quot;content&quot; generally, that tends to be more shallow and less novel in terms of surprising interactivity.<p>Now, that can be a desired kind of game design!  If you look at something like, say, Gran Tourismo, where the pleasure is in having hundreds of real cars modelled, that can be really enjoyable to a certain kind of player.  And of course most static level data is just a giant collection of non-interactive data variations as well.  There are certainly other examples.<p>But if you sit down with, say, the original NES Legend of Zelda, with a paper notebook in your lap, and every time you encounter a new enemy, you write down the enemy&#x27;s name, what is interesting about them, and what you might have to do to implement them, what you&#x27;re going to notice is that the lion&#x27;s share of enemies have custom behavior and interactivity that will need to be special cased, and that that is all the meaningful work of implementing that enemy.<p>Now, obviously, you COULD still use something like a database as the central repository for distinguishing the identities of all of the monsters and their properties.  But in practice, the property of &quot;it gets on top of you and eats your magic shield&quot; is only used by the Like-Likes, the property of &quot;it grabs you and drags you back to the dungeon start&quot; is only used by the wall hand guys, and on and on and on, and _aesthetically_ the game benefits from the fact that each interesting enemy property is only used by each unique enemy (or so I would very, very strongly argue).<p>I&#x27;ve sat down and performed that &quot;notebook in the lap&quot; exercise with a bunch of games in the past, with Half-Life, Castlevania:Symphony of the Night, and Mario 64 being particularly fruitful (the same exercise works for items and weapons in a game, and interactive objects in game levels as well).  One of the big traits that makes SOTN the game that it is is that a fair number of the weapons and items in the game have all sorts of strange, surprising, extremely special case game code, like the Shield Rod.<p>My personal experience from working on game dev teams as a game programmer&#x2F;designer is that, as game programmers are drawn more into database thinking as the lens for expressing game design, the kinds of sparkly, jagged, surprising rules I just gestured at start feeling more and more like violations of the architecture of the system, gumming it up and making it ugly, instead of the actual wonderful desired point of the entire enterprise of game making.<p>And so instead you get games where much of the variations between items or weapons or enemies are things like statistic percentage variations - this weapon has +20% critical hit chance compared to that weapon, this enemy absorbs that kind of damage, this weapon has that attack speed, this enemy has that running speed, this enemy can or can&#x27;t throw grenades, and so on.<p>I feel like I encounter this kind of design a lot in more recent games made by large teams.  And it makes sense.  Often management needs tighter control over game rule possibilities because they have large teams and novel surprising custom game rules are legitimately unpredictable and hard for teams to control or reason about - especially in the context of long-lived games that are going to be maintained by lots of random people coming and going over a long time frame.  Having weapons&#x2F;items&#x2F;enemies that vary only by properties make it easier to add or remove them to hit deadlines without breaking the critical path of the game, they&#x27;re much easier to apply analytics to for balancing, and they&#x27;re much easier to use as DLC without affecting games in potentially show stopping ways, too.<p>But there are absolutely aesthetic ramifications to this approach.  At any given moment, when a player is playing a game and deciding, without consciously recognizing it, whether they&#x27;re going to continue sticking with a game or whether they&#x27;re bored, the question of what new kinds of new stuff they might still encounter if they keep playing is definitely a factor.  And what kinds of rules a game designer can and does vary heavily affects that.