Jump to content
IGNORED

Batari Basic Game Demo - What do you think


donnerkuh
 Share

Recommended Posts

Hi!

 

I´m from Germany and found batari Basic 3 weeks ago. My dream to create my own ATARI 2600 game has become true now. Batari Basic is a powerfull tool! Please try out my Demo of "Karatakus". If you think it is good enough, i will do my best to finish the game.

 

Jump over the shurikens

Joystick down - the stone will miss you

Joystick left/right and fire to kill the attacking ninja

 

Karatakus.bas.bin

 

Last Version:

Karatakus.bas.bin

Edited by donnerkuh
Link to comment
Share on other sites

Please try out my Demo of "Karatakus". If you think it is good enough, i will do my best to finish the game.

That's a good start! I know it's just in the early stages, so you probably plan to add things, and change things, but I have a few suggestions you might want to consider:

 

It seemed rather hard for me at first, and the only reason I was able to get a high score the first time was because right now the player has infinite lives. Granted, it was my own stupidity-- I kept trying to jump over the rocks, when your instructions clearly said to duck under them (if not in those exact words)-- but it was also because there could be several threats on the screen at the same time. So I would suggest that the game begin at an easier difficulty level to let new players get used to the controls, then increase in difficulty at certain points, based on the player's score, or completing a certain number of screens, or just after a certain period of time. The easier difficulty levels would have fewer and slower threats, but the number of simultaneous threats would increase-- and/or speed up-- as the difficulty level goes up.

 

You might want to add another type of screen or two, so the action would vary, with different goals on each type of screen. This could be tied to the increasing difficulty-- e.g., if there are three types of screens, then the difficulty level goes up after completing the three screens, when you go back to start the sequence over with the first screen.

 

It might be nice to have an overall goal in the game, like having to fight your way past the enemies to find and rescue your kidnapped wife, or teacher, or something like that-- maybe having to rescue several people (one per level), fighting with a "boss" to do that (maybe the boss has the key to their cell)-- with the bosses getting tougher to beat on each level, and the final person to rescue is guarded by the toughest boss (the evil warlord himself, or whatever).

 

By the way, I think pushing up to jump, and pressing the fire button to stand still and throw a punch, works fine. However, it might be interesting to add some additional moves if possible, maybe on other screens (i.e., so overcoming the threats on the different types of screens requires using different skills)-- e.g., jumping up and kicking.

 

Michael

Link to comment
Share on other sites

Sorry, Micheal. I will try to explain (with my ugly english) how the game will work in the final version.

 

Of course, your lives will be limited later. The first level you have played (the difficulty will be reduced later) is a training stage. You will have to collect ten sticks. The sticks appear on a random position, protected by Shurikans, Black Ninjas and Stones. If you have finished this level, you will leave the training area and fight real enemys. You will reach the next levels after collecting enough of the sticks (now called staff of might). If you have collected all parts from the staff of might, you have defeated the evil and became king of your kingdom. I think about 3-5 levels.

 

The number of enemys in my demo ist the maximum, batari basic allows (i payed one missile to get a multicolored player). I have some ideas for additional moves and options, but i have to accept the 2600 hardware and memory restrictions.

 

To Walter: Danke für das Kompliment. Programmierst du auch?

Link to comment
Share on other sites

The number of enemys in my demo ist the maximum, batari basic allows (i payed one missile to get a multicolored player).

You're using player0 for the ninja and shuriken, so you could have up to three ninjas or three shurikens at once by using NUSIZ0 to get multiple copies of player0. That would be easy with the shurikens, since they can't be destroyed, but it would be trickier with the ninjas. First, you'd either have to give up the animation of the ninja falling, or else use flickering so you could alternate between one frame showing the falling ninja, and another frame showing the remaining ninjas. And second, you would need to manipulate NUSIZ0 and player0x as appropriate to remove the ninja that was just knocked down, and adjust the positions of the rest of the ninjas.

 

Michael

Link to comment
Share on other sites

Sorry, Micheal. I will try to explain (with my ugly english) how the game will work in the final version.

 

Of course, your lives will be limited later. The first level you have played (the difficulty will be reduced later) is a training stage. You will have to collect ten sticks. The sticks appear on a random position, protected by Shurikans, Black Ninjas and Stones. If you have finished this level, you will leave the training area and fight real enemys. You will reach the next levels after collecting enough of the sticks (now called staff of might). If you have collected all parts from the staff of might, you have defeated the evil and became king of your kingdom. I think about 3-5 levels.

 

The number of enemys in my demo ist the maximum, batari basic allows (i payed one missile to get a multicolored player). I have some ideas for additional moves and options, but i have to accept the 2600 hardware and memory restrictions.

 

To Walter: Danke für das Kompliment. Programmierst du auch?

 

Hallo

Nein,ich bin nur ein kleiner Hacker und hacke 7800er Spiele.

Gruss Walter

Link to comment
Share on other sites

  • 1 year later...

You're using player0 for the ninja and shuriken, so you could have up to three ninjas or three shurikens at once by using NUSIZ0 to get multiple copies of player0

 

----

 

How does NUSIZ0 work? Where will the copies of player0 appear? How will they move? How does the collision detection work? Does anyone have a codesample, how to use NUSIZ0?

Link to comment
Share on other sites

You're using player0 for the ninja and shuriken, so you could have up to three ninjas or three shurikens at once by using NUSIZ0 to get multiple copies of player0

 

----

 

How does NUSIZ0 work?

"NUSIZ0" stands for "NUmber of copies and SIZe of player and missile 0." You should get a copy of the Stella Programmer's Guide. It can be found in many places on the internet, and there are a few different versions of it. A PDF copy of the original document can be found at http://www.digitpress.com/library/techdocs/2600_Stella_Guide_Rev_A_12-3-79.pdf, and a reconstructed version (which combines it with additional information from the TIA manual) can be found at http://www.bjars.com/resources/stella.pdf. There is also an HTML version at http://www.alienbill.com/2600/101/docs/stella.html. I suggest saving a copy of the reconstructed PDF version, because you can read it offline, and it's searchable.

 

NUZIZ0 uses 5 bits to determine the number/size of player0 and missile0:

- bits 0, 1, and 2 control the number/size of player0, and the number of missile0, and

- bits 4 and 5 control the size of missile0.

Note that you cannot control the number of missile0 separately from the number of player0, so if you set NUSIZ0 to get two copies of player0, you'll also get two copies of missile0, like it or not.

 

Player0 (as well as missile0) has one main sprite and three extra copies, which are spaced as follows:

               bit 0           bit 1                           bit 2
main sprite     near copy       middle copy                     far copy
XXXXXXXX        XXXXXXXX        XXXXXXXX                        XXXXXXXX
<-8 cc-><-8 cc-><-8 cc-><-8 cc-><-8 cc-><-8 cc-><-8 cc-><-8 cc-><-8 cc->
("cc" stands for "color clocks"

You control which copies you want to display by setting the appropriate bits to 0 (turn off that copy) or 1 (turn on that copy). Thus, if you set NUSIZ0 to %00000000 (bits 0, 1, and 2 off), you'll get just the main player0 sprite, with no copies.

 

However, you can't just turn on any of the bits you feel like, because the spacing between the main sprite and any extra copies has to be the same. For example, if you set NUSIZ0 to %00000101, you will not get three copies of player0 (the main sprite, the near copy, and the far copy), because the spacing between the main sprite and the near copy would be different than the spacing between the near copy and the far copy, see? So %00000101 is an "illegal" value-- at least as far as getting multiple copies of player0 is concerned. (That value does something else, as we'll see in a moment.)

 

This means you can get one copy of player0 (the main sprite), two copies of player0 (the main sprite and any one of the extra copies), or three copies of player0 (the main sprite and two of the extra copies)-- but you cannot get four copies of player0 (the main sprite plus all three of the extra copies), because the spacing between the last two copies (the middle copy and the far copy) would be different than the spacing between all the other copies.

 

Thus, the "legal" values for NUSIZ0 are as follows:

 

1 copy:

NUSIZ0 = %xxxxx000 ("x" means that the given bit doesn't affect this, so it can be set to either 0 or 1)

 

2 copies:

NUSIZ0 = %xxxxx001 ("close" spacing, 16 color clocks apart, or a gap of 8 color clocks between each copy)

NUSIZ0 = %xxxxx010 ("medium" spacing, 32 color clocks apart, or a gap of 24 color clocks between each copy)

NUSIZ0 = %xxxxx100 ("wide" spacing, 64 color clocks apart, or a gap of 56 color clocks between each copy)

 

3 copies:

NUSIZ0 = %xxxxx011 ("close" spacing)

NUSIZ0 = %xxxxx110 ("medium" spacing)

 

The "illegal" values aren't really illegal, but they do something else-- you get only one copy of player0 (the main sprite), but its size changes. In all, there are three possible sizes of player0:

 

Player0 sizes (1 copy):

NUSIZ0 = %xxxxx000 ("normal" size, where each pixel of player0 is 1 color clock in size)

NUSIZ0 = %xxxxx101 ("double" size, where each pixel of player0 is 2 color clocks in size)

NUSIZ0 = %xxxxx111 ("quadruple" size, where each pixel of player0 is 4 color clocks in size)

 

Missile0 has four possible sizes, controlled by bits 4 and 5, as follows:

 

Missile0 sizes:

NUSIZ0 = %xx00xxxx ("normal" size, 1 color clock in size)

NUSIZ0 = %xx01xxxx ("double" size, 2 color clocks in size)

NUSIZ0 = %xx10xxxx ("quadruple" size, 4 color clocks in size)

NUSIZ0 = %xx11xxxx ("octuple" size, 8 color clocks in size)

 

In all, there are 32 different possible values for NUSIZ0 for setting the number of copies, the size of player0 (if only one copy is being displayed), and the size of missile0 (regardless of its size).

 

Where will the copies of player0 appear?

The main sprite will appear wherever you've positioned player0 with player0x, and the extra copies will appear somewhere to the right of the main sprite, depending on the size of the spacing between them (see above). For example, if you've set player0x to 20, and have set NUSIZ0 to %00000110 (3 copies, "medium" spacing), the main sprite will be at position 20, the second ("middle") copy will be at position 52 (20 plus 32), and the third ("far") copy will be at position 74 (52 plus 32).

 

But note that, since the sprites wrap around to the left side of the screen if you position them far enough to the right, you might actually get some of the copies on the left side of the screen. For example, if you've set player0x to 150, and have set NUSIZ0 to %00000110 (3 copies, "medium" spacing), the main sprite will be at position 150, but the second copy will be at position 22 (150 plus 32 equals 182, and 182 minus 160 equals 22), and the third copy will be at position 54 (22 plus 32).

 

How will they move?

All of the copies will move together as you move the main sprite with player0x, since the spacing between them will remain fixed and constant. Thus, you cannot move the various copies independently of each other.

 

How does the collision detection work?

It still works as usual-- all copies of player0 are still considered to be player0, so a collision between any portion of player0 and its copies with any of the other objects-- playfield, ball, missile0, player1, or missile1-- will set the appropriate bit of the appropriate collision register.

 

This means that if, for example, player1 has collided with player0, the Atari can't tell if the collision was with the main player0 sprite or one of its copies.

 

By the way, this is also true if you've drawn multiple copies of the sprites on other scan lines. For example, if you've got five independent copies of player0 moving around in five different horizontal areas of the screen, and five independent copies of player1 moving around in five different horizontal areas of the screen, and there's a collision between player0 and player1, the Atari can't tell you which copy of player0 collided with which copy of player1.

 

Thus, if you check the collision registers and see that player0 and player1 have collided, you'll need to use some other method to figure out which copy of player0 collided with which copy of player1-- namely, by comparing the positions of player0 and player1.

 

For example, suppose you have just one copy of player1 (the main sprite) and three copies of player0 set at the "medium" spacing. The Atari detectes a collision between player0 and player1. Which copy of player0 collided with player1? You'll need to check the values of player0x and player0y.

 

Suppose player0x is set to position 50. Since each copy of player0 is 8 color clocks wide ("single" width), and there are 32 color clocks between each copy ("medium" spacing), that means the three copies of player0 occupy the following positions:

 

Positions 50 through 57 = first copy of player0

Positions 82 through 89 = second copy of player0

Positions 114 through 121 = third copy of player0

 

So if player1x is set to position 79, that means player1 occupies positions 79 through 86, therefore it had to have collided with the second copy of player0, see?

 

Once you detect a collision between, say, player0 and player1, what you do next will depend on what you want to happen whenever player0 and player1 collide. For example, if you just want player1 (the hero in your game) to get knocked off the bridge by player0, but player0 will just keep moving along as usual, then all you have to do is perform the code that knocks player1 off the bridge, and it won't even matter which copy of player0 did the knocking-- since you'd want player1 to be knocked off regardless of which copy of player0 hit it.

 

But if you've got multiple copies of player0 (either the ninja or the shuriken), and you want the appropriate copy to disappear if it gets hit by player1, then you'll need to figure out which copy of player0 was involved in the collision (see above), and you'll want to modify NUSIZ0-- and possibly also player0x-- to make that copy disappear without the other copies being adversely affected.

 

For example, suppose you've set player0x to 50, and have set NUSIZ0 to %00000110 (3 copies, "medium" spacing) to get 3 ninjas-- ninja 1, ninja 2, and ninja 3, from left to right.

 

If ninja 1 got hit, then you'll need to change NUSIZ0 to %00000010 (2 copies, "medium" spacing), because one of the ninjas has to disappear-- leaving 2 ninjas-- and they'll still be separated by the same spacing, since the ninja that disappeared was one of the two end ninjas (in this case, the one on the left end). But you'll also need to change player0x to 82 (50 plus 32), since the leftmost remaining ninja will now be at position 82. see? Of course, you'd also need to increment or decrement player0x as usual to keep the line of ninjas moving in whatever direction they were moving in.

 

If ninja 3 got hit instead of ninja 1, then it's even easier, because you just need to change NUSIZ0 to remove the rightmost ninja, but you don't need to change player0x, since you still want the leftmost ninja to be at the same position, see?

 

Likewise, if ninja 2 got hit, then you won't need to change player0x, since the leftmost ninja should still be at the same position it was. But in this case, you'll need to change NUSIZ0 to %00000100 (2 copies, "wide" spacing), because you want to remove ninja 2, and the two remaining ninjas should maintain whatever spacing they had originally with respect to each other-- so you need the main sprite (ninja 1) and the "far" copy (ninja 3).

 

The logic is similar when going from 2 copies to just 1 copy-- set NUSIZ0 to %00000000 (so you're left with just 1 copy, the main sprite), and-- if necessary-- adjust player0x as appropriate so the remaining ninja will maintain its original position.

 

Does anyone have a codesample, how to use NUSIZ0?

I don't have an example ready to post (and I've somehow managed to muck up my installation of batari Basic), but I think you might be able to get things working with the information above.

 

Michael

 

Edited to correct problem where %00 gets "eaten" by the forum software. :(

Edited by SeaGtGruff
Link to comment
Share on other sites

This needs a reset button after you die. I found no way to restart the game without turning the system off and back on. Maybe with each level you should draw a different background.

Yes, I agree about the reset option-- I totally forgot to suggest that. The background change idea is good. Maybe after collecting enough to clear a level, the hero should run off the screen, then run back on the other side on a different background, as if he's making progress toward some destination?

 

Michael

Link to comment
Share on other sites

I was thinking about what I said about wraparound. It raises two issues:

 

(1) If you're displaying multiple copies of a player, and are letting them wrap around from the right side of the screen to the left, then you'll need to keep that in mind when doing your collision checks. For example, if player0x is set to 148, and NUSIZ0 is set to %00000110, and player1x is set to 48, and NUSIZ1 is set to %00000000, then a collision between player0 and player1 would have to be with the third ("far") copy of player0.

 

(2) In this game, you'd probably want to avoid wraparound entirely, because you'd probably want the three ninjas (or shurikens) to appear onscreen one at a time, as if they're coming into view from one side, and then disappear offscreen one at a time, without any of the copies reappearing on the other side of the screen as they exit.

 

I also forgot to say that you'll probably want to use the medium spacing (%00000110), because if the ninjas are too close together, it'd be pretty hard (if not impossible) to jump over them one after the other.

 

Michael

Link to comment
Share on other sites

Thank you for the great help. Now I can work on the game. First i will finish another idea, then i will finish this.

I've started working on some examples of using NUSIZ0 in batari Basic, but I won't have them ready to post for another day or two.

 

Michael

Edited by SeaGtGruff
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.

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

  • Recently Browsing   0 members

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