It's not certain if there's going to be different DCPUs with different specs. Notch has said[1] that there's definitely going to be versions with different clock rates floating around in space or on abandoned spaceships.

Reminds me of my community of modders and mappers of the original Jedi Knight game. The engine was out-of-date pretty soon after release, but it's only within the last few years that the editing community has died down. People found ways to create 16 bit textures (the game only came with 8bit colour-mapped ones), how to implement bots in multiplayer, they hacked the binary to remove hard-coded graphical limitations. All of this happened while there were far more powerful engines like Quake 3 and Unreal available to play with.

This reminds of Heroes of Might and Magic III WOG - The folks changed the executable so much that future scripts were encoded as text, hidden in the message-boxes showing information about the map to the player (they would pop once in a while, if the game scripts says so).

I know how crazy (in good sense) are the modders - I had to help release the mod tools for World at War and Black Ops (I work at Treyarch).

Actually, one of things that the DCPU reminds people of it's not enough to just be Turing complete. You also need hardware to represent the state of your machine (graphics monitor or console), and ways of providing input. Turing Complete machines aren't very interesting if you can't see what they're doing ;)

Also, don't forget, you 'only' have 100,000 clock cycles to play with.

What's (potentially) revolutionary about this game is the deep rooted support for emergent gameplay. A telltale sign of a great game is that players themselves, in exploring the game, find new and interesting things to amuse themselves. Minecraft is an obvious example, with hundreds (thousands?) of public servers dedicated to varied pursuits.

A different type of example could be EVE, where the rise and fall of corporations is gameplay not written in by the devs, but gameplay created by the players. Any game that has developed a professional gaming community could also be lumped into the category of having emergent gameplay, since there is an entirely new game mode (spectating) created by a community surrounding the game.

When I look at 0x10c, and know that I'm going to have complete control over a CPU in game, and this CPU will be the basis of my pursuits in the game, I know that there will be interesting things to be done. This is because there's such a strong focus on allowing players to create their own gameplay. No other game (that I know of) takes its players' creativity seriously enough to rest so much of the fun on their shoulders.

Having Notch to hype the game certainly helps, but helping to create this world is alone an exciting prospect.

The fact that it was Notch gave it visibility, but I think the following is more than just design or cult-of-personality.

Simplicity is extremely important. A lot of emulators appeared the same day that the spec was released. That not only needed people who wanted to implement the CPU, but also a spec that could be implemented in under a day.

There's a bit of Benevolent Dictator effect here as well. It's not that the system is the absolute best, but it's something that people can target for interoperability. Someone can write a compiler and someone else can write the emulator.

As an aside, I find it entirely plausible that these restrictions are, if not designed for, at least desired in the design.

As they make the work of a compiler harder, they promote coding in assembly to get faster code. This, on the other hand, leads to lower code quality (as avoiding gotchas and dealing with corner cases correctly is a lot easier even in c than in assembly), which creates more "drama", which is good for gameplay.

I don't think the 6502 had #1, or at least not in an easy way. Accessing, say, the second element from the top of the stack required you to copy the stack pointer to the ?X? register, then use that to index into the stack. That works, but is cumbersome.

How long will it be before somebody ports a nice VM to DCPU-16 or targets a compiler for it? The architecture is so simple and familiar I'm guessing that's not a terribly hard job. Folks are probably not going to write their programs in DCPU-16 assembler.

It does exist: https://github.com/llvm-dcpu16/llvm-dcpu16. The only problem is that there's not going to exist a compiler in-game. People will have to import the compiled assembly code, which isn't nearly as fun as staying in the game during the whole process.

Which is a pretty good argument for building a self-hosted Forth. You get a compiler and REPL suitable for commanding the computer in a package that will fit easily in the limited memory resources available. If you use threaded code with an "inner interpreter", it's possible to generate very compact code and fit a lot in a small space, or you could emit machine code directly ("subroutine threaded code") for speed.

There are already a number of compilers targeted at it. Browse through reddit.com/r/dcpu16 and you'll see a new one pop up every few days. I'm curious how long it will take before we see compilers that are good at optimization. Pretty much every compiler I've seen crop up makes admissions that it's generating terrible code.

I've been finding all of these programs incredibly refreshing and easy to read. Each instruction does exactly one strictly-defined thing before moving to the next instruction - so simple!

It will be interesting to see if my level of refreshment remains intact as the level of complexity inevitably explodes. Even this pacman game, which is the most complex I've seen yet, is much simpler than whatever space ship or armada management programs people will eventually start writing.

Its funny because in retrospect anyone can see how this game should be a success due to how folks were using Minecraft to build complex machines. And yet it came from Notch again (ok, he has a massive fanbase which will probably determine his success, but anyway...)

This brings back distant memories for me: ages ago, just for fun, I wrote a quick-and-dirty PacMan clone for the TRS-80 Color Computer, which was powered by a lousy-by-present-standards Motorola 6809 processor.

I have to agree with some of the other comments here, 0x10c looks to be some sort of milestone: a fully programmable, Turing-complete game!

You are absolutely right -- in the sense that even a dead-simple Turing machine built inside one of those other games is Turing complete too.

0x10c feels like a milestone, though... I guess it's because the in-game CPU this time around is usable on a human timescale. If in-game networking is ever added to 0x10c, one could even imagine a usable minecraft clone inside the game. It feels different this time.

Yes, I think it's an important milestone in terms of making that sort of mechanic more available to everyone. Most people were building small, special purpose circuits instead of general purpose devices, simply because it was difficult and wasteful to build your own CPU... unless that was their goal in the first place.

I have heard that although I never used OS-9. I programmed a 6809E on a development board in college after having learned 6502 assembly in high school. Liked it a lot better than the 8086/8 assembly I took the semester afterwords.