Constraints
This game was made for the GMTK Game Jam 2020, which had the theme "out of control". Games in this jam would be judged on three categories: originality, presentation, and fun. And one other constraint: the "vast majority" of code had to be written during the jam.
That latter constraint ended up constraining the design somewhat. None of my game jam games so far have used any sort of pre-existing third-party framework (e.g. I don't use Unity or anything), which means a lot of things that might otherwise be handled by a framework, like making sure the framerate and scaling are right and handling input, are things I've done myself. To make things easier on myself, I've been taking various bits of non-game-specific code and putting them in a separate file that I copy to all my other games (sort of like my own framework). The problem: for most of my games, the non-game-specific file is larger than the game-specific code. If I just used it as-is, then it would most likely not be the case that the vast majority of code would be written during the jam.
My solution to this problem was to only use a small part of that file, and then delete the parts I wasn't using. I looked through the file and determined that the largest things in the file were keyboard-handling code (which includes support for remapping the keyboard and simulating a controller on a touch screen) and code to display menus, so I decided that I would try to make a game exclusively controlled by mouse/touch (so I could get rid of the keyboard code) and not have an options menu. (This ended up sort of working with the theme: lack of options menu means less control than usual for my games, and my intro about my keyboard-handling code not working ended up being more self-referential than it otherwise would.)
Ideas
A few ideas that I came up with between when I heard the theme and when I started actually doing the programming:
- Something like MariAri or Mario and Wario where the character moves forward automatically and the player makes or destroys platforms for them. (Maybe a bit too obvious of an interpretation of the theme, and it's been done before—I just named two games that did it.)
- Something where the character walks automatically and the player is controlling a light, and the character avoids enemies only if they can see them. (…could have been interesting)
- Something where the main character can get possessed/mind-controlled at some point during the game (sort of used that in my game)
- A menu-driven RPG where the computer picks which attacks you use, and then the player has to actually do them somehow. (Maybe too similar to WarioWare?)
- A game where the player has no control over what order events happen in or how well they do; something based on the idea of illusion of control, but for ordinary gameplay (which would ordinarily still be under the player's control) rather than story stuff.
I chose the last of these options, as this was something that I hadn't seen done before at all. (Looking back I might have been a bit too focused on the "originality" criterion, trying to make something that hadn't been done at all, at the expense of other things.)
Then I tried to come up with what sort of game I'd make. I decided to try to make something like a roguelike, at least in terms of having a procedurally-generated map; for one thing, the idea of taking something out of the designer's control was mentioned in the theme reveal video, and using procedural generation does that; for another thing, if the map isn't predetermined, then I can make the next room that the player hasn't been in be the exact type of room I want them to have. (This means that I don't actually generate the map ahead of time; I generate each room as the player comes to it… mostly. More on this later.)
And then the actual mechanics themselves:
- Confining the player to a box is easy in terms of collision detection.
- I considered having abilities based on Control-key shortcuts like cut, copy, paste, undo, etc., and maybe a "control" meter so you'd be "out of control" at some point (other games did this), but didn't think I'd be able to make this work with my main idea. Instead, I took this "out of control-key" idea and used it for the introduction. (…and I think that's what gave me the idea to use a computer-chip aesthetic.)
- The use of mouse cursors is partly because I needed a mouse cursor for the intro, and I could use the same code to draw that and the player character.
- The player character originally shot bullets when they moved (which would make it a shoot-to-move game, which have been common previous years), but I decided it would be easier to program if enemies just had to dodge one point. (The attack-to-move mechanic I ended up using is similar in some ways to what I did for the first GMTK Jam, X/, although ironically this game gives the player more control over it than that one.)
- The enemies have lasers so I can easily determine before they shoot if they're going to hit or not.
- Originally there would be a laser power-up for the character, but I decided against it for simplicity.
- The music was something I could program quickly (note that none of my games so far actually use any audio files; I tend to do things in code), and like I mentioned earlier, procedural generation fits with the theme. (I don't know if it's noticeable, but the music does change between levels; it uses wider intervals in level 2, and narrower ones in level 3.) (The backgrounds are also procedurally generated; I made a few tiles and then had the program piece them together randomly.)
The bug
A few hours after the deadline, I replayed the game and ran into a bug: when I tried to go down one of the paths, I got an error, which I hadn't gotten when testing the game before the deadline. Later that day, someone was streaming a bunch of games from the jam, and they streamed my game, and encountered a similar error on two attempts of playing my game.
The problem is with the room generation. Like I mentioned earlier, most of the time, the game generates a room when you actually get to it, specifically the moment you enter the path to the room (which is when the error happens). However, to ensure that the player doesn't get stuck in a dead-end, it'll sometimes generate other rooms as well, and the code that was supposed to do that sometimes tried to generate a room that was already generated. This sometimes violated the assumption that there's a next room to go to that hasn't already been generated, so the game would try to generate a path in a nonexistent direction and crash.
After discovering the bug, I uploaded a simple fix to my website and put a notice in the description. However, the 1.3 version (after the final results were revealed) just removes this extra room generation entirely, because it wasn't necessary with how I ended up doing things in the final version (when I wrote that code, I had a more complicated idea in mind for how I'd handle room generation). A side effect of this is that level 3 used to sometimes have split paths with short dead ends, but now no longer does.
(Also, it turns out I introduced another minor bug with the fix by changing the version number. In particular, the version number overflowed the window in the ending screen, because "post-jam version" is longer than "jam version".)
Things I might have done differently
Looking back (and realizing how many entries each person was probably judging), I think I probably should have made something where it was easier to see what I was going for close to the start of the game, rather than intentionally obscuring it and requiring two or three playthroughs to see that something strange was going on. (…so maybe I should have done one of my other ideas.) I still don't know how many people who rated or commented on my entry actually know about the illusion-of-choice thing; maybe some of them just thought that the control-key thing in the intro was my main use of the theme.
Also the unskippable intro was a bad decision. It was supposed to fit with the theme by giving the player less control, but it ended up just taking too much time, especially when I wanted people to play multiple times. Version 1.3 fixes this (click to skip the intro).
Some other things:
- There's not really much hint in the game itself about what's going on. Maybe I should have incorporated it into the story more, put some sort of themes about predetermination or destiny or something like that, and some hinting that things aren't as they seem. That would probably require a much different story than what I actually went with.
- Part of my inspiration was an observation that I'd made in the past that making a perfect Pong player wouldn't be too difficult; I thought during the judging period that maybe I should have just made this a version of Pong instead. That would have the advantage that the player would already know the rules, and probably would have been easier to implement; on the other hand, I don't know if I could use that intro with it, and I wouldn't have gotten as much of an original game out of it. (…aaaand now I'm thinking about making that Pong game… but I have other, non–this-jam-related stuff I want to do, so maybe not…)
Updates
1.3
Some more spoilery details about what I changed in version 1.3 (after the judging period was over), in addition to what I mentioned in the version history page:
- There's a log of most of your actions in the background. My hope is that maybe people will notice certain patterns ("oh, those events were in that order last time I played") and maybe make it slightly easier to see the out-of-control thing.
- Enemies now sometimes randomly teleport before shooting lasers to make it less weird when they teleport to dodge you.
- If the next thing you're supposed to do doesn't involve interacting with enemies, then enemies will start to just teleport out and eventually stop appearing, so hopefully people won't spend a long time trying to kill enemies they can't kill.
- Enemy aim is more accurate when they're trying to hit you.
- If you transition between rooms enough times, the probability of the next room being a shop changes to either 0% or 100%, depending on whether the next thing you're supposed to do is buy from a shop.
(Also, just to be clear: version 1.2.1 was before the deadline for the jam; 1.2.2 was the bugfix version after the deadline during the judging, with a link in the description; 1.3 was the first major update after the judging finished. 1.0-1.2 were other versions that I uploaded before the deadline so that I'd have something in case I didn't get the final version done in time.)
1.4
Encounters are now numbered and you only see enemies when you're supposed to interact with them. I hope this cuts down on potential frustration caused by evading enemies and also makes it a bit clearer what's going on (especially since the end screen now shows the results of each encounter).
Also now buying keys is no longer an action that has to occur in sequence. And neither is getting mind-controlled.
Other notes
The music and sound effects (other than the typing at the beginning) are all triangle waves, which are used in chiptunes...