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: https://store.steampowered.com/app/1212760/Cyborg_Earthworm/
6. A bunch of attempts to attract attention with mediocre success.

I will make more posts expanding some of this.

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: https://www.youtube.com/watch?v=ubWB_ResHwM

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

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:

http://pentode.games/

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 pro

Here is an article that advocates for Norton Commander-like keyboard graphical interfaces (and in general, reconsidering how we use computers for everyday tasks). https://tttthreads.com/thread/927593460642615296

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 th

I'm going to stop working on this project for an unclear amount of time. The main reason is that the project is too large given that I'm trying to get a PhD and do a bunch of other things at the same time. Another reason is that there are legal issues that I don't want to deal with.

If anyone was planning to play when the game is finished, I apologize. However, there will be similar games, because I'm interested in the idea of giving the player an intuitive graphical interface for making a bot playing a game (and exploring this idea doesn't have to involve Tetris).

In the near future I'm planning to go back to making games that run in a browser, and the main motivation for my technical decisions will be the desire to try my ideas as fast as possible and let people play my games with the minimal effort. Thus, the only handmade thing about my programming will be the fact that I like doing things from scratch. I might look into webassembly at some point, though, so if people are i

After making a pretty good progress in May, I thought that I should get more serious about this project. This would involve:

1. Sorting out legal issues. The Tetris Company has been suing people for copyright infringement very actively, and I have to find out a way to avoid a lawsuit.
2. Putting the prototype online and posting a note to a couple of appropriate subreddits and maybe Hacker News to find out whether people find this game interesting (I still don't know whether they will, frankly).
3. Thinking about doing some PR and eventually making the PC version commercial, if there is enough interest. Ideally, getting a licence from TTC to be able to use the word "Tetris" in the description would increase discoverability greatly (I think).

Basically, TTC copyrighted everything they could and a couple of things they couldn't. "Tetriminoes" is a trademark, which is ok, I guess, since they are not tetrominoes. Shapes of blocks are copyrighted, which is pretty confusing: does it

Here is how I measure the speed of my program: I run the game for 1 000 000 randomly picked tetrominoes and measure how much time it takes. In the js prototype it takes 40 seconds.

Here is what I have done in May.

1. Implemented the matching algorithm in C. Running time was 44 seconds, slightly worse than the js version. Compiling with /O2 gave a 2x speedup, bringing it down to around 23 seconds.

2. Made it possible to test a program by loading a pre-generated sequence of tetrominoes and turning on deterministic mode (it was randomized in several ways). Now the game runs identically between launches. After making a change I can make sure that the game runs the program the same way it ran it before by just comparing two files that store results of the run.

3. Improved efficiency of the matching algorithm. Instead of trying to match the pattern to every region of the field, now the game only tries to match it to the regions on the surface. Here is what I mean by that. Let's

The semester is over, though, so May should be more fertile.

When you test your pattern-based program, Tile Machine simulates the Game of Falling Tetrominoes and uses your program to decide where exactly each tetromino will fall. This process consists of the following steps.

1. Pick a tetromino randomly.
2. Consider the patterns that handle this tetromino. Each pattern in the game can handle only one tetromino (*1). I use the word "column" to denote the set of patterns that handle the same tetromino (*2).
3. Patterns in any column are ordered. Take the first pattern.
4. Run the matching algorithm.
5. If the pattern matches a region of the playing field, put the tetromino into the place specified by this pattern and let it fall according to the rules of the Game of Falling Tetrominoes.
6. If the pattern doesn't match any region, take the next pattern and go to step 4.

The matching algorithm consists of four steps.

1. Find all regions that match the pattern (*3).
2. Remove all regions that are obscured by tiles above them.

Before exploring possibilities for speeding up the computations in Tile Machine, I decided to add one more feature to the prototype: small challenges that allow the player to make incremental progress in the game. Trying to beat the whole game at once is difficult, I spent many hours trying to do that and only got to the average game length of 150 rows. Another reason why challenges are useful is that making patterns for all tetrominoes is a lot of work. It's much more enjoyable to make a program just for one tetromino, optimize it and extend it to handling other tetrominoes later. Thus the first several challenges don't involve the whole set of 7 tetrominoes. There are currently 16 challenges, and I will be adding more later.

Another small improvement is that the program is now stored in browser's local memory and persists when the tab is updated or closed and re-opened. If you need to start over from scratch, you can use the "Reset Program" button. This will erase the program from

I am planning to build a higher quality desktop version with a better UI and more advanced testing features. The idea is to use C and Windows API for UI. Another alternative is to keep doing it in javascript and just improve the current version. The current plan is to go with C, because I think that it will be easier to optimize the matching code (which is currently the only bottleneck) in C than in js. Also, I think that a Windows UI will be better than a browser UI. Also, I think that handling saves will be easier and the result will be better. I'm not completely sure about any of that, though.

When I was making the prototype I couldn't answer two questions:

1. Is the game interesting? Will other people enjoy playing it? I'm still not completely convinced that making a higher quality version is something worth doing. If I will be the only person playing the game, I can play the lousy browser version and be happy. Thus, if you like playing the prototype, please let me know. If you