Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

No problem, all feedback anywhere is fine by me :)

The config location, we actually ask libSDL2 where to put the config files, so we're just copying any game that also uses libSDL. Sorry it's not perfect but better than on the desktop :)

libSDL also helps a lot with multi-monitor but it's good to hear that it's working for you. There are a lot of edge cases and we did test for it but only with two monitors.

You're correct, there are a lot of little issues in the menus, I'll add some specific bugs for things we've just overlooked, thanks.

On key bindings, I've added bugs for these, all good points although I'm not sure how to deal with xmodmap mapped keys as SDL (AFAIK) accesses the device directly bypassing any settings. I'll look in to it. Also you found our debug keys and that makes you a very naughty boy! We'll shift them out of the way :)

Fonts: yeah the font is form over function especially for the menus where legibility is paramount. We need to look at that.

Misc: It's a custom engine, the debug menu you are seeing exposes that we use BGFX for rendering and that uses OpenGL2.1 which is old but it also gives us Vulkan, Metal and DX12. We've not enabled those yet as we're trying to focus the testing as we're a two person team, one coder and one artist, and it can get overwhelming very quickly. I really look forward to releasing Vulkan though, it's really nice. THe segfault on exit is completely my fault as I've been too lazy to fix it, sorry.

(1 edit) (+1)
The config location, we actually ask libSDL2 where to put the config files, so we're just copying any game that also uses libSDL. Sorry it's not perfect but better than on the desktop :)

I suspected that might be the case.  No worries, it's still better than dropping it in $HOME or $HOME/Documents (both popular with first-time ports from long-time Windows users) or inside the game's install dir (popular with Steam games. *cough* Starbound), all of which I've seen other games do.  

On key bindings, I've added bugs for these, all good points although I'm not sure how to deal with xmodmap mapped keys as SDL (AFAIK) accesses the device directly bypassing any settings. I'll look in to it.

You may not be able to do anything about it, then.  Luckily it's just a minor cosmetic thing so no big deal :)  

Of the two, setxkbmap is probably more important to respect if possible.  Desktop environments like GNOME and KDE expose it in configuration panels so it gets a fair amount of use, especially capslock remapping.  xmodmap binding is manual and much less common.

 Also you found our debug keys and that makes you a very naughty boy! We'll shift them out of the way :)

Yeah, I tried every key to see what would bind and what wouldn't (Edit: no I didn't, I forgot to try middle mouse. WTF, me).  A lot of games have weird blind spots, like Monster Hunter World can't bind [ and ], UE4 had (has?) trouble with numpad binding, stuff like that.  Figured it would be an easy target to finding something weird.  I really hope you can get mousewheel bindings working, though. 

Like I said when I requested the key, I break software in horrible ways. Some of it is intentional because I think like a programmer/tester, "this looks abusable..." and some of it is because I try to do things that seem reasonable but turn out to be unexpected.  Did something out of sequence in an MMO (got back into a quest area you weren't supposed to be able to re-enter trying to help a friend ) and broke my character so badly that logging in crashed the zone instance I was in for example. :(

Misc: It's a custom engine, the debug menu you are seeing exposes that we use BGFX for rendering and that uses OpenGL2.1 which is old but it also gives us Vulkan, Metal and DX12. We've not enabled those yet as we're trying to focus the testing as we're a two person team

Makes sense, especially with a custom engine.  Also making a custom engine, making it run well, and keeping it cross-platform is impressive.  I know that has to be a lot of work.  

THe segfault on exit is completely my fault as I've been too lazy to fix it, sorry.

Okay so it's not just something weird with my system.  Doesn't bother me, I've noticed a lot of games exit not-so-gracefully like that, especially on Steam which hides it from you unless you're watching syslog or Steam's  console output.

                                                                                             

I spent a bit of time before I slept last night on the game, just a bit of time in the first couple stages of the story mode.  Only ran into a couple major issues:

  1. it crashed before I finished the second area, but itch didn't give a stack trace to report.  If it happens again I'll try to get more info
  2. on next launch after the crash all the voxels were textureless black shapes until I toggled shadows off and on again.  

Aside from that it was minor things:

  •  the ship's text boxes end before the spoken dialogue
  • mining laser audio seems strangely quiet compared to the pea shooter and other effects. Or maybe the pea shooter and enemy weapons are louder than they should be? Unsure
  • Smoke and fire effects absolutely kill game performance. When I went too close to the crashed ship at the very start of story mode the game slowed to a crawl.  F2's rendering info showed GPU time spent jumped from 7-8ms to around 23ms when it happened.  No noticeable change on CPU.
  • Depth of field is maddeningly short, but that's already been covered in other comments
  • Default bindings for fly and dash are backward for keyboards.  Usually games use space for jumping and other jump-like actions, and sprinting type movement goes on shift.

Finally, a feature request that may be too much work to implement:  I'd absolutely love it if the game had a setting or keybind to enable a camera-follows-mouse mode.  Currently, the camera is fixed (and manually controlled) and the player follows the mouse, which works but occasionally feels clunky, especially when platforming.  While playing I kept finding myself wishing the player always faced upward (like an old-school shoot-em-up) and the mouse caused the camera to rotate instead for navigation.

I'll have to spend more time with it when I can.  I didn't get past the very tutorial-y feeling start stages but it was fun and definitely has potential. :D

Thanks for more excellet feedback Ilazki. I've added and updated all your issues in the bug database.


On the camera: We have tried a lot of different camera modes including the always behind and we just couldn't stop people feeling seasick, we even did a first-person version (which was great but required all the gamplay to be rewritten so we dropped it). Like a lot of things it always about balancing features and actually delivering the game.


Once again, thanks for taking the time.

(1 edit) (+1)
On the camera: We have tried a lot of different camera modes including the always behind and we just couldn't stop people feeling seasick

Out of curiosity, were they getting seasick playing that way with a controller, with a mouse, or both?  It seems like the kind of thing that might work better with a mouse, though the turning speed might still make it sickening for some.  People used to playing first/third person shooter type games with KB/mouse are probably more accustomed to quick turning, like that.

To better explain why I even requested it:  with mouse/KB, the current scheme is great for the combat, but feels clunky for platforming, so I was trying to think of a workaround.  One idea might be to have a keybind that, when held down, makes the mouse control the camera at a lower speed than the normal player movement.  That way you could have the current control scheme by default, but hold a key (right mouse by default) to temporarily lock player orientation and take control of the camera (at a lower speed) instead.  If you've ever played World of Warcraft or any number of other MMOs, this should sound familiar, since they do something similar.  That would improve mouse/KB platforming but still keep the current scheme for combat, where it works well.

Once again, thanks for taking the time.

No problem, just trying to help.  That's what I requested the key for. :D  When I see that someone's trying to make a Linux game right instead of releasing half-broken garbage and ignoring bug reports (ARK), I like to help however I can.

(+1)

I see what you're saying actually, I think we might have neglected the mouse/kb controls a little here. It's a very good point. I do remember the control scheme from WoW that you're describing. I've added this to be bug database, we'll think it over and prototype somethings. Once again, thanks , you're a star.