Development Blog 10/20/16

Feeling good

Well, our first week in Proof of Concept is complete, and I gotta say, I feel pretty good. Over the past couple of days, I have been working heavily in sound design, our narrative plan, and exploring our secondary mechanics moving forward in our game. The rest of the team continued along our current path, with our artist, Emma, beginning work on our characters and making some beautiful assets for our main game loop. Our programmer, Ryan, worked on developing some super cool particles and is now moving forward into developing some of our more complex books, which he is excited about. Our level designer, Winston, has spent the past few days developing props, but is getting ready to start rapidly prototyping levels which we will be testing in engine.

This week, I really want to talk about our team. Honestly, right now I feel really good. One of the things that is really encouraging about it is the energy that everyone has while working on our project. No one is feeling bored or like they don't want to do it. Everyone is engaged and just having fun with the tasks that we have, and I think it has been a huge asset to our development. From the get go, the plan has been to make a game that we enjoy making, and if we make it through to next semester then awesome, but if not, at least we made what we wanted to. I think this has been a huge benefit to team spirit and we are not as stressed as we would be otherwise. By choosing something that we want to make and that we would want to put our energy into, we were able to benefit down the line because people are putting in more work then they would necessarily need to. Sure, at the end of the day, we are all professionals, but there is some true benefits to your project when the team is happy and moving forward together. We have done a good job with talking out our difficulties with each other, and we have been able to assist or rework things to make sure no team member is being held back by anything. It's been excellent for team spirit. And I think that our excitement as a team has been translated onto our peers and professors. It's always hard to gauge exactly how you as an individual are performing within your group, and similarly how people perceive your group to be performing. It's something I personally struggle with, and it leads me to second guess myself quite often, and I know our team has quietly wondered how everyone else would react to our game. The positive feedback we got through our QA sessions and from our peers who have seen our game, I think, has really helped our team's confidence. It's always shaky when you first start a project, because you aren't really sure how people are going to react to it. So whenever you start getting those lit-up faces and bright smiles, the whole thing really starts coming together.

Over the years at Champlain, I always was quietly dreading Capstone. We were always told that it was going to be the worst experience at Champlain because of the stress and difficulty of what we were being presented with. Whether because of my experience in other classes, the people in my team, or my own personal development, all I know is I am having more fun working on our project this semester then I have in a very long time, and I can only hope that this is just a sign of things to come in my future.

Development Blog 10/13/16

Moving Forward

Well, today we challenged to move forward into the next section of Capstone, Proof of Concept and past Deep Dive. This past week has been about putting together all the things we need to qualify into moving forward.

We had already established the art pipeline effectively, so the next thing on the list was the audio pipeline. I took the main reins on that because I have built out audio pipelines before in other engines, and with the way that Unreal handles other assets, I figured it couldn't be too difficult. Before building the pipeline, though, I needed to do some research. Building a couch coop game, music and sound effects play a large role in the experience the player ends up having with the game. So I went through and listened to the OSTs of our main competitors to get an idea of what elements to utilize in our game. While upbeat tunes where a pretty frequent thing, we couldn't quite go for the same vibe. The reason behind this being that with our game going for a slight spooky vibe, something too upbeat would be off putting in comparison with the rest of the theming. So I took to finding some Creative Commons music that could act as placeholder in the mean time as we built out our own music. I listened to many tracks, trying to find something that would work not only for the theme of our game, but for games in general. Once I had all of the assets together, I was pleasantly surprised how easy it was to simply implement within the engine. The ease of access to the most complex options for sound in Unreal Engine will be a real benefit to our project as it allows us to do much more complex stuff then we could easily do in Unity.

We also did a hefty amount of QA this past week, testing our camera angles, sound, levels, and books in separate sessions. We also received not a single piece of negative feedback during our tests, which was a huge boon to the team. It is always energizing when the players you work so hard to entertain enjoy the game you make and want to keep playing. There were several occasions where players had to be physically stopped from playing anymore because they refused to stop. These QA sessions were, despite this, productive. Despite working with unexperienced testers, we were able to effectively extract useful feedback from the usual myriad of "add everything" feedback that young testers can be fond of by really focusing on directed questions. Our QA revealed what we sort of expected to see: the impressions of the books really determines on how the level is set up for players to interact with; the level had the majority of people feeling its medium difficulty while outlier found it easy or hard; our camera angle was going to be top-down; the music was an excellent fit for the game; etc. etc..

Then there were documents. Whether for the better or the worse, I tend to always complete those last on my list of things to do. For this particular instance, it worked out for the better. Without the stress of all my other work coming down on me, I was able to really think not only about the content of the documents, but also the actual design of the documents themselves. While my documents have always been functional and have always been well received, they haven't been something that I could look back and be proud of. So this time, I really put forward my best effort on this to create something that not only would serve my team, but would be something that I could really be proud. And suffice it to say, I was successful. I honestly believe this is one of my best design bibles ever, and am actually excited to make further developments on it.

And, of course, the icing on the cake was that we did make it through to Proof of Concept. Our team was once again able to go through easily and we were praised for our presentation and design plan. We have already made our plan for the next Sprint and I can't wait to push forward even more.

Development Blog 10/6/16

Deep

This week was our first week within deep dive, and my god, there is so much to do. The first thing that we began working on was our art pipeline. This was our main focus because moving forward, we wanted to minimize as little work as possible to organize and resetting our levels, assets, and design, and focus more on the actual development of these things. It was set up by our programmer so that any art assets that will need components in our game will be established by him first, and set up to work so that our artist can simply replace pieces in the blueprints as needed, with no extra input. Any pieces she replaces will then automatically replace whichever version in the level, allowing for smooth sailing as we continue this semester.

The next set of changes spawned from our design discipline review. During this, we pitched our game again to one of our other professors, and talked about what it needed and where we should go from here. Going into our meeting, we knew that we needed to add more to our game, it was just a question of how much, where, and how to go about doing it. Which is a taller order then what I am making it, but we knew that we would figure it out eventually. The first question we tackled was the players motivation and why they were doing what they were. We hashed out several ideas until it eventually came down to, and I am paraphrasing here, an evil has befallen the library, and as a subpar-misfit student, you believe that this can finally be your chance to shine by rising up and taking out this mysterious evil. This would allow us to give direction to the player as to why they are doing what they are, as well as set up a context for the world to exist within.

After this, we moved on to the main question we were dealing with: gameplay. This was our primary concern and we addressed it by discussing two things: our level design philosophy, and the systems that the powered the game. The first thing we took on was the level design. We did this because many of the games that we will be in competition with focus primarily on simple mechanics and complex level design. However, in our discussions, what we decided made those work were contextually different environments and more players and tasks for the player to do. Often times these tasks were repetitive and didn't offer much to the player in anything other then a hindrance. What made them fun was the interaction between four players and the crazy level design. Because we are working with 2 players, and don't feel incredibly interested in moving beyond that. we are in a bind compared to our competitors.

So what from a systems side could be done to change up gameplay? One thing that was brought up during our discussion was what impact the enemies being books really had? Most people use books to learn, so perhaps there is something we can do with that? What evolved from this was the idea of learning spells from the books. Whatever player eliminates a book first, gains that books individual spell such as the fire spell for the fire book. To pair this to work within our game, we are planning on setting up the levels to work in a style of phases. We had already planned out the books to work in waves so that players would be able to handle things and not run into situations that were unfair, so as a partner to these waves we added traps that can go hand in hand with the books while offering more difficulty to the waves. This gives us more flexibility in how we develop waves, and builds up strategy and things for the players to do and interact with.

Progressing the rest of the week really focused on creating many of the docs that are not necessarily engaging but are necessary. It was good to have these though, as it allowed for more introspection and creation on what can push our game farther.

Development Blog 9/29/16

Challenging

This week my team decided to challenge to move forward in development. But before we get to that whole mess, this past week we finished our work on our third and final prototype, Sleepy Ninja. This had been one of my personal favorites to develop, as it was my favorite of our original ideas.

Sleepy Ninja was conceptualized during a late night anime binge, specifically Naruto, an anime focusing around ninja in the briefest description possible. At the time, I was getting especially tired, and the thought came to mind "Man, this stuff would be really hard to do while you were sleepy or tired." This sent me down a rabbits hole trying to figure out how this would work in a game form. It eventually became a 2D casual stealth platformer that focused around a sleep meter. This sleep meter controls your ability to move, jump, perform actions well. The closer to awake you are the faster you run, higher you jump, the stealthier you are. This creates an interesting twist in the level design, because their then has to be more then one possible solution to even the simplest of problems because a player could be on any part of the sleep meter. Difficult to perfect, but a great challenge as to what we want to do. 

In order to try and get a better idea of what the setting might be, I spent a large amount of time researching the different periods of Japanese architecture and what influenced the ideas of the period. I find that in my design, and in design in general, that we can become so focused in our own medium that we neglect to go out and research things from other mediums and the past, when that can offer some of the best inspiration to your design. So, I spent several hours reading about the historical changes that were going on, what the architecture meant at the time period and how the people felt about it, because that was able to communicate to a great deal about the people and culture we were developing in as well. 

Once I had completed my research to the group and we decided from it to make a combination of the Edo and Heian periods in order to create a realistic, but still fantastical universe. With our setting in place, we began developing the levels, art, and the prototype itself. Once the prototype had been complete, we brought it before QA and had incredibly positive responses. Players couldn't get enough of the game concept and were very excited to see what more could potentially exist for the game.

The Decision

In the end, though, our decision for our game to move forward with came down to two things: Fun and Scope. Twin Stick Cloner was able to meet the Scope aspect, but the game wasn't going to be as fun to work on. This led to it being immediately scrapped by our, because if we have a choice, we should be having fun while making our game. This brought us to Spellbook Rush and Sleepy Ninja as the two possibilities for what we would move forward with as a group. We had a very health discussion about the possibilities for each game and what each could offer. In the end, it was not a question of which would be more fun, but rather which was closer to being in scope. Each has individual problems with scope, but in the end one was closer: Spellbook Rush. Both games had been successful and well loved by players who had tested them, so it eventually came down to the idea that with Spellbook Rush, while there was still risk to deal with, it would be easier to deal with then some of the  problems that existed with Sleepy Ninja. From art problems to a difficult path to reach our goal, Sleepy Ninja was just not going to be feasible to do in the amount of time we had. Because of this, and the confidence we had in our game idea, we are moving forward with Spellbook Rush, and I for one, can't wait to begin real development.

Development Blog 9/21/16

Continuation of Initial Concepts

This week during our development,  we began to spend more time developing and nurturing our other two ideas for the project we would decide to go forward with: Spellbook Rush and Sleepy Ninja. Since we had a clearer sense of where each project was going from the beginning, we did not have to spend an entire week dedicated to a single concept, and instead were more fluid as to how we went about developing each idea. We did end up splitting our design focus into two separate sections of the week as it was easier to work through.

Spellbook Rush

The main thing we worked on this week was Spellbook Rush. One of the benefits that we had while working through the design on this game was that their was many known qualities about the way the game would work, look, and feel for the player. Spellbook Rush is designed to be a local co-op game where 2 young witches / wizards have awoken a library of spellbooks and must run around a quiet the spirits within before the librarian comes and gives you detention. We already knew that the game was going to be going for a cartoony, cutesy look to it, so while developing obstacles and levels for that, it was easy to set a narrative context around a certain object or idea. The team was able to set off quickly once we broke from our design meeting and we all got to work.

I began work rather quickly, as I had a lot of ideas I wanted to get down quickly. Because I am responsible for designing systems, it was also important for me to get down what obstacles players would need to interact with over the course of the many levels so I could pass them off to Winston, our dedicated level designer. The primary work that I began developing was the the different book types that players would have to deal with as they appeared in the levels. Messing with a few different types of ways to beat the books, I came up with about 8 different book types that could be present in the level and that would all provide a different challenge to the player. My personal favorite is the one that took a slightly different tone compared to the rest: the History book. I have always loved history, but I know many people find it to be one the most boring subjects imaginable, so this enemy is a tribute to them. While in range, the history book lulls players to sleep with his endless tales about the different ways that Sir Blair Flubwubbles and Sir Arthur P. Tubwuffles enjoyed their tea. The second player then has to go and wake up the other player so they can get back to work. While this book was slightly different in the way that it interacts with players and the subject it took, it is representative of the general theme that was taken with the books.

Once on the same page with the rest of the team, we were able to finish up Spellbook Rush and move forward on Sleepy Ninja. 

Sleepy Ninja

Sleepy Ninja currently presents the biggest challenge of all of our games, though we thought something similar about Twin Stick Cloner at one point. We held our typical design meeting, and although we had a lot to hash out and try to decide on, we thought we had landed in a pretty OK space. We had a fairly good idea about gameplay, the biggest problem that we are currently dealing with is we aren't entirely certain what narrative path and what setting it should take place in, as that is incredibly important for our art direction. Hopefully, in our meeting today and we will get one step closer to challenging for Deep Dive.

Development Blog: 9/15/16

Initial Conception

Here we go again, for one last time. Entering my final year at Champlain, I am daunted by one task alone: completing my Capstone, a 5 credit course taking place over the semester, with a chance to be given the greenlight to move forward into the next. I have been through the production cycle before, but never quite at this pace. This blog begins post-ideation phase, following my design decisions, producer experiences, and general highjinks.

Ideation

Moving past the introduction, our team of 4 has been in the works for a couple years. During my first production class, I had the pleasure of working with two of my current team members, albeit on two separate projects. On my very first project, I had the pleasure of working with Emma Campbell, our artist. I have yet to forget the night after our first meeting she had already developed fleshed out concept art for the game. The art was so polished that it ended up being the final product. Singlehandedly, she set the bar of what I began to consider a great artist.

A project later, I began working with a friend of a friend, Ryan Moss, our programmer. Ryan and I instantly hit it off. Our styles for developing meshed well together, and although we have different views regarding sleep, we knew we would prosper while working together. After we submitted our final game for the semester, I asked Ryan if he would like to form the beginnings of a senior team with me and the rest is history.

The final addition to our team was Winston Pemberton the 3rd, a designer like myself. I had known Winston since freshmen year, as we lived in the same dorm. While we didn't have tons of classes together, the few we did, we tended to work as a team. Where I excelled in one thing, Winston would in another and it was easy to bounce things off each other and ask for help when we needed it. Our design ideas rarely clashed, and even when they did, we would find an easy work around to the problem. 

As a team, we began the semester developing thirty different ideas before submitting them to the class. Some were simple, some complex, some impossible, but that is the point of ideation: Get out all the garbage and maybe you will find a gem. After sorting through all the cool, but impossible ideas, we had three that remained: Twin Stick Cloner (working title), Spellbook Rush, and Sleepy Ninja. 

The now

Over the past week, we have been spending time developing Twin Stick Cloner. The concept is rather simple: a twin stick shooter where you can spawn clones to attack the swarms of enemies. While the team found the idea to be a very cool concept, it was universally agreed that we would need to take a solid chunk of time to develop it. So, starting with our weekly Friday meeting, we set off.

In my own vision for the game, I had imagined the player-character being a rather weak character. From a design standpoint, this would force players to summon the clones, rather then try to simply go in guns blazing; from a narrative standpoint, this would allow for more character development as that character would be weak on his/her own, but in numbers, be strong. Furthermore, I instantly had begun thinking of different powers the clones could utilize to make them unique. Simply summoning a copy of yourself might be interesting, but it wasn't the type of engagement I had imagined the player experiencing. Clones, I argued, should be able to be used in combos, and be given different powers. Not only would that make them unique and exciting to the player, but we would be rewarding strategy and would be able to level design around gaining clone powers as a form of progression. 

To my delight, the team bought into my ramblings, and we began to develop further. While sketching out concept art, Emma figured that the best way to communicate to the player that they had gained the power of the gem was to use a staff with slots for gems. Then when we wanted to illustrate to the player that they had successfully added another form of clone to the repertoire, we could just put a gem in the slot. This also began the idea that players could only bring in a certain set of clones per level, in order to avoid being overpowered or having to micromanage the clones. This got me thinking, and while developing a possible control scheme for the game, I began to play around with using the shoulder buttons as the way to spawn the clones. This would allow for fast gameplay and would make it quicker for the player to build combos and deal with oncoming waves. 

At the same time, Winston was busy developing level layouts for the first three dungeons as a sectioned off vertical slice of gameplay. Ryan built out a functioning prototype for it with a basic AI and two types of clones. I developed out different clone types to test in game, and Emma took the idea of a weaker character and ran with it by developing a fun, cute art style with approachable enemies. 

However, we have gone as far as we can manage with our time limit, and must move on to explore our other ideas before finally deciding on one. If our development continues along the path it is right now, I am confident in our team moving forward in addressing problems and putting our foot down to solve them.