So basically q and e strafe while a and d rotate? That seems like a very nice control scheme that would be pretty intuitive if we wanted to have the mouse free for some other function (like clicking to enter the editor window). I can’t actually test it (laptop doesn’t meet min reqs) but the idea is solid.
I’m quite certain that I would absolutely hate this control scheme as everyone who has played games has an idea how a first person 3d character movement should work. So we should stick to it for 3d stages. Flying controls could be slightly altered like some casual flying games do.
Fair, though I do believe this is similar to the control scheme used in console games, which arguably isn’t what we want to be going for since this is a PC game, mainly I was putting forward different control schemes and presenting an alternative to the current one for the Microbe Stage for people to test.
I think trying new control schemes is a great idea. The conflict between using the mouse to turn and click buttons has bothered me for a while, so perhaps we do need to consider a purely keyboard-based system. All of your scheme suggestions have merit and I think we need to perform tests with multiple people to understand which is most intuitive, best balanced and most adaptable to later situations.
Excellent post @Treviisolion!
I think the Keyboard Based 2D-Relative is the best for the Microbe Stage, because the idea for strafing with A and D and rotating with Q and E is a really good idea. Plus, it opens up the mouse which we need for clicking on cells, hovering over and clicking UI elements, etc. Of course once we start playtesting we’ll see which one does work best.
I think that it’s fine to have a difference of controls between 2D Microbe and 3D Multicellular. There will be a brief cutscene in between and the UI will be changing anyways, so we can also use the chance to change control schemes as well to one more appropriate to 3D Multicellular.
Does anyone know if its possible to playtest the pre-Leviathan build of Thrive using the alternative control scheme files you changed?
I worked on it a bit, but I don’t believe it’s possible changing only the lua scripts as I was doing. I’m not certain if working with the pre-Leviathan engine requires as much setup or not as the Leviathan engine though.
The latest pre-Leviathan version in master branch is broken so converting this to work with it wouldn’t work. Maybe you (or someone else on windows) could share (just zipping up thrive/build/bin should work) the WIP version (I can share the linux version if someone wants to test it).
So something that I’m considering is making the A & D tell the cell to apply torque, however that’ll have to wait until the torque is re-implemented. Also hhyyrylained do you know how to upload files to this site, it’s saying it only allows photos.
There’s only a certain types of files that can be uploaded. There’s also the issue of storage as this server doesn’t have ridiculous amounts of storage so it is better to host bigger files elsewhere. But I suppose it is possible to change the allowed file extensions to include .7z to allow small zips to be uploaded.
Alright in theory this link should let you download the .7z file which if you extract will let you test the change without having to recompile. https://drive.google.com/file/d/1qsbRkaOHZ75biPeV3gh_ZrxpRibqE1Bi/view?usp=sharing
It feels a bit too rigid and sticky right now, but it’s something I’d like to see expanded upon.
Where did you get the test from? Also exactly in what ways does it feel rigid and sticky? It’ll help in fixing that.
I replaced the bin folder of 0.3.4 with the one you gave. Given it appears to work in the new engine, I’m surprised it all worked to be honest. This is my first test of the new engine as a whole I guess. I made a quick video of my favourite moment.
Turning is the main issue. It takes a moment or two to register input, and unlike moving forward, there’s no smooth transition in or out of the turning motion.
The .7z file should have fixed the first problem. I hadn’t updated the branch I linked just quite yet. The problem of smooth transition out of turning is unfortunately going to have to wait until we get torque re-added in. The branch should be updated though now.
The oscillation issue with the torque turning method needs to be resolved before it is usable.
@tjwhale and I have been playing with movement in the cell stage. We have a prototype here that allows you to build and test drive a cell (I made it in pygame so it doesn’t use the engine) they use a rotation method that doesn’t involve torque at all. Instead the cell simply turns faster if the angle through which it must turn is large. This prevents oscillation and feels good. In the file that has “const_rot” in the name the turn rate does not depend on the cell properties while in the other file it does. You need python in order to run these prototypes with the command “python movement_prototype.py” or “python movement_prototype_const_rot.py” while in the directory containing the file.
Time to necro this thread because reading what some people have proposed lately and hh’s plan gives me anxiety
there has been a debate in the discord regarding 3D movement when not constrained by being stuck on the ground (swimming and flying)
the wiki proposes this:
WASD movement toward cursor
SPACE / C: up / down
RIGHT MB+MOUSE: VIEW
no pitch and roll
me and several other devs want this:
WASD movement along VIEW
*Q / E: roll
SPACE / C: up/down
SHIFT: sprint / charge
*MOUSE: yaw and pitch; VIEW
*pitch, roll, and yaw only change when moving
I don’t want to start a debate, but I’ll write a summary of my opinion on this from discord.
Basically my idea is that we don’t really need roll control, so instead a more basic scheme like an FPS game would be used, for example I think the movement in source engine games is excellent, and they have the same control scheme for also when swimming in water.
This would have the main benefit of simplicity to implement (as one argument for roll is that a species could have more swim power in different orientations meaning we need to calculate that somehow) and likely simpler for players to understand. One problem I foresee this solving is that if you have an amphibian species, it’ll be less confusing if the control scheme doesn’t entirely change when in water. I can imagine very annoying scenario where you are stuck between water and land when trying to get out of the water and constantly have switching control schemes…
The main drawback is that Thrive wouldn’t be an “underwater flight sim” and we wouldn’t need to have an up / roll indicator in the GUI (or a button to orient back so that up is up).
I just wanted these points out.
If you are a community member, we’d be interested to hear whether you prefer to have an “underwater flight sim” as one stage of the game or if you would prefer simpler controls (and we can put that freed up game design complexity somewhere else). And also if you think that the average Thrive player would quickly grasp that. I have a guess that the overlap between flight sim fans and Thrive fans, isn’t super large, but I could be wrong. Anyway I don’t want this to be decided right now, I think we should do public playtesting for the different control schemes when the time comes. Maybe we’ll even end up with both with an option to switch between them (but then we need to find out which scheme is better for the majority of the players to select which is the default option).
As one final small thing, I’ll just say that I prefer CTRL being the crouch key.
I think I agree. I get the feeling some players (including me) might forget the roll keys exist when swimming around, or just not be familiar enough with hydrodynamics to understand how it would help them. Maybe it could be handled automatically, so you always roll at the best angle for optimal speed when moving and turning?
I think it might be too early for this kind of discussion; as far as I know no one really knows how hydrodynamics or fins are going to work, other than just assuming they’ll behave like they do in real life. Maybe fin placement will be a fairly complex task that requires a good understanding of hydrodynamics, and so controls for rolling wouldn’t feel out of place; or maybe it, and the hydrodynamics system, will be fairly simple (in which case fins won’t be as necessary unless there’s some other reason to add them, which I don’t think is ideal)
Maybe 3D movement could be implemented with support for rolling for now, which would be a useless (but fun) feature, and when fins and hydrodynamics and such are implemented we can see how fun and intuitive it is to roll manually, and if it isn’t then it can be made automatic? (afaik manual control would have to come first because rolling would need to have an effect in order for it to need to be adjusted for any reason)
Also yeah, I don’t think I’ve heard many people mentioning a “crouch” button but I think it’d be a useful feature. I mean I dunno how useful crouching would be in this game, so I’ve always imagined it as more of a sneak button that makes you move more slowly and quietly, letting you somewhat fine-tune your movement and sneak up on prey. Having 3 modes of speed (sneak, normal, sprint) also kinda takes care of the suggestion of controlling thrust without introducing something like a power gague.
If it’s ctrl though, and “sneaking” (moving slower) is allowed underwater, then space and ctrl can’t be used for vertical up and down movement, so maybe R and F would work? But I feel like F would be a good key for an ability so maybe space and C? And also maybe the “move downwards” key could be used on land to actually get down on the ground and crawl? That way space and the down key correspond to moving up and down in whichever ways apply, whether you’re on land or underwater, jumping and crawling or moving up and down respectively, which I think would be pretty cool and intuitive. It seems like it’d be weird to have different keys for moving slower and crawling though. Maybe you could hold sneak and crawl at the same time for maximum slowness, but holding ctrl, C, and using the WASD keys isn’t exactly comfortable. Maybe C could act as a toggle for crawling? It wouldn’t work well as a toggle for moving downwards underwater, but maybe it only acts as a toggle while you’re on land and can crawl, and when you’re in water you have to hold it down to descend (if you have the capability)? I dunno if that would feel good, or if the switching between toggle and non-toggle is too jarring.
I have mulled over this debate for quite some time now, and I suppose I might as well go ahead and present my views. I’ll list both of the main ideas we have and provide my thoughts and opinion on both of them; Referred to as “Immersive” controls and “accessible” controls.
I will almost always value accessibility over full immersion. Thus I’m rather biased towards more simplistic control schemes such as the one I had initially proposed. The primary idea of which was to encompass all of the most basic and primary needs of 3 dimensional travel without immediate and sudden complexity when implemented. From there, we would hypothetically have room to improve and expand the control scheme as needed. It’s also worth mentioning that this control scheme can easily be adapted between aqueous/aerial/terrestrial environments without significant change.
In essence, this scheme is an importation of the microbe controls into the 3D medium, largely unchanged save for the addition of methods of controlling elevation. I suppose I should elaborate and say the standard keys as I envisioned are;
W&S: Moving forward and backward relative to the cursor position.
A&D: Strafing left and right relative to the cursor position.
Ctrl (Or C, not really set in stone right now): Descend/crouch.
The controls are quite straightforward and should be familiar to many players.
Smoother transition between stages
Largely Consistent between environments
Familiar and simple to understand
No fine control of organism, may feel more rigid
Movement may feel less immersive, more FPS-like
I understand the appeal of this proposed control scheme, as I suspect it would present a more engaging movement style and greater range of control for the player. However I fear that it might present a steeper learning curve for players unfamiliar with them.
(Controls elaborated by Nunz)
Wider range of control over organism movement
Works well with physics-governed motion
More immersive and engaging experience
Steeper learning curve
Might be a rougher transition through microbe and later stages
Personally, I prefer the accessible scheme, as it is much easier to pick up. Many of our players may not be familiar with flight-sim-esque controls. It should also smoothly translate into later stages that as of now seem to take on a strategy-game style. That being said, I understand that control schemes can be heavily subject to preference, and I am willing to compromise with presenting the immersive scheme as an alternative control alongside the immersive if it is insisted upon.
In regards to physics-governed movement (Such as pivoting and spinning to turn and control yourself), players would have to learn or know how to specifically steer their organism at the appropriate times as it is designed, and master that in order to stand up against the AI that will presumably know how to steer themselves from the get go. This puts players at a constant disadvantage. My suggestion is that these maneuvers be an automatic function for use in the accessible control scheme, so players will only need to worry about design, and not having to learn how to fly their design as adequately well. Again, this will be something I am willing to compromise with, through the addition of an “advanced” control scheme.
Finally, I should mention that I am sorry about putting the control schemes in the GDD prematurely. I was excited to fill it out as it is largely incomplete right now.
Not only did I fail to properly discuss the controls beforehand, I also presented the alternative “Immersive” proposal inadequately which I feel may have lead to some misunderstanding.