Maze Minders – Bitsy to ZZT

This post documents some work done to convert a Bitsy game to ZZT.

Bitsy is a game engine designed for making small browser-based games. Graphics are based on 16×16 rooms made of 8×8 tiles. It exports to HTML and is very accessible.


ZZT is a text-based action-adventure that enjoyed a very long after-market life, initially spurred by its built-in level editor. Boards are 60×25 in size, and are comprised of various terrain and objects that are represented by DOS text characters.


The game is Maze Minders, a short Bitsy adventure about various pixel-art stick figures wandering around an orthogonal labyrinth. This is not my best Bitsy effort — I was really just interested in drawing prancing 8×8 stick figures — but I went with it because the maps are almost entirely 8×8 solid blocks that would translate easily to ZZT’s DOS text mode.

I’m really happy to see Bitsy finding a community. It reminds me of ZZT’s following in a lot of ways, and I suppose that’s why I am doing this juxtaposition. Figuring out how to do certain things in these kinds of tools sort of becomes its own game.


Tools used

Bitsy 4.6 – 4.8 – By Adam Le Doux – Stock engine with no enhancements.
ZZT 3.2 — By Tim Sweeney – Stock engine with STK1 assets
KevEdit – By Kevin Vance and Ryan Phillips – The most common 3rd party ZZT world editor.

1 Tweaked ZZT game assets that cannot be invoked from the built-in editor.


The ZZT built-in editor and KevEdit have no undo feature at all, so it’s prudent to save your work often. Every saved copy of the ZZT game in-progress has been included in the final release — 192 saved files in all. In hindsight, I really wish that I had kept all of those in-progress snapshots of my old ZZT games.


Mapping From One To The Other

ZZT and Bitsy share similar territory, but the nuts-and-bolts behavior of both engines varies substantially. For example, Bitsy has no moving objects beyond the player avatar. All moving things are either faked by warping the avatar to different-looking rooms, or by modding the game engine.

These limitations are interesting, though. Hard limits with a low barrier to entry can lead to creative decisions.



Bitsy art is 8×8 2-color pixel tiles with a 128×128 display. Any tile can optionally be animated with two 8×8 frames, be it the player avatar, sprites, or background tiles.

ZZT is limited to MS-DOS text mode, which is typically 640×350 resolution comprised of 80×25 character cells that are 8×14 in size. 256 non-editable character symbols are available.


Bitsy supports just three on-screen colors by default: A color for the background, a color for terrain, and a color for the avatar and sprites. These colors can be anything that can be displayed in a web browser, and they can be adjusted on a per-room basis. ZZT is capable of fifteen simultaneous colors, plus black, not counting dithering. Most of those colors are highly saturated.

3rd Party MS-DOS utilities were available that could effect the following changes on a system running ZZT:

  • Apply custom fonts
  • Apply custom VGA colors
  • Disable text blinking in favor of more color combinations in text backgrounds

These utilities were rarely used.



Bitsy has no built-in audio capability, though it is possible to add with mods or by embedding an audio source into a webpage that hosts the game. ZZT provides basic control of the PC Speaker / Beeper. When run through DOSBox, this is sent to your system audio as loud square waves that occasionally crack and wobble.


Engine Limits

Being an MS-DOS game, ZZT has hard limits on what can fit into a single World file, and in many cases, no warning is provided to a developer that those limits have been breached. ZZT doesn’t seem to do much in the way of checking data integrity. This is both a blessing in terms of what is possible, and a curse when it corrupts world files. Bitsy’s limits, sky high in comparison, are less likely to be breached during typical development.


Gameplay Behavior

With no moving objects, Bitsy has no action elements. Puzzles, if present, are typically based around making the right choices, taking the right routes, or having the right items. The only built-in interface element is the dialogue box.

On the other hand, shooting and block puzzles are ZZT’s bread and butter. Although ZZT worlds certainly exist without those elements, there will always be ‘Health’, ‘Ammo’, ‘Keys’ and ‘Score’ indicators on the sidebar, along with instructions on how to shoot things.


Mapping 16×16 + 8×8 to 60×25 + 1×1

Bitsy rooms and ZZT boards are pretty different in terms of layout. What would be the best way to adapt one to the other? In hindsight, maybe this wasn’t a good project to convert.

Because of the tall dimensions of the text cells, a 16×16 map ends up being tall and distorted in ZZT. You could use multiple text cells to stand in for a given Bitsy tile (say, 2×1 ZZT cells for one 8×8 Bitsy tile), but even if you filled the entire 60×25 board with a good-looking recreation of the 16×16 original, ZZT player objects are always a single cell in size, and cannot be expanded to match the new scale.



Differences in Linking Areas Together

Travel to other areas is similar, but different enough to cause issues as well.

Let’s look at two kinds of linking: individual warp tiles that send the player to another area, and walking off the edge of the screen from one area to an adjacent location.

– Portals between areas

Bitsy allows the author to place single-tile exits that can transport the player to any room, at any possible coordinate. These exits cannot be modified during runtime, unless the game engine is modded.

ZZT has Passage cells that behave similarly to Bitsy exits. They can be destroyed, and tweaked ever-so-slightly during runtime, but placing new ones dynamically will only yield passages that point to the game’s title screen. (That’s right.) ZZT passages can be vulnerable to some esoteric problems, and they typically count towards a room’s limited tally of active objects.

Mutually-linked Passages in the first couple of screens of Town of ZZT.

The subject of ‘esoteric problems’ in ZZT is just too large for a single blog post, but consider this example. In Bitsy, you can place exit A and exit B next to each other just fine. No issues. If you put ZZT Passage A and B next to each other, you risk the possibility that a Passage may be erased from the board if the player simply walks a single cell’s distance from A to B. Best case scenario: this is a minor visual problem, if A and B both point to the same destination board. Worst case: A and B pointed to different boards, and now your player loses access to an area and needs to either load from a save file or restart.

(This effect could be used intentionally, but I’m getting way off topic at this point, so onto the next item.)


– Linking areas by their edges

ZZT provides built-in support for linking the edges of one board to another. Let’s say you have two areas that are supposed to be adjacent to each other, and you want the player to be able to travel between them by walking to the bordering edges of those areas. In ZZT, you just define board edge exits: set Board A’s Eastern edge to point to Board B, and Board B’s Western edge to point to Board A. ZZT checks to ensure that the destination cell on the other board is not occupied, so the player can’t get trapped in a wall.

To do the same in Bitsy (as of 4.8), you would need to define an exit for every cell on the edge of both rooms — either that, or just place a single exit and indicate it as such by blocking other parts of the edge, or pointing it out to the user in some way. The former is prone to manual error. The latter is valid, but sometimes you just want to have a wide open area to travel across.


An array of room exits in Bitsy, half-finished.


Board edge linking in ZZT’s Demonstration file.


In general, Bitsy exits are no-frills and instantanous — you can hide exits anywhere you want, and build up animations out of multiple rooms linked together. In contrast, ZZT board transitions are accompanied by a flashing purple screen transition.



I have not gotten too deep into Bitsy scripting, so I can’t make a call on this one. I will say that both Bitsy and ZZT have, at minimum, basic support for setting flags that can be used to tailor how NPCs respond to the user. Bitsy sprites don’t budge an inch from their designated coordinates, while ZZT objects have a small set of flow control and movement statements that can be used, abused and layered in various ways.



After trying a few ways of scaling up the Bitsy rooms to ZZT boards, I decided to just map one Bitsy tile to one ZZT text cell, and fill in the remaining board space with decorative wallpaper. This shortens the amount of time it takes to navigate through the maze, and prevents alignment issues when a sprite is supposed to block the player’s movement through a corridor.

I initially tried making the rooms fill a larger percentage of board space, and making the characters multi-cell text mode doodles, but I couldn’t really fit it into the space properly. The player also looked tiny compared to the NPCs.

Bitsy room for reference.


The room dimensions I ended up working with.


Using double-width blocks. It looks nicer, but takes longer to travel through, and introduces new issues wherever NPCs are supposed to block the player from the North or South.


An unflattering test of expanding the intro room to the whole board.


I briefly tested displaying the NPC sprite art in the corner of the screen using an array of objects, but getting this to work would require either a significant amount of typing labour, or some kind of preprocessing scripting that I didn’t have the time to work out. Also, when a dialogue box is open, there is not enough space around the edges of the screen to display the sprite in its entirety, even if it was moved to all the way into the corner.

This array of objects would have consumed about 20% of each board’s object capacity, which could cause problems when trying to fix other issues, so it definitely didn’t seem worth the effort.


Testing having a ‘Monitor’ in the corner of the screen to represent the NPC you are in contact with.


The monitor would not have been visible during dialogue scrolls, so I just embedded those graphics into the text scrolls themselves.


As mentioned earlier, DOS utilities can apply new fonts and colors at the BIOS level. Here is a quick mockup of what might be doable using additional DOS utilities:

A quick count suggests that there would be enough room to hold all of the in-game sprite art within unused symbols on the code page. However, the characters are  small and difficult to see, and all of their animation would have to be managed with ZZT scripting.

In any case, all NPCs in the final version are single #char 2 smileys. There is a visual indication when an NPC has nothing more to say — they will change over to a hollow #char 1 smiley.


Development Snippets

Converting dialogue.

@Maze Minder is the object’s name. This appears at the top of text boxes invoked by the object.
#cycle 1 makes the object process on every tick (about 10 frames per second).
#end halts program execution.
:touch is a built-in label. If the player walks into an object, the object will move execution to the topmost :touch label in its program, unless none exist.
#zap touch turns the topmost :touch label into a comment, so that you can talk to an object and get different behavior from them.


Left: Sometimes the ZZT player will damage floor graphics when exiting a passage.
Right: To make this less noticeable, you can place black empty cells around all passages on a given board, so that they at least look consistent.


In the Bitsy version, this area is entered from one of the four sides, and can only be exited by jumping down the hole in the center. In ZZT, I placed hidden objects to destroy the passages that the player uses to enter this board. These objects use #put <dir> blue normal to replace the passages with blue dithered walls. I’m not sure why, but the commands didn’t seem to work fully, only destroying 50% of the passages. I had to repeat the command a couple of times in all of these objects to fully get rid of them. I’m sure there’s some explanation for it that’s slipping my mind.


Using KevEdit’s selection highlight to show hidden terrain / objects necessary to prevent the player from wandering out into the background / wallpaper void area.


Here is the most complicated board in the ZZT version (though it’s really not too complicated by ZZT standards). The protagonist has been wandering the maze alone for a very long time, and seems to be going around in circles. In the Bitsy version, every rightmost walkable tile contains an exit that repositions the player on the next path along the top. This isn’t doable in ZZT with just passages, unless you make every path a separate identical-looking board2. However, a bug known as player cloning can be used to accomplish this kind of warping.

2 (A passage can send the player to a different part of the same board, but it only works when traveling from upper-left to lower-right, to a passage with a matching set of colors. This board needs to move the player in the other direction.)

Cloning is possible simply because ZZT includes “player” as one of the entity types that can be invoked through scripting, along with various items and monsters, even though it’s buggy and plainly unintentional.


Four sets of clone-generating objects are used, one for each teleport point. In each case, Object A waits for the player to come in contact with it. When this happens, it sends a message to Object B, which places an empty space to the South of itself,  then a clone of the player to the South. After doing this, it sends a message to Object C, which prompts that object to wait for one tick, shoot a bullet to the East, and then place a blue solid cell to the East as well.


Because of how ZZT behaves internally, this causes the Player to teleport to the East of the newly-minted clone at the top of the area. After one tick has passed, Object C shoots the clone, destroying it, the original player left unscathed.


To make this as seamless as possible (and it’s not really: you can see the cloned player for a fraction of a second before it is destroyed), each set of objects needs to be placed in the correct order, or else the commands will require additional ticks to process. If everything is in order, then each successive object can begin processing its script as soon as the engine will allow.

It’s very interesting that this bug functions as a consistent (though convoluted and potentially fragile) way of moving the player around. This article on Museum of ZZT contains more information if you’re interested in reading about player clone behavior.





KevEdit is a wonderful tool, but do take precautions in case it crashes.



The ending board mimics a Bitsy ending text box with objects. On every ZZT board except for the title screen, the player has to be present on-screen, somewhere. I ended up sticking the player in the lower-left, hoping it would be minimally intrusive if I included some objects around it to prevent movement.


An object to the North of the player always places a blue fake wall to the South, pushing the player downwards.

An object to the East is supposed to place blue fakes to the West, but I forgot that because of a programming error in ZZT, this never works when the destination coordinate is on the last row of the board. The player is free to wiggle around in the corner while the ending text rattles off.

Oh well.

The final conversion can be found on



Rogue V5, as played on

Following are some scattered thoughts about the Roguelike genre, and a to-play list for myself as I explore the catalog.


Roguelikes are basically games that are like the 1980 Unix hack-and-slash Rogue. Originally played on text terminals connected to mainframes, your avatar is a little ‘@’ symbol, tasked with recovering the Amulet of Yendor from the 26th floor of the Dungeons of Doom. If (or rather, when) your character dies, it’s back to the very start with a fresh dungeon layout and new item definitions. Rogue maintains a high-score list, so that multiple users of the same system can compete for the highest amount of gold collected.


Rogue’s action is turn-based, and several aspects of the game are randomized — dungeon layouts, what potions and scrolls do depending on their description — to the point that they can’t be memorized from one game to the next. The chances of beating Rogue are very not in your favour. Luck is a large factor in determining your chances of survival, and on top of that, the difficulty curve soars during the final batch of floors.


The procedural generation systems and intense challenge make Rogue addictive and playable, and many developers have sought to emulate its appeal in the years since its release: from other terminal games, with increasingly complex underlying systems, to modern twitch-action games that have little resemblance outside of procedurally generated maps and permanent player death. I like both kinds.




Personal Roguelikes To-Play List

Will add thoughts as I play… This is going to take a while. Many interesting games are absent from the list, and I will try to flesh it out as I go along. The dates listed shouldn’t be taken too seriously, as I found them from random searches on the internet, and they don’t take subsequent work into account. I just wanted to sort the games along a general timeline.

Beneath Apple Manor | 1978
Superficially similar to Rogue, and released a couple of years earlier on home systems.

Rogue | 1980
My, what a yummy slime-mold.

Sword of Fargoal (Commodore 64) | 1982

Moria / Angband | 1983, 1990

Hack / NetHack | 1985, 1987

Larn | 1986

Omega | 198X

Fatal Labyrinth (Genesis) | 1990

Dragon Crystal (Master System, Game Gear) | 1990

Cave Noire (Game Boy) | 1991
Like a cross between Rogue and a puzzle game like Adventures of Lolo. I wrote a short post about the game here.

UnReal World | 1992

ADOM (Ancient Domains of Mystery) | 1994

Alphaman | 1995

Diablo | 1996

Linley’s Dungeon Crawl / Dungeon Crawl Stone Soup | 1997, 2006

IVAN | 2001

Doom, The Roguelike | 2002

POWDER | 2003

Frozen Depths | 2006

Brogue | 2009

Caves of Qud | 2015

Cogmind | 2015

Hauberk | In Development

 …AND MORE! Always more…


Roguelikes Reading List

John Harris wrote several “@Play” blog posts about Roguelikes, Roguelike design, and the genre’s history on GameSetWatch. His articles are collected on his blog,, and in his eBook @Play: Exploring Roguelike Games.

There are many insightful posts about development on the Roguelikedev Subreddit.

RogueBasin is a Roguelike community wiki.

Development Articles

Map Generation
Geometry, Line of Sight and Pathfinding


(e: 2017-Feb-13: Additional article links)

Cave Noire


Konami’s 1991 Cave Noire is a bite-sized dungeon crawler for the original Game Boy. Released in Japan only, it seems to have come and gone without much notice, outside of a small following on the internet. With minimal story and randomized dungeons, it can be considered a cut-down take on the Roguelike genre, with an emphasis on evading monsters.


Cave Noire has four dungeons with 10 difficulty levels each. Each dungeon uses mostly the same creatures and chamber data, but they have unique background tilesets, and the win conditions are different.

Once a dungeon’s win conditions are met, you need to find an escape door and get out alive. Completing difficulty level 1 of a dungeon will let you play level 2, and so on, up to the tenth level (called M). You win the game by completing difficulty level 6 of every dungeon, but you can continue beyond that, up to M if you want.

You can travel down a floor by using a staircase tile, or by dropping down a pit, but you cannot return to a previous floor. The dungeons vary between short floors with one or two chambers, and larger floors with up to about 8 chambers. Monster and item information is persistent for as long as you are on a floor, so if you dropped a health potion in a previous room, it will still be there on your return. While the dungeons do have a bottom floor, it is very unlikely that you will ever get there before you die or fulfill your win conditions.


cn_quest_1Dungeon 1: Defeat Monsters

You’re given a quota of monsters to destroy. On higher levels, this quota gets pretty high, and you need to pick your battles carefully.


cn_quest_2Dungeon 2: Collect Gold

Strangely, gold has no purpose in Cave Noire outside of this one quest — there is nothing to spend it on. Gold is found in treasure chests, lying on the ground in some rooms, and is occasionally dropped by the tougher enemies when defeated. Larger batches of gold are found on lower levels of the dungeon.


cn_quest_3Dungeon 3: Collect Orbs (Goblets)

Pick up a certain number of orb / goblet items and escape the dungeon. This might be the most challenging quest, because the orbs that you collect will occupy your inventory slots, squeezing out useful spells and potions. On the ‘M’ difficulty, the required orbs will take up your entire inventory.


cn_quest_4Dungeon 4: Rescue Fairies

Locate keys in the dungeon, and then use them to free captive Fairies. Rescuing a Fairy will destroy all enemies and partially remove fog from the screen.



Cave Noire features monsters with variable sizes, such as dragons that occupy four tiles, and different movement patterns. Some of them chase the player, while others patrol vertically or horizontally, or move in a small circle, or hug the walls.

Monsters will attack when you are adjacent to them, or retaliate after you strike them first. But you can also evade monsters indefinitely, even if they are right behind you, as long as you keep moving.

loop1 loop2



Periodically, you will find yourself on a dark or foggy floor. The fog masks all terrain hazards, and enemies are harder to identify (they’re drawn as a pair of cliche “evil eyes” when on a fog tile). When you move, any fog around your eight neighboring cells will be lifted. You have to tread carefully through fog so as not to fall down a hole (travel to next floor and take 4 damage), fall into lava (instant death), or get cornered by a monster.

Some resources on the game:

Monster GIFs

To the best of my knowledge, this is every enemy in the game:

cn_enemy_stationarycn_enemy_zombie cn_enemy_spider cn_enemy_skeleton cn_enemy_knight cn_enemy_minotaur

cn_enemy_mimic cn_enemy_ghost cn_enemy_gas cn_enemy_grim_reaper cn_pointer cn_fire

cn_crab_small  cn_enemy_centipede cn_enemy_stump

cn_enemy_big_bat cn_goblins_framerate_fix cn_enemy_giant_enemy_crab

cn_serpent cyclops

 cn_enemy_hydra  cn_enemy_big_guy_recropped

cn_enemy_big_dragon_white_framerate_fix cn_enemy_dragon_dark

cn_dragon_more cn_another_dragon


(e 24/Sept/2016: wording)
(e 18/Nov/2017: wording)
(e 2/May/2018: translated manual link)



ZZT is a sort of action-puzzle-adventure mashup for MS-DOS, the debut title from Tim Sweeney’s Epic MegaGames in 1991. Technically obsolete before it was even released, it uses Code Page 437 for graphics, the PC speaker for sound, and has a very silly and abstract tone.

ZZT is a difficult and unforgiving game that frequently tests the player’s patience, but it’s also pretty charming and mysterious. At a glance, it sort of resembles an ASCII Roguelike, or Apogee Software’s Kroz series. While Kroz uses a level-based progression, ZZT is more open-ended, with persistent screens that you can revisit.

ZZT enjoyed a cult following thanks to its built-in level editor and scripting language. Any user could build their own scenarios, even with the Shareware version.



The original ZZT Worlds

Tim Sweeney made four game worlds for ZZT:

TOWN.ZZT – The Town of ZZT
DUNGEONS.ZZT – The Dungeons of ZZT
CAVES.ZZT – The Caves of ZZT
CITY.ZZT – Underground City of ZZT

The Town of ZZT is the Shareware episode, and the others could be purchased through mail-order. All of the episodes are freeware now.



The Town of ZZT covers nearly all of the engine’s built-in functionality, and sets the tone for what to expect from other ZZT worlds. In it, you are tasked with finding several purple keys to unlock the ZZT Palace. These keys are scattered throughout the game world, and you’re free to track them down in nonlinear order.

Town is a mix of simple action, mazes (sometimes dark mazes, requiring a torch), and slightly more serious block-pushing puzzles. The enemies are kind of random and difficult to shoot, but the puzzle pieces are predictable, for the most part. There are boulders that can be pushed, but not pulled; sliders that can only be moved in two directions; pushers that shove anything in their way forward, and several other single-cell game pieces that can be combined together into fragile puzzles that necessitate a quit-and-reload if you mess them up. Town is very unforgiving, and the expectation is that you are making new save files whenever you feel even remotely at risk of losing.

There is not really any town in the Town of ZZT. Puzzles and action sequences are just there, because why not? Your reward for breaking into the ZZT Palace is … more ZZT. If and when you make it to the end, the game acknowledges your victory, and that’s pretty much that.

As for the other episodes, they are very much in the same vein. Dungeons of ZZT is a little heavier on action, Caves uses many dark areas and has some tougher slider puzzles, and City feels a little more like an adventure game (just a little), with increased emphasis on NPC interaction and some more object scripting.

Running ZZT Today

In the modern day, how does one take advantage of this opportunity for adventure, puzzles, savescumming and swearing? Browser-Based Emulator  — This is probably the easiest way to play ZZT right now. Just click the link, and voila. All of the original episodes are packed together, and you can find a plethora of other ZZT world files by searching The main downside is that your save files might not persist between browser sessions.

DOSBoxDOSBox works well with ZZT, and can be installed directly onto a variety of platforms. ZZT itself can be downloaded from the link above, as well. Some notes follow:

  • Just a heads up: the volume of DOSBox’s simulated PC Speaker is very loud by default.
  • To make input more responsive, you can increase the default CPU cycles from 3000 to about 10000 — use CTRL+F11 and CTRL+F12 to adjust on the fly. Cycle count is shown in the title bar.
  • There are alternate builds of DOSBox other than the common stable 0.74. Lately I’ve been using DOSBox Daum, which has some benefits:
    • 0.74 has an issue with keyboard input, where releasing one key will cause all keyboard keys to be released. This makes navigating around corners difficult. Other DOS games affected include Betrayal at Krondor. DOSBox Daum doesn’t have this problem.
    • You can toggle aspect correction straight from the menu, so you can view games from the era of 4:3 CRT monitors a little more like they would have looked at the time. You can then turn this off if it’s making things hard to see.
    • You can maximize the window, and toggling fullscreen mode also appears to be faster than plain 0.74.

Native MS-DOS or 32-Bit Windows – The most authentic, but least practical solution. The last systems capable of running ZZT directly were 32-bit Windows machines (and even they use an emulator behind the scenes).

Also, two ZZT supersets / emulators now exist: Chris Allen’s ZZT Ultra and SaxxonPike’s Lyon. I haven’t dug into them much yet, but they look promising.


3rd Party ZZT Games


I started writing some reviews of ZZT games here, but my ZZT nostalgia binge is drawing to a close for now, not to be recharged for another few years. The list I was working on had significant overlap with existing recommendations on the web, so I’m going to take the easy way out and just link to those instead.

As mentioned above, most ZZT games have been uploaded to, and can be played directly within your browser. Just go to, and search for the game’s title, plus ZZT. If the games lag in your browser, try hitting CTRL+F12 to increase the speed of the emulated CPU. If they still lag, you can download the games from the same page, run them in DOSBox, and try hammering CTRL+F12 again.

Other Links

Worlds of ZZT is a social media preservation effort by Dr. Dos. Follow the worldsofzzt Twitter bot to pepper your feed with randomly-selected ZZT game screenshots.



Odallus: The Dark Call under Wine

Here are some quick notes on getting Odallus: The Dark Call working with Wine in Linux. I played about half of the game on Windows, and the rest under Wine. The only major annoying issue was occasional frame-drop stuttering, which happens on my Windows desktop as well.

(I am not an experienced Wine user, so some of my notes might be fixable — this is just what I had to do to get it working. Reference links at the bottom of the post.)

Fedora 23 64-bit
Wine 1.9.12
Steam client in Wine
Odallus 1.1.0 via Steam in Wine
Antimicro input wrapper

I haven’t tested other versions (for example, the version on but I assume they are the same build.

Set Windowed Mode: The game doesn’t seem to go into fullscreen mode properly. By extension, TV Mode (the CRT display filter) doesn’t work either. Windowed mode magnified x2 or x3 ran OK for me.

Gamepad crash: The game crashes after the “seizure warning” screen, a few seconds after startup. Having game controllers enabled in Wine seems to be the cause of this crash. The workaround is to disable all gamepads in the Wine Control Panel, and then use a gamepad-to-keyboard input wrapper if you want to continue using a controller.

Enter wine control into a terminal to get to the Game Controllers screen:

odallus_wine1 odallus_wine2

Sometimes laptop accelerometers are detected as game controllers — if anything like that shows up in the Wine Game Controllers panel, disable it as well.

To restore controller input, you can use an input wrapper like Antimicro (on Fedora, can be found and installed directly in ‘Software’)

Other Stuff

  • It’s worth mentioning that Odallus’s keyboard input seems to be more responsive than the built-in gamepad support (specifically, when transitioning from a run to a crouch), so an input wrapper like Antimicro is something that may be desired even on Windows. I have not personally been able to get a wrapper to work perfectly on Windows, though — I suspect conflicts with the built-in gamepad polling. I left a post on the Steam forums to check if there is any way to just disable the native gamepad input.
  • I’ve noticed one other crash in the launcher — clicking on the “Scores” button — but this isn’t a critical function of the game.
  • If you’re curious: M.I.S. in the options menu is probably Machine Independent Speed, which is a frame-dropping mode in Clickteam game engines. I left it disabled.