
DIGITAL PROJECT MANAGER
Forsaken is the current project my team and I are working on for our third academic year, we've come along way since the beginning of production and are looking to polish our game towards a triple-A standard with the remaining months of the year.
Our team composition consists of 4 Artists, 2 Animators, 2 Programmers and 2 Designers.
On my team, I serve the role of Producer & Animator.
RESPONSIBILITIES
- Consistently track our progress
- Identify and resolve problems with development
- Resolve team conflict
- Maintain scope expectations
- Hold scrum & Deadline meetings
- Rig & Animate hostile enemies (Boss & Rat)
- Help with UI, Art & Animation implementation
- Design the structure of the boss fight
Timeline & Evaluation
​
The goal of Forsaken was to create a Souls-borne experience, taking inspiration from many of the mechanics used in Dark Souls. Our twist was the implementation of Bullet-Hell elements, as both genres follow a similar philosophy but are rarely intertwined.
​
-
Pattern Recognition
-
High-Difficulty/Stakes
-
Challenging Bosses
​​
As the semester started, I knew now more than ever that I had to clearly define my teams tasks leading on into the end of the year, the likeliness of completing our project without any form of organisation would be unlikely, so I took advantage of this and made a prioritisation document, followed by a burndown chart as well. Things have been going far more smoothly and I think the priority right now is to get the core design functionality to give the game far more depth.
What went well:
-
Programmers refactoring their code allowed for a significant increase in speed during production
-
Creating levels of prioritisation for chunks of a game provided a focused and effective scheduling for sprints
-
Understanding the timeline of our production allowed members of our team to deduce whether they were behind schedule and if they needed to put in more hours
What went wrong:
-
The game design could've been far more clear, there were many inconsistencies with programmers and designers due to lack of communication
-
Our USP wasn't defined as soon as it could be. It was only during the middle of development that we dedicated ourselves towards bullet-hell elements
What I've learnt:
-
Give programmers time. As the project went on I had learnt how to code to an average level and could understand why they demanded time for clean code. The pressures of meeting deadlines can make this balance difficult and that's why it should be communicated appropriately with programmers. In the long run, it pays off.
-
Design Documents & Master Documents are meant to be accessible, a reoccurring issue during development was the confusion on the design vision of the game, this wasn't because the documents didn't exist, they just weren't easy to find!
-
Pinpointing core goals for your game can make the creation of prioritisation documents incredibly easy, in this case, our game's main focus was the boss fight, meaning the character controller and boss AI were first and foremost the things we had to tackle.