Hi! Unfortunately, the game's goals are one of those things that has fallen under the onslaught of time :-(
At the moment, you need to fly and search for astronauts to save them, as well as periodically return to the base for repairs and refueling. The relative location of targets is indicated using a green marker on the radar in the upper-right corner. However, in fact, your main goal is to survive :- ) I sometimes need to change several ships myself before I can save an astronaut.

Initially, the game was supposed to be more dynamic, where the player had to first fight with enemy spaceships, but this part was not completed before the deadline. So you're actually playing an early prototype with a few core mechanics

Thank you very much for feedback! I will convey your words of gratitude to the artist (it took a long time to work on the visual part).

What exactly caused the frustration during flights and shooting? Could you explain in more detail?

The flight mechanics are quite typical for games of this kind (Lunar Lander, Asteroids, SpaceWar!) — you just need to fly in the field of gravity to the objective point and land like in Lunar Lander to take the astronaut on board. Flight control is quite smooth in my opinion and similarly to same type games, but it took a lot of time, because both angular and linear motion is provided by physics, in the absence of friction with the help of a simple regulator, and it was quite problematic to balance (given the fact that there are no speed limits) and suddenly it is very closely related to art (because it is pixel art), given that the game uses two different control schemes for large and small ships. So with movement, I need to map out specific growth points in advance. For larger ships, I plan to slightly expand the control system and make it 4DOF by thrusters, as I did earlier.

As for shooting, it was originally planned to add full-fledged enemies, but other aspects of the game took too long and the enemies were not completed (primarily AI and problems with and the mission system), so shooting is more of an auxiliary ability. Finally, shooting is primarily intended to shoot asteroids, because a collision with them can be fatal, especially if the propulsion system is disabled at high altitude. 

So in fact, your entire mission is to fly and rescue an astronaut, periodically shooting asteroids and avoiding collisions with mountains, with breaks for refueling and repairs at the main base — for this you earn points. We didn't have enough time to implement more :-(

There are really no limitation, I thought about getting around this in the following ways: punish the player if he flies too far (it seems that this should be done first), wrap the world around myself (here I encountered jerks in the background, it seems that this issue should be studied better) and procedurally generate an infinite world in blocks (for some reason, this does not work in the WebGL version, so I had to abandon this, the demonstration of level regeneration is only in the PC version, but without an infinite world).

As for the sounds, we didn't have time to finish this part, although I have already started to pick up a collection of freely distributed sound effects, perhaps later if I do a rebild of this game (this will be next year after the voting is completed).

Now I'm trying to collect a detailed feedback. after that, I will decide what to do next: finish the game and add the missing features, or make a new project based on this with a total rework, or do nothing :-)

Thank you very much! 

Yes, I agree with you. There is still a lot of polishing and balance of the gameplay and I need to add movement in all 4 directions (with 4 degrees of freedom, as here, for example) and it will even be more realistic it's just that I've been experimenting with different approaches to gameplay and software architecture.

As for the field of view, this is just the most difficult part, in which I need to correctly choose the size of the ship relative to the height of the screen and accordingly balance the range of available accelerations and gravity. I also think that the field of view is too small, and the relative size of the ship needs to be reduced, however, this is complicated by the fact that I'm using pixel-art that imposes certain restrictions to preserve the perception of art. In other words we need to redraw the spacecraft sprites and reduce their sprite sizes. Currently, spaceships range in size from 24 pixels to 48 pixels, with an average size of 32 pixels, but it seems that the optimal size should be between 16 and 32 pixels, but in most cases no more than 24.

Fast way - I can increase the gameplay resolution: now it is equal to 360 pixels in height of screen which is then scaled to the target resolution (1080p or 720p), potentially I can increase it to 540 pixels, but in this case, the minimum comfortable resolution for the game will be 1080p, not 720p, and everything below 1080p will have noticeable graphic artifacts (related to turns and movement, because I do not use interpolation and anti-aliasing due to the fact that they will lead to pixel blurring).  

I think if I reduce the relative size of the spaceships to 1.5 it will be OK. I think like this:

Or it should be a different art approach: simple sprites (not pixel-art) which using bilinear filtering and anti-aliasing, or should it even be a 3D game. In this case, I can freely choose the zoom of the camera.

Hm. I can probably try adding a simple tutorial screen before starting and do it quickly.

About subsystems — it seems that this was one of the main core mechanics. However, I'm not entirely sure I've chosen the right set of subsystems that the player should track. The current set of subsystems is as follows:

1. Flight computer through which the ship's movement is controlled
2. Main engine — linear forward acceleration
3. Reaction control system — ship rotation
4. Fuel tank — fuel for main engine and RCS operation
5. Fire control — handle for weapon
6. Main gun — pew-pew with specified accuracy, fire-rate and bullet speed modificator
7. Turret (only for big ships) — allows you to rotate the main weapon independently of the ship
8. Missile launcher — canceled, because I havent time for finish the enemy
9. Radar — it should be related to weapons, enemy detection, and mapping, but this was not completed
10. Life support — crew
11. Damage control — hit points and repair of subsystems
12. Cooling system — not released
13. Power system — not released

This emphasis on subsystems in this case is an experimental mechanic that is great for testing on a game jam, but I'm not sure that this is done correctly. It seems to me that the number of subsystems was too large, although this combination allows you to achieve unique combinations of damage effects (for example, a ship without a crew loses control and becomes a useless pile of scrap metal in space), but it seems to me that there should be fewer subsystems, because such a large number of subsystems is very difficult to tracking by player, and it also complicated the development. Now I'm thinking that it probably makes sense to combine some subsystems to reduce their number, for example, 

• Combine the main engine, RCS, and flight computer into a single subsystem, exclude the power system (it is still directly connected to the main engine), but for other hand the main engine and power plant can function independently of the performance of the flight computer and RCS (but not vice versa, since the heart of the atomic ship is a nuclear engine)
• Combine radar and fire control into one subsystem, on the other hand even the failure of the sensors in theory allows the player to shoot blindly
• Combine life support and damage control into one subsystem
• Eliminate a separate cooling system (although it was planned to make an overheating system for weapons, and cool it independently).

In general, as you can see, I got into a classic design fork and experienced developer analysis paralysis. Personally, I think that the number of subsystems should be somehow reduced to 4-6, because first of all, a person can usually keep about 3-5 entities in his head, and secondly, this will simplify the development of code (now I have a very large number of disparate game objects and a voluminous property inspector).  But on the other hand, a large number of subsystems can be perceived by the player as a special version life bar.

What do you think about it?

With contrast, everything should be fine, on the contrary, the terrain tiles and spaceships are very bright, while the background is very dark. The only special feature is the low contrast between the background and asteroids. Initially, asteroids were made in several color options, but now the game only has the darkest version of asteroids, which are faintly distinguishable from the background. This was a deliberate choice to make make asteroids less visible, so that their appearance often comes as a surprise to the player :-) Bright asteroids are too easy to play with :-) 

However, the game uses a linear color space rather than the outdated gamma color space, but I don't think that this can cause problems with contrast on the MacBook.

I don't really understand what mean "jerky" - is it input lag, freezing, image jitter or background jitter while ship moving? There should be no problems with lags, the game runs absolutely smoothly both for WebGL and Standalone versions, but there may be problems with the background image in the Web version. You should also keep in mind that the game was developed for a resolution of at least 720p (1080p is better), so there may be noticeable artifacts in a small browser window (there are none in full-screen mode), also game uses the 2nd version of the graphic API for WebGL version. in general, the images in WebGL and Windows versions are slightly different. I think if you look at the two images below, you will immediately see the differences between the PC and WebGL versions (at least in fonts and the position of UI elements, but not only)

However, I do not know exactly what configuration you have, if your Mac does not have a discrete video card or it is not used for playback, then there may really be problems. As far as I know, only the top 15" models of MacBooks are equipped with discrete video cards, and if this is really standard equipment with an integrated video card from Intel (for example, some Iris UHD), then there will be only 48 shader processors there - this is slightly more powerful than the GPU of a mobile phone, and somewhere in the level of video cards between 2005 and 2010, and this can cause problems because and heavy pixel shaders are very actively used in this game (postprocessing and some effects), although I specifically checked the standalone version on my very cheap laptop without discreate video card and there were no problems, but it was the windows standalone PC version. In general, I need to understand better what your problem is and what it is related to.