I can't wait.
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.
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.
Not sure how that would affect the lag, though.
Sounds like fun.
If he sticks with that, there are good few cross dev. tools. (even C ISTR)
ram[PC++0xfff]&0xff
((ram[PC++0xfff]&0xff)|((ram[PC++0xfff]&0xff)<<8))
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.
int pos=(ram[PC++&0xffff]+X)&0xff; byte v=ram[(ram[pos]&0xff)|
Code generation doesn't need to be heavyweight.
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.
0x0000
0x0001
0x0002
...
That help?
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'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 :)
CPUBuilder is most likely a class with a single method:
buildCPU()
{
return new CPU();
}This aspect alone is enough to excite me, can't way to play it!
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.
Should be really fun to see where this goes.
If there's a living designer who could pull it off then my money would be on notch.
It should have been called World of Errands.
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.