Instructions Unclear
Producer Goal
Strong Vertical Slice to be Chosen to Continue Next Semester
Instructions Unclear was a month-long project with the goal of making a vertical slice that will be pitched and potentially chosen to be continued into the next semester. As the producer on the project, it was my goal to make sure that what we were working on made progress towards a high quality vertical slice that would be able to show off the potential of the game. With a small team of 6 for the pitch part of development and an even smaller team for the initial ideation phase of development, it was important that team was working quickly and efficiently.
To aid with this, I utilized Trello for task management and talked with each member closely to find out their strengths and what they wanted to do on the project. With this information, I was able to assign them tasks that they would be good at and that they would enjoy doing. I also made sure to keep track of our progress towards our vertical slice and to make sure that we were working on the most important things first and saving smaller tasks for later if we had time.
Design Goal and Playtest Pivot
Instructions Unclear is a Party Game where players must work together to complete a simple task, like Overcooked. With the construction aesthetic, we decided to have the game mode be that the players are construction workers and they must build a structure together using the tools at their disposal. This includes a crane to pick up blocks, a turntable to rotate the platform the player's are building on (solves depth issues due to fixed-camera perspective), and a welder to weld blocks together, all driven by pure physics. In order to see what the players had to build, a player would have to walk over to the blueprint table which will bring up a ghost blueprint of the desired structure.
The team and I were guided by the following Design Pillars:
- Theorycrafing and Positive Stress
- "Co-opetition" Adjacent
- Couch Co-op Socialization
- Meaningful Co-Op
Pivot to the Fun
A big thought I keep in my head is to "Find the Fun." Initially, we thought it would be the collaborative aspect of building a structure together but, due to the physics-based gameplay, trolling each other and trying to kill each other ended up being the most fun aspect of the game. We found the fun, but it wasn't the fun we were making. With this in mind, we pivoted to make a more competitive game mode where players would try to kill each other with the physics-based tools at their disposal. Players would build up knockback when taking damage and be flung around the map, deconstructing it in the process. This gamemode served as a nice antithesis to the construction game mode and, luckily for us, it was the fun that players wanted. Thankfully, due to the nature of how interactables were designed for the construction game mode, we were able to easily pivot to this new gamemode without having to rewrite any core systems.
The Building Accuracy System
Creating a Fair System
For the construction game mode, I wanted to ensure that the final build-accuracy checker was fair and that the players wouldn't feel cheated by it. With the nature of physics-based building, players might place a block in the right spot but it might be slightly off due to the physics-based placement. To account for this, I made sure that the accuracy checker would give players some leeway when placing blocks and that it wouldn't be too strict. This way, players would feel like they had a fair chance at placing blocks correctly and that they wouldn't feel cheated by the accuracy checker.
Designer Friendly Design
As the Designer of this system, I wanted to make sure that it was intuitive and easy to use for me and the other Designer on the project. So, I made it so that in the scene, the Designer could build the structure they want with the provided block prefabs, and then the script would automatically make a list of each object and it's desired position and make a ghost structure out of it which the Designer could save in a LevelData Scriptable Object. The Designer can even adjust the tolerance and min-distance-for-perfect for each block which was visualized with gizmos in the scene to make the process more visual. During gameplay, the LevelData Scriptable Object would be loaded in and the ghost structure and the blocks to build it with will be spawned in automatically. This greatly streamlined the process and makde it simple for me and the other Designer to use. Players also found the tolerance for each block to be fair and we didn't have any complaints about the build accuracy during playtesting which was a good sign that it was working as intended. The players could guess what they were going to get before it was checked which helped prevent any feelings of being cheated by the system.
Crafting Your Weapon
Missing Construction
While the PvP game mode had an emphasis on destruction, it needed to have some sort of construction in it too. Simple props can only go so far in a PvP game mode. There had to be special items that players could earn and fight over and steal from each other. My solution to this problem was to design and implement a crafting system that allowed players to combine common items into special ones.
Constructing the System
Keeping with my goal of keeping things as Designer-Friendly as possible, this system utilized Crafting Recipes for Designers and a Item Crafter Script to make them. With a recipe, all that a Designer had to do was input the 2 items required to craft and the single item it would produce. In the game world, a player could see the items required for the recipe as little ghosts and if they brought the items over, the special item would be crafted. The utilization of Sciptable Objects allowed the system to be very simple and easy to add. The addition of it greatly enhanced the PvP gameplay too and was utilized a lot. Overall, adding crafting was a success and achieved what I set out to do, which was to add more depth to the PvP gameplay.
Seeing the Action
Creating a Dynamic Camera
While the construction game mode had a fixed camera to aid in keeping the players' builds accurate, the PvP game mode needed a more dynamic camera to keep up with the fast-paced action. Inspired by the PvP modes featured in some Monkey Ball games, I designed and implemented a dynamic camera that would follow the action and keep all players in view. The camera would zoom in and out depending on how close the players were to each other which helped frame the action better and do so smoothly and neatly so that players wouldn't get motion sick nor lose track of what's going on because of the camera movement.
Implementation
The Dynamic Camera was custom-made in order to allow lots of control over its behavior. It worked by getting the average position of all of the players in the game and then it would find the center and smoothly lerp to it. It also included padding in order to make sure that players wouldn't be at the edge of the screen and so that there was ample room to still see the environment around them. By doing this, a player could see an item off in the distance and run and grab it to use it in the current scuffle. For the camera zoom, I found the largest distance between 2 players and then used that to determine how much to zoom in or out. The closer the players were to each other, the more the camera would zoom in and the farther apart they were, the more it would zoom out. If a player got launched towards their death, the camera would only follow them for a little bit in order to not lose focus of the action. This allowed for a much more dynamic and engaging camera that kept up with the action and made it easier for players to see what was going on. A static camera wouldn't make the PvP action as exciting.
Like with everything else I've Designed and Implemented for this project, I made sure to keep the Dynamic Camera as Designer-Friendly as possible. It has plenty of settings to tweak both in the script and on the camera prefab itself.
The result was a dynamic and engaging camera that helped increase the intensity of the PvP battles and keep everything fair.
Project Reflection
Producer
My biggest lessons from this project were to let members do what they want and trust their expertise and to optimize tasks and the order of those tasks to ensure an efficient schedule. With the short development period the need to make a strong pitch and plan for a potential full-semester of development, it was important that I made sure that the team was working on the most important things first and that they were working efficiently. By letting members do what they wanted and trusting their expertise, I was able to ensure that they were working on tasks that they were good at and that they enjoyed doing which helped increase their motivation and the quality of their work. No one wants to work on a project for long where they aren't doing what they love.
Design
Find the fun. This idea drives me as a Designer. The goal of almost every game out there is to have fun and be enjoyable to play. You can design something expertly but if it isn't fun, then it won't be enjoyed or used. This mentality was put to the test when I realized that players did not find the current ideration of the initial construction game mode fun. While I had ideas of how to make it fun due to the feedback I had recieved, I had to make the decision as Lead Designer and Producer to design and pivot to the new PvP game made in order to make the fun that player's wanted and to be able to achieve a polished vertical slice in the time we had left. Ultimately, this choice was for the better and I'm glad I made it. It showed to me that you can't force the fun on players and sometimes it's best to design around what the players want, and not what you want as a designer (within reason, of course).
Programming
I learned a lot about creating gizmos and Designer-Friendly systems with this project. I had to create gizmos for the build accuracy system and I had to make the dynamic camera system as easy to use and tweak as possible for Designers. I also had to create a whole crafting system too with recipes which was a nice challenge for me. It really forced me to plan out what I was going to program and how, which made me design and create the system very quickly.
