hurlvr-blog

[hurlvr-blog]

Helping players out

Heya, Petras here with another insight of the development processes of Hurl VR. Let’s get started!

One of the features we are proud of is that gameplay is affected by players physique. That gives every single player a bit different gameplay experience! It also creates really specific corner-cases which makes some puzzles a bit harder for one group of people (e.g. tall players) and other puzzles gave mire challenge ti other group of players (e.g. weaker throw). Even though playtesting with a diverse group of players reassured us that the game can be finished by anyone we decided to make some kind of help available for more casual or impatient players.

We wrote down some ground rules: 1. Player is in control of using helps. They are absolutely  optional. 2. A help only solves a part of problem, it mustn’t be get-away-from-puzzle-free card. Even while using help player is required to interact with a puzzle and complete the level. 3. Helps must be given as a reward, not out of pity. These rules gave us a good direction and we knew that if we manage to come up with a system that pleases all the points it’s going to coexist with main gameplay perfectly.

First line of business was coming up with help mechanics. In order to make helps fun, engaging and non gameplay-nulifying we constantly reminded each other and ourselves about our second rule: help must only solve a part of the puzzle player is struggling with, not the whole puzzle. We analyzed recordings from playtesting and found several key areas that players could be challenged. We boiled it down to main three: 1. Players doesn’t manage timing when moving platforms are involved. 2. Players doesn’t figure out a sequence they have to hit platforms. 3. Players doesn’t manage to hit the goal even if they know the right sequence. Knowing what we were solving made coming up with solutions quick. We ended up with these helps: 1. Moving platform slow-mo. • Gives players longer time-frame to throw the ball at the right moment. • Doesn’t reveal puzzle solution. • Player still has to make a right throw. 2. Ghost trail • Draws the path of where the ball should travel. • Player still has to account for timing if there is moving platforms. • Player still has to make a right throw. 3. Magnetic goal • When the ball gets close enough to a goal it gets sucked in from distance. • Player still has to account for timing if there is moving platforms. • Doesn’t reveal puzzle solution. In the end we had a well balanced helps that even when used keeps the bigger part of challenge and only helps player in the area he needs the help.

Then came the time to decide when we want player to get those helps. Coming up with the perfect system was a challenge. At first we got a feeling that the rules we decided upon was too of a creative restriction and everyone secretly hoped to throw at least one of the rules out. What seemed like a system we could come up with real quick ended up being a full week of meetings, brainstorming sessions and nervous walking in circles.

Throughout the week we come up with several ideas, but it either broke one or more rules or was completely incompatible with our design philosophy. Here are couple ideas we throw out:

Player Monitoring Idea: Track player’s progress and activity and from gathered data, variables and flags offer help when it looks like player needs it. Why it’s bad: Lets look at a possible situation. If the player is stuck on puzzle for five minutes, have thrown countless balls and doesn’t get anywhere near the goal we would make an assumption that player needs assistance and we would give the player help. The thing is that we would be giving help to players that struggle and they would realize it, which could possibly give them negative feelings and make them think that they suck and we the game is helping him out of pitty. It would also restrict player ability to freely choose when to use the help and pressure player to use it instantly. Rules 1 and 3 broken, it’s a no go.

Constant stream of helps Idea: We give a new help after each puzzle is beaten. This is the idea we were considering the longest, mostly because at the time it was the only idea that didn’t break any rules. Why it’s bad: Even though it didn’t break any rules it undermined gameplay in other ways. First of all it made beating puzzle less rewarding on it’s own, now the reward was not progression and feeling of accomplishment, but a disposable almost no value having help. Originally we wanted for player to feel that the experience he got was a reward on itself, but handing out shitty ‘physical’ rewards completely took that away. What’s more we realized that if we hand out helps after each puzzle players that has no problems will be banking on helps they don’t need, and players who performed worse would use the help they get immediately and have no way of getting more helps when they would really need it.

But based on probability theory the more bad ideas we had and the longer we brainstormed the more chance we had to come up with something good. And we did.

Achievement hunter Idea: Give players help when they unlock any one of achievements. Why it’s good: Achievements have a lot of diversity and that diversity worked out for us in such ways we didn’t even thought of. First of all we can distribute helps in the manner we like. For example we wanted to introduce helps as soon as possible so players would know their options, but we wanted them to get the idea that help is not always around the corner. Therefore we can introduce an achievement for beating first three levels, right after player has a good sense of throwing mechanic. Now player has one help and we want to push him to use it. We can do it by hinting to achievement ‘use two helps’. The idea of progression and a sense of reward influences people to try the help out, even if it’s nit that helpful. After that we want to let our player know that he might not get helps frequently and he has to use it strategically, therefore the next achievement is for throwing the ball 50 times, which should hit around level 6. But this achievement also lets player know that he can not only get helps organically but also work for them if he really needs to. For example he could go back to level 1 and play five levels in a row with 15 throws or less. Achievement based help giving out evolved gameplay in a way we were not expecting, now playtesters had more fun, they started analyzing achievements, trying to solve puzzles not only with optimal solutions, but in other cool ways too. Finally it gave players one more thing to be excited about and it didn’t undermine the joy of beating puzzles.

So… That was our journey of thinking about the players needs and how we could help them out! We definitely were not expecting such a ride but we learned a lot. Hopefully after reading you learned something too!

Keep on deving! Petras Malinauskas

[hurlvr-blog]

Hurl VR Devblog #3 - Platform philosophy

Early in development, right after we got throwing mechanic right it was time to introduce something to be thrown at. Duuh. Because we didn’t have any experienced level designer we had to “train” one, therefore our goal was to make level building, prototyping and implementing as fast and smooth as possible. That’s why we decided to throw out conventional level and environmental design guidelines.

Instead of creating environment we decided to create a playground for our mechanics: abstract, seemingly empty space. It had two purposes: set the mood and to seamlessly integrate and justify physical gameplay elements existing there. In order to populate our playground we had to come up with a simple yet effective building blocks that could make our empty space look full. Also we wanted those building blocks to act independently in order to give us creative freedom and flexibility. And thus our building blocks manifested as actual physical blocks in game  AKA platforms.

From gameplay design perspective platforms worked really well for us. Mainly because at the very beginning of the game player has to, either by chance or some basic deduction, throw a ball at a platform in order to complete a level. Immediately player has an understanding that if he sees a platform he probably needs to hit it. The side effect of this is when player sees a new platform, even though the color might differ but it looks familiar and he already knows that it’s a platform and he needs to hit it. After throwing a ball at the new platform he instantly gets the response, e.g. ball is pulsed away from the platform with a huge force, thus teaching player a new mechanic without any tutorials or pop up messages. This learning process that player unknowingly goes trough lets us to introduce new mechanics and gameplay varieties rapidly without breaking player’s immersion or slowing down game’s pace.

Another thing that we had really clear idea on how our game should work which makes brainstorming and implementing new ideas easy. Basically we have one rule: when you hit a platform something should happen to the ball or game field. Because platforms are independent from other platforms or gameplay itself implementation is quick. New mechanics can be planned out, prototyped, fully implemented and tested in one day. In the end it worked perfectly for us. By making level building fast we were able to learn about level and puzzle design at accelerated speeds. It also enabled us to use our newly gathered knowledge and implement fixes to previously made levels and new ideas to upcoming levels quite a lot. So yeah... Some monday thoughts on what we are trying to pull off. Time to grab that coffee now.

Cheers!

[hurlvr-blog]

Hurl VR Devblog Entry #2 - Art of putting player up high

Hey folks, Petras here!

I’m one of the programmers and game designers of HurlVR and today I will be shedding some light on good practices in VR. Most of you probably know that even though the workflow of making VR game doesn’t differ that much from making any other 3D game, there are a lot of new rules you should follow. One such rule is “do not move a player in any way if player is not moving himself” and I can’t stress how important it is! 

Of course, there are some hacks to go around this rule, Valves “The Lab” did a good job with teleportation mechanic, but in my opinion teleporting is a cheap hack (though the only one that works so far) and we decided quite early in development that we will not be using such hacks.

And because of huge “morality standards” on issue of using hacks at players expense we hit a roadblock. One of the games goals is to awe player and give him that “holy cow” feeling constantly throughout the game and we decided that putting player out of his comfort zone is one of more effective practices while trying to achieve that. And what is the best way to put player out of the comfort zone if not putting him up far of the ground on a small 2 by 2 meters platform? We thought it is going to serve our purpose quite right and open up new game mechanic possibilities so we rolled with it.

One of the main mistakes game developers make on their first game is moving player, either my animating the camera position which gives the player trippy and unpleasant experience or instantly putting them where they need to be. Both solutions are terrible in my opinion as they quickly throw player out of immersion. And even though we knew it back then this knowledge we possessed didn’t help us much. My first instinct was to just move player and the platforms he is standing on up slowly in non-violent matter. My reasoning behind it was that player has a reference point under his feet so elevation doesn’t mess with his brains. Wrong. Even though platform I was standing on and moving with me helped a bit I still felt uneasy and the uneasiness was not coming from my fear of heights, instead it was from my brain saying “Yo man, sorry for bothering, but something doesn’t add up…”. One could think that this kind of minor uneasiness for a short period of time could be forgiven, because the effect of standing so high on such a small area was extraordinary. Well, we didn’t have that guy in our team so we had to make it right.

We realized that we are cheating and bending our own standards by moving player. We scrapped the idea of elevating player and decided to give a feel of height in some other form. Due to a very forgiving and sandboxy nature of our environment we could mess with it in any way we wanted and the solution quickly presented itself: why move player, when we can move the blocks that make up the environment? New plan was set in motion. But somehow I missed the fact that moving all the environment down while keeping player and platforms he is standing on visually gave the same effect as moving player up. Why so? Because we are moving the main reference point our players use! It was freakin’ horizon! And our final solution came: we won’t move player, we won’t move horizon, we will just put a nice-looking hole around the player!

We knew that punching huge hole around the player will solve all of our problems from game design point of view. Now I had to make it reality.

Technical stuff from this point down!

Given our environment was made from voxels made me think that my new task would be quite an easy ride. What pushed my belief that this is quite an easy task was a plugin I used called iTween (it is amazing, if you don’t know what it does, stop reading and check it out immediately). All I had to do is calculate voxel position from the center of the world. Closer voxel was to the center lower it had to descend. Also I added some randomly generated numbers, so each voxel descended after random delay and moved at random speed. The idea behind the randomness was to add an effect of ground crumbling around the player and revealing a hole in a nice manner. Sounds pretty easy? Haha��� Well, it was easy and it worked. But no good thing comes without any sweat. Even though my solution achieved desired result and looked amazing it also made my buffy PC run like a cripple. Reason: 1521 voxels where calculating their position every update using pretty heavy math. To my disappointment this solution was a no no.

I knew that in the end I will have to choose either good looking or good-performance solution. Performance solution would have been disabling all dynamically moving voxels and putting big plane with tiling voxel texture in a way that a hot-swap would be seamless and lower the plane. Well, performance was intact but the result was quite cheap looking cubic hole. After going back to drawing board and making a love child of both solutions I got a pretty good idea on how to proceed.

Preparations included making uneven relief from voxels underneath a field of dynamic voxels and making them static. This was how the hole relief will look after all the descending animations finished. Then hot-swapping dynamic voxels for similar looking plane with tiling voxel texture and finally moving the plane down. When the plane reached static voxels underneath it looked like when voxels in plane reached desired position they stopped moving with other voxels and stayed in place. It was like stamping hole in place.

The final solution looked pretty, didn’t have any impact on performance and didn’t make player sick from motion. Huge success!

I really hope that this texty babling was of any use to you dear reader, cheers and have a good one!

Petras from Rusty Oak

[hurlvr-blog]

Hurl VR Devblog Entry #1 - The Intro

Hello world! We are a team behind Hurl VR (hurlvr.com) that is based in far-away reaches of Eastern Europe called Lithuania. Only recently we were able to realize our biggest dream – start making games. It didn’t start all well and pretty of course, but hey… for whom it does?! As any newborn studio we had our ups and downs (and oh boy we still have them). Please allow us to share our little story of reaching our current state of development of Hurl VR.

With virtual reality emerging rapidly (and being huge futurists ourselves) we simply couldn’t miss a chance of making something of our own. We’ve started messing around, trying to explore the unexplored, thinking of something that would be within reaches of our skill to pull off and still unique as possible.  After some time one of our developers came up with the idea of this futuristic minimal environment that would serve as physics playground. He crafted a couple of levels with some platforms that would serve as landing pads that a player would need to hit with a ball in order to achieve the goal. The result was somewhat futuristic and very minimal ball throwing environment. Cheers of naïve and unspoiled joy echoed within our office.

But yet, something was still missing. It was the detail, the vibe. We wanted more. We wanted to give more than just one purpose to our game. For it not to stand as a single short VR experience, but to truly immerse player and send a message, both visually and story-wise. To our sadness most of VR experiences seem to lack decent narrative, and that’s something we want to deliver in our own creations. So eventually we’ve started working on our story, thinking of ways how it could be presented to player without overwhelming him/her or distracting from the visual side of VR experience.

After having general arcs of our story (sorry no spoilers) it kinda felt that the tale we wanted to tell dominated the visual side of the game. The game’s looks started to feel very-very plain. And that’s when after some time spent banging our heads against concrete, we’ve came up with something we all would like and agree with – the new aesthetics of our game.

As you can see we went towards more classic retro-neon vibes in highly surreal setting. We’ve managed to build our environment in a way that it could morph into new levels, which became the main pitch of the game. Moving platforms that would feel alive could later be manipulated by player, levels would morph into each other while new mechanics and challenges would be introduced with them as well.

And so after hours of debating, testing, failing and repeating, we’ve found ourselves making a full length VR game, that would implement tons of different mechanics, have immersive narrative that would accompany the gameplay and would have badass (by our standards) looks. There was one problem though… VR experiences are designed to be short and not to overwhelm players too much with long gameplay sessions. So the question on how do we tell the story of the game in limited time without making player bored emerged. The answer came quick – chapters.

We’ve split the game into smaller sections consisting of 10-15 levels each. Each different in difficulty, complexity of mechanics and thus – more engaging and deeper storytelling. Currently we are planning 3 chapters with the release of the game and more downloadable (some of it free) content in the future is in the plans as well.

With that said I think it’s about time to end this entry and go back to work. We’ll keep on updating our devblog as often as possible. Next time expect more technical details and “how to” knowledge and of course more screens and videos of Hurl VR! Cheers! Devs of Hurl VR