Jump to content

Photo

Taxi Panic!

homebrew assembly asm wip

110 replies to this topic

#1 walaber OFFLINE  

walaber

    Chopper Commander

  • 159 posts

Posted Sat Feb 20, 2016 11:38 PM

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.

 

taxi_panic_01.gif

 

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:

 

taxi_panic_04-editor.gif

 

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.

 

taxi_panic_05-editor.gif

 

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

Attached Thumbnails

  • taxi_panic_01.gif
  • taxi_panic_04-editor.gif
  • taxi_panic_05-editor.gif

Edited by walaber, Sat Feb 20, 2016 11:43 PM.


#2 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,881 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sun Feb 21, 2016 1:46 AM

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.

Attached Thumbnails

  • image.jpg


#3 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,942 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sun Feb 21, 2016 5:30 AM

Looks good so far. :thumbsup:

 

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?



#4 Philsan ONLINE  

Philsan

    River Patroller

  • 3,808 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Feb 21, 2016 11:33 AM

Like Nintendo DS GTA Chinatown Wars taxi game!

 

A W E S O M E !



#5 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Sun Feb 21, 2016 5:59 PM

Looks good so far. :thumbsup:

 

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:

 

taxi_panic_07-inertia.gif

 

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).



#6 AtariBrian OFFLINE  

AtariBrian

    River Patroller

  • 3,627 posts
  • Location:Toledo, Ohio

Posted Sun Feb 21, 2016 6:08 PM

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



#7 Jinroh OFFLINE  

Jinroh

    Dragonstomper

  • 696 posts
  • Catgirl Maid Lover

Posted Mon Feb 22, 2016 1:51 PM

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

 

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



#8 SpiceWare ONLINE  

SpiceWare

    Draconian

  • 12,631 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Mon Feb 22, 2016 2:38 PM

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.

#9 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Mon Feb 22, 2016 4:46 PM

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.



#10 Mr SQL ONLINE  

Mr SQL

    River Patroller

  • 2,071 posts

Posted Mon Feb 22, 2016 10:18 PM

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

 



#11 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Wed Feb 24, 2016 12:25 AM

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:

IMG_0062.PNG

 

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

taxi-panic_1.png  taxi-panic_2.png  taxi-panic_3.png

 

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
     (address of PlayfieldData_0)
     (address of PlayfieldData_1)
     .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).



#12 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 760 posts
  • Location:Orlando, FL US

Posted Wed Feb 24, 2016 12:59 AM

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 


#13 SpiceWare ONLINE  

SpiceWare

    Draconian

  • 12,631 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Feb 24, 2016 8:04 AM

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 DisplayDataDigitBlank ; no object
    .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 DisplayDataDigit0
    .word DisplayDataDigit1
    .word DisplayDataDigit2
    .word DisplayDataDigit3
    .word DisplayDataDigit4
    .word DisplayDataDigit5
    .word DisplayDataDigit6
    .word DisplayDataDigit7
    .word DisplayDataDigit8
    .word DisplayDataDigit9
    .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


#14 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Wed Feb 24, 2016 11:01 AM

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.



#15 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Thu Feb 25, 2016 1:38 AM

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.



#16 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,821 posts
  • Busy bee!
  • Location:England

Posted Thu Feb 25, 2016 3:39 AM

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.



#17 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,942 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Feb 25, 2016 4:23 AM

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.



#18 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,942 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Feb 25, 2016 4:34 AM

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, Thu Feb 25, 2016 4:34 AM.


#19 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Thu Feb 25, 2016 10:56 AM

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.



#20 RevEng ONLINE  

RevEng

    Bit Player

  • 5,110 posts
  • Location:bottom of the stack

Posted Thu Feb 25, 2016 11:54 AM

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.

[edit] 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.

#21 Propane13 OFFLINE  

Propane13

    Stargunner

  • 1,649 posts
  • Location:Charleston, SC

Posted Fri Feb 26, 2016 7:12 AM

This is an interesting concept.  Keep it up!



#22 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Sat Feb 27, 2016 9:37 PM

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:

taxi-panic_4.png

 

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.

taxi_panic_08-city.gif

 

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!

Attached Files


Edited by walaber, Sat Feb 27, 2016 10:24 PM.


#23 Mountain King OFFLINE  

Mountain King

    Dragonstomper

  • 690 posts
  • Location:Philadelphia, PA

Posted Sat Feb 27, 2016 11:22 PM

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



#24 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,942 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sun Feb 28, 2016 2:40 AM

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.



#25 walaber OFFLINE  

walaber

    Chopper Commander

  • Topic Starter
  • 159 posts

Posted Sun Feb 28, 2016 6:27 PM

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.

 

taxi-panic-city-layout-03.PNG

 

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, Mon Feb 29, 2016 11:22 AM.






Also tagged with one or more of these keywords: homebrew, assembly, asm, wip

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users