Jump to content

Cybearg

Recommended Posts

Here is an example of drawing three color blocks on the same row that you can look at:

 

post-7074-0-79486100-1359790805_thumb.png

 

ThreeColorBlocks.zip

 

 

This was just meant as an example to do color changes mid-line. So for your game you would probably make a few more mini-kernels, one for the middle row with the heart, one for the other two block rows, and some code that preps between each mini-kernel.

 

For the above routine I posted you would also need to add in some code to handle drawing the shot in that area. A "skipdraw" type of code (search for that and you will find it).

 

I suggest you jump to each mini-kernel as a subroutine. In the prep before that subroutine move the particular color values into a some temporary registers, which you then use in that subroutine. I would help you more with this game, but I'm really pressed for time right now (I got three tests coming up this week). There are plenty of good people here on AA though that I'm sure would be willing to give you a few pointers. :)

Link to comment
Share on other sites

I wish there was some mini-kernel magic that could allow for multi-coloured playfields.

 

I still say he could fake it by alternating playfield rows and even adding some "animation" to the playfield.

 

Note that I change the COLUPF value every time I cycle the playfield colors. This is because the first row of playfield pixels is incorrectly colored when using pfcolors. A workaround is to set COLUPF as it effects the first row of playfield pixels (for some reason).

post-13304-0-43106800-1359793845_thumb.jpg

colorswirl.bas

colorswirl.bin

Link to comment
Share on other sites

Note that I change the COLUPF value every time I cycle the playfield colors. This is because the first row of playfield pixels is incorrectly colored when using pfcolors. A workaround is to set COLUPF as it effects the first row of playfield pixels (for some reason).

 

Another fix is to make sure your latest pfcolors choice is used every time before drawscreen:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernop_pfcolors

 

 

I probably have the numbers wrong, but you can adjust them:

 

colorswirl_2013y_02m_02d_0626t.bas

Link to comment
Share on other sites

Another fix is to make sure your latest pfcolors choice is used every time before drawscreen:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernop_pfcolors

 

 

excellent.

that fixed mine so here it is.

still doesn't look very good to me.

http://pastebin.com/fHQFsUeJ

 

I also wrote a javascript to write out the pfcolors statements

if anybody has a mind to play with it

http://pastebin.com/x15JBkqn

Edited by bogax
Link to comment
Share on other sites

I don't know enough about BB to say whether or not you can replace most of the kernel with assembly. That would be the ideal solution, where you could insert some assembly inline and compile the whole thing from one source.

 

An alternative would be to compile the game as is, and patch in the assembly routine where the BB kernel normal lies (since you won't be using it anyhow).

I was thinking that as well--that I could compile the game, then replace what is needed with an alternate kernel. As long as I knew exactly what to replace and what to replace it with, I'm okay with a workflow that involves me doing that.

 

As to draw it, I believe the routine right now is storing all the PF block bits in ram. You could instead just store the colors for the individual PF (you probably already are), and color the playfield blocks black as they get hit to hide them. Does that make sense?

That's basically what I'm doing, though it's very code-heavy (unless someone has some alternative suggestions for how to do it). The program takes the first 16 variables, a[0] through a[15], and assigns them a number. That number is the color value that will be used for each of the sixteen blocks on-screen, starting at the absolute top one and moving clockwise. The game then does a loop through all the values a[0] through a[15] and, if the color is red, it draws that pfpixel and then sets the playfield to red. If not, the pfpixel is not drawn. Then, it drawscreens and cycles through the main loop again, this time for yellow, then again for blue. So, it takes 3 full cycles of the main loop in order to color every block, and each pfpixels is black for 2/3 frames, which results in significant flicker because each of them is actually black for longer than they are a color.

 

Also, this is a very labor/code-intensive way to determine the colors and makes adding further colors essentially out of the question because of the bulkiness of that code, plus each additional color increases the time that all the other colors are black, thus increasing the flicker. If I did the whole 8 colors that I would prefer, you'd only get a fleeting glimpse at which color is supposed to be being rendered.

 

The reason in this case is it would make the assembly portion much easier to do. Essentially the playfield would be set up in reflected mode, and the circular pattern would be drawn each screen with each block its unique color (or black to be hidden).

 

I believe from your code the collisions are being handled through software, so that should still work.

I don't know what "reflective" mode means, but the circle pattern should not be mirrored, if that's what you're saying. There could be a color standing alone in any location, since it's randomized.

 

But yes, I'm doing it using pfpixels and yes, the collisions are being handled by a series of if-then statements. I'm going to go back and test the code suggestion on the previous thread page to see if it works/is more efficient, but for the time being, every main loop cycle, the location of the ball is checked against these ranges, and if it falls within a range, the color of the ball is checked against the color of the pfpixel in that location and either it's a good hit or a bad hit.

 

Actually, I just had the thought that you are probably in asynchronous mode. That is okay, it is easy to deal with too.

 

Edit:

It would also be nice to know what you are drawing the heart and shot with. Is GRP0 the heart, and GRP1 or M1 the shot?

I've never heard of GRP0 and GRP1. What are those?

 

The heart is Player0. The ball is Player1. This is because missiles take on the color of the player, which is wrong. The ball needs to take on and retain the color of the central heart as soon as the trigger is hit. The color should not be varying once the ball is in play.

 

From the last video I dun get why there is flicker and soft collisions.

 

Can't you use traditional collision(missile0, playfield) when the players shot hits a block?

 

Also, you don't really need multiple colors per row. Stagger the playfield blocks between rows. This should work except for the topmost row and bottom.

The flicker comes from swapping between rendering the red, then yellow, then blue.

 

Well, the color of the ball, when spawned, needs to remain the color of the heart at the moment of the ball's spawning.

 

Maybe I can use traditional collision, but so far as I know, that just checks to see if something collides with something, but doesn't take not or has any feedback indicating WHERE it took place. The game isn't just about hitting a ball to a block--a central gameplay element is hitting the right color of ball to the right color of block. If I can't compare the color of the ball at the time of collision to the color of the specific block that it hit, it won't work.

 

The reason I don't stagger the blocks, aside from that the symmetry more strongly implies a circular shape, is due to calculating ball trajectory. Since there are too few pixels at play for the ball to move at 1/2 or 1/4 value, I have to handle all that manually. +1 x and +0 y will cause the ball to move up. +1 x and +1 y will cause the ball to move up and to the right at about 45 degrees. +0 x and + 1 y will cause the ball to move straight right. So you can only possibly hit 8 out of the 16 blocks on the playfield.

 

The point of the other 8 blocks is to see which colors are where and to react faster. When playing, in my opinion, it isn't nearly so evident that half the spots on-screen will never possibly be hit by the ball.

 

As a result, I only have soft collisions for blocks at every 45 degree increment, since the ball will never hit the every 22.5 degrees.

 

If the blocks were staggered, it would be difficult to make those numbers work to guarantee a collision path, wouldn't it?

 

Here is an example of drawing three color blocks on the same row that you can look at:

 

post-7074-0-79486100-1359790805_thumb.png

 

ThreeColorBlocks.zip

 

 

This was just meant as an example to do color changes mid-line. So for your game you would probably make a few more mini-kernels, one for the middle row with the heart, one for the other two block rows, and some code that preps between each mini-kernel.

 

For the above routine I posted you would also need to add in some code to handle drawing the shot in that area. A "skipdraw" type of code (search for that and you will find it).

 

I suggest you jump to each mini-kernel as a subroutine. In the prep before that subroutine move the particular color values into a some temporary registers, which you then use in that subroutine. I would help you more with this game, but I'm really pressed for time right now (I got three tests coming up this week). There are plenty of good people here on AA though that I'm sure would be willing to give you a few pointers. :)

This looks very much like what I need! I'll definitely ask around to see what can be done, but if worst comes to worst, I can always wait a week or so 'til you've got more free time. :D

I wish there was some mini-kernel magic that could allow for multi-coloured playfields.

 

I still say he could fake it by alternating playfield rows and even adding some "animation" to the playfield.

 

Note that I change the COLUPF value every time I cycle the playfield colors. This is because the first row of playfield pixels is incorrectly colored when using pfcolors. A workaround is to set COLUPF as it effects the first row of playfield pixels (for some reason).

I think that you're not quite understanding the way that the game works. Here, let me show a couple videos:

 

is of the game in its current state. Towards the end of the video, I slow down the footage so that you can see what it's doing.

 

is the game I designed about a week ago for GlobalGameJam, which this Atari game is crudely based off of. Obviously, I can't do much of what was in the original game, but I'm finding compromises where I can. It should give you a better sense of how the gameplay is supposed to work.
Link to comment
Share on other sites

excellent.

that fixed mine so here it is.

still doesn't look very good to me.

http://pastebin.com/fHQFsUeJ

 

I also wrote a javascript to write out the pfcolors statements

if anybody has a mind to play with it

http://pastebin.com/QQRFmVc0

It's a neat idea, but keep in mind that the playfield's colors must be retained during left and right rotation and the right color of ball must go to the right color of block (or, in the case of secondary colors, either of the two primary colors that make up that secondary color). I worry that the back and forth animation to make this possible with be almost as sickening to the player as the flicker itself.

Link to comment
Share on other sites

I just realized you have a title screen as well. So the BB kernel is still needed. The simplest, probably most non-intrusive way to make your game flicker free is to expanded it to 8k, and leave the new bank empty.

 

An assembly kernel could be put in the new bank, and since there is so much room it could all be unwound and the registers that hold your color and and playfield graphics could be directly accessed without using jump to subroutines, or temp registers. The blocks wouldn't have to be hidden by coloring them black. The blocks would be gone because BB would have taken that block out of ram. Once all the graphics are drawn every frame hardware collisions could be used (if desired).

 

So you would compile the game with some inline assembly in the other bank. At this point the game would still be using the old BB kernel, and flicker. You then have to manually edit the rom with a hex editor (like HOM3) to get the game to bankswitch instead of running the BB kernel. Once inside the new bank the assembly logic would decide if the title screen is being drawn. If it is then a jump and bank switch would occur to go back to the BB kernel. Otherwise the assembly kernel would draw. Finally after the assembly kernel a jump and bankswitch occurs to go back to the BB side, and hand off control.

 

 

I know that sounds like a lot, but for an experienced assembly programmer it's not to bad. Since you would be starting out with assembly this might be a little bit too much to ask. You will probably need help to do it, but the plan of attack is there.

 

 

Once the game is finalized (and you compile the assembly in) then there should only have to be a few bytes that need patching if you make changes (I.e. to perform a bankswitch in 1 place, maybe 3 bytes total). Everytime you make a new rom you would have to patch that area, and hopefully that area never changes. The idea and key here is that there is only a small area to patch to get the game working, making the work as little as possible.

Link to comment
Share on other sites

I worry that the back and forth animation to make this possible with be almost as sickening to the player as the flicker itself.

 

yeah that's why I said it still doesn't look very good.

 

interestingly I can see it as either two alternating patterns that jump

back and forth with out regard to the colors or as rotating colored

blocks

I don't know how common that would be but it might take some

practice/concentration for some people to see it correctly.

Edited by bogax
Link to comment
Share on other sites

So you would compile the game with some inline assembly in the other bank. At this point the game would still be using the old BB kernel, and flicker. You then have to manually edit the rom with a hex editor (like HOM3) to get the game to bankswitch instead of running the BB kernel. Once inside the new bank the assembly logic would decide if the title screen is being drawn. If it is then a jump and bank switch would occur to go back to the BB kernel. Otherwise the assembly kernel would draw. Finally after the assembly kernel a jump and bankswitch occurs to go back to the BB side, and hand off control.

 

 

I know that sounds like a lot, but for an experienced assembly programmer it's not to bad. Since you would be starting out with assembly this might be a little bit too much to ask. You will probably need help to do it, but the plan of attack is there.

 

 

Once the game is finalized (and you compile the assembly in) then there should only have to be a few bytes that need patching if you make changes (I.e. to perform a bankswitch in 1 place, maybe 3 bytes total). Everytime you make a new rom you would have to patch that area, and hopefully that area never changes. The idea and key here is that there is only a small area to patch to get the game working, making the work as little as possible.

 

With the standard caveat IAFFAE (I am far from an expert)

I don't think it would take all that.

you might be able to do it with the normal bB far call

(what ever it's called in bB) but if not I think you'd just have to

have a few bytes of ASM to replace the normal drawscreen

statement.

that is to say you'd have your custom kernel in it's own bank

and go to it instead of the bB kernel using the normal (more or less)

bB facilities I don't think you'd have to go in and patch stuff

(and even if you did you could do it in the ASM listing I expect)

might have trouble with conflicting labels I don't know how that's

handled in bB (ie can you create name spaces on a per bank

basis, can labels be the same if they're in different banks or

will that confuse the assembler)

Edited by bogax
Link to comment
Share on other sites

I've never heard of GRP0 and GRP1. What are those?

 

The heart is Player0. The ball is Player1. This is because missiles take on the color of the player, which is wrong. The ball needs to take on and retain the color of the central heart as soon as the trigger is hit. The color should not be varying once the ball is in play.

 

 

GRP0 and GRP1 are the true names of Player0 and Player1 (I think). I'm not intimately familiar with BB, and sometimes the names used in BB throw me off because I'm not sure if they are referring to hardware or a ram location. GRP0 and GRP1 are the hardware registers that hold the graphics for player zero, and the graphics for player one. Hence shortened to GRP0 and GRP1.

 

 

The advantage of using BB is that it is quick. You can try an idea out and modify it on the fly. So that makes it very flexible. What makes BB rigid is that you sacrifice absolute control over the 2600. You see in assembly you have complete control of your kernel, and all the of the backbone of your game down to the very cycle. This allows the programmer to pull off some radical routines. After a while an assembly programmer develops a deep understanding of what the 2600 is really capable of. I sometimes see posts from purely BB programmers where they believe the 2600 is constrained in ways that it is not. I want to point out that these are not because they only use BB. These are artifacts from never learning more of what the 2600 is doing behind the scenes. To be a powerful BB programmer you should also learn how the 2600 really works. Andrew Davie's lessons are the best place to start for that.

Edited by Omegamatrix
Link to comment
Share on other sites

I just realized you have a title screen as well.

No, the "title screen" is just two playfield drawings that alternate. I'm not using bB to do anything special there, at least not in regards to your ability to create "Titlescreens." I don't even really know what those are or how they work.

 

Besides, if I had to choose between a means of making the game itself work and cutting out a title screen, the title screen would get chucked in a second.

 

So the BB kernel is still needed. The simplest, probably most non-intrusive way to make your game flicker free is to expanded it to 8k, and leave the new bank empty.

Just like that? I can set the game size to 8k, but how would that do it? Would it just speed up operations to the point that the flicker wouldn't be noticeable anymore?

 

An assembly kernel could be put in the new bank, and since there is so much room it could all be unwound and the registers that hold your color and and playfield graphics could be directly accessed without using jump to subroutines, or temp registers. The blocks wouldn't have to be hidden by coloring them black. The blocks would be gone because BB would have taken that block out of ram. Once all the graphics are drawn every frame hardware collisions could be used (if desired).

Note that the blocks are not hidden by being colored black. I call pfclear at the top of the main loop and then draw either red, yellow, or blue blocks, depending the value of a variable called flicker, which is either 0, 1, or 2 (and draws a color accordingly).

 

So you would compile the game with some inline assembly in the other bank. At this point the game would still be using the old BB kernel, and flicker. You then have to manually edit the rom with a hex editor (like HOM3) to get the game to bankswitch instead of running the BB kernel. Once inside the new bank the assembly logic would decide if the title screen is being drawn. If it is then a jump and bank switch would occur to go back to the BB kernel. Otherwise the assembly kernel would draw. Finally after the assembly kernel a jump and bankswitch occurs to go back to the BB side, and hand off control.

Okay... I don't fully understand and I have no clue what to actually write to do this, but I'm glad that there's a possible solution! Also, bB converts the .bas file to .asm before compiling it, so I could always edit the assembly file at that stage, rather than HEX-editing the finalized .bin file, although I do have a HEX editor to do so if necessary.

 

I know that sounds like a lot, but for an experienced assembly programmer it's not to bad. Since you would be starting out with assembly this might be a little bit too much to ask. You will probably need help to do it, but the plan of attack is there.

I'm just relieved by your optimism! Any suggestions of who I could/should get into contact with for help on doing what I need to do here?

 

Once the game is finalized (and you compile the assembly in) then there should only have to be a few bytes that need patching if you make changes (I.e. to perform a bankswitch in 1 place, maybe 3 bytes total). Everytime you make a new rom you would have to patch that area, and hopefully that area never changes. The idea and key here is that there is only a small area to patch to get the game working, making the work as little as possible.

Sound simple enough.

 

With the standard caveat IAFFAE (I am far from an expert)

I don't think it would take all that.

you might be able to do it with the normal bB far call

(what ever it's called in bB) but if not I think you'd just have to

have a few bytes of ASM to replace the normal drawscreen

statement.

What do I need to do to call ASM in bB? Do you know?

 

GRP0 and GRP1 are the true names of Player0 and Player1 (I think). I'm not intimately familiar with BB, and sometimes the names used in BB throw me off because I'm not sure if they are referring to hardware or a ram location. GRP0 and GRP1 are the hardware registers that hold the graphics for player zero, and the graphics for player one. Hence shortened to GRP0 and GRP1.

Ah, that makes sense, then.

 

To be a powerful BB programmer you should also learn how the 2600 really works. Andrew Davie's lessons are the best place to start for that.

I've read the first nine of his lessons so far, so I'm fleetingly familiar with how it works and what numbers are involved.

 

I love that acronym. If you can simply call the assembly kernel instead of the BB one, then yeah that's the way to go. At least everytime you compile it wouldn't be a nightmare! :)

So how would I do this, then?

Link to comment
Share on other sites

obviously this is untested but it compiles.

I may well have goofed something up.

 

I rewrote the collision code you posted to get rid of those

redundant if-then statements (and then stuck a couple of

my own in)

 if playerx1<50 || playerx1 > 117 then goto skip_collision_test
if playery1<9 || playery1 > 94 then goto skip_collision_test

for i = 0 to 14 step 2
if a[i] then collision_test
nexti
next

skip_collision_test
if player1x = 0 || player1y = 0 then goto 750
if player1x=156 || player1y = 140 then goto 750


collision_test
temp1 = playerx1-xtbl[i]&127
if temp1>3 then goto nexti
temp1 = playery1-ytbl[i]&127
if temp1>5 then goto nexti
if a[i]<>ballcolor then goto bad_hit

rem good_hit
a[i]=0

bad_hit


750

data xtbl
81, 00, 114, 00, 130, 00, 114, 00, 82, 00, 50, 00, 34, 00, 50
end

data ytbl
9, 00, 17, 00, 49, 00, 81, 00, 89, 00, 81, 00, 49, 00, 17
end

 

edit: goofed the datastaments up (now fixed I hope)

should probably interleave the x and y values but

this is just ment as illustration so I didn't bother to

obfuscate

Thanks much for this! It didn't quite work and I ended up varying a fair bit, but if you hadn't made the suggestion, I wouldn't have known to use a data group (or even what they were, really).

 

Now if only I could simplify my big lists of pfpixel coordinates with a data set. Is that possible? Such as pfpixel [temp1]?

 

Your suggestion cut my ROM size from about 170 bytes to 734 bytes. I'd love to do THAT again!

 

By the way, how many data sets am I allowed? Or is it just as many as I like, so long as they don't total over 256 bytes?

 

Thanks for all the information on the assembly and kernels, folks. I'll check it out, though I'll probably still need a lot of help writing that kernel. Still, things are getting better and better!

 

 

EDIT:

 

And after some more thinking and tweaking, I've cut things yet further, down to 1239 bytes to spare! And with an easier set-up for expansion, to boot, though that size efficiency comes at a bit of a cost of CPU speed. I idle at solid 1024 when on the title screen (which bypasses almost all the code for calculating ball location, colors, etc. until joy0fire wakes it up. When running normally, I can see the numbers going from anywhere between 300 and 1000 in rapid succession. When a ball is in play and I'm rotating the colors, it goes down to anywhere between 300-something and 700-something, sometimes hitting 1000-something here and there.

 

This is quite the change from a few days ago, when my code only had about 100 bytes to spare but the cycles were regularly at 1300-1700. Still, the game is set up to be more easily expanded now, so all that is really needed still is that kernel stuff.

Link to comment
Share on other sites

Now if only I could simplify my big lists of pfpixel coordinates with a data set. Is that possible? Such as pfpixel [temp1]?

 

it'd help if you posted what you've got now so we

can see where you are.

is it secret?

 

this is meant to be a more compact version

of what you posted before

 

untested etc.

for i = 0 to 15
pfclear : pfpixel ctbl[i] rtbl[i] on : COLUPF = a[i] : drawscreen
next

data ctbl
16, 20, 24, 27, 28, 27, 24, 2, 18, 12, 8, 5, 4, 5, 8, 12
end

data rtbl
0, 0, 1, 3, 5, 7, 9, 10, 10, 10, 9, 7, 5, 3, 1, 0
end

 

Your suggestion cut my ROM size from about 170 bytes to 734 bytes. I'd love to do THAT again!

 

By the way, how many data sets am I allowed? Or is it just as many as I like, so long as they don't total over 256 bytes?

 

 

right

edit as many data statments as you want up to 256 bytes EACH

Edited by bogax
Link to comment
Share on other sites

it'd help if you posted what you've got now so we

can see where you are.

is it secret?

Ah, no, it's no secret. I just didn't know of a need to spam with a ton of more code, that's all.

this is meant to be a more compact version

of what you posted before

 

untested etc.

After a bit of tweaking, this worked wonderfully! I changed it to render by pfpixel's color, rather than after each individual pfpixel. Once I get a kernel that will let me update mid-scanline, though, it'll probably be closer to your code.

 

Still, it saved me another 200 bytes or so! That brings me up to 1438 bytes (and two variables) to spare after implementing your suggestion along with some crazy crap I was doing to make things more efficient.

 

right

edit as many data statments as you want up to 256 bytes EACH

Where is this being stored, out of curiosity?

Link to comment
Share on other sites

Where is this being stored, out of curiosity?

the data statements go where ever you put them and the code

jumps around them.

there's a compiler optimization, noinlinedata, which I believe just

tells the compiler not to generate the jumps so you have to put

the data statements where code won't run in to them.

Edited by bogax
Link to comment
Share on other sites

the data statements go where ever you put them and the code

jumps around them.

there's a compiler optimization, noinlinedata, which I believe just

tells the compiler not to generate the jumps so you have to put

the data statements where code won't run in to them.

I meant in the context of memory. The 2600 and its cartridges have very limited space, which is why we only get 26 variables, each of which can hold a single byte. How do we also get as many 256-byte data sets as we want? Where is that information stored? It must go into some area of the RAM that isn't available for normal processes, eh?

Link to comment
Share on other sites

I meant in the context of memory. The 2600 and its cartridges have very limited space, which is why we only get 26 variables, each of which can hold a single byte. How do we also get as many 256-byte data sets as we want? Where is that information stored? It must go into some area of the RAM that isn't available for normal processes, eh?

not in ram, in rom with the code, which is why either the code has to

jump around it or you have to put it out of the way of the code.

and it's read only.

Edited by bogax
Link to comment
Share on other sites

Thanks to SeaGtGruff, the bB page has a slowly growing glossary. Here is the section about memory:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#glossary_memory

 

 

And thanks to Wikipedia, SeaGtGruff, and GroovyBee, there is also a Basic Questions section:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#basic_questions

Link to comment
Share on other sites

I watched the video of the original game and of the Atari 2600 WIP. How many rows (concentric circles) are you going for? The video of the original game started with 1 circle and went up to 2 circles, but I got the impression it would have added more as the game progresses?

There are some gameplay aspects of the original game that I don't think will be able to be replicated. For instance:

 

1. In the original game, yes, there are up to 3 circles, which increases stage complexity as well as difficulty, since you have less time to move a color on the circle to the correct color of ball.

 

2. In the original game, the heart at the center, in addition to serving as a life meter and to indicate which color of ball will be spawned if the player hits the trigger, also serves as a means of increasing difficulty. With more life, the heart gets larger, which in turn, like the added rings, gives the player less time to react to the random location of the spawned ball, so the game requires more strategic thinking about which colors are most wanted at a particular time.

 

3. In the original game, the player gets 3 strikes for each heart, so the player technically has 9 lives. I haven't decided yet whether or not to be that generous with the 2600 version, seeing as there will never be more than 16 blocks on-screen at once, while the original could get about 30 with the three rings and at increasing difficulty.

 

4. The original game was intended to be music-based, so the heartbeat is synchronized to the BPM of the song that's playing (though it may not have been done quite perfectly). For faster songs, this means that the player will need to react faster to the colors that are being swapped with the heartbeat, but the rhythm could also assist the player and improve response. Obviously, this isn't really an option with the 2600 version.

 

Both of these things will likely have to be dropped for the 2600 version. Unlike the original game (which was somewhat clumsily thrown together in Unity over a 27-hour period), the speed of the ball cannot be precisely regulated, the angles of the ball are limited, the locations of the blocks are limited, etc. I think that the game can still be enjoyable and challenging with just a single ring, so long as there's a degree of randomization. Ideally, someone will offer a kernel that will allow me to have multiple colors on screen at once without the flicker so I can add more possible colors to the blocks, including:

 

1. Secondary colors - any of the two primary colors that make up a secondary color can be used to break a secondary color block

 

2. White - Any color can break a white block, plus, at least in the original game, it gives the player +1 heart. They do not spawn nearly as often as the other colors, and it will probably only be a 1/20 or 1/30 chance in the 2600 version, particularly since, unlike the original, there is not really any added difficulty from having a larger heart.

 

3. Black - We didn't get around to doing this in the original, but I'd like to add a chance for black blocks (which would spawn about the same as white blocks). They cannot be broken by any color and must be avoided entirely. The challenge, then, is that the level will seem to spawn with some blank spaces. The player must remember where those blank spaces are in relation to other blocks around it, since once all other blocks are removed, one won't be able to see the black blocks against the black background.

 

If I can implement all these things, I'll set up a series of randomized levels that follow a basic pattern to introduce the player to new concepts, as is done in the original game, but eventually the game will enter a randomized loop where the player gets about a 15 percent chance for each of the primary or secondary colors and a 5 percent chance for white and black blocks. I hope that this degree of complexity is sufficient for an enjoyable 2600 game, as that about reaches the extent of how how complex I intended the gameplay to get.

Link to comment
Share on other sites

I had thought there might be as many as three rings, so that's what I started with in a screen mockup using Paint.

 

You can use the player size register to increase the size of the heart. There are up to 3 player sizes-- normal width, double with, and quadruple width. I think quad might be too big as is, but you could decrease the number of pixels slightly while making the player bigger to make the size increase look more natural (less dramatic). For instance, if the smallest heart is 8 pixels wide, then a double-size player would be 16 color clocks wide (2 color clocks per pixel). So for the third size you could decrease the heart to 6 pixels wide, which would be 24 color clocks wide for a quad-size player (4 color clocks per pixel), or only 3 times the size of the smallest heart as opposed to 4 times the size. That might make the heart look a little too blocky at the largest size, but another option is to draw the largest heart using two double-size players-- the left half with player 0 and the right half with player 1. Yet another option would be to draw the double-size heart using two players so you can still get the same pixel size (16 pixels total, 8 for each half), then draw the triple-size heart with one player sandwiched between two copies of the other player with the second copy being reflected (24 pixels total, 8 for the left side, 8 for the center, and 8 for the right side).

 

I'm tinkering around with some ideas for a custom kernel, and will post more if I can come up with something feasible.

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...