Team NAH: Visceral Plant Killing Machines

3oEduHJsGoAPg7hdle

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

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