AI for hovercraft

[ISAWHIM]

I swear... I thought I was closing them...

Ok, So I am still using the "TestingAI2" as my primary development, but developed code there, is being arranged into my Sand-Box program.

The original runs full-open, so I can throw in 5000 at a time, and test the variation from player to player, instead of watching one car do 5000 laps.

The "PreGame-SandBox", I am treating as if it were the game...

Limited to 8 crafts... in-game camera settings, controls, limits...

In both, I have added buildings for some scale and view-filling. I just with the fog-depth was able to be pushed back, and the camera view made more realistic. (View is too narrow, but seems to be a limit.) Would be neat if the camera could change position while you drive... If you go slower, it pulls up and back, giving you a nice area view. Letting you see more where you are looking. While going faster, would pull down and focus more ahead, as opposed to top-down. (The camera doesn't like to behave when the parent it is created off of, has also moved.)

You can now slow down to 0 and race up to 150, for now. (But you are still on the track. I am separating the first car from the AI control, for full user control.)

I think I may move the car data out of the element. It does not make for easy code when trying to compare three cars, X, Y, and Z, but also three separate values... carX.angle with carY.force with carZ.height. (I may be doing that wrong also, but arrays are needed for multi-car comparison.) I have sort-of started doing that...

For code clean-up...
I have created a universal "GLOBAL xTempLong AS LONG", and others will follow.
I did as instructed, and moved the AI to an outside location, and setup a global matching PTR for the crafts.
I renamed some elements to a more neutral name.
Created another camera, and one more camera view. (Top Center), (Top Start), (Player), and (Bleachers)...
I figure the views could be recycled for some dramatic transition, or for game-backdrops in start-up, pause, etc...
Shortened a lot of the odd looking code I added. Some replaced with more functional code.

Added air-resistance now... (Sort of fast decay)

I still need the DoEvents to stop my CPU from melting, while doing nothing. I have not found a better solution yet.

[ErosOlmi]

That is really something. Thanks.

I get more than 1000 FPS at 150MPH
CPU usage is not bad, around 30 to 50 % but I'm on a Core 2 so not indicative.

[kryton9]

Jason, that is really a lot that you did and the performance is really great. I was getting around 1900 fps with 150mph.

[Michael Hartlef]

What the hell have FPS to do with the simulation of speed, means what have the FPS to do with MPH?

[ErosOlmi]

What the hell have FPS top do with the simulation of speed mean what have the FPS to do with MPH?

In reality nothing ;D
Just nice to report.

[Petr Schreiber]

I get around 300-400 FPS.

Very nice, maybe the ground could be made brighter by setting it from RGB 80, 80, 80 to 255, 255, 255.

One remark - to call function, you do not need to use CALL keyword. This is useful only when you call function by name componed from string. So you in this example, instead of:
[code=thinbasic]
CALL GameSetup()

' -- Resets status of all keys
TBGL_ResetKeyState()

CALL CameraView() ' -- Call EMPTY for reset to start-line view

SLEEP(10)
[/code]

you can go for:
[code=thinbasic]
GameSetup()

' -- Resets status of all keys
TBGL_ResetKeyState()

CameraView() ' -- Call EMPTY for reset to start-line view

SLEEP(10)
[/code]

But this is detail.


Petr

[ISAWHIM]

LOL... I was wondering why they were mentioning speed (MPH)??? (Thinking the same thing myself.)

Though, speed will become an issue when the collision is set into place. (Faster speed = more pixels/distance moved per frame. Slower frame-rate = longer distance moved per frame.)

But for now, it is irrelevant. (Number of cars is the ultimate test, as that is loops iterated.)

I have moved the "TBGL_userdata" out of the entities... just too difficult to manage cross-checking of data. (Requires another array for pointers, and it depends on communication with TBGL to get info that is only for the program. (EG, TBGL does not use that info internally to calculate drawing or motion.)

That added a little speed-gain also...

But once object to object cross-checking begins, the gains should be exponential. (One ms becomes 8 to the 8th power ms, in a cross-checking setup array matrix.)

Now, we can compare car X to Y and car(x).value to car(y).value... and move car(x) without any values. I am not sure I like that all arrays have a fixed range (1-x)... because I am not sure if that creates actual dummy-cells in memory, or if that only creates the index pointers, for memory to be allocated. (Dummy-cells being empty values, but physical blocks of pre-allocated memory.) I am using the constant as the array count, so objects and array cells match. With only 8 cars, that isn't a problem, unless the constant is at the end of the constant list of objects.

I am now moving the ships and the camera's into pivot-elements. There will be only one camera again, for main view. The location and position will be set as needed. The vehicles will be attached to a pivot, so that the vehicle can be raised and lowered and turned on the Y-axis (xz-flat), without altering the xyz(Rot) of the actual ship. We should be able to tilt, lean without having to re-orient every axis and angle and direction with a complex formula. Height has no impact on tilt, when rotated on Y, but attempting to rotate x or z does not result in leaning left, when the ship has been turned 90-deg, it results in a nose-dive... since the axis stays aligned to the world, even when Y is turned on the object with an ANGLE call.

(I knew it could be without them... Figured it was an optional thing. I was using the coloring it creates as a visual marker while scrolling, otherwise the dark-blue just blends in with the rest of the functions and code. I will remove them if they are not needed, or may impact performance.)

I will repost the modified code tonight. I needed the modified code for the rest of the physics.

I was wondering if adding zones, along with way-points, would be better. Use the points as entrance and exit markers, while the zones are the areas between. That would allow you to "Physically" enter a zone, but not be "In the zone" until you have passed through the entrance, which would then reveal the exit. (Not visually seen in the game, but for the AI.)

EG, If the point was a hole in a giant sheet of paper, and the zone was a box/area on the other side, away from you... visually, you know that you can only select a point in the area, through the hole as a target. Being in the zone, but not having passed through the entrance, would turn your target back into your prior zone. Which the exit would be known, so the back side of the box would not be there, you could select any location in the prior zone, but the prior zone needs to be selected, so you can enter into the next zone. (That comes into play more with physics, where a spot "In the next zone", was selected through the "Entrance", but someone knocks the player off the track before the zone was reached, and they fly into the next zone, but off the track. Or that could be assumed as advancement, but the area through the entrance, is only a selectable area, if not knocked into the zone by the game.)

The map editor could create the zones and entrance/exit locations of each section. The AI could actually run around in a created map, at the time of creation, and set-up its own "track", using the map data before the game. Once the game/map is loaded, the AI uses that "track" as a guide. (Unbound to the physical center track.)

If they think like chess, and use the game physics to calculate which move will have the best desired results... they could setup a path that handles varying speeds, banks inside turns (Since that is naturally the shortest path, and banking on a turn is also a shortest path.) It would only have to setup two points per area, one being high-speed, and one being low-speed... It would still only sort-of know an idea where to go, since speed changes with impact from other players, and ship-stats change. But it could choose a point which best suits the speeds they are going. Selecting a point between points would be a natural option based on speed/velocity. (That would have to include code that penalizes for "Bouncing off walls" which may mathematically show it as a viable high-speed short-path. LOL... Good way to get around corners, but if penalized for damage, they will not save that position as a possible path-point for selection.)

The reason I bring that up, is because the paths which mark the center, or any paths, will change shape with velocity. Since velocity is not a constant, nor is mass, it is impossible to setup any single track for all variations. (Other than for the camera, which has a fixed mass, and no collision.)

Having the AI attempt to do this, in-game, may not be wise. As they should only be reacting to impacts and selecting predefined short-paths as a guide. Not doing actual calculations, or following one set zone-target. (To ensure that they are passing through all sequential zones, as we will be expected to do in the race.)