Skip to main content
GameDev.net gamedev.net
🔒 Locked

Generating AI Data for a race game

Started by chronozphere Jan 16, 2010 at 5:48 PM 4 replies 1.9k views
Original Post
chronozphere
chronozphere
Hey guys I'm going to write the next version of my race game called TubeRunner. The game is about racing your vehicle through a tunnel circuit, picking up powerups, dodging obstackles and ramming your opponents to death. Sometimes it's possible to move your vehicle up the wall, over the ceiling and down the other side. The current version of the game doesn't have any opponents, but I want to introduce that in the next version. I also want to rewrite the whole "Racetrack system". I want to develop a tool that allows you to make racetracks quickly. One problem i'm facing is that I have to take care of the AI. The AI needs data about it's enviroment (which is a freeform world, almost no constraints). It's obvious that the geometry of the track is not usable for AI. During the creation of a race track, there might be some high level data availalbe about the track. To mention a few things: -> The spline that defines the flow of the track -> Some anchors along the spline that define the radius of the tunnel and possible the shape of a cross-section at that point. -> Some information about how to build the segment-geometry between these anchors. This could be enough data to generate the geometry (and a lowpoly representation that will be fed to the physics engine). However, I probably need additional high-level information to be able to extract usefull data for the AI. How can this be done? What kind of AI-data representation is suitable for this game and what kind of data must be provided by the user to generate this information? Thanks a bunch!
blackbird04217
blackbird04217
Well, the AI will need to know how to control the car/vehicle. Whereas the environment is some sort of tunnel, there is probably some interesting effects going on; is there a lack of gravity? Can the AI drive upside down at anytime or do they need to use momentum to carry them around?

You may need to have give the AI a 'racing line' to try following. Its obvious you won't have the same structure as a typical course, but your anchor points can have information telling the AI to aim for a certain location/speed etc. There can be multiple lines on these anchors as well if needed; RACING_LINE, POWERUP_LINE, PASSING_LINE etc...

Which brings me into the next obvious thing; the AI needs to know how to pickup and use power ups. This could prove tricky since you don't want the AI to fire at inappropriate times. If the obstacles are built into the track than the RACING_LINE information built into the anchor points should work for dodging those; however if they are dynamically placed by the player/opponents I would guess you would need an additional layer to scan and dodge obstacles when in the way, simply by turning left or right to avoid it then getting back on the line as soon as possible.

So, in short what you need for developing the level would be placing points along the anchor line that tells the AI to aim for that point, also placing any powerup information as needed. Obstacles that are static, baked into the track, should be accounted for with the anchor point lines; though as said dynamic obstacles and handling opponents would be a separate task, that I believe needs no extra information in the track.

Hope it helps.
chronozphere
chronozphere
Thank you for your reply.

Quote:

is there a lack of gravity? Can the AI drive upside down at anytime or do they need to use momentum to carry them around?


Gravity will always pull vehicles away from the center of the tunnel. I will probably define a "downside" for each part of the track. A smaller force will pull vehicles in this direction, so it still takes a bit of momentum to spin around the tunnel. It is not possible to fall through the center of the track, you will always slide back along the sides.

Adding multiple racing lines is a very nice solution.
I see some benefits:

> It's easy for the track creator to provide this information
> It can be nicely integrated into my "anchor based" approach. Just add anchors with various AI-path control points in their cross-sections.
> Flexible: Anchors can set various AI parameters at any point of the track.
> It's not hard to make a vehicle follow the line

Drawbacks:
> AI may be more predictable when it follows defined lines
> When many NPC's are racing in the same area, they might crash into eachother or get stuck, because they must use the same race lines.
> NPC must be able to find thier racing line again when they lost it.

Does anyone know solutions for these drawbacks?

I have a tendancy in thinking in "grids" (That was the approach I picked for this version). I learned that this is not a very good choice for this type of game. Especially because it's alot of work for the creator to fill the grid and because "dodging" is harder to implement.

Benefits:
> It's an easy to understand representation
> Placing powerups is easy
> More suitable for "freeform enviroments" because all free space may be used by the AI (makes AI less predictable).

Drawbacks:
> Everything must be defined on the grid (fixed distances, less flexible)
> More work for the track creator to fill the grid with information for every segment.
> Harder to make the NPC's dodge obstackles(compared to racing line approach).

I have another idea: Instead of using a few control points each cross-section, I could define lines on which control points must lie. The AI could pick a random control point from that line and race towards it. This allows NPC's to race along entire planes instead of just predefined lines.

Is there anyone who can comment on these approaches? I'd like to know what you think. =D
blackbird04217
blackbird04217
Although I say define the racing lines, it does not mean the AI will follow them exactly. In either case you will have the drawback of the AI becoming predictable after the player has played a particular track enough; tell me where this isn't the case in almost any game? I have been thinking about setting up my own experimental racing-ai systems that would remove some of the limitation, however I still believe in the end it will become predictable; after all an algorithm runs as it is told every time without fail. Give it situation A + B it will return C; always.

That said, when I said a racing line, the AI would try following that line as a guide, but they wouldn't need to be on that line at all times. The can follow it loosely which will allow for them to keep track of each other and account for the actions of the player/opponents. The drawback of finding the way back to the racing line isn't a drawback, it is designed into this sort of system- IMO. The crash avoidance will avoid the collisions as well, so you are stuck with the disadvantage that the AI become predictable; which I am sure is still a disadvantage of the grid-based solution.

You forgot that an advantage for these racing lines is to have easily defined powerup paths as well, which the AI would take when they need a powerup. Just mark a racing line as such and that will be added to your advantage list on both.

---

With the grid solution, I don't see how knowing where empty space is helps the AI become less predictable, in the end it is still an algorithm that will produce C from A and B. Admittedly I have not implemented racing AI yet, but I have done enough reading to know the normal technique is to use these racing lines, and have the AI be dynamic enough to get back on the line. Lucky for you, your AI will be enclosed in the tunnel so they can't get too far from the line in the first place; just a DotProduct will tell you whether to turn left or right. And have some form of look ahead that looks into the future depending on the vehicles speed.

Good Luck and Happy Coding.
chronozphere
chronozphere
Thank you very much. I really appreciate your input!

You convinced me. The racing line solution is definitely the best. I'll take a closer look at it. Thanks again!
BattleMetalChris
BattleMetalChris
You could also look into having it generate its own racing line by considering where the entry, apex and exit of the corner (in the simplest sense, since you're not making a hardcore simulation, these are just the points where the track starts to curve, halfway through the curve and where the track finally straightens out). This would also making it easier for the user to create their own tracks as they don't have to do the racing line themselves.

Except where two corners are very close together, the racing line touches the outside of the track at the entry and exit, and touches the inside of the track at the apex.


Or, you could use the trick rFactor uses - to create the racing line on a user-created track, the game is run in a special developer mode and the player drives a lap at racing speed according to where they think the racing line should be. The game records their path round the track and saves the waypoints generated as the racing line.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.