Smith and Winston

Explore and Destroy in this fun adventure, with twin stick combat and full level destruction · By Execution Unit, Charlie, MetalDazza

Add to collection

game Community Devlog

Smith and Winston community

Linux testing feedback

A topic by jotson created Oct 14, 2018 Views: 962 Replies: 8

Viewing posts 1 to 4

jotson6 years ago(+1)

Hey, great looking game! Thanks for letting me try it. I'm running this on an old i5-2500k (2010 vintage) with a GTX 1060 on Ubuntu 18.04.

First off:

Launches fine from itch app
Launches from direct download
Keyboard controls work
Looks good!
Sounds good!
I didn't find any bugs at all with the gameplay itself, moving around, destroying the environment, shooting bad guys, flying, jumping etc. All the portals worked, the keys worked, falling off the island. :-)
Menus all work well, changing options worked, full screen mode worked.
Great job!

Now, some issues:

Had a little issue with my gamepad. It wasn't detected at first even though the controller works with every game on Steam. I'm using xboxdrv to emulate an Xbox controller. Here's how it's reported by html5gamepad.com:

Weirdly, it worked fine with your game when I turn off xboxdrv (but then some of my steam games don't work):

Some suggestions!

The screen shake when those exploding spider things explodes isn't synchronized with the explosion. Feels like it's about a 1/4 second late.

The default gamepad control layout uses X to jump. Since it must be held, it's difficult to aim, jump, and shoot at the same time. I also find it completely unfun to control the camera. I wish the camera would just show me what is important by itself. Some combination of where I'm going and where I'm aiming, weighted towards aiming, would be a good start, I think. In shooters like this, for me, it always feels bad if I have to take my thumbs off the sticks. Like, I just want to shoot stuff non-stop and if I have to stop moving so I can switch weapons or stop aiming to jump, it kills the momentum. It's great that you can remap the controls but losing two buttons to the camera is rough.

I think the depth of field blur is too strong and it's distracting. Here's a couple of examples, both involve not being able to see where I'm looking. First, my landing spot is blurry:

And I can't see enemies down field. Even when they're at the edge of weapon range they're slightly blurry.

I'll keep playing and report back later!

Ilazki6 years ago (4 edits) (+1)

(Hope you don't mind that I'm adding my feedback here as well. Seemed better to consolidate than to make separate topics.)

First off, thanks again for the key. I haven't gotten around to playing yet, but I got it installed and went through the menus and configuration to get everything set, so here's the first batch of thoughts, issues, and oddities:

First Run

No apparent issues on setup, install, or launch.
An extremely minor nitpick: config files are supposed to go under $HOME/.config/; $HOME/.local/share/ is intended for data files. That way you can easily back up all user configuration without inadvertently using a lot of space on things like miscellaneous downloaded data (like, say, a leaderboard, stuff like that). That said, not everyone follows this, and it's good that you used one of the locations. Shows that someone is trying to respect the specs :)
No multi-display issues, good job on that. Having three displays and the middle one set as primary frequently trips up game engines (*cough* Unity, UE4) so congrats on keeping it smooth.

Configuration

The Shadow Quality dropdown, when expanded, goes down to bottom of screen, which causes it to be cut off by the bottom of the window. Might work better expanding upward, would seem less cramped as well.
The hover tip for the "explosion debris" slider appears if the mouse hovers over a "Shadow Quality" dropdown entry, which shouldn't happen since the slider isn't being hovered, the dropdown is.
Not enough visual distinction between selected and deselected checkbox entries. Couldn't tell if vsync was enabled or not at a glance; had to compare it to the fullscreen checkbox to figure out which colour meant it was enabled.
In the settings, it says "* = requires restar". Typo or unexpected truncation?

Key bindings

Technically part of configuration, but there's enough here to need its own section.

I was able to bind mouse4/mouse5 (side buttons) without issue. Nice.
However, the text for them ("extended mouse button...") is too long for the box, so I can't actually tell which one is bound.
Surprisingly, I could not bind mouse wheel up/down. I wanted to set that to the camera zoom but no dice.
Key binding does not respect xmodmap and setxkbmap settings. I have right alt set to AltGr via xmodmap, and use setxkbmap -option compose:menu -option ctrl:swapcaps to swap caps/ctrl and make the menu button act as the Compose key but none of these were respected by game engine. caps was listed as ctrl, ctrl as caps, etc.
Attempting to bind F2 and F3 does unexpected, debug-y things currently. They probably should be somewhere farther away like around F7-F10 , and whatever they're set to really shouldn't be bindable, or triggerable at all during keybinding. I thought the game froze and died at first due to attempting to bind F3.
Similarly, Home is being used for debug menu. Maybe a high-numbered Fkey instead? And not usable as a keybinding.

Fonts

The custom font you're using has a few issues.

2 and Z are identical, which meant I spent a non-trivial amount of time trying to figure out what the "H2" in the resolution selection dropdown meant before noticing it was supposed to be HZ, but used the same glyph as the 2 in "1920 x 1080"
The @ used in the res selection isn't clearly discernible as such.
The inconsistent variation of glyph heights is weird. Some of the characters being shorter than others makes text LooK LikE ThiS . It would probably look better if they're all the same height, or if you want some variation, maybe use a small caps approach where capitals and lowercase use the same glyphs but "lowercase" is slightly smaller.

Miscellaneous

The F2 debug HUD thing indicated that MSAA and anisotropic filtering are available but disabled (judging by the box by 'vsync' being ticked, but those not). Why no configuration options for these?
It also says you're using OpenGL 2.1, which is a 12 year old specification. Surprised something newer isn't used.
Out of curiosity, what engine is this? Is it custom?
Setting shadow quality to "ultra" makes the poor game crawl on the main menus, despite the F2 HUD showing no noticeable difference in FPS. In fact, it makes my entire system noticeably less responsive. High doesn't do this. (Edit: seems to be more of a symptom of the smoke particles. More on this in another post later)
Game segfaults on exit. I used the itch client to send a report, but a bit of additional info that it doesn't provide: when it happens, my syslog shows "error 4 in libGLdispatch.so.0"

That's it for pre-play notes I think. After I've had some time to sit down and play it for a bit I'll do another write-up on that.

MetalDazzaDeveloper6 years ago

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.

Ilazki6 years ago (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:

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

MetalDazzaDeveloper6 years ago

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.

Ilazki6 years ago (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.

MetalDazzaDeveloper6 years ago(+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.

MetalDazzaDeveloper6 years ago

xboxdrv: I've added a bug to the database for this, we use SDL and so it "should just work" but nothing in software does as it's told! Thanks for reporting that.

The next release should fix the issue with the spider camera shake, good spot.

We prototyped an "intelligent" camera and it wasn't very successful. Because the player is pushing right-stick to the right, the camera swings behind the player a little, but the direction the player character faces is relative to the camera so the player character turns a little and the camera swing around a litte and on and on. We can dampen that but players reported that they started to feel a little sea sick as the camera never stopped sloshing about.

In the end we designed the game around the eight angles that you can fix the camera at but I agree it was a compromise and we're trying to balance a lot of things for the player.

The depth of field blur, yeah we can adjust that. It should give a sense of depth not simulate being tipsy.

JDGBOLT6 years ago

Yeah, that was one thing I noticed that I forgot to mention, when the game went below 60fps with the particles on screen when power limiting my Fury, it caused the whole game to seem to go in slow motion, the animations got slower and such. Forgot about that otherwise would have put it in my feedback.

itch.io

Smith and Winston

Linux testing feedback

First Run

Configuration

Key bindings

Fonts

Miscellaneous