Wednesday, April 30, 2014
This is a development diary series for "Get Better Soon", an NEA-funded gay club VR simulator game I'm making for Different Games. You can check out previous dev diaries here.
Virtual reality is weird and terrible for a lot of reasons: "simulator sickness" is the frequent sensation of nausea that attacks many players, simply from trying to exist inside virtual reality. (There are lot of complex reasons why that happens.) There's something fascinating about that -- a reality where existence makes you want to throw-up. A lot of that bizarre beauty is going to get smoothed-over and destroyed as the technology improves, which is unfortunate.
One of the more upsetting developments in VR progress is the specific user flow and use-cases that the two biggest VR influencers (Valve and Oculus) are prescribing for VR games. They imagine every VR user is going to be seated in front of their computer, with a positional tracking camera on a desk in front of them. The idea is to seat the player so they always know which way is "forward" by their dead reckoning, which simplifies how head tracking will combine with controller or mouse input. That way, it matters less whether you're blindfolded with a screen strapped to your face.
I think this is kind of a conceptually lazy way of solving the "input" problem.
Tuesday, April 22, 2014
- When the player does a thing, there should be some possible reason why or situation when they would NOT do that thing. Unless you specifically want it to not matter because ____.
- When the player does a sequence of things, there should be a reason why they did it in that sequence vs. a different sequence. Unless you specifically want it to not matter because ____.
- Things should feel embodied / have "feel" and feedback to them, according to how important they are to understanding what's happening. Unless you specifically want players to not notice it sometimes because ____.
- Your game should occasionally be a little boring, or occasionally be a little exciting. This is called pacing.
- Make the smallest possible game you can make. You can always make it bigger later. Each prototype / iteration is a different game.
- Don't implement most suggestions that people give you. Think more about why they made those suggestions. Also, don't be upset when a dev ignores your suggestion, you're not the one making their game.
- Don't plan too far in advance. Your plan is going to change anyway.
- When tuning, double a value or halve it or increase / decrease by magnitude of 10 or randomize it.
- How you talk about your game affects what your game actually is.
at 3:10 PM
Tuesday, April 8, 2014
This is a development diary series for "Get Better Soon", a commissioned game I'm making for Different Games 2014. If you want to see it and play it, then come hangout at Different Games next weekend in NYC!
Kris Hammes is finishing up the character. The 3D model geometry is basically "done" so now I'm just waiting for the last texture tweaks like chest hair. In the meantime, I've rigged the model with a standard "HumanIK" skeleton in Maya (so that I can easily re-target animations in Mecanim) and I've configured the shader so I can start figuring out how to implement these characters into the game.
Tuesday, April 1, 2014
Last time I tried some type of "procedural narrative" thing, my hubris got the better of me -- naming the system after one of the most famous and influential writers of all-time was, perhaps, just a little arrogant.
Despite my attempt to scope it properly, that system suffered greatly from trying to do too much stuff... It was so much stuff that it was difficult for me to write anything with it. So with the procedurally generated NPCs in Nostrum, I'm developing a much simpler system which will hopefully work better, to solve a smaller problem...
The basis is still the same: Elan Ruskin's GDC 2012 presentation on AI-driven dynamic dialogue in Left 4 Dead 2.