# homebrew Taxi Panic!

## Recommended Posts

The physics and smooth animation made it fun just driving around on the buildings, am i crazy or would it be possible to also turn this into a micro machines/rc pro-am style racing game? The mini map is the only problem I can think of.

##### Share on other sites

Thanks for the feedback everyone! I've made some progress on collision detection/response now. Basically if I detect a collision between the player and the playfield, I switch to a special mode for a frame where I put 1-pixel missiles forward and to the left/right of the front of the car. based on which of those collides with the playfield (or doesn't), I decide which way to turn the player to "steer out" of the collision:

It's working OK. You can still get stuck in collision in a few cases, but with a bit more logic I think I can make it work.

Here's a build you can try driving around the city:

##### Share on other sites

The physics and smooth animation made it fun just driving around on the buildings, am i crazy or would it be possible to also turn this into a micro machines/rc pro-am style racing game? The mini map is the only problem I can think of.

You're right, the core car physics "feel" a lot like RC Pro-Am. That might be another nice application of this car movement/physics code.

##### Share on other sites

I've made some progress on collision detection/response now. Basically if I detect a collision between the player and the playfield, I switch to a special mode for a frame where I put 1-pixel missiles forward and to the left/right of the front of the car. based on which of those collides with the playfield (or doesn't), I decide which way to turn the player to "steer out" of the collision:

I think you can put the pixels inside the car. If the speed is 1 pixel/frame or less then put it 1 pixel inside the car for one axis. For the other axis, put it at the corner.

Example (dX, dY = speeds in x and y direction) 1 < dX <= 2; 0 < dY <= 1 pixel/frame):

• pixel 1: x-corner, y-corner-1 (rounded up dY)
• pixel 2: x-corner-2 (rounded up dX), y-corner

That way the detection pixels should be much less obvious. And you can keep them enabled all the time and save on frame for detection.

Edited by Thomas Jentzsch

##### Share on other sites

Maybe you could make the car change color instead of flashing the screen when there is a collision.

##### Share on other sites

Maybe you could make the car change color instead of flashing the screen when there is a collision.

I think that is only a (debugging) placeholder. A crash sound would be much more appropriate.

##### Share on other sites

Whow. This looks like a killer game of 2016... And right now all in 4k!

##### Share on other sites

Maybe you could make the car change color instead of flashing the screen when there is a collision.

Flashing the screen is OK because we did that in the 80's and the technique looks realy cool in Taxi Panic; I agreed with you flashing the screen was bad with certain colors like white; I had used that for testing and it was a horrible effect. But red is a great color for flashing because of the wavelength. I like it for meteor explosions and it works nicely here with the Taxi for collisions; makes you not want to hit the walls.

You need to get better at the game so you don't see the flash and go into seizures, that sounds horrible.

At least Walabar is not cheating

##### Share on other sites

Flashing the screen is OK because we did that in the 80's . . .

Programmers did a lot of stupid stuff in the 1980s.

But red is a great color for flashing because of the wavelength.

No color is 'great' for flashing. It's a lazy effect that bothers the eyes of some players, so you might as well leave it out.

##### Share on other sites

Programmers did a lot of stupid stuff in the 1980s.

No color is 'great' for flashing. It's a lazy effect that bothers the eyes of some players, so you might as well leave it out.

Programmers do a lot of stupid stuff now that we didn't do in the 80's - some don't like playing games but still write them

imo flashing can be overused which is a good point, but it's an excellent technique and quite effective with the right context. You have a specific disability with your vision so it causes you discomfort.

I understand that because I have double vision in one eye so techniques that cause double vision in games like Thrust where the objects double up on the ground are difficult for me to look at but I can see that it's still a fun game for most folk.

##### Share on other sites

I don't like screen flashing too!

But as Thomas wrote, I think it's only a placeholder.

##### Share on other sites

Thanks for the feedback everyone! I'm not sure if I'll stick with screen flashing, obviously you need *some* feedback when you collide and lose speed, but I'm not sure what it will be in the end. Also the collision response uses Missile 0 and 1, which I'll likely be using for pedestrians or other graphics, which will temporarily disappear when you're colliding... And the screen flash might (or something like it) might help mask that issue.

Anyway I'll keep refining it and soliciting feedback throughout the process. Next I want to refine the collision response a bit more before moving onto adding the pedestrian pickup/delivery system.

Fitting this game into 4K is going to be a significant challenge, I currently only have about 850 bytes of ROM free, and I have a lot yet to add:

- pedestrians who you can pick up and deliver to destinations, with a time limit on the delivery

- overall time limit and scoring system

- HUD for score, timer, arrow to destination, etc

- Some sounds

- Traffic patterns on some city blocks

- Some graphics to help differentiate the destinations.

The current code is not optimized at all, and the data is also ripe for more optimization, but overall it looks like it's going to be tight. I might have to make some changes to the city size or layout (maybe go random?) in the quest for more space.

Obviously I could consider going to 8K w/ bank switching, but I really do like the idea of the game fitting on a "vanilla" 4K cart.

##### Share on other sites

Better flash the car than the whole screen. If in reality a car crashes, the ground doesn't flash too.

And at least one missile could be replaced by the ball.

##### Share on other sites

I've decided to half the vertical resolution of the playfield and get some precious bytes back. My city layout hasn't suffered too much in the change, and it saved me quite a bit of ROM space. Here's a short video of driving around the new, more efficient city.

I've also adjusted the collision response system a bit, it's "tighter" now.

I should have enough space now to start working on the customer pickup and delivery system. Trying to decide how I want to set up the data now.

Here's the current size stats:

```Free RAM: 84 bytes
Code SIZE: 1234 bytes
Data SIZE: 1226 bytes
ROM Free: 1632 bytes
```

##### Share on other sites

Good progress over the last few nights, I've got the basic data layout for my list of destinations (places on the map that customers will want to go to) implemented, and I'm drawing the destination's icon on screen as well:

The idea is that when you pick up a customer, their desired destination's icon will appear in the HUD, along with an arrow that gives you the general direction of the destination. You'll need to deliver them there in a certain amount of time.

I still need to add a few more destinations, and then I'll move onto the passenger data and systems next.

current build size snapshot:

``` Free RAM: 78 bytes
Code SIZE: 1382 bytes
Data SIZE: 1369 bytes
ROM Free: 1341 bytes
```

##### Share on other sites

How are you laying out the room data in ROM? I've been thinking about how to save space with my room layouts in my game, and wondering how you represent them.

##### Share on other sites

I'm not doing much in the way of space-saving... but here's how it's setup:

1. I have a list of city block layouts, which are basically just lists of playfield data. I'm using 8 scanlines per byte, giving me only 12 vertical sections per screen. I've also given myself a limitation that PF2 will always be mirrored (so the center 16 pixels are symmetrical). So that means for an asymmetric screen I need 5 bytes (1 | 2 | 3 | 3 | 4 | 5) x 12 tall, so 60 bytes per screen. I also note if some designs are completely mirror-able and only store 3 bytes for those, so those are 3 x 12 = 36 bytes.

My city is a rectangle, so I have a constant for the number of blocks across and down for the city. Then starting in the upper-left corner, I number each block 0,1,2,3, etc. Given an address of a city block in rows and columns, I calculate the block index like so: (row * CITY_BLOCKS_ACROSS) + col.

I use this index to lookup some data in a master table, which tells me which playfield data to use for that block, what color the PF should be, whether the block is symettrical or not, etc.

example of the block table:

```Block_0_0
.word CityBlock0x0_0
.byte #%00000001
.byte #\$C8
Block_0_1
.word CityBlock0x1_0
.byte #%00000000
.byte #\$78
Block_0_2
.word CityBlock0x2_0
.byte #%00000001
.byte #\$E8
...etc
```

hopefully that makes sense. I know I have a lot of repeat data sections in my ray playfield data, but since I use stride calculations to find data, I'd need to write more code and make my master table bigger if I wanted to overlap data that's shared between block designs. Later if / when I'm pressed for space I'll do more examining to see if this will be a net savings or not.

##### Share on other sites

Cool, thanks for the explanation!

##### Share on other sites

I put in the first set of destination data by hand, mostly to test out my data formatting and code to load the data in the actual game. Now that it's working, I've started updating my city editor so that I can design and adjust destinations there. This will make it much easier to make changes and tweak the game as it becomes more playable.

Here's a shot of the editor, you can now see the little destination icons on the city blocks that I've set up so far.

##### Share on other sites

Looking awesome! What are the controls? I assume this has to be a joystick game to hit the brakes? Or would this also work with a paddle or driving controller?

##### Share on other sites

Looking awesome! What are the controls? I assume this has to be a joystick game to hit the brakes? Or would this also work with a paddle or driving controller?

Right now it's Joystick, FIRE button to accelerate, left/right to steer, and down for brakes. I would like to support the paddle/driving controller if possible, although I'm not sure I'll have time in the kernel since from what I've seen you need to read the value multiple times per frame. I think it controls pretty well with the controller though.

##### Share on other sites

Have you mentioned how you are making your animated GIFs? Seems like that would be a useful thing to know.

##### Share on other sites

Have you mentioned how you are making your animated GIFs? Seems like that would be a useful thing to know.

I use a simple program called LICEcap which is available for Windows and OS-X. I just record myself playing the game in Stella with that. It's a pretty great program.

##### Share on other sites

I use a simple program called LICEcap which is available for Windows and OS-X. I just record myself playing the game in Stella with that. It's a pretty great program.

Thanks. I just downloaded it. What is the Max FPS setting that you use?

30fps.

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

• ### Recently Browsing   0 members

×
×
• Create New...