Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lens numbers 84 through 87.
Game Design Talk EP9
Reply
Monthly Archives: May 2018
Game Design Talk EP8
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lens numbers 75 through 83.
Game Design Talk EP7
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lens numbers 68 through 74.
Game Design Talk EP6
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lens numbers 61 through 67.
Game Design Talk EP5
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lenses in chapter 13 “Interface” lens numbers 53 through 60.
Game Design Talk EP4
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lenses in chapter 11 and 12, lens numbers 41 through 52.
Game Design Talk EP3
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lenses in chapter 11, lens numbers 30 through 40.
Game Design Talk EP2
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we read and talk about the lenses in chapter ten, numbers 21 through 29.
Game Design Talk EP1
Andy and I discuss “The Art of Game Design: A Book of Lenses” by Jesse Schell.
Wherein we introduce the book and talk about lenses one to twenty.
Uplift: Block Scale Nesting
Minecraft uses a single-scale voxel engine, with 1m blocks. The lack of sub-division prevents easily modifying smaller and larger scales.
Instead of considering block textures to be immutable and cosmetic, it could be a 
rendered representation of a projection of the sub-blocks that compose the block itself. In this way, we could see the classic Minecraft grass and dirt blocks as a single level of nesting in a multi-level system of detail. Because all Minecraft blocks share a texture size (16×16 by default), this isn’t a particularly difficult stretch of the imagination. Minecraft blocks, too, exist in 16×16 chunks, each of which carries some data about biomes, heightmaps, and so forth. The problem here is that all of the user-level and simulation-level operations act on a block level. None of them operate on the textures or the chunks. Continue reading
Scarcity
I’d like to talk about artificial scarcity, and how I think it is generally a poor solution. I should begin, though, by an overview of True Scarcity, and its effects on our lives.
True Scarcity, like real things have. Resources are scarce, time, energy, materials, space, attention. People throw around “post-scarcity” as an achievable goal, but depending on how you draw the threshold it could have already happened, or it could never happen.
Artificial Scarcity has to do with arbitrarily limited things, like CCGs, limited runs, and modern currencies. Mimics True Scarcity in order to reproduce its effects. Can be marginally useful (currency), or deceptive (CCG). I don’t like it.
Narrative Scarcity? Resources limited to form a cohesive story (fictional True Scarcity or contrived Artificial Scarcity). Intrinsically artificial in reality (no reason the storyteller can’t solve scarcity by fiat), but percieved as true in context. Mis-used in either direction can lead to story collapse.
Artificial scarcity occurs a lot in games, but aside from people being familiar with this way of thinking, and as a tool for exploring true scarcity, I don’t see the advantage. For example, there is (effectively) no marginal cost to distributing DLC to all game owners. Or to releasing all games into the public domain. At the limit, this ties back to the “win” button. Artificially limiting story progression by game performance is… well, artificial scarcity.
Quests
A “quest” is a stand-in for AI imperative communication.
Speculative history of quests. Started with individual goals. Then transitioned to chains (multiple sequential goals), then to laundry lists (paralell goals) (Many small quests can be rolled into one big one). Very few are reactive to player performance and world state. Completing a quest often resets effective world-state. Rewards are generally in-game money, equipment, relationship points (a different form of currency), and experience (which doesn’t make sense, wouldn’t you gain experience based on how well you performed, and what you did, rather than whether you returned to the quest-giver).
Could be combined with communication (deceit) and bartering. Certainly need to be more reactive.
What’s in a Starship?
We see a lot of depictions of starships. Star Trek, Starwars, and countless others. I’d like to teach computers to make starships, and explore the design-space. But to do that, I’d have to know what a starship was in the first place!
What is this? Is it really a starship? How can we be sure?
So I turned to Jeff Zugale, who recently published Starshipwright One: Science Fiction Spaceships, a collection of 178 of his sketches and renderings, a few of which I have included sections of here as examples, but without permission. Hopefully he doesn’t mind. In perusing the pages, several patterns jumped out at me, which I have cataloged here for your perusal. I’d like to go over the major ones, and offer my own criteria for what it seems like would identify a starship, but apparently doesn’t, as well as what it seems to me is the single defining characteristic.
Pragmatic Parametric Game Design
Shamus wrote an article on procedural generation and I figured I’d follow up with a few of my own thoughts.
Parametric stuff, rules based design. Random = creators decisions. Controllable = design patterns.
Do it manually first. Teaching the machine how to act is nearly impossible if you don’t know how to do it in the first place. Continue reading
Structures, Semantics, Abilities, and Play
The structure of a game sets the stage.
The semantics of a game sets the atmosphere.
The abilities of players and characters dictate the kind of stories that can be told in-game.
Too few abilities stifles expression. Too many abilities stifles creativity.
Too few semantics stifles expression. Too many semantics stifles creativity.
Too much structure stifles expression. Too little structure stifles creativity.
I wish I could recall the fervor of the ideas with which I began this post. Perhaps too much structure.
These are all various angles one may hold a game. In order to examine it. In order to evaluate it. Play is the emergent behavior of an intelligence in contact with a healthy balance between the three.
Fledgeling Scenario
Scenarios are the thing you play in Fledgeling. They are, in essence, a “what if” proposition. While the ideaspace holds all the possibilities of the setting, the scenario outlines the particulars. But even though the scenario will limit the actual state of the world, many particulars could be left open in order to offer the player room to customize and experiment.
We want to make it easy to design scenarios.
Anything not specified in the scenario will be filled in from the “parent” scenario.
Infinite time and energy, thinking about things as sub-characters attempt to embody your fancies. Spalling off sub-universes as you speculate on different archetypes.
Pausing in slow-motion trying to make a hard decision. While that is happening, a new high-growth crisis emerges (nano-tech fire), overturning the whole point of the decision in the first place.
Zarth and Tumult
Corridor: Technical Infrastructure
Last time I wrote about the structure of the overall capability arc in Corridor. This time, I’d like to explore some ideas for how to implement Corridor.
Everything is Corridors
So, the first thing is the cohesive underlying principle. A corridor is a designed transit space. We’re most familiar with the spatial variety, that is a transport corridor along a space-time vector, but one can have corridors along any axis. Storage is a transport corridor along a simple time vector. A workshop is a transformative corridor, along a time vector. A vehicle is a corridor generator on the outside, and storage within. Nested corridors! Continue reading
Player Input
The player really needs to have input in the game. As much input as possible really. The previous article about AI Assistance in mind, much of this input should be optional as well, but the options should be available.
Input is one of the defining characteristics of a game. Can we simply expose all aspects of the game world to the player? How much is too much? Continue reading