Irrlicht Engine

JP, which of these are:
1. Already implemented.
2. Planned to be implemented.
3. Not planned to be implemented.

1. I've told you that already, many times, just breadth first search so far.
2. I may possibly also implement an iterative depth first algorithm, i need to check back over my Uni project and see which was the best out of that and breadth first, this i've already mentioned a few times in this thread. Dijkstra is also a possibility, again something which has been mentioned a lot in the thread.
3. There's nothing completely ruled out.

To be honest i shouldn't think the library needs to have lots of search algorithm implemented, one that does a quick and efficient search is enough imo.

I guess the 8 pages frightened me a bit so sorry for bothering you with it

So JP, whats your thoughts on putting Race AI and Swarm AI in this? I've started the Swarm AI, it's about 40% done now. When I've got a working example I'll post the code or something.

Problem is I can only code these as a generic all-purpose type thing, I don't know much about the irrlicht engine to take advantage of it. But if make the maths of them you could modify it to take advantage of irrlichts engine right?

aussiedude wrote:So JP, whats your thoughts on putting Race AI and Swarm AI in this? I've started the Swarm AI, it's about 40% done now. When I've got a working example I'll post the code or something.

Problem is I can only code these as a generic all-purpose type thing, I don't know much about the irrlicht engine to take advantage of it. But if make the maths of them you could modify it to take advantage of irrlichts engine right?

If I recall correctly, JP wants to keep this library abstract just like Irrlicht isn't a game engine, but just a graphics engine. Some time ago I think I suggested two solutions to JP.

Either way, what solution were you looking at implementing for racing game AI?

Halifax is right, i do want to keep it abstracted away from specific AI types, but i think specific AI type supports can probably be added in, or at least included as an example/tutorial showing how it can be used or as a base project to start from.

As i've said i want to get the broad basics implemented for Christian's First King project first so i'll be focusing on getting the things necessary for an FPS first and then when that's done to a certain degree i can start branching out on other things.

But yes, if you (or anyone) implements some AI stuff, in a generic or irrlicht way then if i like it and think it should be included then, when the time comes, i'll stick it in.

Halifax wrote:

aussiedude wrote:So JP, whats your thoughts on putting Race AI and Swarm AI in this? I've started the Swarm AI, it's about 40% done now. When I've got a working example I'll post the code or something.

Problem is I can only code these as a generic all-purpose type thing, I don't know much about the irrlicht engine to take advantage of it. But if make the maths of them you could modify it to take advantage of irrlichts engine right?

If I recall correctly, JP wants to keep this library abstract just like Irrlicht isn't a game engine, but just a graphics engine. Some time ago I think I suggested two solutions to JP.

Either way, what solution were you looking at implementing for racing game AI?

My line of thought is that AI is about logic and decisions, so this Race AI should be based around the idea of creating a 'driver' to make decisions on how to drive the car. Now in real life, a driver looks at the road, the cars around him, the corners ahead etc, and based on that information and the abilities of the car he makes decisions. He might decide to speed up, slow down, turn hard left, soft right, handbrake etc etc etc.... he makes a decision on what to instruct the car to do. What ACTUALLY happens though is based entirely on physics.

So really we need the follow objects to be represented:

• The race track
  The drivers and their brains/memory

The input we need is:

• The shape of the track (in the race track object)
  The cars mass, acceleration, friction etc (stored in the drivers 'brain') and size
  The position of the car, it's rotation and speed
  The other car's position

And the output we need is:

• The decisions of the drivers to turn left or right and by how much
  The decisions of the drivers to speed up, coast, slow down, handbrake

Based on that theory I was thinking a design like this should work:

Classes:
Device (I always make a 'Device' in my librarys to organise everything)
Map
Driver
Sectors (Will need to explain this one)
Connections (And this one)

Basically the structure of these classes goes like this:


One technique I read in my game programming books is that the easiest way to store a race track especially when doing AI is define your race track as a series of sectors and connections between:


So putting that all together. That's how I intend on organising everything. When the library is being used it will be focused heavily on taking in information and return decisions.
Crappy Example:
while(gameRun==1)
{
redCarDriver->updateTheDriversKnowledge();
performPhysicsOnRedCar();
}

So the Car Driver will be just getting his knowledge updated and the car's acceleration, turning and everything will be changed based on that. Then in a user created function... or multiple functions whatever... the physics and the affects of those decisions are performed. Then the Driver has his knowledge updated, letting him see the results and letting him make a new decision.

As for how I intend on coding the decisions he makes... no idea yet. But something tells me it's gonna involve maths.

Halifax is right, i do want to keep it abstracted away from specific AI types, but i think specific AI type supports can probably be added in, or at least included as an example/tutorial showing how it can be used or as a base project to start from.

As i've said i want to get the broad basics implemented for Christian's First King project first so i'll be focusing on getting the things necessary for an FPS first and then when that's done to a certain degree i can start branching out on other things.

But yes, if you (or anyone) implements some AI stuff, in a generic or irrlicht way then if i like it and think it should be included then, when the time comes, i'll stick it in.

Well maybe I can make this even more generic and make it a vehicle driving AI library. No race track or anything, just driving of vehicles of any form to a destination set by the user. Would that be more useful? I ask because it's most likely that I will be using the code I write myself when i make a game so I want it to be as useful as possible to everyone AND me too. So the more generic and multi-purpose I can make it, the better.

I think the best thing to do would be to first make it for yourself, and then tailor it to the needs of the masses. If you try to do both at the same time, then...that wouldn't exactly make for an easier job, and in fact will probably slow down the development of your game/demo and of the library even more. That's just my suggestion.

aussiedude, that's one cool analysis of how a driver's AI should work hope you're able to implement that in reality.

aussiedude wrote:Problem is I can only code these as a generic all-purpose type thing, I don't know much about the irrlicht engine to take advantage of it. But if make the maths of them you could modify it to take advantage of irrlichts engine right?

does that mean that you're not using any of irrlichts built-in types (e.g. vectors)? if so, you'll be facing extra work.

if it's a library especially for irrlicht, i think you should also use the built-in types to make it feel more "irrlike" and to save you a _lot_ of work.

morris wrote:aussiedude, that's one cool analysis of how a driver's AI should work hope you're able to implement that in reality.

aussiedude wrote:Problem is I can only code these as a generic all-purpose type thing, I don't know much about the irrlicht engine to take advantage of it. But if make the maths of them you could modify it to take advantage of irrlichts engine right?

does that mean that you're not using any of irrlichts built-in types (e.g. vectors)? if so, you'll be facing extra work.

if it's a library especially for irrlicht, i think you should also use the built-in types to make it feel more "irrlike" and to save you a _lot_ of work.

Well it's not especially for irrlicht, I want it to be more or less like my miNav library and be plug&play into any game/graphics engine. It will mean extra work I know but that's ok for me. My theory is that I'll do more or less what Halifax suggested. I'll make a plain version for me and after that I'll try and make a custom Irrlicht version which uses built-in types and stuff.

Thanks for the compliment on my analysis. To be honest I've been planning and writing down notes on how to do this all week at work. So I've had a lot of time to think about how to approach this. It's been good though, I feel the time spent planning will payoff in the end more than just jumping into this.

aussiedude wrote:

morris wrote:aussiedude, that's one cool analysis of how a driver's AI should work hope you're able to implement that in reality.

aussiedude wrote:Problem is I can only code these as a generic all-purpose type thing, I don't know much about the irrlicht engine to take advantage of it. But if make the maths of them you could modify it to take advantage of irrlichts engine right?

does that mean that you're not using any of irrlichts built-in types (e.g. vectors)? if so, you'll be facing extra work.

if it's a library especially for irrlicht, i think you should also use the built-in types to make it feel more "irrlike" and to save you a _lot_ of work.

Well it's not especially for irrlicht, I want it to be more or less like my miNav library and be plug&play into any game/graphics engine. It will mean extra work I know but that's ok for me. My theory is that I'll do more or less what Halifax suggested. I'll make a plain version for me and after that I'll try and make a custom Irrlicht version which uses built-in types and stuff.

Thanks for the compliment on my analysis. To be honest I've been planning and writing down notes on how to do this all week at work. So I've had a lot of time to think about how to approach this. It's been good though, I feel the time spent planning will payoff in the end more than just jumping into this.

Just curious, but have you also taken into account the effect of the other race car drivers on the track. It would be cool if it would be possible for an AI node to recognize other AI nodes, etc.

What I was thinking of, on how to make it easy for the developer, and you, is that you implement a precedence list. So basically the AI runs down the precedence list, analyzing if it is possible or not, and making the correct decision. Of course, there are more things, but I really don't feel like going to in-depth here. They would involve callbacks, and built-in callbacks, etc. You could also dive into depth precedence lists, but those are quite ridiculous, and would take a long time.

At any rate, I would really like to talk to the AI designers of Gran Turismo, because really although it seems like their AI is smart, and provides for an "almost" convicing race their AI is actually really stupid.

You can break down a Gran Turismo race into the following: the car stats, the track, whether the car is next to you, and that's about it. Now this leads me to the conclusion that Gran Turismo's AI is a lot more static than people think. Although parts of them are determined at dynamically, but not a lot.

So basically I am thinking that the AI follows a set streamline path in which that streamline path is a list of all the start and end points, like you said, it is also in the middle of the track, it contains the value of the optimal speed for that part of streamline, the traction of the streamline at that point, etc.

What this means is that the only thing needing to be determined at run-time is to try to reach optimal speed, decide whether to pass the other car in the least amount of space before getting back to the streamline, and to also try to knock the car of the track.

These are all just speculations, but this is what I believe after playing the full Gran Turismo series, and of course this still isn't anything small or easy to implement.

I believe performance is one if not The first thing we should take care of when creating a game. Because AI is only a part of a much larger picture the performance of it should be accordingly and so,

JP wrote:Performance & The Code
As for the number of NPCs you can have running around at one time the current fps example can handle 30 quite easily, without dropping below 60fps (vsync on) and only really starts to struggle when you add up to 40 when the frame rate drops down to between 50 and 60fps.

I don't think those figures are very realistic. Having a smooth FPS with only 30-40, even 60 on a good PC is like saying I have a very effective and strong engine but it's too heavy to make the car move.
I understand it will take time to optimize it but I'm willing to help with reports.
JP, as I don't have Dev-Cpp and I don't want to install it, could you provide me an exe file, .zip with some demos that I will run and test to provide back with report on performance with different PCs? - I'll be glad to do it if it helps.

P.S
Do you have a doxygen-made .chm file of the lib to share with us?

MasterGod wrote:I believe performance is one if not The first thing we should take care of when creating a game. Because AI is only a part of a much larger picture the performance of it should be accordingly and so,

JP wrote:Performance & The Code
As for the number of NPCs you can have running around at one time the current fps example can handle 30 quite easily, without dropping below 60fps (vsync on) and only really starts to struggle when you add up to 40 when the frame rate drops down to between 50 and 60fps.

I don't think those figures are very realistic. Having a smooth FPS with only 30-40, even 60 on a good PC is like saying I have a very effective and strong engine but it's too heavy to make the car move.
I understand it will take time to optimize it but I'm willing to help with reports.
JP, as I don't have Dev-Cpp and I don't want to install it, could you provide me an exe file, .zip with some demos that I will run and test to provide back with report on performance with different PCs? - I'll be glad to do it if it helps.

P.S
Do you have a doxygen-made .chm file of the lib to share with us?

I'm sure it wouldn't be too hard for someone to gather the jist of irrAI through the demos.

And a note on that performance issue, I am sure it wouldn't be too difficult, and in fact I plan to implement it when I get the time. Although it will add time to the creation of AI paths, but basically all you would need to do is hold 3 different waypoint lists, and pick one based on the distance from the reference node. Just a simple interface to provide at least some sort of LOD.

LOD for waypoints you say? I'll have to see how it effects performance with my own eyes on the lame PCs I can get my hands on..
But still, theoretically it could be the best optimization but I don't think you should develop in a path you theoretically believe is good, performance-wise, you must work with real world facts then improve the figures of those facts, this is the best way IMHO to improve performance, or at least part of the way.

MasterGod wrote: JP, as I don't have Dev-Cpp and I don't want to install it, could you provide me an exe file, .zip with some demos that I will run and test to provide back with report on performance with different PCs? - I'll be glad to do it if it helps.

P.S
Do you have a doxygen-made .chm file of the lib to share with us?

Performance is certainly important and as you say you can't have the AI hogging all the CPU time whilst the graphics and physics suffer. But i'm developing this library primarily for Christan and the result of my work with him will be that there will be a library that everyone else can use too. Therefore my priority is to get the library working with the features Christian needs. Obviously he's going to need performance but his project is a long one and so i want to get the basic framework together first and then i can optimise that for him.

The .exe files are included in the download, have you actually looked at the information provided? It's all mentioned on the first page!

There's no documentation provided yet, other than the comments in the code, but that's what doxygen uses to produce the documentation anyway and seeing as the source is so small at the moment it's not that important to get a doc file yet.

My PC is actually quite old, i got it in the summer of 2003 and it wasn't top of the range even back then so there will be a lot of computers which will be able to run the AI code better than mine. But of course PCs like mine still need to be supported, so i guess maybe that will need to be considered for the library...

One thing i'm going to look into is multi-threading to speed things up, this means that the AI can be calculated while the rendering is being done and then the results can be used in the next frame, just like physics engines work. That should improve the performance quite a lot i should think.