"While debugging is considered to be one of the more odious aspects of programming, I felt that under the right circumstances, it could actually be exhilarating," says AP Thompson, designer of Beglitched.
Game Design Deep Dive is an ongoing Gamasutra series with the goal of shedding light on specific design features or mechanics within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all.
Check out earlier installments, including the action-based RPG battles in Undertale, using a real human skull for the audio of Inside, and the realistic chat system of Mr. Robot:1.51exfiltrati0n.
Hi, I’m AP Thomson and I worked as the lead designer and programmer on Beglitched alongside my collaborator Jenny Jiao Hsia. In addition to design and programming, I also wrote the dialogue/text and composed the music for Beglitched.
My background is primarily in Computer Science and, despite that, I still like computers and programming a lot. Other games I’ve worked on include the 2015 IGF nominee Stellar Smooch (another collaboration with Jenny Jiao Hsia), Stair: Slide the Blocks to Ascend (a collaboration with QWOP creator Bennett Foddy), and most recently Multibowl (also a collaboration with Bennett Foddy).
As a designer and programmer, I’m most interested in games that take advantage of the unique properties of computers, so my designs tend to emphasize single-player experiences with healthy doses of hidden information and procedural generation. These design preferences should be fairly visible throughout Beglitched.
Beglitched is a game about interacting with an unfamiliar computer that once belonged to a legendary hacker. While the surface of the game seems very bright and friendly, it isn’t long before the player is required to fend off rival hackers in one-on-one computer combat.
These hacker battles take place on a “Battle Grid” that strongly resembles a traditional match-3 game such as Bejeweled or Candy Crush Saga. Unlike a traditional match-3, however, an enemy hacker is hiding somewhere on the grid and the player must use the tiles on the grid to first discover the location of the enemy hacker and then disconnect them from the network.
As the game continues these battles become more complex. Enemies that initially remained stationary begin moving around the grid, new tiles are introduced that perform special functions, and enemies start imposing additional rules of engagement (such as blocking certain tiles from spawning in your grid).
Ultimately, the player has to approach the battles not as simple match-3 puzzles, but as tactical duels that require an understanding of the bizarre systems at play in the game.
The battle grid in Beglitched
The seed of inspiration for Beglitched’s battle grid mechanic came from a desire to make the act of debugging a computer program fun and accessible. While debugging is traditionally considered to be one of the more odious aspects of programming, I felt that under the right circumstances (i.e. a good understanding of the system and appropriate tools to probe it for information), it could actually be exhilarating and very satisfying. The process I enjoyed involved carefully gathering information from a faulty system to narrow down and ultimately isolate the source of the problem. This process makes me feel like a master detective and it is an experience I wanted to share with everyone.
One of the constraints I placed on this idea early on was that I couldn’t just hand-design a bunch of deduction puzzles. To properly simulate debugging, I needed to make an internally consistent system so that the player could feel like their knowledge could be used to solve any problem within the system, not just problems that were artificially designed. This constraint meant that all of my prototypes along this idea would involve procedural generation at some level.
My first attempt (a couple years before Beglitched) to prototype this idea was to take the sleuth metaphor seriously and create a procedurally generated detective game. This text-only prototype would procedurally generate a city and a population of citizens who each had a procedurally generated schedule. Then, the system would generate a “crime” where one of the citizens would deviate from their schedule and commit a crime. The player was then tasked with interviewing potential witnesses (who would all possess information based on whether their schedules actually placed them at the scene of the crime) to determine which of the citizens was the perpetrator.
Thompson's detective prototype.
In theory, this prototype succeeded in simulating the process of debugging, but in practice it was actually more tedious and inaccessible than debugging an actual computer program as the player needed to record and cross-reference massive amounts of information, most of it erroneous. With this prototype unsuccessful, I tabled the idea for a couple years.
The next time I returned to the debugging idea was for the 29th Ludum Dare competition. The theme of the competition was “Beneath the Surface”. Intent on avoiding surface-level interpretations (pun totally intended) of the theme, I thought of the “Deepweb”, a section of the Internet invisible to search engines that is sometimes associated with criminal activity. The idea of pursuing criminals across a computer network immediately re-kindled my debugging-as-mechanic aspirations, but this time I resolved to make accessibility a priority. My strategy was to strongly limit the density of the information available to the player. Where my text-based detective game included reams of information about schedules, relationships, propensity of certain NPCs to lie, etc. my new prototype (called Deepweb) presented information as a single number—the distance between the player and the hidden enemy. This idea of low-density information is present in many popular deduction games—including Minesweeper and the non-digital Scotland Yard—and worked well for Deepweb.
The original version of Deepweb.
Satisfied with the 48-hour prototype for Deepweb, I spent the next couple months attempting to expand it into something much larger. While many of the ideas I attempted during this period ultimately found their way into Beglitched in some form, I was running into a wall with the core of the game. No matter what variations I placed on the basic idea of navigating a network to gather clues about a hidden enemy, the limitations on what the player could do (or more specifically, the environment the player was moving through), led to fairly narrow and constrained play that soon became repetitive. Feeling discouraged by these failures, I decided to table Deepweb for a while and work on some fresh prototypes.
In parallel to designing Deepweb, I had also prototyped several match-3 style games. These prototypes were intended to be bizarre subversions of the match-3 formula. One involved using at match-3 grid to spawn balloons on a bird that floated upward and needed to avoid obstacles. Another involved using a twin-stick gamepad to control two physical arms of a bear that played a match-3 game to spawn honeycombs and bees that would then interact with the bear arms. The basic premise behind these games was that performing actions in the match-3 grid would have an effect on the game world external to the grid.
Thompson's bird-balloon match 3.
And his bear-arm prototype.
With the ideas of Deepweb and these match-3 prototypes floating around in my head at the same time, it was inevitable that I would attempt to put two and two together. After struggling with Deepweb for several months, I decided to try to make a match-3 prototype that was also a deduction game with low-density information. The basic ideas of Deepweb were still present—an enemy was hidden somewhere on the grid, you as the player needed to find and eliminate them—but the addition of a match-3 grid allowed the player a lot more flexibility in terms of strategy and also allowed for greater variety of situations that could occur. For instance, while an enemy in Deepweb was guaranteed to be hiding in a computer, an enemy in this new prototype could potentially be hiding under a variety of tiles that also served as resources. The match-3 grid also had the advantage of self-balancing the resources (clues, energy, etc.) on the grid since having too many of one tile would often result in that tile matching and disappearing.
Now it may seem like this is the point in which the Beglitched battle grid design would emerge from these ideas fully formed, but in truth my first match-3-combined-with-deduction prototypes where effectively unplayable. Unlike my struggles with Deepweb, however, I could sense that there was a worthwhile design contained somewhere in this mess and I spent the next few weeks iterating constantly on this idea. It was during this iteration period that core aspects of Beglitched such as “cycles”, “energy”, upgradeable bombs, and explosive chain reactions finally emerged.
An early prototype of Beglitched.
Once the battle grid existed in a form I was satisfied with, I needed to come up with a way to connect and contextualize battles in the larger world of the game. That proved to be pretty darn easy since I already had a prototype that involved navigating a computerized space and avoiding (or seeking out) enemies. Originally intended to be the core of the game, Deepweb could now more effectively serve as the “overland” that connected and provided context to the battles. Since much of the deduction mechanics now existed in the battle grid, I could remove most of the constraints that were holding Deepweb hostage. For instance, I no longer had to hide the enemies on the Deepweb, which meant that computer nodes on the network could provide information other than enemy proximity, which ultimately meant I could place many more enemies on the network than I had before. With a revamped Deepweb serving as the bridge between battles on the battle grid, Beglitched as it exists today finally began to take shape.
Beglitched's overland, inspired by Deepweb.
I’m ultimately pleased with the battle grid portion of Beglitched. While it maybe doesn’t perfectly simulate the exhilaration of debugging that served as its initial inspiration, it works well as a battle system for a computer world that is familiar and alien, inviting and hostile, cute but with fangs.
It’s also given me a lot of experience with building match-3 systems and provided me with a wealth of inspiration for games that I’m both currently working on and plan to work on in the future.
You May Also Like
