Tron 'Light Cycles' AI

I've got an old LC game I wrote quite a few years ago. For mine, I went with the Space Invaders method of "They're not smart, but there are a lot of them".

I honestly didn't work all that hard on making 'em smart. I came up with three or four methods that avoided collisions while seeking out enemies, mostly based on trying to work their way towards any enemies near 'em. Then I had the smarter ones fall back to less smart methods if the smart methods got stuck.

And I threw in some randomness too. And the option of having exploding collisions which would sometimes open holes for escape (shown in the screenshot, as the dark green one now has an escape route opened up by the death of the light blue). And disintegrating trails left by dead comrades.

And it actually worked out quite well. IMHO, it's one of my better games. Try out the "several dumb enemies" method before worrying about how smart things have to be.

No way! You wrote Laser Clash, johnhattan? I got that in some '50 Solid Gold Games' pack, or something like that years ago. And upon further looking at your website, did you make all those games in that 50 pack I got? They're all listed on your site.

After digging though things I've written, I found a gem: a c bitmap maze solver. So, I used the algorithm that I created for that with modifications, which is quite simple, but works extemely well (for both light cycles and bitmap mazes). I've only beaten the computer once or twice here, and its only flaw is that it isn't agressive, but at this moment, that's beyond my skillset (and due to protocol design, I probably wouldn't have enough info).

Unless if someone has a super good suggestion, consider it case closed :)

Quote:

Original post by Ezbez No way! You wrote Laser Clash, johnhattan? I got that in some '50 Solid Gold Games' pack, or something like that years ago. And upon further looking at your website, did you make all those games in that 50 pack I got? They're all listed on your site.

Yep, they're all mine.

The Tron 2.0 lightcycle code was entirely reactive. The AI did a series of ray tests against walls, with a few simple rules like 'don't turn the same direction three times', 'when you can't see a target, wander', etc.

It wasn't perfect. For example, its turn frequency was unconstrained so it had a habit of doing very unnatural moves. Capping the turn rate made it crash too frequently, as it didn't look far enough ahead when doing initial turns. If we added a two step search on turns, it would probably have played much better.

FYI, I didn't write it. I did the rest of the AI in the game. I learned a lot from the guy who did:

- When in doubt, make a very simple prototype app if integration with a system will be hard to debug.
- Brute force, simple answers can work suprisingly well.
- Solid experiences can be built by watching for behaviors you don't want and changing the system to eliminate them - iterative design can work very well.