Thoober

Design Goal

Build a Zany Arena Movement Shooter that Allows for Crazy and Hilarious Moments

Thoober's gameplay involves having up to 4 players compete in small surreal arenas affected by random modifiers with a variety of unconventional weapons at their disposal. Weapon's such as an Explosive Device named "Gender Reveal" that explodes blue, pink, or green, a Throwable Music Disc playing the game's soundtrack but sped up, and the 41M, a semi-fire rifle that decreases in recoil as it's shot.

While having a chaotic, unserious, and random vibe to the game is fun, it was important to me that the game still felt fair and somewhat competitive. It was important that the game could feel random, without being unfair.

After having some playtesting sessions (which will be elaborated on later), the team and I came up with the following design pillars to help us stay on track with our vision for the game and to help us make design decisions while addressing feedback for Phase Two of development.

Design Pillars

• Chaotic Fun
• Fair Randomness
• Unserious Competition
• Defy Expectations
• Distinct but Readable Artstyle

Addressing Feedback

After our first phase of development with some internal playtesting, we had the opportunity to be showcased at MSU's Game Showcase. This not only brought a lot of eyes on the project, but also a lot of playtesters too. The main result of the feedback, and why, is as follows:

Really fun, but only for 15 minutes

• Art Style was very inviting
• Too much emphasis on player skill
• Some modifiers were too much
• Some maps were too different than others

The game attracted a more casual audience than we were expecting, which influenced some of the feedback we received. The visuals and design of the game screamed "Casual Fun" but the weapon and modifiers did not. Most weapons were hitscan and rewarded precision and if someone didn't have that skill, then they would be at a heavy disadvantage. Some of the modifiers, especially the movement-related ones, made the player too hard to control for some playtesters. Our game was more like Counter-Strike than Team Fortress 2 which went against our target audience.

Meeting with the other designers on the team, we came up with the following plan to address feedback, which will be implemented in Phase Two of development which is occuring right now:

• More emphasis on Area-of-Effect weapons rather than hitscan ones
• Modifiers should influence the gameplay, but not control it (outside of special occasions)
• Maps should have a consistent size and not lean too heavily movement skill

The 41M - Weapon Design and Implementation

Design

When designing the 41M, I wanted to create a weapon that rewarded players who stuck with it and didn't toss it away after a few shots which is what happened to most of the weapons in the game. I wanted to create a weapon that had a learning curve, but also one that was rewarding to learn and use. The 41M is a semi-fire rifle that decreases in recoil as it's shot. This means that the more you shoot it, the easier it is to control and the more accurate it becomes. This created a risk-reward system where players have to decide whether to fire a few extremely inaccurate shots that will expose them to other players, but be rewarded with pin-point accuracy in the later-third of the magazine.

Implementation

When implementing the weapon, I utilized the Standard Shooter script as a base and created a Non-Static Recoil component that could be used on any weapon to hook into it. The goal for weapon components in Thoober is that they should be weapon-agnostic and be able to hook into any Standard Shooter. With this goal in mind, I designed and created the script to fit perfectly with the Standard Shooter and to be exremely Designer-Friendly.

I utlized Enums to allow Designers to switch between what type of recoil they want, and I utlized Unity's Animation Curves to allow for fine control over the recoil. I also incorporated curve scaling in order to make a Designer's life easier, as Unity's Animation Curve editor for variables specifically is rather difficult to use when the size of the numbers is outside of the 0-1 Range. With curve scaling, a Designer can design their curve easily in the inspector and then scale it to their needs with no hassle.

Weapon Result

The 41M was well-received by players and added a unique dynamic to the gameplay. Some players would frequently take potshots from a great distance at other players and then suprise them with their perfect accuracy as they advance towards them. Other players would use the weapon guns ablazing at close range and hope that the initial extreme recoil would allow their shots to hit another player nearby.

With the NonStaticRecoil Script, Designers found it intuitive and easy to use and it has now become a part of other weapons in the game. No changes to it have been needed so far, which suggests that it has accomplished my goal for the script, that being that it should be Weapon-Agnostic and Designer-Friendly.

Project Reflection

While the development of the game is ongoing, there is still a lot I have learned, and will continue to learn, from working on it.

Mentorship and Teaching

As the senior-most developer on the team and the team being comprised of my younger brother and his friends, I took it upon myself to try and assist everyone on the team as much as I can as they started to learn game development with Unity. Whether it be explaining best code practices, level design tips I've learned over the years, model optimization technique, game optimization techniques, design tips, I try to help and teach them as much as I can. I want to be the Mentor and Teacher to them that I wish I had when I first started game development, that way they don't make the same mistakes as me and so that they can have a head-start compared to the rest of their cohort.

Design

This is the second project I've worked on with online multiplayer functionality and this game is way more casual than the other (Spell Forge). With this game being a First Person Shooter though, I was right at home in my home territory. On this project, I really learned how to communicate myself as a Designer better than I could before. As mentioned, the team is comprised of those new to Game Development so I had to learn to disregard any "Design Assumptions" that my peers in my cohort have but these Designers do not. This resulted in me being very explicit in my reasonings why I designed something a certain way and to use more game references than I normally would. I will be carrying this lesson on with me even when I'm on a team with experienced Designers because it helps get my ideas and reasonings across better and it greatly helps non-Designers understand my choices too (especially if someone has to program my Design).

Programming

This is the first time I'm not the "lead" on something. Usually on projects I am the lead Tech Designer and/or Systems programmer or I'm programming a system alone while other programmers work on something else. However, this time I dove into Networking Programming, which is something I haven't really delved that much into before. So, I had to learn how to program networking-involved systems and how to update and refactor my code as the Lead Networking Programmer optimized the networking code. This required me to stay up-to-date with the latest iteration of our core systems and to keep my systems to the same standard. This resulted in me working collaboratively on the same script with another programmer which is something I haven't done before. Normally I would touch scripts after another programmer was done with it