Posted by: Em | SEP-05-2019
Note: This is a transcript of my talk for Babycastles and Parsons School of Design's GAME ENGINES BEYOND GAMES symposium on September 5th, 2020. To view the presentation and contextualizing links, please also open this page.
Hi! I'm happy to be speaking at this symposium because my research has gotten more interested in game engines and tools. Thanks Darshana for inviting me. I'd also like to acknowledge some other friends, colleagues and internet people who played a role in this presentation:
Don Miguel, who released the English crack of RPGMaker 20 years ago, Adam LeDoux, the developer of Bitsy, Claire Morwood who wrote an early tutorial for Bitsy, Llaura who came up with the concept of flatgames, Eli and Blake Andrews who were my co-curators for the Pixels X Paper exhibition, Kris de Decker's Low Tech blog, my partner Stephen for having an RPGMaker forum teen-hood I could pick his brain about, everyone who makes Bitsy games and the culture around it for embodying the best of what I'm about to describe, and also my friend candle for their passion for tools (including Domino, which I used to make this presentation)
In general, my research finds ways to analyze videogames through art historical frameworks, as a medium for art, which crosses over with game criticism and game development. In this talk, I'll be describing what I call mass art engines and tools for game-making, some interesting qualities they have, and examples of how these qualities work in the Bitsy game engine and what some outcomes are.
A description of medium and process is often included in the wall label or discussion of an art work, but this information can be hidden, sometimes deliberately in videogames. With a few exceptions, we talk about videogames as if they are made up of the same “stuff.” This is partly because the professionalization of the industry has tried to make process invisible, and present the videogame as a slick, black-boxed toy.
When they're invisible, professional tools become norms that are used to define the aesthetics of videogames. With increased graphical and technical complexity, game engines became guarded proprietary technology. Occasionally, studios would offer limited versions to make mods or extra levels, but these were usually subservient to the existing game. If there was enough community interest and work to make a completely different way of playing, it was difficult to distribute outside of the existing ecosystem.
When new tools for game-making become accessible outside of this, what people make can be quite different from professional game development. Elements of the process are often more visible. If you can name the engine a game uses, that can be an evaluation of its quality. Describing something as a Flash game, an RPGMaker game, a Unity horror game, is not always a complement and never an unqualified one. At best the implication is that the game almost conceals its process or makes up for it, never fully successful in its own right. This differs from how tools and process are understood in an art historical perspective. These details are vital elements of provenance and can be a source of important details about the artist or how to preserve the artwork.
“Indie games” only became possible through there being more tools and opportunities to make and distribute videogames; people had always been doing their own hobbyist or amateur programming. The emergence of “indie” as a classification was not something outside of corporate centralization, but working alongside it.
This connects to language like “democratization” and “supporting the indie community” tools promote themselves with, or how storefronts discuss independent titles. How democratic are the things these tools and platforms actually do? Funding a few projects selected to be featured on their closed or rent-seeking platform? Becoming an industry standard or ubiquitous enough that they are what everyone is ushered towards? These are capitalist-oriented views of “community” which indicate captive users to extract value from, in the form of rents, royalties, content, or demographic info, rather than people choosing to work together, for collective benefit.
In that context, something successfully becoming a mass art tool is a threat, and is met with concerns about quality or dismissed as “shovelware” and “not real games.” Even self-consciously retro indies often do this sort of policing but use different ideas of quality and legitimacy than the mainstream industry.
We become entrenched in a capitalist scarcity mindset when we get protective over who really makes games, what games really look like, what tools make real games. From that perspective, the best we can hope for is that the “right” games, whatever that means, get the publisher deals and privileged placement on storefronts. I'd rather see it as a huge opportunity that there are so many games and so many ways of making them. We have to rise to meet the ways people are relating to videogames and using game tools to stay relevant.
To call tools that embody this attitude “accessible” or “easy” or “indie” homogenizes them. Instead I call them “mass art” tools. I use “mass art” not to describe work that is made and distributed at scale, or popular (or well-advertised), but in the sense that Susan Sontag uses it. She observed that in the 1970s, photography “has become almost as widely practised an amusement as sex and dancing—which means that, like every mass art form, photography is not practiced by most people as an art.”
Mass game making would mean many people using these tools aren't using them as a game developer or member of the game industry, even aspirationally. It may seem utopian given the squeeze on arts funding in general and the power of for-profit platforms in gaming but I think we have to consider this type of production worthy and exciting in itself, not as a pool to pick out sleeper hits or game design students from. I always work envisioning an idea of a culture where this work is sustainable, uplifted, and has a critical dialogue around it.
Here are some important qualities of mass art tools:
A distinct starting point. This is what we currently focus on when deciding if something is accessible or not, beyond if it's publicly distributed or free. Is the interface that opens legible and is it clear what the first few things you should do are? This plays a role in the success of applications which provide icons or drag and drop menus and allow you to place elements visually. It's a good first step but not the most important, nor does it ensure it is sustainable in the long run.
What can we learn from Piracy? Piracy is resilient, creative and accessible, usually much more so than the gaming companies that try to shut it down. It is a context that has enabled the preservation of games history and the development of new ways to play that the industry neglects.
Piracy is also linked to translation patching. Don Miguel’s English release of the RPGMaker distributed a Japanese-only product around the world. The series is now released officially in multiple languages, but the idiosyncratic and illicitly distributed English crack did the most to shape the international RPGMaker community. Originating in an act of piracy contributed to its magpie nature, creating games with ripped sprites and licensed music. Piracy is where we can see what barriers to distribution, preservation and usability people are struggling with, and build for them instead.
Do people really own the tool and what it puts out? Forms of online-only or rent-based access don't only monitor and control users’ access and more aggressively extract value, they’re also environmentally inefficient compared to downloading or installing a piece of software that works offline on your computer, and saves your work as a local file.
Streaming platforms also have a really poor memory. Things appear and disappear from them in increasingly opaque ways. If there's a platform that mediates your access to a game or file, unless you have an offline version or way to simulate that platform, you can't say it's preserved.
Always-online and auto-updating apps and social media sites leaves users behind unless they can afford to constantly upgrade. In a practical sense we need to start refurbishing and extending the life of our existing tech while using less resources and energy but also if your project doesn't work on a several years old laptop, you are excluding a lot of people from your audience right off the bat.
File size is also important. Mainstream games can now be in the tens or hundreds of gigabytes. This growth is unsustainable, and for diminishing returns. The files are annoyingly huge to download with a decent internet connection, but they’re also super inaccessible. Capless, fast internet is far from the norm around the world.
Similarly, ease of use and recognition of the files it puts out matters. Can you make distributable .exe file or something that has to be zipped up or played through a specific interface? The more steps it takes for a computer to open and run, the more places something can go wrong or daunt a novice user.
Formats that enable community upkeep are also valuable for the long-term life of a project. The output of many creativity tools are hosted or usable only as long as the service is active or profitable, and it means tons of work is locked away or lost. Rather than being tied to a specific product life cycle, files that can be stored in homepages or community databases have a much better chance of sticking around.
Finally, there has to be a place for everyone to share. Philome.la was an enormous part of why Twine took off, just as much as its HTML based format and visual interface. Itch.io has been a general purpose place where many games can be uploaded and both downloaded and run in-browser. These platforms should be as open as possible, in terms of what they take.
Bitsy is a game engine that does a lot of these things, and interests me a lot. It is a personal project by Adam LeDoux, though now hundreds of people use it. Bitsy started out as a way to work on games with a notes app while on the bus home from work. There's now an online javascript-based interface which outputs text files, which work the same way as this early text-only development, and HTML files where the game is interpreted and run in-browser.
Bitsy references older formats and the qualities of digital media itself. The pixels in each 8x8 tile are defined as binary 0s and 1s, and items you can interact with are a different color than static tiles, giving each 8x8 tile room a three color palette. This may seem restrictive or destined to always “look like Bitsy” from a professionalized game design perspective.
In practice, however, there are over 2000 Bitsy games posted to Itch.io. This has led to a community around Bitsy games, which creates a context for appreciating the Bitsy-ness of their production, and the particulars of working with the tool.
This has led to a culture that is self-directed, which shares and pools resources and builds on others' work, and is not doing this in the context of a proprietary modding or user generated content context.
Bitsy provides an intuitive interface that produces lightweight and legible files that have existing distribution channels, under a creative commons licence so making things like mods and hacks are both technologically straightforward and explicitly condoned. This means there are straightforward ways to combine or troubleshoot Bitsy games from the text files. Additionally, when you open the editor there's an avatar, a room, a cup of tea item and a cat already placed so you have a small demo that conveys how you move around and how you interact with objects.
The only potential problem is that Bitsy is still mostly online in terms of how people use it and access the games. A stand-alone editor and way to package Bitsy games would be ideal, but there are community workarounds.
There's a lot of interesting results of these open and low tech qualities in a game engine. These are some examples:
Bitsy collections have been included in several game festivals and exhibitions, with custom hardware like the Bitsy Boutique, or with tools that allow multiple games to be presented in the same Bitsy page. Because Bitsy games are text or html files, they're easy for existing archival organizations like the British Library to incorporate into their interactive fiction collections.
Transparent game data means writing directly to the game data or creating tools that automate these hacks is a common way to add capabilities not included in the editor. Making and sharing hacks is a common way Bitsy developers help each other and work together on projects. Borksy is an example of a tool which automates adding several different hacks to any project.
This leads to the formal development of the engine building on accessibility rather than complexity. Bitsy is available in 17 languages, but has retained its original look and workflow, and hasn't expanded features in a way that makes user developed hacks redundant. This prioritizes changes that allow more people to use Bitsy while still maintaining its legible interface. It also makes the development of the engine more distributed than hierarchical.
And finally, there's a lot of shitposting in Bitsy. Rather than seeing this as spam, insincere, or low quality work, games like this are evidence an engine is being used casually and for communication. The structure and aesthetics of Bitsy also informed projects by and for the communities that use it, like the video sharing space Zone.
To conclude, I hope this provided some insight into game tools' mass potential in addition to what they let tech-savvy game designers and artists do. Making tools that have this potential means fighting pressure towards professionalization, polish and scale that cause tools like Unity become standards. With Unity's recent IPO, who knows what the future will look like in terms of accessibility and conservation of work made with it?
The games industry cares about videogames being called art, and I think artists and independent practitioners do too. It's still hard and awkward to talk about videogames as art, because we've inherited so many anti-art assumptions of the tech industry. Often discussions revolve around a particular idea of how to make videogames, or what the proper uses of the medium are at the time.
It may involve work that doesn't seem like videogames, or worse, seem like bad games, but considering this work can help shift the discussion around games towards one that values process and variety. It has already been said many times, but worries about accessible tools and storefronts leading to “too many games” are overblown. It should be equally as ridiculous as saying there is “too much art” because so many people can pick up a digital camera or a pencil and paper.