Let's Play: Ancient Greek Punishment: Bitsy Demake

Initial thoughts

Because I'm on vacation more or less and that means roughly full-time parent life, which is nice, I need something relatively small and straightforward to poke at in the evenings. The Twine was pretty satisfying design-wise and only required a day to implement, so it makes sense to me to turn to the "other" extremely simple and clean game engine that gets used by new creators especially, Bitsy.

I've used Bitsy exactly one time before to make b r 1 and really enjoyed the experience and the challenges associated with working with the limitations of 2D, specific tile-sets, particular avatar representations, and so forth. Bitsy is hyper limited in a way that I think could be quite rewarding to work with on these punishment games, especially its extreme lack of interactivity.

Bitsy thoughts

So if the primary question is around interactivity and what I can represent for a player to engage with then

• Spatial navigation (technically the space is implied by the tiles etc., but it's the usual way of using Bitsy so I roughly assume I'll stick with this concept in order to stay true to the form). You move an avatar around in the space of a "room" and it can collide with "walls".
• Triggers. If I recall correctly Bitsy has the ability to define tiles that take you to other rooms on overlap, allowing you to do all kinds of stuff potentially. Most obviously travel to a new location, but also to portray a change in state.
• Items. You can "pick things up" in Bitsy. That is, you can overlap them, they disappear, and you can display a message associated with this event.
• NPCS. You can bump into something (wall-like) and it displays a message (over and over).
• Plugins. Alonside those basics there, I became aware through a talk by Enric Llagostera that there are tons of extensions of Bitsy that allow all sorts of other potential agencies/affordances. I'm currently unsure that I want to go down that path just because I feel like it might detract a bit from the pure contraint of a demake into Bitsy. Will think about it though, pending how frustrating the project is.

Along with that I suspect I'll need/want to implement each level as a separate Bitsy game because I think the limitations especially around the avatar and just management might get out of hand. Actually the avatar's probably not such a big deal, but I guess I just worry that if there's a shit-ton of rooms it might get ugly? Maybe we'll just see on that front.

Aesthetics

How is this going to look aesthetically? I need a consistent style. Minimalist I assume? I don't think I have it in my to try to make something as beautiful as several Bitsy games I've seen have been? We'll see.

Specific levels

So with that in mind, what are my initial thoughts for how to represent this stuff?

Sisyphus

• One thought is a bit of a joke-oriented idea, which is that you see the boulder in the first screen and "pick it up", then carry it up a representation of a hill, and then on reach the top trigger a message telling you it has rolled back down to the bottom, and then you have to go back down? There might be some weird state stuff involved even in something as simple as this, but it could be a funny representation (I'll need to use the idea of a pickup at least once, I think, anyway - though there are other opportunities).
• The other idea is more of a recreation of a frame-by-frame animation where each step up the hill triggers a new room with the boulder element moved further up. Sounds like hell in terms of just redrawing the same thing over and over, to which end it may be better to go with the other option?

Tantalus

• Here the 'obvious' approach is to have an apple and water element(s) and then to make them inaccessible specifically by placing a wall, or alternatively to trigger a second room when you "reach" for them that places them beyond your ability to grasp. Will just have to play around a bit with representations and see what sticks? I think this basic idea is pretty obvious though?
• A related idea might be that you do pick them up but then trigger back to a level where they're back where they were? This doesn't make as much sense though given that we don't want even an underlying representation of a successful pickup?

Prometheus

• Should make sense in terms of representing a little dude trapped on a rock who can't move, but then how does the eagle come into play? If you allow movement with triggers (each of which always leads to a room where you haven't moved?) then each subsequent room could animate the eagle closer, and you just end up using a sequence of rooms as a form of animation?
• Alternately the eagle could be an NPC (it's the only real opportunity for this in the game so maybe that's a good option?). The problem with that being there's no way to track state at all, so I would have to be okay with the idea that I don't represent the cyclical nature of the punishment. It would be more satisfying to literally "chain down" the player and have no movement, but because Bitsy is movement-oriented, that then ties my hands (ha ha) in terms of actually making anything happen. So.

Danaids

• As always, the most complex one in terms of step, but should make sense to be able to pick up the water and carry it to the bath? The bath as an NPC that registers your contribution? Then use a trigger (or two?) that resets back to the initial screen?

Zeno

• This one scares me a little bit because I doubt I'm going to be able to come up with any particularly deep representation of the idea of a kind of fractal space? As simple as just allowing them to get half-way there? Or a sequence of rooms in which the flag gets "further away"? I'm really unsure of how to make this one work actually, maybe it's the hardest one?

Hi there, just reporting in after my initial foray into actually doing stuff in Bitsy. Specifically I wanted to clarify that I understood the relationships between items, sprites, the avatar, and exits.

Avatar, sprites, items, oh my :(

It turns out to be more frustrating than expected, especially for someone who wants to make something cyclical. As per my previous commit message

• Items can be placed multiply but if you pick one up it's gone for good (across rooms during a playing), so to they're very temporary but have an irritating permanence when they're gone, which makes them a bit useless for anything you want to happen more than once
• Sprites can only exist in one place (across rooms during a playing), so they're "stable" and can be returned to, but can't move or vanish. And as far as I can tell no trickery available in terms of triggering a room shift on examining/interacting with a sprite.

The result of this is that I suspect I'm going to have to think significantly differently about how to represent these myths. In particular, my cute idea of "picking up" the boulder as an item and transporting it to the top isn't going to work, because when you return to the bottom the item will be gone.

In fact at least initially I have felt quite defeated by it. If the boulder is an item, it vanishes and can't be repeated. If the boulder is a sprite it can't move and I'd be limited to something horrendous like an "animation" room by room of "pushing" it up the hill. Which I guess is fine, but just feels like you're fighting what Bitsy is good at. There's something to that (consider that moth game I played that did some cool animation effects), but I'm wanting to mostly explore how to "express" the myths through this engine, not bend it totally to my will.

Be the boulder you want to see in the world?

In my despair I did think that perhaps an approach to Sisyphus is to make the avatar the boulder. This is quite satisfying in that it collapses the myth in a way that seems videogame-y. An alternative would be to try to represent Sisyphus+Boulder in a single tile, but that would be impossible given the tile size. And one reading of boulder-as-avatar is that then the player is very specifically Sisyphus, "pushing" the boulder uphill with the keys?

This would allow the requisite looping behaviour because you'd go to the top and hit a hidden exit that drops you back at the bottom. This would require you to know that it had happened though, so there would need to be some distinguishing features that differentiate it all. Probably want to just represent the whole myth on a single screen?

Separate Bitsies?

This would also more or less require each myth to be a separate Bitsy rather than doing them all within a single one which is a shame. Interesting that the nature of the engine, though, perhaps kills the idea of an avatar performing multiple different kinds of tasks? I guess the set of verbs and objects just can't encompass it. And perhaps most of all because movement is the most powerful (almost only) agency in a Bitsy game and so you do need to hold it back for specific actions and not just wandering around.

One nice thing about needing to use separate Bitsies per myth is that it would allow a return to the colour schemes of the different levels, so that would be something.

Menu?

How would I link them all together I wonder? Just an HTML page with links? Seems a shame, but if that's how it is then that's how it is.

Extensions?

Looking through the list of bitsy extensions at https://github.com/seleb/bitsy-hacks I see some possibilities to overcome certain issues. Notably

• I see you can execute JS from a dialog which could suffice for creating a Bitsy that is the menu linking to the other Bitsies
• More extreme I see you can do things like have a sprite follow an avatar which could provide a model for Sisyphus pushing a boulder
• I also see you can change the avatar in different rooms, which would potentially put me back in position to be able to produce all the game in one Bitsy (because you can have distinct palettes per room, so I wouldn't be losing out on that).

The question with all of these is whether using hacks like this devalues the overall experiment in using what Bitsy provides in order to be able to produce the myths. The menu I think I can get away with, but is having a singular avatar just a part of Bitsy I shouldn't be opting out of?

This is a bit of a challenging question, pretty philosophical.

I think my feelings here are that I should be using default Bitsy as much as possible in order to treat it as the language/material of expression for the project. The more I tweak it the less case I suppose I have for talking about (and experiencing) the limitations set by such an approach.

As such I imagine allowing myself to use JS dialog in order to create a menu more in-keeping with the experience (and not intruding into the myths themselves) but otherwise staying vanilla.

Another one of those cases where I simply haven't written these prior to actually making the project, which kind of makes most of this redundant in terms of "research", but just allows me to indicate, as per usual, what I think is interesting in terms of what's going on here.

Translation

Clearly this is part of the ongoing interest in translating between forms, in this case from a standard "retro" style (or indeed from the punishment myths themselves) into the Bitsy engine specifically, including all its many limitations - thus allowing for an exploration of how those limitations (and affordances) can be used to express the specific ideas required for the myths.

Repetition with variation

Similarly clearly, this is part of the very specific project of translating and reimagining a single game design concept (the punishments), being the tenth variation in the ancient greek punishment series. It's really starting to build up a pretty diverse set of approaches to the basic question of how one designs a game especially in conversation with the materials, including engines and genres (as well as, in other cases, how one varies some specific part of the design to dramatic effect). Bitsy is especially interesting, as above, because it's just so limited - a lot of fighting with the engine to get something resembling what I want.

(Note: throughout this text, I’ll be linking to process materials generated as part of the project in its code repository. I'll also cite specific "commits" (moments of active development) by their hash number where relevant. This approach to process documentation is part of the Games as Research project.)

Let's Play: Ancient Greek Punishment: Bitsy Demake is the tenth edition in the "Ancient Greek Punishment" series I've been working on since 2011. As a kind of companion piece to the Twine version I made previously, I decided to make the same five punishment myths in the "other" highly popular and accessible game engine, Bitsy. By way of reminder (and links), those punishments are: Sisyphus (pushing a boulder up a hill), Tantalus (reaching for unattainable food and drink), Prometheus (chained to a rock with his liver being pecked out), Danaids (eternally trying to fill a leaking bath/basin), and Zeno (doomed to run a race that cannot be finished).

Bitsy is a web-based tool for making simple 2D games that allow the player to move a character around and between a series of "rooms" (which could represent indoor or outdoor spaces or anything else) and to interact with "items" (by picking them up) and "sprites" (by bumping into them). It's not too much more complicated than that, which makes it a lovely tool for quickly building clear and direct exploration experiences, environmental storytelling, and related forms of play.

In the case of the punishment games, I was most interested in how such a basic set of tools would be able to accommodate the myths in question. In the following, I want to explore this by largely highlighting moments of tension between the ideas I wanted to convey and the specific constraints of Bitsy.

8x8s and heartbreak

One thing you're confronted with as soon as you start using Bitsy is the serious limitation on making images. Bitsy's games are "tile based", composed of a collection of 8x8 pixel tiles. Your avatar is one tile, sprites are each one tile, and so on. 8x8 is not a lot of space to work with.

The most obvious issue came in trying to use this tool to represent the key elements in each myth, particularly in terms of legibility (see my sadness about Prometheus in 0b18f11). Representing any complex form in 8x8 is just not easy, so there was often a real need to simplify the images of the game, often shooting for something more iconic than "realistic". This is especially true of the avatars, which have a hard limit of a single tile shape. It's very possible to draw a little "person" shape (which I did for Zeno, Tantalus, and less successfully for Prometheus), but more detailed compositions like a person pushing a boulder just won't fly - not enough pixels. This was thus a big factor behind the decision to make the avatar in Sisyphus be just the boulder itself, for instance.

Along with the avatar issue, there's the need to represent environmental elements such as rocks or clouds, etc. There was a part of me that wanted the purity of one object per tile, as there's a kind of atomic truth to that. However, it just isn't possible to draw a very convincing cloud in 8x8. The solution, much more magnificently demonstrated by more experience and talented Bitsy authors, is to compose complex scenery out of multiple tiles. It makes the actual management of tiles a bit of a hellscape, but it means you've got the potential for much more "resolution" in your visual elements. A room is 16x16 tiles, and tiles are 8x8, so the largest possible image you could create would be 128x128 - still smaller than most desktop icons, but enough to make something pretty recognizable. As such, things like the rock in Prometheus are composed of multiple kinds of tiles to allow for a more naturalistic/organic line rather than the hideously blocky early attempts (9128154).

The majesty (and misery?) of colours

A major feature of Bitsy is its limited colour palettes. In fact for a single screen (room) you can only have 3 distinct colours: a background, a standard tile colour, and a sprite colour (for sprites, items, and the avatar). As you might imagine, this can make it a challenge to have everything in a scene be a "realistic" colour and it becomes correspondingly harder to rely on colour as a way explain to a player what something is, you really need to rely on (8x8 pixel) form.

Background colours were pretty straightforward since the punishment series has what I think of as quite iconic pastel-ish background colours already established, I just used them. Similarly, the basic tile colour is almost always black, corresponding to the default pixel colour in the original punishment game, which uses black as a kind of nod to images on ancient Greek pottery etc. Things got weird with the sprite colour.

My initial assumption had been that I would do the very tidy thing of having the sprite colour match the "highlight colour" I'd used in the original game (e.g. the yellow of Prometheus's chains or the green of the flag). This had a pleasing symmetry to it, but in practice didn't actually work. Consider Tantalus, which must contain an apple (traditionally red!), water (traditionally blue!), the background (a nice green), an avatar (black in the games), and ideally some clouds (white!) and a tree (brown and green???). Disaster. If the apple (a sprite) is red (in keeping with the original game) then the avatar has to be red too, since it shares the sprite colour. This looks bad (f28008d). If the avatar is black (in keeping with the original game), then the apple has to be black too, but this makes it look like an evil death apple (cb816c5).

This is all compounded by the fact that while working on Zeno, the most visually blank of the scenes, I realised it would help to have clouds in every scene as a way to add some detail to the sky area (d97aad4). Clouds are, as everyone knows, white, and so with two colours already taken (the background colour and the black of the base tile), the sprite colour effectively had to be white in most levels (e.g. 2a8453c).

This led, in turn, to a need to communicate more clearly about the apple, given it was white, eventually creating the need for a (white) tree to further explain it, as well as a dialog message that literally tells you the apple is an apple.

Also visible in the Tantalus scene is a particular feature of Bitsy's sprites - they always have the background colour as their background rather than having transparency. This is part of Bitsy's aesthetic charm, but is also odd-looking, since it means that the avatar in particular "erases" parts of the background when it moves over them, as you can see with Tantalus in the water here. It was a kind of wonderful moment when I realised that for this specific scene, this specificity of Bitsy is actually a beautiful win: Tantalus cannot drink the water in the myth, and here it's as if Bitsy itself solved the problem of representing this! Wherever you move the avatar, the water "recedes" from him because it can't share his tile, creating the effect of undrinkable, ever elusive water. This is probably my favourite moment of interaction between design and platform in this whole game (f28008d).

5 items or less

One objective I often have when using new tools is to think about the specific kind of world the tool makes possible, the map of reality is has under the hood. So, in the case of Bitsy, I was excited to use the idea of "items" as a specific part of my design. In Bitsy an item is a tile you can walk onto which then displays a message and disappears (as in, you picked it up).

In thinking this through, I imagined the ability to use items for a kind of "authenticity" in the telling of the myths, but it was not to be (ac29f28). In particular, I figured I'd be able to make the apple in Tantalus an item as this would have a delightful truth to it: the apple would genuinely be something you could pick up (technically, according to Bitsy's code), you just wouldn't be able to reach it, just like Tantalus (see this process journal entry). However, it turned out that if the apple was an item it would have to be at least one tile removed from Tantalus (in order for it to be blocked off from him) and, while this was funny, it removed the ability to display a message when Tantalus tried to reach it. Given my anxieties about the representation being pretty hard to decipher (as above), I decided to make the apple a sprite instead, so the player could "bump into it" and see a message about failing to grasp it (f28008d). In retrospect I'm not completely certain this was the right call, but it felt like the best move at the time.

In what I thought was quite a novel use of items, I also planned to make Sisyphus's boulder an item that could be picked up. This way the Sisyphus scenario would be that you would pick up the boulder at the foot of the hill and carry it to the top, only to receive a message that it had rolled back down. You'd go back down and there it would be again. I still think this is funny, but it turns out not to be possible: when you pick up an item it is gone for good, so when you return to where it was (even if you've visited other places during the play-through), it'll still be gone. This is an example of how Bitsy resisted the inherently cyclical nature of the punishment myths - with items in particular there was no way have that kind of infinity, they were obstinately finite (see this woe filled process journal entry).

In the end I didn't use any items at all, which I view as a kind of failing given how central they feel to the effectiveness of Bitsy, but also as a good example of how there can be poor fits between specific design objectives and the actual affordances of a tool.

I like to move it move it

A key point of tension between the myths and Bitsy is that the myths naturally involve the player trying to carry out some sort of activity, while Bitsy is most centrally a game engine about a player moving through a world, talking to things, and picking things up. As such, all the myths have to be told via movement and dialog (items being disregarded as above) and thus movement can't really be used for exploration anymore, it needs to be reserved for expressing the task at hand.

This is what led to having the avatar in both Sisyphus and Danaids be the actual object of torment rather than a person interacting with those objects. There's no way in Bitsy for an avatar to push anything, so the only way to move the boulder is to be the boulder. It's quite nicely philosophical in a way that Camus might approve of? This is also nice in that it pushes the role of Sisyphus much more directly onto the player of the game - you're the one pushing the boulder around with the arrow keys, there's no intermediary. Similarly, in Danaids, you can't have an avatar pick up and transport the water (items don't work for this damnit!), so the avatar is the water, which the player then transports to the bathtub.

In the other myths, the focus of Bitsy of movement works nicely because the myths focus on some kind of movement through space as their core activity. Zeno, most obvious, is running a race and so must move through space to do so - the standard avatar works well here. Tantalus is involved in a kind of movement when he is reaching for things, so it's not too hard to reinterpret his movement through the water as a "quest" for water (perpetually thwarted by the background effect discussed earlier), and the use of the up arrow beneath the apple is a special case of a failed movement (not permitted because you can't walk onto a sprite) (cb816c5). Prometheus is all about failed movement (0b18f11), surrounded by invisible sprites that serve as his chains (and deliver messages about the hopelessness of his situation) - here a lack of movement is what is needed and that negation fits into Bitsy's possibilities nicely.

The spacetime continuum

The standard approach to using Bitsy is to make an exploration experience. This is implied by the metaphor of "rooms" (individual screens) and "exits" (special tiles that allow you to move from room to room). Naturally, the clearest way to use these two elements of Bitsy is to make interconnected spaces that the player navigates, often while unfolding some kind of story or environmental storytelling.

As many Bitsy authors experiment with, however, the rooms/scenes don't really have to be connected in a logical spatial fashion. There could be weird spatial effects, for instance, or indeed the connections could be in time. This could be a dramatic time-travel effect in which you jump 60 years into the past, or it could be used to create very small shifts in time, amounting to animation (I particularly like the effect achieved in Day in the Life by Linda ND).

In the punishment myths this is important because they often need to create what amounts to a loop in time, with the player returning to a starting position (but with time having actually passed). Thus in Zeno the avatar reaches the half-way point only to be "teleported" (by an exit) back to the starting position (in the room), a nod to my original portrayal of this myth (bf0ccd1). Sisyphus uses this same idea: the boulder teleports from the top of the hill to the bottom, with the actual "rolling down" being implied between frames (not unlike the idea in Scott McLeod's Understanding Comics of "closure" using the gutters of a comic).

Finally, this kind of animated use of space can be helpful for making a more comprehensible experience. In Danaids when you place the water (avatar) into the bathtub, we need it to "leak out", which of course isn't something Bitsy can do straightforwardly. Instead, it was necessary to teleport the player to a room in which the water remains in the bathtub as a sprite, but the avatar has moved back to the starting position. On the player's first move, they are teleported back to the original room (without the water in the bathtub), creating an illusion of the water having drained away. It's primitive, but far more compelling than the earlier version in which putting the water into the bathtub just cut immediately to the water being gone and the avatar-water being back at the start (66ee125) - "spatial animation" allows this experience to be extended just enough to be a bit clearer (e340c4e).

Conclusion

Perhaps what I've found most interesting about making and thinking about (re)making these games in the form of Bitsy games is just how much detail is involved in the translation. It isn't the case that because the myths are pretty simple and Bitsy is pretty simple that their conjunction will be straightforward. Rather, the ways in which the story and the storytelling device conflict and contrast create frustrating, but generative problems that require a depth of design thinking I wouldn't have expected.