Now that the GUI's almost done, and it supports being controlled by a mouse, why not add that kind of support to the game itself? In doing this, we need to make sure that the game clamps fast mouse movement while allowing for more precise adjustments and otherwise not negatively impacting the player's experience with the game. A good example of this is in Tyrian (specifically OpenTyrian). You can get the source port, OpenTyrian, off Flathub and I really recommend trying it out because the mouse controls are superb. Anyway, I think that after messing around with the game and with a very basic prototype for InfiniteShooter where I've added these controls, it would be a good feature to polish up for InfiniteShooter 5.0.

Is your feature request related to a problem? Please describe.
I'm a bit concerned with how I'm working with branches in InfiniteShooter. Here's the thing:

• I want to have something for each stable release, like 0.4.x, where bug fixes happen.
• I also want to have a branch for 0.5.0, where I can start adding new features.
  But how do I make sure that bug fixes for the game apply to both 0.5.0 (dev) and 0.4.x (0.4.x)?

Describe the solution you'd like
I... actually have no idea. That's mainly why I'm asking--if I knew how to make something, and have it be sustainable, I would do so in a heartbeat.

Describe alternatives you've considered
Something like what Godot's doing? But unfortunately I didn't really see any solutions to my issue in their repository/docs.

Describe the bug
Limiting physics frames per second visually breaks some elements of the game, such as walls or the red arrow. This is most evident when the limiting is low.

To Reproduce
Steps to reproduce the behavior:

1. Launch the game.
2. Set the physics frame limit to the minimum.
3. Press the start button.
4. Observe unusual behavior of some objects on the screen.

Desktop (please complete the following information):

• OS and OS version: Windows 10 21H2
• InfiniteShooter version: latest commit

What?
Godot 3.5 is now out!

Describe the solution you'd like
Try out some of the cool settings in Godot 3.5 to tweak InfiniteShooter to get better performance! While I'm at it, I'll try to add implement some new features from 3.5 into InfiniteShooter.

Describe alternatives you've considered
THERE ARE NO ALTERNATIVES

So. InfiniteShooter is designed to be a quick game, or at least a game that can last as long as you want it to, while being a rougelike of sorts in the sense that when you die you have to start all over again. The problem with this, however, is that this means each "session" of the game you have ends when you die. What if you only had 10 minutes of spare time, but it's been half an hour now and you still haven't died?
This is why I'm thinking of including saves for InfiniteShooter.
With this, you should be able to save your game after the ten minutes and come back to it another day. However, this can lead to cheating the rouge-like-ness of the game by just reloading your last save when you die. Therefore, I suggest that saves:

• Should respect the rouge-like-ness of InfiniteShooter (sorry, I really don't have a better word). This can mean, for example, deleting saves for a run once you die (and organizing saves by runs).
• Should allow you to pick up where you left off so time for each "session" can be of any amount.
  I'll probably add more points when I come up with them, but I think this would be really beneficial for InfiniteShooter.

Is your feature request related to a problem? Please describe.
I often find that the background moves too fast, which sometimes makes me feel a little dizzy.

Describe the solution you'd like
It would be nice to add an additional option in the settings menu to solve this problem.

Describe alternatives you've considered
If you can't add an extra option, you can hardcode the speed of the background in the code itself.

Beside regular upgrades that deal with how much damage lasers do/how much health your ship has, an idea could be to split the upgrades screen into two tabs: one for regular upgrades and one for laser upgrades. These upgrades would be fixed, so not randomly generated each time the upgrade screen is shown, and you would only be able to equip one upgrade at a time. For example, there could be an upgrade for firing two lasers at once or three lasers in different directions, and you could purchase both, but you could only equip one for the next level. This could also work for the ship too, where for example you could have an upgrade for shields.

EDIT (2023-01-31):
Here's just a quick checklist I'm going to put here so I know how I should tackle this:

• Create a label for each "enhancement" (what I'll call permanent per run upgrades) and integrate it with the Upgrades screen (ex. adding a tab)
• Create a global array which has all enhancements and can be saved/loaded (we will change the state of some as each run progresses)
• Implement the label/GUI with the array (so you can purchase items and have it affect the global array)
• Implement equipping enhancements
• Implement a weapon switcher for laser enhancements
  • GUI
  • Create slots/update the GUI with names of equipped weapons
  • Get a way for Player.gd to see what enhancement is equipped
• Add extra lasers in the player's ship to be used for certain enhancements (using LaserGun for different weapon types and Player/LaserController to be an interface to all the LaserGun instances in the ship)
• Add extra laser types and develop enhancements to be used with those
• Implement laser enhancements
• Implement ship enhancements

Right now there's a lot of things that's going on in the game that the player can easily be unaware of, like how much points you get after you blow up an enemy ship. In short, my idea is that we can use the GUI to highlight when some of these events happen. Here's a short list of some of the stuff that could have alerts/HUD notifications:

• How much points you get after blowing up enemy ships
• Current/upcoming changes for each level (ex. Difficulty reset in 5 levels, [game mechanic change] in 2, or [an image indicating an enemy type] in 6)
• Elemental types of lasers acquired (ex. fire/ice/corrosion)
• How much coins you get after blowing up a coin crate
• How much levels are next until the next warp/reset (every 10 levels)

Is your feature request related to a problem? Please describe.
It seems that the boss mechanics don't change at all with different game difficulty choices. The boss will be the same whether on "Medium" or "Nightmare" difficulty.

Describe the solution you'd like
I suggest changing maybe his health, frequency of his shooting or speed of moving through space depending on the chosen game difficulty.

Additional context
Perhaps the difficulty of regular opponents will also have to be adjusted to the selected one.

Is your feature request related to a problem? Please describe.
It would be nice to be able to sort upgrades by damage, price, or amount of health added.

Describe the solution you'd like
For each option, there will be a corresponding sorting column at the top of the upgrade menu.

So as soon as I merged my code for saving games I noticed a bug with it :(

Describe the bug
When you save a game, it saves certain variables from Game.tscn that are initially set when you set the difficulty of the game. Therefore it shouldn't be tampered with for the rest of the run... but you can actually save it and go to the main menu, change the difficulty of the game, and then mess up some values when you load the save. This can be especially apparent under the "carnage" difficulty where InfiniteShooter will then save the game with variables changed. So, for a game that was in Medium difficulty, you can exit and come back to it in carnage, but when you save that again it will save the number of enemies that should be on the screen at one time. So something in medium difficulty will perpetually be stuck on a harder one!

To Reproduce
Steps to reproduce the behavior:

1. Create a save on any difficulty (ex. medium)
2. Play a bit of the game (because why not?)
3. Now, save and exit back to the main menu
4. Open the settings dialog and set the difficulty to something else (ex. carnage)
5. Watch it affect your save in unintended ways

Desktop:

• OS and OS version: All
• InfiniteShooter version: 0.5.0

Is your feature request related to a problem? Please describe.
The way I have backgrounds right now is that they're very detailed images projected onto a very large spinning sphere. While this is nice to animate, the fact that there's no blurring or anything can make it dizzying to look at. I mean, Tyrian was able to make moving backgrounds pretty well. But Tyrian was in 2D, and I have to make a fully 3-D implementation of a flat scrolling background. So there's a bit of ground to cover here.

Describe the solution you'd like
Maybe motion blur only for the background to make things in the foreground easier to see? But it would need to be performant so it can run on all machines. Plus, I need to make the background look more flat and less like it's a spinning sphere.

Describe alternatives you've considered
Maybe putting a plane behind everything, and changing that? But then reflections wouldn't work as well...

Is your feature request related to a problem? Please describe.
I think the frame limit is an important option because it allows you to remove unnecessary load from the GPU. For example, it makes no sense to play at 200 fps if your monitor only allows 60.

Describe the solution you'd like
You can add an additional option to the "Graphics" section of the settings.

Describe alternatives you've considered
Unfortunately, I haven't come up with an alternative.

If possible, provide any screenshots or mockups of your intended feature

Additional context

Right now, the selection square is a bit of a hack. There's code that works to do actual "selection" by cycling through indexes of a node (usually titled "Options"), and then the selection square itself is just displayed on top of a selected child node, resizing to the same size as the node.
This, however, is not without its problems. For one, you can't do horizontal selection and things get difficult when you start to take scrolling menus into effect. (For example, just look at Settings.tscn. It's a lot of hassle to try and get it to work, and it's full of hacks.)
For that, I think the selection square needs a sort of redesign. I think a redesigned version of it might use Godot's default way of highlighting objects, and labels can be replaced with buttons (to help with mouse support).
Doing this should help to lay the groundwork to tackle #15 and #5.