Tron 'Light Cycles' AI
Author
I've just finished writing a networked Tron 'Light Cycles' server/client. For those not familiar, Light Cycles is a classic arcade game similar to "Snake", except your 'tail' does not follow you (always grows) and the object is to simply force other players into hitting your tail or the wall.
Everything is working well, and since the client is abstracted enough that it is fairly simple, I've decided to write an AI bot. However, I am at a loss for what algo I should use.
The light paths are simply stored on a boolean[][] grid for the AI client, so this and the AI player's current direction (north, east, south, or west) are all it can use in making the decision as to which way to turn.
Can anyone suggest an algo for finding which direction the AI bike should turn?
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.
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.
Author
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 :)
Unless if someone has a super good suggestion, consider it case closed :)
In the clone version of this game that I played once...
The AI strategy was to wall itself off within a large portion of the map separate from everyone else
then do a very tight spiral towards the center of his own 'territory'
Generally since the player does not have the same instantaneous reaction time as the bot, he kills himself on his own, while the bot happily spirals away to his own (delayed) doom.
I think that strategy sucked.
the bot is essentially 'cheating'; winning by virtue of infallible reaction/turning speed. And is not intereacting with the player At All-You might as well leave the player in an empty arena with no bots; he dies the same way when he gets low on space and kills himself.
This does bring up the question though, of what are some good strategies for this game?
seeing a bot pull up alongside you, try to get ahead then cut across your path to block you would be nice to see....
having it take that blocking strategy to a higher level to actually 'herd' the player towards the arena wall and limit his space would be even nicer...
This brings up a problem though... if you chase an enemy, you do not want to be in his 'blind spot' because he can turn and cut you off
you want to be slightly in front of him to do the same back... but how do you arrive at such a location?
approaching someone implies chasing him... and chasing means you are behind him, which is a very bad spot to be in...
the dynamic here just seems... annoying
-walling yourself off and spiraling towards your doom slower than your enemy does to himself seems to be the best strategy... but obviously terrible for gameplay
maybe you could add in other factors like speed versus turning ability?
The AI strategy was to wall itself off within a large portion of the map separate from everyone else
then do a very tight spiral towards the center of his own 'territory'
Generally since the player does not have the same instantaneous reaction time as the bot, he kills himself on his own, while the bot happily spirals away to his own (delayed) doom.
I think that strategy sucked.
the bot is essentially 'cheating'; winning by virtue of infallible reaction/turning speed. And is not intereacting with the player At All-You might as well leave the player in an empty arena with no bots; he dies the same way when he gets low on space and kills himself.
This does bring up the question though, of what are some good strategies for this game?
seeing a bot pull up alongside you, try to get ahead then cut across your path to block you would be nice to see....
having it take that blocking strategy to a higher level to actually 'herd' the player towards the arena wall and limit his space would be even nicer...
This brings up a problem though... if you chase an enemy, you do not want to be in his 'blind spot' because he can turn and cut you off
you want to be slightly in front of him to do the same back... but how do you arrive at such a location?
approaching someone implies chasing him... and chasing means you are behind him, which is a very bad spot to be in...
the dynamic here just seems... annoying
-walling yourself off and spiraling towards your doom slower than your enemy does to himself seems to be the best strategy... but obviously terrible for gameplay
maybe you could add in other factors like speed versus turning ability?
Quote:Original post by EzbezYep, they're all mine.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement