[Done] Astronomer development thread

[+Random Terrain]

In case you were wondering, I'm still working on this. I'm adding some extra comments as I go along to help me remember/keep track.

[Coolcrab]

Cool that you are still looking. It does get a bit messy at the bottom, sorry about that. I didn't have time to look myself the last two days so also no progress from my side.

[+Random Terrain]

Cool that you are still looking. It does get a bit messy at the bottom, sorry about that. I didn't have time to look myself the last two days so also no progress from my side.

 

That's good for me because it's hard to make changes to a new version while I'm working on the previous version. While we're on the subject, what does the "int" part of "_star_int" and "_cloud_int" stand for?

[+Random Terrain]

Before I can finish my first attempt, I need to know a few things:

1.

What does the "int" part of "_star_int" and "_cloud_int" stand for?

 

 

2.

The pause feature you're using will only work correctly when using an emulator that always starts out with the COLOR/BW switch in the same position. You never know where the COLOR/BW switch will be set to on a real Atari, so the game could start out paused and the player would have to flip the COLOR/BW switch to start the game. The bB page has a pause example that works on the Atari 2600 and Atari 7800:

 

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

 

If you don't think you have enough variables and ROM space for a properly working pause feature, it might be best to remove it.

 

 

3.

Is the program supposed to remember the high score from game to game? If so, the code you're using doesn't seem to be what you need. The bB page has example programs that show what it takes to remember a high score:

 

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

 

If you don't have three spare variables to waste on it, you might want to simply display the latest score like many classic games did.

 

 

Let me know what you want and I'll rip out what you don't want or try to add or fix what you do want.

[Coolcrab]

Let me know what you want and I'll rip out what you don't want or try to add or fix what you do want.

1) int stands for integrate. So how long the telescope has to look at it to go up or down one block on the healthbar/observation bar. The star_int might have to become longer at higher levels. But then there's another thing to balance

 

2) this does seem like a good solution and if it fits it might be nice to have. But requiring the switch to be in a certain position is not to strange is it? You have to also make sure the left and right switch is set properly.

 

3) the idea was to save the high score. But if wouldn't give it the highest priority. My method should work though right? Because I compare the value that I put into the score with a different variable. And not the score itself. (That gets redrawn each time with bogaxes secipt) since I use the score for a countdown anyway and don't display the level until after the player dies. (Although it would be nice to show that somehow. But it seemed confusing to show the level in score and add a second Life bar that counts down as the timer. Input on that is welcome.)

 

Thanks again for looking into this. And I really have to read your site more, as it keeps surprising me how everything is there.

[+Random Terrain]

1) int stands for integrate. So how long the telescope has to look at it to go up or down one block on the healthbar/observation bar. The star_int might have to become longer at higher levels. But then there's another thing to balance

Thanks.

 

 

 

2) this does seem like a good solution and if it fits it might be nice to have. But requiring the switch to be in a certain position is not to strange is it? You have to also make sure the left and right switch is set properly.

Some people might want to play it on an Atari 7800 that has a button instead of a switch, so the game wouldn't work properly on that console the way the program is right now. The example on the bB page works on the Atari 2600 and the Atari 7800.

 

 

 

3) the idea was to save the high score. But if wouldn't give it the highest priority. My method should work though right? Because I compare the value that I put into the score with a different variable. And not the score itself. (That gets redrawn each time with bogaxes secipt) since I use the score for a countdown anyway and don't display the level until after the player dies. (Although it would be nice to show that somehow. But it seemed confusing to show the level in score and add a second Life bar that counts down as the timer. Input on that is welcome.)

I wasn't exactly sure what you were doing with the score. Now that I look back at it, you show the level in the score at the end of the game, then display the contents of a score variable and flip between that and the high score variable. That means only one variable will have to be used to remember, not three like the usual high score code on the bB page.

 

The thing I don't get is that your score variable doesn't seem to get used in the game. I've done a search and I don't see where anything is added to that variable.

 

 

 

Thanks again for looking into this. And I really have to read your site more, as it keeps surprising me how everything is there.

batari had a lot of things on the page already, but more was added over the years. I asked a bunch of questions when working on Seaweed Assault and some assembly language programmers got together and came up with solutions for various things I needed in the program. I put their useful code on the bB page in the hopes that it would help other bB users who have the same questions.

[Coolcrab]

 

 

 

Some people might want to play it on an Atari 7800 that has a button instead of a switch, so the game wouldn't work properly on that console the way the program is right now. The example on the bB page works on the Atari 2600 and the Atari 7800.

 

Aha I didn't know! I don't have a 7800 unfortunately. But in that case it is a good point indeed.

 

 

 

I wasn't exactly sure what you were doing with the score. Now that I look back at it, it's just showing the level that the player reached, right? If so, that means only one variable will have to be used to remember, not three like the usual high score code on the bB page.

 

 

 

Yes, ok then that won't be too heavy to implement variable wise. Did you manage to free any variables up by the way?

 

 

batari had a lot of things on the page already, but more was added over the years. I asked a bunch of questions when working on Seaweed Assault and some assembly language programmers got together and came up with solutions for various things I needed in the program. I put their useful code on the bB page in the hopes that it would help other bB users who have the same questions.

 

That is nice indeed. I love how nice and helpful this community is.

[+Random Terrain]

Oops, I updated my post above. It was the part about the score.

 

Your score variable doesn't seem to get anything added to it in the game.

[Coolcrab]

In the main loop score is used as a countdown. So at line 320 it ticks down and at line 414 it can go up. (when a star is observed)

At 294 I say _level = _level +1 and count it that way and at 349 I replace score by _level and go back to the menu. (all in the 0.8 version that I uploaded last time.)

 

Is that what you meant?

[+Random Terrain]

No, you also have a score variable. Example:

---

   if _Score > _High_Score then _High_Score = _Score

---

_Score always seems to be empty, so it will never be greater than _High_Score.

[Coolcrab]

Oh that is strange indeed. That has to be _level I think.

[+Random Terrain]

Oh that is strange indeed. That has to be _level I think.

 

OK, so for sure, you want to show the current level and the highest level in the actual score at the bottom of the title screen, right? If so, we can get rid of that _Score variable.

[Coolcrab]

Yes, this was what I meant to do. I think that I meant to put _level into _score. But its a bit double as _level doesn't get killed until you restart the game anyway.

[+Random Terrain]

I have another question. It's about the number one and number two displayed on the title screen. What exactly are they for?

[Coolcrab]

The game modes. In the old version I had this on the right A/B switch.

Gamemode 1 is a progressive game where the clouds change by adding +1 to NUSIZ1 and every 7th level the clouds become faster. (this should probably happen quicker). But its predictable in the way of what the next level will be.

 

Gamemode 2 is more random. Each new level will have a random NUSIZ1 and place the cloud at a random speed and location. The star is also in a random location. So its a bit harder and less repetitive for people who don't wat the same level over and over again.

 

​I also wanted to add a difficulty setting on the AB switch that I freed up to make the star_int a bit lower and maybe give more points per star. So that it is more forgiving.

[+Random Terrain]

Will there always only be two game modes? If so, I can use a bit instead of wasting a whole variable for the setting.

[Coolcrab]

I think so, can't really think of much more things to add. Especially because the space is almost gone. ~250k left I think.

[+Random Terrain]

Speaking of the setting variable that I'm going to change to a bit, you have this in your main loop:

---

   if _setting && switchselect then _cloud_rot =  (rand&7) : _cloud_v =  (rand&3) : player1x = (rand&127) : player1y = (rand&31) + 25  : score = 150 : _Level = 0 : gosub _reset_star

---

Seems like switchselect needs to be removed from the if-then and the whole line needs to be moved to where your new level section is. Where is the section that is responsible for creating a new level (so I don't have to hunt it down)?

 

I'll also need to make sure that randomness happens at the beginning of a mode 2 game. Right now, the cloud is in the same spot when the game starts no matter which mode is selected.

[Coolcrab]

In the _score label (which is sloppy of me, should be __score), on line 415.

There I say the same thing. So the randomness in level 2, if game mode 2. But good point to have it start on level 1

[+Random Terrain]

In the paddle simulation section, you use the variable q. Do you know what that variable does/stands for so I can give it a meaningful alias?

 

You have a variable called _blink, but it doesn't seem to be used in the program. Can I get rid of it?

[Coolcrab]

The paddle part was by bogax. It basically is a script that allows the telescope to point anywhere, with p the 'x' position and q the 'y' position of the end point of the beam. In his original script you could move the line anywhere and let it terminate mid air if you moved the pad0down. I changed it to move along the edge of the map. So it starts in the low right corner, moves up (in q) then reaches the upper left corner and moves right (in p) until it reaches the upper right corner and then moves down (in q)

 

I didn't rename them because I didn't want to touch that script too much. But you could call p _telelescope_point_horz and q _telescope_point_vert. (Or something similar) [small side note, the edge of the field is not the same as the edge of the screen, there is about 1 block missing on both sides, can that be drawn in somehow to make the telescope beam touch the window edge?]

 

And I have no idea what _blink is for. Probably something to do with the menu but it got replaced by something else. so yes that can go.

Edited December 22, 2017 by Coolcrab

[+Random Terrain]

What does rot in "_cloud_rot" stand for? And what does the v in "_cloud_v" stand for?

 

Also, how would you describe what "_State" is or does in a REM?

[Coolcrab]

Cloud_rot decides the nuz1 (so the shape and multiplier of the cloud) i think. And cloud_v is the cloud velocity. _state is the menu blinker I think? (Don't have the code infront of me, where is it used?)

[+Random Terrain]

Cloud_rot decides the nuz1 (so the shape and multiplier of the cloud) i think. And cloud_v is the cloud velocity. _state is the menu blinker I think? (Don't have the code infront of me, where is it used?)

 

It seems to tell the program where to jump:

---

   on _State goto __Read_Joy_Paddles __Drawline __Do_Score

---

So do you think "_Cloud_rot" could be called "_Cloud_Type"?

[Coolcrab]

Ah state is from bogax's code. I'm not sure what it does but it has to do with the paddle simulation or the drawing of the telescope line.

 

Cloud_rot stood for rotation. But type is also fine