Jump to content
IGNORED

Gosub


atari2600land

Recommended Posts

I think a chase through every level would be very difficult to program. As for the mine idea, I'll wait and see if this enemy sub is unpopular.

 

I wouldn't use the chase for every level. Just have a chase level every now and then to break up the game action. Same thing with the mines. Variety is the spice of life, and also the lifeblood of a good game. Keep up the good work. :thumbsup:

Link to comment
Share on other sites

Chris,

 

I like the idea of moving obstacles, but beware of randomness.

 

Remember what Archer McClean (a famous game programmer) once said: if you can't blame the computer for dying in a game, than it's a good game.

 

8)

That's why I was thinking a giant octopus might be good, rather than an enemy sub. For one thing, I don't think an enemy sub would move randomly unless it had a problem with steering or "visibility"-- especially once the player's sub came into its view. Also, the idea of the octopus (as I suggested before) is that if it's touching you only a little bit, then it slows you down just a little bit-- but the more it wraps around your sub, the more it slows you down, eventually stopping you completely and causing you to lose a life. Maybe you could have some kind of electrical charge to zap it and make it let go, but then it look a little time to build up another charge. The idea is that the octopus would move around randomly-- much as the enemy sub is currently doing-- and then once the player's sub got within a certain distance and was in the octopus's line of sight, the octopus would swim after the sub. But the octopus should swim in a jerky manner-- go, stop, go, stop, which could even have two different sprite shapes so it looks like the octopus is swimming-- and swim more slowly than the player's sub moves, otherwise the player wouldn't have much of a chance against it. As for how much the octopus is wrapped around the player's sub, that would be determined by comparing the coordinates of the two sprites. :)

 

Michael

Link to comment
Share on other sites

That's why I was thinking a giant octopus might be good, rather than an enemy sub. For one thing, I don't think an enemy sub would move randomly unless it had a problem with steering or "visibility"-- especially once the player's sub came into its view. Also, the idea of the octopus (as I suggested before) is that if it's touching you only a little bit, then it slows you down just a little bit-- but the more it wraps around your sub, the more it slows you down, eventually stopping you completely and causing you to lose a life.

Could you help me with this one? I don't really think I have the programming skills in order to do this alone.

Link to comment
Share on other sites

That's why I was thinking a giant octopus might be good, rather than an enemy sub. For one thing, I don't think an enemy sub would move randomly unless it had a problem with steering or "visibility"-- especially once the player's sub came into its view. Also, the idea of the octopus (as I suggested before) is that if it's touching you only a little bit, then it slows you down just a little bit-- but the more it wraps around your sub, the more it slows you down, eventually stopping you completely and causing you to lose a life.

Could you help me with this one? I don't really think I have the programming skills in order to do this alone.

Sure, I can help you try it. :) It may turn out to be a crummy idea, but you'll never know until you try it!

 

Michael

Link to comment
Share on other sites

Chris, I really think this can become a great game.

 

Try to keep the colours in style (blue for the water and green, brown or black for the walls or seaweed).

 

post-6203-1167775445_thumb.jpg

 

Know what I mean?

 

Perhaps the further you come, the darker it gets?

 

What about falling rocks?

 

BTW, I really like this level:

 

post-6203-1167776798_thumb.jpg

 

It looks 'organic' and it is challenging.

 

8)

Edited by Rom Hunter
Link to comment
Share on other sites

I think gradually getting darker (or lighter) would help the monotony of the coral (walls) being one color. Here's my first attempt at a "holding" octopus. If you touch him, you speed down significantly and the octopus stops. If you take too long (in this case, 53 ticks of the timer, close to one second), he crushes your sub and you lose a life.) Tell me what you think of it.

gosub010207b.bas.bin

gosub010207b.bas

Link to comment
Share on other sites

Not bad, Chris.

 

But I also think it isn't threatening enough now.

 

Somehow I was thinking about the classic piranha scene in Aztec Challenge:

post-6203-1167778025_thumb.jpg

 

The piranha's were barely visible and when you touched one, they all came speeding towards you to eat you up in a split second.

 

Very scary indeed.

 

What I mean is: perhaps you can make the octopus more threatening by giving it a more 'camouflaged' colour (or by hiding it somewhere behind the corals)?

 

BTW: an enemy that is able to slowly follow you through all the walls (like Evil Otto) is also an idea.

 

8)

Edited by Rom Hunter
Link to comment
Share on other sites

I think gradually getting darker (or lighter) would help the monotony of the coral (walls) being one color. Here's my first attempt at a "holding" octopus. If you touch him, you speed down significantly and the octopus stops. If you take too long (in this case, 53 ticks of the timer, close to one second), he crushes your sub and you lose a life.) Tell me what you think of it.

 

Nice! This is getting pretty close to AA material. One more suggestion I forgot to mention. How about different views of the sub for different directions you are moving? This could allow some of the "impossible" mazes to be possible and would add a bit more "life" into the game.

 

:)

Link to comment
Share on other sites

Warning: I'm about to post some long-winded rambles where I explain ideas I came up with while daydreaming on a defensive possession in basketball. Then I'm going to suggest that (other) people do significant amounts of work based on these 24 second thoughts. Read at your own risk.

 

 

Bouncing objects demo:

demoforsubexper.bin

 

I made this demo of how to bounce a prize around the screen using hardware collision detection (it bounces off the actual graphics the atari is displaying, not some preprogrammed invisible maze coordinates.) It was mainly to see how feasible a suggestion I made for this game was.

 

The idea is some prize determined by using bB's built in random number generator and the current level would pop out of the treasure chest and float around the maze. Higher the level: more likely to get a good prize. Getting the prize in timed mode, would add seconds to your score. (small prizes=a few seconds, big prizes=like ten seconds) At the end of the game, all of your left over seconds would be added up, and your deaths subtracted to get your final score.

 

The demo uses a cherry graphic, from something else. The treasure could be stuff like:

post-9522-1167795957_thumb.png

 

Evil sub:

I made half of a demo to prove (to myself) that this idea worked. But I got halfway through and was satisified (I didn't set out to make half of a demo.) The idea is that on the untimed mode, horrible things would happen (no prizes) such as current, sea snakes, and most importantly an evil sub. The doppleganger sub would pop out of the treasure chest (I know. That doesn't make sense. I thought it would be more fun like that, though. Because you'd be forced to deal with the sub. He's like the minotaur.)

 

He shoots a harmless sonar ping in whatever direction he's traveling:

post-9522-1167797790_thumb.png

 

The ping travels twice as fast as the sub. Whenever it hits something (your sub or a wall) it bounces back to the evil sub. All the while a timer runs in the background. The game will check the timer to see if whatever it hit was close or far away. It will then put the info in the sub's memory.

 

The sub's memory looks something like this:
Wall | Subs
0000 | 0000		these will be one if the sub found a player
^>v< | ^>v<		or wall in that direction, and zero if it's open

Up:	  00000000  these are the x and y coordinates
Down:	00000000  where the subs sonar was used.
Left:	00000000  the game will compare them to the sub's
Right:   00000000  current x and y values to see if there 

X Value: 00000000  is still a wall in that direction.  if
Y Value: 00000000  it turns out that the sub has moved
			   the game will change the direction to zero

The evil sub randomly choose an open lane until his ping reveals the player sub. (also, he should probably go about half as fast the player's sub.) When the evil sub finds the protagonist, he will go in whatever direction the protagonist is, and his speed will quadruple for a short period of time.

 

Current:

current.bas.bin

This is totally not my original thought. (I'm ripping other people off.) But among the horrible things that happen to players for refusing to play timed mode is current. One is added to x or y every other (or if that's too hard, [which it probably is] every three frames, every four frames, etc.) frame. So hypothetically if the current runs left then:

> go right slowly

< go left fast

v go down slowly drifting left

^ go up slowly drifting left

 

Mike Rideout Octupus:

I really like the idea of an octupus that blanks the screen out. Maybe instead of killing you the octupus just slows you down, but as long as the sub is in contact with the octofoe then the screen will be blank. Killing your sub for hitting the octupus seems sort of weird and artificial.

 

It should be pretty easy to code too.

if collision(submarine,octopus) then COLUBK=0 : COLUETC=0

 

Also, the octupus could be less random. Right now he feels completely random. Maybe something like whenever he changes directions, half of his changes will be one hundred percent random, and half will go straight at the sub.

 

Darker colors:

This is another idea i really like. At the start of the game, the walls/coral can be light green, yellow, orange. And progressively work their way to dark green and brown walls. The background could start out lighter too. As the game goes on, getting a deeper and deeper blue.

 

Selling it in AA's store:

Premature, I know, but it would be a shame to not have a blue cart version of this available. If AA doesn't have any blue carts when this is released, I'd be willing to front the money for like 50 cart shells for first fifty copies of the game. (If vgwiz is still making them. Their storefront is down right now. ??:(??) (And if that doesn't make it prohibitively expensive. Forgot it was 8K. Nice Label, Manual, 8K, Blue Case, = $15, $18, $25, $28)

 

EDIT: just saw the build where the octupus can go through walls. Nice. It still feels a little random, but he (the octupus) seems a lot more fierce and threatening (I had to use the pronoun he, because he's so fierce there was no doubt in my mind, that this octupus is anything other than manly man-octupus.)

post-9522-1167797744_thumb.png

Edited by R. Jones
Link to comment
Share on other sites

And here it is, the octopus can go through the walls. I've also slowed him down a little bit. What do you think?
Excellent!

 

What about giving the octopus the same color as the water?

 

This way you can only see it when it's going through the coral.

 

And instead of letting it roam around randomly, you can let it slowly home in to you.

 

This really adds an element of tactic to the game, because you have to lure it away from the exit now and it's much more creative than an ordinary time-clock.

 

The octopus can start from the centre or bottom of the screen and only when it touches you, it changes its colour, slows you down and you have a split second to escape (like in your latest versions).

 

Now you have an almost invisible enemy that constantly follows you.

 

Very creepy.

 

Also, on the higher levels, let the exit be the same colour as the water.

 

This way you have to search for the exit.

 

 

And here's an idea for the last level:

 

Dark water, invisible walls, a very slowly moving sub, and its sonar sound will become faster and louder when you're nearing a wall.

 

You'll have to find your way to the exit by listening!

 

Think about it.

 

8)

Edited by Rom Hunter
Link to comment
Share on other sites

And here it is, the octopus can go through the walls. I've also slowed him down a little bit. What do you think?
Excellent!

 

What about giving the octopus the same color as the water?

 

This way you can only see it when it's going through the coral.

 

And instead of letting it roam around randomly, you can let it slowly home in to you.

 

This really adds an element of tactic to the game, because you have to lure it away from the exit now and it's much more creative than an ordinary time-clock.

 

The octopus can start from the centre or bottom of the screen and only when it touches you, it changes its colour, slows you down and you have a split second to escape (like in your latest versions).

 

Now you have an almost invisible enemy that constantly follows you.

 

Very creepy.

 

Also, on the higher levels, let the exit be the same colour as the water.

 

This way you have to search for the exit.

 

 

And here's an idea for the last level:

 

Dark water, invisible walls, a very slowly moving sub, and its sonar sound will become faster and louder when you're nearing a wall.

 

You'll have to find your way to the exit by listening!

 

Think about it.

 

8)

I modified the last version of the source so the octopus would home in on the sub if it got close enough to detect the sub (as determined by the differences in their x and y coordinates), but right now the octopus is moving too fast and too frequently for that to work well, because the octopus invariably homes in on the sub and crushes it before the sub can get to the treasure/exit, so it needs some more tweaking. I PM'd my changes to Chris so he could see what I did.

 

If the octopus is invisible (water-colored), then I think it should probably become visible when it's close enough to the sub and the sub has a line of sight with it (or line of sonar :)). Also, I think it would be helpful if the sub had some way of repelling the octopus, like an electrical discharge-- which would need to rebuild its charge for at least a few seconds before the player could use it again, otherwise the player could just keep zapping the octopus to keep it at bay. And if you zap the octopus, it gets startled and squirts ink while it escapes (the player1 sprite temporarily turns into a black cloud around the sub) and the sub can't see (the background, playfield, and player colors all go black) until the sub gets out of the ink cloud-- and as it's leaving the ink cloud, the colors transition from black to normal, instead of just changing instantly. :)

 

As far as the invisible maze idea, I think the idea of having to use the sonar to "feel" your way through the maze is great, but I think the sonar should actually reveal the maze walls and keep them revealed, the way you automatically map a dark dungeon as you move through it in a dungeon crawler, with the exception that the playfield is revealed only in the general direction that the sub is pointing in-- or should it be in all directions, since sonar goes outward in all directions? :?

 

Michael

Link to comment
Share on other sites

With all these changes people are suggesting, we're gonna have to change the size to 16K. Also, I'm not too keen on disciplining players for not using the timed mode. Changing the color of the octopus is kinda cool, but you should be able to see it when it comes to a certain distance. Here's the build (with a few very minor changes) that Michael was talking about, but to me, it still feels to me like it's impossible to get out of the octopus's clutch. So for right now, here's the current to-do list:

 

-change wall colors (coral?)/water colors

-make octopus less agressive (maybe)

-change octopus color to water, brown when it comes close.

 

I'm kinda taking little steps at this point, hopefully the big picture will come into view soon. And, of course, if anyone wants to add on to the current build, you are welcome to do so.

gosub010207f.bas.bin

gosub010207f.bas

Link to comment
Share on other sites

I just thought of something: In order to have the octopus change color, I'd have to move the missile1 to ball or else the missile will change color with the octopus. So that's what I've done in this build. Also, I've done the color changing of the octopus. And remember, I'd really like a B&W version done also (just for fun), and that's why COLUP1, COLUBK and COLUPF all have variables as colors, so they can change with the flip of the b&w switch at the title screen. In this build, the octopus also changes color in the B&W mode, too.

gosub010307.bas.bin

gosub010307.bas

Link to comment
Share on other sites

If you want, you can move the octopus with a routine I wrote for another game (yet to be announced.) This scheme uses subpixel movement and varying velocity to give a more natural feel. Try moving the sub to various parts of the screen and watch how the octopus hangs out near the sub.

 

The scheme isn't particularly simple and uses (IIRC) 6 variables, but if you like it and can find the space, it should be fairly simple to add.

octopus.bas

octopus.bas.bin

Link to comment
Share on other sites

I just thought of something: In order to have the octopus change color, I'd have to move the missile1 to ball or else the missile will change color with the octopus. So that's what I've done in this build. Also, I've done the color changing of the octopus. And remember, I'd really like a B&W version done also (just for fun), and that's why COLUP1, COLUBK and COLUPF all have variables as colors, so they can change with the flip of the b&w switch at the title screen. In this build, the octopus also changes color in the B&W mode, too.

I had thought about the color change and the treasure, as well. But there are at least three different ways you could handle it. (My boss always says that you haven't really understood a problem until you can think of at least three different possible solutions to it, so I guess I understand?)

 

(1) Let the treasure be invisible, too, until you get to within a certain distance of it and your line of sight isn't cut off by a playfield pixel. That apparently still leaves the question of the treasure and the octopus having to be visible or invisible at the same time, but that's not actually true if we solve that problem in a different way (see number 3).

 

(2) Draw the treasure with the ball instead of missile1, so the treasure and the octopus can be visible at the same time yet be different colors. However, that means the treasure has to be the same color as the maze, which I don't particularly like-- although, on the other hand, items left sitting on the sea floor for any appreciable length of time *do* start to look like part of the ocean environment! :)

 

(3) Another way to let the octopus and treasure be visible or invisible independently of each other is to change their pixel shapes. You can have an 8x8 octopus with all of its pixels turned off, and let it swim around (i.e., change its x and y coordinates) just as if it were visible. You're letting the octopus swim through the walls, anyway, so it isn't like you need to be able to monitor collisions between the octopus and playfield while the octopus is invisible. Then, when the octopus is within sighting distance of the sub, you can turn its pixels back on, which of course also lets you detect collisions between the octopus and the sub. The same approach can be used with the treasure, regardless of whether it's drawn with missile1 or the ball. (Note to everyone who doesn't already know this: "Gosub" uses bB's "no_blank_lines" option, which means that missile0 isn't available.)

 

So guess which approach I like the best? ;) *All* of the above! :P As I was telling Chris last night in a PM, I think he ought to consider having different challenges that get added to the levels following some kind of logical progression, so the levels keep getting tougher, because that's the way most video games operate. So the octopus doesn't have to be (and probably shouldn't be) present in all levels, and in the levels where it (and presumably any other enemy) isn't present, the treasure can be drawn with missile1 without having to worry about color-changing issues; but in levels that have an enemy, the treasure could be drawn with either missile1 or the ball depending on how you wanted it to work. And you could have invisible treasures and invisible enemies (i.e., "drawn" with all pixels turned off, but still setting their x and y positions), and even let that be one of the things that change with the level increases-- easier levels have always-visible enemies and treasures, but harder levels have enemies and/or treasures which are invisible until you can spot them.

 

Michael

Link to comment
Share on other sites

I just thought of something: In order to have the octopus change color, I'd have to move the missile1 to ball or else the missile will change color with the octopus. So that's what I've done in this build. Also, I've done the color changing of the octopus.

Nice. :cool:
And remember, I'd really like a B&W version done also (just for fun), and that's why COLUP1, COLUBK and COLUPF all have variables as colors, so they can change with the flip of the b&w switch at the title screen. In this build, the octopus also changes color in the B&W mode, too.

Yar. I took a look at your source. Your comments at the beginning say you only have one variable left right now. You'll probably have to optimize a lot to fit anything in after this octopus.

 

One thing I noticed is you don't seem to be using the row 11 flags. Since your not scrolling, anything that could be done with flags (b&w switch, sub direction, etc.) could be done with single bit flags rather than whole variables and handled with the hidden row of pf pixels.

Link to comment
Share on other sites

One thing I noticed is you don't seem to be using the row 11 flags. Since your not scrolling, anything that could be done with flags (b&w switch, sub direction, etc.) could be done with single bit flags rather than whole variables and handled with the hidden row of pf pixels.

No, the very top of the "hidden" row of playfield pixels is visible just above the score, and Chris is counting on it being there to make some of the mazes work. This is a result of the "no_blank_lines" kernel option. But I suspect there are other places where he can optimize his use of variables. I'll take a look at the code tonight after work and see what can be optimized.

 

Michael

Link to comment
Share on other sites

One thing I noticed is you don't seem to be using the row 11 flags. Since your not scrolling, anything that could be done with flags (b&w switch, sub direction, etc.) could be done with single bit flags rather than whole variables and handled with the hidden row of pf pixels.

No, the very top of the "hidden" row of playfield pixels is visible just above the score, and Chris is counting on it being there to make some of the mazes work. This is a result of the "no_blank_lines" kernel option. But I suspect there are other places where he can optimize his use of variables. I'll take a look at the code tonight after work and see what can be optimized.

 

Michael

Shoot, you're right.

 

If you are going to fix the ram, you should check and see if Chris has a commented source or a planning file or something. From the source file I looked at, it wasn't really clear what some of the RAM was being used for.

 

The two obvious things when I looked at the code, though were the color variables and the movement byte.

 

The sub control is currently handled with:
810 if joy0left then d=1
811 if joy0right then d=2
812 if joy0up then d=3
813 if joy0down then d=4
818 if joy0up && joy0right then d=9
819 if joy0down && joy0right then d=10
820 if joy0up && joy0left then d=11
821 if joy0down && joy0left then d=12

You could save half the "d" byte with something like
if joy0left then d{0}=1 : d{1} = 0
if joy0right then d{1}=1 : d{0} = 0
if joy0up then d{2}=1 : d{3} = 0
if joy0down then d{3}=1 : d{2} = 0

The other thing I noticed was the b/w switch.

Currently it's being handled like this:
44 if switchbw then c{0}=0
if !switchbw then c{0}=1
[ . . . ]
48 if c{0} then COLUP0=0 : e=128 : scorecolor=30
timer=timer+1
if timer=3 then timer=0 : g=g+2
if g=254 then g=2
49 if !c{0} then u=4 : e=8 : g=14 : scorecolor=0

 

It doesn't make sense to use variables for the colours here. The only color that really needs a variable is the title screen. Since that graphic isn't used in the rest of the game, the variable could be used for the title screen graphics and something else in game. Those two changes alone would free up four bytes. S is already open, so that's five completely open bytes of RAM for the main game.

 

I'm sure there's more. You'll probably be able to come with better solutions than me. You seem to have a really good handle on bB and atari programming in general.

Link to comment
Share on other sites

If you are going to fix the ram, you should check and see if Chris has a commented source or a planning file or something. From the source file I looked at, it wasn't really clear what some of the RAM was being used for.

 

The two obvious things when I looked at the code, though were the color variables and the movement byte.

 

The sub control is currently handled with:
810 if joy0left then d=1
811 if joy0right then d=2
812 if joy0up then d=3
813 if joy0down then d=4
818 if joy0up && joy0right then d=9
819 if joy0down && joy0right then d=10
820 if joy0up && joy0left then d=11
821 if joy0down && joy0left then d=12

You could save half the "d" byte with something like
if joy0left then d{0}=1 : d{1} = 0
if joy0right then d{1}=1 : d{0} = 0
if joy0up then d{2}=1 : d{3} = 0
if joy0down then d{3}=1 : d{2} = 0

The other thing I noticed was the b/w switch.

Currently it's being handled like this:
44 if switchbw then c{0}=0
if !switchbw then c{0}=1
[ . . . ]
48 if c{0} then COLUP0=0 : e=128 : scorecolor=30
timer=timer+1
if timer=3 then timer=0 : g=g+2
if g=254 then g=2
49 if !c{0} then u=4 : e=8 : g=14 : scorecolor=0

 

It doesn't make sense to use variables for the colours here. The only color that really needs a variable is the title screen. Since that graphic isn't used in the rest of the game, the variable could be used for the title screen graphics and something else in game. Those two changes alone would free up four bytes. S is already open, so that's five completely open bytes of RAM for the main game.

 

I'm sure there's more. You'll probably be able to come with better solutions than me. You seem to have a really good handle on bB and atari programming in general.

When modifying the octopus's movement the other night so that he homes in on the sub, I changed several lines to update player1x and player1y directly, instead of putting the new values into i and j and then moving i and j into player1x and player1y. But it looked like i and/or j were being used for some other things, too, so I'm not sure if that freed up i and j yet. I didn't check on doing the same thing for player0x and player0y, but I'm planning to. I think the color variables are so the color/b&w version can be selected dynamically, but that could probably be handled with a subroutine that sets them to the desired color values using immediate values, or even using some named constants that are defined at the beginning of the program. I'll help Chris optimize the code and the RAM usage as much as I can. And thank you very much for the nice compliment! :)

 

Michael

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