Two low-importance ones now:
- - -
It seems to me that the message "Ship off scope" should have a precedence before "Pilot too far". Because if I am very near a crashed ship (for example so near that it takes some attention to determinate the direction from the radar), then the message "Pilot too far" is funny because I am obviously after a different pilot for which this message is completely false. I maneuvered to land very close to this pilot and if the final maneuver brought another pilot into the sight of my radar, then I probably haven't even noticed it. So the message can be really confusing for a few seconds (and probably more for a beginner).
But I can live it with, it actually makes the game more interesting (less tediously monotonous). And I can also imagine an objection, that if I land and a pilot is 3.00 miles before me, then it might be strange to display "pilot off scope" for a pilot which is 2.99 miles behind me. So maybe the closer pilot should take precedence only if he is in the running (rescue) range.
- - -
And a funny thing happened to me: I believe that the crashed ship is represented by a point (with zero size) for the sake of determining the correct direction which is not "off scope". Because a while ago I landed very close and I turned the ship until I saw a part of the crashed ship. Then I turned off my systems and it said "Ship off scope" (or actually "Pilot too far" for the reason above, but that is not important). So I thought: "What??!! What the h** does this mean?" And then I guessed the reason and I rotated my ship and then I saw a larger part of the crashed ship and everything was OK.
So I suggest that the "ship off scope" message should be tolerantly omitted if the distance from the crashed shuttle is not clearly bigger than the shuttle size.
Fractalus 1.x: ideas for future updates
Re: Fractalus 1.x: ideas for future updates
I would like to propose an animation between alien's decisive hit and the "game over" screen. Even a very simple one would do. As it is now, I (almost) don't know whether I was too slow to kill the alien or something killed me at the same time. For example a saucer. Or energy consumption which depletes energy slowly no matter what is happening. Sometimes these thing do happen by chance near the moment when an alien jumps at me. At least once I was really, genuinly puzzled about what happened.
Re: Fractalus 1.x: ideas for future updates
Right now I played level ca. 24 and I think I reacted to the alien in less than ca. half a second. I think it was his first blow - and game over.
Well, I don't question that it is faithful to the original. And I don't question that this kind of difficulty contributes to player's thrill and challenge and therefore enjoyment. But now it seems to me that I can handle level 24 easily (I mean combat and related things - using this tactics), but a split second difference between my and alien's reflexes can ruin the entire progress I made to get to this level.
Allow me to say that I don't like that at all - and so I look forward for alien difficulty adjustable independently on combat difficulty.
What can I do now? Shoot out all turrets and then say "I would rescue the pilots if I had faster 'fry the alien' reactions."? This would be acceptable, but I could not try my luck against high levels. I hope I will think up something how to enjoy the game. Or perhaps... I will practice to build better reflexes Yes, maybe I wrote it because I am spoiled by the fact that until level ca. 20, it is very easy to kill the alien in time.
Fortunately, in an email Luke wrote that it is his intention to customize various aspects of gameplay and difficulty independently on one another.
Pavel
Well, I don't question that it is faithful to the original. And I don't question that this kind of difficulty contributes to player's thrill and challenge and therefore enjoyment. But now it seems to me that I can handle level 24 easily (I mean combat and related things - using this tactics), but a split second difference between my and alien's reflexes can ruin the entire progress I made to get to this level.
Allow me to say that I don't like that at all - and so I look forward for alien difficulty adjustable independently on combat difficulty.
What can I do now? Shoot out all turrets and then say "I would rescue the pilots if I had faster 'fry the alien' reactions."? This would be acceptable, but I could not try my luck against high levels. I hope I will think up something how to enjoy the game. Or perhaps... I will practice to build better reflexes Yes, maybe I wrote it because I am spoiled by the fact that until level ca. 20, it is very easy to kill the alien in time.
Fortunately, in an email Luke wrote that it is his intention to customize various aspects of gameplay and difficulty independently on one another.
Pavel
A small comment on alien scare
Just a short personal observation about the alien scare:
When I proposed that alien damage should be cumulative, I wrote (as a reason) that now the tension from a scaring alien jump is very little (almost none) because the alien looks the same each time and because it is too easy to kill him in time.
Then I realized that the scare from alien jump is (in my case when playing Remake 1.0.0 now) not so little, if it is a dark night (I mean in-game) or if it leaps unexpectedly (if I forget to "brace" against the fear).
But as I wrote here a few days ago, I discovered that on level 24 the alien (either always or sometimes) destroys my ship with the (almost?) first blow. So now I must admit that the tension from the Alien increased a lot. Even on level 16 when the alien is conveniently slow, I feel "I must kill the beast before it delivers the first blow, because if I don't learn it, then on level 24 I will be..." And my reflexes are too slow, I have never killed the alien before its first blow, not even when I expect it because of the green helmet.
So this is just a feedback about how the opinion on the alien scare evolves in me.
Btw. I will have to verify my hypothesis that the increase in alien difficulty from level 20 (maybe even 22) to 24 is very steep. I have seen it far too few times to consider this hypothesis confirmed.
When I proposed that alien damage should be cumulative, I wrote (as a reason) that now the tension from a scaring alien jump is very little (almost none) because the alien looks the same each time and because it is too easy to kill him in time.
Then I realized that the scare from alien jump is (in my case when playing Remake 1.0.0 now) not so little, if it is a dark night (I mean in-game) or if it leaps unexpectedly (if I forget to "brace" against the fear).
But as I wrote here a few days ago, I discovered that on level 24 the alien (either always or sometimes) destroys my ship with the (almost?) first blow. So now I must admit that the tension from the Alien increased a lot. Even on level 16 when the alien is conveniently slow, I feel "I must kill the beast before it delivers the first blow, because if I don't learn it, then on level 24 I will be..." And my reflexes are too slow, I have never killed the alien before its first blow, not even when I expect it because of the green helmet.
So this is just a feedback about how the opinion on the alien scare evolves in me.
Btw. I will have to verify my hypothesis that the increase in alien difficulty from level 20 (maybe even 22) to 24 is very steep. I have seen it far too few times to consider this hypothesis confirmed.
Last edited by reflame on 2022-Jun-29 19:12, edited 1 time in total.
Random shade of color of alien's helmet
How about making the helmet color of some aliens a random color exactly between the darkgreen and white used in Remake. When I say "exactly", I mean that it will be exactly on the "line segment" connecting these two points in the "color space", but it can be anywhere on that line.
I propose this because I have already enough experience to say "at this distance, it means nothing that the helmet does not seem green, but (...) now he is close enough that I would recognize the green color, so I know he has a white color".
If this was implemented, then I exert my eyes (pay intensive attention) the whole time (as the pilot is approaching) in hope to see a proof of his alien identity.
I propose this because I have already enough experience to say "at this distance, it means nothing that the helmet does not seem green, but (...) now he is close enough that I would recognize the green color, so I know he has a white color".
If this was implemented, then I exert my eyes (pay intensive attention) the whole time (as the pilot is approaching) in hope to see a proof of his alien identity.
Terrain features drawing attention
Today I loaded the pilot and looked for the smoke of the crashed ship that I needed to destroy. And I saw something like a smoke, so I immediatelly look there and wanted to turn my ship, but it was something else (maybe a raised dust).
This reminded me that after some experience with the game, one gets used to what things look like and does not need any (exerted, strong) attention to discern it. For example: when I have loaded the pilot, I see nothing but rock, peaks with turrets, sky and a smoking ship. (Maybe I forgot about something, but still:) So my eyes immediatelly identify a thing as a smoking ship if it looks more like a smoking ship than rock, turret or sky.
But if there were terrain elements in the game that look very loosely like turrets, smoke etc. (very loosely: that means which differ less from a smoke, or for example turret, than from rock or sky; I hope you understand me ), then the player would have to pay at least a little attention to discern interesting game objects from innocent meaningless terrain features. I would like that. Little required attention is better than no required attention, in my opinion.
This goes in the same line as some of my former ideas (1, 2).
This reminded me that after some experience with the game, one gets used to what things look like and does not need any (exerted, strong) attention to discern it. For example: when I have loaded the pilot, I see nothing but rock, peaks with turrets, sky and a smoking ship. (Maybe I forgot about something, but still:) So my eyes immediatelly identify a thing as a smoking ship if it looks more like a smoking ship than rock, turret or sky.
But if there were terrain elements in the game that look very loosely like turrets, smoke etc. (very loosely: that means which differ less from a smoke, or for example turret, than from rock or sky; I hope you understand me ), then the player would have to pay at least a little attention to discern interesting game objects from innocent meaningless terrain features. I would like that. Little required attention is better than no required attention, in my opinion.
This goes in the same line as some of my former ideas (1, 2).
Re: Fractalus 1.x: ideas for future updates
Sorry everyone for the long delay in responding to this thread, there was a tremendous amount to go through and it took me a while to read through and parse all of it.
--
@Loafmeister Different game modes is an idea I've also been thinking about, in particular the "zen mode" is one I've found is quite enjoyable, as I frequently experienced something like it while working on the terrain and environment systems where I had no entities in the world so I could focus on just the environment. Artifacts would be an interesting idea, but I would need to consider what they would be and look like to fit in with the lore.
Alternate turret weapons is also a good idea, and in my very early builds of the remake, the turrets fired a moving projectile instead of a beam, so it would be interesting to have that as an option. The aliens repairing the human ships I'm not sure would work lore-wise, as according to the original lore those crashed ships are only suited for space combat, not air combat - that's why they're crashed on Fractalus.
--
@Lighthope One of the ideas I'm considering is the ability to have custom game modes, and part of that would be some options to control the terrain generation, so I expect that being able to control the height and complexity of the terrain would be part of this.
--
@Michael I considered caves during development of the remake, and I'd also like to see them, I think it would be an interesting technical thing to implement as the terrain is a small area that repeats infinitely, but I'm not sure of the best way to do them. Many years ago I made a small test project to render a cave the way Eidolon did it by rendering a terrain twice - once at its normal height but upside down to render the cave ceiling and walls, and again at a very short height but the right way up to render the floor, but if I were to do this it would result in an infinitely repeating cave world, which wouldn't work with the level entry/exit sequences in Fractalus, so I think the most sensible way to implement that would be with holes in the terrain with a cave mesh behind them, which would require significantly more work.
The idea for loading/idle screen animations with info sounds like it would be a neat addition to have. Showing an intro logo in the original style with the same music and blink might run me into some copyright/trademark issues, so I think I'll avoid implementing that one.
--
@Jammer777 Yep, the alien needs a jumpscare sound. This was one of the most common complaints about the 1.0.0 release, so the next build will definitely have some jumpscare sound, which I'm still working on getting right. I can also improve the airlock knocking sound, as it is still a bit hard to discern against the background ambience in some cases.
--
@reflame As noted in my email reply to you, my plan with the Fractalus remake was always to create a 1:1 replica of the original game and to be as faithful to the original gameplay as much as possible. During development I came up with some of my own ideas for ways in which I could expand on the gameplay but I wasn't sure if I wanted to ever implement them as I had only intended to make a replica and was uncertain about whether I would want to continue it beyond that.
Some of your ideas align with some of my own, such as adding new weapon types, ship customisation, and adding some new elements to the game and allowing some customisation of those elements, with some preset configurations of those elements to provide preset game modes that differ from the original game slightly. Additionally adding some sort of mission or objective mode, or some sort of campaign, would be something I'd like to add, but again as mentioned in my email reply to you I'm not sure about defining a storyline myself. My thoughts around this, if I were to implement it, would be something akin to the custom mission editor in the Freespace games, where you could create your own mission sequences and play them through. This would add the ability to have missions in Fractalus without explicitly defining a fixed storyline.
Some of your other ideas would unfortunately require significant changes to the current implementation of my Fractalus remake, and would effectively turn it into a different game. There are fundamental limits on what I can do in the Fractalus remake without significantly rewriting it, and this limits or prevents both the idea of implementing larger scale missions and many of your ideas around larger persistent worlds. As noted earlier in this message, the Fractalus "world" is actually a small play area that repeats infinitely. Technically, the entire play area is 200Wx200Lx30H units in size, and seamlessly loops at the edges. This is also the way that the original game was implemented, so it was also subject to the same limitations. To do anything outside this design would require me to completely rewrite the terrain generation system and the world entity logic, and at that point it would no longer be "Fractalus" and would effectively be a different game, as part of the premise of the remake is that it copies the original game's style and also technical implementation, as that was a key feature of what made it the game it was. My vision for expanding on Rescue on Fractalus, if I am to do so at all, is only to expand on the existing concept, not to turn it into a different game.
On to some of the issues with the current remake you've mentioned. In your more recent posts, you mentioned an issue with "unrealistic aiming" where you noted that your projectile registers a collision with a turret even when it appears quite distant. The way that I implemented the collision detection in the remake is indeed based on the distance between a turret and the projectile and is checked per rendered frame. I noticed while testing this that if the game is running at a sufficiently low frame rate, this can result in the projectile skipping over the collision range in a single frame, which would result in the projectile not registering a hit, so I made the logic for this more forgiving in cases where the frame rate is low by expanding the collision area, however this will mean that a hit can be registered even when the projectile doesn't seem to be anywhere near the turret. I will look into fixing this issue with more sensible collision logic, perhaps by checking each frame if there was a collision between the two points that the projectile was at for each of those frames instead. However it should also be noted that in the original game, the range for detecting a collision was also fairly forgiving due to the low framerate of the original game, and I think this was explained away in the lore by describing the projectile as an "Anti-Matter Bubble", which presumably would have a large sphere of influence that would explain the wide tolerance when considering a collision - which would also be true for the collision range when destroying a crashed ship.
You also mentioned in a later post that your estimate of how quickly the scene was moving was about 10 frames per second, and also that you felt that the player cannot control the ship's heading smoothly, which may indicate that your graphics hardware is struggling to run the game or you may have the graphics quality setting set too high, as you definitely shouldn't be getting that low a frame rate except on low-end hardware, and this would be causing my collision logic to be far more tolerant, to the point of a hit being registered well outside the expected distance. At a better frame rate, the collision range is reasonable and the player ship should be quite smooth to control and be fairly precise.
In the same post you mentioned that you feel that after starting a level the first minutes are very tense while destroying turrets, but then it's just a tedious process of picking up the required number of pilots. This is implemented the same way as it was in the original game - once you had cleared out the turrets on the level, they did not regenerate, so this is intended behaviour. You also mentioned an issue with the messaging about "ship off scope" and "pilot too far" depending on where nearby pilots are when you land. The messaging is based on what the radar can see in a 90 degree range forward of the ship - everything outside that range is ignored, as it was in the original game as well. So if there is a pilot 3 units ahead of you, and a pilot 2 units behind you, only the pilot 3 units ahead of you will be considered for the logic for deciding whether a pilot is in range or off scope. Your observation that the crashed ship's position is represented as a point with zero size is correct - most things in video games are represented this way as it's simpler to compute.
As for the difficulty of the game at level 24 and above, this is the same as it was in the original game. Beyond about level 20, the game starts getting very difficult, and by about level 40 it's nearly impossible. The highest level I have ever seen anyone get to in the original legitimately is around level 44. In my communication with the original game's developers, they told me that they didn't implement an end screen for finishing the game because they didn't think anyone would make it that far - and I ran a modified version of the original game to check this and confirmed that there is no end screen if you complete level 99. Keep in mind that the original game was made in 1984 and it followed some of the design of arcade games of the time, in particular where successive levels get increasingly difficult to the point of being almost impossible to beat, and the point was to see how far you could get and/or how high your score was. If I implement custom game modes, there will be parameters for things like this that could be modified.
--
Thanks everyone for your ideas! I'm still working on getting a new build finished to fix the issues from 1.0.0, so the next build won't have anything that expands on the original game. I'm also not sure at this stage if I will develop further versions of Fractalus to expand on the original game, but if/when I do I will consider the ideas posted here and try to include as much as I can with the time I have available to work on Fractalus.
--
@Loafmeister Different game modes is an idea I've also been thinking about, in particular the "zen mode" is one I've found is quite enjoyable, as I frequently experienced something like it while working on the terrain and environment systems where I had no entities in the world so I could focus on just the environment. Artifacts would be an interesting idea, but I would need to consider what they would be and look like to fit in with the lore.
Alternate turret weapons is also a good idea, and in my very early builds of the remake, the turrets fired a moving projectile instead of a beam, so it would be interesting to have that as an option. The aliens repairing the human ships I'm not sure would work lore-wise, as according to the original lore those crashed ships are only suited for space combat, not air combat - that's why they're crashed on Fractalus.
--
@Lighthope One of the ideas I'm considering is the ability to have custom game modes, and part of that would be some options to control the terrain generation, so I expect that being able to control the height and complexity of the terrain would be part of this.
--
@Michael I considered caves during development of the remake, and I'd also like to see them, I think it would be an interesting technical thing to implement as the terrain is a small area that repeats infinitely, but I'm not sure of the best way to do them. Many years ago I made a small test project to render a cave the way Eidolon did it by rendering a terrain twice - once at its normal height but upside down to render the cave ceiling and walls, and again at a very short height but the right way up to render the floor, but if I were to do this it would result in an infinitely repeating cave world, which wouldn't work with the level entry/exit sequences in Fractalus, so I think the most sensible way to implement that would be with holes in the terrain with a cave mesh behind them, which would require significantly more work.
The idea for loading/idle screen animations with info sounds like it would be a neat addition to have. Showing an intro logo in the original style with the same music and blink might run me into some copyright/trademark issues, so I think I'll avoid implementing that one.
--
@Jammer777 Yep, the alien needs a jumpscare sound. This was one of the most common complaints about the 1.0.0 release, so the next build will definitely have some jumpscare sound, which I'm still working on getting right. I can also improve the airlock knocking sound, as it is still a bit hard to discern against the background ambience in some cases.
--
@reflame As noted in my email reply to you, my plan with the Fractalus remake was always to create a 1:1 replica of the original game and to be as faithful to the original gameplay as much as possible. During development I came up with some of my own ideas for ways in which I could expand on the gameplay but I wasn't sure if I wanted to ever implement them as I had only intended to make a replica and was uncertain about whether I would want to continue it beyond that.
Some of your ideas align with some of my own, such as adding new weapon types, ship customisation, and adding some new elements to the game and allowing some customisation of those elements, with some preset configurations of those elements to provide preset game modes that differ from the original game slightly. Additionally adding some sort of mission or objective mode, or some sort of campaign, would be something I'd like to add, but again as mentioned in my email reply to you I'm not sure about defining a storyline myself. My thoughts around this, if I were to implement it, would be something akin to the custom mission editor in the Freespace games, where you could create your own mission sequences and play them through. This would add the ability to have missions in Fractalus without explicitly defining a fixed storyline.
Some of your other ideas would unfortunately require significant changes to the current implementation of my Fractalus remake, and would effectively turn it into a different game. There are fundamental limits on what I can do in the Fractalus remake without significantly rewriting it, and this limits or prevents both the idea of implementing larger scale missions and many of your ideas around larger persistent worlds. As noted earlier in this message, the Fractalus "world" is actually a small play area that repeats infinitely. Technically, the entire play area is 200Wx200Lx30H units in size, and seamlessly loops at the edges. This is also the way that the original game was implemented, so it was also subject to the same limitations. To do anything outside this design would require me to completely rewrite the terrain generation system and the world entity logic, and at that point it would no longer be "Fractalus" and would effectively be a different game, as part of the premise of the remake is that it copies the original game's style and also technical implementation, as that was a key feature of what made it the game it was. My vision for expanding on Rescue on Fractalus, if I am to do so at all, is only to expand on the existing concept, not to turn it into a different game.
On to some of the issues with the current remake you've mentioned. In your more recent posts, you mentioned an issue with "unrealistic aiming" where you noted that your projectile registers a collision with a turret even when it appears quite distant. The way that I implemented the collision detection in the remake is indeed based on the distance between a turret and the projectile and is checked per rendered frame. I noticed while testing this that if the game is running at a sufficiently low frame rate, this can result in the projectile skipping over the collision range in a single frame, which would result in the projectile not registering a hit, so I made the logic for this more forgiving in cases where the frame rate is low by expanding the collision area, however this will mean that a hit can be registered even when the projectile doesn't seem to be anywhere near the turret. I will look into fixing this issue with more sensible collision logic, perhaps by checking each frame if there was a collision between the two points that the projectile was at for each of those frames instead. However it should also be noted that in the original game, the range for detecting a collision was also fairly forgiving due to the low framerate of the original game, and I think this was explained away in the lore by describing the projectile as an "Anti-Matter Bubble", which presumably would have a large sphere of influence that would explain the wide tolerance when considering a collision - which would also be true for the collision range when destroying a crashed ship.
You also mentioned in a later post that your estimate of how quickly the scene was moving was about 10 frames per second, and also that you felt that the player cannot control the ship's heading smoothly, which may indicate that your graphics hardware is struggling to run the game or you may have the graphics quality setting set too high, as you definitely shouldn't be getting that low a frame rate except on low-end hardware, and this would be causing my collision logic to be far more tolerant, to the point of a hit being registered well outside the expected distance. At a better frame rate, the collision range is reasonable and the player ship should be quite smooth to control and be fairly precise.
In the same post you mentioned that you feel that after starting a level the first minutes are very tense while destroying turrets, but then it's just a tedious process of picking up the required number of pilots. This is implemented the same way as it was in the original game - once you had cleared out the turrets on the level, they did not regenerate, so this is intended behaviour. You also mentioned an issue with the messaging about "ship off scope" and "pilot too far" depending on where nearby pilots are when you land. The messaging is based on what the radar can see in a 90 degree range forward of the ship - everything outside that range is ignored, as it was in the original game as well. So if there is a pilot 3 units ahead of you, and a pilot 2 units behind you, only the pilot 3 units ahead of you will be considered for the logic for deciding whether a pilot is in range or off scope. Your observation that the crashed ship's position is represented as a point with zero size is correct - most things in video games are represented this way as it's simpler to compute.
As for the difficulty of the game at level 24 and above, this is the same as it was in the original game. Beyond about level 20, the game starts getting very difficult, and by about level 40 it's nearly impossible. The highest level I have ever seen anyone get to in the original legitimately is around level 44. In my communication with the original game's developers, they told me that they didn't implement an end screen for finishing the game because they didn't think anyone would make it that far - and I ran a modified version of the original game to check this and confirmed that there is no end screen if you complete level 99. Keep in mind that the original game was made in 1984 and it followed some of the design of arcade games of the time, in particular where successive levels get increasingly difficult to the point of being almost impossible to beat, and the point was to see how far you could get and/or how high your score was. If I implement custom game modes, there will be parameters for things like this that could be modified.
--
Thanks everyone for your ideas! I'm still working on getting a new build finished to fix the issues from 1.0.0, so the next build won't have anything that expands on the original game. I'm also not sure at this stage if I will develop further versions of Fractalus to expand on the original game, but if/when I do I will consider the ideas posted here and try to include as much as I can with the time I have available to work on Fractalus.
Luke's Software and Design
http://www.lsdwa.com
http://www.lsdwa.com
Re: Fractalus 1.x: ideas for future updates
I would like to see a feature to mute or at least lower the volume of the background swooshing sound that persists in the background while on a mission to save pilots.
Sound design is very powerful, not just for game play but movies as well. Having sound respond to user/game interaction can dramatically increase play appeal.
If the now static sound loop were to respond to game play properties/conditions it could evoke a more interesting audible experience that is not prone to monotony.
The swoosh sound could be revisited to make it vary in volume, bass, treble or other frequencies dependent on conditions or environmental values that are under constant flux.
The swoosh sound could vary in the following ways;
Intensity (volume)
pitch
equalization
distortion
adding some noise
adding transients from other sounds
The varying of the sound could be calculated based on;
Ship Altitude
Ship distance from nearby terrain
Ship velocity
Ship pitch
Ship yaw
Environmental conditions such as night/day (sometimes this sounds like wind hence my day/night recommendation)
----
In terms of the current sound loop being reminiscent of wind; adding a somewhat random value unrelated to all of the above to simulate turbulence could make the game a little more challenging as well. Perhaps an algorithmic value could be set to a min or max value based on what level the gamer will be playing.
----
Kind regards and thank you for an exceptionally well designed remake of one of the best games that ever lived inside of 48KB of RAM. Amazing work, I hope you continue to iterate by implementing some further tweaks.
PS: I came back to edit because of a curiosity of mine. I wonder if there are interviews out there with the original game designers where they reveal ideas that never got implemented for one reason or another. I am sure there were some things that were on the list but never made it due to time, costs or just resource constraints the machine's themselves were subject to. I am sure there are some good ideas there to consider. Thanks again!
Sound design is very powerful, not just for game play but movies as well. Having sound respond to user/game interaction can dramatically increase play appeal.
If the now static sound loop were to respond to game play properties/conditions it could evoke a more interesting audible experience that is not prone to monotony.
The swoosh sound could be revisited to make it vary in volume, bass, treble or other frequencies dependent on conditions or environmental values that are under constant flux.
The swoosh sound could vary in the following ways;
Intensity (volume)
pitch
equalization
distortion
adding some noise
adding transients from other sounds
The varying of the sound could be calculated based on;
Ship Altitude
Ship distance from nearby terrain
Ship velocity
Ship pitch
Ship yaw
Environmental conditions such as night/day (sometimes this sounds like wind hence my day/night recommendation)
----
In terms of the current sound loop being reminiscent of wind; adding a somewhat random value unrelated to all of the above to simulate turbulence could make the game a little more challenging as well. Perhaps an algorithmic value could be set to a min or max value based on what level the gamer will be playing.
----
Kind regards and thank you for an exceptionally well designed remake of one of the best games that ever lived inside of 48KB of RAM. Amazing work, I hope you continue to iterate by implementing some further tweaks.
PS: I came back to edit because of a curiosity of mine. I wonder if there are interviews out there with the original game designers where they reveal ideas that never got implemented for one reason or another. I am sure there were some things that were on the list but never made it due to time, costs or just resource constraints the machine's themselves were subject to. I am sure there are some good ideas there to consider. Thanks again!