Pop Box Arena - New WIP 2600 Quadtari Homebrew

[+littaum]

Hi all,

 

I am working on my 4th Atari 2600 homebrew game (the others being ElectroBall, Berry Fun! and Catch), which is a Quadtari-oriented demolition derby inspired game currently called Pop Box Arena.  It is presently a 16K game with a F6 bankswitching scheme.  You take control of 1 of 4 recalled electric cars, which has a battery pack crudely attached to the back.  Your goal is to ram into the battery packs of the other cars to weaken the battery harness.  Each battery harness can only take so many hits until it completely falls apart, after which your car will run no more.  The last car running wins!  Control is joystick based (why not driving controllers?  Because I wanted to program for the most accessible controller scheme and the non-linear aspect of the driving controller would unduly influence gameplay in my opinion) where you press left to steer left, right to steer right, and press the fire button to accelerate.  The electric cars were recalled due to faulty brakes, so those have been removed. But don't worry, the regenerative breaking technology is still working, slowing down your car when your foot is not on the gas.

 

      

 

I am working towards having something that is demo-able at PRGE 2024 - I would love for those of you that are attending to help me give the game a try to root out strangeness as well as get ideas for gameplay tweaks.  I anticipate this being a somewhat long WIP - a final version would likely not be done until sometime in 2025.   I always like to learn new things when I do a new 2600 homebrew, so these are the topics I've been learning:

 

1.  Programming for the Quadtari.

2.  Sprite flicker management (the above gameplay graphic is done with ~30 Hz flickering of the car sprites, and dynamic repositioning of the missile objects so each player has a color shifting missile aka battery pack trailing behind them).  I got some inspiration from a Todd Frye talk about what he might have done differently to the 4K Pac-Man sprite display scheme to make the ghosts less "ghosty").  The sprites and missiles are flickered across 32 different combinations to minimize player irritation over sprite display.

3.  Software collision detection (both between the car sprites and the cars sprites with the battery missiles) .. car and playfield collision are still handled via hardware collision.  I went with software collision for cars/batteries due to my flicker management scheme having to spread around what sprite/missile does what car/battery).

4.  Handling a very large number of sprite possibilities (each car has 1 of 16 directions with 3 possible frames of animation.  My initial implementation managed to exceed 256 bytes so I had to get a little creative in exceeding this barrier.)

5.  Making the cars "drifty" so that their direction and orientation are not always 1:1.

 

Some of the other items on my wish list:

1.  NTSC and PAL60 versions (pretty easy to do on my end)

2.  Multiple arena layouts

3.  Dirt and ice surfaces (the cars have a slight drift to them, and dirt and ice would make the drift more pronounced)

4.  A two player "duel" where you battle each other and can drive over powerups to enhance your vehicle or hinder your opponent.

5.  A single player "time attack" where the goal is to drive over things that give you points (and avoid driving over bad things) over a period of time.

6.  AI option for cars (will be tough to make an effective opponent but no one said automated driving was 100% perfect!)

7.  Auto-Quadtari detection and handling when a Quadtari is not installed.

 

After PRGE 2024 I will post the demo ROM here for everyone to try out.   In the past my games have been fairly feature complete before I post them, but this will be the most complicated game I've made so far so I still have some work to do (and I only proceeded with game development once I reached a stage where I was confident I would not run out of either RAM or (more likely) clock cycle processing time).    Presently I assume a Quadtari is installed - if it isn't then each player controls 2 cars simultaneously.

 

 

[Thomas Jentzsch]

Sounds cool!

[Seth A]

I cannot wait to try this! I love the conceit—the battery packs are a lovely touch and make me think of how in Robot City you must attack from the rear, which adds a fantastic new layer of difficulty—and I love seeing more and more Quadtari games coming out. (I am creating a whole "Idle, Online, and Quadtari" section for Vol. 2 of the Top 500 Atari 2600 Homebrews—as it is definitely well past time for this!) Just got my PlusCart in the mail this week!

 

S.

 

____________

 

The Top 500 Atari 2600 Homebrews, Vol. 1: https://retrostack.substack.com/p/the-top-500-atari-2600-homebrews

[+Al_Nafuur]

7 hours ago, Seth A said:

 Just got my PlusCart in the mail this week!

May I ask which shop you ordered from?

[Silvio Mogno]

Cool concept!

 

Just my little humble opinion: using CDFJ acceleration sprite flicker management could be greatly improved. Opponents AI too.

 

[+littaum]

2 hours ago, Silvio Mogno said:

Cool concept!

 

Just my little humble opinion: using CDFJ acceleration sprite flicker management could be greatly improved. Opponents AI too.

 

 

I think it definitely would too.  I'm already having to carefully manage the vertical blank and overscan to make sure I don't overrun on cycles and am doing a lot of "every other frame" for logic.  At one point I implemented Oscar Toledo G's example on testing to see if a point would touch a playfield to count for when the cars collide with the arena, but it would end up taking too many cycles for my game - but that would be fairly easy for a CDFJ implementation.  Right now I'm seeing how far I can take it on "standard" hardware.

[Seth A]

10 hours ago, Al_Nafuur said:

May I ask which shop you ordered from?

got it used on eBay

[Silvio Mogno]

20 hours ago, littaum said:

I think it definitely would too.  I'm already having to carefully manage the vertical blank and overscan to make sure I don't overrun on cycles and am doing a lot of "every other frame" for logic.  At one point I implemented Oscar Toledo G's example on testing to see if a point would touch a playfield to count for when the cars collide with the arena, but it would end up taking too many cycles for my game - but that would be fairly easy for a CDFJ implementation.  Right now I'm seeing how far I can take it on "standard" hardware.

I made my rubyQ game starting from "Collect3" demo source code by @SpiceWare. It's a good point to start from.

 

Moreover it's easier and faster to implement data structures and algorithms in C.

[Thomas Jentzsch]

20 hours ago, littaum said:

Right now I'm seeing how far I can take it on "standard" hardware.

👍