itch.io

Hi! Everything seems to be in order now and you solved the download problem. Keep it up !

Where are the sprites? Something seems to have happened and now the archive contains only a GameMaker project with two textures (Space station and BG tile).

I like the concept and graphics (the visual style is very original). However, I have a couple of recommendations: 

1) You need a HUD that would indicate the FPV (positive and negative) on the radar plot and flight director. For inspiration, you can explore the control panel of real spacecraft

2) Also, for the game need a radio altimeter.

3) in fact, spaceships have several turn control modes: indication of angular velocity, the direction of rotation and direct control, and as I understand it, only the last control mode is implemented in the game, which is very rarely used IRL. Also, the inversion of the keys is a bit confusing, the fact is that traditionally only one axis of rotation can have an inversion of control - this is the pitch, I understand what the logic is, but the control of any aircraft is always designed in such a way that it is convenient for a person (the control must be ergonomic).

4) It seems that the game aspect ratio is 4: 3, but I doubt that such monitors are still left, the vast majority use monitors with 16:9. I think you should also focus on this aspect ratio, and you can use the additional areas on the sides for additional game elements.

I like the concept of the game (a never-aging classic), I also like special effects but the implementation is a bit lame:

1. I think that you need to swap the destinations of the right and left mouse buttons. The fact is that in 99.999% of the game with mouse control, the attack is carried out using the left mouse button, well, in about half of the game, the right mouse button is associated with movement and context menus, so the current control constantly confused me.
2. I think that small arms need mechanics to overheat is to limit the duration of the shooting. 
3. Ships should be smaller, I have worked a lot on this before and I can say that the optimal ratio of the size of the spacecraft to the height of the screen should be from 1/20 to 1/10. 
4. The friction is too strong, ideally, it should not be at all.

Graphics: I liked the basic style and post-processing, but it's better to redraw the spaceships.

Protection of the base on the contrary. Very fun :-)

An interesting concept, it seems to me that it can be developed into a full-fledged game.

Very fun and hardcore game. I like that the game uses procedural generation and the resulting graphic style. Very original approach. 

Still, it would be good to come up with a way that the difficulty of the game rises smoothly.

Wow, man! You do a very useful job: so many video reviews of published games, I didn't even have time to watch everything. Try to make a review on this game:

https://itch.io/jam/game-off-2020/rate/839075 

I got it randomly, and the number of ratings is very small, although the game is very original! It seems to me that this game is undeservedly overlooked.

The visual style is awesome!

Brilliant! Great idea! it works and looks great. I also wanted to implement the same one.

Brilliant! Great idea! it works and looks great. I also wanted to implement the same one.

Hi! Different classes of spacecraft use a different control scheme. Control scheme like classic lunar lander using fro large spaceships with the turret.

Thank you very much! In general, I'm thinking about it now, in fact, we managed to complete about 1/3 of the game, and most of the art is ready (and some of the art is not used, for example, only 2 ships are available out of 6 and only half of the weapons are available in the game). I plan to wait for the game jam to finish, get feedback, and then finish the game based on it (at least bring it to the demo stage). Basically, I am now thinking about the fact that I need to increase the dynamics of the game, rework the user interface and refine, make a smooth intro, and finish what was originally planned: enemies and dynamic missions.

We started later than the game jam started and in total the game spent about 1 week developing the art (you can find both packages on the artist's page, they are released under CC0 license) and about 1 week programming, so it probably takes about 2 more weeks to complete this. I think I can try to finish the game after the voting is over for the Christmas holidays.

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

So. I'm use Google Chrome on Windows 10. I also have another browser and I have already noticed that there is a difference between them for WebGL, maybe I should try and restart the browser, clean cookies, cache and see what happens. In fact, I was surprised to find that WebGL is very unstable from platform to platform, from browser to browser, form user to user and etc., but I do not understand what this is due to (the old Flash technology seems to be more reliable). Additionally, I can check with my XBOX-controller.

Ok. I understand. I also think that we should change the field of view. I'm thinking that if I increase field of view by about 1.5 times (camera is orthographic) , it should improve the game experience - the player will have more room to maneuver, more free time to reaction, and also allow for a higher dynamic speed range. The main problem is that initially the game was planned to control an astronaut, for these reasons, spaceships were drawn large enough (so that it would not turn out that the astronaut is larger than the spacecraft). Another feature is how I have implemented the render workflow: gameplay resolution is 640x360 pixel, than I'm scaling all sprites (with point filter) in 3 times to 1080p full hd resolution, because this approach allows me to freely use sprite rotation without fear of losing the aesthetics of pixel art. Thus, to increase field of view, I need to either reduce the size of all sprites 1.5 times, or set the gameplay resolution to 540p, then it will look like this:

I hope this will be enough.

As for the sluggishness of the ships, this is somewhat more difficult, because I need more experiments to understand which linear and angular accelerations are optimal. For slow ships with turrets, I think that I need relize movement with 4 degrees of freedom (in other words, the ship should have engines around its perimeter and move in any direction without having to turn). For fast small ship I need adjust thrust and angular speed. There is some difficulty in adjusting the parameters. The fact is that most arcade games use the friction, so that the ships slow down very quickly, but in my case, honest Newtonian physics without friction is used, so that the spaceships have high inertia. I plan to increase the thrust of all spaceships, but I'm thinking about how to discreetly limit the appetites of players so that they don't accelerate to superluminal speeds :-) Either I have to do fly-by-wire for spaceships (like, Wing Commander, Elite and Star Citizen),  or I somehow have to create obstacles for players so that they only accelerate to reasonable speeds. Perhaps the game needs some helpers for navigation. At least that's what I'm thinking right now. 

Thank you for your feedback.

Great art style!

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 :-)

Cool game! I hate orange flying eye...

It would be nice if the gun and jetpack were duplicated on the mouse buttons (left and right). Also probably missing some roll/dash action in order to abruptly go to the side. It would also be nice to be able to go both left and right from start location

Nice style and topic!

I haven't been able to get very far (it seems that this is very hardcore in my taste), but overall the game looks fun and I like it. 

It seems that the game lacks a fog that would hide the appearance of obstacles.

Hi! I use, regular mechanical USB keyboard. It seems that this is just another random webgl bug related to the combination of platform and browser. In PC version all Ok. I also observe with my game in the WebGL version, for example, some have problems with rendering, and someone does not start the game at all, although the PC version works fine for everyone. I don't really understand what these things are called for.

Thank you very much! Yes, the damage system of the ship's subsystems was one of the core-mechanics that we wanted to test and figure out how to better balance it. There were other ideas, but we didn't have time to implement everything on time.

This seems to be a problem with my mission generator, which should place astronauts on the map in random places and show them the path on the minimap - I did it on the residual principle, and it seems that it sometimes places the astronauts too far away from the player.  In general, this is normal, I myself sometimes lose several spaceships before I get to the astronaut :-)

I planned to make a dynamic mission system, where the mission controller will alternate between different missions: exploration, attack, rescue and defense depending on the situation in the game, but I did not have time to finish this part of the game as planned before deadline :-(

Hi all!

Our game is inspired by the classic Lunar Lander game, where player have to fly in the field of gravity of the moon around mountains, destroy meteorites, and rescue astronauts who will join to crew. This is an experimental game in which we decided to try to implement space with a wide range of subsystems that include:

1. Flight computer
2. RCS
3. Main engine
4. Fuel tank
5. Life support system
6. Damage control
7. Fire control computer
8. Weapon

Each spacecraft subsystem can fail for a short time in the event of damage to the spacecraft, and has its own unique effect on the control of the spacecraft. Unfortunately, the game is only partially implemented with a minimal set of game mechanics (some special effects, enemy spaceships, homing missiles, and the mission system were not implemented) therefore, only the game prototype is available.

Game pages:

• https://crazyfizik.itch.io/lunar-rescuer
• https://itch.io/jam/game-off-2020/rate/839119

Authors:

• https://crazyfizik.itch.io/
• https://mattwalkden.itch.io/

Nice game! The shooting is very good, and the visual style and sound in my opinion is original. However, I ran into a some problem, for some reason the input didn't work in WebGL (I played in the downloaded PC version).

Awesome game! The art style, graphics and special effects are great and I like the feel of the game. Although I'm not a fan of tower defense, but I liked this game.  But after a while, the game becomes very difficult and I'm completely swept away. It would also be interesting to have regular troops (infantry, armored vehicles) in addition to the towers.

Great concept, graphics and sound. I like the overall design of the game. Although it seems that it is a bit hardcore — I did not always have time to dodge the cracks and appeared suddenly (BTW, how are the cracks growing? Is this a procedural?)

Yes. This is possible, I think you can set any speed record you want to fly off the map :- ) Maybe I should somehow punish players who fly too far and accelerate too fast :-)

A good interpretation of the theme and a fairly complex gameplay with the control of the rocket and the character in turn (I also initially planned to move in a similar direction, but did not have time for finish all).

Great game! Very hardcore, but interesting :-) Very intertying art style. 

But there is not enough keyboard control. Also I need tooltips in shipyard menu and I have enough opportunity to install a radar. 

Cool! Excellent interpretation of the theme, excellent art and sound! I like it!

Thank you very much! Of course, I'm just thinking about what I can try to continue developing the game further, maybe I can start this next year.

I like the Intro when I have to overcome the Starlink barrier :-) The approach with alternating different mini-games is great, I like it. Yes, and the idea to make the Oregon Trail in space is good (although there is already such a game in Steam).

Very funny, flying weapons - I like the idea :-)

This solution will work in any case. In other words, the engines that are necessary for the required movement will always be activated.

However, if, for example, you have asymmetric pairs of engines with different thrust and any angles, and you act on Rigidbody through engines as now, then there will be side effects. For example, you have right-hand engines: the first with 1 kN and the second with 2 kN that are located at the same distance from the center of mass, and if you use my dot product approach to get acceleration to the left, then both engines will be activated at maximum power, and in addition to the linear force of 3 kN, you will also get torsion. To avoid such side effects, dot-product alone will not be enough and in order to accurately determine what the thrust should be for each engine to provide the necessary torque and linear acceleration, you will have to solve the linear programming problem. Alternatively, use a direct impact on Rigidbody, and use thrusters only as a special effects emitter, and in this case, you will only activate special effects using dot-product. which will be logically similar to realistic ones.

Cool! I like this idea. Frankly speaking, I also wanted to do something similar, but in the end I hit the side of the lunar lander. The only thing I would like is to be able to have an auto mode for firing a gun, and not just single fire and full-screen mode.

Very nice!

It would be even more fun if it was possible to shoot torpedoes at enemies or to clear the way :-) 

The only thing I didn't understand was what the floodlights were for. The idea of spotlights is interesting, and for example, it is used in games such as Sunless Sea, but even without spotlights, I can clearly see the environment. Maybe I just couldn't get down deep enough (so far my record is 600+ meters) to appreciate the benefits of spotlights.

But other than that, it's a simple, but great game.

I like your idea, although it is very hardcore and inherently ambitious (simulator).

A few comments about game and code: 

1) Relative to the rotation of the spacecraft. Although the possibility of direct activation of the RCS does exist, in fact, the rotation of aircraft and spacecraft is controlled either by setting the angular velocity or by setting the angle of rotation. In general, it would be good to develop a simple regulator for controlling the angular velocity of the spacecraft. 

2) And I looked at your source code, and I can say that you do not need to manually attach the activation of the engine to a particular button and there is no need for pre-manual distribution of thruster in directions, instead, in simple cases, you can use a dot-product to determine which engines are directed in the right direction for the desired movement and rotation, for example, like in my example in Activation method. I don't set any threshold in this example, because this script does not interact with physics, but is only needed for special effects, but you can set a special threshold (for example, if dot-product is greater than 0.5). This works well if your engines are directed orthogonally or collinearly to each other. You can see how this works in practice in the demonstration of my other old example.

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?