This week I’m showing off my teleportation system, which is meant to complement the controller-based locomotion system I demonstrated last week.
I want to make sure Teleporting feels like a natural part of the game-world and to do that I’ve made the teleporter marker itself a physical object. You toss the teleporter-ball around and warp to it. In some ways it’s quite similar to other teleporter systems, but it does intentionally remove some of the player’s accuracy at where they land. It also takes time to throw and retrieve / cancel, which allows for some inherent cooldowns without an intrusive cooldown-meter or somesuch.
Players should be able to get around entirely with the teleporter, just as the could with the other locomotion, but I think the two systems are best when paired. Precise movement by pointing the controller and pulling the trigger, combined with longer-distance teleporters by tossing the ball from the other hand. Of course, one or the other would have to be put away to use any other objects, but that too is an intentional trade-off meant to encourage room-scale play.
The controller-based locomotion system I’ve implemented for OBSCURON has evolved from my old “System Sum” prototype, although I’ve learned quite a bit since last April. For starters it’s ground-based movement now and is fully physics-based too. It handles a variety of terrain and collision.
It’s relatively simple to use: Select the locomotion tool via the pie menu, point the controller and pull the trigger. You will move at a walking pace in the direction you point. It’s fairly low in chance to cause motion-sickness, which games like Onward have already proven: The trick is your intent by pointing the direction with your hands. It’s significantly more comfortable than head-tracked based movement. Once again motion-controllers are a good solution.
Despite the ease-of-use, it was surprisingly complex to develop this system. It’s taken a lot of trial and error, plus learning a few tricks over time. I’ll be advancing it further into a full parkour-like system, one element of which you can see in this video when I demonstrate sliding on steep surfaces.
I’m feeling ready to get back to full-time game development. After a bunch of VR experiments I’m re-approaching my “parallel play” OBSCURON concept as a shared world. It will be a VR adventure within a Sci-Fi universe, following themes similar to my previous prototypes.
Here’s a small start on my UI: a pie menu for quick selection of modes and equipped items. I’ll be adding inventory next, which can be dragged / dropped into these pie slots. Locomotion is the default, but that leaves three other equip choices per hand. Gameplay will be driven by items the players find / collect.
I’ve been thinking about Shared Experiences lately as a variation to the standard type of co-op that players expect in games.
I had a cat that always followed me from room to room, just to park himself down nearby. Occasionally he’d jump up on my desk to get himself noticed for attention, but most of the time he was comfortable just being nearby, doing his own thing. As soon as I walked to another room, he’d follow along.
My online friends are like that now. They seem happy to be within the same game world, but not necessarily on the same quests or tasks or level or whatever. Just nearby. Maybe in the same location, maybe just somewhere else within the same game. Enough of a shared experience to make it a water-cooler experience and to feel like the game-world is alive.
I wonder if that’s more natural?
When I think of the way people behave within co-op games, even amongst close friends or games that require close cooperation (IE: Left4Dead) there’s an urge to be the cowboy. To be together, but also to choose your own path, your own targets– Your own agency.
I’m going to try a gameplay experiment with OBSCURON where players will interact directly with a shared environment, but less directly with each other.
Things are still early at this point, so I don’t want to explain too much just yet. My plan is to primarily test gameplay and related elements, plus get a framework of the essentials (menus, data, networking, etc.) out of the way. Then test, expand, tune, test, repeat.