Jump to content
IGNORED

New Atari 2600 Homebrew: Oh Shoot!


Recommended Posts

Here's some basic info about my 2600 game "Oh Shoot!":
-32K F4 bank switched 1v1 "Combat Killer!"
-uses stock 2600 hardware - no extra RAM or arm processor
-1, 2, or 0 player modes
-multiple flight modes and speed options
-4 ship types
-1024 screens
-flashy title screen
-large flashy animated explosions
-full screen scrolling, warping, and rumble effects
-fully couch compliant with match tapout
-user friendly game select screen
-AI controlled players and "AI assistance" for human players
-exhibition modes
-consistent 276 lines in NTSC
-functional b/w and difficulty switches

 

OhShootCover_20211204-Copy-Copy.thumb.png.72422dc482461aa933ac0c3f9a0b3039.png

OhShoot.thumb.png.a5ec4521b8c1b5f4146f5e6412fb1667.pngOhShoot_1.thumb.png.fc6f551ab12778a5ecc1ba395624fa88.pngOhShoot_2.thumb.png.c2e3ce3c372107a80c49f055cf36c79a.pngOhShoot_10.thumb.png.9e2f0e7bdae9668cd8b70f97e6c9c65b.pngOhShoot_13.thumb.png.e1030571e662140642981737f23934bf.pngOhShoot_14.thumb.png.d8057f2ec8b5e51c10d4a75b303b81c5.png

  • Like 12
Link to comment
Share on other sites

15 hours ago, Propane13 said:

I like the title screen!

 

Got any video of gameplay?

It was played on ZPH last night. Check around the 1 hour 20 minute mark:

 

https://player.twitch.tv/?enableExtensions=true&muted=false&parent=twitch.tv&player=popout&quality=auto&t=1h20m3s&video=2169779791&volume=1

 

I'm looking forward to a ROM being made available.  🙂 

  • Like 1
Link to comment
Share on other sites

16 hours ago, LatchKeyKid said:

Looks cool!   If you don't mind me asking (as a complete novice myself), how did you program it?

 

I programmed it all in assembly.  I started off using the 8bitworkshop web based ide.  It's pretty amazing, but I got frustrated trying to debug with it so I switched to Visual Studio Code with the 2600 programming extension.

I made some C# apps that would assemble all my screens into rom format.

  • Like 3
Link to comment
Share on other sites

Posted (edited)

I'll give some credit to what helped me the most on this project.
The 2600 video course from Gustavo Pezzi was the gentle introduction I needed:
https://pikuma.com/courses/learn-assembly-language-programming-atari-2600-games

Steven Hugg's 2600 programming book got me almost to the finish line:
https://www.amazon.ca/Making-Games-Atari-2600-Steven/dp/1541021304

 

There were some other technical bits n bobs I got from various sources but the above two were my best sources.

By the way this project was the hardest thing I have EVER done!  The technical constraints are crushing!

Edited by Piledriver
  • Like 7
  • Thanks 1
Link to comment
Share on other sites

13 hours ago, Piledriver said:

 

I dunno.  Maybe?  All I want right now is to get this into the Atariage store.

Well that part is up to @Albertof course, and from what I've seen on ZPH, it would be a fine addition.

 

Letting people try out the game beforehand does have some advantages through, including getting useful feedback to improve your game, finding obscure bugs, and being more likely to be nominated for the Atari Homebrew Awards. Additionally, it can help build enthusiasm / demand for a possible future cartridge release. Just my opinion, of course. 🙂

  • Like 5
Link to comment
Share on other sites

1 hour ago, Almaric said:

Put me down for the purchase of the final digital version on Itch or Atariage when that functionality gets added to the store. I agree that those backgrounds are so cool!

We're working on the new store, it's coming along nicely so far.  :)

 

 ..Al

  • Like 4
Link to comment
Share on other sites

Posted (edited)

Got a bunch of questions about how I made 1024 screens for Oh Shoot!  I hope this answers those questions.

 

There were several iterations to my level storage solutions.

 

1.  Naïve level storage
-store PF0, PF1, and PF2 for each of the 22 rows of a screen (66 bytes per screen - no compression)
-screen drawn directly from ROM
-I think this only allowed me 4 screens in my 4KB game?  Don't remember.

 

2.  Run length encoding
-used 4 unused bits in PF0 to store run length value
-identical adjacent rows now grouped into chunks
-run length data extracted on the fly in the kernel code (not ideal but it worked)
-allowed me to have 16 screens in my 4KB game

 

3.  Screens are a list of indexes into a chunk palette
-each index is one byte (can index up to 256 chunks... although I only had space for much fewer chunks)
-chunks can be reused many times and in different screens
-each screen is between 2 and 15 indexes to chunks (limiting the number of times I can change the playfield values to 15 times per screen)
-each chunk palette entry consists of PF1 and PF2 data (I ditched PF0) and the run length encoding value (number of rows in the chunk)
-this data could no longer be decompressed on the fly
-needed 22 rows x 2PF bytes of RAM for my uncompressed screen that could be easily drawn
-44 bytes of RAM required!!!
-I also needed one frame between rounds to load/decompress the screen into RAM
-In my 4KB game I only had about 640 bytes for all my screens
-I was able to make 64 screens that were mostly big chunky blocks.

 

4.  Chunk Palettes with bank switching (32KB)
-Instead of using the leftover crumbs in my 4KB game for level data I now had 4 banks just for level data (and decompression/retrieval code) - that's half the ROM right there!
-Instead of one set of 64 screens (lists of chunk indexes) and corresponding chunk palettes I now had 16 sets of 64 screens each with corresponding chunk palette for each screen set.
-Not only did I now have 16 sets of screens instead of only 1, but each set was almost a full KB instead of only 640 bytes.
-16 sets of 64 screens each = 1024 screens!


*storing each row uncompressed in RAM and having lots of ROM to play with made it relatively easy to add warping effects
*there is no metadata stored for a screen... screens have to be analyzed to generate metadata like where the corridors are for AI and greatest corridor width to determine if warp effect can be applied
*the analysis also cuts the screen in two vertically so the vertical scrolling makes sense (we wouldn't want a castle to be cut in half during scroll in effect for example)

 

I could not manually generate the screen set data, so I wrote a C# app to automate this process.  For each set it reads in 64 pngs - one for each screen and generates the screen set from that.  This app also generates reports on how much rom the screen set uses, how many chunks there are, how often the chunks are used in the screen set, which screens they appear in, etc.  This would allow me to edit my screens while staying inside my byte budget.

 

Creating/editing screens was my fun task that I would keep coming back to when frustrated with coding.

 

There are even more details than this, but I think this gives you a good idea of what was involved.

Edited by Piledriver
  • Like 3
Link to comment
Share on other sites

On 6/12/2024 at 11:56 AM, Piledriver said:

I'll give some credit to what helped me the most on this project.
The 2600 video course from Gustavo Pezzi was the gentle introduction I needed:
https://pikuma.com/courses/learn-assembly-language-programming-atari-2600-games

Steven Hugg's 2600 programming book got me almost to the finish line:
https://www.amazon.ca/Making-Games-Atari-2600-Steven/dp/1541021304

 

There were some other technical bits n bobs I got from various sources but the above two were my best sources.

By the way this project was the hardest thing I have EVER done!  The technical constraints are crushing!

I am really inclined to purchase this courses on assembly language. Thanks

  • Like 1
Link to comment
Share on other sites

Judging from the video, I think the Atari 2600 hasn't had a two player smash up this much fun since maybe Cannonhead Clash in 2019.  

 

A bit off topic, but I wonder if Mattel's Sea Battle (linkmanual) could be modified to eliminate the MAP MODE and just go straight to the BATTLE MODE?  Then it would become a two player smash up similar to Oh Shoot!, just in the naval combat category.  

 

Images of Sea Battle in Battle Mode

 

Spoiler

DestroyervsPTboat2_200x139.jpg.61bb708888b8c50d210732ff5d6ef1c9.jpg Destroyer (blue) vs PT Boat (yellow)

BattleshipvsSubmarine_200x145.jpg.ad764e38ba575c1feb3da2d0ce596dff.jpg Battleship (yellow) vs Submarine (blue)

PTBoatvsSubmarine2_171x200.jpg.405fc2f05f787c512a326c092030438d.jpg PT Boat (blue) vs Submarine (yellow)

It says in the manual that each player starts with 12 ships, 3 of each type (Sub, PT Boat, Destroyer and Battleship).  

image.thumb.png.a6d2f9c80ffa1be3fd956ebff6da003d.png

I would say keep it that way.  However, completely remove the MAP MODE.  Instead just have a simple menu (a la Mortal Kombat) to let each player select their ships and then Voila! go straight to BATTLE MODE and FIGHT!  

 

I'm imagining the ship selection process would be a little like M-Network's Super Challenge Football where the players are silently making their selections with their joysticks and locking in their choices with their buttons.  After both players have made their selections, the BATTLE BEGINS!  

 

In the beginning, both sides are evenly matched.  But as each player begins losing ships, strategy would come into play.  

 

The strategy would be to try to force mismatches.  For example, submarines are good at sinking battleships.  If you could destroy all 3 of your opponents subs with, say, your destroyers, then you could force a mismatch when you choose your battleship, since your opponent would have no subs left, they would have to choose something else and probably you win that round.  

 

Near the end of the game, it could become quite bad for one of the players, there could be some bad mismatches leading to the total defeat of their naval fleet.  Smart ship selections + skill in battle will lead to VICTORY!  

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...