(In which I try to think of a Mel Brook's The Producers title for this blog series, and fail.)

After a long, and needed break, I'm back at Champlain College for my final semester. And with it, is weekly blog updates. After an excruciating, and eventful travel back to campus (thanks JetBlue!), I'm starting to settle in and get to all my classes, including my Senior Production team, Radiant Ronin. We will have our first official meeting this Sunday, and we have a lot of things to discuss.

Getting through the Green Light portion of Senior Production is very important to us, and we have a large list of things that we wish to address with the current state of the game:

1.  UI. The UI in Kanji Samurai is all over the place. There's too many buttons at once, the buttons are too small, the design of the buttons are flat and boring, there's text boxes giving tutorials to the side of the main play area, drawing attention to two different areas of the screen at once to new players, and honestly there's a bunch of redundancy. Considering Kanji Samurai is ALL UI, refactoring the UI as it currently stands is a high priority.  Julia, one of our artists is working on a UI storyboard that I'll stitch together as an interactive PDF, creating a prototype of our first pass at UI revamp.
2. Juice. The game is fairly flat and lifeless right now. There's no feedback at all in the game. There's a single sound effect, something our sound designer Connor is working on fixing, and the only indication of your inputs being right or wrong is the dots on the grid becoming green or red whether you are right or wrong respectively. Giving any kind of feedback, positive and negative on how you are doing in the game is a top priority, instantly resetting wrong kanji (with a fade), and giving positive feedback for getting things right. 
3. Rethinking the Kanji system. I'm not super up to date on the backend of the kanji system, as I've been on the team officially for 2 days now, but there has been some early initial talk of changing how inputs work. Currently it's based on stroke order and directions, getting the exact way that the kanji should be drawn. There's some early talk about possibly removing those systems and focusing on just the shape of the Kanji. In addition, a scoring system or a more clear progression system will help make it feel more like a video game, rather than a teaching tool, which it currently feels more like.

I'm excited to get to work on this project this semester, and I'm excited for our first meeting this Sunday, seeing how this team decides to take this Capstone version and bring it to release, but we are still in early days with little to comment on yet.

The FUTURE! A terrifying prospect. What does it hold? Who can say, but the future of Rhythm of the Night is pretty solid.

We've been getting art assets in, and the game is starting to look like more of a game. There's more static art to be made, some variations to make things look a little less monotone, and animations to get in, but in terms of art, the game is getting to a solid spot. Gameplay wise, work needs to be done on the rhythm mechanic, and the security cameras need to be implemented, which is something that can definitely be done in the next few weeks.

And for things that I need to do? I need to give the sound another pass, and create actual levels. Every level in the game so far has been designed by programmers to test out systems and their level design pipeline. While these levels are great, having designer lead levels could go a long way to show what I'm thinking about systems. I have a bunch of ideas I'm excited to get to work on, including one that I've barred myself from making. Since everything moves to the beat, and you can move off beat, you can get "off synch" with the level, making levels more difficult. I've thought about a level that you intentionally have to get off synch in order to beat the level. After talking with various designers, I have come to the decision that this is a bad idea. At least, for the first semester vertical slice. We want people to buy into the rhythm mechanic, and that moving on beat is desirable. By having a level that teaches the opposite, we break cardinal rules of our own game. This level could be something added on in the second semester, but it would need some retooling. 

Speaking of the second semester: we have 3 weeks to challenge through 2 stages. And while I like to be an optimist, this might not be possible. We need to get 2 QA sessions for each stage, and both QA liasons also need to be testers for QA in order to not fail, so we need to think of a QA solution. Plus, the amount of work required for each stage is large enough that I estimate that this next stage requires a 2 week sprint in order to get through, leaving us only one week to get through Vertical Slice. I'm not saying it's impossible, but it at the very least seems impractical. 

I'm going to give it my all, and what happens happens. But that is what has been happening over the last month, in 4 acts. I really like the progress we've made on our game, and I'm excited/nervous to see what the future holds.

I am now a Certified Scrum Master. Or, I will be, once I am sent the test to take. I spend the last weekend in a 16 hour Scrum training session, and I learned about so many ways we could improve our work load and scheduling.

We had been using Scrum at Champlain College in various sorts of capacities. The way we log hours and organize our projects uses Redmine, a team organizational board that features a Project Wiki, a task board, point and time estimates, and the ability to make and assign user stories. But the way we had been taught Scrum left a lot to be desired. It came after classes where teams collaborated on smaller games and were told to just meet up and work on specific parts of the project until it comes together. It came down to the team to determine what was most needed and what would work the best, and often communication errors or people missing meetings left people in the dark about what was going on. It wasn't until around Sophomore year that I recall hearing the word Scrum, and the concept of logging hours for tasks you did, and the ideas of User Stories were hastily explained to us. It felt like a chore, an extra layer of busy work that we "had to do because the industry does it", and looking back, not only was the way we were taught confusing, the way that it was implemented in practice for teams was confusing. There was no real reason for people to use User Stories, or have daily Scrums. Classes were structured in a way that we had deliverables due ever x number of weeks, so people just worked on what they needed to do in order not to fail, and everything was fine. With something more flexible as Capstone, where teams can get in and out of stages whenever they are ready, Scrum starts to make sense.

But what is Scrum? It's a organizational strategy where larger teams are broken up into small groups, or a team just acts as a small group. Before work starts, the team gets together and breaks down what they want to accomplish as a big picture for the game. For our game, the big picture ideas are: a rhythm system that feels natural to move with, security systems that act as blocking agents to the player, and levels to play in. Broken down, these three objects would become User Stories, written from the perspective of the user of the product. These three goals would ideally be broken down further, but as point of reference, they would show up in our Project Backlog, a list of things needed, listed in order of priority or difficulty, as this:

"As a Player, I want a rhythm mechanic so that I can move to the beat and feel in control of my actions."

"As a Player, I want obstacles, and challenges so that I may have challenge in this game"

"As a Player, I want levels that are designed around obstacles, so that I have clever puzzles to solve"

These user stories would then have tasks underneath them, created when the stories are, breaking each section down. For the rhythm mechanic, not only would we need to code the rhythm mechanic, but also design the buffer zone around it, test it, and iterate on it. Sound designers would need to create sounds for the beat, as well as other objects in order to sell the rhythm movement, while artists would need to create art assets that can visually communicate the beat and rhythm movement. Each of these pieces would be added as tasks to the task board underneath stories. After that, a meeting would occur where people volunteer to work on certain stories and tasks. Nothing is assigned to people.

Every day after that, until the end of the "sprint" a 1-3 week long session where people try to accomplish all that was set out in the volunteer meeting, a daily 15 minute meeting is held where people are asked what they have been working on, what they will work on, and if there are any roadblocks that other team members can help with.

In a business setting, all of the above is perfect, but in a school setting, things get a lot more tricky. Differing schedules, residences of team members, and time flat out makes a regular Daily Scrum meeting impossible. I'm looking into ways to hold digital Daily Scrum meetings in order to help solve some communication issues. But the rest of the Scrum methodology is incredibly useful, heading into the last stretch before presentations.

By setting out what is left as stories, and having people take responsibility of stories, we can organize what we are doing on a week by week basis much easier. Previously we would have a weekly meeting where we talked about what needed to get done and people said "Oh, I'll do this" but ended up working on other tasks that seemed more important as they came up. By having people stick to a rigid schedule of what they are doing each week, we can avoid feature creep and people working on things that aren't important. In our meeting, later tonight, we will be creating user stories for the rest of the project and assigning stories for this next week. Scrum will be a major asset going forward. Our game is so close to being done, we just need to push it for the rest of the home stretch.

With a rhythm based game, sound is fairly important. We had this pitch early on to have a sound system that dynamically brings sound in and out as you walk around a level. Something akin to the game Proteus

In Proteus, the beautiful sound and music "design" by experimental musician David Kanaga, isn't actually designed to provide a specific experience to the player. Some sounds play only in certain seasons or with certain conditions, sure, but Proteus was designed to dynamically create music with over 500 short sound samples, ranging from 1 second long, to as long as 2 minutes. Certain key moments of the game will make pre-determined "songs" that act as themes to experiences, but for the rest of the game, the procedural generated islands with randomly placed music playing objects provides the player with a completely unique musical experience. 

A small section of Proteus's sound folder, intrepid game designers and modders and built their own games in the Proteus engine by replacing sound files and model assets (also exposed) creating a new game with the same gameplay

Playing around with replacing and switching around various sound files, and playing with various Proteus mods had given me the idea to try taking this dynamic route to sound design, with no game ideas to follow up on. As we started work on a rhythm game, I thought back to my experiments with Proteus and wanted to create a sound library like that. We obviously would have a beat for the level, but each security system and element would have it's own sounds that would dynamically merge in and out of the audio mix and you progress through the level, essentially creating "music" with the game. Our professor told me early on that I needed to prove this system, and so while the programmers got to work creating a sound radius that the player character can hear:

Visualization of sound.

I got to work on creating specific sounds. Keeping to the Proteus mentality of sound design, I tried to keep everything musical. I wanted the guards to have a cartoony Bassoon melody, and after finding staccato notes on freesounds.org I pulled together a 4 note loop. Lasers were cold and mechanical and after finding what sold itself as an "online theremin", I created a punchy, bassy electronic drone. When it came time to find a sound for a security camera, I blanked. I had already used a synthesizer sound for the laser, and wanted to come up with an audio "walkthrough" for the level, so I decided on a temporary sound of a film projector. I threw all these sounds in Audacity, added a simple click track, and out came this:

It's rough around the edges, but it got the point across. The sketch posits the player walking from left to right, with sounds entering from the right and leaving on the left. If you use headphones, you can hear the sounds enter from the distance, linger, and then leave as the character walks through. I could have sold this element more with reverb, but trying to get a quick sample out the door to prove the concept worked. I later found an 808 kick, and an 808 clap on Freesounds, and sent each sound file to the programmers, each organized in their own folders in the repo with files explaining how to use them.

And the results... are mixed. The beat definitely works, though some people though the clap was another element. I wanted to have a two tone beat sound, but after feedback, a one tone beat may work better. Also the bassoon sounds sound cheesy with the rest of the sounds, and all pile on top of each other. What works as a 4 note solo above, sounds like a mushy mess. And the laser could use more work to make it more apparent. But beyond all of that, it was a great start. Once people heard the audio they were more sold on the rhythm aspect of the game than ever before. Despite some implementation issues, the first pass of audio was solid. Specific sounds need a bit more time to get the right feel, and not feel discordant, but overall I'm happy with where the sound is right now. I could have helped work on some of the implementation issues, except the weekend that they were being put in, I was doing SCRUM training...