Fun little release trailer we did for a soft launch of the game!
A game that looks into crunch culture as you use paranormal means to keep your employees productive through the help of an alternate controller!
Role - Lead Producer, Vision Holder
Engine - Unreal 4.2
Time Period - 3 Months
What is Voodoo Management?
Controller
Voodoo Management is an alternative controller game where players use a Voodoo Doll to choose which employee to control as they try to maximize their workers efficiency and end up with the best KPI at the end of the round.
Depending on how an employee is slacking off, players must place the doll on that employee on the Employee of the Month Board which will select that employee and press on the corresponding button on the doll to get them back to work. But beware! If you press the wrong button or the wrong employee, they'll stop working altogether.
Employee of the Month Board
Where did we start?
So while I didn't start off on the project, it's a project I was integrated onto when some of the preliminary work was done.
This is the initial pitch that passed the project from the pitching stage to the prototyping stage.
Basic Control Document
So what did I do?
Great Question! I broke down the current mechanics and went through the ideas that the previous team had in order to improve it. It was initially a little scattered with the direction to take the project, but due to the time we had it made sense to try out new ideas that excited us before finalizing major decisions.
There were some things we knew we wanted to improve and build up on that we knew would stay within the whole game. Those would be creating sharper looking and more consistent art assets, improving on the animations present in the game, and adding more functionality to the controller. We also wanted to make it clear to the player who they're choosing to control with the Voodoo Doll, so we had to update the camera system as well.
Old - Prototype
New - Alpha
As you can see adding that small camera in the bottom right corner makes it obvious what character is selected and shows off the animation they're doing so much better.
Production
1. Creating Pillars
When working on a project, it's easy to throw out ideas and especially on a group project, it's fun to build and grow those ideas. I think this is great in building relationships within the team and encouraging them to work together, but it's so easy to spend meetings discussing game design details for mechanics that we just simply didn't have time to make.
To avoid this issue, I implemented a series of core pillars that every game design decision had to be judged against and only if it met the goals of those pillars would we continue forward with that idea.
I didn't want to have a total dictatorship and enforce my own will on everyone, I had everyone on the team create their own pillars and let it come down to a vote.
2. Hearing Out Changes
I implemented a new way designers had to pitch new mechanics or changes to the game. Using Paper Prototype as a huge inspiration, I required designers to come up with a short one-page design document and a rough version of what their mechanic would play out like using physical items.
This was to ensure that the idea was clear in the designers head, gave them the chance to think about the mechanic to avoid clear pitfalls, and also to promote the tactical feeling that an Alternate Controller should have!
While I admit it could be a little too high of barrier of entry for new mechanics this was limited to things that go against the pillars. I was fine experimenting within the player fantasy we had created with the pillars, but anything outside of that had to go through vigorous examination.
3. Breaking Down Mechanics from Designers to Deliverable Tasks to Engineers
For smaller, more implementable ideas, we created a reference or basic design document.
I presented these ideas to the engineers, explaining them in detail and answering any questions.
My goal was to ensure the engineers could implement the ideas comfortably and clearly understood the requirements.
With my experience in Unreal and Engineering, I served as a point of contact for the Engineering Team.
I assisted the team with questions and provided support for the detailed implementation of the design.
General Production Work
I address team issues by listening, asking questions to understand the situation, and acting as a mediator when necessary.
I ensure team members feel safe and heard by checking in on them if they appear worried or stressed.
Being approachable allows me to better understand my team and reallocate tasks to accommodate their needs.
For the project controller, we needed new sensors, boards, breadboards, materials for the Employee of the Month board, and merch for our college's Play Fest.
I handled these purchases, keeping a detailed record in an Excel sheet.
We had a limited budget of around $125 from the college, which required careful spending.
I researched and found the best prices, confirming with team members before making purchases.
Despite the budget constraints, we managed to get the necessary materials.
My meticulous record-keeping ensured that everyone who paid out-of-pocket was reimbursed.
Design
We considered adding complex mechanics like hiring/firing and rotating characters, but playtests showed the game's simplicity was most appealing.
The Whack-A-Mole style gameplay became the core identity, fitting within our established pillars.
We enhanced minute-to-minute gameplay with slight improvements, ensuring it remained easy to pick up and play.
Initially, we planned for characters to have right and wrong task animations, but exaggerated, goofy animations proved more effective and fun.
We implemented a shop system despite initial concerns, fitting it within the project timeframe.
I assisted with shop dialogue, item descriptions, and bug reporting.
Allowing the team to pursue the shop idea built trust and resulted in a happier team, even though it wasn't my favorite mechanic.
Dialogue System + Opening Video
The Dialogue System is something I coded into the engine and made the tool accessible and easy enough that the narrative writer who wasn't comfortable with the engine could use and troubleshoot if they had any problem with it. This was also used to display text in the shop.
The opening video was storyboarded and created by me and another teammate. I helped edit the video as well working on stitching the scenes together and the transitions in-between shots as well. I also did the VA of the L'WA in the introduction so if you love that, the recording booth is always open!
Here's the difference we were able to do!
Alpha Gameplay
Almost Final Gameplay
What Went Wrong?
1) The Controller
At the start of the project, we established basic functionality and decided to make the wireless controller a key feature, allowing players to hold the doll. With most team members being new to circuitry and breadboards, we relied heavily on the engineers to select boards that were compact yet powerful enough to handle the sensors and functions. After thorough discussions, we chose the Arduino Nano board, which offered both Bluetooth and sound motion capabilities.
The engineers quickly integrated the sound, Bluetooth, and buttons, but the controller itself presented significant challenges. Connections were time-consuming, testing was delayed, and the precise measurements for the doll and battery compartments led to fitting issues. Assembling and testing the controller inside the doll proved difficult due to the intricate wiring. Additionally, the vibration motors drained the batteries rapidly and caused glitches, forcing frequent re-downloads of the Arduino code.
We initially focused too much on gameplay, pushing back controller development until it became urgent. The complex design and lack of early experimentation with the doll components and battery mechanics prolonged the process. In hindsight, we should have started assembling and testing the doll components earlier, rather than keeping them connected to the PC for too long. This would have allowed us to address issues more efficiently and ensure a smoother development process.
2) Letting People Off Too Easy
Being an effective producer involves balancing autonomy with accountability, addressing critical obstacles, and ensuring tasks are completed on schedule. I entrusted a Tech Artist with creating a dynamic Skybox for our game, believing their assurance that it would be completed promptly. Allowing an extra week for flexibility, I monitored their progress daily, anticipating its integration into the game engine by the agreed-upon deadline.
Despite their initial promise, when the time came, the Skybox was not found by our Engineers. The Tech Artist cited forgetfulness and delays, causing repeated setbacks that affected our project's momentum. Recognizing the growing issue, I empathized with their challenges but knew I needed to assert clearer expectations to maintain project integrity.
As deadlines continued to be missed, I eventually confronted the Tech Artist about their commitment to the project. Their remorse was evident, and they pledged to refocus, albeit temporarily. However, this pattern persisted, highlighting the need for stricter adherence to timelines and clearer communication.
Another challenge arose when a workload imbalance impacted one of our artists, leading to missed deliverables. I adjusted expectations and prioritized tasks, ensuring manageable goals while learning the importance of proactive workload management.
Reflecting on these experiences, I acknowledge the need for balanced oversight and structured timelines to optimize team performance and project outcomes.