[WIP] Tanks 2022

[Fort Apocalypse]

Tank combat games.

Standard kernel version (8K) (Standard 0.1-0.4 were 4K, Standard 0.5 and later are 8K):

• Find the radio to send a drone after the other player.
• Tanks are fast, similar to modern tanks.
• Curve your shots.
• If you shoot without pulling back the joystick, it often will remove the playfield pixel where the missile lands.
• If you shoot while pulling back the joystick, it attempts to draw playfield pixels as you go backwards.
• Maximum distance of missile varies some.
• Unlike most tank battle games, shooting the other player doesn't win points. Instead, you must capture the other player's base.
• Each player has four bases.
• Each round (and select/reset). you get a random map along with random colors and tanks may be invisible/same color as playfield until it shoots.

 

DPC+ kernel version (All DPC+ are 32K):

Is similar to but varies substantially from the other version.

(discussion) The DPC+ 0.2 version was tested by alex_79 and confirmed working. I'm assuming 0.3 and any later versions work on Harmony cart, but if not, please let me know!

(Note: DPC+ version doesn't work in Javatari, because Javatari doesn't support DPC+ yet. Each version works in Stella 6.7 for me in developer and player modes.)

The differences in the DPC+ version (compared to standard version) are:

• Better playfield graphics.
• Only one map for now.
• Can't select different colors for now.
• No tank invisibility for now.

 

 

tanks_2022_dpc_0.3.bas.bin tanks_2022_dpc_0.3.bas

tanks_2022_0.8.bas.bin tanks_2022_0.8.bas

Edited July 16, 2022 by Fort Apocalypse

[Fort Apocalypse]

First release.

 

Tank combat game with the following features:

• Find the radio to send a drone after the other player.
• Shoot over the playfield and curve your shots.
• Tanks are fast, similar to modern tanks
• You can select from a few static maps or a random one, along with a wide variety of colors for player one, player two, background, and playfield.
• Unlike most tank battle games, shooting the other player doesn't win points. Instead, you must capture the other player's base to win.

 

You can win by capturing the other player's base, but it doesn't keep score; if you win, it's the end of the game.

The playfield walls can trap the player, making it difficult to escape. This can be frustrating, but the game is fully playable.

 

 

tanks_2022_0.1.bas tanks_2022_0.1.bas.bin

Edited June 22, 2022 by Fort Apocalypse

[LatchKeyKid]

Thanks and I'll try it later tonight!  One general question from a bB n00b... are the lines separating the playfield into horizontal blocks a stylistic choice or a feature of bBatari?   I never noticed that in older games as they had solid chunks but newer ones utilizing bBatari almost always seem to have the horizontal gaps between them.  Does that offer some sort of coding/cpu cycle advantage to segment it that way between changes (like using the line to run CPU game code)?

Edited June 22, 2022 by LatchKeyKid

[Fort Apocalypse]

Changed:

• Pulling down on the joystick modifies the local playfield. (A goal was to make the game vaguely similar to Bolo by allowing the player to alter the playfield.)
• Tank collide with playfield and shot collisions flip a nearby pixel in the playfield, to simulate damage.
• If a player's tank collides, it stops.

 

tanks_2022_0.2.bas tanks_2022_0.2.bas.bin

Edited June 23, 2022 by Fort Apocalypse

[+TwentySixHundred]

21 minutes ago, LatchKeyKid said:

Thanks and I'll try it later tonight!  One general question from a bB n00b... are the lines separating the playfield into horizontal blocks a stylistic choice or a feature of bBatari?   I never noticed that in older games as they had solid chunks but newer ones utilizing bBatari almost always seem to have the horizontal gaps between them.  Does that offer some sort of coding/cpu cycle advantage to segment it that way between changes (like using the line to run CPU game code)?

Using the default kernel those separation lines will appear. You can change this with i believe setting the kernel options no_blanklines if i remember correctly. However there will be a tradeoff like no second player missile or whatever. You will need to check RT's guide to see what the syntax and tradeoff is

[Fort Apocalypse]

1 hour ago, LatchKeyKid said:

Thanks and I'll try it later tonight!  One general question from a bB n00b... are the lines separating the playfield into horizontal blocks a stylistic choice or a feature of bBatari?   I never noticed that in older games as they had solid chunks but newer ones utilizing bBatari almost always seem to have the horizontal gaps between them.  Does that offer some sort of coding/cpu cycle advantage to segment it that way between changes (like using the line to run CPU game code)?

In the standard bB kernel, the lines show unless you give up missile0 and use the no_blank_lines kernel option, which I didn't do, because I wanted to use missile0.

 

According to CurtisP, when using no_blank_lines, missile0 is lost because "the instructions used to draw the missile are replaced with the instructions to increment the pointer to the playfield data (which would normally be executed during the blank line)". So the blank line is caused by cycles required to increment the pointer to the playfield data to read the playfield data while it's displaying the playfield, unless cycles are freed up ahead of time by not showing missile0:

 

Here's info from RT about kernel option combinations, which includes info on when no_blank_lines can be used:

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart

 

I was interested in allowing the tank to build or destroy the playfield to make it a little like Bolo (see also: WinBolo and the old sci-fi Bolo Universe), so I went with the standard kernel out of familiarity, but I could look into using the DPC+ kernel, maybe.

Edited June 22, 2022 by Fort Apocalypse

[LatchKeyKid]

Thanks!  That's a big help.  I'm not able to fully read (let alone comprehend it yet!) but I (apparently incorrectly?) thought that changing the color of the sprite line by line was just a normal thing for Atari since it was in Pitfall.  I know that predates bBatari by decades but I wonder if they're using the same technique and that's why the game doesn't seem to use missiles from looking at the Stella Debugger view in order to give Harry his colors.

[Fort Apocalypse]

2 hours ago, LatchKeyKid said:

Thanks!  That's a big help.  I'm not able to fully read (let alone comprehend it yet!) but I (apparently incorrectly?) thought that changing the color of the sprite line by line was just a normal thing for Atari since it was in Pitfall.

Yep, it's not a limitation of the Atari 2600, and not really a limitation of bB either. In the standard kernel of bB, the blank lines can be removed by using the no_blank_lines kernel option. I was just using the bB standard kernel, and I didn't want to give up missile0 by using the no_blank_lines kernel option. I could've used no_blank_lines kernel option in the standard kernel and alternated use of missile1 so it would be used for both tanks, but that would've required more work. I could've used the ball as a missile, but I chose to use it as a radio and drone.

 

There are also other kernels in bB, for example the multisprite kernel and DPC+ kernel, and neither of those have blank lines. DPC+ has the built-in ability to write pixels to the playfield similar to the standard kernel, so that could be an option also.

Edited June 22, 2022 by Fort Apocalypse

[+Al_Nafuur]

1 hour ago, Fort Apocalypse said:

I was interested in allowing the tank to build or destroy the playfield to make it a little like Bolo (see also: WinBolo and the old sci-fi Bolo Universe), so I went with the standard kernel out of familiarity, but I could look into using the DPC+ kernel, maybe.

?

Bolo looks very interesting. I've been looking for an idea to make a 2600 online version (via PlusROM functions) of a combat/tank based game.

[+TwentySixHundred]

To get a full understanding you need to learn how the hardware itself works. To put it as simple and easy to understand, bB and assembly coding the developer looks at very differently. The end goal is the same give or take.

 

Basically with assembly the developer needs to write everything (kernel). Where as with bB you're using pre-written kernels and filling them with logic. Much like when making a burger for example; you can have the buns and meat already made for you and you add the filler. bB is just that while assembly the developer makes the buns, meat and filler.

 

Where as tradeoffs are mentioned you are basically selecting one of the pre-written kernels to use. Some allow you to add different colours per scanline for sprites for a tradeoff. The reason there is a tradeoff is because you only have so much time to display everything. Telling the TIA to change colour for the next scanline on an sprite eats into that time so you need to drop something else. It can be anything really however these have been chosen for you.

 

I suggest watching some technical talk from the original developers on youtube to get the full understanding. Knowing how the system works really does help getting a better understanding even when coding in bB.

Edited June 22, 2022 by TwentySixHundred

[LatchKeyKid]

28 minutes ago, Fort Apocalypse said:

Yep, it's not a limitation of the Atari 2600, and not really a limitation of bB either. In the standard kernel of bB, the blank lines can be removed by using the no_blank_lines kernel option. I was just using the bB standard kernel, and I didn't want to give up missile0 by using the no_blank_lines kernel option. I could've used no_blank_lines kernel option in the standard kernel and alternated use of missile1 so it would be used for both tanks, but that would've required more work. I could've used the ball as a missile, but I chose to use it as a radio and drone.

 

There are also other kernels in bB, for example the multisprite kernel and DPC+ kernel, and neither of those have blank lines. DPC+ has the built-in ability to write to playfield similar to the standard kernel, so that could be an option also.

 

FWIW, I think that you made the right choice.  Obviously strictly from my player only perspective, being able to use the missiles in a two player tank game plus still have the flexibility to use the ball is more important.

[LatchKeyKid]

17 minutes ago, TwentySixHundred said:

To get a full understanding you need to learn how the hardware itself works. To put it as simple and easy to understand, bB and assembly coding the developer looks at very differently. The end goal is the same give or take.

 

Basically with assembly the developer needs to write everything (kernel). Where as with bB you're using pre-written kernels and filling them with logic. Much like when making a burger for example; you can have the buns and meat already made for you and you add the filler. bB is just that while assembly the developer makes the buns, meat and filler.

 

Where as tradeoffs are mentioned you are basically selecting one of the pre-written kernels to use. Some allow you to add different colours per scanline for sprites for a tradeoff. The reason there is a tradeoff is because you only have so much time to display everything. Telling the TIA to change colour for the next scanline on an sprite eats into that time so you need to drop something else. It can be anything really however these have been chosen for you.

 

I suggest watching some technical talk from the original developers on youtube to get the full understanding. Knowing how the system works really does help getting a better understanding even when coding in bB.

 

Thanks again.  I actually have watched talks and "how to" assembly vidoes on youtube when trying to make my first hack but that's obviously just the first of many steps.  I appreciate the somewhat derailing Q&A I started regarding the graphics as it has been very enlightening.  I think that I may have developed an unrealistic expectation by starting with the original Pitfall and thinking that was good but not revolutionary for the 2600 for its time. Regardless, I won't derail the thread further with general bB questions!

[Fort Apocalypse]

2 hours ago, Al_Nafuur said:

?

Bolo looks very interesting. I've been looking for an idea to make a 2600 online version (via PlusROM functions) of a combat/tank based game.

Bolo is one of my favorites! It was a great game until trolls (or guards for more serious games by others, perhaps) started staying around the entry portals doing things that would make you effectively unable to play, so you'd have to drop off of the server, try again, and the same thing would happen. Maybe people just got too good at it! All folks on servers aren't like that, though, and it seemed to just happen in WinBolo, not in the Mac version decades before; it was so fast, it could've been an AI.

Edited June 22, 2022 by Fort Apocalypse

[+Al_Nafuur]

5 minutes ago, Fort Apocalypse said:

Bolo is one of my favorites! It was a great game until trolls (or guards?) started staying around the entry portals doing things that would make you effectively unable to play, so you'd have to drop off of the server, try again, and the same thing would happen. Maybe people just got too good at it!

Do you have some links to the Bolo documentation and screenshots? Most of the links on the Bolo website seem to be dead ?

 

[Fort Apocalypse]

4 hours ago, Al_Nafuur said:

Do you have some links to the Bolo documentation and screenshots? Most of the links on the Bolo website seem to be dead ?

 

The audio is this video is what games with a lot of lag sounded like, which I imagine is due to slow emulation, but I'm not sure. I was on a faster network in the 90s, and the sounds were much better.

 

The sounds in this are more like they were for a local game and are in stereo which is cool, because I didn't have headphones then:

 

Here's documentation and source:

http://www.winbolo.com/downloads/manual.pdf

https://github.com/milki/winbolo/

http://www.winbolo.org/wiki/index.php/WinBolo_Source_Code

http://www.winbolo.org/wiki/index.php/Design

http://www.textfiles.com/apple/DOCUMENTATION/bolo.txt

http://www.faqs.org/faqs/games/bolo-faq/part1/

http://www.faqs.org/faqs/games/bolo-faq/part2/

 

A book ("The Secret History of Mac Gaming") claims that the name Bolo for the game initially didn't come from the sci-fi. It says Stuart Cheshire's girlfriend in school at Sidney Sussex in Cambridge kept saying "bolo, bolo, bolo" in Hindi to try to get him off the computer to talk to her.

 

Here's a bit about someone at MIT working on a Bolo AI in 1995: https://web.media.mit.edu/~intille/II/inducting_indy.html
 

 

Edited June 22, 2022 by Fort Apocalypse

[Fort Apocalypse]

Changes:

• Selected colors persist after winning.
• If you shoot without pulling back the joystick, it attempts to remove the playfield pixel where the missile lands.
• If you shoot while pulling back the joystick, it attempts to add a playfield pixel where the missile lands.
• Maximum distance of missile varies a little.
• Changes to selectable playfields: first is more complex, second is fully painted, third is empty, fourth is still random but not as dense.

 

 

tanks_2022_0.3.bas tanks_2022_0.3.bas.bin

[Fort Apocalypse]

Changes:

• Can select invisible player tanks that are only revealed when they rotate, move forward, or shoot/build structures.
• The amount of playfield drawn depends on the map number.
• Faster random playfield display during game selection. The game selection is still a little jarring and flashy, but it's fast.
• Either joystick button will start a new game after a player wins (without changing colors).
• Reset switch resets to high-contrast game colors. (If you'd like to play again after a win using the same colors, press either joystick button.)
• Can now do game selection after a win.
• Missiles vary even more in how far they go to help with greater playfield removal and creation.

tanks_2022_0.4.bas tanks_2022_0.4.bas.bin

Edited June 23, 2022 by Fort Apocalypse

[+ZeroPage Homebrew]

On the newest version it seems to be fairly easy to get stuck on a block and be unable to shoot it to make it disappear unfortunately.

 

The black tank in this screenshot is completely stuck, unable to move to get away in any direction. Also trying to shoot while pressing up will create/destroy a block to the right of the one it's stuck on.

 

- James

 

[Fort Apocalypse]

7 hours ago, ZeroPage Homebrew said:

On the newest version it seems to be fairly easy to get stuck on a block and be unable to shoot it to make it disappear unfortunately.

 

The black tank in this screenshot is completely stuck, unable to move to get away in any direction. Also trying to shoot while pressing up will create/destroy a block to the right of the one it's stuck on.

 

- James

 

 

Thanks! When I was just kicking the player back from the wall (like the player in Adventure) it would skip across the playfield backward because it would catch on another playfield pixel since I was moving the tank so quickly, but I'll fix it to kick back again and just not kick back enough to skip. I thought I'd done that but I think it was still catching, so I've have to try it again tomorrow/this weekend and fix that.

 

Speaking of tank speed and the playfield, I have a new version locally where I got the playfield destruction working cleanly, but along with fixing some calculations of pfpixel, I had to slow the missiles down. The tank seems too Combat-ish going at half-speed, so I've got to work on that also, and I'm not sure if slowing the tank down when shooting and speeding it up when not shouting would feel weird, but I bet it will.

 

I also want to share the code I put together to test and verify the missile0, missile1, ball, player0, and player1 to pfpixel x,y calculations. I had something similar in Insane Painter years ago that I referred to when trying to get that working in Tanks 2022, and part of it's in various drawing programs that a few of us have done. But it's a problem I've tried to find a solution before and want to try to help others (and me, possibly) find the solution and not repeat the effort again, though it's possible it's all on RT's page and I should've looked for it. It's a little weird how the calculation varies a little between them, and that seems familar from years ago, but I didn't search for the reason yet.

Edited June 24, 2022 by Fort Apocalypse

[Fort Apocalypse]

Note: I threw away the changes I mentioned to slow the tank and missiles down.

 

Release 0.5:

• Action is still fast!
• Playfield collisions fixed via trudging, which played better than alternatives. (<- Most of the hours were trying collision kickbacks and pfread)
• More maps.
• Less jarring selection, score to show map number (0-255, but for now uses 6 digits), fire to start if select. Slightly more obvious which maps are "fog of war"/invisibility.
• Four of opponents bases must be taken to win.
• Tightened extents for tanks, and placed tank over base.
• 8K romsize. Looked at using DPC+ briefly, but it's still standard kernel.

 

tanks_2022_0.5.bas.bin tanks_2022_0.5.bas

Edited June 27, 2022 by Fort Apocalypse

[SoundGammon]

Here's some tanks:

[Fort Apocalypse]

5 hours ago, SoundGammon said:

Here's some tanks:

We need an Octoatari for Tank 8!

 

[+ZeroPage Homebrew]

10 hours ago, Fort Apocalypse said:

We need an Octoatari for Tank 8!

I'm not saying it should be done but you could implement a TERRIBLE control scheme to control eight tanks with the QuadTari + 8 Paddles (which can only use the button in this configuration).

 

FIRE: Short 1 Button Press. Leave a slight pause before trying to shoot again.

TURN RIGHT: Hold 1 Button Press. Tank with stop turning after button is let go.

TURN LEFT: 1 Short + 1 Long Button Press. Tank with stop turning after button is let go. (Tank will fire once when this is executed, but that's not a problem really)

ADVANCE: 2 Short + 1 Long Button Press. Tank with stop moving forward after button is let go. (Tank will fire once when this is executed, but that's not a problem really)

 

- James

[Fort Apocalypse]

DPC+ kernel version - release 0.1 (branch of the standard kernel game that has different gameplay, and I'm not sure if I'll keep going with it yet)

 

Similar to standard version, but:

• Invincible civilians!
• No slowing down of tank when move on playfield, yet.
• For now, if you shoot a civilian or the other tank, both tanks blow up. The goal is still to get the other player's base, so maybe that doesn't matter.
• Civilians can start drone.
• Better graphics, but it's hard to tear up the playfield as much for now.
• Although I know there's a way to dynamically set background, playfield, and player colors, for now, it doesn't change.
• Invisibility doesn't work yet.

 

 

tanks_2022_dpc_0.1.bas tanks_2022_dpc_0.1.bas.bin

Edited June 28, 2022 by Fort Apocalypse

[+ZeroPage Homebrew]

ZeroPage Homebrew is playing Tanks 2022 on tomorrow's stream LIVE on Twitch, hope you can join us!

 

Tue Jul 12, 2022 @ 6PM PT | 9PM ET | 1AM GMT+1Day

WATCH: https://www.twitch.tv/zeropagehomebrew/

 

Games:

• Spiders and Flies (2022 Exclusive World Premiere | 2600) by Game Select / Ricardo Pim @Ricardo Pim (Design, Development & Game Play), Everaldo Bonifacio (Game Play)
• Tanks 2022 (2022 WIP | 2600) by Fort Apocalypse @Fort Apocalypse
• 1942 (2022 WIP Update | 2600) by homerhomer @homerhomer, Wolfgang Stubig @Al_Nafuur, Philip Blackman @splendidnut / Pat Brady @Pat Brady (Sound)

(WATCH AT 1080P60 FOR BEST QUALITY)