Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(3 edits) (+1)

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

As far as frustration with flying/shooting - the ships felt sluggish. Additionally, the POV is pretty zoomed in so there isn't a lot of time to notice an asteroid coming and move the guns and fire and actually destroy them before they hit you or fly by. While I was playing I think i only used the initial small ship (the one you crash with the astronauts) and the bigger ship you get second. I wound up restarting a few times and repeating with these ships because I flew too far up or over and didn't feel like trying to navigate my way back to land.

Also I hope this doesn't feel negative. If anything, what you have feels like a great foundation and I can see a clear path something really great... I always wind up having more constructive feedback in that sort of case. You all did a great job and I'm impressed you did this much so quickly.

(1 edit)

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.