Wow, A lot has happened. So much so that I haven't been able to write a blog post in a while.

We have been hard at work on the game, getting art assets in, scratch audio, QA testing the game, getting feedback, and getting out of deep dive. I figured I'd break this blog post into multiple parts. How many? As long as it takes.

Going into deep dive, we needed to reprogram the game from scratch. The original pitch prototype was in 3D, while the game was in 2D. Work on this was slow, initially, focusing a lot on the beat system and making things easy to make levels with (see last post). What we ended up with looked a lot like this:

At this point, the game was functional, it had working guards, with paths they follow (the blue "N"'s serving as a visual representation of points the guard will walk to.), a laser system, (seen with the red line coming from the wall) and a beat. At this stage, there was no audio beat for the rhythm, and only a visualizer down below. When a beat would happen, the two would meet. In addition, all the security systems moved to the beat. We took this to QA and got strange feedback.

Without audio for a beat, people were confused, but some people actually found the game perfectly playable without it. Having everything move to the beat, at a consistent rate, gave some people enough feedback to get through the game perfectly. While some were dumbfounded. We asked people what we could do to improve the rhythm aspect of the game, and we got a lot of people saying "add sound" while other people gave us much more ingenious ideas:

Our current rhythm visualizer is out of the way from gameplay, at the bottom of the screen and kind of distracting. It could be replaced by a flashing at the sides of the screen. Other people wanted "tells". While the guards and lasers move at fixed beats, the guard can feel "unpredictable" as there is no animation on the guard. A lurching forward animation or a head bob could go a long way to making the beat feel great

We also got lashed for the lack of art. Everything in this build was programmer art, due to inability to communicate with our artist. Our artist was seemingly impossible to be reached, and promised art over and over... but didn't deliver. We were frantically shuffling around to get art in, and eventually got some assets, but only a few usable ones.

With what we had, we decided to try to challenge out of deep dive, only to be told what we already knew: we need art and sound. Luckily, I had been working on sound the last week, and our artist promised to get art to us as soon as she could. Which leads to the next part.

Woah. I let this blog get a little rusty. Sorry about that. 

What has happened in the last 2 weeks? It turns out... a lot! We challenged, and Rhythm of the Night now has been accepted as our game we are going forward with. As you saw in the last update, the prototype was in 3D however, the game was always envisioned as a 2D game. It makes making levels easier, and the art load is a lot lower for our single artist. 

Since you last saw progress on the game, the whole of the game has been rebuilt from the ground up. It's not quite 100% there just yet, but the rhythm system and event handler that passes a beat to all other systems of the game are almost fully in place, and systems are being made to make level design easier.

Gif Courtesy of Dan Covert

We now have a system that automatically locks tiles to a grid system, meaning when it comes to making levels, all I have to do is drag and drop. We've also been working on getting proper implementation of camera and laser systems up and running, the two easiest security systems to get up and running early on. Once those are in, we can start making some test/real levels and building out the game from there. Early on, getting a pipeline that makes level design quick and easy has been our biggest bottleneck, but getting it right means that we never have to think about it again down the line.

Lasers gif by Dan Covert

There's been a lot of talk about the specifics of implementation, and debate on how moving to a beat actually works. After a large conversation, and some debate, how beats work has been broken down in this example:

(timing and numbers are not exact here. This is massively simplified)

Imagine a period of 10 seconds. In those 10 seconds, the player can push the movement button, and the character will move. However, the last 3 seconds of those 10 seconds count as "correct", and moves you to the beat. If you move in the "correct" period, either as early, as late, or in the middle as you can, the game registers your movement as the start of the next beat. Systems will update along a beat, audio shifts slightly, and visuals update, allowing you some leeway with the beat and not making you feel punished if you are actually off on a beat by a little bit. However, any movement in those first 7 seconds still count, though they do not count as an on beat movement. The player can move freely during this time, but there's only so many times they can move. Plus moving off beat has it's consequences, dropping your score, and alerting security systems that are designed to react to off beat movement. Now, take this imaginary period of 10 seconds, and shrink it down to what you think of as a single beat in a song. There's leeway around the correct timing of the beat, and you can still mess up and move off beat if you aren't timing it correctly.

Lots of work is being put in, in order to make beat based movement feel good, and not a chore, or something that doesn't feel off. We want the constant forward momentum to drive the player forward at all times, and think on their feet when it comes to finding the best ways around obstacles. 

On the design side, I've been hard at work touching up our Design Document, and turning it's updated values into a VDD for the team.

Lower quality version of the VDD. The full thing is a massive, scale-able PDF.

I'm not the best artist in the world, but luckily our systems are fairly easy to depict based on vision cones. Using highlighted tiles, and semi transparent vision cones, I was able to show how far each system can see, what it looks like rotated, how many steps does it take for a guard to turn (and where is he looking while he does?), etc.

This will probably become more cleaned up and simplified later on, if we get a chance to add more systems, but for now, it gets the job done, conveying direct metrics of everything we're working with.

A shorter update this week.

Things this week have been progressing smoothly. All of our prototypes are in a position to "challenge" and go forward with, and the majority of the week for people has been spent writing documentation or hashing out fine details in things. 

Quite possibly the biggest piece of the puzzle was a meeting the whole team had on Wednesday. In this meeting, we hashed out a plan to get everything on track by this Monday, but not to be too afraid to let it slip to next Monday. In the meeting we decided what game to go forward with (the Rhythm Stealth game, now tentatively titled Rhythm of the Night), and our team name (Zamboni Dreams).

The VR platformer prototype is now in a somewhat functional state. Dan took over the programming and was able to create a prototype that is a combination of real perspective physics, as well as fake perspective physics in order to get the prototype up and running.

Meanwhile, Dan has been working on the Zone of Chalk prototype. The Zone of Chalk prototype was another incredibly tricky one, as both it, and the VR platformer contain ideas that are very hard to program, and thus got the axe. As much as we loved both ideas, the thought of going forward with a game we can actually make and finish is more appealing than bashing our heads against trying to ray-cast physics from a VR perspective.

Zone of Chalk, in prototype state.

Going forward, we plan to work on a game, currently titled Rhythm of the Night, which I don't believe I've fully explained.

Rhythm of the Night is a top-down, 2D stealth game, based on rhythm movement mechanics. This means that you can only move from tile to tile on a beat, and cannot on off beats. You must navigate a house, bank, or other locations and steal as much stuff as you can (stealing may be done on off beats), while also going from your entrance point to the exit without being caught. In addition to you moving on Rhythm Mechanics, so does the rest of the game, guards will patrol paths, moving one tile at a time on the beat. Lasers switch on and off to the beat. Cameras swing around to the beat, so forth and so on.

The game is non-combat oriented, so being detected by any of these causes a fail state for the level, so it's imperative to sneak through a level while remaining undetected. Players have powerups, that can slow down the beat, turn it off entirely, or get away from being detected by throwing down a smoke bomb that can help them navigate through various levels of all sorts of security systems. How many security systems? It's too early to tell, but the design document currently has 2 pages worth of security systems and numbers of how they all work. This prototype gif should be able to help illustrate the point (I keep getting caught by the laser)

Speaking of design documents, every game has their own 4-5 page full design document planning out early thoughts, and things to go forward with for the vertical slice, as well as things for next semester. These documents are living, allowing me to go into them at any time and add and remove ideas so nothing is set in stone just yet.

On to challenging!

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.

via GIPHY

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:

via GIPHY

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.