IGNORED

# homebrew Taxi Panic!

## Recommended Posts

Hey everyone! It's been a while since I've worked on anything atari, but I've started up a new homebrew project that I hope to finish, tentatively called "Taxi Panic!". It's a top-down city arcade taxi game, I'm aiming for a city that's maybe 7x5 screens or so in size. You'll be picking up fares and delivering them to their destinations while the clock ticks down. Sort of a 2600 homage to Crazy Taxi.

So far I've got a first pass at the driving physics and car sprites implemented, and now I'm working on designing the city layout. I'm trying hard to make the car physics feel as smooth and "analog" as possible, right now the movement works in 11.25 degree increments (32 directions), and the visual sprite has 16 increments (22.5 degree precision). movement values are based on a lookup table for sin/cos values times an acceleration curve for speeding up and slowing down.

The city will be created entirely with the playfield, and I need each screen to line up properly, so in order to make designing it easier, I've decided to make myself a little tool:

It's an app (made in Unity, since I'm familiar with it) that actually runs on my iPad, and lets me design the city easily. Eventually this data will be exported out of the app into playfield data for the game.

Anyway, I'm starting this thread because getting feedback tends to keep me motivated. Let me know what you think!

Edited by walaber
• 12
##### Share on other sites

Nice!

The 16 increments and driving physics gives it a unique polish that usually isn't done in 2600 games.

I remember an old Atari 800 type in program about bounce physics in Antic, October 1984.

It really felt like a rubber ball.

You could change the gravity to the point where the bounce gets higher each time.

Never figured a way to make a game with it, but it was impressive how one object with a little bottom squish animation frame and just a few variables of force, gravity, x, y, gave a convincing rubber bounce animation.

Heh, it was co-authored by the man that spearheaded Rescue on Fractalus... no wonder I was so impressed.

I tried to make a version on Atari 2600 - you mainly only need the variables and animation loop math, but I never succeeded.

##### Share on other sites

Looks good so far.

I would suggest that you give the car some inertia, so that cornering becomes more difficult. Will it bounce from the buildings? Or crash?

How about predefined city tiles, which can be randomly combined into new cities?

##### Share on other sites

Like Nintendo DS GTA Chinatown Wars taxi game!

A W E S O M E !

##### Share on other sites

Looks good so far.

I would suggest that you give the car some inertia, so that cornering becomes more difficult. Will it bounce from the buildings? Or crash?

How about predefined city tiles, which can be randomly combined into new cities?

Good ideas. I agree w/ the inertia comment, I worked on it a bit today and it already feels like an improvement:

I think you will bounce off buildings and lose speed, the collision detection response will be a challenge for sure.

I like the idea of a randomized city (and may need to do this since I want to fit the game in 4k), although my preference is a fixed city that you learn slowly and start to figure out the fastest way to get to different places on the map.

I'm probably going to have to go with a flickering kernel for this as well, since I'll need a fair amount of sprites on-screen (potential passengers, traffic, some kind of navigation arrow).

##### Share on other sites

If it is near as fun as Wall Jump Ninja then I am sure this game will be another gem

##### Share on other sites

Very cool! I like the idea, I'm a fan of crazy taxi and those car physics look great! Very original!

Very cool editor too, that'll make things a lot easier.

##### Share on other sites

I want to fit the game in 4k

Aha! I was wondering why you were going with 32 directions but only 16 images.

If you end up having to expand the ROM size, please consider using some of the extra space to increase that to 32 images.

##### Share on other sites

Aha! I was wondering why you were going with 32 directions but only 16 images.

If you end up having to expand the ROM size, please consider using some of the extra space to increase that to 32 images.

yeah, I've already made some tweaks so that when you release the steering input, I clamp the underlying movement angle to what you're seeing on-screen, so that you never see the car pointing straight up but it's actually moving at a slight angle for example.

we'll see how difficult it is to keep this under 4K, some quick math on the size of the playfield data means I might have to give up on that, or come up with a lot of effort to compress the data.

##### Share on other sites

Nice game, I like the physics on the Cab! Very cool if you can keep it under 4K

##### Share on other sites

my editor is now exporting data (it generates a text file and attaches it to an email so I can send it from my iPad to my PC easily), and it seems to be formatted correctly. here's what the current city layout looks like:

and here's a few of those screens in-game:

Now I need to make a proper system for driving from 1 screen to another, which will require a meta-table of data. Does anyone know the proper syntax in DASM to store the address to another label somewhere else in the program?

for example if I have:

```PlayfieldData_0
.byte #%00101101
.byte #%00111101
(etc)

PlayfieldData_1
.byte #%00101101
.byte #%00111101
(etc)

Screen0_Data
.byte #%00000101  ; (flags, whatever)
```

do you know what I mean? I expect to have a variable in RAM that says what room I'm in, and I need a way to use that to look up into a table and get some data about the room (various flags, etc), in addition to pointers to the playfield data for that room (which is likely shared with other rooms).

##### Share on other sites

Is this what you're looking for? dc.b or dc.w is for data constant byte and word respectively. > takes the high byte of a word and < takes the low byte of a word. Looking forward to a demo of this. Keep up the great work!

```StageHBLU
dc.b >Stage0Col0,>Stage0Col1,>Stage0Col2,>Stage0Col3,>Stage0Col4,>Stage0Col5,>Stage0Col6,>Stage0Col7,>Stage0Col8,>Stage0Col9

StageLBLU
dc.b <Stage0Col0,<Stage0Col1,<Stage0Col2,<Stage0Col3,<Stage0Col4,<Stage0Col5,<Stage0Col6,<Stage0Col7,<Stage0Col8,<Stage0Col9

Stage0Col0
;   BL GY GN BR
HEX f9 00 06 00   f0 00 0f 00   00 00 ff 00   00 00 ff 00   00 00 ff 00
HEX 00 00 ff 00   00 00 ff 00   00 00 ff 00   00 00 f6 00   00 00 f4 00
HEX 00 00 f0 00   00 00 f0 00   00 04 60 00   00 06 40 00   00 06 00 20
HEX 00 06 00 a0   00 0f 00 f0   00 0f 00 60   00 00 00 ff   aa ff aa ff
```
##### Share on other sites

Now I need to make a proper system for driving from 1 screen to another, which will require a meta-table of data. Does anyone know the proper syntax in DASM to store the address to another label somewhere else in the program?

use WORD. An example you're probably familiar with:

```        ORG \$FFFA        ; set address to 6507 Interrupt Vectors
.WORD InitSystem ; NMI
.WORD InitSystem ; RESET
.WORD InitSystem ; IRQ
```

Conveniently the ARM processor in Harmony/Melody is also little-endian, so data tables in the 6502 code can be directly used by the ARM code. From Stay Frosty 2:

```ObjectImages:
.word FireballLargeA
.word FireballLargeB
.word FireballLargeC
.word FireballLargeD
.word FireballSmallA
.word FireballSmallB
.word FireballSmallC
.word FireballSmallD
.word FireballLargeA
.word FireballLargeB
.word FireballLargeC
.word FireballLargeD
.word FireballLargeA
.word FireballLargeB
.word FireballLargeC
.word FireballLargeD
.word FireballSmallA
.word FireballSmallB
.word FireballSmallC
.word FireballSmallD
.word BirdA
.word BirdB
.word BirdC
.word BirdD
.word BirdE
.word BirdF
.word BirdG
.word BirdH
.word ExitLevelArrow
.word ExitDownArrow
.word IceChest
.word Carrot
.word Coal
.word Broom
.word Pipe
.word Branch
.word GasCan
.word Snowflake
.word Present
.word Present
.word Present
.word Present
.word PresentBonus
.word ContinueMessage
.word RescueElf
.word RescueElfb
.word RescueRudolf
.word RescueRudolfb
.word RescueHolly
.word RescueHollyb
.word RescueSanta
.word RescueSantab```

You can also use < and > like ZackAttack mentions:

```        ORG \$FFFA        ; set address to 6507 Interrupt Vectors
.byte <InitSystem, >InitSystem ; NMI
.byte <InitSystem, >InitSystem ; RESET
.byte <InitSystem ; IRQ low
.byte >InitSystem ; IRQ high
```
##### Share on other sites

Perfect, thanks for the examples everyone! Once I've got the car driving around the entire city I'll post a ROM to get some feedback. After I get the city data working the next step is collision response, which will also be a challenge I'm not yet sure how I'm going to handle.

##### Share on other sites

thanks for the help everyone! today I got my city layout data working in the game, you can now drive to the edges of the screen and it pops over to the next city block and adjusts the player's taxi position. I have several identical blocks in the current design (to save memory), and it's a bit disorienting right now when you actually drive around in the build. later there should be some sprites and other indications of differences in the blocks (traffic patterns, etc), but right now it's confusing. I'm going to implement per-block playfield colors (which should help a bit), and then make a build people can try out.

Next big task is collision. I'd love for a forgiving collision response, but I'm not sure how I'll use the just the data from the collision register to properly respond to collision without simply "bouncing" you backwards the way you came. Something to think about a bit. Ideally I'd be able to determine which direction to "steer" you out of collision, but to do that I'll need more information, like the exact point of collision for example.

##### Share on other sites

How about showing buildings like the 80s Ghostbusters game e.g. just their front but "flat" on the ground. You could make them out of the playfield. Although the amount of detail you could see would depend on your kernel and ROM space.

##### Share on other sites

Next big task is collision. I'd love for a forgiving collision response, but I'm not sure how I'll use the just the data from the collision register to properly respond to collision without simply "bouncing" you backwards the way you came. Something to think about a bit. Ideally I'd be able to determine which direction to "steer" you out of collision, but to do that I'll need more information, like the exact point of collision for example.

Agreed, simply bouncing (with or without reduced speed) may be too simple.

But calculating the exact collision position is not always easy. Especially for "rounded" corners. Maybe some short cuts using hardware collision are acceptable (especially if you want to stay within 4K)?

1. A single ball or missile pixel, which after a car collision (or even permanently) is trying to detect the direction of the wall you just hit. Based on the current speeds, for vertical and horizontal walls, there are only two checks necessary. E.g. for positive X and Y speeds, you check from the front right corner of the car X-sX/Y and X/Y-sY (sX/sY are current speeds).
2. Reverse just one direction (x or y), e.g. the faster one. After the next frame(s), check if the collision still exists. If yes, reverse the other direction instead.

Depending on how many frames the detection requires, the intermediate frame may look odd.

BTW: I would try not to repeat (larger) city map pattern close together. This may make the orientation more complicated.

##### Share on other sites

BTW: Why are there all black lines? For the buildings they are ok, but the interrupted car looks a bit odd.

Edited by Thomas Jentzsch
##### Share on other sites

Thanks for the ideas. using a "proxy" setup of missiles/balls to determine more about the collision normal is a good idea. It means I'll definitely need a kernel that is repositioning missiles, ball, and sprites throughout the frame, which I haven't done before, that should be interesting.

the black lines are just a side-effect of my first pass at the Kernel, I was thinking of using the blank lines as an opportunity to put "lane lines" on the horizontal roads in some city blocks... but I agree the car looks lame not drawing during those sections. I have a feeling the kernel is going to be a challenge with this game as I start to try and cram in all the visual pieces I need.

##### Share on other sites

Another collision scheme to keep in mind is the one from Adventure. It checks for a simple playfield collision with the player and deals with it over 3 frames. Collision on frame 1 reverses the dX. Collision on frame 2 reverses the dY. Collision on frame 3 reapplies the first dX again.

Pros: The code is quite simple. It allows the sprite to slide along a vertical or horizontal section.

Cons: Collisions cause the sprite to be visually bouncy. The sprite only gets to move every 3rd frame.

 You could fairly easily change that last "Con" into "the sprite only gets to move every 3rd frame while colliding", which seems reasonable and might add to the realism by having the car slow down as it grinds into a wall.

##### Share on other sites

This is an interesting concept. Keep it up!

##### Share on other sites

Alrighty, my city layout is implemented into the build! my editor is already paying off, making it easy to make adjustments. I also cleaned up my kernel significantly, and I'm happy with where it's at right now.

Next up, collision detection and response!

here's the current city layout:

and a gif of me driving around the city. The different colors help a bit to differentiate the repetitive areas, but I'll still need more solutions for that before the game's done.

I've attached a binary, the scanline count is solid, but it's at 260 at the moment. Not tested on hardware yet, just Stella.

The city "wraps" if you go past the edges btw.

any feedback welcome!

taxi-panic_2016_02_27_initial_city_layout.bin

Edited by walaber
##### Share on other sites

This a really cool start. I love games where you are free to explore.

##### Share on other sites

Looks nice so far. There is quite some variety in those tiles. But I somehow miss the horizontal black lines in the buildings now, they gave the surrounding some extra structure.

I am coming back to my randomly generated city suggestion. If you define e.g. 3 or 4 vertical and horizontal connection pattern, you could create a random city. The random number generation only has to be deterministic and bidirectional, so that the city doesn't change when you drive around.

That way you could include an huge number of cities in your game, either based on well defined seeds you have chosen and tested or completely randomly chosen seeds. And the size of the cities could become huge too. So people can learn and replay known maps or discover new cities almost endlessly. This would increase the replay value.

##### Share on other sites

Before I tacke collision I took another pass at adjusting the city blocks to be a bit easier to drive in-game, and have a bit more uniqueness to them. ideally all the tiles will start to feel as unique as the cooler ones in here right now like the Mall ("M"), Bus Stops, and stadium left/right.

Here's the latest snapshot on game size:

```Free RAM: 89 bytes
Code SIZE: 786 bytes
Data SIZE: 2040 bytes
ROM Free: 1266 bytes
```
Edited by walaber

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.