The Mechanic
And before I even knew it, we’ve come to the end of another month. This month my goal was to develop a backpack similar to the backpack in Half-Life: Alyx (HL:A). Did I succeed? Not really. I ended up creating something more akin to a portable hole than a vacuum cleaner. What exactly do I mean by that, and how exactly did I get here though?
The Plan
So my original plan was to create a game object that held a list of all objects inserted into it, turning off those objects in the scene, then when the player reaches into the backpack, they could pull out the last item put in to the backpack. This model is even simpler than the context sensitivity found in HL:A, and yet things got clogged real quick.
The Results
Originally I had the backpack as one object. This worked as a way to store the objects, as once they entered you just shove them into a List of game objects so the backpack knows what and where it has a particular object. After this is was easy to set up the backpack as a trigger and have OnTriggerEnter work to add the inserted object to the list and then make the object Inactive. It’s pulling the object back out that I got stumped on. And so, this is as far as a I got:
http://https://www.youtube.com/watch?v=BVJ4x_A4z_4
I thought that the issue lied with me pulling the object from the backpack, immediately setting off the trigger and putting it back into the backpack, so I separated the backpack into two parts: storage and spawner, that way I could edit the colliders on the two separate events for the backpack, and I edited the size of the test object so you could stick your hand in the spawner to grab the item and not have it touch the storage collider when you grab the object, but it doesn’t spawn the object. From what I can tell in my debugging, the backpack knows when a hand is inside of it, but it doesn’t register the pulling of the trigger when inside inside the trigger. I’m not sure what that occasional visual snag is (when the controller pauses and rotates, and then snaps back to where my hand actually is) but I am sure it has something to do with why the retrieval of the object doesn’t work properly.
The Conclusion
I think the immediate take away from this month’s mechanic is that nothing in game design is ever as easy as it looks, and that a game programmer like me can still have more than enough hubris to forget that very crucial fact. The other thing idea I’m walking away with is that I need to do a bit more work understanding the logic of the input system for OVR, because that seems to be the only spot where the logic breaks. It looks incredibly similar to Unity’s default Input logic, but perhaps there are some intricacies that I was unaware of when using it.
Next month I’ll be tackling hand tracking in Quest. I’m really excited for this, as the tech surrounding it seems super cool, but I am a little apprehensive about getting over the hurdle of development for the Quest (building for Android and deploying it and whatnot). Not that I’m worried I won’t get it, but that it’ll slow development down considerably, but who knows?
Leave a Reply