walaber

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.

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.

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.

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

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

Very fun! I like the theme change to a car, and the main sprite looks nice. Paddle controls feel nice. I like the addition of the risk/reward "jump" mechanic. The sounds are really nice too. What else are you planning for this game, or is it mostly done?

The game plays very well, nice job! Already a nice sense of adventure, and variety in the environments and enemies. I tried it on hardware, and it looks pretty good (didn't make it out of the first dungeon). only problem so far is the black bats are very hard to see over the dark red background on my crappy, noisy CRT TV. keep up the great work! Also cool to see the source available for people to see. It's cool to see how such a complex assembly game can be organized and set up.

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.

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.

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: taxi-panic_2016_03_02_collision_response.bin

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

BTW there is indeed a bug with the Savekey/AtariVox+ high score saving/loading code. I'm working on a fix now.

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

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.

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.

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.

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

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.

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

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!

more points isn't really a powerup... perhaps instead the 2nd powerup could widen all the openings for the next x seconds?

you were right, I was indeed on version 3! Just played 4 and it's much improved! nice work. I got up to around 9,000 points and didn't feel the game speed up, does that come later? Also I'm a bit confused on the powerups. they all look the same, and I only seemed to encounter 2: 1- you blink and are invulnerable for a short period (cool!) 2- you pick it up and a different sound plays, but nothing noticeable happens The music is indeed really great, like others have mentioned.

BTW I also tried using the driving controller (in the right-hand port), and it didn't work (as you probably know).

nice job! I played on a Harmony on hardware with paddle and joystick. I definitely prefer paddle, given the way you have the obstacles designed, it's much more frustrating with a joystick. also, on the paddle controller, it appears you're not using the entire range of the paddle. if I turn all the way to the right (until the hardware limit), I'm at the right edge of the screen, and turning left from there the ship starts moving left right away, but it reaches the left side of the screen well before the left turn limit of the paddle. It makes me think that you could use a bit more range of the paddle to make the controls slightly less sensitive (they feel a bit touchy to me). overall great progress! I'd be glad to play future versions on hardware and give feedback.

The game is now available in the AtariAge store! If you buy it, let me know what you think!