Spectrum Computing

Ast A. Moore wrote: ↑Wed May 05, 2021 11:43 pm 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).

Thanks man. After easing off for a couple of days, I've realised where the problem lies. I'm 99% sure my single AABB collision is watertight - all issues have arisen since adding a 2nd AABB to the car. I made some assumptions here which now seem ridiculous, so a rewrite of that section is on the cards!

But not yet... I have more fun things to sort out first

I'll have to look into RZX format, I'm using Spectaculator which seems to support it. I think I need to get my head around debugging properly in the emulator too, I've solved a few things with it but more by chance than anything else!

So far I've been using video recordings of lab experiments with appropriate values output to the screen, then using VLC to observe things frame by frame with the "E" hotkey. Also border flashes to signal when the program reaches certain points. Might be time to level up my debugging skills!

There's an old adage that the first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

presh wrote: ↑Fri May 07, 2021 4:47 pm So far I've been using video recordings of lab experiments with appropriate values output to the screen, then using VLC to observe things frame by frame.

Yeah, no, this is very limiting. With an RZX recording, you can set breakpoints close to when the bug occurs and examine the state of the machine in great detail. An ordinary video recording is not going to give you much information aside from some visuals (which are always secondary to the actual bug). Seriously, RZX has saved my ass many times, especially in some tricky runaway-stack situations.

About time for another update

Up to 4 cars on screen at once. Cars are despawned when they drive beyond the edge of collision map (16 x 16 tiles, compared to 12 x 12 tiles visible on screen) and are spawned from the edges of the screen when spare slots become available.

Sprites are now clipped correctly at screen edges. This implementation still requires some optimisation before being extended to the display routine for inverted car graphics.

Some new car designs added.

All cars in the demo are computer-controlled, each with different settings for acceleration, brake, top speed, etc. This will allow the different car models to have different handling characteristics.

Collisions between cars still need to be resolved!

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

Collisions are, for me, the worst and most difficult thing to develop... I promised myself that first thing I'll do before begin writting a game, from now on, is to design the collision routine...

First attempt at collision resolution between cars!

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

Nice... Look forward to playing the final game...

What are the diagnostics/numbers on the right of the screen for?

Cheers!

0123 - represent the active car slots

Then for each car, its velocity (car_v) and a value representing loss of traction (car_skid)

It's all a bit of a fudge at the moment, but I've been preparing some super-cute low-budget trigonometry which I'm hoping will improve the fluidity of the collision resolution. At the moment, it feels nice smashing into a bunch of cars, but escaping the aftermath can be sluggish. The NPC AI needs a tickle too regarding this, but hey ho - for a quick & dirty implementation just to get the ball rolling, I'm pretty chuffed. Onwards!

Looks good to me. I like that there's a little overlap on collision, more satisfying that way than having them "crash" just because they're next to each other on screen.

I saw one or two computer cars got stuck when pushed into the corner - I guess they don't know how to reverse.

Great progress. Thanks for sharing the process, too

With all the dynamics already in place in this phase, it looks that it's going to be a pretty fun game with a high level of playability.

Turtle_Quality wrote: ↑Thu May 27, 2021 10:15 am Looks good to me. I like that there's a little overlap on collision, more satisfying that way than having them "crash" just because they're next to each other on screen.

Agree. Maybe the flaws are more apparent if you play it, but it looks easily good enough from where I'm sitting. I don't know if it helps save a bit of CPU time to use for something else? I admire your perfectionism though [mention]presh[/mention].

Excited to see this game developing!

clebin wrote: ↑Thu May 27, 2021 11:05 am

Turtle_Quality wrote: ↑Thu May 27, 2021 10:15 am Looks good to me. I like that there's a little overlap on collision, more satisfying that way than having them "crash" just because they're next to each other on screen.

Agree. Maybe the flaws are more apparent if you play it, but it looks easily good enough from where I'm sitting. I don't know if it helps save a bit of CPU time to use for something else? I admire your perfectionism though @presh.

Excited to see this game developing!

Yeah, a little overlap was inevitable as I'm only using 2 axis-aligned bounding boxes (AABBs) for the cars as computationally they're very cheap / fast. I was worried that the result might turn out crap, but it actually feels pretty good especially now it can make the distinction between "head on" collisions and ones with some direction in common, setting values accordingly.

Here's an example of how the AABBs (black/green) are arranged for one of the directions:


And [mention]Turtle_Quality[/mention] is right that the cars don't know how to reverse at the moment. They just put their foot down and try to steam ahead no matter what's happening! I need to add a few more behaviours to the cars to make them less aggressive & help them find their way out of sticky spots...

presh wrote: ↑Tue Jun 01, 2021 4:00 pm Yeah, a little overlap was inevitable as I'm only using 2 axis-aligned bounding boxes (AABBs) for the cars as computationally they're very cheap / fast. I was worried that the result might turn out crap, but it actually feels pretty good especially now it can make the distinction between "head on" collisions and ones with some direction in common, setting values accordingly.

Here's an example of how the AABBs (black/green) are arranged for one of the directions:

Sorry to sound a bit dumb, but can you expand on that? What do all the black/green/yellow bits signify in that graphic?

I (fairly) recently wrote an article on collision detection, so I feel I should immediately understand what you're saying. But I don't, immediately or otherwise.

dfzx wrote: ↑Tue Jun 01, 2021 5:18 pm

presh wrote: ↑Tue Jun 01, 2021 4:00 pm Yeah, a little overlap was inevitable as I'm only using 2 axis-aligned bounding boxes (AABBs) for the cars as computationally they're very cheap / fast. I was worried that the result might turn out crap, but it actually feels pretty good especially now it can make the distinction between "head on" collisions and ones with some direction in common, setting values accordingly.

Here's an example of how the AABBs (black/green) are arranged for one of the directions:

Sorry to sound a bit dumb, but can you expand on that? What do all the black/green/yellow bits signify in that graphic?

I (fairly) recently wrote an article on collision detection, so I feel I should immediately understand what you're saying. But I don't, immediately or otherwise.

Sure.

I was being lazy and drew the AABBs using the sprite mask layer in SevenuP, which is why it's highlighting the AABB boundaries black if the pixel is empty, or green if the pixel is filled. That's just how SevenuP colours pixels in the mask layer & has no significance here!

The yellow pixels are the filled pixels which aren't on an AABB boundary (compare with original sprite in right-hand image)

The images in your article are much clearer, e.g.



...so just try and visualise that green/black mess similarly!

presh wrote: ↑Tue Jun 01, 2021 6:10 pm The yellow pixels are the filled pixels which aren't on an AABB boundary (compare with original sprite in right-hand image)

Oh, I see now! It's actually just 2 squares. Mentally think of the the green pixels as black and it makes sense.

Thanks!

it makes me think a little of badlands, but only because everything does because it's probably my favourite game

presh wrote: ↑Wed May 05, 2021 10:41 pm ...

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

...

That sounds a lot like hacking it away ... and it will eventually catch up with you in the future.

Progress has been slow recently... trying to buy a house, so that's left very little free time to do much else!

...but finally, an update!

I've ventured into 128K territory for the first time, using one of the pages to hold all of the car graphics data. This will allow many more car models to be added. I'm also aiming to do the same with the map / tiles, so that the map can be much bigger.

Yesterday I made it so that the cars can be destroyed by entering the water (sploosh!) or by taking too much damage (boom!)

The cars in this demo are spawned with very little energy to make them easy to destroy. The player car has a bit more to begin with, but eventually that goes boom as well!

A side effect of the existing car spawning code is that if the player's car is destroyed, it will eventually be respawned (with "not much energy", same as the other cars). As a result, it's starting to feel a bit like a game... particularly if the car that killed you is still on screen, you can chase after it and exact your revenge...

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

Oh, this is brilliant! I love the fact that the puff of smoke keeps moving following the trajectory of the car. Many programmers (myself included) are too lazy to bother with that, and explosions remain static even if the object was moving before exploding.

The whole project is becoming more and more exciting to follow!

P.S. Just a thought. Since you’re targeting 128K machines now, have you toyed with the idea of using the shadow screen and drawing the next playing area onto it? That way you could just instantly switch between the two display banks and the flickering between the screens would be unnoticeable.

You could start slowly building up the scenery in the second screen when the player’s car is a certain distance away from one of the four edges of the current screen.

Again, just a thought.

Ast A. Moore wrote: ↑Sun Jun 20, 2021 7:18 pm Oh, this is brilliant! I love the fact that the puff of smoke keeps moving following the trajectory of the car. Many programmers (myself included) are too lazy to bother with that, and explosions remain static even if the object was moving before exploding.

The whole project is becoming more and more exciting to follow!

Thanks! I've actually used a really cheap/efficient/lazy hack to achieve that - the car remains active until the explosion ends. When displaying an exploding car, I just display an explosion instead of the usual car graphic. Then when moving the car, just remove the ability for the car to be "driven" (no turning, accelerating, etc) and leave it to the *cough* "physics" engine to handle the rest. It does however mean that other cars can still crash into an explosion and send it flying the other way, which is not realistic but still looks kinda cool

P.S. Just a thought. Since you’re targeting 128K machines now, have you toyed with the idea of using the shadow screen and drawing the next playing area onto it? That way you could just instantly switch between the two display banks and the flickering between the screens would be unnoticeable.

You could start slowly building up the scenery in the second screen when the player’s car is a certain distance away from one of the four edges of the current screen.

Again, just a thought.

You mean bank 5? That's actually a really interesting idea... I've struggled to figure out a use for it - it seems almost useless for scrolling games (where everything potentially needs doing twice) but as a use case for flip-screen, that has potential. I suppose it depends how much "action" there is in the HUD, as any changes there will also need transferring. As I haven't decided what the game is yet, I've no idea! But assuming it's minimal - e.g. mostly a static banner, with just with score, lives, speed, etc changing - it should be quick enough to do.

presh wrote: ↑Sun Jun 20, 2021 10:43 pm You mean bank 5?

Well, Banks 7 and 5. The idea is to start rendering the next flip screen as soon as the player’s car is near an edge and then switch the banks when a screen flip normally happens.

You’re right about the HUD, I hadn’t considered that. But the text can be rendered pretty quickly right after a bank switch. Any static graphical elements can exist as copies in both banks, so that wouldn’t add any delay.

I've been unable to spare much time lately, so progress has been somewhat slow.

That said:

- inverted vehicles are back, now with clipping at screen edges

- adjusted some map tile attributes for better visual clarity, i.e. inverted cars stay black (as much as possible), and regular cars always take the INK colour

- explosions cause significant damage to other vehicles close by, often causing them to explode immediately

- vehicles flash when they are about to explode, so you can keep your distance!

- NPC cars can reverse and turn around to find their way out of tight spots, though this is still very simplistic - I've initialised the NPC cars so that they inevitably crash & make use of this logic, which you can see at the start of the video in all its janky glory.

https://youtu.be/FVCO-QEkF1U

The first game is now looking like it could be a top-down Chase HQ style game, but with enemy cars to ram & enemy pedestrians to squish... so perhaps more like the GTA "vigilante" missions. An obvious choice would be to have all of the enemies use the inverted display method to make them easy to spot. I still have to add the pedestrians & their logic, but this was next on the cards anyway. After working solely on cars for what seems like forever, I'm looking forward to a change!

The biggest annoyance I have at the moment is a classic 8-bit trope: if I drive off one screen but then re-enter the same screen a few frames later, none of the sprites are there any more. This is because the game runs on a 16 x 16 cell grid of 16px x 16px tiles, giving x and y coordinates an effective range of 0-255. When the screen switches, any sprites which landed outside of this area are despawned immediately. The issue is particularly noticeable if you are chasing a car which makes it to the despawn point at the edge of the play area just before you hit the screen flipping point - the car which was just in front of you has disappeared into thin air!!

I'm currently figuring out how to implement a way to track cars "off grid" for a period of time without having to expand the available playing coordinates beyond 0-255, as this would require more than 8 bits per coordinate* leading to a huge performance hit. An approximation of their position on the overall map seems more plausible, though not without its own complexities! This version however will also allow, say, a "boss" enemy car to trace its way around the map regardless of its distance from the player.

* as an aside: the coordinates are already 16 bits, in 8.8 fixed point form - however only the integer part (top 8 bits) are used to determine collisions etc

OK, so now we're getting somewhere!

I held off posting any updates for a while as I wasn't sure I'd make it this far without things slowing down to an unacceptable level.

However I think we can all see where this is heading now...

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

The big change here is: Pedestrians!
- player can now travel on foot or in car
- up to 8 active at once (with up to 4 in vehicles)
- all pedestrians can enter/exit vehicles; entry is only possible at low speeds, such as when cars are cornering. The driver can bail out a higher speeds, though this puts them on the floor for a while (depending on the speed at time of exit) leaving them vulnerable to traffic etc until they can get up again.
- NPC pedestrians include some simple behaviours such as panicking if there's an explosion, a hit & run, or if they have a near-miss with a car; very panicked pedestrians may also attempt carjacking to escape!
- AY sound effects for engine noise, collisions, explosions & deaths
- 8 vehicle types

Since posting the video, I've made some progress on the scoring system. The two lowest numbers on the right show how many of each pedestrian type (normal or inverted) have been killed. The latest version also tracks vehicles destroyed. The idea is that you pick the colour of your gang at the start (normal or inverted - i.e. INKy or PAPERy), then try to gain control of the city by destroying the opposing gang members and their vehicles. Some pedestrians/drivers will be docile, whereas others will become aggressive if provoked.

I've also added a sound effect for entering/exiting a vehicle which definitely helps clarify what's going on there, but it's currently a bit crap and needs improving!

Biggest problem right now is that I'm having so much fun playing it and having "just one more go" that I keep running out of time to actually do any dev on it

I'd like to think this bodes well in terms of playability, but then I guess most programmers found their games playable even if the reviewers & general public ended up disagreeing...

presh wrote: ↑Wed Sep 29, 2021 4:09 pm Biggest problem right now is that I'm having so much fun playing it and having "just one more go" that I keep running out of time to actually do any dev on it

Oh, yeah. Been there.

presh wrote: ↑Wed Sep 29, 2021 4:09 pm I'd like to think this bodes well in terms of playability, but then I guess most programmers found their games playable even if the reviewers & general public ended up disagreeing...

The biggest downside to playing your game over and over again is that you get so good at it, that you overlook how a first-time player will react to it. I had to add two difficulty levels to Yankee (medium and easy), because virtually everyone had complained the game was too hard and no one lasted more than a few seconds. Me? I thought it was still way too easy even on hard.