Team NAH: “OOPSIBROKETHEBUILD”

3oEduLQn18x1NrheVO

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.

Team NAH: This Time, With Style

xTiTneepxdgjTsC9CU

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”

Team NAH: Magical Teamwork

l41lQEJuMxrn5xDA4

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.

Team NAH: Merging Into the Same Branch

wasteland

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

Team NAH: Meet Our New Friend Jenkins.

jenkins

Even before any work was set in stone for this team, I already was in the works for aspects of the development process that will help aid our efforts to mimic a more realistic development environment. The two main systems that I put in place in order to maintain this idea of professionalism was to have a build server in place for our projects, and the second was proper use of a version control system. Continue reading “Team NAH: Meet Our New Friend Jenkins.”