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.

It's Senior year at Champlain College, and that means one thing: Capstone. This semester, I'll be working with a small team on a prototype with the hope of going forward working on that game for the second semester as well. But before we go ahead and start working on that prototype, we need to come up with other ideas as well.

Iteration across many months.

Thankfully, throughout the past 3 months, I've been working on a handful of game ideas, around 20 to start with, that was whittled down into a short list of three games: A cooking game using the Leap Motion controller to create a frantic, arcade cooking game, a rhythm stealth game, where you go through various different places stealing everything you can to the beat, and avoiding guards, security cameras, and other stealth like things that operate on the beat, and a 1v1 puzzle game like Tetris, with Street Fighter style power meter mechanics, to keep the game interesting. We figured we might as well have our main idea, and two back ups before the semester even started, and finalized our 3 ideas on August 19th.

But then the semester started and we were thrown a curve-ball, not only do we need to make 3 prototypes to start, but we need to generate 50 ideas, so we sat down and got cracking on 50 ideas. Not all of them were golden, stuff like "Hollywood Hacking simulator where 2 people share the same keyboard", and some were awesome, but entirely out of scope, like Olli Olli Oxen Free, a hide and seek skateboarding game, with the same open level design of a Tony Hawk game. In the end we decided on 4 solid ideas: the cooking game from before, the rhythm stealth game from before, as well as two others, a game where you are a boom mic operator chasing the main actor, but trying not to get the mic in shot, and a murder mystery adventure game set in a room, and in files on a computer in a room.

How we ended presenting the brainstormed ideas.

But we got another surprise after that as well. We created a 51 slide PowerPoint, giving each idea it's own slide (as well as a title slide), and presented it to our class to find that people thought that the other ideas we had thrown away were more interesting overall. All in all, from our list of 50, 14 various ideas were mentioned by peers and professors alike as something that could be really interesting, and that made us sit back and think. While 3 of those ideas we had already thought about going forward with, the rest we hadn't. Each team member got a chance to think about the game idea they thought about on that list and what could make it appealing, and I created a bunch more "game sketches", micro design documents that give a sense of flavor and direction to the idea, and after a long hour we whittled down to these 3 ideas: (keep in mind that all titles are placeholders.)

Point of the VieweR/ 2D VR Platformer:

Largely inspired by having a photographer professor dad, and growing up being taught about various different camera techniques and terminology like foreshortening, Point of the VieweR is a Virtual Reality 2D platformer, where the player must position their head, and look in specific ways in order to make jumps possible. As way of explanation, lets take these 2 images:

Let's imagine that the red cylinder is our main character, and we want to get them over to the white platform over to the left. There's two problems with making that jump:

1. It's too long, and our character can't make that gap.

2. The second platform is actually in the background, about 50 Unity Units away. It's more apparent in the editor or while wearing a VR headset. 

But as far as image rendering is concerned, it's a 2D scene, which we can see from a fixed camera perspective. But what if we could change that camera perspective. What if we could move the camera a bit to the left, and then look towards these two platforms over towards the right?

As if by magic, these two platforms look like they are right next to each other, and the gap between them is smaller, making it possible to make the red cylinder jump between the platforms. By using camera foreshortening, and VR head tracking in order to move the camera, we can make that jump possible. In addition to making simple jumps like this, we intend to have other types of platforms that experiment with how a camera, or a VR point of view could be interesting: platforms that only show up if you stare at them for long enough, platforms that show up only if you aren't looking at them. Platforms that show up only if you are close to them, or far enough away from them, and much more.

Zone of Chalk:

An infinite runner focused on momentum, and speed, where you have to draw your own path. You find yourself trapped inside a chalkboard, and the spirits of erased creatures have possessed the eraser and are trying to erase you. There is no floor in the land of chalk and you must draw your own as you run. The player draws the floor as the game runs for you, but the player must be able to draw paths that avoid obstacles on the board, such as existing drawings, scratches, pull down maps, or magnets. In addition to having to draw your own path, the shape of your path matters. Going downhill is the fastest way you can go, but you have limited space to do so. A flat path gives you a fairly steady speed, while going uphill makes you slower. So not only do you have to draw the line in order to avoid objects, you have to do it in such a way that you try your best to maintain your momentum. If you slip up, and slow down enough, you get erased, and it's game over.

RHYTHM STEALTH:

This one has been fun to try to design, as it originated as a throwaway idea, and has grown to something much bigger and beautiful, and then changed again to try to bring it within technical means.

Source: http://static1.gamespot.com/uploads/original/416/4161502/2853813-0001.jpg

Envisioned as a top down rhythm game like Crypt of the Necrodancer, players must move onto other tiles to the beat, not of music, but to the "pulse of the house", a mysterious magical force that houses, banks, mansions and all sorts of buildings with valuable objects are all under the thrall of. Laying around the house, on various pieces of furniture are all sorts of jewels, gold, precious artifacts and more. You must steal all (or as much as you can) while navigating through the house, trying to find the source of the pulse that's making you and EVERYTHING else move to the beat.

Security cameras swing around on the beat, guards step and turn on the beat, doors swing open and close to the beat, guards conga line to the beat, and you swipe everything you can see on the beat. We intend to make each level built on modular assets so I, or anyone who wants to make a level just needs to plop down some floor, cameras, guards, and loot, and set a Beats Per Minute per level in order to create level after level, each one focusing on various different ways that mechanics can interact. What happens if you have a level full of guards, and need to shuffle them around by being spotted and slinking away? What happens if you rob a place filled with security cameras, which give you a small window of opportunity to sneak through? In addition to just having your beat based movement, you have an assortment of items you can use to aid you:

(Please Don’t) Stop The Music: Allows a brief pause in the beat… and everything else. Time the use of this powerup when a guard is looking away, or a door is open in order to speed through a house.

Slow Slow Quick Quick: Salsa your way through the level by slowing down the beat, allowing you to study patterns or get through an area that was moving too fast for you.

Nowhere Man: A smoke bomb, allowing you to evade being caught, even when a guard sees you.

As well as a potential for other items in the future.

I feel like all three of these are really solid ideas and I'm looking forward to seeing what my team and I accomplish over the semester. Each of the programmers and I have all taken a prototype to bring under our wing in order to see how difficult each one is, I'm taking the VR platformer, while Dan is taking the Zone of Chalk idea, and Garret is taking the Rhythm stealth game, this way we can spread out the work load of 3 prototypes across the team and get towards our "final" game sooner. 

What's our final game? I don't know yet, but I'm personally gunning for Point of the VieweR, as I think it would be a lot of fun to make, and we can do a lot with various platformer tropes in VR. Other team members are also really pulling for the Rhythm Stealth game, so we might end up going down that road. Either way, this semester looks new and exciting, and I'm excited to see where it goes.

It's been a while, hasn't it?

After a long while, what I set out to do this semester working on Dream Surgeons is done! We have walking, smooth interior transitions, an experimental UI, an inventory system and Puzzles! A lot of them have graphical errors (that log plank in the main square should be in the water not in the center, items go to the right rather than left of the UI), but all puzzles are in. I didn't have as much time as I wanted to work on stretch goals (both playable characters, interactive dialogue, etc), but for 3 months, along side another game (to be announced soon!) and other classes, I did quite a lot.

So what's next for Dream Surgeons? For now... nothing, at least nothing publicly visible. Over the summer and next year I'm going to be working on finalizing the script and working on designing all the puzzles and areas, and once those are set in stone, make prototype, temp art layouts like this. Once those are done, I want to do a code pass, cleaning up everything, get dialogue running, etc. Once that's all done... I don't know. I really want to make The Dream Surgeons in stop motion, but getting artists and clay is expensive. I might run a Kickstarter or something once The Dream Surgeons is fully playable, and needs a coat of paint like art, music, sounds, and possibly voice acting.

But for now, I'm taking a brief break from The Dream Surgeons. Working on one small scene, bumping my head against the wall (though with plenty of help from peers), I just want to step away from it for a while.

Please excuse the artifacting on the .gifs. I need to find a better .gif maker.

With loads of help from my fantastic roommates, I now have a fully functional* UI system in the Dream Surgeons demo. This concept came out of an idea I had for a final project last semester. Most point n click adventure games have lots of variance on how they play, control, etc, and UI is a big split as well. Most games fold the settings and save buttons into the inventory, but either make the inventory hidden on the sides of the screen, and make it show up when you mouse over that region, or make a button that brings it up once clicked. Neither really are satisfactory solutions, at least to me. And I came up with a system that naturally is hidden so you can enjoy the art of the game, but could also allow you to keep it up if you "lock it" in place. 

Full UI flow

Next step? Put some items in that blank inventory space. And work out how to pick up items.