The Virtual Frontier

Sound Design in VR

by Leave a Comment

At the end of the year I thought I’d take the time to reflect on a critical part of game design that can be very easy to ignore in the pre-production phase: audio. Specifically I want to talk about the importance of sound effects, as important as music and ambient noise are to the sense of presence and mood in a game, sound effects are pivotal in establishing clear and consistent feedback patterns to player behavior that helps “sell” a concept without solidly locking down a specific direction if the designer doesn’t want to.

For example, if someone was designing a first-person shooter and there were enemies spawning off screen to attack you, it would feel incredibly bad if you just started losing health and the camera started shaking every time you got shot. You wouldn’t know where the damage was coming from, or what was dealing the damage. However, with even simple sounds you could incorporate the sound of the bullets firing, the bark of the enemies as they call more friends, and even the footsteps and shuffles of those enemies getting in to position. This way a player can make inferences based on audio feedback that visuals are too limited to represent. And that is a very important note for not only the work I’ve been doing on creating tutorials for PuppetJump, but also VR game design in general. In a medium where almost every game is in first person, that means your ability to provide clean visual feedback is more limited, and audio has to be able to pull more weight throughout the project.

This came up as I was working on adding a timed section to the tutorials as a “final test” of sorts. Implementation was easy enough, and applying it to the UI was also simple, but I was having trouble getting across the idea that you were being timed in real time. My initial solutions were all visual in nature, and none of them were good. My first thought was having a static UI element on the screen, similar to a timer in racing games. I very quickly ruled that out, you want to avoid cluttering the screen and forcing a player to move their eyes independent of their head puts a lot of strain on a player that already has a pound of plastic strapped to the front of their face.

UI Example
This kind of timer works great when the screen isn’t 2 inches from your screen!

I wanted to keep the timer though, so I thought about having a UI element parented to the player, meaning it moves alongside the player, like one of those holoscreens in a scifi or superhero movies. I tried that, but took that out because of how distracting it was. It was very uncomfortable having something follow you that doesn’t have a direct anatomical analogue (like hands) or has an entire entity dedicated to it (like an NPC following you), and moving while looking at the screen was very disorienting so I imagine those with motion sickness may have a harder time completing those sections like that.

Follow Example
This works well for a third person view of someone looking at holoscreens, but being in the first person makes holoscreens much more uncomfortable.

Then I thought I could add a visual element to the hands, that way there wasn’t a sense of detachment from the player, but that felt antithetical to the overall minimalist design of PuppetJump’s avatar. If I took this clean, abstract hand model and slapped on an additional piece it would have broken the simple balance of the avatar. Maybe some day there will be a reason to expand upon the avatar, but for something small and specific like this? It felt unnecessary.

 

So I gave up. Thinking visually, that is! I realized if I wanted the player focus visually on one thing, but also be aware of another thing, I had to rely on a different sense for that. So I added sound! I added a ticking sound effect that gets faster as it approaches the end of the timer. Specifically I have one ticking sound play, then when the timer reaches the last quarter of its runtime, I have a faster ticking noise play. This was exactly what the scene needed! While I still have to do some work balancing the sound and I’m sure the sound itself will be replaced with a cleaner recording in polish, right now it provides the exact feedback I was looking for. Now a player can focus on traversing the scene while being aware at all times that they are under a specific time restraint!

All this to say that it is important to consider the user experience as early as pre-production and what kind of feedback you use in your greyboxes and why! Understanding how your visual feedback and stimulus may be limited and using other sense to either enhance or replace those visuals will help your game have a strong foundation initially, allowing an easier transition from greybox to alpha to beta to release. As with most aspects of game design, the more thought and work done to refine and establish the user experience early, the less time you’ll have to spend later redesigning something this intricate and specific.

Makeit Demonstration Application Postmortem

by Leave a Comment

Introduction:

At the beginning of summer this year, I was told that my department at TLT would be participating in an event called Makeit. Makeit was meant to be a conference/event in which faculty from around the different campuses would come together to explore new and available technologies and concepts in order to better understand them and think about how they could bring those concepts to the classroom and incorporate them into current pedagogy. Some of that new technology derived directly from XR, so as an XR developer I was encouraged to participate as a way to provide expertise on the burgeoning technologies from the development side of things. I thought for a couple days about how I could best articulate my opinions and knowledge about the technology and I came to a pretty obvious conclusion: I’m there to help people understand the development side of this technology, why don’t I develop an application and talk about the process and decision making that went in to creating the experience?

Conceptually, this turned out to be a great idea. The organizer of the event liked the idea of having an experience made specifically for this event, even if it was just for part of one of the talks, my boss liked the initiative I took with presenting this idea and using it as a way to have a more structured project going in to the summer, and I liked the idea of spending a couple of months on an idea and going through the entire development pipeline as a way to reinforce my current knowledge and analyze my current processes and techniques. Plus, I’d have a cool little deliverable at the end of this, so it was basically the chillest Game Jam I’ve ever participated in. A win-win-win in my book!

As I planned out what this experience would be, I laid out exactly what this experience needed to do. No matter what the main aesthetic/mechanical hook of the game was, I would need to be able to deconstruct it in real time, showing players the choices I made as a developer to make this an enjoyable VR experience. Since the goal was to highlight the differences that still clearly exist between physical reality and virtual reality, I would need to have clear checkpoints to highlight to the player when they were losing an assistance or comfort tool. Early on we identified a couple concepts that VR fails to replicate clearly when used, and I think they’re good things to consider for any designer/developer who wants to build a VR experience:

  1. Weight – A concept so simple I think a lot of people take it for granted. No matter how much weight you add to an object in Unity (or Unreal, or any other engine) your controllers will only ever weight about 4.5 ounces. So does your game account for weight when an object is being held? And if so, how? And, most importantly, why?
  2. Dynamic Intricacy- Currently, you don’t have hands in VR. You don’t exist as a fully fleshed out person in VR. On its most basic level, in VR you exist as three points in space (1 for your head, and 1 for each hand). And if your game has grabbing, then 2 of those points are sticky. So, when you grab an object in VR, you can’t dynamically sculpt your right hand to match perfectly with how you would want to grab an object. Physically, you are holding a controller that was designed to be held in one particular way, and virtually you can’t extrapolate a dot into multiple unique contact points. There are systems that allow designers to create poses that hand models can take when grabbing an object, but those poses are limited to specific contexts and are only approximations on how a person will grab that object. Do you take the time to create detailed models and intricate animations? Or do you abstract the hand to be a more generic object, like a sphere, or an icon? Originally I called this concept Precision, but I think that doesn’t really articulate the problem very well, and it makes VR sound worse than it is. The problem isn’t an inability to be precise, it’s a problem to dynamically replicate common intricate gestures given the current technology.

After defining these areas as targets or goals the application should highlight, I took the time to think of what activity (or set of activities) would work. Honestly the idea came pretty quickly, as my team had been creating blocks and dice for other demonstrations I thought “what if we had the player stack blocks, like little blocks they would’ve stacked in Kindergarten?” That’s a task that I thought any adult could accomplish conceptually and mechanically, as picking up a physical block of any size is easy when you have fully controllable human hands, but would be difficult to make feel right in VR, where you don’t have hands, you have two sticky dots. Additionally, it was recommended that I could have the players stack the blocks according to their weight, another metric that would be much easier to track physically than virtually.

Stacking blocks was also a repeatable, short activity I could have the player do multiple times in order to establish a pattern of recognition so they would notice when certain elements had been removed from the original scene.

First Iteration:

So here’s what the first iteration of the game looked like. I was able to get a quick prototype up and ready for testing. It included four scenes that broke down a bunch of the tools I was using to help the player for the first scene, that I was able to peel back in future scenes. So we can see concepts like PuppetJump Connectors being used to help a player (and the game manager) understand if a block was on top of another block, and also keeping the blocks together in case the player accidentally knocked over the stack, something I was particularly prone to doing. I also used PuppetJump’s standard systems for replicating/simulating weight, and also labeled the blocks so the players could visually identify and properly stack via weight in the first scene.

The original four scenes were focused almost entirely on highlighting the assistance tools (or their absence) so that a player would be able to recognize what’s been lost as they continue. I felt this was the most important aspect of the experience. As we tested this application we had some interesting results:

First, it’s too short. That might sound like a major flaw, and to a larger studio with more rigid policies around asset creation and time management that’s a major problem. But specifically for me, and specifically for this project, that was great news. This game was conceptually simple enough that creating new scenes was a great expansion of what was already working in my book. It’s not always a bad thing if your testers leave wanting more, especially this early in testing.

Second, progression is too simple. The game in its current state was hyper-focused on being able to identify the differences between each of the scenes, and the problem with that is this wasn’t a spot the difference game. In a metatextual sense it was, but textually it was a game about stacking blocks, so the block stacking still has to be interesting. Just doing the same activity with the same variables slightly altered every time wasn’t enough to engage anyone. I can talk about the themes and significance behind and I do find analysis to be important, but in order to properly analyze something, you have to digest it first, and for games, that means you have to play the game. It doesn’t matter how deep your themes are if your players don’t engage with the game on the surface level.

Third, the table was too short. This may seem like a fairly innocuous change. Just raise the table, but it led to my boss and I having a very interesting discussion on how the severity of the changes between your physical body and the current virtual representation impacts development in so many different ways. As you can see from the video, a waist height table becomes a real struggle to handle in VR. In our current framework, when you bend over physically, virtually you’re still just moving your entire body forward. So the table keeps pushing you back because like a bad speedrunner you keep clipping your collider into the middle of the table, so it keeps pushing you back out!

Fourth, picking things up off the ground in VR, especially small things, is a bad experience. Forcing people to bend down and then slam their hands into the ground while they technically can’t see it is not good. It’s why Half-Life: Alyx has the force grab flick feature with very forgiving hit detection when it comes to pointing at the objects. Puppetjump also has a force grab like feature, but I wanted to make sure players stayed focused on the table, so I would need something that automatically puts the blocks back on the table when they’ve been thrown off.

Finally, the UI was terrible. I originally had a plan to make the UI both more adaptive and non-intrusive, allowing players to move around the table and the position of the UI would update according to where the player was, similar to menus popping up on the peripheral in sci-fi movies. In practice, this idea sucked. People didn’t know where the UI was going to be and so they did a maneuver that is a death knell for VR design: the swirlie. If you’ve designed VR or full body applications, then you’ve seen this move before. The player des a full 360, wildly whipping their head around trying to find exactly what the game wants them to interact with. While it’s usually laughed off as a silly move on the player’s part, if your players are consistently performing the swirlie at certain points in your game, you need to seriously review what is going on during that part. And for me, it was this poorly explained UI design that was trying to be too smart for no good reason. Additionally, the colors I had worked for testing, but overall were pretty muted and dull and didn’t sell the more active or brighter tone the game was supposed to have.

So I took those critiques into consideration, and iterated on the original project a lot. Over the next 4 months I tested and iterated on 20 more builds after this first one, and at the end of it all, I had this:

Final Iteration:

New backdrop, ornamentation, and a taller table! But that’s not all, now there are five scenes, different colored blocks, and a gradually increasing amount of blocks as the game progresses! This, combined with a lot of bugfixing and rewritings for logic, made for a game that felt very different from the first iteration while retaining as much of the focus and strengths there from the beginning. Let’s take our critiques from before, and see how they’ve been addressed.

First, the game now has five scenes, and the later scenes were extended in order to address the second critique. This increased the play time from on average a minute, to a more appropriate 3-5 minutes. That way, for groups of 5 people with only one headset, we have you play for 5 minutes, then watch others and discuss their experience for 20 minutes, then we all come together for conclusions for another 5 minutes. And we could guarantee that everyone stayed in the headset for 5 minutes, because of a point I’ll talk about later.

Second, the game’s complexity has increased. Now we ramp up the amount of blocks in the scene, and I was able to find more assistance tools I could remove while retaining the basic mechanical experience. This meant that even though the scene’s were more complicated, the longer duration of each progressive stage meant the player had more time to identify exactly what was missing, so it was more beneficial to the original goal of identifying what had been removed than my original iteration!

Third, the table is taller. It’s also thinner. Now, you don’t need to bend over to reach out to the blocks, and you don’t feel like you’re fighting against the table trying to get a block!

Fourth, players don’t have to bend over to pick up blocks on the ground. Instead, if a block touches the ground, it disappears in a small puff of smoke and reappears on the table! It was a cute whimsical solution that in some cases may have worked too well, as we’ll discuss later.

Finally, the UI is much simpler and brighter. While the player retains the freedom of movement to move anywhere they want in the scene, the UI firmly anchors them on the side of the table they start on. No one noticed at all, immediately gravitating to that side of the table. No one once even moved around to the other side of the table, even though there was nothing stopping them. Since I could assume where they’d be, I could have the UI ever present, so it was able to provide constant feedback and direction without being too obtrusive. On recommendation of my artist Tyler Greer, I changed the color scheme from a dull purple and gray to a bright blue and white contrast. This made a lot of the UI elements pop out more and proved to be not only more jovial and brighter, but also increased legibility through the brightness and contrast.

However, like Pual Valéry said “A Work of Art Is Never Finished, Merely Abandoned“, so now that I’ve “abandoned” this experience, let’s talk about how I could improve upon this design and future projects I work on.

First off, I wish I had the time to do even more testing. Especially with people who didn’t even know about the experience or what it was supposed to be. Everyone has bias, that’s what allows us to have different perspectives, so I wish I could have had more people with even more perspectives take a look at the game than just other members of my team. Or professional testers, but that’s probably way out of scope and budget for any project at this level.

The testing problem ties directly in to the issue with the blocks reappearing on the table. So, currently it’s coded so that when a block hits the ground, the ground basically teleports it back to the table and kills its velocity. That way, if the block was going super fast towards the ground it wouldn’t teleport on the table and bounce right off it, it would stay put. When blocks are connected, they retain all of their properties, they’re just connected using a physics object called a joint. See the problem? If you throw a stack of connected blocks off the table, there is a high chance one of those blocks does not touch the ground but is teleported anyway. Since it never touched the ground it doesn’t lose its speed. Since it doesn’t lose its speed, it bounces off the table, gaining even more speed. Eventually the speed becomes so great that it bounces around like a bullet and the player is unable to recover those blocks. My players found it very funny, but this was a huge oversight on my part. Luckily it wasn’t game breaking because I had included an always available reset button to scene, so if this happens you just hit the reset button and try again, but the fact that I missed this was a big blind spot in my testing.

I also should have included better tutorialization.  The current experience just kinda drops you in, and while the cold open can work in a lot of experiences, including this one, I do think my future projects should make less assumptions about the players experience. For this app, it was mitigated by the fact that I was present during the play and could offer tutorializing elements, but that would not fly in an autonomous experience.

But the application at the event went great. People really liked exploring the interactions and systems in the game. There were a lot of very smart people who interrogated the systems present heavily, and we had some really interesting discussions about the viability of current technology and its limitations shown in this experience. I believe that overall I achieved my main goal of creating an experience that highlighted the current limitations of the technology, not as a way to scare off potentially interested faculty, but as a way for them to appreciate that development and utilization of this tech requires a different way of thinking about the material and experience they want their students to have.

I am very proud of the work I’ve put into this project and the final result! That being said, I’m most excited about taking what I learned here and applying it to my new experiences going forward! And if you want to try out the game, it’ll be available on Sidequest as a free to download application!

PJVoxels: A Month Later

by Leave a Comment

Well I told you all it would be a couple of weeks until I follow up on my last blog post and here we are, a “couple” weeks later. I promise you though, the wait has been worth it. I’ve accomplished some major updates to PJVoxels, and I am pumped to share them all with you! So let’s dive right in, starting with:

1: Variable Voxel Sizes

4 Square
The process kinda works like this 1 square being divided into 4, except it’s in 3D, so there are 6 squares, and from 1 cube you get 4 cubes.

That’s right! You can now change the size of the individual voxel the world loads with. Without getting too into the weeds, the way this works is by subdividing the voxels present in the scene. Now we can use the same maximum world size for each Voxel Size, and get exponentially different voxel counts depending on the size we’re using. Since we’re dividing from a base Voxel Size, this does limit us to only using proportions of the base Voxel Size, but the 4 sizes currently available (1/8 for tiny, 1/4 for small, 1/2 for medium, and 1 for large) are good for most use cases. And since the base size is considered to be too big for normal use, treating like the maximum size means that somewhere in the smaller proportions is a good general use case size for us to use. Luckily, it just so happens that 1/2 is that size. Another issue is one who’s obstruction may be addressed depending on the use case, and that’s the world size. You see, Unity has a maximum amount of vertices it will render for a single object in the world. That maximum, for our purposes, is 65,535 vertices. Since each world is a singular chunk, that means our world has a maximum vertex count of 65,535. That means with each step smaller we go in Voxel Size, we have to cut the world size down considerably to compensate. Whether or not this is an issue that needs to be resolved is one I’ll answer once we have more testing, since I don’t know yet if it’s a big deal for people to be on a smaller chunk because there are more voxels to edit per base voxel. And testing world generation stuff will be much easier with another addition I’ve made:

2: World Generation Scene

Now it’s not just the developers who can set the world size, but also the users themselves! In addition to that, the player can also select which biome they want to use for their world. I’ve also included preview references for both the voxel size and the biomes so the player knows exactly what they’re generating when they decide. And what if a user really likes the world they’ve created, can they save it for later use? Well now, they absolutely can with:

3: Data Storage

The user can now save their world and use it as their base if they choose to during the World Generation Scene. There’s definitely a lot of work that still needs to be done in regards to this, but this first draft allows for a world of any size and biome to be saved. Currently they save the major details of the world and the type of voxel each voxel is in the scene. Then when that data is loaded in it just pulls from the save file instead of using the normal info SmallVoxelData.cs.

Conclusion

There have also been numerous minor updates and bugfixes including things like: Adding a pointer when placing voxels, Removed the ability to remove edge voxels so you can’t just fall through the world, Reduced the amount of vibrating between blocks, and I’ve already had to resolve issues tied to how the data is saved/loaded and when to use that data. So all in all there’s still a ton to do on this project, but this has been a great step forward. I look forward to reporting my progress and showing off more cool new updates in a few weeks. See you all then!

Starting at Block One

by Leave a Comment

A group of voxels

2 weeks ago I said that I would be posting updates on my progress when I had them, and now, I’ve got those updates.

Tutorial: Complete

To start, I completed b3agz’s tutorial series which has given me a wide variety of tools and techniques in order to expand this project beyond just “Minecraft in VR”. If anyone has any interest in pursuing a project similar to this I recommend the tutorial overall, however I have concerns about some of the later lessons. Specifically it seems like the logic surrounding saving data and the logic the game uses to mark a block’s neighbors conflict, and these issues were just compounded by how large the project is at that point. I won’t go into a crazy long explanation of the issues, but I say this just as a warning that if you follow the tutorial line for line, you’re going to have to go in and edit/remove some functionality to make the data loading/saving work.

Where the Project Stands

In the last post I showed you that I had gotten to a point in the project where I was able to plant a PlayerRig in the scene and had hooked up the logic for placing and deleting voxels. Now, you can still do that! A lot of what’s been done has been backend stuff, but in terms of things to show off you can now both build and remove blocks with both hands, using a button to switch between the functionality. So now, you can use one hand for creating and one hand for deleting:

Or create with both hands:

Or destroy everything!

And that’s where we’re at! At this point the project is sort of like a block of marble. I just need to start shaving away at all the extra bulk and find a work of art somewhere in there. I’ve already removed a lot of the unneeded code tied to custom shaders and player logic, and the player transition has been going over well. So I can’t wait to see where the project stands in another couple of weeks!

 

 

Laying the Foundation for Prototype Park

by Leave a Comment

Earlier this year I began a focused exploration into creating an experience in VR for creating and manipulating objects with the purpose of developing virtual (paper) prototypes. Originally, the plan was to create an application heavily inspired by currently existing VR prototyping apps like ShapesXR. The logic being that using a market tested version of what we hope to create for Penn State would be a good springboard into tailoring our application to better fit our needs.

A look at ShapesXR
ShapesXR provides a wide array of options for creating testable prototypes.

And we weren’t wrong. I learned a lot from using ShapesXR and recreating some of the core functionality. Zac and I talked a lot about what I had been working on and what we liked and didn’t like about the functionality present in ShapesXR, and came to a pretty succinct conclusion.

We Want the Features, Not the Foundation

ShapesXR has a lot of good features we would be happy to adapt into our application, but its core systems aren’t precise enough for what we want people to be able to create. And this is something core to any VR experience. Humans are naturally fidgety creatures, we are not precise on our own or without experience. Add to that a headset and controllers whose weights we constantly have to counterbalance, and you’ve got an imprecise environment for creating what are supposed to be precise prototypes.

So for our prototyping application, how do we introduce this precision while maintaining the sense of scale and presence in VR? Well, after talking about it for a while Zac has two different systems in mind. And while he’ll tackle one way, he’s left the other way for me to think outside the box, or should I say, outside the block…

Minecraft Header
First released in 2012, Minecraft is one of the most popular games ever made, with an average of 3 million people playing it daily 10 years later.

It’s Time to Craft Some Mines!

Well, not exactly. See, Minecraft uses a 3D graphical concept known as Voxels to store data specific to its world. Voxels have a lot of interesting properties, but the one we’re most concerned with for our exploration is their precision. Similar to pixels, a system knows where a voxel is based on its neighboring voxels, so their position in space is always relative. So when you place a block in Minecraft, its always perfectly align with its neighboring voxels. This is a really helpful work around to the imprecise nature of VR. By sacrificing a bit of player autonomy in object placement, we’re able to give them much more control and precision during the prototyping process.

There was just one problem. I didn’t know how to make Minecraft in VR! Luckily, Zac had done a bit of research and found b3agz’s Code a Game Like Minecraft In Unity Series which I’ve been watching and learning a ton of techniques and concepts related to voxel generation and management. There’s going to be a lot of editing done on my part to make these concepts work for our team, but so far the results have been promising. And when I’ve got a more concrete demonstration I’ll post an update, but for now I’ll leave you with a video showing the first rough draft of this version of the prototyping application:

Tearables for PuppetJump

by Leave a Comment

Intro

So, at a recent meeting we discussed concepts for a new project. Everyone brought cool ideas and while we’re still working out exactly what idea we’re doing, in passing a comment was made about how tearing apart objects in VR is a cool idea with generic applications. And y’know what? That’s right! And so I spent the last week working on this “Tearing” mechanic and now I’ve got the first iteration of the mechanic to show off.

Abstract

Simply put, the system currently works by tracking the offset between a user’s hand in physical space vs the hand in virtual space. When that offset reaches a threshold set by Tearable.cs, the object “tears”.

Assets

Tearable.cs – Inherits from Grabbable.cs, since this is just a specialized Grabbable, it made sense to do this so we decrease the amount of components needed on an object and decrease bloat. And all the additional logic can be turned off with a boolean, so if you want to use just the base Grabbable system, you can just set isTearable to false and boom! You’re back to it just being a normal Grabbable.

DestroySelf.cs – An object destroys itself after a period of time that can be set in Editor. Used for Tear System.

Tear System – A particle system that activates on tear. Currently set to a cube mesh for the particle, however the color and scale of the particles scales with the object.

 

Breakdown

This system is based entirely around measuring the distance between the physical and virtual hand. This is great for a multitude of reasons:

  • Works with stationary objects, which all objects will be as you pull them in opposite directions with equal force
  • Because it doesn’t measure something tied to the physics system like object speed, there are no weird situations where holding an object with both hands and moving too fast causes the object to break unexpectedly
  • Because it’s reliant on the hands and not the object, it can be applied to any object and the base functionality works immediately

Although, the fact that it doesn’t rely on the physics interactions does limit the scope of this iteration, and introduce design complications like the tearing not being dynamically responsive, you’ve either torn the object fully or you haven’t, there’s no mesh tearing tricks to go half way.

The divisibility is user friendly, and only a click away. You can set an object to be your output, but if you don’t and still want divisibility, the object sets itself as the object, then divides in half indefinitely.

Future Considerations and Learning Applications

 

So where do we go from here? My next tasks will be incorporating the Rigidbody component into this project. Right now the object will visually split, but physical components like the mass stay the same, so next up would be that.

For learning applications I could see this being used in really any application. Viscerally the action of pulling an object apart fits a ton of educational genres. In biology, you could tear open objects to look inside them, like coconuts or eggs. In chemistry, you could tear apart molecules or atoms (and watch your virtual world explode from the fission).

 

Conclusion

So that’s my update! I’m super excited to further iterate on this and see where it goes. Stay tuned for the next update to this project when I attach the Rigidbody and Forcible component.

Matter Changer for PuppetJump

by Leave a Comment

Introduction

A couple weeks ago my coworker Bart posted about some experimentation he had done with Zac’s new VR development library: PuppetJump. It’s a fun experiment about magnets (how do they work?), and a real good read about his process (which you can check out here), but more importantly it’s given me some inspiration to get in to PuppetJump and do some fun experimenting with the system Zac has written specifically to create a demo called “The Matter Changer”!

Abstract

Alright so I’ve actually created 3 demos from this project: The Preset Matter Changer, “The Transfer” Changer, and the In Scene Editing Changer. Each one has their own purpose, which I’ll discuss more thoroughly when we get to them, but they all share a couple things in common. They all rely on the Forcibles and Rigidbody classes, and they all provided a chance for me to try out the PJ3DUI library. Here’s a list of the variables that can currently be changed using this system:

  • The object’s Mass
  • The object’s Physics Material
  • The object’s brake and angular brake (controls the drag and angular drag respectively)
  • The object’s max speed and max angular speed (how fast it can move and turn)
  • Whether or not the object is using Gravity

Assets

I’ve developed two classes for this project: MatterChanger.cs and MatterButton.cs. MatterChanger holds a reference to all of the information about the object placed on it, and MatterButton changes those values.

Version 1: Preset Matter Changer

The simplest form of the Matter Changer from a design perspective. The basic concept is that you assign each button a matter type using MatterButton.cs, and then they tell the Matter Changer what to change about the object you’ve placed on top of the Matter Changer. In its current iteration, this Matter Changer is great if you’ve got specific static material types and want a simpler method of interaction for the user to engage with. Since all you need to do is drop the object on the Changer, then press the button, it’s good for exploring the concept of changing materials, without bogging the user down with more complicated tasks.

Version 2: “The Transfer” Changer

This form of the Matter Changer takes advantage of the fact that the button is in of itself a type of object with all of these variables that can be changed, so if it simply reads in the data from one object on a special type of Matter Changer base, it can send that information to an object on a different Matter Changer base. This iteration could see use in simple puzzle exercises or explorations that wanted to focus on what happens when you give one object some of another object’s physical properties, but it still retains its innate shape and dimensional properties.

Version 3: In Scene Editing Changer

This iteration of the Matter Changer is the most malleable form of the Matter Changer. Theoretically you could create an enormous amount of materials to give objects with what is given to you in this final demo. Not all of them will be viable, not even close to all, but experimenting with what works and what you can create will be the main focus of this type of Changer. It also functions as a dynamic Matter Changer, and is adaptable in scene to whatever needs you have at that moment, so if you know what you’re doing, you can leverage some really interesting results with any objects you have in scene! The biggest issue with this is in order to understand what you’re doing, the user has to have some knowledge of how objects work physically and maybe a little bit of Unity knowledge to understand how things differ virtually. Or you could run in with no experience and just see what works, y’know: Science!

Future Considerations

So where can this project go from here? Well I see two lenses to view this question from, the first being educationally, the other being development. In terms of development my first thought is to make the Matter Changer mobile. For example, having a little instrument you could carry that allows you to change an object’s properties just by pointing at it, like a remote control, except instead of changing a channel, it changes the mass of an object. Maybe there’s a use case for a 2 way transfer, so both objects switch properties instead of the receiver just getting the sender’s properties. Heck, even something like a scanner that tells you the innate properties that an object comes into scene with would be cool. For example, Zac’s already added an abstraction for weight where an object moves slower when held because it’s offering more resistance because it has more mass, but if the user new what the mass of that object was going in, and a had a reference for how heavy that is, then it would help sell the illusion further. From an educational standpoint I could see this application being used in something as straightforward as a Physics 101 class as an aid for students to better understand the relationship of matter to its properties, to a more abstract philosophical discussion of the metaphysics. Y’know, like how much of a thing is a thing if you keep changing the parts that make it that thing. Could do a fun discussion referencing the ship of Theseus, or some aspects of metaphysics. I really believe there’s a lot you could do both inside of and around this tool.

Conclusion

And that’s what I’ve got to show! I think this application could have a lot of educational potential for the university. I mean, even the concept, like turning a barrel physically into a ball, could be taken in a million different directions. I hope with further iterations, or even collaborative work within my organization, this idea could be a good way to teach a concept that’s hard to visualize without this direct, virtual approach.

Basic Experience Comparison Project Post: What Space do I Use?

by Leave a Comment

The Intro

Hey y’all. I’ve been thinking about space again. This time I wanna focus on space as an extension of the play experience, rather than the current mechanical limitations placed on the play experience by our available space. More specifically I’ve been talking with my boss about creating an environment in which we can give people basic mechanical interactions/experiences within a well defined and easily understood space so we can have people test the mechanical viability of an interaction in a VR application vs. a desktop application. Part of this post is going to be a pros and cons discussion of the different environments we’ve been exploring, but another part I want to focus on is the idea of “functional space” and how it relates back to VR mainly.
[Read more…]

Skip to toolbar