Page Contents
Team Project: Cult
Cult is a multiplayer FPS that pits two teams teams of four players against each other in Capture the Flag. It focuses on creating a compelling and unique experience through a blend of horror and charm and facilitating meaningful local multiplayer interactions.
Executive Summary
Role - Level design and Scripting
Team Size - 7
Development Time - 5 months
Engine - Unreal Engine 4.6
Project Details
Charming/Disturbing Theme - Art and design should channel a combination of Lovecraftian horror and Nightmare Before Christmas-esque charm.
Fun Gameplay - Multiplayer elements should allow for strategies and interaction, while weapons and world should support balanced play between teams.
Immersive World - Elements should feel purposeful and appropriate to the space. While priority should go to gameplay, care should still be taken to support world-relevant realism and internal consistency.
Design Pillars
-
Exploring new systems (engine or otherwise) to support the team's forward development and understanding
-
Integrating 3D assets and animations from a technical and design standpoint
-
Assisting network implementation, including implementation and debugging of guns, pickups, and game feedback mechanisms as needed
-
Storyboard, game capture, and editing for release trailer
-
Other design and programming tasks as needed
Personal Responsibilities
Implementation Highlights
Dynamic Cloth:
One of our goals with this project was exploring the Unreal Engine's capabilities. To that end, and to set us apart from other teams, we endeavored to include cloth simulation using Nvidia's PhysX technology. My job was to figure out both the process of creating dynamic cloth and integrating it into the engine. The Flag is an important part of Capture the Flag, and we wanted ours to be immediately distinct element of the game.
I used 3DS Max with Nvidia's PhysX plugin to do this. At the time, tutorials on this technology (and particularly its interactions in the Unreal Engine) were limited, so I also helped create a (very) rough tutorial for SMU Guildhall's private student wiki.
Message Log:
One of the more interesting elements I implemented was likely the game's kill/death/join message log. As local multiplayer thrives on the interaction of players, having feedback to alert players of who they need to wreak vengeance upon was a personal priority.
In particular, we wanted to maintain an active, living log that kept players across the game up to date on what might be considered "important events." Although we had a separate, more visually aggressive system for flag related actions such as captures and drops, we wanted to ensure players were able to make—and settle—personal scores with one another.
Rigging and Posing:
Although our artists would be fairly well versed in 3D animation and rigging by the end of our project, at the outset our artists (truly our whole team) were unfamiliar with the paradigms and processes of setting up a moving 3D character. As their early time was to be focused on creating quality assets, and due to the fact that our art team was relatively small at two people, I elected to help them tackle this issue.
My first goal was to get our player character, the cultist, up and running (pun intended!) with the animations available for Unreal Engine's default skeleton. While our lead artist focused on creating more assets and guiding our visual designs, I created the initial rig for the character. The quality was high enough that we ended up using the rig to launch, and our artists were later able to add animations with one less step in the process.
We also wanted to add a little more pizzaz to the world in the form in the form of statues. These supported the lore of each team's "god" that provided narration and justification for the strange festivities in this little cult town. As in the case of our player character, I helped to rig and create the initial pose for one of the statues. Eventually our artists were able to take over and refine my efforts, but it was at a later stage of the project when such the luxury of refinements became available.
First Pass
Artist Refinement
Post-Mortem
The Good:
-
Shared Team Knowledge: Our team drew from a host of backgrounds to contribute and teach one another throughout the develpment process. Everything one member learned was quickly distilled and disseminated to the rest of the team.
-
Shared Vision: While there were some early concerns about nailing our thematic goals, the art team was able to rapidly form a coherent style. Generally, there was very little contention among the team about how to solve problems and our priorities for milestones.
-
Small Team: The relatively small team meant that we needed very little overhead and communication between departments was fluid and seamless. Having all team members in conversational distance contributed to the culture and learning of the team.
The Bad:
-
Unstable Engine: The project began as a heavily modified version of the Unreal Tournament. Unfortunately, the editor was still in its early stages and building the game was impossible. Shifting to vanilla Unreal Engine 4 was a huge time and energy sink, and rebuilding basic FPS functionality was an unforeseen challenge that cost a lot of effort on the part of myself and our team's sole dedicated programmer.
-
Time Management: Even neglecting the above difficulties, this was the first experience in the full production pipeline for a 3D game for all our team members. Task planning often underestimated complexity and a number of milestones forced extra hours to meet our goals.
-
Crunch: Related to the above time management and engine issues, our team had to put a lot of extra time. This not only cost significant developer morale, but also tended to feedback on itself by introducing larger numbers of bugs we would later need to tease back out of the system.
The Takeaways:
-
Choose Egines Carefully: Though building through Unreal Tournament would have greatly simplified the implementation of our main gameplay loop, the limitations of working on top of an existing project without access to good information on it (and without some elements needed to build properly) cannot be overestimated. Whenever possible, a quick slice of the whole process in your desired engine can be invaluable in properly planning development of your game.
-
Networking Is Hard: While most elements of game development are non-trivial, some can be considerably larger time sinks than others. Networking in particular can double the work needed for every technical task, just to ensure its functionality on all machines (in our case, both the server and client).
-
Multiplayer Playtesting is Expensive: Testing a multiplayer game, particularly one that plays with team sizes equal to or larger than the dev team, can drain significant time away from developers actually working. This is particularly true when funding or other limitations necessitate most testing be in-house.
Gallery