Our Last Hope (Is Some Kid) - Blog Post Postmortem

 Postmortem

Now that the last sprint is completed, I feel quite satisfied with what was achieved given the time frame we had. There were a lot of successful things about the prototype and a lot of things that could have become successful if there was more time to do so. It was a huge learning experience to act as a lead, even if it was just in a small team of three, and I’m very happy with having the opportunity to do so. I very much felt like my team worked well together, and that is possibly the most important and successful part of making any game or prototype.

 Although the stress of turning in a working prototype caused everything to feel like it was crashing down, we managed to pull it together and turn in a successful prototype. Our main movement mechanic, grappling, turned out to be flawless. We noticed far too late that there was a rare occurrence where grappling would cause Kevin to freeze, and the only way to fix it was starting over. My teammate was able to find the problem and fix it, making the most important feature work perfectly. 

 We also had an issue with having Kevin take damage while the player was in hand mode, and having the old Kevin despawn if the player died from it. It was essentially a duplication bug, but it was really important to fix because the old Kevin would keep getting hit if it was in the line of a zombie’s movement. This caused the player to die shortly after respawning. I was eventually able to fix it by making a list of all the duplicated Kevin’s, and destroying them every time the player would die and go to a checkpoint.

With all the successes that can be considered for a five sprint prototype, there were some things that could have been grea
tly improved if more time was given. Luckily, none of the bugs are game breaking. There was one bug that existed for a while, and no matter how much we tried to fix it, we simply couldn’t figure out how. There are times when going back to Kevin mode when in hand mode would cause Kevin to disappear, causing the player to remain in hand mode with no Kevin to go back to. Kevin would come back if the player pressed E a couple of times, or if the player restarted from the last checkpoint. We tried to figure out what caused it, but we could never find any true way to make it occur. This made testing whether it's gone or not really difficult. We ended up adding UI that said “Kevin gone? Push E” as a last resort for the final playtest day.

Since a lot of the focus had to be on making sure the movement mechanics worked, some features that were worked on didn’t make it into the final prototype, and secondary features, such as weapons and combat, weren’t as polished. One thing that would have been nice to be able to fix was having only certain weapons be wielded by the hand, instead of all of them. I originally didn’t want the hand to be able to use the bat or ball, but making the distinction would have taken two more cards worth of work. There would have been a lot of factors to take into account, like going into hand mode when a weapon the hand can’t wield is already wielded by Kevin or picking up a weapon as the hand and switching back to Kevin with it. Unfortunately, there was not enough time to prioritize that feature.

 As far as using Agile development goes, I did a decent job of working on one card at a time up until the last sprint. Since we were using GitHub, we would never have more than one person using it at once. We all had our own personal projects that were copies of our shared one that we would work on and then push the packages onto GitHub. This wasn’t normally a problem, but since there were so many things to take into account with every new card completed, everyone took a bit more time on the GitHub when pushing their work to make sure it all worked properly and didn’t break anything. I ended up completing cards, but not being able to push the work immediately after because someone else was on the GitHub project. This caused me to move on to the next card before pushing and fully completing the current one. I was greatly feeling the pressure of time running out. Considering the yet to be assigned work I had to look forward to for other classes, I didn’t want to waste whatever precious time I had at the moment doing nothing. I do really like using Agile development but in the last sprint when it’s crunch time it was very hard to do it properly, and I have a lot to learn about how to skillfully do that.

Most of what I would change if I were to do this project again would be relating to Trello and Agile development. This was a very big learning experience for me, not only with using Trello, but also with leading a group in the development of a prototype. While I have been a group leader in other settings, being the lead of a prototype is vastly different. While I knew what needed to be done for the prototype, prioritizing each thing was much more difficult. I always felt like I had two or three cards off when prioritizing the backlog, even though we never missed a deadline for each playtest and the features we needed to have present. I truly believe that if I had prioritized the backlog better, some of the bugs that we still have or felt rushed to fix would have been dealt with much earlier or wouldn’t have occurred at all. The nature of making a game is hard, and things go wrong especially when learning a new system at the same time. I know that there's a lot more room for me to grow, more than likely more than I have mentioned, but the final product that my team and I completed is one that I can say I’m proud of.

Our Last Hope (Is Some Kid) - Blog Post 4

Sprint 4

After Sprint 4, I am finally confident in my capabilities of using Trello. I have remained on top of verifying cards, as well as making new cards when it is needed. I also remember to move my cards into the various sections when appropriate based on the work I am doing. I could still use more work on writing good user stories that convey the goal of the card, while still giving the creative freedom to the designer or programmer that plans to complete the card.

I started off this sprint by finally making the water kill the player when touching it. This was a more important feature for a prototype than I originally thought it would be, due to some playtesters refusing to grapple or jump when playtesting. The addition of the water killing the player on impact gave much more incentive to use the main movement mechanic, grappling, when playtesting the prototype.

 

Another issue found during the electronic playtest during Sprint 3 was that players couldn’t figure out the controls, so it was important for players to be able to see the controls while playtesting, not just from the initial controls screen. Now, when the player holds the tab key the controls will appear on the screen. This is a capability that the player can use at any point in the prototype if they ever feel like they forgot the controls. I preferred making the controls only appear when the player wants them to, since there are quite a bit of controls in the game that would be annoying to have on screen the whole time.

After addressing the issues from the last playtest, I moved on to features that were already planned for the prototype. I made it possible for players to interact with objects. If a player comes across a weapon and points at it, the object will light up and then be equipped by the player after pressing F. I made the object change materials so that it’s clear to the player that the object is interactable.

I then moved on to adding UI in the level itself. There are two types of UI I added, one that pops up in a specific area and one that pops up when the player is pointing at a specific object. The first type is used to help guide the player around the level, so when a player enters a given space, text will pop up that could give the player a sort of hint for how to proceed. For example, when the player walks towards the first vent, text will pop up as if in Kevin’s voice giving the player a hint to send the hand through. The second type pops up with the controls required to perform a specific action. For instance, when the player points at an interactable object, “Press F” will pop up to help prompt the player. Similarly, when the player points at a grapple hook on a spot where the player is allowed to grapple, “Press Q” pops up.

Based on the spreadsheet I created in the last sprint, I made weapons that will do a different amount of damage and last a different amount of uses. I also added a variable for distance, since a ball would reach farther than a bat for example. After interacting with a weapon, the player can then use it to attack enemies. If a weapon is already equipped, and the player interacts with a new one, the old one gets dropped and the new one is now equipped; this keep players from having multiple weapons at once. For objects that are swung at the enemy, like a bat, the duration only decreases when an enemy is actually hit, but for objects that are thrown or shot at an enemy, like a ball, the duration decreases regardless of the hit being successful. Similarly, objects like a bat have a much shorter distance than objects like a ball. Each weapon also does a different amount of damage.

After the final level was added to the prototype, I created a script that allowed the final boss to follow the player in a given radius, and stop following when the player is close enough to get hit. I also made the win screen pop up when the player finally reaches Kevin’s friends after the final door.

As a little bit of a minigame, I created a point system for when the player throws the hand into the hoop, so that it gives the player an incentive to practice throwing the hand in a way that is fun. This also adds an opportunity for an alternative ending to the game if the player spends too much time essentially playing basketball with the hand.

From the playtest that occurred during this sprint, we discovered a lot of valuable information. Playtesters really enjoyed the grapple mechanic, the wall climb, the UI, and overall thought it was a fun concept. They also wished there was more navigational help provided by UI, more simplified controls, and better camera positioning. We also came across a couple of bugs, such as a duplication of Kevins when dying in hand mode and UI getting stuck on the screen. All of these concerns were addressed by adding the necessary cards in Trello for the last sprint.

Our Last Hope (Is Some Kid) - Blog Post 3

Sprint 3

Now that Sprint 3 has come to a close, I feel relatively comfortable with using Trello. I still could use work on writing good user stories for the cards. I became very good at making sure that the cards that are needed for the sprints are already in the backlog, as well as staying on top of adding new cards any time a new one is needed. The addition of points to the cards didn’t seem as complicated as I thought it would be initially. Most of my user stories are all one point, with a few three point exceptions and two epics, which is ideal.

I began this sprint by adding all the keys and doors to the level, so that the play testers would have a reason to use the movement mechanics when playtesting the prototype. I had to add a couple walls to block off areas that wouldn’t be completely ready by the time the playtest occurred. I also had to change a bit of the challenge in level 2, to make the goal a key instead of a box to push off the shelf.

I then made a Google Form for playtesters to fill out and give valuable feedback based on the rubric provided for the class. We only had five playtesters, one of which did not have time to answer the form, but each of those playtesters provided useful insight into how we can improve the game. Playtesters pointed out that the first wall climb was difficult, it wasn’t clear which grapple the player could grapple to, and sometimes the player could lock the game by getting Kevin stuck in a vent or preventing the hand from reattaching. Some suggestions for things to add in the game was also to have either a countdown timer or a maximum radius to limit the player when they are in hand mode.

I then playtested the prototype myself before the playtest day to ensure that everything was ready for playtesting. While I didn’t notice anything that would break the prototype, I did notice a couple things. Like the playtesters, I noticed that the distance the player could grapple was not clear. I also found that there’s an area where the hand can fall off the map from under a vent entrance, which was a simple fix of just adding a wall under the vent. Sometimes when unlocking a door, it takes the game a bit of time to actually open the door. It’s enough time to where it made me think the game wasn’t working properly, and if I was a playtester I would think the game was broken. I believe this can be fixed by having the player click a button to open the door, instead of simply walking up to it. I also think that it would benefit the player if UI would pop up telling the player if they can or cannot unlock the door.

After the playtest, I made the grapples more clear by making the hooks that the player can grapple to glow when pointed at.  The mouse will now also lock to the center of the screen when clicking on the game window. 

During this sprint, I also made a spreadsheet with weapons to add to the game. Some weapons can be picked up by the hand, while others cannot. Each weapon has a different amount of damage, amount of duration, and type of attack. Some weapons are used to hit enemies, while others are shot or thrown. The different numbers are based on the assumption that most enemy health is at 5. Balancing would have to happen after the weapons are created, so that we can test different damage and duration amounts.

Our Last Hope (Is Some Kid) - Blog Post 2

Sprint 2

With the completion of Sprint 2, I have realized a lot more about Trello than I knew before, and the difficulties in using it properly. One thing that I was unsure about was how to track the work that a team member or I do that occurred on the spot, rather than planned. The process of making games sometimes takes little things that aren’t necessarily part of an existing card. For example: after connecting level 2 to level 1, I added temporary ramps for players to be able to get back up on the desks if they fall. We originally planned to have the water kill you, but due to the need to have a kinesthetic prototype done by October 26, we were prioritizing all movement mechanics and not the additional features. I have since learned that if these small tasks took more than ten minutes to complete, then track the work with a card.

We were still dealing with the same GitHub issue from the last sprint. We worked around it by having the team member put his work in our shared Google Drive, so I could then put his work into the repository myself. While this wasn’t much of a problem initially, the new scripts now require certain objects in the hierarchy to have specific tags or labels. Due to this new factor, I also had to add all the necessary tags and labels myself, causing the task to take longer than it previously did. For Sprint 3, we are going to work on fixing the GitHub issue.

While we were still working around our issues with GitHub, my team and I encountered a new issue at Sprint 2 Kickoff. After our first sprint review, we learned that our movement mechanic may not be unique enough to fulfill the project requirements. We then decided that a previously mentioned feature of a grapple hand would be implemented as the main movement mechanic of the game. We were able to quickly adapt to the change.

After Sprint Kickoff, I completed the skate park. Even though our priorities changed, I wanted to complete the work I already started in the last sprint before moving on to new cards. We are hoping to implement the skate park as a sort of easter egg if we find we have the time.

After the skate park, I moved on to creating the script for the skateboard. I broke up that requirement into three cards, the basic skateboard movement, making the skateboard feel like a skateboard, and being able to switch between the player and the skateboard. The only card of those that I completed is the basic movement of the skateboard. We are thinking that using the skateboard to navigate the level would add another unique movement element and fun to the prototype, and having the basic movement allows for a small test of that concept in future sprints.

Later, I began work on the third challenge of level 2. The player has to grapple into a classroom; then the player uses the detachable hand to crawl through a vent, up a wall, and push a box down from the shelf that Kevin can use to move on to the next section. I placed fake zombies and spiders in the level to give an idea of the combat that could happen in the level. I wanted the hand to have more goals than obtaining keys because it seemed like the concept would get a bit too monotonous for a player.

Since the kinesthetic prototype playtest is in Sprint 3, I am currently working on adding the keys and doors to the levels that were already blocked out. We want to have a reason for the player to use the unique movements, and putting keys in areas that the player can only reach using the grapple hand and detachable hand gives them the motivation to do so.

Our Last Hope (Is Some Kid) - Blog Post 1

Sprint 1

So far, the process of building a prototype is quite different from others I’m used to because of the use of Trello. It is a concept that took some time to figure out, and I admittedly don’t have it perfected yet. The difficulty isn’t with remembering to move cards and where to move them to. It’s with making cards that are different enough to be considered different tasks, and not too long to be considered an epic user story.

The biggest issue that my team and I encountered, and is still partially dealing with, is setting up GitHub. Initially, I created a repository on my Macbook, but one team member was having issues pushing and pulling. We decided to have a different team member create a repository on his Windows computer instead. Still, only two of us can use GitHub properly, so we are adding levels to the main Unity project by making them prefabs and sharing them on Google Drive.

For the first part of the sprint, a lot of my attention initially went towards setting up a collaborative workspace and making the design treatment. I created a Google Drive, a Discord, and a GitHub. Unfortunately, GitHub created a lot of issues, which made it hard to combine everyone’s work into one Unity project at first. All members of the team worked together on the design treatment, so that way the plan for the game would be clear among all team members. The treatment asked for some concept art to be added, so my teammate and I worked on a couple simple sketches of elements of the game that represented the aesthetic feel, and even some humorous aspects that we wished for in the game.

I moved on to creating the paper prototype. It took some time to figure out how to translate a 3D idea into a 2D space, especially when a big part of the game is meant to involve a unique movement mechanic. I settled on making a grid with some enemies and items that you would pick up similar to a Roll20 campaign layout. Creating rules that were simple enough to learn in a couple minutes, but detailed enough to play the prototype correctly was challenging. It’s very hard to remove my own perspective from the equation of a rule sheet, since I already know how the game is meant to be played. I decided a good thing to do would be to playtest the prototype a day after completing it and its rule sheet, so that way the rules aren’t as fresh in my mind. It helped with making small changes before the playtest day. During the day of the playtest, I had to add a health pack since the first two playtesters died, and that improved the experience of the game for the other playtesters.

After completing the prototype, I moved to working in Unity. I created a particle system for the vent and the climbable walls, so when a player is playing the game, they would be less likely to miss a key element in completing a level. I haven’t worked with particle systems in Unity before, but it was a very easy thing to figure out for the purposes of the game.

I started on creating a skatepark, that would help teach players the basics on how to use a skateboard when it’s equipt. The limited shapes available in Unity made it a bit more difficult to figure out how to go about making something like this, so I had to think outside the box. It is not complete yet, but I will continue to work on it in the next sprint. I also did not add health packs around the level yet, even though I had it assigned.