Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
(+1)

In the first camera system I made for Nytro, controlling the camera with the look input while charging was actually implemented that way, because I felt the same way about it. There's a pretty strong desire to steer with the look controls, and it feels pretty good on a gamepad (while using left bumper/L1 to charge).

But, it works poorly with a mouse due to it giving off a 0 to 1 value  based on a change in movement rather than a constant value like you would get with an analog stick or button press. Since there's an intentional limit to how fast Nytro can rotate while charging, it tends to feel sluggish with a mouse. It's a lot like controlling a super slow turning aircraft in a flight sim using a mouse. I've thought of and tried some solutions, but it's pretty hard to make it feel solid.

That being said, I do still want to try porting steering with the look controls over to the new camera system with gamepads, at the very least. And, I'll try to find a reasonable compromise for the mouse.

Animations are definitely in the list of things to polish up, with some of them thrown together out of necessity while working out the basic movement kinks. Swimming uses existing dry land animations just to indicate a clear state change while testing, and the glide animation (which is temporarily used for multiple swimming states) is more like a glide frame of animation. For swimming, my current plans are to either add retracting paddle wheels around the thighs that extend in water or use the legs themselves as paddle wheels.

I may be misunderstanding about the character snapping forward suggestion, but if you mean that it's difficult to keep the character aligned to the intended movement direction while walking and rotating the camera, I agree.  Although, rather than artificially bias the player's input to their original forward vector, I'll be changing the way the camera targets the player so that it's less wobbly, which should mitigate the problem as a side-effect. If that fails, I may, indeed, have to look into adding a movement input bias. But, I'll leave that as a last resort and possibly a user preference in the options menu.

Anyway, enough of my thinking out loud. Thanks for the feedback! Overall, most of the suggestions I've heard so far align pretty well with the to do list points in my notes. So, while they may not show up in the demo for a while (as I'll be focusing on content until I have a couple of decent levels and a proper hub world) they'll certainly make their way into the game eventually, in some form.