is it better to let a couple of boy and girl sit together closely sometimes?
huh?
i mean let audience be more natural and cute
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!
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.
@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.
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.
It only took me a couple of years, but it’s worth it #-o
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.
@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 - 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.
I worked on my 3D version a bit more, see below for video (note there are some visual artefacts caused by the recording process).
https://www.youtube.com/watch?v=WH-OQLYuntU
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.
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
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).
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
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.
=D>
@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.