This is Loose Gravel! A pseudo-3d racer that started as a proof of concept, and gradually grew into something of a game.
If you're curious, you can view the progress here.
Pretty self explanatory. Choose a course and try to overtake the other cars in 3 laps to win.
Courses are randomly generated but have their own unique parameters and feel.
I was planning to add a tournament mode (and some more tracks), but I ran out of cart space (so that means it's finished! :) )
Tip: If you tap the up arrow you will keep accelerating until you hit something or drive off the road. You don't need to hold it down.
Update: Replace scaled map routine with tline version
Pretty darned good at that !
Here is a star for you.
Also, here is the original OUTRUN for which I think you may have modeled your game, and if not, it might have some good ideas in it for you.
There is also the more recent and popular Cruis'n USA.
Flying lessons anyone ?
Some of the greatest thrills a player can have in a 3D racing game is getting to the top of a ramp or bridge and going so fast they literally jump off of the track and air airborne for a few seconds.
It's mostly inspired by 8-bit conversions of old racers, like Chase HQ on speccy (which had quite good pseudo-3D) or Powerdrift on C64 (which didn't really, but was fast, colourful and fun).
Outrun was pretty classic though.
I had planned to add some ramps and jumps. Would have needed a quite a bit more code though.
This is excellent!
The sense of speed is great and it really shows of the capability of the system.
Any chance the car sprite could shift/rotate in order to make turning feel more “active”? Right now it just feels like the car is pasted on the world rather than being part of it.
I've added in a slightly rotated sprite to make the car appear to steer, and also give a side on view of the other cars when you pass them.
I had to make the logic very simple to squeeze it in (it's on exactly 8192 tokens now!) but I think it looks okay.
Also the camera only tracks the car 90% horizontally, so it's not completely fixed in the center of the screen.
I'm not sure if I can improve on the cobblestones. There is some basic "mipmapping" logic to attempt to avoid the moire patterns and it works pretty well for the desert road imo. But the cobblestones are quite a busy texture. I may have to simplify it down a little.
Good game - I love the tunnels (didn’t have a chance to implement them in my Thunderblade demake!).
Token wise you can optimize a lot:
- if x!=nil can be replace by if x then
- clip(0,0,128,128) = clip()
- make use of the local a,b,c=1,2,3 notation
- metatable vector math is nice but not sure that’s a win in your game
- a lot more convoluted but the track/sprite data could be packed in json (see my games) or using a custom encoder/decoder. You can certainly reclaim 100’s of tokens this way
performance wise: you rely a lot on clip for correct drawing.
clip is actually quite taxing cpu-wise (eg it is cheaper to draw extra pixels than clip them!)
Thanks for the tips - I'm fairly new to lua and pico.
Good to know that "nil" is falsy, I never actually thought to check. Other points are useful too.
I'm still not sure whether I'll try to optimise the track and background data yet. I kindof like the limitations that pico imposes, as it stops projects from growing until they stop being fun and start becoming a mountain of work. So trying to circumvent those limitations feels counterproductive. I'm happy to call it done and move onto something else.
I quite like the clip based algorithm - I find it elegant and satisfying to implement, and it's fast enough even if it's not the most optimal (on pico). I assume it's the lua code to calculate and set the clipping regions that is the bottleneck?
On other platforms, particularly on fill rate limited devices, it's quite performant, because you can draw the track from front to back with zero overdraw (not counting the sprites). You can even skip clearing the screen initially - just clear the remaining clip rectangle to the sky colour after drawing the road.
It still seems like the road automatically turns in the direction to keep the player on the road whether they themselves are turning the wheel or not.
You can see this in going at a straight-away and when a turn comes up, continue straight. You will see it 'seems' as if the player is turning to stay on the road.
If this is to assist the player because of a difficulty level, that's fine. But modern racing games today completely allow you to drive off the road without automatically rotating the road to prevent it.
@dan9er: More background graphics would do it. I had to reduce the frequency of the buildings on the city stage to keep the CPU under 100%. pico doesn't have a scale map command (afaik), so to draw the buildings it has to issue a sspr for each tile.
Could extend the background generation logic to support multiple background objects on the left/right to make more interesting scenes.
Although the cart is out of tokens and compressed space, so you'd have to find a way to free up some.
Another simple change would be to up the # of cars, and start them closer together. Maybe change it to generate longer stages too. Might be interesting.
@dw817: Yeah I was going for a pretty simple arcade model. It is possible to implement a more realistic steering model with this pseudo 3D approach (as long as you don't let the car turn too far), but that gives a different type of game-play.
:-) I gave the other drivers names of random people I know (except for Dick and Harry).
The game assigns random speeds to each driver when it boots up, and it doesn't change them between races. It was going to have a championship mode where you race on each track and it tracks your score over all of them, so whoever is the fastest CPU driver would be your main rival for 1st place in each race.
[Please log in to post a comment]