Whew! That last entry was a long one and I was almost wondering if there's anything to add to the month of September. As it turns out, there is always lots to talk about :)

So, I launched my game. That was pretty cool. It's a first, and I feel happy and proud about it. I hold my head a teensy bit higher now. But, let's not kid ourselves. The game is far from finished and there's a TON of work left to do. I mean, I released it in "Early Access". There's at least another two years worth of work for me to continue on, so there's no time to rest or slack off.

Right after launching, I sent Oculus a message to see if they'd be kind enough to send me an Oculus Touch and a CV1. To my surprise and delight, they agreed! The Oculus Rift arrived on Monday and I've been spending the whole week working with it and adding in support for it. I am not allowed to write any details about the Oculus Touch however, so I can't say much other than I'm working with it. I'm eager to add full support for the Rift however, and I hope that some day Spellbound will have a presence on the Oculus Store.

I want to talk about the Oculus "experience" for a moment though. From the moment I opened up the shipped package to the moment I was inside VR, I had a very smooth, crisp installation experience. I was pleasantly surprised by just how well engineered everything was. It's incredible. *This* type of experience is what VR needs in order to succeed and win in the market. The oculus store is another excellent experience refined to perfection. The *only* thing I would complain about the oculus store at the moment is the lack of a review system for the content, and ways for early access developers to interact with their customers & community. I suspect that these features are upcoming, but there are still some VR engineering challenges for oculus to get through. Their store experience is designed to be a virtual reality store, so text input will be a stumbling block for people who are not touch typists. I think that they also have a unique opportunity to demo the VR products in a way unlike what any other storefront can offer: Use VR to your advantage! Let's stop thinking in 2D. Let's create game play trailers in VR, to be viewed in VR. Nobody has done this before, and the first VR storefront to do it will set the bar for every other VR storefront to meet.

After I released my game, I started working on a patch to fix some issues people identified and to add requested features. One of those feature requests ended up requiring me to update the game to the latest version of Unreal Engine 4, and that update caused a significant bug in my room scale locomotion setup. The problem is that I am using a customized camera setup for VR. If the player walks forward 1ft in their play area, I move the camera forward 1ft as well. Then the engine moves the camera forward 1ft again. So, there's now a 1:2 ratio of movement. When it comes to intelligence, I'm just average, so it took me longer to figure out exactly what was happening than what it would take most people (a couple days). So, you might ask, "Why not just let the engine move the camera?". Fair question, but the problem is that the engine doesn't do any collision checking with the camera, so you can easily put your head through a wall in VR. So, *I* have to control the camera position at all times.

That brings up an interesting VR design principle: Who controls the first person camera? The player or the game? The intuitive answer would be "The player!" but that is actually the wrong answer. The game controls the camera position and orientation at all times, but it responds to input *requests* from the player. It's up to the game to decide whether to accept those input requests. 99% of the time, they pass through and are accepted. However, there will be some very special times when you'll want to control the camera position or orientation. What if the player tries to put their head through a virtual wall? The wall should block that movement, and the only way to block that is to stop the game camera from accepting the movement request of the player. In the real world, we're physically blocked from putting our heads through walls by the wall itself, but in VR, there is no physical restraint. Likewise with hand movement controls. If you have a hand and you pass your controller through a virtual table, you should sweep the virtual hand through the world until it gets blocked by a colliding object. The really tricky design problem becomes, "What happens to the virtual hand position after the physical hand controller is in an unblocked state?"

Now that I'm adding support for multiple hardware input devices, I've had to come up with a new way to support the differences in hardware. I decided that there should be one common interface that the hardware works with, and one common interface that controlled characters interact with. I came up with this weird principle of disembodied control. Instead of directly controlling a character, you are a in control of a "head" game object. The head game object is the interface for working with all VR and input hardware. It is responsible for converting the various coordinate spaces into a unified common coordinate space, applying the appropriate vector offsets for each hardware platform, and generating the common input commands all characters would have to respond to. The head also contains a skeletal mesh which can be swapped out to match the character being controlled, so you're literally plopping a head onto the shoulders of a headless character. What's interesting and important about disconnecting the head from the rest of the body is that the player who controls the head should never render the head for themselves (or else you see the insides of the head mesh), but anyone else seeing the player should see the head. The head mesh should be attached to the body at all times and it shouldn't be apparent to the player that they're different objects. On a slightly more abstract conceptual level, the head is like a puppeteer, and the body they're on is the puppet being controlled. Your inputs are like pulling the puppet strings, but sometimes the puppet can't do what you're telling it to do (like clip through colliding objects). This creates some interesting new game play opportunities. There is no reason why a player now couldn't control a zombie, much in the same way they control a wizard. So, in a future multiplayer game mode, players could play as zombies against a wizard. Because the heads are also disembodied, they can very easily become spectators in VR -- just don't give them a body and don't render the head mesh, and they're now invisible observers!

This also introduces some interesting new design considerations. What happens if the player is really short (such as a kid)? What happens if the monster you're controlling has their head in a different position relative to the rest of their body (such as a crawler zombie)? Is your locomotion system still valid if players are controlling zombies (ie, no teleporting)? What information do you give the player playing as a zombie to make their play style indistinguishable from the AI?

Anyways, the huge win with this design is that it creates a layer of abstraction between the hardware implementation and the creature control, so I only have to add support for a single interface and all creatures which respond to that interface are automatically supported. Adding extra hardware platform support becomes a lot faster and easier, and its a lot easier to work with characters which have no idea whether they're being controlled by AI or VR interfaces. I don't know if this is common, but if you're doing VR, you should consider this extra layer of abstraction.

On the financial front, I'm still broke. Any proceeds from sales I made in the month of September won't be received until the end of the following month. Aside from this dev blog, I've done zero advertising for my game. Despite that, I've gotten some reasonable sales, relatively speaking :) Thank you to anyone here that purchased my game. I'm still 5 months late on my office rent and I'm getting pressured to pay up. I went to the bank today to apply for a personal line of credit to pay my office $800, but the bank rejected my application. I haven't had income for the last three years, and I have no credit history because I've never owned a credit card in my life. It's weird to think that I have to pay myself, but I guess that makes sense. Being "self-employed" still means I'm employed, and you have to pay your employees. Still, it's like having a conversation with yourself where you're like, "Here yourself, have some of your own money!". But I guess when you do that, you generate a paper trail... and get taxed for giving yourself your own money. It's time to ask friends and family to lend me money for a month to get by. Some day, I'll have enough money to be fully self-sustained by my work, and then I can truly call myself a "professional", though maybe I may not necessarily always act like one ;)

I had this interesting dilemma the other day in regards to communicating with my community of fans, and I'm still a bit perplexed by it. I know there are bugs and issues I need to fix with my game. I've fixed them in the latest build, but thanks to my most recent overhaul of the character control scheme, it's going to take a few weeks to finish and test before I launch. I want to tell people "I fixed all these things, but it's not ready yet!". But when I start writing a list of all the things I fixed, I find myself wondering: What's the point of telling people what I fixed weeks before releasing the build with the fixes? Wouldn't that just cause more confusion? Shouldn't this just be included as patch notes to go along with the update?

Another interesting observation: I have TONS of people who have my game on their steam wishlists. The question is, "What are they waiting for?" And there could be multiple answers:
-Support for different VR hardware platforms
-Steam sales
-Full game release
-Content updates
-Money
-More compelling sales pitch?
It would be interesting to know what they're waiting for and how they discovered my game (despite no advertising).

Last note:
I'll be at the Steam Dev Days in Seattle on 12 October 2016. It's just a short walk from my work place :) Let me know if you are going and want to go get a beer or chat about game development.