Sorry your browser is not supported!

Hi I am new to coding for games and I developed an algorythm and I was wonder if this is the most efficient method for a racing game.

My idea is to have a race which will move players, record position and direction like the game MarioKart.

A line will be formed from two points in 3-D space representing the checkpoints. Height doesn't matter.

DIM LowXCheck(NumberOfCheckpoints)
DIM LowZCheck(NumberOfCheckpoints)
DIM HighXCheck(NumberOfCheckpoints)
DIM HighZCheck(NumberOfCheckpoints)

There will be a checkpoint everytime there is a change in direction.

The route of the enemy will go to a randomly determined point on the line. If the difficulty is set higher then the route will be closer to another point on this line called the 'perfect path' which would be the best possible route to take.

The objects position (First, Second, Third...), will be determined by the current checkpoint state, and if there is a tie (from two racers passing the same checkpoint), the distance to the 'perfect point' of the next checkpoint would give the position precisely.

If the direction is greater than the high angle value or less than the low angle value for the checkpoint a message displaying that the object is going in reverse will be shown.

The laps will only increase if you have cleared every checkpoint in order. So if you go backwards your checkpoint state will be reduced so you cannot clear the last checkpoint and travel backwards go through the start and have an increase in laps.

Well whaddya think? Is there a better method? Is that too big and bulky? I was wondering if anyone had any comments on it. If you can't improve on it hopefully it helped someone who was wondering how.

I made an image but I don't understand how to use the image command...

Hey Black Hydra
I've often thought about the same problem as I have a love of car games (yet to finish one though...
A couple of things I'd suggest
1) Rather than compute all the way to a checkpoint for 2 players near each other (if I've got what you wrote right), why not have each player head for a point at the next checkpoint and have collision avoidance code? This would also allow for things like "slipstreaming" which they do in real races - the added advantage, compute the path for one and have the ones behind it follow rather than computing their whole path!

2) Make sure your checkpoints continue off the edges of the track as players who go past the checkpoint but are off the road should also be credited with a lap

3) Depending on your track model, you can get creative with your checkpoint idea. If the players can't go cross country to an out-of-sequence checkpoint, you'll only need to keep track of the current checkpoint, the last checkpoint gone through, and possibly the next checkpoint. This is particularly handy if you have heaps of checkpoints.

There are loads of methods of making a race game AI. Which one is best depends entirely on your game and also, to an extent, where your strengths as a programmer are.

In some of my early race games from when I was a kid I made a picture template of the race track and on each pixel I placed a coloured dot for the direction I would like the AI's to be if they where on that part of the racetrack. Red might be true left, red with a bit of green might be left and down just a little bit. This made accident recovery very good no matter where the cars ended up, but the only deviation in the racing line was from minor changes in the cars physics such as acceleration speed, top speed, turn speed etc. It's great for 2D racers.

Other methods might be to store checkpoints in an array as you have suggested, or you might also use limbs on the track object and read off their position.

You could also use object intersection to test for line of sight and have the AI calculate a racing line on the fly. That might sound slow but actually it isn't. With just three object intersections you could read off everything the AI can see and calculate where it wants to be heading. It would only work if the track was walled. It wouldn't be my choice of method, but it could be got to work.

One change I would make to your system is not to check *every* checkpoint in order for the AI. If you have anything like a racing line setup on some bends you could easily skip a checkpoint. Instead just pick a few that are on straits midway down.

Another option is a bit like the first. Make a little editor to view your track, make an array that breaks the track down into small areas. So if you track is 2000x2000 in 3D size you might make an array that is 100x100 where each value represents a 20x20 area.

Now set the ideal facing for each area. So if the AI is in square 1,1 (top left corner) he would want to be facing bearing 135 (down right).

This method requires lots of data, but less calculation in real time because you have already precalculated your entire movement path no matter where the AI ends up.

Rather than using checkpoints you could also do ghosting. Record your x,z position as you yourself drive around a lap and have the AI's copy that. You could enhance this further by having several ghosted laps that they can follow, or by letting them experiment with a few of the recorded positions by trying adjusting a few checkpoints subtley and comparing the laptimes so that the drivers learn what is faster and what isn't.

There's probably a few more possibilities as well, what it all boils down too is how you have constructed your world and where your strengths as a programmer lie.

Thanks for the advice guys but I will have to clear some things up

1) @ Cowboy - The code your talking about in your first comment is to determine position. i.e. 1st, 2nd, 3rd place DURING the race.
I think your idea about collision avoidance is something to look into. If it were collision for static objects then I would make the objects go around it but, if user placed traps from weapons (think banana from MarioKart) were involved it would be more complex to adjust how the AI handles it at different difficulties...

2) @Dryll - Ghosting isn't something I wan't to do. Not because it wouldn't be good but I prefer using maths to form a course AI. This will allow me to adjust difficulties using these maths. This may make a slightly more angular race (if I can use that term...) unless complex curvangle adjustments are made but that is my goal on this project so to speak.

And as for your idea of facing when on certain blocks, although it is an interesting perspective, I think it would require more data to be stored than neccessary. My method of checkpoints would only require six numbers of data for each turn where as your would require three for each square (x, y, angle) if I understand it right. I have to face facts I have a very poor comp so optimization will be key. Thanks anyways as new perspectives always help you judge your own code and algorythms more effectively.