1. the neat one, which simulates everything you can think of and2. the absolutly simplyfied one

If the enemy/rpc/whatever is on screen you use #1 and if it's off screen you use #2.

The silly one doesn't even need to follow your game rules strictly. Eg you have there 2 space ships, which try to shoot down each other... if they are off screen you just move their positions around (which you can see on your radar) and subtract ammo and shield of em every once in a while. So no chasing, no aiming, fuzzy behaviour... just some random number juggling which should *somewhat* reflect the outcome of a real battle

but if you cannot see them, shouldn't you also make sure they are not on the radar? to avoid even "moving" as such?

Is that strictly lod tho? Because in graphics terms, lod applies to objects you can still see, they just have a lower face/vertex count because you can't distinguish the many faces from the rest....

I guess that also applied to AI, perform less operations if they are furthur away, but how would I be able to know which operations to remove and which ones to keep? For all the pc knows, the "moving" is the same as "moods"....

That's what I'm gonna try with my game. Now that it's time based instead of frame based, I can skip running a far off system for a frame and instead render it for double time next frame. Half the calculations for a very similar effect. Now I just have to think of how to organize it

whats the point malohkan? your still gonna run it twice which just makes up for that not ran frame.

However, if you could turn down the amount of calculations done per frame, with a flag perhaps, then it would be good. E.g. A calculation that must be done has a priority of 0. And one that is immediately take off as soon as the Agent isn't in view, set that to 1. And the second thing that is taken off from the calculations roster if its distance is 500 km away from the player...etc

So its basically a "resitance" factor. But how can this be done in a general, APIish sort of way?

Moving because it's visible on the radar... well it was just an example, where it make sense to move em around.

> Is that strictly lod tho?

lod=level of detail

Sure it's lod

>but how would I be able to know which operations to remove and which ones to keep?

It... uhm... depends

In my example you have 2 very different things. Therefore you have 2 completly different kinds of AI. A neat one which all buzzwords you can think of and a... uhm... rule of thumb thingy, which just changes some numbers to approximate the outcome of a battle.

There are also games where enemys - once off screen - cease to exist or simply freeze.

Always remember that it's good enough if no one can tell that you have cheated

If no one can see it there is no need for making it look realistic. So instead of letting em aim at each other you just subtract ammo and shield energie accordingly to their statistics and some fiddling around. You could for example generate some tables filled with "accuracy" percentages. Eg with 10 ship types you would get 10 tables with 10 entries. You could gather em by running your usual ai for some minutes... the accuracy you get could be saved afterwards.

So whenever they are off screen and batteling against each other you let em shoot with their fire rate and their accuracy is used for calculating if it's a hit or not. You don't run any AI here - you just use your statistical data for determining a *possible* outcome of the battle (this is of course very cheap to calculate).

Well, it's your rules - you can break em all if you want to

You can always switch to a completely different/much cheaper AI if you want to.

well, i actually *just* implemented that feature in. ALL calculations that are done in my Engine are done via whats called "AgentActions".

Those literally do the thinking for the agent, its a simple class with one method, and one int variable. That variable will be compared with what the method's lod variable is. And if the AgentAction's levelOfDetail's int is greater than the entity's, then go ahead and perform that operation.

Is that the way its generally done? Also, can you please explain more about switching to a cheaper AI algo thingy that you mentioned at the very bottom?

If im understanding you correctly, that means when the LOD of a particular algo goes out of focus, then simply replace with a cheaper one? E.g. pathfinding, using A* upclose for accurate pathfinding, then just do navigational meshes or something like that?

DP, you're looking at LOD-AI in a fairly strict, almost mathematical way. Which is good. Except...the game devs who coined the phrase were being far lazier than that .

Quote

Is that strictly lod tho? Because in graphics terms, lod applies to objects you can still see, they just have a lower face/vertex count because you can't distinguish the many faces from the rest....

In graphics, all games have identical graphics engines...they are "merely" triangle-renderers. Hence, you can "invent" a LOD system that applies to ALL graphics engines, so long as it only works at a very low level (the triangles) which is common to all graphics engines.

Unfortunately, there is VERY little standardization in AI. Also, whereas 99% of graphics engines are tri-renderers, with only 0.5% being voxels, and 0.5% being sprite engines etc (hey, those aren't accurate, I'm being rhetorically extreme here ), in AI you get a more 25% - 18% - 9% - 8% ... etc split - i.e. there are no truly "dominant" AI implementations. Some things - like pathfinding - are widely used, and there are LOD algorithms for them in particular, although not always referred to as "LOD". But on the whole the phrase is more directed at the general concept of LOD being applied to AI rather than the specifics of a single re-usable concrete algorithm.

Quote

I guess that also applied to AI, perform less operations if they are furthur away, but how would I be able to know which operations to remove and which ones to keep? For all the pc knows, the "moving" is the same as "moods"....

This is the thing: with AI, you have to decide for yourself. Triangles are really very simple indeed, so when it came to inventing LOD algorihtms there wasn't much to play with; with AI, it's so incredibly dependent upon how your personal game's AI works that it's much harder to make general observations...

I suppose its a good approach to have, but also a flawed one as AI behaviour isn't so mathmatical. Take POV-ray for example, it produces very realist images. But they are too realist, the shadows are crisp...etc. Purely mathmatical.

I guess i need to take a few drinks to get rid of that maths for a while

But because im creating an API, it must provide extendability to be almost plug'n'play. So I sorta need to be awake then.

that works fine if your algorithms are time based. And to be frank, most of them are. However, the time based are usually very trivial. Pathfinding is the big one without being time based.

For LOD to work with pathfinding, you must be able to "pause" the algorithm. Simply done by not calling a method and keeping the data the same. However, the big problem happens when the data needs to be changed between updates (say you update every 6 frames, the change occured in the 3rd frame).

The data needs to be changed, but when the algo is resumed, the data isn't the same as it was before, and you end up getting inconsistant information, or information that is completely wrong!

In my case, if a change occurs, as in, a guy reached an objective in the 3rd frame, but now in the 6th he's passed it, well he just turns back the other way so it takes him a bit longer. The idea though is that I've chosen to run him this way because he's far off and I won't see him, which means I don't care that he's acting like a drunken moron. He'll get to his objective ok, it'll just take him a bit longer

In the case of an activity like, an event should have occured at frame 3, well you just don't respond to that event until frame 6. It's just like there's a tiny bit of lag. However, if you're giving such low speed priority to a group anyway, you should expect those sorts of effects.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org