Cyborg Earthworm»Blog
Anton Swifton
I have finally released the game in Early Access on Steam:
Anton Swifton
I procrastinated writing a blog post for more than one year, so quite a lot happened since last update.

1. Some experiments with design. I will probably make a bunch of separate posts about it.
2. A talk at Handmade Seattle.
3. An unsuccessful attempt to make the art fancy.
4. A successful attempt to make better programmer art.
5. A "coming soon" page on Steam:
6. A bunch of attempts to attract attention with mediocre success.

I will make more posts expanding some of this.
Anton Swifton
I procrastinated for 4 months, and then realized that I can't work on the web version anymore. There are too many big changes that have to happen in the code before I can be productive in making this program do more things. And recently I got a brief but clear explanation of why it's so difficult to make those changes:

So I decided to start working on a PC version. There are two pieces of feedback I got from friends and parents when I released the web version:
1. It's very difficult to understand what's happening. There is too much stuff on the screen and the rules of the game are not obvious.
2. The ui is pretty bad and ugly.

Neither is very surprising, considering that this is how it looked:

I wrote the whole ui system from scratch in javaScript in about 40 hours using HTML5 canvas. This time I decided that instead of doing it myself again, I will use Dear ImGui with SDL 2. The result (the first approximation) looks a little nicer and simpler:

Except for the images. The black thing that looks like a headless spider is an exit. It was my attempt to draw a pipe going down in Paint. The purple arrow on the field is an entrance. It should be a different image because the purple arrow is usually used to show directions, but I haven't worked on images yet.

In general, all images should be redone, because I realized that
1. The style doesn't work. You can't make it look good without making an entire rendering engine that will adjust the distance between strokes depending on the scale of the image. You also can't draw an image on top of another image easily.
2. It might make a more interesting game, if the body segments, instead of being simple circles, will be more like parts of a real worm, thus containing information about neighboring segments:

Using ImGui also helped with complexity. Here are some simplifications that happened:
1. The "details" label and its buttons were deleted. Their purpose was to visualize how the program works. Now it's done by simply hovering over patterns.
2. Three buttons per pattern for moving patterns around were replaced by drag-and-drop.
3. Most buttons are invisible at the beginning and get turned on as the player makes progress through the game.

There are also some game simplifications I made.
1. Hunger had to go. The purpose of it was to end a game when a worm gets into a loop. This was replaced by a proper loop recognition.
2. Cutting patterns wasn't essential, so it went away.
3. The first levels involved eating coffee beans, but a big part of these levels was also not hitting a wall. Now there are no coffee beans in the early levels, only walls. The beans will come later.
4. This also makes the histogram of the lengths unnecessary. The histogram shows for each length, how many times the worm reached that length before dying. With wall levels, you only have to know, in what percentage of games the worm found the exit -- that's one number.
5. There is a tutorial of the type that puzzle games usually feature. The first level is trivial, and each subsequent level introduces exactly one concept (most of the time).

I'm planning to bring this version into a playable state before the end of June, at which point I will release it on Itch and keep iterating until I run out of ideas.
Anton Swifton
I shut down this project more than a year ago, but this idea is still bothering me. After some thought and a couple of tests I decided to use Snake instead of Tetris as the base game. It seems to work relatively well, not worse than Tetris. Here is a little demo-version:

Short story long:

The main reason I shut down the project was that I didn't have the programming skills to finish it in reasonable time. There was also a small legal risk of being ceased and desisted by The Tetris Company, which I didn't want to deal with. Besides that, I found that patterns are not the best way to describe a program that plays Tetris. If you take whatever tetromino you get and put it in the deepest cavity it can fit into, that alone goes a long way. This simple idea will give you a program that completes around 70 rows on average. A good pattern-based program can do more than that, but it will be much more complicated. In fact, getting to 70 rows with a pattern-based program is already a lot of work. This doesn't mean that there cannot be a good visual language for expressing a Tetris program, but it will probably involve more than just patterns.

I didn't want to use Snake at first, because I took the idea of using patterns from this old game:

It was made in the nineties, and it lets the player program a snake with patterns. I thought that I have to contribute something novel and use this idea with a different game. It turns out that there is enough space for innovation even if you constrain yourself to the Snake game. The patterns can be done differently, the metrics can be expanded, and the whole game can be set up as optimization instead of competition.

It's in javaScript again, because it was the easiest way to try out the idea and to show it to people. It is unclear what the best direction of development for this project is, but locally I will probably keep improving the demo-version for at least a couple of months, because there are some obvious flaws that should be fixed.

Edit (2019, May 20):
I'm evicting old screenshots from the front page, so here is how the game looked when this post was written.
Anton Swifton
Here is an article that advocates for Norton Commander-like keyboard graphical interfaces (and in general, reconsidering how we use computers for everyday tasks).

Ignore the fact that this is a long article about what tools are better suited for particular tasks, written as a sequence of tweets.

I agree that keyboard interfaces are faster to use once you get used to them than interfaces based on screen buttons. Also, Screen buttons, if you think about it, sound a little unnatural: you have a bunch of physical buttons already, why would you draw a fake physical button on the screen, that doesn't give you any tactile feedback, and then animate it so that it gets better at pretending that it's a real button and gives you at least some visual feedback?

On the other hand, I used Norton Commander as a child (not having decades of practice using a mouse), and I remember that it was still tremendously easier to use it with a mouse than with a keyboard. So, I'm not sure that the difficulty of keyboard interfaces is caused by absence of experience compared to mouse. I think keyboard interfaces might still be inherently more difficult to learn than mouse interfaces. I should probably look up some studies on this sometime.

Maybe sometime later I will implement a keyboard-only interface as an option for this game or another game of this kind. I don't know how to make pattern input convenient on keyboard, though.