And we're off!

Sunday came, and a massive 2 hour meeting with it, helping us understand what steps to make going forward. Before the meeting, I had worked with Julia, one of the artists on adapting some of her sketches into a UI Prototype.

The original sketch from Julia

Making interactive PDF's is something I set myself down to learn last year, I adapted this sketch and make some photoshop mockups using ingame assets I found poking around the repo. And then from there I took screenshots of every existing UI menu in engine, and stitched them all together.

It's rough, but it's much cleaner than the current UI:

Buttons are scattered all over the place and aren't really necessary all the time. The checkmark button is going away, as programmers this week have been working on an auto detect system that automatically checks and accepts correctly drawn kanji. We really only need 3 permanent buttons: play audio (pronunciation of kanji), undo, and hint. These 3 buttons are now permanently affixed to the bottom right of the screen, and any additional buttons can be moved down there with small glyphs as well. Something else about the above screenshot is how weighted it is to the left. The game takes place in the center, while the tutorial takes up 80% of the right 1/5th of the screen. This means that players are looking to the left every few moments for a game that takes place in the center of the screen. We plan on moving this tutorial UI above or on top of the game board, with freshly updated text.

The tutorial as it stands is wordy, overly formal, and too tutorial-y. It's in a game about samurai, with mention to them once at the very end. So this week I was giving the task of transcribing the entire player experience for the tutorial:

What words show up when, what animations for hints play when, when is the player left alone, and simplifying and decorating that old crusty text.

Even this is subject to change, as we have made the decision to go with smaller, starter kanji and teach combinations of them that make different kanji (think letters not words), but it's much more flavorful, gives encouragement,  and is less redundant. Tomorrow we meet again to discuss what's left in terms of getting things ready for Greenlight, but we've already made a lot of progress, and our initial steps in cleaning up the rough stuff in the original capstone prototype.

(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.