Great Exploitations

I would suggest that a "turn-based" game where objects move on grid cells might be more practical than a smooth-motion one. Probably do something like allow each player to run 60 instructions per gametick (3 per frame), and end each gametick when either 60 instructions have been executed or a "move", "turn", "fire", or "wait" instruction is executed. Some instructions could take multiple instruction cycles (counted against the 60 limit).

 

Using grid-cell-based motion (and 90-degree rotations) would make it practical for an AI to have some sense of its surroundings. For example, something like:

0 if enemy_ahead
1 fire_cannon
2 elseif space_to_right
3 rotate_right
4 elseif space_ahead
5 move_forward
6 else
7 rotate_left
8 endif
9 goto 0

I'd figure on using one byte per instruction; each line above would be a byte, and there could be maybe 32 instructions per person max. Note, btw, that the "if_enemy_ahead" would indicate whether the enemy was straight ahead during the current game step; the enemy could very well move at the same time as the shot is fired, causing the shot to miss.

 

Maybe that would be enough to be interesting, or maybe the game would be better as a single-player challenge: given a maze with certain objects to be collected and others to be avoided, write a program of a specified size to perform the required task within a specified time.

I would suggest that a "turn-based" game where objects move on grid cells might be more practical than a smooth-motion one. Probably do something like allow each player to run 60 instructions per gametick (3 per frame), and end each gametick when either 60 instructions have been executed or a "move", "turn", "fire", or "wait" instruction is executed. Some instructions could take multiple instruction cycles (counted against the 60 limit).

That's an interesting idea for a game. It becomes more of a puzzle game. It's still a "zero-player" game like RobotWar and it might have a wider appeal than what I'm proposing.

 

But widening the appeal is not necessarily the point. The turn-based approach is getting further from what RobotWar was all about. RobotWar was a real-time, smooth motion game, and you had even less information about other robots than I proposed.

 

Here's a page about RobotWar that has a downloadable manual to get an idea of what the "players" had to deal with.

 

The better robot programs used "interesting" methods to find more information about the other robots. I proposed more information by default because of the limitations of the 2600, though I'm sure I left off some key element. I'm thinking now that the following instruction:

IFNRF   8	   2	   IF enemy is within firing range then branch

Should be replaced with:

INCU   8	   1	   USER=USER+1

And the "TIME" register should then become "USER"

 

This would allow one to get more information about other robots with creative programming. Yeah, I know that just giving INCU don't seem useful, but you can assign USER to any value you want with a loop.

Could you connect two 2600s and have them fight each other? I know there have been ideas tossed around that you could connect them via the player 2 joystick port.

 

Have different programmers come up with their own AI schemes, but make them compatible so they could each take their cart, plug it into a console, and have the two consoles connect and the AI battles it out.

 

Not that this would be useful as a game or anything, but just kind of a fun experiment.

Could you connect two 2600s and have them fight each other? I know there have been ideas tossed around that you could connect them via the player 2 joystick port.

 

Have different programmers come up with their own AI schemes, but make them compatible so they could each take their cart, plug it into a console, and have the two consoles connect and the AI battles it out.

 

Not that this would be useful as a game or anything, but just kind of a fun experiment.

In theory, yes. I've talked about this in the past. The problem is always that I need two consoles and two programmable carts to actually test everything, which significantly slows the development process.

 

But Tank war would be different, in that players wouldn't need to connect two consoles - just post their tank programs and you could set up your own game to battle it out.

 

E.g., one player posts the following tank program:

 

DFF43398983988919818989DE898F9898FD9D8E

 

You enter it in the console and battle it out.

I don't know why I didn't think of this before, but this might be a good application for the SaveKey/AtariVox. The biggest limitation would be that the player would only be able to use one keypad instead of two.

I don't know why I didn't think of this before, but this might be a good application for the SaveKey/AtariVox. The biggest limitation would be that the player would only be able to use one keypad instead of two.

Good point. I'm hesitant to write anything that requires the Avox, but it would be handy to be able to save a tank's data without having to manually enter it every time.

 

Also, a keyboard controller is a good idea as an option, though it's too bad they only have 12 keys - not ideal for hexadecimal code. I suppose one could be given the option to enter octal code. It would be 25% longer but easier than trying to make the keyboard keys multi-purpose.

I suppose one could be given the option to enter octal code. It would be 25% longer but easier than trying to make the keyboard keys multi-purpose.

 

Octal's kinda messy. Moreso in many ways than hex. If things were mapped sensibly, decimal might actually not be so bad (e.g. if there was one opcode that took an operand 0-99, fourteen that took an operand 0-9, and sixteen that didn't take any operand). Note that because the first digit of each byte would have to be a "0", "1", or "2", the other keys could be used for navigation when not typing in a new opcode.

I suppose one could be given the option to enter octal code. It would be 25% longer but easier than trying to make the keyboard keys multi-purpose.

 

Octal's kinda messy. Moreso in many ways than hex. If things were mapped sensibly, decimal might actually not be so bad (e.g. if there was one opcode that took an operand 0-99, fourteen that took an operand 0-9, and sixteen that didn't take any operand). Note that because the first digit of each byte would have to be a "0", "1", or "2", the other keys could be used for navigation when not typing in a new opcode.

Well, if you convert each byte to 3 octal digits, yes, it is messy. But I was thinking more of converting to octal at the bit level so all characters could be 0-7. Anything but hex would, of course, make it impossible for those to hand-assemble their code on the fly, though it seems unlikely that anyone's going to do that. If I assume nobody's going to hand-assemble any code, I can have an assembler slip in a CRC at the end.

 

It seems to me now that the 12 keys could be based on 10-key with 8 and 9 given practical uses:

7	←	→
4	5	6
1	2	3
0	Del  End

End would check CRC, which would most likely prevent accidental ending.