Yes and no. WMR can use it through SteamVR. But Freedom Locomotion was built in a version of Unreal which had a hand flipping bug - a 50/50 chance of loading the left hand as the right hand - which never posed a problem for the Vive due to the symmetrical nature - but will do for the WMR controllers which are asymmetrical and mirrored copies of each other.
Recent community posts
Thanks Mikekan13. At this time, it's still a while a way to be honest - various issues (including business development) has taken my focus away from plugin development. It's quite probable that I'll be detouring from plugin development to making a game out of it first, so that I can fully understand the sort of issues that one would face in a real development situation - ultimately making for a cleaner, more robust plugin when it's released.
At this time, the VRTK is still a great go to for Unity VR developers, and it features an in-place locomotion solution as well (albeit with a different feel to the one in Freedom Locomotion) - which should serve as a good base to experiment upon! Good luck!
Thanks for the kind words Tadd.
I've been continuing to work on the functionality in response to feedback from users; including the climbing stuff (much more robust now, not so easy to fall inadvertantly).
I've been planning various strategies for getting the broader VR industry to take notice - most devs have their own idea of what constitutes a good solution to their problems at this point, so best as I can figure, I'll need to put together a package that can ably demonstrate the versatility and usefulness of what I've put together here; preferably in the form of a fun (actual) game that can gain some traction in the media.
Thanks for the suggestion. Having tried a blink flip solution like you suggest... it's super disorientating. You touch/open the door, and then it blinks, and then you're looking at the other side of the door. Except because you haven't spatially reoriented yourself, it just feels like you're staring at a different door and you've teleported to some non-contiguous location.
Easiest solution... as crude as it'll be, is probably just allow doors to swing both ways, so you can open into it.
Hi intraVRt, thanks for the review and the kind words! Much appreciated!
A note about hand selection... for this particular demo, both (hands controlling movement) is really the best way to go - as it lets you use either hand to specify the direction. So you can grab a gun and a sword in both hands, and then when you're running around shooting, you can use the hand grasping the sword to direct movement... but when you close in and start swinging the sword, you can use the gun hand to direct motion. There's a few minutes of learning curve involved there, but it's very natural once you get used to it.
I only actually have hand selection in there for the 'secret' teleport function I've left in (you access it with the off hand, and it works in most places, not all though... although now that I think about it, this might only work on the Vive, so I'll have to double check that). Also it's intended as a way to show other developers that you can use locomotion on one hand, while retaining the other touchpad/thumbstick for buttons and other functions that developers might want to use that part of the controller for.
I've been working on polishing up and also adding a number of new features. Hope to get a major update out in a few days or so.
With regards to motion sickness reports from users using CAOTS - I still get some, but I also get more reports from users saying that it really does work for them (they get motion sick in sliding experiences, but not in this) - showing that this really is a pretty effective solution for many users.
The real intent though is to provide VR with a solution that can allow everyone to use and engage in continuous VR locomotion, so that's why there's dash step and blink step... and soon I'll be adding more, including sliding and an option for proper hybrid-armswinger/CAOTS (as opposed to right now where swinging your arms only helps add more speed at a jogging/running pace).
Once I'm done on feature development, I'll be turning this into a plugin that initially will be accessible by Unreal developers, and then for Unity as well; where VR developers can then build on top of it to make their game. Unfortunately, this also means that it's not really suitable as a mod - so it won't be plugging into existing games and solutions.
Finally, this demo is also available on Steam if users prefer to download from there. Just google for 'Freedom Locomotion Steam' and it should pop up right away.
Hi d3lux3, thanks for the feedback. Some good points in there, I'll definetly consider how to best tweak it during the revision process.
The small distance interaction is... tricky. A lot of it is me combining room scale interaction with 1.5m+ distance travel. If you're relying solely on Freedom locomotion for short scale movement, it does become less than ideal. Indeed, this stuff has become so second nature to me that the problem has largely become transparent to me. It's only when you framed those separate (but entirely related) elements like that, that it's clicking for me. So thanks.
The ideal is still to combine room scale and locomotion - that's when the system is at its best. And that's my intent for the door opening/closing - you get up to the door, and you pull it back, taking a step back in real life, then walk through the doorway, again in roomscale. It's a pretty fantastic feeling. On the other hand, if you don't have the physical space to step back as you pull the door open, then yeah, absolutely I can see how it's a not the best way to deal with it! Perhaps a button to the side (like with the dev notes) to open the door automatically so you can stand clear of it.
With that said, the last point you mention is already in there (albeit as an undocumented function) - by switching to the left or right hand for locomotion, your secondary hand turns into a teleportation function. Doesn't work everywhere, but it works in most places. I think there may have been an issue with the rooftop level that prevented teleportation - I'll have to double check (I generally don't use it as you might be able to tell).
I think in general, up/down motion is tougher for many people, so I'll definetly have to design alternative movement mechanics for those sorts of areas (e.g. push button teleportation).
The Steam and Rift release is taking longer than expected due to some learning pains. But it's available to select users now. Let me know if you're interested. Contact me via my website to take me up on the offer. Cheers.
Thanks for the detailed feedback! Much appreciated. Good news is the Rift update is pretty much done. Just some final testing and upload. Going to get it up on Steam as well, so I'll have to go through that process too.
But yeah, all the things you've identified are reasons I told people that it wasn't compatible with the Rift (but I didn't take action to lock out Rift users explicitly).
The Rift version is every bit as good as the Vive version now; if not better, because of the analogue stick - so hopefully when I get the update live in the next day or two, you'll be able to go through it again and give me the same level of detailed feedback there! :D
Thanks for trying out the demo, and for the kind words. The feedback is much appreciated. In response to your questions/points
1. Unfortunately, horizontal head motion is fraught with its own issues; primarily if you read horizontal motion as forward vector motion - you'll be moved around inadvertantly when you're just looking around (with the movement active). It's what I started with, but moved away on, because it just didn't feel good.
There are a lot of options that can be tweaked to adjust the movement more to your liking... if it's the case that you don't move your head much, and thus keep falling below the activation threshold, in the version I'm working on right now (nearly done; just a bunch of UI work to update) I've removed the activation threshold... it just comes at the cost of rejecting some inadvertant head motion when turning your head - but it's fairly minimal, and I think ultimately improves the outcome.
I think the other thing I can do to improve the walking situation is to give an explicit walking video demo to show exactly the extent to which you need to walk/move on the spot to provide a good outcome. In my live demos, the instruction 'walk on the spot/in place' seemed to be insufficient for some people (while others understood right off the bat); mainly with people producing minimal or timid movement.
Ultimately, these issues tend to disappear once you've spent a bit of time acclimatizing and getting used to it... but this kind of feedback is valuable in helping me know where to focus to make it better *right off the bat*.
2. Yes, that certainly is a bug. I'll have to test it a bit more as you describe it - but I recently solved a problem very similar to what you're describing; hopefully that solution has caught the same issue you're experiencing.
3. There is some ability to grip flatter terrain (it's what allows for you to grab the ground while prone), but relaxing the angle too much essentially makes everything climbable. Which isn't a terrible thing, but it's also kind of a 'game breaking' thing - not that there is a game to break per se; merely that I wanted to show that the system could have reasonable limitations. The angles and the rules of climbing can certainly be altered according to many different elements (e.g. a stamina grip system, equipment, etc). But I don't have specific plans to do it with this demo, because I wanted to focus it more on the walking/movement aspect.
Yes, the plan is to build it as a plugin for first the Unreal system and then the Unity Engine so that I can help get this functionality far and wide in VR. That said, I've had to deal with a lot of non-development work recently, so work has slowed down a bit; but hopefully the time I'm investing into the non-development side now will help speed up future development.
Hi Nismo Ny,
Tried your demo at your behest. It's very colorful and pleasant!
But the actual locomotion mechanics range from good to not so good.
The good is jogging movement is quite convincing. My locomotion is smoother in that the peaks and trough of speed aren't as extreme, but there's a niceness to the more direct motion from jogging.
Transition between speeds is quite good as well; I've tried a number of other walking in place solutions and many of them have been quite jerky between walking/jogging transitions.
Walking speed feels a bit too slow however.
Jumping is very spotty. I managed to jump twice in the demo, but I physically jumped around 10-20 times, so the height detection algorithm seems a bit off. Or maybe it calibrated funny (although it shouldn't have as far as I can tell).
As a result, I couldn't get past the twin pipe obstacles and left it there.
Perhaps have jumping on a button as an option - even if its likely to induce motion sickness, it's at least a work around for those that can't jump or can't get it working right.
Also, direction of motion gets wonky when you turn around as forward motion now becomes backwards motion.
I get that having it independent of head motion allows you to look around without causing motion in that direction... but without motion controller/touch support, it's the only real solution for a robust movement system... because I can't see walking in place becoming a widely accepted solution if it needs to be limited to tracks like this one (i.e. your solution works fine within the context of what you've presented, but you might need to consider how it can work more broadly).
It's a pretty cool demo - but to really take advantage of VR, needs to have motion controller support (if only to use it as the forward vector that's independent of head motion), and it should be... less track focused and allow for broader more interesting exploration.
Good luck with it!
That's disappointing to hear. I'm not sure why that'd be - I've been told the same by a couple other people - but I've also had thousands of user successfully download it... so my guess is it might be some sort of VPN issue with itch.io? I'm not certain there.
I've been working on an update to this for a while (things going slow due to non-development activity occupying a lot of time), so will be releasing a steam version of it soon - hopefully within a week or so.
Will post here and on the social media channels (reddit/twitter/facebook/etc) when I've uploaded the Steam version. Thanks for the interest!
Thanks for the feedback. Glad blink step worked out for you.
As for the suggestion - I'm aware that there are a few other games that employ a scheme similar to what you're describing (e.g. Technolust), but through my own research and testing, it's not an ideal scheme for most users, because you lose a great deal of the flexibility of movement... moreover, most people don't expect motion to be stuck in one direction, but follow their bodily direction of movement.
The main thing I'd suggest if you know you can get nauseous easily from non-forward movement is to keep your hand by your side, aligned with your torso. This should be easy as it's essentially the default resting position for your arms when moving. Also there's an option for 'Simple Touch', which rejects the thumb direction and only uses the controller direction.
This way, you're only moving in the direction of your body - but retain the flexibility to turn and move without having to stop and start.
For more advanced users, simply moving in a manner that roughly indicates their intended direction of travel is sufficient to help further reduce motion sickness (e.g. if I'm moving sideways, I mimic a motion for strafing, or if I'm moving backwards, I mimic a motion of backpedadling).
As for the elevation issue - it's a difficult one to deal with outside of teleportation/blink stepping. I think a reasonable compromise is to make elevation changes optional by allowing players the ability to teleport between the different levels, or to reduce the amount of elevation changes in general.
I assume you had the comfort mode on high?
Thanks for the feedback. How'd the dash/blink step testing go if I may ask?
CAOTS has a lot of mechanics that help reduce motion sickness for a wide range of users... but it's not a bullet proof solution unfortunately. That's a large part of why dash and blink step are included in the first place. But at the same time, I think it's capable of slowing the rate at which people get motion sick - such that people can reasonable use it to build up their motion sickness resistance over time, especially if they're mindful and avoid the actions that are more likely to cause motion sickness... although this too isn't a perfect solution by any means - given that resistance can go back down over time if the user doesn't continue using VR on a regular basis.
You can actually mimic the 'walkabout' solution featured in cosmic-wandering in Freedom Locomotion VR - by using the grab turning functionality. To activate grab turning, you hold down grip and press and hold the touchpad. The camera then rotates along with the position of your hand, meaning that you can walk from one end of the room to the other - grab turn, keeping your arm by your side, turn around physically, and then let go of grab turning. You end up facing along the same direction on the path in VR (much like the cosmic wandering system) while having the full extent of the room in front of you to continue walking. Repeating this process allows you to walk physically in a much larger space then you'd otherwise have access to.
Indeed, it's actually a better implementation of that sort of system in my opinion (even though it's only a secondary intention of grab turning) - because instead of locking the view to your head, it locks it to your hand, meaning that you can continue to look around freely while turning around, which is useful for seeing where you actually need to turn to next without actually affecting where you'll end up turning to, which can feel quite disorientating.
Despite all this, I don't prefer using grab turning in this manner - the frequent turns in order to cover any reasonable amount of space is both inconvenient and pulls you out of the immersion of VR - even though you get the benefit of actual 1:1 physical movement. This is because CAOTS is more than a good enough solution (at least for me) for covering both large and small distances in VR while still staying highly immersed without much motion sickness to boot.
Hi ch4r13 G0rd0n,
Glad to hear you liked it! I've had a lot of comments about the walking speed not been quite sensitive enough, but the users that have managed to spend a bit more time with it have ended up liking it, like yourself. But nonetheless, I've taken on board the feedback and have spent the last couple weeks tweaking a lot of details and have also added a calibration system - which means the system will fit your movement style as best it can without forcing the user to tweak until they get it right (although you can, and there are now more options to do so!).
I'm literally in the process of uploading that update, so hope you give the updated version a shot!
Thanks for the kind words! It's in my plans to bring this to Unity, but it's not something that will be happening quickly - not least because I actually have to go through the process of learning Unity as well. If I can find a pathway to accelerate development, then that'll be the way I'll go so I can get it out to everyone faster - there's a lot of demand for a full featured physically oriented locomotion system like what I'm showing off, so I'm working hard to fulfill that demand.
> I actually have been talking to friends and they have liked the slow movement, I might just need more time with it.
There are a fair number of options in the menu to tweak to your hearts content. 'Realistic' has been calibrated against my own movements - I measured the number and distance of steps it'd take me to cross my room and tweaked it to match the same with walking in place.
Having said that, I think the issue that many are finding with 'slow' movement (and probably effecting yourself) is that the system currently prefers exaggerated head motion when walking. The best way to achieve this is by essentially pushing off and landing on the tippy toes before allowing the heel to land on the ground. This produces a pronounced head motion which works well with the system.
The other method of walking that I've observed and tested myself is definetly much slower than intended (about 1/4 to 1/3rd of intended pace) - so hopefully the calibration changes will allow both users to enjoy the system at all motion ranges. Luckily, jogging and running speeds consistently produce sufficient head motion for all users.
Thanks for the reply. Excellent comments.
I've been working on remedying a lot of the issues you've described (as they've also been experienced by other users). The comment about the boundary walls is quite useful, and I'll have to have a play around with it.
I actually had the double click to toggle movement on implemented before, but changed it under advice from another tester. Having tried both methods, I think I prefer the touch to move option more; allows flexibility without adding additional stress to having to push down. I might actually merge the options into one unified - click to start movement, but lift off finger completely to stop as the default. That way you don't accidentally trigger movement, but you don't have to grind your thumb into the touchpad. I'll see how user feedback goes.
The climbing is something I've been working hard on - both in conveying when you can climb and in communicating to users how to climb. The long and short of it is essentially that you can grab corners to pull yourself around. You can also grab shallow inclines (like the top of a table, or the top of the Huge Robot foot). Hopefully those changes will help improve how the climbing is perceived.
The slow walking locomotion is another issue I've been working hard on. The real challenge is that there are a variety of styles of walking in place, that a single default setting can't readily capture. So working on a detailed calibration system that will allow users to set it closer to their personal preference/style of moving right off the bat. For the people that it works for (currently), I've been told it's fantastic for all movement speeds though.
Hope to get an update in shortly.
Thanks for the interest. At this point in time, the system is only a tech demo to showcase the potential of these systems to both VR users and developers. I'm continuously working on it to refine it based on the feedback received, and once I'm satisfied with the functionality, I'll be working on refactoring and refining the code so that it can be released as an Unreal Marketplace asset that I'll be proud of. I estimate (very roughly) that this process will take 3-6 months. Unity support will come after that (or sooner if I'm able to grow my company faster than that).
Thanks for the feedback. Sounds like you've been affected by some of the bugs that I've been having difficulty tracking down.
Also are you using an Oculus Rift or a Vive? The Rift is currently not compatible (although I haven't specifically turned it off), but I've been getting reports of a couple users with hard to hit buttons using the Vive too.
That said, I've made a number of improvements to the climbing system based off feedback from others; hopefully once I rerelease/update, people like yourself will find it much more intuitive!
I'm not sure how to fix that - but I do know that Rift users trying it now will get a very sub-optimal experience.
Rift support is something I'll be working on for the Steam release (and I'll update the itch.io version then too if you prefer to download from here), and will provide a far better experience if you can hold off until then.