Combat
Comments(6) I recently read Nick Montfort and Ian Bogost’s Racing the Beam, a book about the Atari 2600, with a particular focus on how the games written for it were affected by the limitations and affordances of its rather odd hardware design. I highly recommend it to anyone who reads this blog. The Atari 2600 was my childhood console, and reading about it made me nostalgic enough to pull out a game written specifically to prey on this very nostalgia.
The original Combat was the first cartridge to be bundled with the 2600, and, along with Pong, one of the two games that the platform was specifically designed around. Apparently it was an adaptation and extension of an arcade game called Tank, although the cartridge also featured airplane modes. It was a 2D shooter that required two players — there was no expectation of computer-controlled opponents in those days. Matches lasted exactly two minutes and 16 seconds — I have no idea why they chose that specific number — at the end of which whoever got the most hits on the other guy won. Some playfields had obstacles that blocked movement and fire, others were completely open. It was all very simple and abstract: the tanks were single-colored and blocky, the walls even moreso.
But that’s not what I’m playing. I’m playing the 2001 remake, part of the wave of “classic” game remakes that hit the stores around that time. And of all the remakes I’ve played, this is probably the one that has the least to do with the game it’s based on. It’s a single-player level-based 3D shooter, where the goal on each level is to reach an exit point. The designers kept the tanks (and ditched the airplanes), they adapted the simple abstractness into a sort of Tron-like stylization, and they kept the complete lack of backstory (a laudable decision, and one made by too few of these remakes). Everything else about the original, they just ignored.
And honestly, if it had been up to me, I’d probably have made similar decisions. I suppose that Team Fortress 2 has proved that pure time-limited PvP combat is still viable, if you’re willing to spend years honing it. But this game was made with the constraint of trying to be recognizable as Combat, and that must be difficult for a modern game. Even the most formulaic adaptation possible (which this one is pretty close to being) has to add an awful lot. Heck, a formulaic adaptation has to add more than a clever one, because the original was made with a mindset so far-removed from where the game industry eventually wound up going. I’ve joked before that the general formula for the remakes churned out during this period was to just support 3D acceleration in some way and add power-ups, but the original Combat doesn’t just lack 3D and power-ups, it lacks basic concepts like levels, and lives, and an ending.
If you’re still wondering about the weird time limit in the game, I think you should convert the time to seconds and then compare with how many different values you can store in one byte. :)
Oh wait, never mind, I’m terribly sleep deprived – that would of course work out for 4:16
Actually, I think I have a better explanation. 136 seconds at 60 frames per second (the refresh rate of the CRT televisions the Atari 2600 was made for) is 8160 frames. That’s awfully close to 8192, which is 2^13. Probably the “two minutes and 16 seconds” figure is just rounded down.
And anyway, frames are a much more natural time unit for the Atari 2600 than seconds. The whole design of the system is very tightly coupled with the CRT refresh cycle.
Your description reminds me of this.
Ah, Combat….
If you really want a game totally unlike the source game, the two Battlezone games are good.
The 2:16 are the result of using 2 counters based on the 60 Hz NTSC frequency. The first counter has 6 bits, i.e. counts to 64. It overflows every 64/60 s. The second counter has 7 bits and counts to 128. In total that 8192/60 = 136,53 seconds = 2:16 minutes.
The resons for the choices are simple:
– About 64/60 is a good approximation for game steps which should occur frequently
– The 6 bit counter can be implement using a simple increment and AND #63 operation
– The overflow of the 7 bit counter can be detected by the increment as the counter value will then set/clear bit 7.
Cheers JAC!