tetris A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS

[NostAlgae37]

Yup, the pieces definitely looked better with the fewer gradient changes... I tried the old "two-T-block-test.bin" with TV mode enabled in all iterations (Composite, S-Video, RGB) and even in the crappiest video quality they still had a nicer overall appearance and a more convincing 3D effect than the current gradient method that you have been using for your more recent posts. Just my two cents.

[Andromeda Stardust]

I like the color gradients. It helps define the top and botgom edges of the rows. Too bad Chetiry didn't do this. There is enough roomfor two Tetris variants on Atari VCS...

[AkashicRecord]

Yup, the pieces definitely looked better with the fewer gradient changes... I tried the old "two-T-block-test.bin" with TV mode enabled in all iterations (Composite, S-Video, RGB) and even in the crappiest video quality they still had a nicer overall appearance and a more convincing 3D effect than the current gradient method that you have been using for your more recent posts. Just my two cents.

 

I'll go back to that shading method in some upcoming tests for sure. Thanks for the input

 

After all, it may be required. When two players are on the same scanlines (like at the start of a new game) there might not even be enough CPU time to make all of those color changes! Every color change is about 5 CPU cycles, that means that the electron beam advances 15 pixels across the screen...out of 160 visibile pixels. You quickly run out of time to do anything before the next line is drawn on the screen!

Edited November 1, 2018 by AkashicRecord

[AkashicRecord]

Yup, the pieces definitely looked better with the fewer gradient changes... I tried the old "two-T-block-test.bin" with TV mode enabled in all iterations (Composite, S-Video, RGB) and even in the crappiest video quality they still had a nicer overall appearance and a more convincing 3D effect than the current gradient method that you have been using for your more recent posts. Just my two cents.

 

So this old (but better) shading scheme looks great for the pieces and rotations that are 2 game blocks high...but I haven't applied this method to the vertical orientations yet, so I'll have to do some testing there and ask for opinions...

 

 

Oh, and for the record, everyone who is submitting ideas and opinions; you are basically helping to develop the game... I have no objections to list others in the credits for the finished product..

[AkashicRecord]

This morning, I managed to greatly simplify the horizontal and vertical positioning of the game pieces, reducing the majority of the calculations down to 2 or 3 bitshifts, plus one addition. This is great because it's only a few bytes and a few CPU cycles, it could almost even be applied within the joystick handler...

 

The technical details about this is that I can use a default vertical positioning value of 22, shifted left 3 times which multiplies it by 8, giving the exact scanline in which to start drawing...after adding 16 to take into account the floor of the game playfield, of course. The horizontal positioning value has to be multiplied by 4, so that gives a value range between 0 and 9, which when shifted left 2 times multiplies the value by 4. Adding 26 (for Player 1) equates to the left edge of Player 1's game field; Player 2 simply has a larger offset value to position at the left edge of their side of the screen.

 

The most difficult thing about the game playfield is handling the bitmap representation...that is to say, figuring out which parts are empty or not. I want to simplify everything and use exactly the same data representation that will be expected by the TIA (...it's PF registers) if possible, but this complicates things quite nicely...while simultaneously simplifying one part of the problem.

Edited November 1, 2018 by AkashicRecord

[AkashicRecord]

I'll fix the glitch in this one when I have time later, but this sort of demonstrates the playfield grid that I was mentioning earlier, though the left and right movements certainly need to be tamed.

 

This is the first test of the "soft drop," but the condition at the bottom of the screen isn't handled properly because the PieceCanAdvance code hasn't been written yet.

 

Use the button to reset the piece position if/when it bugs out...

 

HPOS-JS-PF-test.bin

(still a little bugged, but better than before)

Edited November 2, 2018 by AkashicRecord

[AkashicRecord]

As you could see, the control is *too* responsive in the above test. This is actually a good thing. It means that with only some minor smoothing, it will be incredibly responsive and fluid.

 

This one is going to knock it out of the park for playability and control...

[AkashicRecord]

Yuck! Today's issue is with positioning of both sprites. I'm definitely missing something minor, and it hasn't jumped out at me yet.

 

I had started to add the second player to the test program, so that the second joystick would independently move a game piece on the appropriate side of the screen...and it was very close to working.

[AkashicRecord]

Alright, so I managed to fix a few of the issues. There is still an occasional scanline glitch at the bottom that I'm not terribly concerned with at the moment...

 

HPOS-JS-TEST2.bin

This update adds 2P joystick movement. The first stick moves the piece on the left, and the second stick controls the right side. Right now, they are in lock-step with each other on the vertical axis because that is one of the next things to tackle.

 

Right now, the pieces move horizontally (independently) but share the same downward movement....this prototype test kind of gives me an idea for a strange game mode... The fire button on P1 resets the vertical location. As you can also see, the 2P piece is just a solid color. I haven't moved on to independent shading yet.

[AkashicRecord]

I added the gradient shading to the second player and it worked, but it was starting to "do too much work" on a scanline which causes a loss of some pixels on the left side. (I completely expected this.)

 

I had already planned on a complete redesign for the actual rendering process anyway, so right now I'm going to back those changes out and work on a joystick handler rewrite (it doesn't handle both players simultaneously very well) and need to work on input smoothing. I may move on over to preliminary piece rotations soon. That's where it starts to get exciting.

Edited November 2, 2018 by AkashicRecord

[AkashicRecord]

I won't have a .bin for this one because it is completely *not* exciting, but it demonstrates the fine positioning of the Player 1 and 2 Missile objects so as to form one side of each player's Well. This example has each Missile object placed to within 1 pixel of the flush edge of the game playfield...

 

HPOS-JS-TEST3.bin

 

You can easily see how the missile objects take the current color of the player on a scanline. This makes it a bit difficult to use them for decoration without things looking a bit...weird. (Press UP to cycle the background colors and see how the colors clash against each other.)

 

I'll play around with some different ideas later, but for now I'm going to ignore the missiles. I'm pleased that they are finally being positioned properly, as only one single function is positioning every game object in under 30 bytes.

Edited November 3, 2018 by AkashicRecord

[CrazyChris]

Are you going to have a one player option?

[AkashicRecord]

Are you going to have a one player option?

 

Absolutely. I had a 1P centered playfield in earlier test programs, but I wanted to focus on 2P from the start. Trying to add a second player later in development would be a major PITA, though the first playable prototypes will probably only have 1P...

[AkashicRecord]

Before I temporarily say goodbye to missiles, I'll have a look at drawing the edges of a single-player playfield using the second player sprite and missile. This might lead to the quickest way to get out a playable prototype.

[Andromeda Stardust]

Before I temporarily say goodbye to missiles, I'll have a look at drawing the edges of a single-player playfield using the second player sprite and missile. This might lead to the quickest way to get out a playable prototype.

I don't think it matters that the screen borders (missiles) match the player color. If you need to, use playfield graphics for the placed bricks and player 1/2 for the bricks in play. If the entire playfield worth of placed bricks needs to be uniform colors, that's okay. Tengen Tetris (NES) even did this. I like the gradients. You could use gradients on the player active bricks (p1/p2 sprites in play), the playfield static bricks (background), and p1/p2 missiles as borders without any mid-scanline color swaps. Two player competitive could even use the ball object to form a thin wall between the two playfields if the missiles cannot be commuted mid scanline.

 

I would love to see coop and competitive modes like Tengen Tetris had. I believe Tengen Tetris used a 12-block wide flayfield (instead of 10) to allow ample room to manipulate p1 and p2 pieces.

https://www.youtube.com/watch?v=GcXrNKfcr3M

[AkashicRecord]

Yes, Tengen Tetris is my primary model for this title. It will definitely have all of those modes in the finished product. (I originally had a 12x20 well for the Co-Op mode, just never posted a screenshot or .bin.)

 

I'll have some "brick" test protos coming soon. I have a few ideas that I think will look pretty good, especially with this new minimalist approach to the playfield walls and decorations.

[+grafixbmp]

Single button controls can work if the button is used as a mode change to the joystick. Joystick alone can move the pieces around and holding the button down can allow left and right on the stick to rotate pieces respectively. Though this method can cause minor slowdown in input at faster levels.

Edited November 4, 2018 by grafixbmp

[AkashicRecord]

Single button controls can work if the button is used as a mode change to the joystick. Joystick alone can move the pieces around and holding the button down can allow left and right on the stick to rotate pieces respectively. Though this method can cause minor slowdown in input at faster levels.

 

You're on my level for sure... I thought about exactly that, but I was concerned about "over complicating" the controls a bit... I had an idea for the single-button control that will help with certain time-critical rotations...but only under certain circumstances. (I'll explain this one later because it is something that hasn't existed in any "Tetris" game, even to this date.)

 

I might be able to squeeze in a few different control methods that will just "work" based on play style. I don't see too much of a problem with only having one button on the standard joystick... (I did want to code in some auto-detection for the Sega Genesis controller if possible, though.)

 

 

On another note... How willing are you to pass the Castlevania 2600 torch to another programmer?

[+fdr4prez]

For the joystick:

Up for CW rotation

Fire for CCW rotation

?

 

Booster Grip?

 

I like the thought of using the Sega Genesis controller.

 

Is the Keypad controller a possibility? You'd have plenty of buttons, but playstyle may be odd using the keypad compared to a joystick

[AkashicRecord]

For the joystick:

Up for CW rotation

Fire for CCW rotation

?

 

Booster Grip?

 

I like the thought of using the Sega Genesis controller.

 

Is the Keypad controller a possibility? You'd have plenty of buttons, but playstyle may be odd using the keypad compared to a joystick

 

If I can test it, I can code for it.

Edited November 5, 2018 by AkashicRecord

[Andromeda Stardust]

For the joystick:

Up for CW rotation

Fire for CCW rotation

?

 

Booster Grip?

 

I like the thought of using the Sega Genesis controller.

 

Is the Keypad controller a possibility? You'd have plenty of buttons, but playstyle may be odd using the keypad compared to a joystick

Then if software detects a Genesis controller (paddle pins pulled high), it maps CW to button C instead of up. Then you get full rotation control, sadly lacking on the Chetiry cart. I probably would have egged my score up past 200k for the big rocket if it allowed ccw rotations. Very difficult frantically trying to rotate pieces 270 degrees in the upper bricks at level 15...

 

I also don't care for modern Tetris interpretations that use hard drops for up. Too many misplaced blocks if I accidentally hit a diagonal.

[AkashicRecord]

Any objections to the game pieces coming into play with the "flattest" side down? (Sometimes this can make it possible to put pieces into play with hardly any rotations required.)

 

I kind of forget what the "standard" method is for this aspect of the game. I kind of always just made my own rules here.

[AkashicRecord]

Well, it seems that this kind of information is a bit easier to come by these days.

 

This is the "SRS" or Super Rotation Standard for the game. It gives each piece 4 unique rotations...except the square. This causes some minor horizontal and vertical translations for the Z, S and Line pieces which are absent from many Tetris variations...

 

 

If there are any that object to this rotation behavior, I could have this as an "SRS On / Off" game option toggle before the start of a game.

Edited November 6, 2018 by AkashicRecord

[AkashicRecord]

Ok, so I've started some serious coding for the block rotations, and I've added an assemble-time constant to enable or disable the peculiarities of the SRS system. This way, I'll be able to roll out some prototypes that have the feature, and some that don't, without having to code a detailed options system (yet), and I can still work from the same source file without having to maintain multiple versions...because that is how the nastiest bugs are born.

 

Most of this stuff is just a bunch of onerous pointer preinitialization to facilitate fast loading within the display kernel(s), and handling the application of horizontal and vertical grid position "kludges" to tweak the sprite placement. (The only reason that is necessary, is that the VCS doesn't really have a screen coordinate system, per se, so you have to perform extra bookkeeping to know which particular scanlines to "hit" on, or not... Vertical positioning is rather ad-hoc on the 2600.)

Edited November 6, 2018 by AkashicRecord

[TheHoboInYourRoom]

If there are any that object to this rotation behavior, I could have this as an "SRS On / Off" game option toggle before the start of a game.

I myself am used to the behavior of Game Boy Tetris, which rotates S and Z pieces such that they appear as they do in the third and fourth columns of the chart you posted. I pieces are rotated about the second block from the left (in horizontal orientation).

I'm not particularly fussed about the nuances of I pieces, but I have basically no experience with any Tetris where pieces translate as they rotate.