Article by figosdev

Summary: Cheat modes are useful for developers because they enable debugging, and are sometimes called "Debug mode"

This article is more about an ideal than a hard rule, but it's an ideal that I want to encourage.

Lately I've been teaching a little about minicomputers, as a different perspective on coding and program design. I don't know a lot about minicomputers, but then I'm not teaching expert-level stuff either. In the process, I've learned some cool things myself. I am happy to note that there are people I can consult about and discuss minicomputers with who have actually worked with them.

One of the things that is very cool about minicomputers, is that some have a "cheat mode" even for the CPU itself. I was going to call this article "all software should be programmable", but then I realised that cheat modes were not just a great metaphor for what I mean, they're a good example.

I did not play all that many games on computers, at any point since I learned how to use them. I played Ghostbusters on a PCjr connected to a television, I played with an Atari 2600 before most people had ever played Mario on an 8-bit console, I played Tetris and Solitaire, and I played a handful of DOS games -- including Monuments of Mars and Commander Keen.

"Cheat modes are useful for developers because they enable debugging, and are sometimes called "Debug mode"."My original experience with computing (other than a few month stint with an 8-bit cassette-based Timex Sinclair) was a command prompt, a graphical, mouse-driven DOS application for drawing, and a manual for writing in BASIC. I would eventually learn that changing the code in BASIC programs was a lot of fun (and extremely educational) but it gave me an opportunity to try a lot of programs for free -- you could just borrow (or purchase) a magazine or book from the library or a friend, and start typing things in.

Monuments of Mars was a simple CGA game that I honestly thought was one of the coolest things ever. The graphics were simple, but the structures put together with sprites (along with aliens and robots that had only two to five frame "animation") were something I found exciting. Jumping up to shoot switches to turn them on and off was also cool.

I did eventually go to the trouble of beating both Commander Keen and Monuments of Mars without cheating, of course. But I honestly found cheating was more fun. At the time, I was more interested in the possibility of making games than playing them, and I wanted to explore the levels more than I wanted to jump up and shoot robots. Obviously, straight game play did demonstrate things that cheat mode did not -- like how far a jump will actually get you when it's not unlimited and basically flying.

Cheat modes are useful for developers because they enable debugging, and are sometimes called "Debug mode". This is also true of ODT mode for some late-model PDP-11 machines. But the cool thing about cheat mode, whether you're talking about a minicomputer CPU or Commander Keen, is that a lot of boundaries created by the game are transcended. This is something we generally want in our programs.

"The term window is a bit like "cheat mode", especially when you're root."It's a unique feeling to suddenly be able to walk through walls, fly around, visit game levels that were inaccessible or discover hidden levels and easter eggs. When you're writing code, a lot of this is simply the nature of being able to tell the computer what to do. And there are levels of accessibility, to be sure -- I don't have to recompile the operating system to be able to open a term window and become root. The term window is a bit like "cheat mode", especially when you're root.

Obviously I'm not saying that administrators shouldn't be able to lock down certain features, including root and sudo -- but the owner of the computer should be able to override everything; that's one of the promises of Free software. But this idea is about exposing a bit more power to the user, for those who would use it.

And it's not a new idea -- ODT mode on the PDP-11 let you change any value at any address. BASIC let you do more or less this with the PEEK and POKE commands. The Sugar platform was designed for a laptop that had a "View Source" key that was meant for native applications, not just HTML and JavaScript. And various games let you use cheats to add points, ammo, health and extra lives.

Before Minecraft, the Sims let you build a house with unlimited access to materials. I was more interested in putting weird houses together than actually playing. If I was using Minetest, it would be the same. It's cool that Minecraft is also a game, but what I really want is a voxel building application.

"This is a fun way to introduce the concept of variables and coding to users."Having explored some of the recent Unity-based games designed to teach coding -- I'm not interested in promoting them, though I did want to be able to rate and explain the concept -- for some of them, "cheating" (debugging the playing field) is really one of the goals of native game play. If you want to cross a bridge, the way you do that is by loading the bridge values in a widget and changing them so the bridge is long enough to cross.

This is a fun way to introduce the concept of variables and coding to users. You could put this sort of thing in so many games, including ones that aren't written for a non-free engine; instead of just having a cheat mode, you could make it so the player could bring up an option to "hack" individual objects in the game.

For Monuments of Mars, which came out decades earlier -- I found that save games were basically two bytes -- one was the ASCII value for the saved level (there were only about 20 levels per game) and the other was an ASCII value for how many charges you had left for the gun. Rewriting this binary file using BASIC (or a hex editor, though writing a few reusable lines of BASIC for the task was satisfying) was extremely fun for a beginner.

I also put a cheat mode in the text editor I'm using / extending / writing. The goal is to have something to use instead of Leafpad. It doesn't have proper word wrap (it just wraps around mid-word like the cat command does) but it does let me pipe text to it like a graphical version of "less" and CTRL-T runs whatever text is on a certain line as a shell command. So for example, there is no word count feature, but while I'm typing this I can hit CTRL-S to save and then type:

    wc cheatmode.txt

And if I hit CTRL-T then it tells me how many lines, words and characters the file I'm writing has. I could also open a term and do that, but this lets me do it right from the text editor. Then I just select the output, delete it and keep working.

This is more than a way to have features available before I even implement them. It means that I don't have to copy text to and from the term window nearly as much. Output is piped directly into the editor, and every line of text in the editor is a line of text I can run.

People who use programmable text editors already know how cool it is to be able to do this, but I don't really love Vi or Emacs. I use GNU Nano and Leafpad -- these are not editors known for a lot of features. I like them for their simplicity, and if I make a programmable text editor it's going to be designed for simplicity as well. Suppose I want to run some figplus code:

    figplus
    p "hello world" split p " "
    forin each p
        c randint 1 15
        now each colourtext c print
        next

Then I select those lines of text and hit CTRL-T again. This isn't implemented yet, though the first line of the selection would be "figplus" -- telling it I want to run "figplus" code. It then treats the rest of the selection the way it's designed to treat selections that begin with that keyword. Since a child process can't change the cwd of a parent process natively, I've already implemented a "cd " command that changes the cwd for the editor process via os.chdir. If Leafpad had this I would use it!

I could take all the code for figplus and stick it in the code for the editor, but since this creates a second version of figplus to maintain, I think I will just have it call figplus from the shell -- much easier to implement and maintain for snippets of fig code (doing it this way will create a few limitations).

I could have it simply save the code to a file, compile and run it -- and if I make it process standard "fig" that is how I will most likely implement it. But just to extend the capabilities beyond shell code, all it needs to do is take these lines:

    p "hello world" split p " "
    forin each p
        c randint 1 15
        now each colourtext c print
        next

-- put a newline between them:

    p "hello world" split p " "\nforin each p\n    c randint 1 15\n   
    now each colourtext c print\n    next

-- change the double quotes to single:

    p 'hello world' split p ' "\nforin each p\n    c randint 1 15\n   
    now each colourtext c print\n    next

-- and add double quotes to each side and call with figplus:

    os.system("figplus05.py -c " + chr(34) + 
    "p 'hello world' split p ' '\nforin each p\n    c randint 1 15\n 
    now each colourtext c print\n    next" + chr(34))

Then CTRL-T can run fig code as well as shell code. And we can add other commands too, like:

    append-to log.txt
    These lines will
    be appended to
    the log file.

Highlight that, CTRL-T, it writes what I've highlighted to a file. The only tokens processed by the editor are "append-to" and "log.txt".

Again, this is not the first editor that does stuff like this. But it's written in Python, it's PyPy-compatible, and it's designed the way I like it. The lack of a Code-of-Conduct is just a bonus.

To distinguish "all software should have a cheat mode or be programmable" from something like "all software should be as insecure as browsers with DirectX support, let's note a couple of things here:

The editor doesn't actually DO ANYTHING with the text when it loads. It doesn't get parsed, no automatic actions are taken.

To run code, you have to hit CTRL-T on a line that has code on it, or select code and hit CTRL-T where it recognises the first line of the selection. This is nothing like JavaScript, which runs when it's loaded and parses the entire document. It's not even like HTML.

"Different programs benefit from different cheat modes."The entire document is just text -- it may not even contain code, but the editor has no idea if it does or not until you highlight something and ask it to run what's highlighted.

Different programs benefit from different cheat modes. A video game that lets you change how long a bridge is might not benefit from calling shell code (it probably won't, unless the game design is very unusual). JavaScript might pose a security risk to the user sometimes, but the JavaScript console itself is less likely to.

One thing that saddens me at times about JavaScript (and HTML) is how complex it has gotten. To have a "cheat mode" or be programmable, I don't think every application needs a full-fledged, general-purpose scripting language. Though that's one way of doing it.

Simple languages with a handful of commands (10 to 100, just for some simple features) with simple syntax provide enough of a window to the program, to get more people interested in programming and computing in general. Sometimes you may need more than that, which is alright. But I'm still talking about all this in the context of homemade software I think corporate software should have features like this as well, but sometimes (as with Minecraft, Mozilla and LibreOffice) corporate software already is programmable or has debug or cheat modes.

As for the amount of work it took to add shell code processing to a text editor, I can actually grep the code while I'm writing this:

    nl = chr(10) ; from os import popen as po
    cmd = self.textarea.get(1.0,tk.END).split(nl) # get text
    cmd = cmd[int(self.textarea.index(tk.INSERT).split(".")[0]) - 1] # get line cursor is at
    f = po(cmd.split(nl)[0]) # call shell
    self.textarea.insert(tk.INSERT, nl + f.read().rstrip() + " " + nl) # update editor
    self.textarea.bind('<Control-t>', self.find_file)

This is slightly abbreviated, but basically what I added to make the feature possible. I've since added the ability to background processes with & (which first indicates the desire to background, and then is passed to the shell).

"...sometimes (as with Minecraft, Mozilla and LibreOffice) corporate software already is programmable or has debug or cheat modes."Adding a cheat mode doesn't have to require redesigning the entire program. It just takes thinking about what would allow the user to transcend the usual boundaries and assumptions of the program they're using -- to create an interesting and perhaps useful new window into the program itself.

As for snippets of code, particularly shell code and quick scripts, how can those have a cheat mode? In my opinion, if you're running a line of easy-to-edit shell code or a few lines of Python, you're in "cheat mode" already. Though for applications substantial enough to consider adding a feature, it's worth thinking about what sort of code you could use within the running application -- partly to make it more useful, and partly for the sake of education and encouraging the next generation of coders.

leafpad cheatmode.txt & # (I haven't added font sizes to the editor yet; this will make it easier to proofread) &

Long live rms, and happy hacking. ⬆

Licence: Creative Commons CC0 1.0 (public domain)