Voodudes is a free to download third-person action RPG in which the player takes on the role of Virgil, a voodoo doll who must save the world of voodoo from the evil Baron Samedi. Voodudes features six unique abilities that can be equipped at an in-game shop. Players may also equip alternate costumes and accessories by collecting various items throughout the game.
Voodudes was developed in UDK by fifteen full-time Master’s students at the Guildhall at SMU. The total project length lasted five months, with twenty work hours per team member. As the Producer on this project, I will outline what went right, what went wrong, and the things we learned.
What Went Well
The Zombears fit together like one big family. Everyone was good-natured, had a great sense humor, and was super dedicated to making an awesome game. Because of this, motivation wasn’t a concern, nor did we have to stop and deal with any major personality conflicts. This allowed us to always drive the project forward.
We could focus on making a great game while having a great time. Although the game has shipped, I’m proud to say that we’re all still friends, and there’s something to be said for that.
Super cuts, super early
During pre-production, I approached several professors asking them which capstone milestone gave student teams the most trouble. The consensus was that most teams struggled at Alpha. Around this time, teams realized that they would not be able to implement all of their intended features. This resulted in tremendous amounts of throwaway work and rework.
Two weeks before Vertical Slice, the Lead Level Designer, the Game Designer, and I met to discuss feedback that we received at our previous milestone. The general consensus from our professors was that the game was going to be much too large and should reduced our planned number of levels.
We weighed the pros and cons of such a large cut. We were convinced that we could create all eight levels, though we also knew that there was no way we could polish them all. Some would look good and some would look mediocre. We met with the team and discussed these options, and we all decided to make the cut.
Understandably, some people were not thrilled about the cut. That being said, we started to see the increased quality in our four existing levels, and realized very quickly that if we hadn’t listened to feedback, we would have run into many problems down the road.
We decided to push for the IGF submission deadline on October 31st. The week before the deadline was a mad dash to the finish, but this push propelled the project forward and placed us well ahead of our Alpha milestone.
We made the deadline and we were better for it. Submitting to IGF was a great change of pace from the typical workweek, and ended up being a huge morale booster for the entire team. As for joining the winner’s circle – you’ll have to keep an eye out for us next time.
What Went Wrong
The Betrayal of Modularity
Modularity and Tiers had their drawbacks. Everything ended up looking the same. Tiers made us race through development rather than focus on quality.
We completed several robust building facades very early in the development process. By proof of tech, we had seven completed facades that were available for use. The awesome part about this was that we proved very early that our easily-placeable modular façade system would work.
Unfortunately, we got carried away with these assets and created massive play spaces that the artists and designers would have to fill. Fortunately, the cuts at Vertical slice alleviated the bulk of the scope issues resulting from this. It’s still a valuable lesson in not getting carried away with your modular assets early in development.
Finding the source of the bugs became difficult because the game became so big.
As the game got larger and more complex, the bugs also became larger and more complex. We developed six unique abilities that the player could change out at checkpoints and an in-game shop. These abilities provided a wide variety of playstyles for players. However, the interactions of player abilities, enemy abilities, and boss abilities
Audio - Late to the Party
Sound started very late. We got lucky.
While we know that sound is a crucial element in game development, sound is not a large focus of the Guildhall’s curriculum. we prioritized it later in the project. Consequently, we didn’t have a good idea of the audio direction for the game, and many early playtest sessions were void of many sounds and music.
We were very lucky, and were able to contract with a sound design company in Dallas. The quality of the sound and music ended up being fantastic, but we should have implemented placeholder sounds by proof of gameplay. This allows you to iterate on your audio style as you develop the game.
What We Learned
People Deserve to be Heard
As long as people feel that they’ve had a chance to speak and participate in a discussion, they will be more likely to buy-in to the decision in the long run. Even if an undesirable decision is reached, your team will respect you for listening to them before reaching a verdict.
Transparent communication amongst team leads and disciplines allows many potential roadblocks to float to the surface. Whether it be issues between teammates or confusion between disciplines, transparent communication allows you to identify issues early and resolve them quickly.
The willingness to critically listen to feedback on your game is invaluable. Playtesters always reveal things about your game that you could never have seen yourself. You just get too close to the game. Listen to your players. You don’t always have to run off and make every change that you hear about in your forums, but it’s important to look at the feedback and examine how you can implement it into your game while maintaining the overall vision.