One of the reasons why I wanted to join Legitimate Studios on their quest to bring Dan Shredder to completion was that it spoke to me on a deep level. I was the one percent that played Guitar Hero excessively in middle school, and was enthralled by rhythm games. I was also that heavy metal head kid during that time, wearing an Iron Maiden shirt and listening to Megadeath while riding the bus to school. Dan Shredder seems that way to me. When I envision Dan Shredder rocking his way through hell, I imagine a very burly dude who has a deep passion for metal. In the times I can contribute to the world building and creative aspects of the game, I always mention how previous games such as Brütal Legend and earlier Guitar Hero games took themselves. They seemed more of a tribute to metal than mocking it. We should follow by example of these games. One of the largest modern perpetrators of this idea is Jack Black. Voice of Eddie Riggs, the protagonist of Brutal Legend, and front man to the band Tenacious D. Tenacious D in the Pick of Destiny was a movie released a decade ago that seems to match the type of metal that I imagine this game to be. One of my goals for this team is to help this game really show my passion of metal to the rest of the team and help build a love product of Heavy Metal that will rock the world.
One of the most cool things about rhythm games like Guitar Hero was that you have this feeling that the notes you are playing actually make sense to play and feel nice to perform flawlessly. This blog post is mostly going to be about Guitar Hero note theory.
There are a set of patterns in Guitar Hero that are common across many songs. One of the most common ones are scales that go higher or lower.
The most extreme case of this in Guitar Hero 3 is the Mosh 1 section in Slayer’s Raining Blood. This entire section is just the following pattern in the image repeating with occasional breaks for a chord. It is often considered the hardest part of the song, however, it is in essence the same pattern. When played correctly, one rarely has to strum, it evokes a feeling of zen where all there is is you, and the feeling of a cascading waterfall, of blood. This pattern does not have to be used with just four notes descending, it has been used in many other places, including patterns of 3 notes ascending as in the Guitar Break in Jordan, by Buckethead or as a repeated three note triplet, such as in Solo A in Metallica’s One.
Another popular technique that are in a variety of Guitar Hero Songs are trills. They are two notes repeated over an amount of time. They can be at a decent pace, as in Tonight I’m Gonna Rock You by Spinal Tap in Guitar Hero 2, or an insane blistering pace as in Surfing With the Alien by Joe Satriani. There are various techniques to play these notes, the version I use is to root my index finger on the lower note and use my middle finger or ring finger to do the hammer-ons. For faster ones, most higher level players actually take their strumming hand and use it to help fret.
This may seem like a weird blog post, but it has a purpose. One of the main goals of Guitar Hero is to make the player feel like they are playing the actual instrument, and not just some plastic toy. Having to use multiple hands in order to play notes, especially trills has been common in guitar playing since Eddie Van Halen’s hayday. Using all four fingers to play a riff is how Raining Blood is actually played.
One of the first rules about Game Development is that one needs to learn how to adapt to foreign environments quickly or else one will fall behind. Moving to a different team is can not that difficult, a new code base, maybe some high concepts about what the game’s architecture is. However, the new team that I moved to would be the most difficult engine changes I have faced before.
A Chinese philosopher once said, “千里之行，始於足下” , “A thousand miles begins with a single step.” This is true for both grand conquests and game production. Going back to the very formation of Team NAH, it was one that was never stressed. Some teams formed due to friendships, others formed from the remains of Production 2 teams, some were “formed” out of the leftovers. Team NAH in the beginning, had never worked with each other on a single game. We quickly formed as a team, and left it as that for months. It was not until halfway through the summer, that we realized that we should do some preparation/discussions about the coming semester. Still nameless at this point, we would suggest game ideas, usually tagged along with some joke or gimmick. When it came time to actually name ourselves, we were stumped. On a walk home from work one day, I jokingly said we should just call ourselves, “Names Are Hard.” We all liked the name and it somewhat reflected our relaxed nature of a team. It may have taken a couple of weeks to get the workflow going, but when it did, we were walking at a brisk pace. We planned everything in advanced so we know when things needed to be done, and what was needed from us for that to happen. By the end, all of us had a product that we were happy with. Even though we did not move forward into production, I feel like we all moved forward in our respective disciplines.
Individually, I believe that I am not a creative person at all. Aiding in the creative process of the team is something I can do in a roundabout way as a Programmer. Something I heard other Programmers talked about near the beginning of the semester was the “Programmer’s Veto.” In essence, the Programmer’s Veto is the idea that since you are the primary way to get ideas or mechanics into the game, then you have some extra say in how it exists in game. Now, some people would think of this as, “I don’t like this idea so I’m not going to do it” which is a toxic mentality, however, the Programmer’s Veto can be used in a positive light. Since I was usually closest to the game integration wise, I feel like I had a better sense of what was in and out of scope with the current state of the game/technology. This may sound like I was actually hindering the creative process instead of contributing to it, I can think of one time where I said “I don’t think we can do this with the time we have left.” After explaining to the team why I thought this, they agreed with me. The way I most often added to the creative process was the way I would add features to the game, sometimes sparking new ideas for other features.
There was one time throughout the development of The Root of the Problem where I had to think about how what I was doing was going to be used by other members of the team. Rewriting how enemies spawned came out of nowhere, and was a great way to spend a restless night. Previously, enemies could only be spawned with one wave, and in a very specific way, something that that needed to be changed so that spawning enemies could be done easier. When I was rewriting the system, the one thing I had in mind was, “What would be the easiest way for Scott [our Designer] to make interesting enemy arrangements.” After a couple hours of hacking away, I finally reached a point where spawning enemies was much simpler and more intuitive that the previous state it was in.
Some important key decisions that I had to make throughout the course of the semester was Git vs SVN, Unity vs Unreal, and The Root of the Problem vs our other prototype, Blind Faith. To be fair, the first two were questions that were raised before we even started development. The Git vs SVN debate is one that seems to be a foreign one to many of my peers. I know many teams that went with Subversion because they and everyone on their team already knew it, which are valid reasons. After talking with the team, they said that there was no preference between Git or SVN, so that might beg the question, “Why did you go with Git then?” The answer to that question is that over the course of the summer, I was growing accustom to Git and saw that it was being used much more than Subversion outside of the educational environment we were all used too. It may have caused some troubles when everyone had to switch from the SVN mindset over to a Git one, but I still think it was the right choice.
The next major decision was Unreal vs Unity. One of the main reasons we were wanting to go towards Unreal was the fact that from the start we did not want our game to have the “Unity” look that so many games before it had. We wanted to stand out and have people think that our product was not made in Unity. The downside to Unreal however, was that very few of us had ever done anything in it, let alone make a game. After spending a couple weeks during the summer trying to navigate through Unreal’s, at the time, atrociously lacking C++ documentation, I told the group that if we were to use Unreal, we could make the same thing in Unity at a much faster pace, and it would probably be much more stable. In the end, the main way to not have a game look like an “Unity Game” is to create a unique art style that either abandons the Standard Shader, or uses it to it’s fullest potential.
The final decision was probably one of the hardest and most important decisions I, and the whole team had to make. We were all very into the idea of The Root of the Problem since inception, but most of the faculty we talked to did not like the idea and loved the premise of Blind Faith, a game where the player helps guide damned souls out of hell by creating a path for them. I vividly remember sitting at dinner one night with the team and we were all discussing what game we should go forward with. Whenever we talked about Blind Faith, it seemed we all had a much less passionate tone about the game, compared to The Root of the Problem, where we would all sound excited to be working on it. We all knew it would be the harder game to pull off, and we went forward with it knowing that. The deciding factor for going forward with The Root of the Problem instead of Blind Faith was that we all wanted to make a game we would have fun playing and have fun developing.
Moving forward into Production, there are a few things that I learned that are not nice to have, but rather required to have in order to have a functioning team. The largest one was camaraderie and communication. Throughout the course of the development of The Root of the Problem, I wanted to keep working on the game because I wanted to keep working with the team. Looking at our slack, you would see both channels where we would just spam gifs, while at the same time daily scrum channels. This allowed us, or at least me, to feel comfortable addressing any concerns that there was with the game. Wanting to work with your team is probably the most important factor when it comes to game development.
“By the way you guys, I signed us up for GMGF.” Being told this was somewhat frightening news. GMGF, or Green Mountain Games Festival was about two weeks away, and our game was not in a state that I would be proud to show off to the public. It was in a raw state that many would consider to be visible still in the early stages of development. Not that much thought was put into the game itself, the systems were there, but there was not that much attention put into how they were structured. Various bugs were in the game that made restarting the game a thing that had to be done very often during QA Tests. Getting the game to a point that I would want to show it off to the public would take a large amount of work, but we managed to pull it off.
On of the primary concerns with the game was that spawning enemies was very rudimentary. You hit a trigger and it would spawn X amount of Y enemies spread across Z spawners. There was no way to offset enemy spawning or make conditional spawning. One of the first tasks I set myself up to do is rewrite how enemy spawning works. After a few hours working on a side branch, I emerged back with a much more robust way to handle enemy spawning. Now, each area has a set amount of waves. Each wave has a set amount of spawners that that specific wave can spawn from, what types of enemies can spawn in this wave, and how many enemies will spawn in this wave. The most important feature of this new system is that a designer can set if the next wave spawns off of a time delay, or off of a percentage of enemies being dead. This allowed us to set up a much longer level and more unique spawning systems. The best part of having this new spawning system is that it is very simple to create a new area and set up how the enemies spawn there.
The second feature that I primarily worked on in order to have the game be ready for GMGF was adding Quality of Life features to our grenade weapons. Heading into this sprint players had an unlimited number of grenades, couldn’t control how far they went, and couldn’t tell where they would end up. To address these features, there were a few simple changes, and some more complex changes. The simple one was to have the grenades use an ammo system that you regained more from enemy drops. The more complex fix was to preview how far the grenades would go. Due to how the grenades gain their trajectory, the path of the grenade is unknown until the object itself is spawned. To allow for a preview, I had to move a lot of the calculations from the grenade itself to the object that spawns the grenades. After that, it was a matter of graphing a kinematic equation, which thanks to some google-fu turned up Line Renderers being able to do such that.
Adding these changes to TRotP made me feel much more confident about how we showed the game off at GMGF, which a full report of how it went will be written in the upcoming weeks
There have been many a Game Developer to learn the hard lesson of, “Don’t commit anything right before showing your game off.” While this holds true, sometimes, it has to be done in order to make sure that what you are showing off does in fact, work as intended. That is how “OOPIBROKETHEBUILD” was created.
“OOPSIBROKETHEBUILD” is the one version of The Root of the Problem that is not in our builds repository, it only exists on a handful of computers in a room, probably erased at this point in time. It is a build of the game that has the unique feature of not having a version number. The whole reason why “OOPSIBROKETHEBUILD” exists is because the version of the game we were going to be using was unexpectedly broken to a level none of us knew going in. I was there setting everything up when we noticed a large amount of controller issues. Player 2 controlled Player 1’s attacks, Player 1 controlled Player 2’s weapon changing, sometimes there was a Player 3 so one person would have had to use a controller. In the state it was in, the game was unplayable, let alone testable. Now, depending the team, a multitude of options are presented when the build is non-functional. One can either pack up and go home, persevere with the broken build, or the option our team took; try and fix it. “OOPSIBROKETHEBUILD” was the product of trying to fix the problems very quickly, and it did work for the purpose it was needed for, but making “OOPSIBROKETHEBUILD” really showed how Team NAH interacts with each other as a whole.
What that interaction is is hard to write in words. No one blames anyone when something doesn’t go according to plan, we all shake it off and figure out where to go from the current point. With “OOPSIBROKETHEBUILD”, we all saw that the build was broken, and instead of trying to figure out what broke it, we decided on making a new build so we can keep on testing. As a team, we are all friendly with each other, and I think part of that is because of how we see The Root of the Problem. It’s a game we all enjoy the concept of, and enjoy working on. It’s an aspect I don’t see in other teams, that might be because I don’t see the internals of that team and how they interact, or it is not just there. All the other teams seem very serious about their games, while we are being serious also, but having fun at the same time, and I think that shows in our work and our presentations.
One thing that holds true for most modern gamers is the idea that, “Graphics rules all.” I believe this to not be the case, however, graphics do help hide a game’s flaws, or helps make a game standout amongst its competition. After almost a month of development, The Root of the Problem has it’s own art assets in engine, alongside finding a look that sets apart from the rest.
Due to this week being different, due to not having classes on most of the days, one would expect there to be either no work done, or a substantial amount of work done. Thankfully, Team NAH was the latter, and went into overdrive over this long weekend. We only had one of our enemies modeled going into this weekend, and coming out, we had that enemy modeled, rigged, and having an idle animation, our main character, Salt, being modeled and rigged, and having all of these being in engine and put into use.
Although that seems like it was only our artist who was doing a majority of the work, all of us were at it. As a team we went to QA Test our game twice since the last week. The first one giving us valuable feedback about how players felt about player combat and interacting with each other. With that information in mind, we refined the player controls and how the camera works. Now making it so the players can not run off camera from each other, causing problems such as the camera not dealing with elevation, random bugs causing parts of the game to break. All of which amounting to “OOPSIBROKETHEBUILD.exe”
For the past couple of days, Work on The Root of the Problem for myself took a pause for a combination of reasons. The primary reasons for not working was being under the weather, and some celebration for moving into the Deep Dive portion of TRotP. However, not working directly on the game does not mean that it has been a productive week.
In place of our usual Saturday meeting, we took the time to explore one of the inspirations of The Root of the Problem, Magicka. Magicka is a four player game where each player controls a Wizard who can use keys on the keyboard to cast a wide variety of spells to hurt enemies… or your allies. We spent about three hours going through the Story mode seeing what we actually liked about the game and how it does it well, and what we didn’t like about it. One thing that we all agreed was how the camera only grew so large, and after that, restricts the players movements. Outside of finding game systems that we enjoy and we think would work in our game, it also was a way to have an efficient Team Building Exercise. And also showed we all enjoy the cooperative aspects of a game where one can also unintentionally hurt their allies.
The next day, we decided to have a more traditional meeting, where we planned out everything we want to appear in The Root of the Problem. Doing this allowed us to make clear what we are all expecting from a vertical slice of the game and what is needed to get to there. We started with five core features we want for the game, and then made user stories for each of those five features, covering every facet of what would be needed to accomplish that goal. Once we figured out what was needed to be done in order to accomplish the vertical slice, we figured out what was considered the highest priority to finish first and added them to the current Sprint.
For the past couple of weeks, Team NAH has been a search to find what makes Weed Whacker different from the rest. A reason for it’s existence. When asked what our core mechanic is, we would fumble about, unable to provide a clear answer. We all knew what we wanted out of the game, but unable to describe it in words. We almost decided to not go forward with Weed Whacker due to not being able to fully define what we envisioned the game to be. But over the past couple of days, we have found our voice.
We discussed over dinner what project we wanted to move forward with. After reviewing what professors have stated to us about both projects, we noticed a trend. All of the faculty that we talked to adored the Control the Level idea and prototype. They said how it is more design challenging and more can go wrong with Weed Whacker. We understood their sentiments, and that almost convinced us to go forward with that project. But in the discussion, we kept going back to Weed Whacker, and how much we enjoyed discussing it. This helped us ultimately decide why we are going forward with Weed Whacker. We want to make a game we would enjoy making.
A majority of the time we would discuss things related to Control the Level, we would often discuss it as if we were making it because other people liked it. If I would describe our game to someone and then state who was on the team, I could only think that they would respond with “I did not expect that kind of game out of all of you.”
Now that we have decided on Weed Whacker, we have refined what we are looking for out of the game, and how we are going to deliver that experience to the players. We’re making a game that we will enjoy playing
For the past couple of weeks, one could say that each member of our team was working on their own branch of a repository. Which, seems all fine and dandy, except for a repository to work properly, everyone needs to merge their changes back with each other. Our team was not doing that and it was noticeable to others. “Yeah, it’s pretty apparent that you were the only one working on the prototype” was said to me within the past week. With that statement, I start to evaluate the current state of the team.
At that current point, I was chugging along with our second prototype; a game where you manipulate the level and not the character. All I knew about the game was that the character always moved to the right, and you could place, and remove blocks in the level. With that in mind, I hacked away at exactly that. Because we did not exactly have a theme down, I just went with every programmers placeholder object, cubes. Because they were cubes, I got to see what the actual game play would be, and it did not seem that enticing at all. The actual game play seemed very boring. Just place the blocks before the NPC got there, then wait for them to get there. It suffered from the “Escort Mission” problem a large amount of games these days exhibit this problem. When guiding an NPC from point A to point B, they will walk slightly faster than your walk, and will run slower than your run, leading to a large amount of time standing still, waiting for them to catch up. I echoed these statements to the rest of the team, but fell on deaf ears.
Due to the lack of design input that was happening, I decided to start work on a third prototype, one that the game play is generated from multiplayer interactions and player versus player aspects. It originated from how in the game Castle Crashers, after fighting together to save the princess, you fight against each other for the right to kiss the recently rescued princess. That sense of friendly competition combined with the rpg elements of Castle Crashers lead to the idea of a game where players fight, but also obtain currency in order to change how their character plays. With that idea in my head, I started on a prototype, without asking the rest of the team. After a few hours, I had a prototype that was playable between multiple characters, combat, and upgrading your character. Now to show it to the team.
Earlier tonight we had one of our meetings that was not a SCRUM meeting. I stated that I made a third prototype and it was ready to show. Due to some technical difficulties, we had to wait to get the prototype running. During this time, I suggested that as a team, we go over the following questions for each of our prototypes:
1. What is our intent? What do we want to accomplish?
2. What is the player engaging most of the time? What is this core experience?
3. What technology best facilitates this interaction?
4. What will the game look like?
5. How can we quickly test this idea?
Surprisingly, by doing this, we all found out what each of us thought about each of the prototypes and how the games would end up. Because of this, we were all able to figure out what direction the prototypes the games should take and which directions excite us the most. For the Control the Level idea, seeing as more of a game where you create an attachment to the NPC’s and them having perma-death if you mess it up. Coming out of the meeting, It seems like we finally merged onto the same branch and are a much stronger team