Game Summary Statement:

Two players scoot around on wheelie chairs in various classroom levels and fight to be the first to five points. You get a point if you can make the opponent fall out of their chair. 

Valerie

What Went Right?

Playtesting: Over the course of development I hosted close to 70 different Kleenex playtests and this really helped refine the game.

Start Menu Design: This allowed players to experiment with the controls in a fun way without being forced through a tutorial at the start.

Game Loop: The flow of the game is overall very smooth

General Design Planning: Designing around the limitations was a great strategy to create a game that felt finished and fun within the scope we had. I created this game as a strategy to complete something effectively on time knowing that there would be very limited resources. 

What Went Wrong?

Players often ignored the rematch screen interactivity. They would put the controllers down as soon as they saw the game was over, or they would immediately press rematch without interacting with the characters. 

Tap to move: I intentionally messed with the standard for the control scheme in order to give the player a better feeling of agency with their movement in the chair, but because this was a new concept a lot of people had trouble figuring out the proper movement at the start. Despite this, it seemingly never affected the player’s enjoyment of the game. 

Spin attack idle charge: Adding an idle charge to the spin attack destroyed the game flow because it encouraged players to hide from each other rather than fight. Players would hide and wait for their bar to fill up, making rounds painfully long. This was cut and it stopped this issue from happening again. 

What did you learn from this experience?

Players love ragdolls a lot more than I thought. I wish I had recorded some of the Kleenex playtests because there were some people dying of laughter because their player character fell in a silly way. People are also very forgiving of the bugs and just find it funny when their character spazzes out. 

Playtesting is super important

I like being a game designer :)

What would you change about the development process for next time?

I would probably reconsider the movement. Rather than tap to move maybe I would try to find a system that is more intuitive while still giving the player enough agency. 

Brad

What Went Right?

Communication was a significant strong point that our team had. We were all actively participating in the Discord. This meant that if someone had any information that they needed to get from another team member, we were able to efficiently communicate, allowing us to complete work faster without having to wait long periods of time for a response.

Overall, the organization of cards in the backlog did have some things done right. When it comes to the general organization of our backlog, we were able to find the specific category of tasks by labeling each card as it was made. By doing this, I was able to find the category of tasks to assign to each member, but it was not efficient for kickoffs.

Coordination with the game designer was done extremely well. As the producer, while I was making cards, or working on a card myself, I was able to communicate effectively with my designer to ensure that we were on the same page with how things were going. This was not only contributed by excellent communication, but also a solid vision of what she was looking for from the game.

What Went Wrong?

Initially, kickoffs were taking an extremely long time, resulting in the team not being able to begin working until the end of class, in some cases. The core reason for this had to do with the method I was using for prioritizing/organizing user stories in the backlog for individual team members.

Wording user stories was difficult at first. It took me a long time to get to the point where I had a more solid understanding of user stories and ways to clearly communicate what was wanted and the check for that task. By utilizing the description field for the user stories, it greatly helped with the ease of creating user stories. This is primarily because I was trying to include all of the things that were wanted into the user story, rather than utilizing the description to include the smaller details that weren’t necessary to include in the user story.

The level that I designed to have explosions in it caused the controllers of the player to die and not be usable until the computer was restarted. Luckily we found this while we were doing internal playtests, but it was a substantial bug that could have been a large issue if it were to have been present in a build release.

What did you learn from this experience?

Finding an effective way to organize/prioritize the backlog is essential and leads to much more efficient work being done, especially during kickoff days. Also, something that I noticed was that our scope was pretty spot on with the time we had to complete this project. What stood out to me was that we were able to make almost all of our tasks into 1 point cards. We had a total of 3-4 3 point cards throughout the seven sprints. I believe that this was something that could be contributed to the scope of the project and finishing everything that we wanted to by the beginning of the 7th sprint.

What would you change about the development process for next time?

After going through the ups and downs of the producer position throughout this project, I will be applying the various methods that I have come to learn in future projects. This primarily comes down to efficiently and effectively managing the backlog of our project. I feel that if I had the knowledge that I gained from this semester, we would be able to implement even more things into our game.

Matthew

What Went Right?

Using a multiscene system with a local scene manager and a global manager that migrated information between scenes. This allowed for easy management of our scenes and for our team members to create levels without having to worry about someone else needing to touch their scene.

Using a PID controller for the player’s rotation control. This was a major challenge for the project as it would not have been possible to use transform as everything needed to be done through physics.

Adjusting the physics timestep and solver intervals in order to have the player’s reactions and physics act more responsively.

What Went Wrong?

Attempting to simulate friction with articulation bodies, caused a lot of wasted time for the project.

Enabling adaptive force caused our movement to become almost unusable by players and this was reflected in the playtest responses.

Originally lambdas were used for subscribing actions to the player's controls, however, due to these being unanimous functions, the unsubscribing method was not working correctly, causing 

What did you learn from this experience?

I’ve become more acquainted with the unity physics system as well as with how the new input system handles controller inputs.

What would you change about the development process for next time?

I would study more models of systems and codding patterns beforehand so I could conceive a clearer system ahead of time.

Kyle

What Went Right?

One of the biggest things that went really well during this project was asset creation. The goal of the models and textures we were supposed to make were very simple looking, so it was a pretty easy process to create all of the different objects that we needed to populate the game's levels. There were certainly a few that were a bit challenging, but for the most part it was all a fairly easy process.

Most of the level creation for the game was easy and understandable. I believe that I was able to create quite a few interesting and unique levels, and I believe they add a lot of character to the game.

Overall communication between all of the team members was really good. Whenever someone had a question or issue, there was always at least one person who would step up to help.

What Went Wrong?

While asset creation was fairly simple, asset implementation was not. After we had completed most of the models, we realized that almost half of them hadn’t actually been implemented into the Unity project as prefabs yet, which was a bit of a speed bump for starting level creation.

At the very beginning of creating levels, I personally wasn’t quite sure what our ideal process for putting together levels would be. Because of this, my first level was very lackluster. Luckily I got more of an idea on how to do things afterwards, and the rest of level creation went smoothly.

The only major “problem” I can think of was that there wasn’t much work for me to do over the last sprint of the project. At that point we decided to stop creating new levels and just focus on polishing the existing ones. This was fairly simple, as I just had to go and readjust a few things in each of the levels I had created, but that process was very easy and took little time. Otherwise any sort of bug fixing that was specific to scripting problems was taken care of by a different team member, leaving me with little to do at the end of production.

What did you learn from this experience?

After some unfortunately poor products at the end of other projects in different classes, I realized just how much of a difference it can make when a team comes together in the right way. In some past projects, it often felt like some team members had different visions for the game than others, and communication would often be difficult, making the final product pretty poor. However, this project wasn’t like that at all. It felt like the team was able to communicate with each other properly and had a lot of synergy. Seeing how much can be achieved with a fully functioning and tightly knit team was certainly an eye opener.

What would you change about the development process for next time?

I think the most major thing I’d change about development was the implementation of assets. As I mentioned earlier, there were some problems regarding how we implemented assets into the Unity project, and this slowed down the level creating process. If we had gone about asset implementation differently, we likely would have gotten more work done.

Micah

What Went Right?

As a team, we definitely had great communication. We held two meetings a week outside of class for working on the project and playtesting it. We also made sure to inform each other if we were going to be absent for meetings or if we needed more time to complete certain tasks for the project or more work to do if needed. Our lead game designer was very good at communicating her ideas to everyone on the team as well, so everyone understood exactly what needed to be done and how to do it.

I also believe that the modeling and texturing for this project went very well. The models were fairly simple and there were two modelers on our team, myself included, so I feel like we were able to get through all of the modeling and texturing for the project in a very efficient manner. We even made through the wish cards. We were fast and efficient and I don’t believe that levels would have come together so nicely without the variety of models that we were able to create.

The level design part of the project also went well. Since we were able to knock out all of the models fairly quickly, we were able to work and complete various levels up to the end. We had three level designers adding levels to the project, myself included, so it was easy to get as many levels in as we could. Since there were three level designers, each of the levels are very unique from one another. There is a good amount of variety for players to experience.

What Went Wrong?

One of the biggest challenges that I faced working on this project was organization. Specifically when working in Unity. Sometimes it was difficult to find certain prefabs that I was looking for while trying to build levels because there were a lot of folders to sort through just to get to the prefab that I needed. Sometimes I also wanted to change the texture using a texture swap on an object, but again, there were a lot of folders to sort through so it was difficult to find the textures that I was looking for.

Something more specific that went wrong for me, was I didn’t understand how the camera system worked in our game. I had created a few levels with each of the walls filled with props, not knowing that the camera didn’t rotate around the whole level like I thought it would. Instead, the camera is in a fixed almost orthographic view on one side of the level. So, after learning this, I had to go back to each of the levels that I had already completed and remove the props from the wall that the camera is behind.

Something else that went wrong regarding the levels was the placement of some of the marker pickups. We noticed during playtests that somehow markers were spawning either half way through the floor, completely through the floor, or off of the level entirely. This wasn’t a huge problem that was difficult to fix, it was just surprising because we couldn’t figure out how that happened. Once we learned that it was a problem we fixed it fairly quickly.

What did you learn from this experience?

The main thing that I learned while working on this project was that communication is absolutely key. Everyone started to and continued to actively communicate if they needed something, or if there was a problem. Having a very supportive team also made it easier to work. It was motivating, and making sure that everyone on the team understands the vision of the game made it extremely easy to work together and build the game together.

What would you change about the development process for next time?

The only thing that I would change about the development process would be the organization in Unity. Especially for a project that uses multiple models like this one. I think if we imported the models and textures differently it would have saved on the amount of folders used in the project, and it would have made the project's folders easier to navigate.