+littaum Posted August 25 Share Posted August 25 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. PRGE 2024 ROMs (and a PAL50 in-development proof of concept with more scan lines of logic with better car/car and car/battery collisions, car/background improvements to be done as well) are below: PopBoxArena_Demo_PRGE2024_B1[NTSC].bin <-- NTSC Version of PRGE 2024 demo PopBoxArena_Demo_PRGE2024_B1[PAL60].bin <-- PAL60 Version of PRGE 2024 demo (same logic as NTSC, colors changed for better display on PAL60) PopBoxArena_Demo_PRGE2024_B1[PAL50].bin <--PAL50 Version of PRGE 2024 demo (better car/car, car/battery hit detection, car/wall detection to be worked on) Pop Box Arena Text PRGE 2024.pdf <--Rough draft text of placard for display on top of the game during PRGE 2024) The game had its premiere on ZPH, followed by a demo at PRGE 2024. 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) (DONE) 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!) (CRUDE PLACEHOLDER DONE) 7. Auto-Quadtari detection and handling when a Quadtari is not installed. (DONE - could l like do with some graphical display indicating if it was detected) 8. Investigation of other strategies to allow for more logic checks than 262 linescans can provide (PAL50 for testing, likely CDFJ+ for more time for logic) 9. Add in a slow reverse in case the player wants to back up from a wall. 10.Add in a timer bar to the player select screen so that people know how long they have to decide whether to play in the next game or not. 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 - which I have on the 60 Hz versions). If a Quadtari is installed, you can select between red, blue, yellow, and green. If a Quadtari is not installed, you can select between red and blue, and yellow and green PopBoxArena_Demo_PRGE2024_B1[PAL50].bin PopBoxArena_Demo_PRGE2024_B1[PAL60].bin PopBoxArena_Demo_PRGE2024_B1[NTSC].bin 17 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 25 Share Posted August 25 Sounds cool! 1 Quote Link to comment Share on other sites More sharing options...
Seth A Posted August 25 Share Posted August 25 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 3 Quote Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 26 Share Posted August 26 7 hours ago, Seth A said: Just got my PlusCart in the mail this week! May I ask which shop you ordered from? Quote Link to comment Share on other sites More sharing options...
Silvio Mogno Posted August 26 Share Posted August 26 Cool concept! Just my little humble opinion: using CDFJ acceleration sprite flicker management could be greatly improved. Opponents AI too. 1 Quote Link to comment Share on other sites More sharing options...
+littaum Posted August 26 Author Share Posted August 26 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. 2 Quote Link to comment Share on other sites More sharing options...
Seth A Posted August 26 Share Posted August 26 10 hours ago, Al_Nafuur said: May I ask which shop you ordered from? got it used on eBay 1 Quote Link to comment Share on other sites More sharing options...
Silvio Mogno Posted August 27 Share Posted August 27 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. 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 27 Share Posted August 27 20 hours ago, littaum said: Right now I'm seeing how far I can take it on "standard" hardware. 👍 2 Quote Link to comment Share on other sites More sharing options...
+ZeroPage Homebrew Posted September 19 Share Posted September 19 ZeroPage Homebrew has the Exclusive World Premiere of Pop Box Arena on tomorrow's ZPH stream LIVE on Twitch! Hope you can join us! Fri Sep 20, 2024 | LIVE @ 12PM PT | 3PM ET | 7PM GMT WATCH LIVE: https://twitch.tv/zeropagehomebrew/ WATCH LATER: https://youtube.com/zeropagehomebrew/ Games: Pop Box Arena (2024 Exclusive World Premiere | 2600) by Mike Littau @littaum Minigun Miner (2024 Exclusive WIP Update | 2600) by Dr. Ludos @drludos AtariAge PRGE Demos Day 2: Atari 2600 1 Quote Link to comment Share on other sites More sharing options...
+littaum Posted September 22 Author Share Posted September 22 Much thanks to James and Aerlan for playing Pop Box Arena on Friday's show - I'm glad to hear/see that, #1 - I didn't see any screen rolls, and #2 - they thought the basic game concept was fun. I still have some memory left over for new variables, but I am currently overloaded on the game logic. I'm having to monitor the timer in both the vertical blank and the overscan, and if I am below the timer in certain instances the rest of the functions get skipped. For vertical blank this means that some frames the battery box/missiles will not be drawn, and in the overscan it means that the joystick reads or joystick reads or battery box/car collisions or the "is game over yet" functions are not run. I'm also only able to have car/car software collisions for each car once every four frames (so red car gets checked against blue/green/yellow, next frame blue car gets checked against red/green/yellow, next frame green car gets checked against red/blue/yellow, then yellow car gets checked against red/blue/green). Car/playfield collisions are checked every other frame thanks to hardware detection, and car/missile checks also are sub-sampled (plus the possibility of them being skipped altogether if car collision detection takes too long). That is the reason for a lot of the "combat-esque" collision chaos seen on the stream. I'll likely see if I can further optimize some of the routines, and/or see if a re-organization of what functions get called in what order so that I can prioritize collision checks. I might also see if the benefit of more clock cycles will help make more of these functions call-able each frame, so I might immediately try a PAL50 version to see if the extra 50 scanlines worth of logic helps out. If it does - I might seriously consider re-doing the game in CDFJ to allow for this and to see if this allows for the cars/batteries to be displayed without flicker. And hopefully some computer AI that is smarter than the current joystick wrangling it does now. From a technological standpoint this whole game would have been much cleaner to write as a game for the Atari 8-bit computer (but I don't have one of those...2600 for me for now. ) I like ZPH's idea for the ability of a slow reverse. When I play and get into a similar situation of my car facing the wall, I just accelerate into the wall, and as soon as I hit, let go of the gas so that the car drifts backwards. I was able to add support for non-quadtari systems for this demo (so that up to 2 players can play), which is auto-detected. Anyways, I hope to play against several of you at PRGE, and everyone will get access to the demo ROM in this thread after PRGE. 2 Quote Link to comment Share on other sites More sharing options...
+littaum Posted Monday at 03:16 PM Author Share Posted Monday at 03:16 PM PRGE 2024 demo ROMs of the game are now posted in the first post. In addition I have a "work in progress" version of PAL50 as a still-in-working proof of concept that more cycle time to do per-frame collision checks will avoid running up the walls or over other people's cars. 3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.