3D Tilt Racing (UPDATE self driving car)

Ignatz

This is a 3D (ok, 2.5D) racing game, where you tilt the iPad to steer left and right, and to speed up and slow down.

It has a track editor shown at the start of the video below, allowing you to push the track into a shape of your choice, then you can race on it (this technique could be used to create a sculpting app).

I still need to provide the ability to save and load custom tracks, and scoring, and maybe things on the track to collect or avoid.

But the app is all about responsiveness.

yojimbo2000

Awesome! It would look great with some textures and lighting.

yojimbo2000

I'm also looking forward to seeing your tilt steering code. I've struggled with tilt steering in the past, because you only seem to be able to access the rotation rate, rather than an absolute value, so the "centre" of the wheel shifts if the user steers past the left or right wheel lock

Ignatz

I am simply using gravity, I will share code tomorrow

West

Looks great!

deactive

Wow, love it

Simeon

Looks amazing @Ignatz. I think your track editor is very intuitive.

You could make the little people into billboards so they always face the camera (at least on the y-axis)

Ignatz

Thanks, @Simeon

I'm thinking of billboarding the people, but that means separating them individually from the side panels, so it's quite a lot of work. There may be a better option.

Ignatz

I've updated it

The crowd is individually animated, there is a mini-map, and a rather crude car front end image that helps with steering. All the images are really placeholders.

I'm not going to finish this game for the competition, because there isn't a lot of time, and that is all the boring work. Instead, I'm going to write up the interesting stuff in the game on my blog, then I'll post the link here.

For those who want to try it as it stands now - code

firewolf

some praise, 3D Tilt Racing

Simeon

Out of curiosity, how does the track editor work at a high level? Is it a spline that you add control points to?

Ignatz

@Simeon - easier than that

It's a fixed set of 100 points. When you touch the screen, it takes the direction and dots it with the directions of all the points, and distorts them more if they are close in angle. That's all.

 for i=1,points do  --loop through track points
    local ti=track[i]:normalize() --get direction of this point
    local a=dn:dot(ti) --dot with touch direction
    if a>0 then --if on same side of track, then
        a=a^(16-Smoothness*3) --adjust for smoothness
         --then move point up or down its normal
        track[i]=ti*(dLen*a+track[i]:len()*(1-a))
    end
end 

hpsoft

beautiful
i remember the first car game in 2d "Atari Eduro" by Ruilov
a lot of work to create 3d car game in 60 fps on ipad air
I can not wait to see the buildings on the side of the road ^:)^ ^:)^

Ignatz

@yojimbo2000 - this is my tilt code

--speed is controlled by tilting forward and backward
speed=math.max(0,math.min(maxSpeed,speed+Gravity.y))
--turning left and right is controlled by tilting left and right
--this angle is in radians to avoid needing to convert for sin/cos
angle=angle+Gravity.x/100

This is literally all the controller code.

yojimbo2000

I can't believe it never occurred to me to try the gravity variable for steering. X_X

TechDojo

Well done @Ignatz another class piece of work. I like the neat way you set draw to equal the function you want to use for rendering (ie managing wether your in the editor or in the game). The only thing I noticed is that if you tilt it too far forward then the orientation changes, I guess you could fix it to either LANDSCAPE_LEFT or LANDSCAPE_RIGHT.

@yojimbo2000 - whenever I've seen games that use the accelerometer to control movement it's usual to have a calibration screen at the start of the game to define some initial reference point (ie hold device still for a couple of seconds) and then calculate distance from this point. Personally I'm not a fan of tilt based gaming but each to their own.

Ignatz

This competition was about responsiveness, which is why I used tilt

wrt redefining draw to different functions depending on the state of the game, well I can thank the forum for that. It's a great approach.

I posted some comments on this project here

https://coolcodea.wordpress.com/2015/03/28/208-3d-racing-game-faq/

TechDojo

@Ignatz - for what it's worth, when the voting opens your game is the one that will get my vote. I think out of all the entries I've seen so far it's the most technically impressive and offers the greatest opportunity to learn new skills from.

deactive

Especially if it was all written in one week time.

Ignatz

No, it's unfinished, so it can't win, but I did it for fun

firewolf

is it better to let a couple of boy and girl sit together closely sometimes？

Ignatz

huh?

firewolf

i mean let audience be more natural and cute

Ignatz

ok, I get it. Yes, that would be a good idea. If I was coding this seriously, I'd have lots more different people and place them less regularly.

But it makes things easier at the beginning to keep the people simple, when you are trying to get the racing working. You can always improve the people later!

yojimbo2000

Fantastic presentation. Love the blurry walls, the people jumping up and down, the mini map, the way the car bonnet shudders, fabulous stuff.

My only criticism is you have to tilt the iPad way too far forward to get it to accelerate, the screen flips upside down. If it were me, I'd make accelerate touch, and reserve the tilt for steering.

And the track editor is very cool. I thought it must be some kind of spline when I first saw it, I'm going to have to take a closer look at your code.

Ignatz

@yojimbo2000 - thanks for that. I agree the tilting needs some fine tuning, but I threw it together towards the end, and didn't really get to fine tune it.

Distorting the vertices is fun. If you do look at the code, i suggest you also look at my blog post about it, and (if you aren't very familiar with them), my links to posts on the dot function and vectors. Really understanding them has made a huge difference to what I can do, in both 2D and 3D.

yojimbo2000

Yeah, I read the dot and cross posts, only once though. Will take a few more reads to sink in! They keep cropping up in bits of code I borrow off others, ie calculating normals, or @LoopSpace 's algorithm for whether 2 lines cross. I'm sure at some point the concept will get into my thick skull.

Ignatz

It only took me a couple of years, but it's worth it #-o

Ignatz

My ambition for some time has been to make a full 3D racing game. So now I'm trying again. My only rule is that it all has to be done in Codea.

I've made a map (below) by setting up a grid of vertices, and distorting them to create mountains, and now I have to cut a tunnel through the mountain in the middle, and make the track less flat, and make round corners.

deactive

no way, I want to see this map in action now
Always and only great stuff from @ignatz

+10!

TechDojo

@Ignatz - yet another cool demo. Both this and your tilt racing demo reminds me of a game I designed back in the mid 90's called Cavern Racer - where by you had two height grids, one to represent the floor and the other to represent the ceiling and the track would be the space between the two. The idea was to use a midpoint fractal displacement to create a rocky cavernous interior from an initial simple track layout - the cool thing would be to increase the level of detail as you got closer to the walls (using the midpoint displacement and a fixed seed).

I figured you could "morph" the terrain in real time to have sections open up and close. The "cars" would actually fly around the track from floating waypoint to waypoint and you'd be free to pick your own route providing you hit each waypoint.

Unfortunately the idea never got past the paper stage but I always wanted to have a go at doing it - I guess Codea is easily as powerful as the PSX / N64 from back then so it should be possible, especially with some optimized shaders and mesh code.

Ignatz

@TechDojo - I think I'll leave you to do that, this is hard enough!

TechDojo

@Ignatz - from small acorns my friend, I'll bet looking back you've probably come further than you'd ever realised you would (and had a lot of fun along the way).

If you duplicate your landscape above and rotate it 180 degree's you'd be almost there.

Ignatz

I worked on my 3D version a bit more, see below for video (note there are some visual artefacts caused by the recording process).

You will find the code here. It doesn't require any assets. (And yes, I noticed there is a gap in the track near the tunnel, it is a bit tricky to fix).

The game has a nice cartoony feel. I would have preferred more realism, but my FPS (on my iPad 3) was down to 20, so I couldn't afford more detail.

I changed the controls to joysticks, fixed the corners, and cut a tunnel through the middle. (I like tunnels).

What I haven't done is made the track 3D. It is flat all the way round. There are two challenges in making it 3D. One is shaping it, including making the corners curve correctly, and the other is getting the car to follow the track height. This in turn has two challenges - figuring out where you are on the track, and what height it is at. I have done this before (eg wraiths in the mist), so I'm not sure I'll bother.

Bri_G

HI @ignatz,

As usual a very impressive package - where do you get the time ????

Only one problem - the grass texture - replaced with one of my own and bingo - running (or racing should I say) in circles. Smashed through the wall - nothing but blue sky!!

I was very impressed with the whole package but intrigued by the video of the race course map spinning in the video - how did you build that up, very smooth 3D effect.

Thanks again,

Bri_G

Ignatz

sorry, I forgot about the grass texture. A light green image will substitute.

I didn't include code to trap crashing. This is definitely an unfinished game. I was mainly testing terrain generation and tunnel building.

You will get the spinning map effect if you go into setup and set camAngle=1. Look in the SetCamera function for the code that is used when camAngle=1. (The other camAngle settings are used for debugging, except 0, which is for racing).

Bri_G

Hi @ignatz,

No problem with the textures - could be useful having a few textures in the app documents - like grass, sand, brick etc so that in the event that posts refer to other Dropbox libraries they can be easily replaced.

Thanks for the prompt on camAngle - now got that up and running and looking at how you've done it. This will take me a while to explore.

Thanks again,

Bri_G

Ignatz

Ray tracing came up in a forum topic, and I wondered if a shader could be used to create a self-driving car, by identifying the features and obstacles in front of the car.

The result is below. The steering is jerky, and the car can crash, but it does a pretty good job of driving round the track by itself. The yellow dot in front of the car shows where it is pointing.

It works by drawing an extra copy of the track to an image in memory, a few times per second. The image is clipped so only one row of pixels gets drawn, halfway up the screen (making the drawing very fast). I chose this height because it captures pixels from all the track sidewalls.

The shader sets the colour of each pixel in this row, to a number that encodes the z value, ie distance to the sidewall. Codea can then read the pixel colours from left to right (perhaps sampling only 1 in 5, for speed), and figure out which way to go (generally towards the furthest pixel), and how fast.

My example above is crudely coded, and any faults in the driving are down to how I decide direction and speed. The ray tracing works well.

The reason I thought of it is that normally, if you want to scan your surroundings to see what is close or far away, you need to pick a direction, and test every pixel (or maybe sample 1 in X pixels) between you and the horizon, until you hit something, and then repeat this for a lot of angles. The advantage of a shader is that it is very fast, and it doesn't need to test all the pixels between you and the horizon. The disadvantage is in having to read the colour values out of the results, because that is not terribly fast.

In my (limited) experience, ray tracing of this sort has fairly limited uses, because whichever way you do it, Codea is not fast enough to do a full scan of screen width and height. You need to minimise the number of tests that you do.

But it is an interesting technique, and I'll write it up soon.

Jmv38

=D>

Simeon

@Ignatz doing AI in the shader very clever. I like that it's kind of based on what the car can "see".

Would this be equivalent to doing the raycast in 2D against your map points? You could even do it with the physics engine by encoding the map as two CHAIN type bodies and doing raycasts forwards from the car.

Ignatz

@Simeon - yes, it's essentially a 2D horizontal scan. I also like the fact it's based on what the car can see. It's more versatile than doing a 2D scan against a memory map, because it doesn't need any map and can handle objects moving around in the scene. Against that, it is just one row of pixels..

I'm guessing if you use the physics raycast function, it actually examines all the points between you and the horizon (unless it just examines the other physics objects based on their position and orientation), whereas the shader just draws one row of pixels and you can encode the z value in the colour.

Simeon

@Ignatz I believe the physics engine will use a bounding volume hierarchy to quickly find the point of intersection (i.e., it can throw away large portions of the scene and quickly isolate the approximate intersection point). Other objects could be modelled as 2D polygons for the purposes of intersection tests. I suspect it would be the most computationally efficient. (Not that it really matters.)

Because your shader version is essentially "2D" (one row of pixels) you could make it a little more robust by scaling the map and all cars on the Y axis so they are infinitely tall for the purposes of rendering the collision row. This would ensure that the nearest objects are always detectable within the single row of pixels.

Archimedes

@Ignatz if the coordinates of the player are easily referenced, we could make this a multiplayer game.

Ignatz

@Archimedes - the player stats are very simple, just position (vec2), angle and speed, ie 4 numbers.

However, the game would need some work, eg better collision detection, start and end, etc.

I'll have a think about it. It might be better to start with a simple 2D game, which will be easier for other people to adapt.

wrt 3D, I may have other, more exciting options to choose from [past work], such as a large 3D dungeon, or a fighter plane dogfight, either of which would require very little socket traffic.

As soon as you have a workable socket setup, let's talk about it some more.