Previous Blog Next Blog
Prev/Next Blog
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:GarageGames Blog feedor 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

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 ResourceSubmit your own resources!

Xavier "eXoDuS" Amado   (Jul 11, 2004 at 05:27 GMT)
Very interesting stuff there Mike. I like your method, I had to implement some AI for a racing game some time ago, but it was much much more basic, had to do the whole game in 3 weeks. It 'worked', each node had a special maxSpeed setting I could use to control if the AI shouldn't try to take the next curve with a speed over that limit. It needed a bit of mission tweaking but it was ok for the purpose.

Mike Nelson   (Jul 11, 2004 at 05:43 GMT)
That's interesting. I've read that most driving AI is usually track specific in some way like what you did. I'm hoping to get away from that as much as possible since their are tag modes like Rabbit and Hunter. What you did there sounds like a good tradeoff though to help the bots to be competitive for the race modes. Maybe I can calc some sort of guestimate for things like maxSpeed on the fly or pre-calc it...

Phil Carlisle   (Jul 11, 2004 at 08:27 GMT)
Interesting work Mike.

Phil Carlisle   (Jul 11, 2004 at 09:01 GMT)
Hey Mike, just out of interest, are you going to use some kind of rubber banding implementation to stop the bikes from just roaring off? (for those that dont know, rubber banding involves slowing the other bikes a bit if they are too far ahead of the player, or speeding them up if they are too far behind).

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)
Phil, we probably would do something like that. We haven't thought that out yet. I think I need to get the AI to that point first and see how it plays.

John Kabus (BobTheCBuilder)   (Jul 11, 2004 at 16:17 GMT)
Hi Mike,

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)
John,

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.