Jump to content
  • entries
    4,956
  • comments
    2,719
  • views
    1,809,810

A-Maze-Ing


atari2600land

839 views

Here's a new maze submitted by gambler172. With this binary file, I've also introduced a new hitting the wall sound. Tell me what you think of it and the maze.

6 Comments


Recommended Comments

Hello Again,

 

I like the music. :)

 

I got bB and I've been playing around with it. I have a much better idea of what can be done with it now. So, now I have more detailed suggestions. :) I know there's only a little bit of RAM in bB, so included an estimate for the RAM cost of the suggestions.

 

You can have several modes. They would be chosen with the select switch at the title screen. You could number them with the score sprites.

 

 

 

1. Easy Mode

This would be timed. At the start of the maze, some sort of prize would pop out of the end point. The object would simply bounce around the maze. This should only take three bytes of RAM. Two for the x and y positions and use four bits for the four directions. If the prize hits a wall check to see which two bits are on. Then reverse one direction. If the prize is still hitting a wall. Reverse the other direction. (If you like this idea, but don't know what I mean, I could explain it better, or even make a demo program.)

 

At the end of every maze, the current score (time left on the clock) could be added to a location in the RAM for the final score. Whenever the player collects a prize, it will add time to the clock rather than directly add points. This would give the player more incentive to go after them, than simply giving them points. Points would be taken away from the final score for dying, but you couldn't completely lose.

 

The prizes can be colored and the finish point made out of the ball. To differentiate the ball from the maze, flicker it at 30 hz which shouldn't look very bad at all on a real television with how dark Gosub's background is. (To keep track of whether the ball is on or off, you could use another bit of that third prize RAM byte.)

 

Check the RAM that holds your current level and have proggressively nicer prizes. For example:

 

 

Total RAM cost: 4 bytes

Rom Cost: at least one maze

 

 

 

2. Hard Mode

In this mode the timer will progressively go up. And the time will be subtracted from some predetermined number, to get the player's final score. If a player dies too many times they'll lose in this mode.

 

Have a solid color sub pop out of the maze's finish point. The sub can move in the four cardinal directions and shoot a harmless "sonar" ping. The ball would be his ping. This should make AI easier to program. The ping will shoot off of the sub in whatever direction he's traveling. Whenever it hits something it will reverse directions and return to the enemy sub. Set up a byte of RAM with a timer. If the ping take too long to come back the sub knows that way is open. If the ping comes back quick the sub knows there is a wall there.

 

You can keep a byte of Ram with above, below, left, and right mapped to four bits for the enemy sub. You can also four more bytes of Ram open with the xpos and ypos the sub was at when the ping returned on each side. Put something in your kernel that says something along the lines of:

If Currentypos - yposwhenleftwallwasdetected > 10 set Thereisawallontheleftbit back to false.

 

That way if the sub detects a wall on the left. The goes up about fifty lines, he isn't still trying to go right.

 

This would take up a lot of RAM, though.

Total RAM cost: at least 9 bytes

 

 

 

Alternating Players

This is something I suggested before. On the title screen you could have 1-8 in one color for easy and then 1-8 in another color for hard (there's a byte of RAM)

 

Each player would get a single go at each maze. When they die a different colored sub we appear at the starting point, and they'd passe the joystick. At the end of the game every player's score would be shown. This is something I suggested before. I don't think it would work though. You need an extra byte of RAM for the title screen. A byte for each player's score. A byte to keep track of whose turn it is. If you don't add anything but multiplayer with individual scores to the game, you're already adding 10 bytes.

 

You'll need to write a routine for cycling through each player's score and displaying different colored subs (this would also probably take a byte of RAM, now that I think about it.)

 

This would be really cool to have, but I'm not sure if there would be room for it. (Ramwise)

 

Cost: at least 11 bytes of RAM

 

 

 

Race Mode

This might be a better solution for multiplayer. Have a time limit on the mazes. No enemies or anything. But if a player dies once they're gone. This would only take two bytes. One to keep track of whose turn it was, and one to keep track of who's alive.

Link to comment

Thanks for the suggestions. I've only been doing Batari Basic since June and it just amazes me how people know precisely how many bytes such and such action does. I'm not really all that good at math. In fact, I'm pretty amazed at what I've done so far in GoSub. How about this for a multiplayer thing? Have both subs go at once and have them race to the finish, maybe try to ram them in the walls or something? Of course the walls shouldn't be deadly, so how about them being sticky or something? I think having just one go is kinda harsh, given the difficulty of some of the later levels. The enemy thing is a good idea too, but the sub would have to be brown because I'm using missile1 for the treasure chest, and its ping would have to be black because I'd be using missile0 for an actual missile. I'll do some fiddling around with the program this week and see what I can do.

Link to comment

Thanks for the suggestions. I've only been doing Batari Basic since June and it just amazes me how people know precisely how many bytes such and such action does. I'm not really all that good at math. In fact, I'm pretty amazed at what I've done so far in GoSub.

I understand. Do what you can with what you've got. Thanks for the reply. :)

 

How about this for a multiplayer thing? Have both subs go at once and have them race to the finish, maybe try to ram them in the walls or something? Of course the walls shouldn't be deadly, so how about them being sticky or something? I think having just one go is kinda harsh, given the difficulty of some of the later levels.
That sounds cool. The reason I suggested alternating multiplayer is there could be about eight people playing. I'm not sure if you meant one go was harsh for my first multiplayer idea or my second.

 

In the first suggestion for alternating multiplayer, even if a player didn't finish a maze, they'd still be playing in the next round. Each player would get one go at each maze. Then the scores would be shown for each player. That doesn't seem to harsh, so I think you were talking about the idea of a "race" mode.

 

If you have eight people playing to elimination, I don't think it would really be that bad. It would go pretty quick, but it's like when you play basketball in the summer and you set the score low, because it's so hot. If it did go by too fast, you move it up to two or three lives for just a byt or two of RAM.

 

The enemy thing is a good idea too, but the sub would have to be brown because I'm using missile1 for the treasure chest, and its ping would have to be black because I'd be using missile0 for an actual missile. I'll do some fiddling around with the program this week and see what I can do.

Hmm . . .

 

Brown enemies sound fine. I'm sort of confused about why its ping would have to be black. I was under the impression that your were using

Player0: sub

Player1: unused

Missile0: unused (noblanklines takes away the option of missile0 right?)

Missile1: Treasure

Ball: unused

 

I thought that meant you would have to use the ball for a ping. I didn't think that you would be able to have missiles and an enemy ping on screen at once. (because they would both need the ball) When I made the suggestion, I was thinking that the enemy sub would take you out the same way the walls do whenever you come into contact with it. You wouldn't have anyway to kill it, but since it's "vision" is so limited the player could outsmart or even trick the enemy sub to get around it.

 

That's also why I said not to time it. A timer and an unkillable enemy would just be frustrating.

 

Good luck,

Robert Jones

 

EDIT: nevermind

Link to comment

You're right, I can't use missile0. That means the ping would have to be the color of the walls (playfield). And I don't want to get rid of no_blank_lines because then it would look crappy. I only have about 1K left in bank 1 (bank 2 is where all the mazes are stored in.), so I'll see how much memory is left after I put in the multiplayer races.

Link to comment
Guest
Add a comment...

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