Control Scheme


#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


Compound Rebalancing
#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.


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


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


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


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


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


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