Cappin' Stones (9/16/2016)
A lot can happen in a week. This past week is one of those weeks. The three people working on the three prototypes have made a lot of progress on their respective prototypes.
Garret Moran has been hard at work getting movement systems working on a beat for the rhythm stealth game, based around Crypt of the Necrodancer's implementation. There's a small amount of leeway on each beat, but it's still fairly easy to miss beats, so the next stage of implementation is having a system where if you move on your own internal beat that's similar but not quite the beat in the game, the game moves the beats to your movement, effectively cheating on your behalf.
Dan Covert has been working on Zone of Chalk, but has been running into problems. The core conceit of having a game where you draw a path is very difficult to pull off in Unity. Dan has got the core movement working, and a character that will run along paths given to him, as well as speeds on differently sloped paths, but getting a "drawing" system will end up more complicated. We just had a meeting talking about what we can do with that prototype going forward, and we all agreed that having some sort of prefab "placing" rather than full path drawing is a nice middle ground for prototype stage.
And I... I've been in Unity physics hell.
I took on the second most technically difficult prototype, and it's been giving me the works. The concept of a VR 2D platformer is a fairly simple concept to design about on paper, how camera foreshortening will make jumps smaller, having a head-tracking camera act as a 3rd person camera, and laying out example platforms makes the concept easy to swallow (see previous blog post).
The first way of going about this was to set up a fake VR headset. In order to do this I set up a cage inside Unity:
Despite all my rage, I am still just a FPS Controller locked in a cage.
And then I hide the mesh renderers.
Hidden Cage, Crouching Box Colliders
And then placed an FPS controller inside the cage. What this effectively does is provide a small closed in area for the player to move around in emulating an (exaggerated sized) VR Headset seated area. You can look around in 360 movement, and "lean" around the scene by moving with the WASD keys. Currently, in order to see if concepts work, the cage is fairly large, allowing for a wider range of movement than simple seated VR would allow. Though in practice, I do like the idea of locking the movement of the VR camera to a small box. In doing so, it makes sure that each perspective "puzzle" is always doable from a small range, lets say for example seated.
If you are seated while wearing a VR headset, you have about a 260 degree horizontal range around you you can comfortably move around without feeling you are straining yourself to move around. In addition, for about 180 of those degrees, you can comfortably jut your body out in order to push your head outside of that 260 degree seated circle. From a jutted out angle you can comfortably turn your head horizontally around 160 degrees, and vertically as far as your head will allow you to. Constraining your view movement to this range will lead to a more comfortable play experience, and by using that box as a design constraint, each perspective puzzle or jump must be doable in that box, allowing for experimentation without having to worry about Room-Scale-VR play-spaces, boundaries, or people moving into places that will break the game.
It provides the first half of the 2 elements of our game, the camera system, the next half is the part that would prove the most tricky. Platforming.
Setting up platforming was simple enough, I went through some old Unity scripts and found a nice 2D platforming script from Game Tech II (the game originally using this code can be found on this website). After some re-configuring to make the character not jump 100 miles into the sky every time you jump, and some control re-configuring so it wouldn't conflict with the FPS controller (the platforming character uses J, L and I to move), I tweaked it a bit as to not feel totally terrible. It's not totally done, there's no ground check to prevent double, triple, quadruple, pentuple, etc jumping, which came in handy later to test complex collisions.
Both elements working in tandem with the most important 3rd wheel, comedy.
Now began the trickiest part of the whole problem, making the jumping based on perspective work. There are 2 parts to this: being able to make a jump onto a platform that is physically behind the character in 3D space as well as making jumps work based on perspective.
After a largely unsuccessful 3 and a half hours of research and experimentation I wound up with this implementation:
Using 2D colliders on both the player and the platforms, the problem of jumping between 2 platforms on two different 3D planes became trivial, but the problem still remained, I had to double jump in order to make this impossible gap. I had solved the problem of the 3D jumping, but still needed to get perspective jumping working. And then like any good Hollywood story, I got a ray of hope.
The hand of god.
After vaguely crying about it on Facebook, a friend of mine, Levi Rohr from Sundae Month messaged me with an idea so obvious I can't believe it didn't occur to me. In order to make perspective jumps work, you have to have things be based on the camera. Raycasting from the camera to the players feet and using the raycast as a ground check should be the way to go. The only problem is, while the idea was sound, I have nowhere near the technical expertise to pull it off.
And that's where Garret Moran comes back in. We spend 3 hours retooling the way we handle collisions on the player, setting up raycasting from the FPS controller, billboarding a sprite towards the camera, and setting up box colliders on the feet of the character in order to make collisions possible. If you're wondering why all the gifs above all look slightly different in terms of character movement and character look, its because these gifs were made at all stages of development.
After 3 hours we learned a lot: in order to pull this off we needed to set up an invisible cube in front of a sprite. The sprite is our character but the invisible cube handles our player movement and basic collisions. The sprite constantly rotates towards our camera view, giving us the ability to easily raycast towards the sprites center and then use math to find the corners of the sprite in order to find the corners for collision. Once we got the corners casted, we set our sights on getting collisions working. We added small boxes at the raycasts on our players feet that move with the raycasts, and ran into problems with them moving at random. The problem was traced to the raycast and we attempted to layermask hide them, but to no avail, Unity wouldn't let us hide them. After some fiddling, we tried a perspective jump... and it worked.
And then we tried again, and it didn't.
What you see above is the most reliable jump we can get the prototype to do right now. A double jump towards the other platform, once again solving the jumping between two different 3D planes problem, but not the perspective. The perspective jumping works... some of the time. From personal experience I would say it works 10% of the time. Part of the problem is that the collision boxes that move based on the raycasts are buggy. Either they move on their own or they don't move at all. This is partially because we can't get the raycasts to ignore seeing them. The other part is due to the fact that the collision boxes don't move fast enough to the platform behind you. You can avoid this by falling slowly, by lightly double, triple, and quadruple jumping before you land. Sometimes you just fall through the platform entirely, and if you double jump upwards you can get the collision box to land on the ledge. Through falling-through-and-jumping-back-up strategy you can occasionally get perspective jumping to work. I couldn't get a gif of it because it's so finicky.
So in a way, this prototype is functional, it does all the things we want it to. It simulates a VR headtracking space, it has decent platforming controls, and you can jump between 3D dimensions all the time, and jump based on perspective... some of the time. It's definitely not good enough to go forward with, but it's Just. So. Close.
At this point getting this thing to the spot where we can present it is far above my current technical know-how, and Garret wants to continue working on the rhythm stealth game and get that in a solid spot before he takes another look at this, which is probably the best course of action, but for a while, leaving this prototype in this state I'm fairly OK with. It's nearly there, and just needs a bit more love in order to fully get there.
So what's next? Obviously getting the prototype in proper working order, as well as advancing the other 2 prototypes to a solid stage, but this week I'm also going to be writing Production-level design documents for our games. I'll start out with two of them: the rhythm stealth game and the VR Platformer, but getting design docs at the stage we are at with our prototypes I feel will be super useful. We will have a lot of the core systems of our prototypes done, and ready to start thinking of other things to put in there to make it feel more like a "game" rather than a tech demo of various ideas, as well as it will allow our team to visualize what we can do going forward with all three of these ideas in order to find our one game idea to go forward with. It's a brave, and exciting world out there in Capstone land and I'm ready to start exploring.