Control Scheme

Gameplay
1

So before the team I mentioned this idea on the Community Forums, but I figured I might as well post it here, especially now that I have a (decently) working system. As you know you control the microbe orientation by moving the mouse, which in the last version felt very awkward, and I felt it might feel better if I used A & D to turn left and right. Of course this potentially conflicts with different environments, so I’d like to break them down just to talk about them.

First we have to define our movement environments. I would say there are 3 basic forms. 2D (current microbe stage) 3D (ocean and flying creatures), and 3D constrained (most land animals and bottom-dwellers). Next there is the question of whether the movement is absolute or relative. Right now our microbes move relative to the orientation, ie. moving left will actually move you towards the right edge of the screen if you are facing downwards. If we create a pseudo-pod creature then it might make more sense to get rid of orientation and instead have absolute movements and rotation. That gives us six possibly different movement schematics.

How might these work using the mouse to determine orientation?
2D-relative = current control scheme
3D-relative = choose direction using mouse and w to move that way, s back, a left, d right, and space and left_shift/control for up and down relative to your up and down (for instance if you are upside down space would make you go towards the earth)
3D constrained-relative = Minecraft controls
2D-absolute = this would likely be very confusing as wasd would move you in a direction while the mouse simply rotates without any clear indication which direction you’re facing, then again maybe not
3D-absolute = wasd move you along the x and z axis with space and shift controlling movement along the y axis, mouse lets you look around
3D constrained-absolute = same as previous

Now with a keyboard based control scheme (at least as I envision it, the mouse is still useful)
2D-relative = w and s control forward and backward movement, a and d rotate left and right, q and e move left and right (in the way that a and d currently do), mouse is free for other things like targeting
3D-relative = w tilts forward, s tilts back, a rotates left, d rotates right, q moves left, e moves right, space moves up, shift moves down, and two other keys (perhaps f and b) move forward and back, meanwhile the mouse lets you look around without changing your orientation
3D constrained-relative same as previous but w moves forward and s back
2D-absolute = same as 2D relative but maybe switch q and e with a and d
3D-absolute = same as mouse controls
3D constrained-absolute = same as previous.

If you want to try the control scheme I created, here’s a link to my fork and branch that I created for it. https://github.com/trackman1997/Thrive/tree/alternative_control_scheme

The two files changed are player_microbe_control.h & player_microbe_control.cpp

2 Likes
2

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.

1 Like
3

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.

4

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.

5

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.

2 Likes
6

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?

2 Likes
7

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.

8

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

1 Like
9

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.

10

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.

11

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

12

It feels a bit too rigid and sticky right now, but it’s something I’d like to see expanded upon.

13

Where did you get the test from? Also exactly in what ways does it feel rigid and sticky? It’ll help in fixing that.

14

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.

1 Like
15

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.

16

The oscillation issue with the torque turning method needs to be resolved before it is usable.

2 Likes
17

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

3 Likes
18

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

discuss

19

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.

1 Like
20

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.

2 Likes