itch.io

Hello, some bugs I've found

• You can attack enemies, pick up items, and throw shurikens through walls
• If you try to throw items (holding the item button) while facing into a wall they will fly off at a weird angle
• Holding the L trigger while near another character and throwing shurikens (tapping button) will make the shurikens home into them even if you're not locked on
• I noticed you can't switch between input methods; if you start playing with gamepad you can't pick up mouse and keyboard controls. Could also be annoying if you just want to close the game for example. (This did lead me to discover that there's split screen multiplayer though!)
• I've noticed some animations look jittery on my screen. For example dodge rolling, some camera movements, and carrying bodies is especially noticeable because your character doesn't jitter but the one you're holding does. I wonder if you might be doing some kind of updates at 60Hz? My monitor is 165Hz so it's just a guess at something it could be. I also know you can get jitter from calling things in the wrong "Update" in Unity's execution order for example.
• I figured out that you can double tap dodge to cancel out of the drop kick before you hit the ground. Not sure if it's intentional but it feels a bit OP. 
• You can do some weird stuff like continue to strangle and break the necks of people who are already dead (lol). I also kicked a dead person in the nuts. 

By the way, it took me a long time to figure out that you need to hold the context button down to pick up bodies. Also, at one point I dropkicked myself onto the ground right next to a dead body in the camp and laid there for a bit, and a guy came over surprised at the sight of a dead body. I'm sure it was the real dead body he was reacting to but it gave me the idea that it could be cool if you could "play dead" by laying on the ground like that and enemies might react to you differently for some kind of shenanigans. I'm not sure if that would be useful for anything but it's a fun idea. 

Thanks!

Hi, thanks for this!

So you set the sensitivity to the maximum value but the bars still wouldn't move very far? I might have goofed and made the visuals for it framerate dependent somehow. Will take a look at that. The actual input sensitivity should still work fine though.

Did you try turning the plane by rolling to the side and pitching up, or were you relying on the yaw exclusively?

The missile trails are a "ribbon" particle effect with tube-shaped geometry.

Tried the update

Forgot to post here 

Thanks for trying! I made the combat harder this time as an experiment. Last DD demo was a lot easier, to be appropriate for new players. But I realized that people could breeze through without really engaging with the game's maneuvering, just taking it slow. I made it hard this time to see if anyone might step up to the pressure and figure out what the plane is really capable of.

In the end the problem is that it takes time and practice to learn to maneuver the plane and people can't get that in a short demo like this. 😄 But I already knew that. Your experience with it makes perfect sense. 

Technically there is gravity, but you fall slowly and push off the ground when you're close to it. 😁 It has vertical thrust

It's understandable. The plane can roll very quickly, so using the mouse for roll allows for finer adjustments compared to using keys or buttons. It's also intended that pitching and rolling is your primary means of turning, rather than yawing, which I like having together on the same input for that reason. Some games use yawing as your main means of turning, but I wanted to make a pitching and rolling game. I'll be exploring rebinding in the future but I suspect some configurations may not work well for this game.

The feedback is helpful, thank you!

Rolling and pitching gives you much more maneuverability than just yawing. The thing is, currently you don't need to. When I play, I fly crazy because it's fun, but the game doesn't compel you to. I imagine even in a finished product the early levels won't demand that much of new players, but it will be something to work into the game. 

I figured out early on that this was going to be a game that would take time for people to get the hang of. Unfortunate but if you do take the time with it you'll find it's absolutely worth it. Granted there is not enough content right now for anyone to do that but me lol.  Long way to go still. I will explore adding controller support etc. eventually but the foundation of the control scheme will remain the same. 

I will get that bug fixed, thanks for pointing it out!

I also found it troublesome to play other people's flying games after I started working on this. They all control different.

You're absolutely right about the boss. It's a bit crude at the moment; just chucked it in there at the last minute. 

Thanks for trying!

Thanks for doing this! This is actually the first time I've seen someone else play the game. It definitely helps.

It just takes some practice to get good with the flying. You actually did pretty good. I'd even say you looked quite natural. The major thing is turning around quickly. Onboarding will be a really important thing to figure out for this game. I think I need to record footage of myself playing so people can see what it can look like. 

Thanks for taking the time to write all this out. This is all very interesting to me.

I like the overall concept of the game, I think it's a good one and the reasoning behind your ideas for it make plenty of sense. 

Moku at its core is a game about exploration, discovery, and mastery over environment.

I think it's hard to make a game like this "about exploration" without having a world map. Not only is it just harder for the player to keep their bearings, but they can't really make decisions about where they should go or explore next without having that information available. A map also informs players about the structure of the game, which is something I didn't get while playing. Each time I encountered a new camp it felt like a step forward, kind of like reaching a new level, and I didn't think much about the idea of backtracking, whereas in a Zelda or Metroid game the idea of going back to previous areas feels natural and expected even if I've encountered newer save rooms already. 

You missed (various items)

One question I think can be asked is, do you expect, or want, players to find every item before continuing? Clearly it's at least possible that they don't. 

You also missed a pamphlet that would teach you about the stab attack, which is really useful to avoid hitting walls. You would have had a way easier time with the double spike arm guys if you had a shield and could just block their wild charge.

It seems like it's something inherent to your design, that players may not have all the tools that are potentially available to them. They are not required for progression like in Zelda and Metroid games. So the ideal might be that things are designed in a way that it's always still reasonable for players who may not have this item or that item. But that is also limiting on how you can design things. Broadly speaking, this can be tricky. It follows logically that the more important something is the worse it probably is if a player for any reason doesn't have it. There's a reason why so many games are structured in such a way that you can't continue without getting an important item or upgrade or even tutorial; it usually requires too many compromises on the kinds of mechanics and interactions you can do with items and upgrades if you can't ensure the player will have them. But that's not to say you can't have any interesting items or upgrades without them being strictly required. You certainly can, but it does require a lot of careful thought about the case in which the player just never picks these things up, and balancing that against the case in which they do. If there are certain things you 100% want every player to encounter, you might want to figure out ways to enforce that it happens at least for those items, even if you don't do it for all. (I will also point out that having a map will likely lead to players collecting more of the items.)

...different ingredients to cook with, one of which makes it so you don't lose your EXP on death

A word of warning: I have seen some games make unfortunate mistakes with these kinds of forced compromise upgrade systems. I'll give you an example: in the game Ori and the Will of the Wisps, you have a bunch of unlockable upgrades but only a limited number of slots to equip them, though you can swap them out as you will. Early on I found one that lets you stick to and climb up and down walls instead of sliding down them. I found this to be a nice QoL improvement, so once I put it on I didn't want to take it off again. But that meant that now one of my few slots was basically permanently out of the picture. Later I would keep unlocking some interesting new things, but the other one I had equipped was too strong so I couldn't justify taking it off to try the new ones. So in spite of having all these cool unlocks that were meant to add interesting wrinkles to the game, I couldn't really use them, or if I did I would be forced to make other compromises I didn't want to. It's easy to make this kind of thing an annoyance to the player instead of a choice that keeps things interesting. 

I haven't played enough of your game to know, but I could imagine someone seeing that an ingredient makes it so you don't lose EXP on death, and deciding that's something they want to have all the time. Then maybe some point later in the game if they found some other thing they wanted or needed enough to replace that effect with, they might find it frustrating that now they have to live with EXP disappearing on death. 

The kinds of things I think DO work well for this that are relevant to your game are the things like certain resistances, things which could apply to preparing for a certain goal the player might have in mind at that point in time. Things that could be more or less relevant depending on the situations. If it's something the player might ALWAYS want, especially if it feels like some kind of QoL improvement, I think that's something which you should think twice about. The EXP on death thing, if you're thinking about making that possible through items, maybe that should just be how it works by default instead.

One small mechanic you complained about was the injury system

To be clear I didn't complain about it, rather I just didn't understand it, or what was causing it. Now that you've explained it it makes perfect sense. I think a more graphical Status screen could help communicate more of these important details, and maybe renaming the "Health Cap" to something related to injury would help. 

...the sparkle is the most obvious thing I feel I can do right now without downright dragging players to the crafting table by the ear.

A pattern I've noticed with a lot of devs is they are overly afraid of tutoring the player. It's certainly true there are better and worse ways to do so. But in my opinion, the first rule is that if there's something the player needs to know, then you need to tell it to them, and clearly. The second rule is to do it in a nice way, and everything that entails. But the first rule comes first, even if it's at the expense of the second, instead of the other way around (which is how it seems like many amateur devs do it). 

One thing that came to mind, which is something I've seen that works well and suits the flavor of this kind of lone survivor type game, is that you could have some text pop up that shows the player character's thoughts to themselves. There's a lot of things you can communicate that way. But for example, in this case when the player picks up the item they could simply say to themselves "I should see what else I can craft with this." Something like that. 

GPU: RTX 3080
CPU: 7900x
64GB RAM
Windows 10

If there's anything else I can tell you let me know

I just realized I've been recording all my videos without any game audio lol. Oops!

The game crashed multiple times for me during the tutorials, and caused a bluescreen at one point (which is why there are two videos). I'm using Windows 10. Hope the videos are useful 
Edit: I just realized I've been recording all my videos without any game audio lol. Oops!

Edit: I just realized I've been recording all my videos without any game audio lol. Oops!

I really like this game! I'm glad you're still making it. Do you need any help with audio or anything? I would be happy to talk about it.

It sounds like the changes you have/will have in the updated version are good ones. At one point I did try to turn the craft perpendicular expecting the extra drag would slow me down, but for reasons that are now obvious didn't have success with it. 

I can appreciate wanting to have some complexity, and not just the simplest possible form of the concept. There is a question of, do the quirks make it challenging in a way that's fun to contend with. For me personally, dealing with a lot of inertia in three dimensions like this already feels challenging, but things that add confusion or inputs not doing what I expect them to do, those sorts of "challenges" are harder for me to come to terms with.

I'm still not convinced that having two separate modes the way you have them is either necessary or a good idea. But I'm also curious to know what led you to try that in the first place. I can understand as far as you wanting airplane like flight and helicopter like flight, and so you have two different modes for it, that kind of follows at least on paper. But practically speaking, it doesn't seem like something that arose out of necessity, or maybe I'm just not seeing it. 

As I mentioned, I'm not fond of how many things change when you switch modes. I could understand if it was something a little more specific, like enabling a particular kind of stabilizing effect. Then at least the button would have a clearer intention and utility, rather than being a button that just changes "a bunch of things." It's also unclear precisely how/when to make the transition from one mode to the other. You talked about using maneuvering skill to make the transition between modes of flight, but you also have a button that's supposed to cross that transition; how do the two meet?

To give a more concrete suggestion, why not leave the pitch/roll control unchanged between modes and just have the hover mode try to stabilize you vertically or something? If the player wants to flip upside down and crash then let them. That would keep the controls more consistent and make it clearer what the button is for. You could also have the hover mode be an on/off feature rather than creating a logical division between two separate flight modes (which would also help solve your naming issue).

I made a 1 hour video of this, but I feel it is probably painful to watch lol, and you probably wouldn't want to, but if you want me to I can upload it. 

My thoughts are as follows.

I can't help but feel the solution is overcomplicated. Switching between modes sounds straightforward enough on paper, but when it changes everything about the controls and behavior of the craft rather than just one or two things it makes things much more complicated. And for example, if I want to control vertical thrust, I need to change to hover mode, but in hover mode I can no longer roll the aircraft, and etc. By gaining some things I'm losing others.

Also, "automating" certain things to smooth out the user experience can be a great tool, but while the goal is to simplify the inputs, if you're not careful you can make them more complicated in a way. For example if I just want to move straight forward, I switch to manual mode, but if I don't have enough speed it's only giving me vertical thrust. I "can't" just move forward because I have to contend with the rules of how it wants to work rather than how I want it to work.

Between this and the aforementioned mode switching, I find myself wanting for more consistency in the controls. My game is designed as a very different experience, but it also features both airplane-like and helicopter-like control. I have no mode switching; if I want to move up I press the button to move up; if I want to move forward I press the button to move forward; some things adjust here and there but the inputs always move you in the same ways and when you want to move (or at least apply forces) in those ways you always can. It's hard for me to imagine why that wouldn't be achievable for what you're trying to do, but maybe there's something I'm missing.

The thing I had the hardest time with in general was slowing down. There are no brakes, and while I didn't specifically expect there to be brakes while playing, it does beg the question: how does a craft that flies like an airplane and lands like a helicopter transition between the two without brakes? It clearly is possible to do so within your game, but it's not clear what the proper answer to that question is or what the intended method is. Of course the other question you can ask is, why not have brakes?
Edit: I just found the part on the game page where you mention the engines firing backwards, but the way you implemented it seems counterintuitive. Why not give the player more direct control over it rather than have it tied to a particular maneuver in a particular case?

I wanted to do something like fly in and bank sharply left or right and then use vertical thrust to counteract my forward inertia, but switching to hover mode cancels out my ability to roll.

When I was in the tunnel I was trying to switch to manual mode and fly straight forward to exit the tunnel, but it kept flying me up into the ceiling of the thing, because I was not up to speed. It doesn't seem helpful for the manual mode thrust to move you up vertically when you're already up in the air but not up to speed. I also sometimes would try to accelerate and roll/turn right away but since the thrust starts out vertical only I would just go straight into the ground. As I understand it you're trying to compensate for a lack of lift in the transition to forward flight, which understandably complicates things, but it brings me to my next point.

While I'm confident "airplane controls" are a good idea for a spaceship game, I'm not so confident that it makes sense to have aerodynamic lift. I could understand if your goal was to create a game about a VTOL jet that can also somehow fly in space, and you wanted to achieve that with some realism, but the way you presented the concept was wingless sci-fi movie space ships taking off and landing, which doesn't seem in line with that. I understand there is a collision there between making something fly like a plane and not fly like a plane, but there are certain things about the concepts of gaining and maintaining lift that I don't feel someone piloting a spaceworthy metal brick should ever have to think about.

I definitely believe in the idea you have here, and clearly you've made it work for yourself, as the videos you've shared look very pleasing in how you're able to pull off the landings. 

I couldn't stop playing and yammering on about this one 😄

Hi, there was some funny business going on with the resolutions changing, which ended up with the capture looking a little funny as you'll see, though I didn't notice until after I finished recording. Anyways, hope you find it helpful!

Apologies for the multiple issues, including less than perfect audio. It's a new recording setup, plus there were audio glitches I wasn't aware of until I played back the video (it's my sound drivers/hardware not your game). Hope it helps though!

One time I thought I saw this happen in my game but I realized I actually hit the camera springarm lol

Hey, thanks for trying it out. I agree with the points you brought up. Did you try adjusting the mouse sensitivity though? One thing I wonder is if people will forget that mouse sensitivity is a thing because it's not your typical mouse look kind of thing. I tried to make that more obvious. Either way, it is the kind of thing where you get better at it with experience. 

Making weapons that feel good instead of sucky is one of the major priorities, as well as making enemies that are good and not sucky. 

It's funny because the towers are really easy to defeat *if* you're good at flying. I kept making them turn slower because I knew that people new to the game wouldn't be able to maneuver as sharply as I can after so much time with it, but then they got so slow I was worried people wouldn't notice them turning at all haha. Kind of a silly gimmick but just something I could get into the game in limited time.

We are on the same page about presentation. Thanks for trying it out.