Technology of note: "The computer in the game is a fully functioning emulated 16 bit CPU that can be used to control your entire ship, or just to play games on while waiting for a large mining operation to finish.
[...]
The cost of the game is still undecided, but it's likely there will be a monthly fee for joining the Multiverse as we are going to emulate all computers and physics even when players aren't logged in."
This could quite possibly be the nerdiest game ever made. The amazing level of boffin creativity we've seen in Minecraft could easily be eclipsed by giving everyone their own in-game programmable computers to tinker with.
I've followed his comments on Twitter. Apparently he considered doing a clone of a real CPU (6502), but it was too complicated to emulate efficiently. According to notch, the custom architecture he's inventing can run 2,000 DCPU's at 100kHz each and only use 50% of the time on a real CPU. Here's the first public spec from a few days ago, I think it's changed a bit since then http://notch.tumblr.com/post/20056289891/start-classified-tr...
You have N players == N computers to simulate. Assign randomly 5 computers to each player to emulate. Choose the result that majority of clients return and optionally punish cheaters.
EDIT: apparently simulation will go on even when players log out, so each connected client may need to simulate 100 in-game computers to account for that. Still less resource intensive than running everything on the server. But Notch thought about that much longer and surely have great reasons for his architecture.
Letting the clients handle the simulation would have a lot of problems for a MMO. Extra problems if you were doing the work for other players as well.
I think part of the point of it being a special emulated CPU set at a certain speed is to make it fair for each player, rather than the player having more processing power just because they have a better computer.
The easiest way to secure all that is to run it on the server. Anything going to the client or trusted coming from the client eventually gets hacked if there's much interest in doing so.
You could make the client run other player's CPUs, perhaps ones from accounts on a different server. If it's not someone you know or are playing with, then there's less incentive to cheat. You could even pass the same work to multiple clients and flag those that are tampering with the results.
Backstory is cool too and coincidentally appropriate for parent's username: "released, compatible with all popular 16 bit computers. Unfortunately, it used big endian, whereas the DCPU-16 specifications called for little endian. This led to a severe bug in the included drivers, causing a requested sleep of 0x0000 0000 0000 0001 years to last for 0x0001 0000 0000 0000 years."
That looks like pretty much every small virtual machine I can remember reading. There's nothing atrocious about it; that's what small virtual machines look like.
With a couple of simple macros, the code could be fraction of its size and much more readable. Code with that property is atrocious in my mind. For example these "argument reading" bits are repeated over and over again:
Of course Notch said it has been generated, so he probably had a neat definition that barfed this garbage out. But it's strange that so many commentators here are defending the output as a reasonable coding style for a VM!
It's just a big switch/case over the instruction set by the looks of it. Those things can get pretty damn large if your are implementing anything close to a proper CPU.
It's just very condensed, I imagine so he can change a bunch of values and re-test quickly.
It's not quite as bad as it would be in a program other than an emulator, granted, but I can't imagine that it's easy to notice a bug in a 200-character line of:
int pos=(ram[PC++&0xffff]+X)&0xff; byte v=ram[(ram[pos]&0xff)|
And so on. It just seems like some sort of code generation would be much easier.
That kind of code generation is unlikely to exist. Each line of that code has its own specific purpose, it's not some copy pasta. And surprisingly, it should be trivial to test it! there are no conditions of edge cases apart from the conditional instructions. As long as you test for ranges and off by ones, there's no space for mistakes really. I'd take that kind of code over usual "business logic" any time :-)
Nonsense! Look at the code again. There are a lot of repeated motifs, like the things that fetch from memory and increment the program counter. It cries out to be partially automated. If nothing else, there has got to be a more human-readable equivalent to all that bit-masking and offset-adding.
Off by one errors, maybe we'll even bring back the golden age of buffer overflow exploits, emergent realistic hacking gameplay mechanics, Notch you're a genius...
You cannot really do code-generation when all the lines have meaningful differences. What you saw was very likely the most compact representation of the VM -- any other form would likely be just as bad.
This is true, but it should be easy enough to make a script that can pack/unpack the code as needed.
Most likely when you have a bug in something like this it will be isolated to one specific instruction. So you can just zoom in on the bit you need.
If you followed the standard Java practice for this you would probably have an Instruction class that inherited from several base classes and that would make your project very large and difficult to navigate indeed.
I would suggest you attempt to solve the "Cult of the Bound Variable" programming problem[0]. The first stage of the problem requires you to write an emulator for an "ancient" computer that has a very easy to follow instruction set.
it's just a bunch of (virtual) CPU state changes, really easy to read if you've ever simulated a CPU before. Take the INY instruction for example. it does: increment Y register, set the Z(ero) flag/bit to whether Y is now equal to zero, set the N(egative) flat/bit to whether Y is now less than zero.
Or BNE (branch not equal): if the last instruction (hopefully a compare) set the Z(ero) flag, jump ahead t instructions. otherwise don't do anything.
Maybe notch has asserted that if he can't fit what an instruction does in ~60 characters, that instruction is doing too much
I know this sounds like nitpicking, but that mistake right there has caused many a 6502 emulators to produce erroneous results. The 6502 core's status register is resident and the flags in it are changed only when an op-code directly does so; it never "resets" arbitrarily, so proper conditionals that act on a specific status flag can actually occur far and wide between the op-code that actually affected that one specific flag.
I don't know if the behavior you describe is commonplace on other cpus, but it seems quite reasonable, if only because it greatly reduces the complexity of the emulator because not every instruction has to touch every status register. What would JMP set the Z(ero) or N(egative) status bits to anyway?
I've only briefly glanced through the dcpu-16 spec, but it doesn't seem to explicitly call Z or N by the names I've imputed, I think they're just regular registers that get used for a certain purpose sometimes.
"this _sounds_ like nitpicking"
when emulating a cpu, there's nothing but nits. pick away :)
This essentially embraces "macroing" as part of the game. Something every MMO out there has tried to fight and usually ends up losing. Makes me wonder if he will provide a way for players to sell the programs they make for in-game resources.
This aspect alone is enough to excite me, can't way to play it!
I wonder how far this concept will be extended. Will there be a full OS running on the in-game CPU, with I/O protocols to interface with the ship's systems? Will you be able to cripple your enemies' ships by writing malware, a la Independence Day?
Taken to its fullest extent, this seems like not just a game, but also a simulated world in which one can learn and practice actual engineering skills.
I wouldn't be surprised if an impromptu communication protocol (based on assigning meanings to things other ships can observe you doing) sprung up pretty quickly to allow networking. At the point that ships can communicate, it's bound to come down to needing to do it with securely-written code, or risk ship-to-ship malware.
You'd still need to develop "hardware" for the input side of that protocol, though. Unless the ship's sensors already can be programmed to detect what other ships' systems are doing.
So true, I played WoW for about a month when it came out then I thought: "Didn't I get into to programming because I didn't want to work at UPS delivering packages?"
It's better since Cataclysm, the errands are more directly, visually, and emotionally tied to saving the world (of Warcraft.)
Anyone who once thought they liked the game's single player questing aspects should spend a week with a free scroll of ressurection and experience what the game has become, because it's really awesome and fun.
