Cappin' Stones (10/13/2016)

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.

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.

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.

Blog