For a while now I have been working on removing some of the common critiques people had regarding the realism of the game. The main changes have been requiring components to be powered, adding latches and the change you can watch explained in this video.



It is in a video format, because I wanted to explain the changes thoroughly and I fear the blog post would have been too long.

Because I wanted to announce this large change properly and not have players guess it ahead of time, I wasn't able to really let players know I was working towards this goal of realism and why. But since the cat is now out of the bag, I am excited to once again be able to share the short term roadmap for the game.

With this change, the realism modifications I wanted to make are pretty much done (there may or may not be an option for having an explicit counter at some point, but this would not affect scoring and might be better suited for user generated levels). The next goal is to finally implement ingame sharing. I imagine 3 types of sharing.

1. Architectures: These would be fully fledged machines you can download to your own computer. I imagine this being useful for fantasy game consoles, real world architectures or community architectures. Other players will then be able to share programs for each architecture. So user A can make a game for the fantasy console of user B and so on.

2. Demos: Read only schematics for neat stand alone programs, like the game of life, a mandelbrot explorer or games.

3. Custom components: A way to share custom components or packs of custom components.

All this would take place through in-game UI and there would be upvotes / downvotes and comments. The magic internet points earned by player uploads will be visible on their profile (but you can't get downvoted below 0, so no need to worry about losing points).

In order to get this far though, there is a bunch of stuff I want to do first.

First of all, I want to tie up some loose ends. I need to actually implement the change mentioned in the above video, then fix a bunch of small UI glitches and quality of life issues and I want to finish translation support.

Secondly, I want to get to a stable point in terms of the basic components supported in the game. My opinions of many of these things have stabilized I think and I would like to make an honest attempt at never having to break things that have been committed to the sharing platform. So first I will add a lot of missing sandbox components, like more kinds of RAM, displays, networking and sound. The way the players should interact with these things will take some time to settle, so I will prioritize adding this first. I used to think that I should give players as much power as possible, but my opinion has been refined a bit. Providing players with finished building blocks for everything is like giving players the most powerful weapons in a first person shooter game. It makes them feel powerful but removes a lot of gameplay and fun. Instead I should provide players low level control of the IO of their computer, so they can build anything they want. I also want to have just one easy to understand way to do things and it is OK if it means it takes a bit of work to do common things, as long as it is not extremely tedious. This is also why the Random component was removed.

While we experiment with the sandbox components and give their interface some time to settle, I will add 16 and 32 bit variants of the 64 bit components. I like simplicity and you can use the 64 bit components for 16 or 32 bit operations, by simply ignoring the high bits (for all components except signed less). Further there is a neat symmetry of the byte maker taking 8 bits to produce a byte, while the 64 bit maker takes 8 bytes. However, actually watching a stream of someone building a 16 bit computer it became clear that it is a bit awkward and it just doesn't feel right. I can’t see myself ever supporting odd bit widths, since for speed I want all components to map to a single x86 or ARM instruction as much as possible. If you want to build a 107 bit computer, you can still do it, but simple schematics should reduce to simple machine code and if you are doing something complicated, it should be obvious from your schematic.

To support all these new components I will also have to upgrade the component menu, so it doesn't become completely cluttered.

Finally I want to mention that I had originally planned to bring back the old architecture scoring "perf score" system around this time, but thinking about it more, saving this effort in order to get to user generated levels faster is the better plan. User levels is the most important missing feature (although it will take much work) and users will likely create a better architecture scoring systems than I could.
Written 2022-03-18

Debrief
The original plan to have a "soft launch" of this game and scale up the player base slowly completely failed. Believing that games don't become popular without at least a bit of marketing, I thought I was well prepared when the game launched. With a handful of active beta testers, I wasn't aware of any bugs or anything I urgently needed to change, but with a high launch discount 500 players joined on launch day and I had to scramble to keep up with. That said I am of course very happy people are interested in the game.

Besides a ton of bug fixes the most noteworthy changes in the 6 weeks since launch are:
- 5(?) new levels
- A few new components and component changes
- A lot of reordering the level tree
- Faster undo / redo system
- Added level search
- Added WASD to pan
- Added the zoom feature
- Added a new control scheme (click to wire)
- Added key remapping
- Reworked the level save system
- Enabled nested components
- Added 64 bit wires and components

The road ahead
In the near to mid term there are 3 major features I am eager to add to the game.

One of them is allowing players to create and share custom levels. To do this I need to upgrade and document the custom scripting language used for levels. Any levels built in this scripting language can also be scored by the server. At some point I want players to be able to browse a wealth of custom levels in game. These levels will be ordered by up / down votes by default and will have server verified scores.

Another thing I want to add is schematic sharing through the sandbox. Here again I want an in game menu for browsing and sharing projects. I imagine players would create music, little games and so on. Before this I want to rework the screen and the sound component and make them work during fast simulation, as well as enabling 64 bit in the assembler.

And a third thing I want to add is content that deals with deeply pipelined architectures. New components and levels are needed for this, as well as a speed up of simulation.

So if any of that sounds exciting to you, stay tuned!
Written 2021-11-20

Conventional wisdom says that you should market your game as early as possible. Your game is supposed to have a "hook", which is something that trigger player interest and the game sales are supposed to spike on launch day, only to have interest taper off until you abandon the project. And then, on to the next flashy thing.

My goal is to make Turing Complete something different. If games could only compete on novel features or fancy graphics, this game would fail. But Turing Complete is about digital logic, something that is foundational to computer science, it was relevant 50 years ago and will remain relevant 50 years from now. And I intend to keep this game alive for for 50 years, or as long as I can. My hope is that curious engineers many years in the future will stumble upon this game and be intrigued. In short, while this game will never be mainstream, I do hope that it will be long lived.

So I agree with the conventional wisdom, if you are building a conventional game. But I don't think I am. And from a purely development perspective, I prefer a slowly rising user curve, so I can fix bugs in a timely manner. Therefore I didn't feel like it made sense to divert effort away from actually finishing the game, just for a spike on launch day.

That said, I know that this approach is a big risk and am very happy to exit stealth mode. It marks a major milestone and I can't wait to see the reception. I have such an exciting road map ahead, but I will save that for future blog posts!
Written 2021-08-28