Overhead driving engine development

[presh]

This is why I was asking about fixed point arithmetic a few weeks back

It's very early days, loads of improvements to make as it's using some very goofy pseudo-physics to keep things ticking over quickly, nevertheless it's pretty fun to bomb around at top speed using the handbrake to skid around corners

At the moment, I've limited the frame rate with a couple of HALTs to provide some headrooom for displaying/processing other vehicles etc. I'm looking to add some computer-controlled vehicles soon, which will follow the arrows currently visible on the road tiles (relating to the "traffic direction" flags for those tiles).

The collision detection/resolution was an absolute bast to get working, of course. I'm tempted to do a write-up on it before I forget the details, as it's actually pretty simple once it's written out in pseudo-code, and can be applied to any tile-based map (e.g. platform games). It's using a single AABB for the car for now, though I intend to use a pair eventually to improve accuracy.

One of the most obvious things from playing is that the position at which the screen flips & the amount it flips by, gives you very little time to react to that house you're about to smash into... so next on my agenda is figuring out a better screen flip position/amount.

https://www.youtube.com/watch?v=EeyzL27R3EI

[Jbizzel]

Grand theft ZXauto here we come!!

Looks brilliant

[presh]

Grand theft ZXauto here we come!!

Looks brilliant

Heh! The thought had crossed my mind... I mean, that car is clearly the Bulldog from GTA I



And realistically, I suppose the point where it starts feeling like a game will be when I'm trying to run as many people over as possible until my car explodes

[Jbizzel]

The zx version you might drive around killing trash men, Horace and frogs

The car movement looks super smooth btw

[Sokurah]

The zx version you might drive around killing trash men, Horace and frogs

Horace is an icon - just like Chuck Norris.
If you drive into him you'll wreck the car

[Morkin]

Looks pretty cool, seems as if there's a nice balance of momentum/inertia.

A combination of a slightly earlier screen flip and small map design tweaks would probably help, though I guess some driving games rely on players learning the map as well as skill.

[clebin]

Heh! The thought had crossed my mind... I mean, that car is clearly the Bulldog from GTA I

My first thought was the Gameboy Color version of GTA!

That was pretty cool in a lot of ways, but the mechanics were lacking. If only they’d added some drift to the car like yours, it would’ve been a classic.

https://www.mobygames.com/game/gameboy ... theft-auto

[Ralf]

Looks nice, what will be the goal of the game?

You should really look at existing similar games like Miami Vice to what's good and
what's bad about them.

Miami Vice is actually a bad game. It looks nice but it's very easy to crash and you can completely miss
the game plot and never achieve anything.

[Turtle_Quality]

Looks pretty cool, seems as if there's a nice balance of momentum/inertia.

A combination of a slightly earlier screen flip and small map design tweaks would probably help, though I guess some driving games rely on players learning the map as well as skill.

Looks great but as Morkin says there's a danger of crashing without warning on screen flip - especially when enemy vehicles are added. Could there be an "overlap" between screens ?

[Joefish]

I presume you limit the turn rate of the vehicle, so that at faster speeds you end up taking wider turns?

And then there's some X/Y momentum calculation that dies off with friction, so if you turn fast enough it leaves you skidding for a bit in the direction you were travelling? (I mean, rather than modelling side-slip at right angles to the car, you just model it in X and Y map directions).

I'm not sure how sophisticated a model you'd need to be able to pull off some good powerslides, that's all...?

[Morkin]

One thing some games do is scroll in the new screen rather than flip it.

Not as in constant screen scrolling, just when you get to the edge, a bit like Quazatron or Thrust.

Main issue is it's often accused of looking a bit ugly, though depending on how fast it's scrolled in it can give the player chance to react (so probably wasn't needed for Quazatron after all ).

Then again, not sure how well it'd work, it might be preferable to keep it just flip screen, and encourage the player to learn the map a bit.

[Evil Genius]

Looks good, like 'Trashman goes TWOCing' That kind of 'nudge-scrolling' as I call it, is ok if it's done quickly enough. On Quazatron it looks bad because it's a bit slow, i guess due to the pseudo-3d view. Alternatively, you could have a city map on the right hand side of the screen.

[presh]

You should really look at existing similar games like Miami Vice to what's good and
what's bad about them.

I'm struggling to find much in the way of top-down flip screen car related stuff to be honest! I've had a dig through the database here. And yes, Miami Vice is beyond awful so I can't really glean much positive inspiration from that!

[bob_fossil]

How about Give My Regards To Broad Street ?

[presh]

How about Give My Regards To Broad Street ?

That looks more like it! Though watched a bit of footage and noticed the car does that funny "turn around on the spot" thing I'll give it a bash anyway!

[presh]

A few tweaks:

Collision resolution improved, so the car bounces off the walls. This makes it feel more forgiving, as it's easier to rectify yourself with a bit of space. Once I have upgraded the collision detection to two bounding boxes (one front, one rear) it should be possible to add some rotational correction also, depending which box was resolved and in which direction.

Damage "score" added. Faster collisions = higher damage. This is also fairly forgiving, as scraping your car against the wall (cosmetic damage, perhaps?) does not cause any actual damage. Chucking your car into a corner wall at high speed (as I do at the end!) does quite the opposite!

There's also a small red border flash when a collision is resolved, just as a visual indicator for the moment. Ideally this will evolve into a suitably crunchy noise, depending on the amount of damage done.

And in line with what [mention]Morkin[/mention] and [mention]Turtle_Quality[/mention] mentioned, I've pulled in the flipping point considerably so that your eyes aren't having to dart around quite as much. Feels much better now.

Regarding the idea of "nudge-scrolling" (to steal [mention]Evil Genius[/mention]'s nice description!), I originally had ambitions for full 8-way pixel-perfect scrolling but given how huge a task that would just be to get running (let alone quickly!) I decided to plump for flip-screen primarily for simplicity, so I could focus on getting the car movement right. It also means I can use colour... very difficult to do right with non-cell-based scrolling, which I imagine would look horribly jerky. I'd be interested in seeing some decent nudge-scrolling examples, particularly in colour - I can only think of APB, which is monochrome and I always thought the way it scrolled was pretty annoying, though looking at it right now I can't imagine being able create something better!

https://www.youtube.com/watch?v=HUarb2QOaws

[presh]

Hoping to make some good progress on this over the long weekend

I managed to fix a bug last night at around 3:30am I'd been comparing a value which hadn't been updated yet, and this caused the collision resolution between cars to fail, as once of the core assumptions which allows it to work - objects must begin and end their turn in a state of non-collision - was no longer true. It was a real bugger to find, so I was overjoyed to fix it and I went to bed very happy

Collision detection has been my life for the last few weeks it seems, and will be for the next few days too as I aim to finish the car-vs-car collision.

I did make some progress with optimising the sprite shifting earlier this week. The graphics aren't pre-shifted (that would require 12K per vehicle sprite instead of 1.5K!) but I managed to get it down to a maximum of 2 shifts using a combination of RL, RR and RRD... e.g. previously the 7-pixel shift was just 7 x RR (lazy!!!), now it's a single RL. Shifts of 3, 4 or 5 pixels use RRD to skip 4 pixels initially, followed by a single shift (RL for 3px, RR for 5px). The timings are generally shorter and much closer to uniformity now that only 2 shifts are required, so that's nice

[presh]

Also I'm 100% certain I added a 3rd video a few weeks back! It, and subsequent replies, seem to have vanished... weird

[Morkin]

I managed to fix a bug last night at around 3:30am I'd been comparing a value which hadn't been updated yet, and this caused the collision resolution between cars to fail, as once of the core assumptions which allows it to work - objects must begin and end their turn in a state of non-collision - was no longer true. It was a real bugger to find, so I was overjoyed to fix it and I went to bed very happy

...Nothing beats finally being able to go to bed after resolving a bug...

I did make some progress with optimising the sprite shifting earlier this week. The graphics aren't pre-shifted (that would require 12K per vehicle sprite instead of 1.5K!) but I managed to get it down to a maximum of 2 shifts using a combination of RL, RR and RRD... e.g. previously the 7-pixel shift was just 7 x RR (lazy!!!), now it's a single RL. Shifts of 3, 4 or 5 pixels use RRD to skip 4 pixels initially, followed by a single shift (RL for 3px, RR for 5px). The timings are generally shorter and much closer to uniformity now that only 2 shifts are required, so that's nice

Nice to have used RRD, I've always wondered where I could use those functions (like [mention]R-Tape[/mention] and his quest to use CPIR).

[catmeows]

Thé engine looks very promising.

[toot_toot]

The graphics totally remind me of Trashman! Maybe it could be used to make a game where you get to drive the trash, I mean rubbish lorry. Kind of like a spin off of Trashman!

Or you could make a 100% better version of Miami Vice

[presh]

...Nothing beats finally being able to go to bed after resolving a bug...

Indeed! Not that it prevented me from charging head-first into another one almost immediately... though at least I was finished by 1:30am this time

Nice to have used RRD, I've always wondered where I could use those functions (like @R-Tape and his quest to use CPIR).

Yeah, I understand RLD/RRD are used to multiply/divide BCD numbers by 10 but is most commonly used for 4 pixel scrolling in Speccy games

[presh]

The graphics totally remind me of Trashman! Maybe it could be used to make a game where you get to drive the trash, I mean rubbish lorry. Kind of like a spin off of Trashman!

Or you could make a 100% better version of Miami Vice

Trashman and Miami Vice both have repeated mentions in this thread. The obvious difference being that Trashman isn't utter horseshit.

Perhaps I should combine the two... a struggling Private Investigator who's also a part-time bin man to make ends meet?

The tagline writes itself though:

"IT'S TIME TO TAKE OUT THE TRASH!!!"

[presh]

Jeez, I keep having a crisis of confidence because I keep finding bugs in my supposedly watertight collision detection algorithm. Every time I fix one, another appears - or two, in the last case!

One I'd anticipated and isn't so much a bug as an anomoly which means you can't turn if you're right against a wall and parallel to it. I know how to fix this one (I think!)

The other I think is an artefact from an assumption I made to try and fix a bug which was itself caused by another incorrect assumption. I haven't been able to replicate it in the "real world" (i.e. when actually playing the game) but I've seen it when firing test values at the collision engine (i.e. I discovered it while lab testing something else)

One thing I've noticed is that the further I progress, the more specific the conditions need to be to "trip up" the logic - I could easily replicate the earlier bugs, but gradually they became more difficult to replicate. It definitely seems to show things are going in the right direction. But you just know that someone, somewhere, at some point is gonna hit the magic combination and have their game ruined by getting anchored to a wall or something

It just feels like the more I add caveats to it, the further away I move from the "pure" simplicity of where I began. And the more that happens, the more complex the whole thing becomes, and the more opportunities there are for flawed logic to arise, while also becoming more painstaking to debug

I'm trying not to let it get me down too much though - the collision resolution code is "pluggable", so could be entirely replaced / rewritten from scratch if necessary without affecting the rest of the code, which takes the pressure off a bit. It certainly feels "good enough" for now, so I'm tempted to worry about it later, rather than getting stuck in Collision Hell worrying about what are potentially 1-in-a-million glitches.

On the positive side, there are still plenty of other fun & interesting things to be done. I've designed a variety of (better looking!) cars, also figured out a way to cut the amount of car graphics down by 44% because 7 of the 16 frames are just vertically-flipped versions of other frames, achievable by changing how I write them to the pixel shifting buffer, hopefully with a minimal enough performance hit to justify it. That would bring a single car's graphics data down from 1536 bytes to 864 bytes, so space for more car varieties or bigger maps or whatever

[Ast A. Moore]

It’s good practice to walk away from a particular piece of code and work on something else, if only to give your brain a rest. Finding unusual bugs like those you’re describing can be daunting. I often run my game in an emulator while recording it to an RZX file. That way, if you catch a rare bug, you can rewind and find the exact conditions that trigger it. It’s not the fastest way, but it’s fool-proof (if you hit the bug, that is).