Hands

 Hands - an unreleased multiplayer movement sandbox

• So what exactly is it?

The concept is a pretty simple (though unique) one - rather than having a whole humanoid body to run around the world like most VR games, you are a hand. The game uses the hand tracking functionality of the meta quest to use your hand's movement to control your hand in game (I feel like I might end up saying hand a lot in this post...). You can scuttle along the ground like a crab, slap the ground to jump and make gestures with your fingers to the other players. The game provided a playground with a number of toys available, such as trampolines and jetpacks, and was planned to release with a tag game mode (though another football game mode was also finished). The 30s teaser trailer below shows the tag game mode, the movement (both jumping and crawling), the playground and some of the various customizations.

In my time with the game I worked on a number of the features, as well as general bug fixing and improvements (I also ended up doing a fair bit of organizing and moving relevant behaviour from blueprint to code, as the project's prototype roots were still very evident). The biggest feature I worked on was monetization and the shop, which I will produce a separate post for, but here are some of the others:

• Movement improvements

One of the reasons I was brought onto the project was my success with the Frenzies movement; at the time the Hands movement still felt quite unnatural; it was easy to accidentally send your hand moving backwards when you didn't want to, and there was no air control. I quickly managed to find improvements that made the game far more comfortable. For the grounded movement, I discovered that there was some code to detect when the player's fingers were moving in circles, and give them a boost forwards or backwards depending on the direction. However, the backward motion was triggering when it should have been, and was also unnecessary because of the mesh collision itself; straightening your fingers would naturally send you backwards. I removed the backwards boost and tuned the forwards boost to feel better.

For adding air control, the solution was simple enough; while airborne, a force should be applied to the hand upwards from the back of the hand. This produced a glider-like effect, where you fall a bit slower if your hand is flat, but can tilt your hand to move slightly forward, backwards or sideways and control your jump arc. After tuning, this removed the feeling of detachment when airborne that was there before. I also fulfilled a design request to make your hand fall faster when you make a fist gesture.

• Progression

The other big reason to bring me onto the Hands team was my experience with the progression system in Frenzies. The team wanted the ability to have challenges that players could complete, allowing players to unlock badges that they could show off. To do this, I had to both implement the challenges themselves in gameplay and hook up the backend to track progress for players and award badges when completed. My experience with Frenzies made this easy, and I quickly set up a subsystem to control progression, sending stat updates using stat keys and listening for challenge completions. Once I had a system that could support arbitrary stats, all I needed to do was implement the specific challenges (for things like traveling a certain distance or scoring a basket with the basketball in the lobby) and call the increment stat function in the subsystem when a stat was increased.

• Live-ops support

It was decided that Hands needed some more control over the game post launch. For example, rotating which maps are available each week, changing which toys appear and being able to update a giant screen in the lobby, all without needed a new build each time. After a very productive meeting with the design team about what they wanted and how I could give it to them, I got to work.

For maps, toys (and also in game skins at this point, though that later moved to the in-game shop), the solution was to use Epic title storage. This is a system where documents can be stored related to a specific stream of a game, and then requested by the game. Using a simple JSON format, keys for which maps/toys are in rotation can be sent and decoded into an array, then the game server can cross-reference those keys against data tables to find the right assets to load. I also added a class of spawn points for toys with keys; this made it possible to control not just which toys spawn from the JSON, but where they spawn as well.

Updating the jumbotron screen was even simpler, because the in-house backend already had a service that could send out notifications to clients, including images. Although the system was originally created for news notifications, it was made flexible enough to support my purposes. On the client side, I created a notification system that would work not just for the jumbotron but for any other future uses too. Using an interface, notification handlers can be registered with the subsystem, and will be updated with the notifications when they register or when a new notification arrives. But obviously you don't want irrelevant notifications going to the wrong handlers, so I added in a simple tagging system; each notification and each handler has an array of tags, and the handler will only get the notification if there's a shared tag.

The cannon is one of the toys that could be spawned from the title storage without requiring a game update

• Hands as a project

I worked on Hands for around six months, and it was really interesting working on a project with such a different style. The studio, Compass (now also planned to close), was based around making prototypes quickly. This meant there were two key differences to Frenzies, firstly a smaller team and secondly the project was focused on getting things working in the short term, without the long-term thinking that Frenzies possessed throughout its development. I really enjoyed working with a close team, but although having a less rigorous project had its advantages, I think I tend to prefer creating robust systems that will take into account future uses rather than only thinking about the short term!