Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swinging arm locomotion #65

Closed
jtoktas opened this issue May 16, 2016 · 28 comments
Closed

Swinging arm locomotion #65

jtoktas opened this issue May 16, 2016 · 28 comments
Labels

Comments

@jtoktas
Copy link

jtoktas commented May 16, 2016

@thestonefox Thanks for your efforts, like many others i'm new to programming / unity and your template has made it possible for me to get started developing in VR. Thanks a bunch, a donation link somewhere would be great for us to thank you with dollars instead of just words.

I also came across this locomotion system for unreal someone is working on with swinging arms, looks interesting. Not sure if it would be useful or practical to implement in your template but if you find it interesting perhaps you can include it. https://www.youtube.com/watch?v=8PoKx0EUqRE

@thestonefox
Copy link
Member

@jtoktas Hey, glad the toolkit is helping you out!

I've seen that locomotion system, I tried reaching out the the developer behind it but never heard back from him :(

It's something I'll seriously consider implementing because it looks pretty cool!

@Tetralogy
Copy link

It is cool, but I have to be honest the way it is right now it just feels more like you're dragging the world under you rather than you moving through the world. I think it might have something to do with it being too smooth?

@thestonefox
Copy link
Member

Yeah I know what you mean. I like trying different locomotion techniques, teleporting works the best at the moment but would be cool to implement something more intuitive.

@bcoyle
Copy link

bcoyle commented May 18, 2016

Not a fan of the swinging arms locomotion. A few options for teleporting might be :

  • limiting the distance, and direction basted on direction controller is pointed. (Eg. Moving 5ft with every click) I've seen too many people teleport wayyyy off into the distance by accident
  • buffer from walls, so teleporting against a wall doesn't put you directly co planar with the wall.

@thestonefox
Copy link
Member

@bcoyle You should already be able to prevent teleporting next to a wall by using the play area cursor, that checks for collisions prior to teleporting and should never put your play area into a position where you can walk into walls (technically!)

@xEvoGx
Copy link

xEvoGx commented May 18, 2016

You know I like the play cursor idea a lot, but it doesn't help you navigate spaces smaller than your room space (I'm lucky to have 9 x 9 feet).

I agree with @bcoyle that having a non-fixed teleport distance is 'meh'. I'm already having to concede that I don't see conventional FP controls working in VR (nausea), so it's important, at least for me, to nail a system that's consistent and reduces the amount the immersion is broken.

FYI Vanishing Realms has a distance limited teleport, and The Gallery uses a time dilation if you will depending on how far you teleport (character takes more or less time to blink to the new spot). Finally Spell Fighter has a neat idea that's not too dissimilar to The Gallery. When you click on a teleport spot, a translucent animated character 'walks' to that spot. Wherever that character is when you confirm your teleport is where you end up. So if you want to teleport a greater distance, you have to wait for the character to walk to that spot (he walks pretty fast regardless but you still have to wait or be teleported a shorter distance)

@thestonefox
Copy link
Member

@xEvoGx I like that distance affects fade, I can implement that quite easily I think.

I'll take a look when I get chance.

@xEvoGx
Copy link

xEvoGx commented May 18, 2016

Equally you might want to just put in a distance limiter.

Also I like @bcoyle 's idea of a buffer to avoid coplanarity with walls. Similar to your play area cursor, you could perhaps do a half-way implementation where you're checking the players current position in the play area, and then have a buffer of X units around the player to prevent them from teleporting too close to walls.

@thestonefox
Copy link
Member

There is already a distance limit on the bezier teleporter, which is the more appropriate teleport beam to use when wanting to travel limited distances.

The play area collider is a player position buffer already. Anything other than that won't really solve the problem, there's nothing to stop you walking out of your play area and walking through a wall anyway.

@xEvoGx
Copy link

xEvoGx commented May 18, 2016

No no we're referring to the fact the 'entire' play area has to fit to be a valid teleport location...

...what I'm suggesting is simply having an area that is X units around the actual player position regardless of the play area, so people can't teleport right up on a wall (this happens in the Budget Cuts demo). So effectively it's exactly like the Play_Area teleport, but much smaller! :)

@thestonefox
Copy link
Member

@xEvoGx Ok gotcha, I'll add something where you can set a varying size buffer that prevents you putting the cursor next to a wall.

@thestonefox
Copy link
Member

I think what I may do instead is allow you to specify the size of the play area cursor.

Have 2 values, x,z that you can determine it's size with, if you leave them blank then it is calibrated to the play area.

@xEvoGx
Copy link

xEvoGx commented May 18, 2016

Would that be centered around the player? What if he's at one end of said area?

That's why I was thinking having a Player_Buffer, along with Play_Area and Other.

@thestonefox
Copy link
Member

When you teleport you're located in the offset position of your play area if you have the Headset Position Compensation ticked on the teleport script. If this is unticked then your teleport location is always centered.

The player buffer doesn't solve the problem of being able to walk through walls, the only thing that's really solved is being able to teleport to areas where your play area is large and would create unwanted collisions.

Having the play area cursor smaller means it will provide a custom size you deem acceptable to teleport near walls whilst within the play area boundaries. Nothing to stop you walking through objects though or out of the wall. Best way to do that is to use the whole play area bounds (but still doesn't really stop you as you can walk out of your own bounds)

@xEvoGx
Copy link

xEvoGx commented May 18, 2016

Well you can't solve walking through walls beyond fading to black, which works wonderfully. If you want to take that a step further (no pun intended!), you could simply teleport them back to the last safe spot if they attempt to pass through geometry.

The only concern I have at that point is just not being able to teleport too close to a wall. It's one thing to intentionally try to walk through a solid surface, and another altogether when you blink right up on geometry that's completely in your field of view.

@thestonefox
Copy link
Member

I played with that teleport back to a safe location to resolve conflicts, it was really flaky, also depending on how levels are designed, nothing stops you just sticking your hand through a wall and teleporting anyway (I do this in budget cuts :p)

Hopefully the new custom size play area cursor will allow people to set smaller cursors to prevent teleporting next to a wall but giving enough room to still teleport around tight areas. It's live now if you wanna check it out :)

@xEvoGx
Copy link

xEvoGx commented May 18, 2016

Will do!

@thestonefox
Copy link
Member

@xEvoGx FYI, the distance affecting fade time is now in:
#68

@xEvoGx
Copy link

xEvoGx commented May 20, 2016

Awesome and my bad...I neglected to check out your last build. I guess I'm checking out the new one! :)

@thestonefox
Copy link
Member

@xEvoGx I also added another feature that allows the pointer beams to stay on constantly.

Someone asked for it so when they're in a menu screen the beam is always on and the button still initiates the selection, seemed like a good quick win.

@xEvoGx
Copy link

xEvoGx commented May 20, 2016

Yea saw that, sweet

@fznmeatpopsicle
Copy link

Oh yea, this locomotion. It looks pretty nice, and I'd love to try it in my demo.

I actually saw it here first. It's inspired by the one in the OP, but I feel it's much smoother and nicer

@thestonefox
Copy link
Member

Do you think these moving forward whilst standing still locomotion techniques will make you feel like you're going to fall over?

The touchpad walking one makes me feel a bit sick and I'm not moving.

@fznmeatpopsicle
Copy link

Good question. Maybe the act of swinging your arms is just enough to make a difference?

I can maybe anticipate that the version that the OP linked might not be the best implementation since it looks pretty jerky, with the distinct stop and start at the apex of the arm swings. I feel that the one in my link may feel better since it's a lot smoother. That said, I'd like to try both versions out before making any real assumptions.

@fznmeatpopsicle
Copy link

Okay, I've tried the version in the OP and while initially it felt weird because of the stopping and starting, I got used to it pretty quick. It does need work though. As said, the movement could definitely be smoother. It also needs some deceleration when you stop. At the moment it's an instant stop. This version definitely looks like it'll feel better.

@fznmeatpopsicle
Copy link

I've now tried both versions. The smoother version is definitely the better of the 2. There's a new updated version with a demo to try out. Apart from some speed tweaks, I definitely like it.

Overall, they're definitely less motion-sickness inducing than using the touchpad to move. Tricks your brain just enough, I feel.

@xEvoGx
Copy link

xEvoGx commented Jul 18, 2016

I was wondering if this idea has been tossed out? I still think it has quite a bit of validity, moreso after seeng frozenMeat's links from ChiefehTiger, where the motion is continuous rather than start/stop.

I didn't mind the run-in-place method but that could get fatiguing, and yea I too had bouts of losing my balance, so this version would be a pretty decent compromise methinks! 😅

@thestonefox
Copy link
Member

Will be resolved by:

#602

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants