by date
Plan for Mike Nelson
Plan for Mike Nelson
| Name: | Mike Nelson | ![]() |
|---|---|---|
| Date Posted: | Jul 11, 2004 | |
| Rating: | Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Mike Nelson |
Blog post
Reworking the AI a bit
The AI was working great for low speeds at which I was originally testing at. Then once I raised the speeds to more appropriate speeds for the game I found that the momentum of the bikes when going around turns was too much for the bots to handle often over correcting through the turns and creating a hobbling mess.
After some thought I rebuilt the turning AI routine to take into account the current velocity of the bike rather than just the direction of the bike and then falling back on the direction of the bike for low speeds.
After some work I got it basically working under then new system. Although they were driving very badly at the beginning. Then I had to tweak the algorithm so they could drive pretty well under this system. Mainly adjusting a few variables here and there as well as accounting for some special conditions like the need for a super tight turn where the bot can turn on grav-mode in order to hug the turn (with grav-mode on the bike sticks to the ground better), or tap the brake to slow down.
The tweaking was more complex to visualize than the previous version which basically just turned the front of the bike to the target position, which is not something that you always want to do especially around a tight turn. This was what was causing the over correction around the turns. What's more important is that the bike will move towards the goal; not that the bike is always pointed at the goal. Because of this added complexity I added some debug rendering stuff to show the current velocity of the bike as well as the direction to the target. So I could more easily see what is going on. The angle between these two vectors is important for the AI to determine the amount of turn to use.

In the shots the red lines represent the bike's current velocity and the blue line points to their immediate goal node on their path. The path is in bright green with the large green sphere as their end goal for the path. Their end goals in these shots are checkpoints.
After some time of tweaking, which is basically just watching them go around the track to see where they get caught up and finding a way to fix it. Eventually they started going around the track fairly well but they still veer off the path a bit and need to slow down in order to get back on track but at least they don't go too far off track like they used to at higher speeds.
I still haven't enabled them for boosting yet which will be another challenge. Firstly they will need to know when a good time to boost is. But one step at a time.
I also added the ability for the bots to pre-calculate their next path after their current one if they can. This is meant for the racing modes where they can pre-calc the route to the checkpoint after the current one. Before I added this there was a slight pause where the they would just stop once they got to a checkpoint while they figure out how to get to the next one. I added this visually to the editor as well. So you can see the next pre-calced path in a darker color of green.
These shots also show off the Synapse Gaming's Lighting Pack, which we just put in. It even makes my programmer art level look bare-able. Everything is much nicer looking with the cool lighting.

www.gravrally.com
After some thought I rebuilt the turning AI routine to take into account the current velocity of the bike rather than just the direction of the bike and then falling back on the direction of the bike for low speeds.
After some work I got it basically working under then new system. Although they were driving very badly at the beginning. Then I had to tweak the algorithm so they could drive pretty well under this system. Mainly adjusting a few variables here and there as well as accounting for some special conditions like the need for a super tight turn where the bot can turn on grav-mode in order to hug the turn (with grav-mode on the bike sticks to the ground better), or tap the brake to slow down.
The tweaking was more complex to visualize than the previous version which basically just turned the front of the bike to the target position, which is not something that you always want to do especially around a tight turn. This was what was causing the over correction around the turns. What's more important is that the bike will move towards the goal; not that the bike is always pointed at the goal. Because of this added complexity I added some debug rendering stuff to show the current velocity of the bike as well as the direction to the target. So I could more easily see what is going on. The angle between these two vectors is important for the AI to determine the amount of turn to use.

In the shots the red lines represent the bike's current velocity and the blue line points to their immediate goal node on their path. The path is in bright green with the large green sphere as their end goal for the path. Their end goals in these shots are checkpoints.
After some time of tweaking, which is basically just watching them go around the track to see where they get caught up and finding a way to fix it. Eventually they started going around the track fairly well but they still veer off the path a bit and need to slow down in order to get back on track but at least they don't go too far off track like they used to at higher speeds.
I still haven't enabled them for boosting yet which will be another challenge. Firstly they will need to know when a good time to boost is. But one step at a time.
I also added the ability for the bots to pre-calculate their next path after their current one if they can. This is meant for the racing modes where they can pre-calc the route to the checkpoint after the current one. Before I added this there was a slight pause where the they would just stop once they got to a checkpoint while they figure out how to get to the next one. I added this visually to the editor as well. So you can see the next pre-calced path in a darker color of green.
These shots also show off the Synapse Gaming's Lighting Pack, which we just put in. It even makes my programmer art level look bare-able. Everything is much nicer looking with the cool lighting.

www.gravrally.com
Recent Blog Posts
| List: | 07/11/04 - Plan for Mike Nelson 04/29/04 - Plan for Mike Nelson 08/05/02 - Plan for Mike Nelson 05/06/02 - Plan for Mike Nelson 03/24/02 - Plan for Mike Nelson 03/09/02 - Plan for Mike Nelson 02/27/02 - Plan for Mike Nelson 02/06/02 - Plan for Mike Nelson |
|---|
Submit your own resources!| Xavier "eXoDuS" Amado (Jul 11, 2004 at 05:27 GMT) |
| Mike Nelson (Jul 11, 2004 at 05:43 GMT) |
| Phil Carlisle (Jul 11, 2004 at 08:27 GMT) |
| Phil Carlisle (Jul 11, 2004 at 09:01 GMT) |
Ive played a few racing games without rubberbanding and they all just sucked. As soon as you piled your car even once, the AI's were so far ahead as to be uncatchable.
| Mike Nelson (Jul 11, 2004 at 16:14 GMT) |
| John Kabus (BobTheCBuilder) (Jul 11, 2004 at 16:17 GMT) |
I'm glad to see the pack is working out for you.
Your AI implementation sounds great, any chance we can see a short video of it in action?
-John
| Mike Nelson (Jul 14, 2004 at 23:27 GMT) |
Thanks for the great support with the pack.
That's a good idea. Then people could appreciate how badly they drive right now. :) I just need to figure out how to use FRAPS.
You must be a member and be logged in to either append comments or rate this resource.



Not Rated


