I tested a Mini Micro video game currently being developed for a game jam. A TextDisplay was being used as a combination HUD and debug screen. The health being displayed started at 100%. This was intuitive and made sense. After taking some damage, however, I noticed the player's health became "97%%".
Not only that, but other oddities are happening. "Ammo" is written as "%mmo", for example.
What's going on?
Mini Micro's TextDisplay
Mini Micro's TextDisplay is a graphics layer specifically for text only. It is a two-dimensional grid of cells, with each cell accepting a single character. This grid has 68 columns and 26 rows. When you print to a TextDisplay, the TextDisplay prints the string character by character, starting at the row and column that it has stored internally. The starting row and column can be altered easily by the game, which is what is happening in order to print the HUD.
Let's consider the above screenshot, taken from the MiniScript wiki. If one were to set the TextDisplay's column and row to 30 and 20 respectively and print "Goodbye!" in this state, you would see "Goodbye!orld!" printed on the screen. Printing "Goodbye!" doesn't erase all of the text of "Hello World!" Printing only overwrites the cells that are in its way. In this case, we are only partially overwriting what is on the screen, leaving a mix of new text and old text.
The Problem
In the game, this same issue was happening. "100%" is 4 characters. "97%" is only 3 characters. The 4th character from "100%" (which is the '%' character) is never overwritten when "97%" is printed. This results in the extraneous percent character being left on the screen.
"%mmo" is being written because originally it's written as "Ammo" -- but the string "ZomFrogs left: 100%" line is written chronologically after. When there isn't enough room to write that final '%' character, it gets written to the next line, obliterating the 'A' in "Ammo".
A Worse Problem
These are fairly easy for a player to spot as errors, but what happens when you are dealing with pure numbers? This is where things get much worse.
Imagine if the player must manage the temperature of a critical piece of equipment in a game. Let's say that 150 degrees (in whatever unit) would be too hot, and the player must act quickly and cool the equipment whenever it is reaching this temperature. If it goes over 150 for too long, the facility is in danger, and the player must abandon the equipment and escape.
Now let's further say the player sees "142" printed to the HUD. He recognizes that he must correct the issue by cooling the equipment. He does this successfully by bringing the temperature down to 98 degrees. When the HUD is updated, however, "98" is only 2 characters, whereas "142" is 3 characters. Printing "98" on the same row and column will result in a temperature being displayed of 982 degrees! The player might be convinced that he somehow failed and that he needs to escape immediately. Yet, internally, the game logic is treating the temperature as if it's 98 degrees, well within tolerance.
This sort of mismatch between the internal state of the game vs the feedback given to the player will confuse players endlessly, since it won't always be so clear to them whether the feedback they are receiving is a visual bug or not. If they are able to tell, then this could simply be a major source of frustration.
Solutions
We have a number of potential solutions. We could clear the TextDisplay before we write our data, thereby erasing all text and starting fresh. This is a valid solution in many cases, but it can be a bit expensive in terms of performance to erase the TextDisplay every frame of a game when we really only want to erase parts of it.
We could import the textUtil module (already included in /sys/lib) and use clearRow or clearRect to clear a limited amount of screen space. This is perhaps a better solution in that you're erasing less than the entire screen, but this requires you to keep track of each area that you need to clear.
A third solution could be to write the same amount of characters each time no matter what. Health, for example, in the original game mentioned, would always be written as 4 characters (assuming, of course, that 4 is truly the maximum length it could be). Ninety seven percent would then really be written as "97% " with an extra space appended. This is rather nifty, and relatively efficient if you're dealing with smaller strings whose max lengths you already know.
TextLabel
TextLabel is a new class I've added to my Mini Micro library to address the underlying issue. As it is brand new, it is subject to change in the API, but the concept behind it should remain the same. It tracks where you want to print, and it knows how many characters you wrote the last time, thereby handling the erasure of previous text.
The current implementation, as of July 29, 2025, could be used simply like this:
import "bclib"
health = bclib.TextLabel.Create(text, 55, 25)
health.print "100%"
health.print "97%"
Line 1 is just importing the library.
The next line creates the label. It binds to the TextDisplay pointed to by text, which by default points to the default TextDisplay used by Mini Micro on startup. If you have a custom TextDisplay that you created, you can bind it to that.
The next line prints the message at column 55, row 25 of the TextDisplay pointed to by text, and the line after that updates the text to read "97%". Because it knows the last message was 4 characters long, and the current message being printed is only 3 characters long, it knows to pad the rest of the output with spaces to overwrite only one extra character's worth.
Also, if you want to clear the label, health.clear would do the job.
The Need
This class could be useful because it achieves the results of the other solutions presented while seriously limiting the amount of work the programmer must do. For each update to the value being printed, the programmer only needs to write one print statement, with little to no calculation.
Hopefully this class will be updated and finalized in the near future.