A few days ago a friend in my math class introduced me to the game Core Wars, and I immediately decided to port it to the calculator! Core Wars is a two player competitive game, featuring a unique type of gameplay. The two contestants must each write a program in Redcode, which is the programming language of the Core. Each program is then inserted into a section of memory called the Core. If either program stops executing, that player loses. Of course it is simple to make a program that never terminates when left on its own, the tricky part is that both programs live in the same memory (the Core) and so can influence each other. The programs must try to find their opposing program and sabotage and destroy it in order to halt it's execution. It's the greatest battle of a programmers ingenuity, as they pit their own programs to destroy others in The Core!
Redcode: The programming language of The Core is called RedCode, and is like a simplified version of assembly. There are only 18 possible instructions, but many different modifiers that make each instruction powerful. The instructions are formatted in a very specific way that is consistant for all instructions:
NAME A BNAME is the name of the instruction. The name also indicates the type of instruction, and what it does. The A and B field both hold numbers, and in general data passes from the A field into the B field. The instructions are specifically:
DAT: If any process tries to execute a DAT command, that process is killed. A and B field can be used to hold data.
MOV: Moves data from A into B
ADD: Adds A to B and stores the result into B
SUB: Subtracts A from B and stores the result into B
MUL: Multiplies A and B and stores the result into B
DIV: Divides B by A and stores the result into B
MOD: Divides B by A and stores the remainder into B
JMP: Moves program execution to location A (B is ignored)
JMZ: Jumps to location A if B is zero
JMN: Humps to location A if B is not zero
DJN: Decreases B and jumps to A if B is not zero
SPL: Starts a new process at location A
SEQ: Skips the next instruction if A and B are equal
SNE: Skips the next instruction if A and B are not equal
SLT: Skips the next instruction if A is less than B
NOP: Does nothing, guess you could use this to hold data as well.There is more than these instructions, and A/B than is just told here, and there are some good tutorials that I will
LINK to in order to help keep this post shorter, and to probably help better explain as well.
One element I do want to cover though is the SPL instruction. It says that it creates another process at location A, but what does that mean? Processes in Redcode are handled a very specific way. If you have two processes, each process will run twice as slow as if you only had one process. In other words, creating new processes does not give you any more computing power. If you had 3 processes and your opponent only has 1, then execution might look something like this:
Player 1 Process 1
Player 2 Process 1
Player 1 Process 2
Player 2 Process 1
Player 1 Process 3
Player 2 Process 1As you can see, Player 2 was able to execute 3 instructions in his one process, while each of your processes were only able to execute a single instruction.
Conclusion/Plans: Now the game hasn't been completed yet, but I do have the majority of the instructions implemented, as well as an assembler and a working interpreter. I will be updating the tutorial part of this thread as time goes on, but in the meantime feel free to visit
This tutorial as well. The syntax is slightly different since we don't have access to the same characters as they do, but I will be posting more on syntax in the future. For now I will leave you with this screenie of what the game screen will look like! It features the two program's names, as well as showing how many processes they currently have. The square in the center is a visual representation of the Core, and shows how the programs move through and modify memory. The two other squares are each programs private memory areas.
Show Posts
