How much do you really need to create?

I read through Montfort and Bogost's Racing the Beam this week. A fascinating look at the Atari 2600 (or VCS, as it was known when it launched, and which they therefore call it throughout the book) as a platform, and what its peculiarities meant for the people who made games for it. Looking at how much people were able to do with so little makes me wonder whether I really need all the tools I've come to depend on.

These people did not have more than 128 bytes of RAM to work with or memory-mapped graphics, much less higher-level languages, IDEs, interactive debuggers that step through the source code easily. And yet within short spans of six months, these people would make games which were genre-defining, and commercially successful. And they did sometimes have to compete with higher quality hardware - both from other consoles that came after, and from the arcade machines which, at the time, were the high end of hardware prowess.

Yes, the games were much simpler, and the expectations were nevertheless lower than they are now. But is that really an excuse? You would think that with better tools you would be able to make better products, but it doesn't feel like that's the case. I don't feel that I am equal to these people in my output. Am I truly making the best of the tools in front of me? Or should I try and use fewer of them, and see what that's like?

When playing through some examples from Computer Systems: a Programmer's Approach, since they are written to be compiled and run under a more bare-bones Linux platform, I have made use of Microsoft Windows' Windows Subsystem for Linux, along with a text editor and command line use of the GCC toolchain to solve problems (and sometimes fix code that has since been broken). Would I be able to create something as complex as a Windows, or Linux for that matter, video game, using just such tools? I would think so. Actual Linux is how I did most of my development when I was an undergraduate. But I have definitely not done this for a long time.

Console cowboys and arcade aces

On several occasions, William Gibson has noted that his inspiration for console cowboys in Neuromancer wasn't necessarily contemporary hacker culture, but instead the kids he saw in video arcades who became experts at the games, so immersed they mastered these new pieces of technology.

Before video games became a home phenomenon, their greatest popularization was through arcade machines. I, myself, remember spending far too much time and my parents` money on these machines in the 90s, but at least overseas the first wave started in the late 70s, and author Martin Amis wrote a very illuminating contemporary account published in 1982, Invasion of the Space Invaders. It is interesting to see how much closer to the grimy entertainment culture of dive bars, drug dens, and porn theaters. He describes his relationship to them as addictive, and interprets their design in the context of getting as many quarters from players as possible. He then also describes the people who have mastered some of these games, the aces, how they exchanged tips with each other, and in fact spends a third of the book describing tips and strategies for the most popular games. Another third is dedicated to home and hand-held consoles, comparing them with the arcade experience.

Sol Yurick's 1965 novel The Warriors obviously predates the video game arcade phenomenon, but one of the Warriors encounters an arcade full of mechanical games in the same Times Square station in which he earlier has an experience at a brothel, and feels quite at home in that milieu.

This kind of social, ubiquitous but subcultural view of gaming seems very distant now that "Gamer" has been so heavily molded by ads and marketing. Ironic that the "barcade" is in fact a lot closer to the origin of video games as a cultural phenomenon, although it's obviously quite gentrified.

Modern art and computer graphics

Last weekend I spent a long time at the Museum of Modern Art in Manhattan, most of it covering their 5th floor galleries, holding their "Collection 1880s-1940s". Now that I've been in computer graphics for a while, I feel like I get a bit more of an appreciation for what many of the artists were doing, particularly the abstract ones.

Piet Mondrian's works (like this, this, or this), which used to look like a bunch of rectangles, now seem like representations of spatial hierarchies that you would see in computer graphics, like quadtrees or bounding volume hierarchies. Joaquín Torres-García's work here is a bit like a three-dimensional version of this concept, and Irene Rice Pereira's work here is like the visualization of a more elaborate one.

I've always enjoyed Vasily Kandinsky's work, but now pieces like this, this, and this, forming complicated pictures out of simple elements, have me thinking of how real graphical scenes are composed for rendering.

Even Pablo Picasso, that I've always struggled with, has made more sense to me, and I could finally internalize an interpretation I read somewhere, that he was trying to capture a single scene or moving person from multiple perspectives or at multiple times.

I wonder what other art is out there for which I can find a new understanding.

Is episodic television roguelike?

I recently finished the first season of the old Perry Mason show from the 50's and 60s. I haven't watched it before - instead, I came to it after having watched the new, short-lived HBO show with the same title and almost the same characters. That gave me the reverse perspective from people who have watched these chronologically.

The HBO show benefits and suffers from a pattern of prestige remakes of old shows. In the old show you see defense lawyer Mason, his secretary Della Street, and his trusty private investigator Paul Drake, save a client from a murder charge by extreme means as of the first episode. In the new show, the first episode introduces us to Mason as a private investigator, Paul Drake as a police officer being, and Della Street as legal secretary to a lawyer who is Mason's mentor. The season ends with Mason transforming into a defense attorney, Street becoming his secretary, and Drake somewhat more associated with him. Mason's court nemesis from the old show, Hamilton Berger, is much more ambiguous here, and is a mere assistant DA. Lt. Arthur Tragg, the homicide detective and the one usually more closely involved in making a case against Mason's client, is not significant here. Since the show was canceled before it could be completely finished, I don't know how far they would go in reproducing the dynamics of the original show. Since it's supposed to be more closely based on the books than the original, it may never have been planned to reach that status quo at all.

The original show in light of all this is fascinating. It's a truly episodic show. There is no reference to earlier episodes, no characters develop in writing. Each episode stands on its own. They also all have a very similar pattern: we are presented with a non-deadly conflict, having to do with finances, emotion, or both - maybe someone is being blackmailed, maybe someone's heart is broken, maybe someone is being cheated out of an inheritance - and someone involved contacts Mason, and becomes his client. Then someone that was in conflict with the client dies, and Mason is diverted from corporate and real estate law to criminal defense. Mason himself often finds the body, and his law-stretching attempts to balance his duties as an officer of the court and his duties to his client bring upon him the ire of Lt. Tragg, who is not far behind. As more evidence is uncovered, Mason's client looks more and more guilty, until he comes up with an insight that lets him not only avert his client's conviction, but help Tragg and the district attorney, Berger, find the real culprit. Usually this involves the guilty party blurting out a confession in open court.

I watched a full season of this. In fact, many people, from the early history of television, and to this very day, watch shows like this, for many, many seasons. Shows in which the episodes are connected by the characters and the circumstances, but don't explicitly build one episode on the other.

It used to be suggested by the medium: in the time before VCRs, and with reruns and syndication depending on popularity to begin with, you simply couldn't depend on your viewers to have watched several shows in a row in order to follow any kind of serial narrative. You had to make every episode stand on its own, but you also had to make it reproduce the brand you were marketing. So repeating the same episode premise with some variation was a pretty reasonable design decision. Once you knew you had an audience, you could start playing with the medium more. You could end episodes or seasons with cliffhangers, and use those to encourage people to watch next time. You could change the status quo. That being said, you didn't have to.

So I watched 40 episodes (39 from the first season and one from the second). What did I get out of this? The writers did not present me with character growth. If you mixed the episodes up I wouldn't have been able to see the difference. But I changed. My frame of mind about the show changed. As I watched episode after episode, I got to see more and more of these static characters. Instead of seeing how Mason grew into his position, how he formed the relationships he has with his allies and antagonists, I saw Mason in this position, I saw these relationships, under many variations of the same challenges. I saw Mason and Tragg maintaining an almost erotic tension, so delighted to one-up each other, but with a certain moral commonality that meant that when Mason really managed to find out who the real culprit was, Tragg would cooperate with him, waiting in the wings to make an arrest once he'd pressured the guilty party, if he couldn't do it in court. I saw the legal procedures, and possibly understood them better - when it does make sense to object, when it doesn't. I could start seeing patterns of when it's clear that Mason or Burger were going out of bounds intentionally, as a rhetorical point, and when they've clearly been stymied by the other party, or by the behavior of a witness. If an episode did go in a very unusual direction - so far only one got all the way to a jury reading a verdict for one of Mason's clients - it could be used to examine the others in sharper relief.

I think that the process of a viewer of such an episodic TV show is like that of a player of a roguelike video game. A roguelike usually has the same general premise from playthrough to playthrough. However, the details are procedurally generated. In the more strict versions, you don't get to keep anything, so you can't build up a mechanical narrative of change as you play. What you do is learn, from session to session, about the laws of the world, of the patterns of action of the enemies, of the power-ups, of the dynamics of difficulty as you move farther and farther in, or travel farther and farther out. You understand existing things - those which don't change from playthrough to playthrough - better, due to how they interact, or how they relate to each other, through what does change each time.

Arcade games are similar. You play Galaga over and over. The game starts over each time, regardless of how well or how poorly you did in your last run. However, these games usually have a certain progression that is repeatable, so that you end up learning that, more perhaps than anything more inherent about your avatar in the game, or the enemies, or your power-ups. Often you can memorize some of the specific patterns enemies take in specific levels - in fact, depending on difficulty, it might be a requirement to advance.

So I think that (strict) roguelikes might be the best gaming exemplars of what I'm talking about. Might be time for me to try looking at this genre anew.

Trying something different for 2024

Greetings, faithful readers! It's been a while!

The purpose of this blog was to be an informal creative outlet. Sometimes it's worked out. Mostly I've been overthinking posts to the point of not publishing them at all. I have way too many drafts and half-baked ideas, and they're not getting to you. So I'm going to try something different this year.

I will try to set myself a schedule of posting once a week, starting today, but usually on Sunday nights. Instead of requiring myself to have a great piece of writing ready, I'll just treat this as a log, a journal, a commonplace book - somewhere to write down my thoughts with a bit of editing, then share them with the world.

In the past, I have been more prolific when I forced myself to spend October on some daily project. That is a bit much, especially with a day job, but once a week, just getting those thoughts out there, whether or not I have something fancy to share, should be doable.

So, what is up with me? For a while I was reading too many books at once, which was good in that I was making some progress, slowly, but bad in that I was having a hard time getting a clear sense of any individual book, to the point where I feel like I'd have to reread some of them to get anything meaningful out. Once I started committing myself to reading fewer and finishing them, I've felt a lot more accomplished.

I haven't read anything really folklore-related recently, hopefully I'll get back to that, but I've been trying to get at my other interests. For example, I recently finished reading Dungeons and Desktops - The History of Computer Role-Playing Games, 2nd Ed, by Matt Barton and Shane Stacks. Some of the games I've played, but a lot of them I didn't - either way, it was great to get a deep and broad sense of what this part of gaming has going for it. This is a field that was dying when the first edition came out, but has been getting more popular in time for the second, so it was interesting to get a slightly removed analysis of this revival.

I finished reading the second book in my Ervingiad, Encounters: Two Studies in the Sociology of Interaction. Unfortunately, it's another victim in my being spread too thin problem, so I'm now rereading it and summarizing it to myself. So far I've been finding it most illuminating - in particular, the book hinges on the distinction between analyzing certain activities that involve a set of people, and the structure of small groups, with obvious applications to, say, role-playing games.

Speaking of role-playing games, I haven't run a game myself in more than two years, although I have been playing Call of Cthulhu pretty consistently, with occasional dips into other systems. I hope to run games again this year, starting with attempting to do Apocalypse World one-shots. We'll see how that goes. Hopefully better than my one attempt at doing so for Sorcerer.

I've also been working on my French again. And in that context, I've gotten back to attempting to read René Daumal's Le Mont Analogue, which I got years ago. I now sit down with it, go to the dictionaries when needed, resort to Google Translate when all else fails, and climb through. I'm almost two chapters in. It's fascinating.

Aside from these I have a bunch of few-sentence book, film, and TV reviews from the past few years that currently exist as messages on Discord, and which I should collate some time. Incidentally, I've watched a few good movies this year, including Promising Young Woman and In the Mouth of Madness, and read pretty much all the literature recommended for Sorcerer. I might try to collect the reviews and my thoughts and share them in future posts.

Here's to more of me in 2024!

Layered mysteries

WARNING: The following post contains significant spoilers for Raymond Chandler’s novel The Big Sleep, for the 1973 film The Long Goodbye based on his novel on the same name (so probably for the novel itself), and the video game Castlevania: Symphony of the Night.

Perception-oriented graphics

I'm going to try and express an understanding that is forming in my brain as a convergence of several interests I've expressed through the years.

Recently I've mentioned some first impressions from Vision Science: From Photons to Phenomenology. I noted that it seems like its models of visual perception mirror the way a modern graphics pipeline is structured. Reading further in, that impression remains. It's not entirely surprising - I can't imagine the designers and engineers who built up the modern pipeline were ignorant of theories and practices of computer vision, which is one of the three disciplines covered by this book (the other two are psychology and neurophysiology), and, for example, the explanation for the importance of effects like diffuse shading in a computer graphics guide I have read recently, OpenGL SuperBible, mirror those in Vision Science.

Much earlier in the year, I mentioned that I'd gotten into folklore the previous year, and specifically Edward T. Hall's The Hidden Dimension, which discussed how people from different backgrounds perceive and make use of space differently when they interact with each other, as well as how different cultures and genres express spatial information visually.

Even before that, I reflected on a talk I gave years ago about virtual reality and various types of immersion. I expressed an idiosyncratic and limited version of rejecting the immersive fallacy, the notion that the more video games are able to reproduce the sensory impressions that a real experience would provide, the more players will enjoy and be taken in by the game world.

To this let me add something I've not discussed, mostly because I don't have as much personal experience with it yet: physically-based rendering (PBR for short), which is a set of techniques on the graphics side of video games, film, and other visual media, meant to put sensory reproduction to practice by trying to approach a close physical simulation of the interaction of light with various real materials. This encourages moving towards computationally expensive techniques such as ray tracing to generate the visuals, practically expensive techniques such as photogrammetry to extract light interaction information from real materials, and then storing this information and making use of that when rendering, which tends to increase the memory and processing requirements further.

If you happen to be thinking about the next game or digital movie you're going to create, I think it's worth it to take a step back and ask: what is it that rendering is supposed to do for a video game or a movie? Its main task to provide information to a person, a player or viewer, about a virtual world; or possibly to pass along a mood. Perspective 3D rendering of a view of an environment and objects within it is one way of doing this, but it is not necessarily the best. Even in modern games and realistic visualizations, other forms are used. For example, map applications usually provide orthographic projections rather than perspective projections, because that is a better way of providing regional information in graphical form. Even in realistic modern 3d video games, a lot of information is still provided through UI and menus. What are those? Stylistic, non-perspective descriptions of information, laid over the 3D view, instead of being placed within it. And yet, after a bit of a learning curve, they are a very effective way to present information, better than if a perspective rendered substitute were required.

Making use of these non-perspective, non-simulative representations was a recurring problem for me when working on virtual reality applications. Since control of the visual field is given over to the computer, it needs to provide something close to what your own visual field provides, in terms of reactivity and the organization of information, so entirely stylized overlays, like subtitles placed at a constant place in the visual image, which work pretty well when watching a movie on a stationary display, can be jarring and even lead to simulation sickness. This results in solutions such as placing them inside of artificial objects in the environment, which leads to challenges such as making sure that they are not obscured by other elements in the environment.

But it is possible to think about this differently. Instead of starting with the idea of having a three dimensional world built towards being presented through a perspective projection (with at most a parallel orthographic projection for an automap), it should be possible to create a more sophisticated logical framework connecting them, and decide how to turn this into visual data later.

Lateral thinking about how to render still exists in contemporary game design. Take shadows, for example. Shadows require a bit of work to render, over just ignoring them. But as Vision Science explains, shadows are an important tool for the visual system to extract at least two pieces of information from the environment: their detailed spatial structure, and how far away they are from the viewer. However, these two uses of shadows don't have to be rendered the same way, and sometimes it's best not to. If you've played any modern third-person 3D platformer, you would have noticed that yes, there's naturalistic shadowcasting that is consistent with the lighting conditions, but there's also usually a small shadow right under your character, regardless of the direction of light. That's because when light is coming from above, the vertical distance between the object and the shadow gives you very good information as to where the object is in 3D space, and it also tells you where the object will fall if it were dropped. That's essential when you want your in-game avatar to perform complicated jumps, a basic problem of the platformer genre.

Instead of thinking of shadows as a physical effect that must be simulated as realistically as possible to create an immersive scene, you can think of shadows as a way of conveying information to the player. That is a creative choice. An ideal version of what I would call "perception-oriented graphics" would let you make decisions like this for the overall display of the system - whether you want to display a perspective projection of the space or an orthographic overview - as well as for individual objects or phenomena - like the question of whether to use light-reactive or drop-down shadows. Maybe some day I will have the opportunity to work on something like this.

The graphics pipeline and human visual perception

I don't post about this a lot, but professionally I've been working as a graphics programmer for many years. Some time before I started this career, I was recommended a seminal work on human visual peception, Vision Science: Photons to Phenomenology, which presents a unified view of the problems of vision drawing from disciplines such as physical optics, cognitive psychology, and neurophysiology. I am just starting to read it now, and, as often happens, kicking myself for not having done so sooner.

One thing that stood out to me in the introductory chapter is how, according to models and experiments current to the time - this was published in 1999, so I am not sure how up to date this view is - the way visual data is analyzed is broken down in the brain in various ways. In particular, shape and position are analyzed in two different parts of the brain, as are color and shape in contrast with distance and dynamics. This is interesting because in computer graphics, often there is a separation between model data (shape) and world position (captured by a model transformation), and there is also a separation between perceived color data and depth data, the latter often also compared to past depth data to drive dynamical calculations.

I wonder if further reading will lead to other such correlations. And whether this information was used by the designers of modern graphics processing units and architectures when deciding how to structure the modern graphics pipeline to begin with.

Uncertainty in Games by Greg Costikyan - a review

Greg Costikyan's name came up often in Jon Peterson's The Elusive Shift. He was a prominent figure in the zine scene that formed around Dungeons & Dragons and the fledgling tabletop role-playing game community in the 1970s. A typical contribution of his to the discourse back then was Lord of the Dice, a satire on the role of randomness and rules in TTRPGs.

I was, therefore, very excited when @laurenmakegames on Twitter posted some books she was giving away, and I spotted Costikyan's name on one of them, Uncertainty in Games. I hadn't heard of this book before, but considering the name and the topic, which is dear to my heart - see my discussion of the Monty Hall problem, or the post where I formulated constructive alienation - asking for it was a no-brainer. Lauren was kind enough to send it to me, and it did make for great reading.

The book mostly focuses on video and board games, which he called "closed systems" in his early theoretical work. When tabletop role-playing games are mentioned, it's just Dungeons & Dragons, and only as an early example of potentially limitless games, and as an inspiration for massively multiplayer online games, like World of Warcraft. However, I think the framework he provides can be useful for TTRPGs, although that will have to wait for a future post.

His main argument, some caveats aside, is that the goal of games in culture is to be a safe space for confronting uncertainty, in a world where we usually attempt to reduce it as much as possible. What draws us to continue playing games is the existence of this uncertainty, and our ability to get better at addressing it. Once we accept this framework, a big question in the analysis and design of games is where their uncertainty comes from.

He goes on to analyze several games through their uncertainty, among them Super Mario Bros., The Curse of Monkey Island, Rock/Paper/Scissors, Chess, Poker, CityVille, and Civilization V. Using these games, he comes up with a list of sources of uncertainty, of which every game he cites makes use of one or two, sometimes more. I will try and formulate each as a question:

1. Performative uncertainty - can you use the controller to have Mario make that jump?
2. Solver's uncertainty - have you gathered enough witty retorts to defeat the sword master?
3. Player unpredictability - will this player put up scissors next after having done paper twice?
4. Randomness - will my phalanx defeat the enemy's chariot?
5. Analytic complexity - what is a good way to respond to the Queens' Gambit opening?
6. Hidden information - what hand did the player on my left draw?
7. Narrative anticipation - what is going to happen in the Governor's mansion?
8. Development anticipation - what new features are going to come in the next update?
9. Schedule uncertainty - can I return to the game in time to harvest my crops?
10. Uncertainty of perception - can I notice the hammer coming at me quickly enough to react?
11. Semiotic contingency - what meaning will the game have when I conclude this segment?

I think some of these are a bit of a stretch. "Narrative anticipation" seems more like a study of what kind of prior information the player has before some hidden information about the rest of the game is revealed, or maybe the results of resolving uncertainty from other sources, in the context of furthering a story. I'm also not sure that performative and perception uncertainty are really significantly separate. Semiotic contingency, which Costikyan gets from work by Thomas Malaby, doesn't really feature in any of the prior long-form analyses presented in this book, perhaps because of how few examples there are of games that actually make use of it.

The book ends with an insightful piece of advice: one way of creating a new game, or improving an existing one, is by focus on its sources of uncertainty: tuning the ones you have, adding or removing some, until the mix works for the experience or audience you're aiming for.

But I would like to jump back to an even more insightful comment made before the bulk of the book: that you should be careful using lessons from interface design in game design, and vice versa. The problem is that there are opposing goals at play: with interfaces to word processors, web browsers, spreadsheets, and other products, you want users to be certain of what happens, not uncertain. This constrains how well you can "gamify" productivity. It also goes in the opposite direction, in constraining how usable game interfaces can be made, without affecting the very uncertainty that you expect would draw people into your game and retain their interest.

An example from my experience is the existence of automaps in dungeon crawlers. Last year I spent a few months streaming playthroughs of the first two Eye of the Beholder games, first person dungeon crawlers based on the ruleset of AD&D 2nd Edition. I started by attempting to do so without automapping, as they were originally designed to be played, before getting extremely frustrated at a certain confusing point. I then restarted my gameplay using All-Seeing Eye, an extension which provides a few quality of life and outright game-editing capabilities, including automapping, which is all I used.

This did, in fact, make things easier, and I was able to beat both games. However, several of the puzzles in these games, and indeed, in the genre generally, hinge on the player's need to map by themselves, and on the uncertainty that comes from only being able to see what's right around the party of characters when making any individual decision. They become trivial to someone who can simply look at what's going on in the map and where the party is at all times. In retrospect, I'm certain that I've missed out on a lot of the experience, although on the other hand, perhaps I would have just given up due to this uncertainty and the difficulty involved in overcoming it, and never gotten any exposure to much of the content.

In total, I would recommend having a look at this short monograph, as uncertainty is a very interesting lens through which to analyze games. It's definitely staying on my shelf.

Game structure oracle

Text parser adventure games, usually called interactive fiction, are video games which present you with the state of the virtual world, and expect you to type in commands which change this state, usually actions of a character which you play. Zork (playable online here) was a famous series of completely text-based parser adventure games, where the state was also presented as text. The early Quest games from Sierra (King's Quest, Space Quest, Quest for Glory, etc), while providing information in both textual and graphic form, still required you to type commands in.

Eventually most of these series culminated in games with more graphical interfaces, resulting in the genre of point and click adventure games, but there is a small community of designers who still create fully textual parser games, often using the Inform language, which is ultimately based on the language used to design the old Zork games and other Infocom interactive fictions. One of the skills you had to develop as a seasoned text parser gamer was expressing what you wanted in a way the parser would understand: which nouns must be acted upon by which verbs, based on possibilities gleaned from the textual descriptions, or from knowledge of the system itself, such as its inventory and combat features.

As a thought experiment, suppose that instead of developing these skills yourself, you had a professional parser gamer working for you: someone who knew exactly how to navigate the game and understand its description, who might even be able to peek at the video game's code or assets directly, although they'd only do so to make sure they were answering your questions correctly, rather than to give you information you shouldn't have. This person would take your descriptions of what you wanted your character to do in the virtual world, and translate them into commands that the mundane parser would be able to use; they'd then describe the new state of the world to you, using the result provided by the parser game. This person is starting to sound a little bit like a gamemaster, in the role of judge or referee, except that they wouldn't be enforcing rules, so much as translating back and forth between you, the player, and the parser game, which does the actual enforcement.

This professional parser interpreter would be acting as an oracle for the text parser adventure game. An oracle in this sense is the term used in theoretical computer science for a kind of black box which can be asked questions to which it provides answers, in ways that the questioning algorithm's designer does not have to understand. In this case, the parser sends the description of the current state to the professional parser gamer, who will eventually come back with instructions the parser can understand and act upon.

When we look at role-playing game structures like the hexcrawl, or the node-based scenario, their systems, taken at face value, could be implemented in software. You could write an Inform program to provide the backing to a hexcrawl, once you've populated it; you could change it whenever you added or removed anything. And then your job as a GM while running the game could move towards being an oracle for the program, and something role-playing-like would occur between you and the player, even if you don't go beyond that to riffing or improvising at the edges. This is an extreme version of constructive alienation, an almost complete distillation of all creative thought into the process of designing and implementing the external structure and its procedures, and then supporting the player in engaging with it as a mere interpreter.

If you limit yourself to being a game structure oracle GM, there are several ways in which you can improve. First of all, the better programmed or designed your game structures are, the more variety the players will encounter as they engage with them, and the less you will be pressured to improvise. This will make you a better systems designer - or adapter, if you decide to use an existing adventure module in this way. In fact, it may well make it easier for you to create an adventure for someone else to use - you could honestly provide them with an interesting experience to run for their players, without forcing them to improvise to cover gaps you might've otherwise left.

Another thing you can get better at is translating player intent into rules usage. If you want to better support the implied character sheet game of the RPG your system runs on, this can be very beneficial. Alternatively, you might come into conflict with player knowledge of the CSG if you're trying to hide the details from the players to improve immersion. There's a balance that's worth striking.

Since the system is limited, and we're excluding the possibility of improvisation or ad-hoc rulings, another thing you might have to get used to doing is either diplomatically saying no, rationalizing why an unsupported action won't work, or preemptively guiding the players to consider choices that are supported by the system. The latter can be done by making sure to emphasize the systematically relevant features of the environment when you're describing its state. In extreme cases, you'd be making sure that even if the system itself effectively requires pixel hunting, the players aren't required to perform it.

As I said when I was discussing the CSG, this limit of GMing isn't in line with my natural inclinations. I am far likelier to improvise, to make rulings in the moment, to run with what the players give me directly. The purpose of this exercise is to challenge myself to improve in the aspects of GMing that do not come naturally to me; hopefully, this will lead me to be more well-rounded.

Character death in games

Yesterday, it finally happened. Having indulged in some constructive alienation to set up a framework for a dungeon combat challenge for the player characters, and furthermore, committing to a certain attitude by the enemies, I ran the game as it rolled, and one of the PCs died. Even in Dungeons & Dragons 5th Edition, it's possible to die in battle, and it happened. And it was a good death, for several reasons: it was a heroic and somewhat foolhardy press forward to engage the enemy without really waiting for backup, which fit well with the character; this somehow worked in previous iterations, but his luck ran out. The player also will have to take a break from gaming for a few months, so the out-of-game timing was good, as well. But still, it's sad for me when a character dies, and especially when that is connected to the player leaving the game, even if it's amicable.

I am reminded of a round of Betrayal at the House on the Hill I played at Who's Yer Con 2019. The game starts out with all the players cooperatively exploring a haunted house, which is generated using random tiles. Things go wrong, until one of the players moves beyond a point threshold, and becomes the betrayer. The game is paused while this player consults an entry in a book expressing the haunting, while the other players consult a corresponding explanation in the other book of how to defeat it. Play resumes, and it is now adversarial, until either the haunted player is defeated, or the other players are all killed or coopted, or whatever other end condition is achieved. In this particular instance of the game, I was the haunted one. And I slowly had to take out the other players. This was the last game of the night, so as I was taking people's characters out, they left to their hotel rooms, or to drive off. And it was really unpleasant for me to succeed at each juncture, and then to win the game. I felt like I was kicking people out of the game, rather than just challenging them inside its rules.

In a single-player video game, the situation is often very different. If you run into a challenge, and your character dies, you can just reload and try again. Even without saves or continues, even if you have to restart the game every time, you're ultimately able to confront the same challenge - or type of challenge, if it's procedurally generated - over and over again, until you tire of it, or until you overcome it. Death is a signal to you that you have failed, and an invitation to try again. In games made for the arcades, it is also a way to push you to spend more money. But I think games have moved more and more towards focusing on the specific challenge at hand. Instead of having to start games over, there are saves, or checkpoints; some games automatically restart you at the beginning of the latest challenge, allowing you to retry it over and over. Some games will adjust the difficulty of the challenge down, so that you are not stuck in one area due to missing out on a particular skill or capability. And of course, there are many games where death isn't really a possibility; it's just a matter of which of a variety of endings you get to when the game ends. I personally find a lot of the older games a bit frustrating these days, although certain retro and retro-style indie games have captured my interest.

So my experience with death in games leans towards the negative. I don't like getting characters killed, as a role-player, as a gamemaster, or as a board game player, and I find video game deaths frustrating when they require me to redo a lot of progress. But when thinking about gamemastering, game design, and theory, I'm trying to avoid just focusing on what I like. So let's discuss some parameters for lethality in role-playing games.

Many old school games were very lethal, or could be made to be. Original D&D did not provide characters with many hit points, or quick ways of replenishing them, monsters were deadly, as were traps and poisons, some of which would kill immediately. It was also very easy to build a new character - I recently played an OD&D game, and even with checking up on whatever houserules were in place, it took me about half an hour the first time, and would probably not take me more than ten minutes if I wanted to do so again with the same table. Another important aspect of early versions of D&D is that it expected adventures which did not really dig into character backgrounds and motivations. You crawled a dungeon with other players to look for treasure. The constant threat of death motivated you to be careful as you crawled, although combat did often happen, as did falling into pits. If your character survived, it might develop a larger narrative, especially if it ended up taking its funds to settle outside, but it could easily perish, and you would write up a short memorial and start again from scratch.

As I noted above, meanwhile, D&D 5E makes it very hard to die, or rather, makes it very easy for a PC to survive brushes with death. Your character gets to revive some of your hit points with an hour's rest, or all of your hit points on a night's rest. Once taken to zero hit points, a character needs to roll 10 or lower three times with a d20 (or two if one of the rolls was a 1) before rolling three 11s or above to die permanently. Moreover, a critical success (a 20) has the character at 1 hit point and ready to get back into the fray - or flee, likely the more prudent option, albeit made difficult by the system's punishing combat movement system. Correspondingly, character creation is a much more arduous task than in the original edition. It is usually recommended that the party and the DM take up the equivalent of a whole session to build characters together, to make sure that they mesh well and that their backgrounds can be tied into the plot properly. The adventures are expected to be long-term affairs, with meaningful participation of the characters at each step, so a character's death can really mess with the process. But other things can happen when you play: allies and enemies can win or fail, you can alienate former allies, befriend former enemies. Your character's choices can have a lot to do with how that changes.

I think this leads to a bigger discussion of what stakes you are playing for. The stakes can be the life of your character. But if the character is easy to generate and is expected to be easily killed, what are you losing when it dies? The string of successes you've had with it against a hostile world? Definitely not time out of the game. Meanwhile, if a character is difficult to create and adapt to the world at hand, you're not only losing all that starting investment, you are also probably losing a significant amount of participation with the game as you are taken out of it to restart this process. And if the game involved a lot of social relations with other parties to the game, both player and non-player characters, then all of that is lost, too. Meanwhile, you can lose some of these connections due to poor judgment or failures without killing the character. So your experience of the game with the other participants continues, even though you have suffered setbacks, setbacks that can be significant for you, if you have become invested in the world and the people in it. It can be a meaningful experience even if it is not lethal for your character individually.

That being said, if there is combat in the game, there is no greater proof of how important it is to do it well than the death of a party member, with all that entails. If there is a dungeon, death by trap is the best way to show that it is vital to tread carefully. If there is a despotic society you must navigate in, there is no better proof that you have to watch your actions very carefully than a summary execution.

And on that positive note, rest in peace, 2020.

Plane Defensive - my old indie game prototype

After finishing my PhD in physics in 2015, I decided to pivot towards video games. I went to some talks and workshops at Tech Valley Game Space in Troy, New York, near Albany, gathered up some tools, and started coming up with ideas, vetting them, and turning them into something playable.

The main product of this period was a game called Plane Defensive. The latest (and probably final) version can be played for free here. This was the end of a long line of prototypes that I playtested at TVGS's Interactive Showcase, which allowed members of the Troy community to try out locally-developed game. 

The premise was that the player would be controlling some kind of defensive platform, whose purpose was to deflect invaders from another dimension. To begin with, the platform would live in a two-dimensional plane and deflect invaders that came into it from the third dimension; I was thinking that some day I'd try to create a version where the platform would travel around our own space and deflect higher-dimensional foes.

Working on versions of this game taught me a lot about the differences in what you can expect from people familiar with video games, as opposed to people coming to play one for the first time. Many things that seemed obvious to me required a bit of education, like clicking and dragging objects around. I also saw first-hand how adapting a game to different platforms can be a challenge: for example, tying text to size in pixels is not great when you're developing on a low resolution laptop for high resolution test computers.

In terms of content, I went through a few separate conceptions of how to express that there is a way for the two-dimensional platform to peek into the third dimension. At first I mixed different cameras, but eventually I decided that the most convincing detector would simply point towards the projection of the high-dimensional being onto the play space - given enough directional detectors, the invaders can be triangulated and anticipated. I also played around with using stereo sounds for some of the challenges. The visuals were very "programmer art", and the sounds were simple generated effects.

You can see a full play-through of pretty much all of the versions, along with a more elaborate discussion of my process, in this video, part of a series called Devs Play, hosted by TVGS for a span of time. Enjoy!