Of course the reaction time would fall under the "super control" category. I may have mentioned it somewhere in the thread already, but I know it is included in my document and covered already. I am almost finished writing this document, (one hour or so), for the general public. And will begin researching and writing the specification part of the document: which will be more technical probably including math, code and good stuff like that. Heh, boring for the average person.
Of course the reaction time would fall under the "super control" category. I may have mentioned it somewhere in the thread already, but I know it is included in my document and covered already. I am almost finished writing this document, (one hour or so), for the general public. And will begin researching and writing the specification part of the document: which will be more technical probably including math, code and good stuff like that. Heh, boring for the average person.
Then you have your environment, but no physics, track or whatever that you can actually test your stuff on. Collecting these data points, however that is achieved, is also a really tiny amount of work compared to figuring out even the simplest algorithms for the AI to use and writing your own graphics/physics engine.
Using LFS also has the added benefit that if you succeed, you can share your AI as a program for others to actually use, even if it's not perfect.
Then just place these reference points on your virtual map manually? It's just like overlaying a paper on the LFS track and manually marking wherever points of interest are. You don't have to actually have access to the polygons of the track to use certain objects as reference points which would require a completely own engine tailored for exactly this and going kinda beyond the presumingly abstract nature of your AI.
So? That's in no contradiction to what I suggest in regards to using LFS.
From my understanding you'd write:
The AI
- Has a field of view containing various reference points of whatever nature
- Has any additional input you see fit to use (speed, rpm, tyre sound - stuff you can see on the dashboard or hear)
- Has lots of complicated algorithms making sense of the reference points it sees
- Has a memory to store experiences ("no, braking 10m in front of the cone is not enough to make the corner!")
The LFS <> AI interface
- Has the virtual track map with all reference points (of whatever nature) stored in the LFS coordinate system
- Has an InSim component that gets the current car position on the virtual track map
- Uses the current car position, direction vector and field of view to compute what reference points are visible to The AI and feeds it this data in an abstract form (a "cone" is visible 10 metres ahead, 15° left and 6° down)
- Has an OutSim component that feeds the AI any additional info
- Has a rudimentary sound emulator to figure out what sounds the tyres would make at the moment (or actually intercept and analyse sound output?) to send to The AI. This is no harder than if you have to write your own physics engine/environment.
If you do it like that, then your AI is completely independent of what simulator you use, provided the physics are sufficiently similar (kinda the point when you want to make a realistic sim) and that you can write an interface that can feed the required data to your AI.
Personally (as a non-programmer) I think it's something worth pursuing. It might be overly complicated, it might use a lot of CPU time, but I would have thought as a complex learning experiment it is the right way to go. Sure, it would be easier and quicker to make a very basic cheating AI and then add algorithms that make it seem like it doesn't cheat and behaves realistically, but that is curing the symptom rather than the cause.
Heh, curing the cause. The symptom: the AI does not behave human. The cause: the AI is not human. The cure: make the AI human.
Making the AI behave more human-like by changing the way it acquires input is still curing the symptoms, not the cause.
Having access to abstract things like reference points of various natures is still "cheating," just a different form of cheating.
Making the AI behave more human-like by changing the way it acquires input is still curing the symptoms, not the cause.
Having access to abstract things like reference points of various natures is still "cheating," just a different form of cheating.
Why? I use reference points. I know I'll start braking when my front wheel goes past a darker mark (example from Mallory Park), or when a distant tree lines up with a corner marker post (example from Snetterton), or as I pass under a 100m board (Rockingham), or between two red parts of a barrier (Silverstone), plus/minus a bit depending on conditions, tyre temps, distance from my line etc. Same with throttle points, or turn in points. When I've learnt a circuit these become unconsious things, perhaps based on image 'snapshots' of what the scene looks like when I've braked before, but I'd wager that whatever the method is, my brain nows where to brake (or whatever) ultimately based on the reference data.
It strikes me as using references, combined with input from other factors, is vastly more human-like.
It strikes me as using references, combined with input from other factors, is vastly more human-like.
Oh of course you do. But you also plot a certain line on the track that you know (from experience) is the best line to follow (Quote: "[...] distance from my line [...]"). By that I don't mean you visually imagine the ideal line as if you pressed '4' in LFS, but you subconsciously know this line and you follow it lap after lap to the best of your capabilities. Since you can't just visually plot the line with colours indicating when to brake/accelerate, you use reference points on the track to give you hints when to do what (brake, turn in, etc.). Extensive experience also lets you drive the track when you're off the line (due to an obstacle or driving error) and you know from the learned car behaviour what the most efficient path to return to the line is.
So you do have an internal line you know to follow, why can't the AI have one? If you do give the AI this line (since a human has it in his mind) then all you use the reference points for is storing the data of when to engage what input to make the car follow that line. Storing that abstractly as "start braking as soon as the cone leaves my field of view" or "the data on my ideal line says start braking now" is just substituting one way to encode data for another.
So you do have an internal line you know to follow, why can't the AI have one? If you do give the AI this line (since a human has it in his mind) then all you use the reference points for is storing the data of when to engage what input to make the car follow that line. Storing that abstractly as "start braking as soon as the cone leaves my field of view" or "the data on my ideal line says start braking now" is just substituting one way to encode data for another.
Thanks much for the support and it seems you understood exactly where I am coming from with this project, if I decide to do it. Which seems likely considering the effort I've went into explaining things both on this thread and the document I am writing...
I do *think* that this is not what I am after actually. I haven't truly come with the correct symptom, still writing and thinking about that to be honest. But I think my symptom is: The AI cheats.
By the way, its not only changing what the AI receives for input, but how the AI reacts with the input. In what form is the AI cheating if it see's the cone, that the player sees. Sure it sees it in mathematical values. But there is no way around that. It is seeing the data as an estimation. Which is how the player interprets it. So if this is still somehow cheating please do let me know, I would be interested as I am trying to remove that.
The two need to be linked. If I'm slow, and someone comes along who is quicker using a different line, then I have to work out why. It might be my line, formed from the first few laps by reference points, is wrong. So I use new reference points to plot a new 'line', and give it a try. Plus you're always experimenting a bit anyway - on the last lap it wasn't very nice braking that late on the that line, but maybe if I angle the car this way...
Whilst I have no problem with the AI 'knowing' a line, it should be entirely self determined, and constantly updated based on reference points and performance. Very basic rules, such as "slow in, fast out", or "entry, apex, exit" can be applied so the AI forms the initial line (e.g. on my first lap anywhere, chances are I get within 5% of the final racing line all around the track. Probably closer).
Even the 'line' I know, is probably more accurately described as reference points anyway - "I know I should be parallel to the white line and 50cm away from it" or "smooth curve, missing the drain cover by 10cm". It's still a join the dots exercise rather than a mental 'line', and those dots are reference points.
How this works in terms of programming I have no idea though. I can only discuss, in very vague terms, the human side of it.
Whilst I have no problem with the AI 'knowing' a line, it should be entirely self determined, and constantly updated based on reference points and performance. Very basic rules, such as "slow in, fast out", or "entry, apex, exit" can be applied so the AI forms the initial line (e.g. on my first lap anywhere, chances are I get within 5% of the final racing line all around the track. Probably closer).
Even the 'line' I know, is probably more accurately described as reference points anyway - "I know I should be parallel to the white line and 50cm away from it" or "smooth curve, missing the drain cover by 10cm". It's still a join the dots exercise rather than a mental 'line', and those dots are reference points.
How this works in terms of programming I have no idea though. I can only discuss, in very vague terms, the human side of it.
BINGO!
But not quite there. I think this will help, the point is maybe the AI gets this "best line" as reference points as well. Just for the knowledge of, that is where I would be under ideal circumstances... However, the ideal line shouldn't contain information about braking/throttle and stuff - that is where I feel the AI does not make "observation mistakes" and "estimations". Sure we know the best line because our brain knows to take a corner wide to keep moving fast. Or to take a corner with a late apex because the long stretch after it. But that line is not our visual cue for braking, accelerating or turning - unless you press 4 in LFS and watch it.
------
Umm I missed a post earlier, just before tristancliffe's first. And it wouldn't work: I don't have line of site using the LFS data... There are hills and cars. The cars I could kinda work in. But it was the last comment on reading the sound data of the tires that got me. You write me some code that opens the mic, records LFS at that moment in time, processes the data and gives me a value stating: UNDER LIMIT, NEAR LIMIT, AT LIMIT and OVER LIMIT from that : / Cause that's scary to me trying to get that info from LFS.
I don't see how sharing it would be a benifit to anyone though as it wouldn't contol an AI driver.
Its the programming side that is gonna make me wonder about following through. But from a human standpoint I have a question from you.
On a small track, FE1, SO3, AS1 and such, how many reference points would you think you know of. I mean, in general, for the ideal situation, no car around you to obstruct view.
My guess on a small circuit is probably 75 to 80 points, but I could be wrong.
I have been thinking of how to do these reference points and I thought of something based on what you've written above somewhere.
My original thought had "Detailed Points" close to an action, something that you look at. "General Points" which are far away, you use your peripheral vision on these usually, but you use them during points in time that you can't see the Detailed Point. And then I had "Track Points" the left and right edges of the track, which are only meant as guides. I want to make the AI so that these points are only meant to see if it will hit a wall, or to know if they can move left/right more. But I don't see the left/right points as detailed in anyway. If a curb starts near a turn that would be a detailed point, even if it is near the track point.
But you can easily extrapolate that data from the track points you have (and you kinda have to have them). It would probably the job of the LFS <> AI interface to do this Z-culling for you, though. Just use each of the two opposing track points as height reference and you can work out the track contours from that. Not 100% accurate but in practice you're not going to encounter weird hills that obscure some points but not others all too often.
The remark about using actual sound output was just a jab at just how generic and realistic you want to go with this. What I'd actually do is read the tyre loads / slip angles / slip ratios and guess from there what sound the tyres would make, i.e. I give you a value of loudness and pitch. Your AI then decides from learned experience what values correspond to what "X LIMIT."
How so? Set up a separate PC with the AI that joins you in a LAN game. Whoop, there is your "AI" driver.
You know, this might actually be where we differ. From that comment it seems you're thinking about this whole idea very abstractly, more from a conceptual point of view, whereas I tend to slip directly to concrete programmatic solutions (not saying that either is better, just that we apparently tackle this topic from a different point of view).
Blimey!
I don't know... You're on a straight - this is easy. All you want to do is end up on the outside of the track. The first reference point or marker will be the braking zone. You'll see it in the distance (or, if you can't see it, you'll know what is near it and how quickly it's approaching), and when you reach it you'll hit the brakes. Do you hit them as hard as possible, or is it better to brake early and less hard?
Maybe there is a defined turn marker, or maybe it's a corner where you just gradually feed it in without using a turn marker.
There will be some point at which you come off the brakes - whether it's a marker or just feel (perhaps originally based on a marker, or just something built from trial and error)) I don't know.
Usually you'll have a point (or area
) that you use as an apex point, and your throttle application point will be based on that, probably. You might want to hit the power at the apex, just before it, or just after it. Experience will tell you whether you can nail the throttle or have to feed it in gradually.
Do you have an exit point? I'd say probably not - you exit where the car exits. If you don't get near the outside of the curve then you're either over-turning the car (scrubbing off speed), or not carrying enough speed. One should rarely have to drive to the exit of the corner - the car should want to go there by itself, so the entry and throttle application points define the exit more than a specific marker.
And then you go in a straight line until the next corner (generally).
So what's that? 3? 5? 10? 50 points per turn? When you learn a track you choose a conservative braking point. Very quickly that moves towards the corner, unless you're a muppet. Gradually you stop relying on 'a point', but 'the scene' as a whole. Experience, parallax, and some clever brain activity means that, eventually, I know when I can brake when I'm off line (assuming the track isn't especially marbley or greasy off line). In a racing situation you need this, because you'll quickly find yourself entering a corner on a line you've never even dreamt of using, yet you'll still brake within a couple of meters of "The Limit" (less if you're talented, but I can't talk from that point of view).
It's very complex when you think of it. I definitely use reference points at times. Some I still use, some I only consiously use for the first couple of laps. It's very hard to determine what I'm doing subconsiously, because it's subconsious
I don't know... You're on a straight - this is easy. All you want to do is end up on the outside of the track. The first reference point or marker will be the braking zone. You'll see it in the distance (or, if you can't see it, you'll know what is near it and how quickly it's approaching), and when you reach it you'll hit the brakes. Do you hit them as hard as possible, or is it better to brake early and less hard?
Maybe there is a defined turn marker, or maybe it's a corner where you just gradually feed it in without using a turn marker.
There will be some point at which you come off the brakes - whether it's a marker or just feel (perhaps originally based on a marker, or just something built from trial and error)) I don't know.
Usually you'll have a point (or area
) that you use as an apex point, and your throttle application point will be based on that, probably. You might want to hit the power at the apex, just before it, or just after it. Experience will tell you whether you can nail the throttle or have to feed it in gradually.Do you have an exit point? I'd say probably not - you exit where the car exits. If you don't get near the outside of the curve then you're either over-turning the car (scrubbing off speed), or not carrying enough speed. One should rarely have to drive to the exit of the corner - the car should want to go there by itself, so the entry and throttle application points define the exit more than a specific marker.
And then you go in a straight line until the next corner (generally).
So what's that? 3? 5? 10? 50 points per turn? When you learn a track you choose a conservative braking point. Very quickly that moves towards the corner, unless you're a muppet. Gradually you stop relying on 'a point', but 'the scene' as a whole. Experience, parallax, and some clever brain activity means that, eventually, I know when I can brake when I'm off line (assuming the track isn't especially marbley or greasy off line). In a racing situation you need this, because you'll quickly find yourself entering a corner on a line you've never even dreamt of using, yet you'll still brake within a couple of meters of "The Limit" (less if you're talented, but I can't talk from that point of view).
It's very complex when you think of it. I definitely use reference points at times. Some I still use, some I only consiously use for the first couple of laps. It's very hard to determine what I'm doing subconsiously, because it's subconsious
I never thought about someone using it as a LAN AI, though that is kinda interesting I still don't know if I wanna try facing all the challenges of integration with LFS, like I said way above, making it for LFS would likely be as challenging as making it work for a simplistic environment.
Yes, I am trying to keep it conceptual still. Like I said I wanna try new, not the old proven techniques. And its more natural to try new from the human perspective: especially since I am trying to eliminate cheats/tricks that racing AI has developed over the years.
My objective is not currently for an optimized algorithm for use in racing games.
Ok guys, for those that are interested which a few obviously are but not as many as I was thinking, must be the programmer section? Should I ask to move to Off-topic? As my first post says I didn't know where I should put it.
Anyways... For those interested I have attached the PDF document. Its a little lengthy but it describes the thoughts I've been having. If you've read the thread you might find a few things but likely know a lot of what is in it. This is not a technical read, and is actual meant for the general public. I am now starting on the second portion of the document which will go into greater detail of the technical requirements and math of the project. I expect that this will answer my question; Whether I should attempt this project or not.
Please post any thoughts you have on how you think AI gets advantages over the player, and anything related.
Anyways... For those interested I have attached the PDF document. Its a little lengthy but it describes the thoughts I've been having. If you've read the thread you might find a few things but likely know a lot of what is in it. This is not a technical read, and is actual meant for the general public. I am now starting on the second portion of the document which will go into greater detail of the technical requirements and math of the project. I expect that this will answer my question; Whether I should attempt this project or not.
Please post any thoughts you have on how you think AI gets advantages over the player, and anything related.
Maybe the problem is that you started this thread too early. Personally I'm more interested in actual technical aspects (that you haven't worked out yet), not so much in the "general public" riff-raff.
So far all that was stated were a few quite obvious 'faults' of current AI implementations (half of which don't even apply to LFS) and your announcement that you want to use reference points instead of cheating to make the AI go round, all still very theoretical. I'd have preferred if you would've had at least a rudimentary look at the technical side of things before posting this, but oh well, let's see what you can come up with.
That you don't want to use LFS as tool for this is also kind of a bummer, since it would've given this project a little bit more... substance, though that might not be the word I'm looking for.
From a purely technical aspect I'd have to admit your choice of programming language would actually be the biggest hindrance for me. I guess with some effort I could start finding my way around C++ again, but alas, I am lazy and C# makes many basic and not so basic things a lot easier to deal with. AI programming / maths is hard enough, I'd rather not struggle with the language, too.
Heh, I understand. And I have put a lot of thought in the few days that I've been thinking of the idea. I wouldn't mind using LFS if two things were to happen: Someone wrote all the stuff that dealt with it. IE: If I had the information my sensors would need available to me, and the AI outputs would automatically work when I would be fine. But I see too many hurdles with using AI to do it, hurdles that wouldn't be their by just writing a small 2D app or something similar.
As far as the language, sorry for my choice. It's just I know C++ in and out. I know a little C# as well, but dealing with it sometimes annoys me. I like the freedom, I guess.
As far as the technical stuff, I have some of it in my head. The biggest hurdle is converting the reference points into usable data. I may need to add an 'ideal line' that is only useful to tell the AI that this is what you want to be AIMING at. Although I have a feeling that then the AI doesn't use the reference points and the idea is back to square one. I know there must be a solution using only the edges of the track, and maybe the AI sensor will always find the 4 nearest track points. 2 for left and 2 for right, and use this to guess at where they should be going if their reference points are not telling them any information...
The technical design of the reference point has not been done yet either. But I know there will be different types holding different things. The most basic holds a direction and length. Seperated only for a more optimized system. The detailed points would have some sort of memory or instructions attached, which the AI could change when they feel something went better.
As far as the language, sorry for my choice. It's just I know C++ in and out. I know a little C# as well, but dealing with it sometimes annoys me. I like the freedom, I guess.
As far as the technical stuff, I have some of it in my head. The biggest hurdle is converting the reference points into usable data. I may need to add an 'ideal line' that is only useful to tell the AI that this is what you want to be AIMING at. Although I have a feeling that then the AI doesn't use the reference points and the idea is back to square one. I know there must be a solution using only the edges of the track, and maybe the AI sensor will always find the 4 nearest track points. 2 for left and 2 for right, and use this to guess at where they should be going if their reference points are not telling them any information...
The technical design of the reference point has not been done yet either. But I know there will be different types holding different things. The most basic holds a direction and length. Seperated only for a more optimized system. The detailed points would have some sort of memory or instructions attached, which the AI could change when they feel something went better.
Honestly, you'd probably pick up C# pretty easily. Many to all of the same concepts apply, but you get some things that are simplified or work different than you'd expect. You'd need a bit of adjustment to figure it out.
Also, if you're using LFS, wouldn't you be able to use OutSim (provided that works on AI cars), to gather some more details regarding the current forces acting on the vehicle. I imagine you've definitely thought of this, but covering a few more bases.
Also, something that might be of interest - http://cig.dei.polimi.it/?cat=16 / http://torcs.sourceforge.net/i ... p;file=article&sid=72
It uses TORCS, but some of the vehicles show a good sense of what you're trying to achieve, although it is using an arcade racer (and some of the results aren't very spectacular).
I'm probably not too useful for help other than if you need to fake it (
), but i do have a few brains occasionally.
Also, if you're using LFS, wouldn't you be able to use OutSim (provided that works on AI cars), to gather some more details regarding the current forces acting on the vehicle. I imagine you've definitely thought of this, but covering a few more bases.
Also, something that might be of interest - http://cig.dei.polimi.it/?cat=16 / http://torcs.sourceforge.net/i ... p;file=article&sid=72
It uses TORCS, but some of the vehicles show a good sense of what you're trying to achieve, although it is using an arcade racer (and some of the results aren't very spectacular).
I'm probably not too useful for help other than if you need to fake it (
), but i do have a few brains occasionally.I've seen TORCS but to me it didn't seem all that active - I could be proven wrong.
I haven't seen the other, which I am looking into because it seems to me a lot more active.
I haven't seen the other, which I am looking into because it seems to me a lot more active.
Those "AI's" are implemented in TORCS, and there's videos out there that drive like humans kinda do. E.G. Running wide in a corner, the next lap this will be rectified, overtaking drivers, accident recovery, etc. Some of the examples aren't as good as others, but seem to be similar to what you're planning.
I'm working since 2 months in a project called KRR.
It is a insim that auto detect the other cars, analyze them, change the pit strategy automaticaly, speak for give me info without read it in the chat, detect police near if i'm in a cruise,... and another lots of things.
I'm looking for improve it with auto-driving like the LFS IA, but that i can change the driving line if i found a better way for go faster, but I'm not working in it now.
Sorry for the bad english
It is a insim that auto detect the other cars, analyze them, change the pit strategy automaticaly, speak for give me info without read it in the chat, detect police near if i'm in a cruise,... and another lots of things.
I'm looking for improve it with auto-driving like the LFS IA, but that i can change the driving line if i found a better way for go faster, but I'm not working in it now.
Sorry for the bad english
First off, I'm sorry, I did not read all of the posts in this thread, just to much data and not enough time. Anyway, here's my addition.
When I am racing, I posistion my car based of these points:
Your AI MUST learn, it just like a driver is going to make mistakes, it must learn from them for it to be any good.
Many times, it's going to take a turn wrong, just because it thought it could go that fast, it was wrong.
Hell, it might even discover that it can go faster though a turn by a freak accident, such a another car touching it that give it a better line, it should learn from that too!
Amp88 also came up with a great point about how much downforce levels effect the car.
So if I go faster though the turn, with more down force will the turn be successful at that speed?
So, here is my question to you, what reference points are you going to use, because the human mind uses much more then just breaking markers.
For the non programers that want to help, think about what you use to help you get around the track, what you take into account when going down a stright to taken simple turn, to taking a turn with elavation change and taking a turn with a bank. All of this information will help him, just because your not a programmer, does not mean that you can't help. He is talking about the human element, and thus each races input is invalueable.
When I am racing, I posistion my car based of these points:
- Width of the Track vs. Width of the Car. (How much room do I have?)
- Tightness of Turn vs. Width of the Car + Angle of Attack. (Do I fit at this angle?)
- Can I do something to make my angle of attack work so I can go faster though this turn?
- Am I driving within the limit of my grip, does it matter for this turn?
- Can I get a faster avg speed if I kill my tires though this turn?
- What is the cost vs beifit of using my tires for this turn vs the rest of the track.
- Current tilt, yaw and pitch of my car.
- Current available grip (from sound, and visually from my posision on track)
- Current throttle, brake and clutch posision combined with each other.
- I can feel (see and hear, because I'm a mouser) when my car bottoms out, your AI should know this too.
Your AI MUST learn, it just like a driver is going to make mistakes, it must learn from them for it to be any good.
Many times, it's going to take a turn wrong, just because it thought it could go that fast, it was wrong.
Hell, it might even discover that it can go faster though a turn by a freak accident, such a another car touching it that give it a better line, it should learn from that too!
Amp88 also came up with a great point about how much downforce levels effect the car.
So if I go faster though the turn, with more down force will the turn be successful at that speed?
So, here is my question to you, what reference points are you going to use, because the human mind uses much more then just breaking markers.
For the non programers that want to help, think about what you use to help you get around the track, what you take into account when going down a stright to taken simple turn, to taking a turn with elavation change and taking a turn with a bank. All of this information will help him, just because your not a programmer, does not mean that you can't help. He is talking about the human element, and thus each races input is invalueable.
I would like to know more about what you mean from this statement. Sure I understand it to a point but I don't think the human uses anything more than reference points; I don't know if you read the part where we do use different type of ref points in different ways, but reference points is the only information about the track that we use.
You are completely correct, the human has 'hundreds' of points along the left, and right side of the track. And these points are mostly used only to know how wide you can go without hitting grass; where to pass a car, and as you said the angle of attack around a specific corner. But all in all these are still reference points, and in the human mind only used by estimation. It is this estimation that causes mistakes, and also allows the car to regain control by detecting the mistake.
--------
You did add an entire element that I overlooked during my investigation into this though; resource management. You are completely correct that during a race, especially a long race, the driver should be aware of their tires, fuel and other resources that have wear.
I also overlooked, in a sense, the aerodynamics of some cars. I am trying to remove as much of the physics knowledge from the AI. I would like to believe simply 'knowing' an estimation of how much traction each tire has would be enough for the AI driver. I will have to consider a way to keep the AI detached from the physics system while gaining a basic understanding of a car with downforce - that could be tricky.
How does a human mind read how much downforce is on the car at a given time? How do we automatically cope with coming behind a car and losing the downforce?
There are a few questions anyone can answer, though it will be hard because it is probably mostly subconsciously.
I'm basically asking, what input from the 'world' are you going to use. I might not know my actual X and Y in the track, but I know where I'm relativity speaking. If I was an AI, I would know where I am. So I would take that into consideration, as well as knowing what turns are coming up next so I can get the best line though all of the turns. Also, forget racing lines ... They don't count for me, and your AI might just find a better one, so don't use the one in game. I use breaking points only to fine tune where I press the break, I can get around a turn without one just fine, I might be slower, but I'm still getting around it.
Here's an experiment, what's your favorite track? BL1? Go to BL1 and just drive at a pedestrian pace and see if you can do a whole lap. How much far do you get, I think you might be surprised ... I bet you could do better in real life feeling the tilt and pitch of the car knowing where that is. Your AI is going to 'feel' more then the real user is going to 'feel'.
And you can emulate estimation of the mind in other ways. Build them to be perfect, you can add imperfection later.
That's a great point. I 'feel' the areo grip from the car by comparing it to the mechanical grip I feel from a car without wings, or by taking off some wing, going around a turn, putting on some wing going around a turn and seeing how much faster I can go. Being a driver is much more then just knowing where to break, it's also knowing how to setup your car. Knowing what you can do to go faster, but changing the setup of your car.
Some times I don't cope with the down force loss, I don't care, I know it does not matter some times and I go with it. So long as I don't feel that the down force loss is going to cause me to lose control or go off the track. But that's animation, your AI is going have to think also where it's going to be, not just where it's been and where it is.
I actually meant that in more then just the way you took it. I see the total grip of the tire at any given time as a resource, the total grip vs the amount of grip used to accelerate, break, turn. So, I can use the tires grip to turn, and accelerate but I can do either of that to it's maximum because I'm using the grip to do two things at once. Some times, it's for the best, some times it's not. Try thinking about the balance of the car as a resource, you can stabilize a car around a turn by adding break along with with turning. That's alot more abstract then I'd like it to be because I can't tell you why this works.
To really make a good AI, you need to read some books about the theory of driving. Good drivers will make a good AI.
E: @Dygear: I don't think he necessarily wants to write the best/fastest AI, but simply an AI that uses a more human-like approach of driving and decision making, no matter whether that will result in a more believable / competitive / human-like AI or not. My approach would certainly be a different one.
Warning, wall of text incoming!
I don't think the human mind does that at all. Downforce just makes the car more grippy, resulting in a different baseline knowledge (see below) of how to drive the car - having another car in front is a special condition that just translates into "watch out! less grip / more understeer" and you compensate for that by driving slower / braking earlier / finding a line that is not directly behind the car. Just how and how much you compensate for less grip comes down to how much experience you have with your car's behaviour in that situation.
How much grip a car has in absolute terms at a certain point is not really a concern for the driver anyway - you're never actively calculating grip during a race and deciding how fast you can possibly go through a corner. Rather, you have a baseline knowledge of what corner can be taken at which gear (= speed) using which motions (= braking motions, turn-in motions, throttle motions) under normal conditions. By motions I literally mean the motions you perform - they are stored in your muscle memory and can be accessed very quickly without requiring you to think.
This knowledge is built up by practice and slowly approaching the limits starting from a rough but safe initial guess (and learning from following competitors or watching replays, etc.). So what you end up with is a set of inputs + expected results that need to be started at a certain time.
Any special conditions are then accounted for afterwards, for example by having altered "baseline knowledge sets" for different but frequently occurring situations. Having less grip until the tyres are warmed up, approaching T1 after the race start, driving on a wet track or overtaking a competitor are probably situations that are worth learning a different set of motions for as they happen relatively often.
Conditions you don't have a learned set of motions for (due to them occurring very infrequently or if you simply don't have much experience yet) have to be compensated differently, either by educated guessing or pure guessing. These generally require you to actively use your brain and are thus much slower than if you had a stored set of motions ready for them.
The educated guess comes into play when you have specific pre-existing knowledge about the nature of the situation or you can link the situation to similar situations that you know how to handle. Say for example your rear tyres are overheated. Or dirty. Or your rear suspension is damaged. You might not exactly know what actually happened and you have no idea how much grip you have at the rear tyres (other than less than usual) so you can't simply "play back" the motions you're usually going through anymore, but you do know that using the throttle less aggressively and softening your steering inputs (less sharp and aggressive cornering) will probably help in this rear grip = lower situation. Just how much you have to alter your usual driving by these rules comes then down to trial & error, but basically you increase the strength/influence of the input alteration until your error-correction trigger rate (see below) goes down to an acceptable level, while constantly going back more and more to your usual unaltered behaviour to test if the special condition has improved or gone away.
A pure guess is, besides being the worst, a kind of guess you have to take when you have no reference or prior knowledge of how to handle a situation correctly. For the most part this is probably the simple reaction of reducing speed and/or taking evasive action. By gaining more experience you reduce the amount of situations where you have to resort to this kind of guessing.
During a race you also have a secondary set of motions ready, not used for specific parts of the track but for general error corrections. It's basically a set of triggers running in the background that auto-launch corrective motions in certain situations.
For example: trigger condition > error > actions to resolve
- Car turns unexpectedly/without steering input > oversteer > countersteer
- Front tyre screech under braking > front lockup > reduce brake strength temporarily
- Rear starts coming around under braking in RWD car > rear lockup > countersteer + apply throttle / reduce brake strength
- Car doesn't turn enough under braking > braking understeer > reduce brake strength and wheel turn
- Car doesn't turn enough under throttle > throttle understeer > reduce throttle and wheel turn
- Car turns too much under throttle > throttle oversteer > countersteer + reduce throttle
- etc.
Of course these are very general and might not be correct under all situations (= trigger condition not refined enough), but they simply represent the learned/automatic reactions to correct various errors that occur due to whatever reason. Of course these can also be more complex / abstract / meta-triggers, like "rate of oversteer corrections too high" (something wrong with rear wheels? overheated?) or "motion with high success rate starts failing too often" (something wrong with the car?), etc.
Basically I'd say for driving around a track you're using a set of learned and sometimes deliberate motions, using triggers (distance to-/position of a reference point can also be a trigger) to determine when to start or stop the motion.
I guess the point I'm trying to make is that you try to avoid as many active calculations - as much thinking - as possible and rather follow learned motions.
Or maybe an even simpler, more abstract process:
Warning, wall of text incoming!
I don't think the human mind does that at all. Downforce just makes the car more grippy, resulting in a different baseline knowledge (see below) of how to drive the car - having another car in front is a special condition that just translates into "watch out! less grip / more understeer" and you compensate for that by driving slower / braking earlier / finding a line that is not directly behind the car. Just how and how much you compensate for less grip comes down to how much experience you have with your car's behaviour in that situation.
How much grip a car has in absolute terms at a certain point is not really a concern for the driver anyway - you're never actively calculating grip during a race and deciding how fast you can possibly go through a corner. Rather, you have a baseline knowledge of what corner can be taken at which gear (= speed) using which motions (= braking motions, turn-in motions, throttle motions) under normal conditions. By motions I literally mean the motions you perform - they are stored in your muscle memory and can be accessed very quickly without requiring you to think.
This knowledge is built up by practice and slowly approaching the limits starting from a rough but safe initial guess (and learning from following competitors or watching replays, etc.). So what you end up with is a set of inputs + expected results that need to be started at a certain time.
Any special conditions are then accounted for afterwards, for example by having altered "baseline knowledge sets" for different but frequently occurring situations. Having less grip until the tyres are warmed up, approaching T1 after the race start, driving on a wet track or overtaking a competitor are probably situations that are worth learning a different set of motions for as they happen relatively often.
Conditions you don't have a learned set of motions for (due to them occurring very infrequently or if you simply don't have much experience yet) have to be compensated differently, either by educated guessing or pure guessing. These generally require you to actively use your brain and are thus much slower than if you had a stored set of motions ready for them.
The educated guess comes into play when you have specific pre-existing knowledge about the nature of the situation or you can link the situation to similar situations that you know how to handle. Say for example your rear tyres are overheated. Or dirty. Or your rear suspension is damaged. You might not exactly know what actually happened and you have no idea how much grip you have at the rear tyres (other than less than usual) so you can't simply "play back" the motions you're usually going through anymore, but you do know that using the throttle less aggressively and softening your steering inputs (less sharp and aggressive cornering) will probably help in this rear grip = lower situation. Just how much you have to alter your usual driving by these rules comes then down to trial & error, but basically you increase the strength/influence of the input alteration until your error-correction trigger rate (see below) goes down to an acceptable level, while constantly going back more and more to your usual unaltered behaviour to test if the special condition has improved or gone away.
A pure guess is, besides being the worst, a kind of guess you have to take when you have no reference or prior knowledge of how to handle a situation correctly. For the most part this is probably the simple reaction of reducing speed and/or taking evasive action. By gaining more experience you reduce the amount of situations where you have to resort to this kind of guessing.
During a race you also have a secondary set of motions ready, not used for specific parts of the track but for general error corrections. It's basically a set of triggers running in the background that auto-launch corrective motions in certain situations.
For example: trigger condition > error > actions to resolve
- Car turns unexpectedly/without steering input > oversteer > countersteer
- Front tyre screech under braking > front lockup > reduce brake strength temporarily
- Rear starts coming around under braking in RWD car > rear lockup > countersteer + apply throttle / reduce brake strength
- Car doesn't turn enough under braking > braking understeer > reduce brake strength and wheel turn
- Car doesn't turn enough under throttle > throttle understeer > reduce throttle and wheel turn
- Car turns too much under throttle > throttle oversteer > countersteer + reduce throttle
- etc.
Of course these are very general and might not be correct under all situations (= trigger condition not refined enough), but they simply represent the learned/automatic reactions to correct various errors that occur due to whatever reason. Of course these can also be more complex / abstract / meta-triggers, like "rate of oversteer corrections too high" (something wrong with rear wheels? overheated?) or "motion with high success rate starts failing too often" (something wrong with the car?), etc.
Basically I'd say for driving around a track you're using a set of learned and sometimes deliberate motions, using triggers (distance to-/position of a reference point can also be a trigger) to determine when to start or stop the motion.
- Brakepoint
Start braking motion- Press brake pedal with certain speed/strength
- Repeat heel-toe downshift motion with certain frequency till desired gear (speed) and/or turn in-point is reached
- Press brake pedal with certain speed/strength
- Turn-in point
Start turn-in motions- Release brake pedal with certain speed
- Start turning the wheel till desired/sufficient angular momentum is acquired to hit the apex
- Release brake pedal with certain speed
- Apex
Start exit-turn motions- Increase throttle with certain speed
- Reduce wheel turn while maintaining sufficient angular momentum to reach corner exit
- Increase throttle with certain speed
- Corner exit
Start straight-line motions- Repeat gearchange motion every time the engine pitch reaches a certain point
- Follow track till the next brakepoint is reached
- Repeat gearchange motion every time the engine pitch reaches a certain point
I guess the point I'm trying to make is that you try to avoid as many active calculations - as much thinking - as possible and rather follow learned motions.
Or maybe an even simpler, more abstract process:
- Wait for trigger
- Start motion
- Does it achieve desired result?
Yes: Goto 1, No: Continue
- Do we have an error-trigger to correct the situation?
Yes: Goto 1/2, No: Continue
- Start up brain
- Can we make an educated guess from our general car-behaviour / situational knowledge?
Yes: Do it!
No: Slow down / evade
Why does the AI need to know their exact X,Y on the track if you don't. I don't think they do, but I think like you said they need to know their position - relatively speaking - to each object around or near the track. I will place a large wager on the fact that you use reference points more than just braking and turning. And part of that wager extends to the fact that you will not get around a corner just fine without these reference points.
I made an example above:
I don't think your intention was to say that reference points were unneeded, but I think that reference points are 'all' you work with. The only difference is the number of points your mind handles vs the number that the AI will handle.
I almost always drive at 'pedestrian pace' when learning a track for the first time. I don't know what I am supposed to be surprised about here though, so I would like to know what to look for and I will certainly be up for trying it!
As for emulating the estimation and building the AI to be perfect - adding imperfections later. I don't know how much you understand about the project at this point, I don't know how much you have actually read in the thread or document that I wrote, but I am trying to go against the normal way of thinking about AI. I havn't started the technical designs of this system - which might be useful for the programmer side. I don't want to add imperfection later, though the imperfection in the estimation will happen based on some sort of algorithm or setting based on how the AI settings and such.
I have other opinions on a few things here. One being that you can feel the aero on the car. I agree existing knowledge tells me that more speed = more downforce therefore more traction in most situations, but that you can feel that, is where I disagree. Sure, you can feel it in G forces or speed increases around corner, but that you can read it, feel it change etc is something I don't think you can. (You can to a degree by knowing that all of a sudden you are understeering because you read that your front wheels lost traction. You can associate the loss of traction with the aero based on knowing you just got behind a car.)
I see. I understand now what you mean and the AI should take that into consideration based on judging their cars traction limits at each tire. Trying to keep the tire "AT LIMIT" as much as possible without pressing beyond the limits.
I have been reading several books on racing, as far as the driver and basic setup skills are concerned, for the last few years.
Thanks for the interest, hope you offer more
Artificial Intelligence in Racing Simulations Project
(570 posts, started )
FGED GREDG RDFGDR GSFDG