My Role
My role in the development was Game Designer. My job was to create a unified creative vision for the whole team to follow and communicate that across all departments. I also created the narrative background and designed the combat experience.
Role: Game Designer
Engine: Unreal Engine 4
Team Size: 27 Developers
Platform: PC
Development Time: 5 Months
Game Summary
High Concept: Conjury Revell is a first-person shooter with wave-based arena combat over three levels, each with their own distinct environment. Play as a rebellious dissident fighting to rid their world of magical oppression and forge a better future for their city in the clouds.
Leadership Role
My role throughout the development was that of a Game Designer. This meant that the core combat mechanics, enemy mechanics, game mechanics, and aesthetics were either envisioned or approved by me throughout the development.
At the outset of the development, I created a game design document (or GDD) for the team to give an entry point to begin working. As the development progressed my updates on the document became less pervasive as more communication was happening in person and over Slack to clarify for the team any changes, as the team responded better with those methods.
Eventually as time grew short and we entered the Beta milestone I was also maintaining a document which held our greatest priorities and used it to coordinate with the other leads and the team to ensure they were being completed.
Design Pillars
Arcane Godhood
Gothic Steampunk Core
Juicy As Can Be
Some specific callouts from my design document. I tried to give visual reference for my descriptions to try and tackle understanding from a couple angles.
Designing the Game
Every design decision I undertook I wanted to reinforce the feeling for the player that the tools they had available to them would encourage aggressive action against the enemy forces. The originally I designed a system that rooted the player to the world around them. In the system players would absorb magic from the world, and then use that as a spell. While I still like the idea of using the magic native to the world, eventually I had to come to terms with the fact that it slowed down gameplay too much. Players didn't feel strong and godlike, they felt burdened by the inability to use their most powerful abilities unless they found magic to absorb in the world.
To fix this I followed Occam's Razor. If players want to throw spells, let them. Changing the system to just allow players to have the spells normally sped up gameplay considerably and we were able to dig into adjusting the spells and how they worked together as a triad of weapons for the player.
Finding Aesthetic
When we initially began brainstorming during our Prototype milestones the team was excited about the idea of having a steampunk aesthetic. The idea that magic was being combined through gears and gauntlets to be transformed by the player was a really cool idea, that everyone wanted to make something with. So when I began imagining a setting for the game to take place in, I was instantly drawn to the setting of worlds like Warhammer 40k and it's gothic architecture. It felt like such a natural evolution to me that a society that had magic would have these gothic structures where the practice of magic was almost worshiped. The inclusion of the steampunk aspect also added a fun duality for the setting. The idea that a new world is wanting to be born and is spidering out and around all these gothic structures would say a lot about the world without having to actually say anything.
Example images and callout sheets I created to drive environmental direction
Shatterfield was one of the biggest spells that benefited from a hyper iterative feedback loop
Combat Tweaking
Based on research I did, I knew one of the key design aspects to make the game feel really good was the level of polish or juice our game had. Over the course of multiple milestones one of our biggest iterations was on the feeling of the spells. The spells had to feel good. To be successful in this endeavor with multiple spells I would often consult with the team and oft intone "Get one feature to 50% complete, we test it, then we shore up the next mechanic."
The gameplay of the game is such that when you get one aspect feeling good you would end up comparing and contrasting each spell against the other. In order to make progress, I felt whatever iterations we had planned, it was simplest and fastest to get an idea on screen and test it as fast as possible. With this hyper iterative loop of feedback on testing we were able to get a lot of the spells feeling good and fulfilling unique roles in a very short time frame.
Postmortem
What Went Well
What Went Wrong
Even Better If
Technology working early
From the end of POCT most essential systems were working and had time to iterate over the remainder of development
Cross-discipline team composition
Teams were composed of multiple members of each discipline keeping people from isolating themselves in discipline.
Effective utilization of physical Kanban board
Once we brought in a physical Kanban board to track tasks the entire team did an amazing job at consistently updating the board and communicating what needed to be done in their smaller teams.
Team Buy-in
At the start of the development the team had voted for the idea we went with, this in turn meant that when we started dev in earnest the team really was motivated to make something fun that they all agreed upon.
Create space for feedback
A large factor that would have contributed to our success would have been creating a document for shared input from playtests rather than unguided playtests run by people reviewing only their work.
Reinforce and empower pipeline
Early on it would have helped our production massively if we'd spent the extra time to ensure pipelines were understood and concretely being followed. This would have reduced the amount of work happening in different directions and unified the vision quicker.
A greater utilization of the Prototype milestone
While a good many fun ideas came out of the prototype milestone, we as a team felt pressured to jump into development of a game right away. When we eventually struck upon the fun of our game we picked up incredible momentum and we would have hit that stride much earlier with a properly utilized prototype milestone.
Feedback needed to be gathered much earlier
We gained our most consistent playtesting feedback late into development, this resulted in a lack of concrete information to iterate on in the earlier milestones.
Pipelines were established very late
Pipelines were partially constructed but never reinforced and eventually each discipline created their own pseudo-pipelines. Late into development we fixed this issue, but it caused problems throughout the early milestones.
Sprint Planning often took too long
When making the sprint plan we often would take upwards of a day or two to create a plan for the team to follow. This created problems of people being unsure what they should be working on at the outset of each milestone.
Gameplay took numerous iterations
While the team had a good idea of the kind of game we wanted to make, it took several milestones of feedback and iterations to finally strike upon the fun.