We stepped into this project knowing it would be a hard task as senior students warned us about it. Because of it, we knew that keeping morale high was a top priority.
As expected, the first 2-3 weeks were quite chaotic due to the agile development shift in mentality. Members of the team still had department-centric approaches to structure and work synergy. This affected the earliest stages of development, a problem that could have been solved if we did heavier prior research into the matter. Agile development is extremely useful, but it needs a robust and knowledgeable implementation.
Developing the game at the same time that we developed its engine proved to be a problem tenfold worse than expected. Development was often halted due to technical problems, new features had to be constantly delayed and a general sense of unease was felt each time an engine tweak was brought to the table. Although we had no alternative, let this be a warning to all who think of following our path: just don’t.
We knew that to fit all we wanted to do in the short span of 4 months some sacrifices needed to be made. At some point in development, we decided that updating our documentation was something we could sacrifice to have more time. Huge mistake: the amount of time we needed to fix mistakes born out of confusion and misunderstanding because of this heavily outweighs whatever time we thought to have gained.
The team worked exceptionally well in an online environment. We feel that, although we would have loved to have presential meetings, we adapted fast and we adapted well.
Going for a low poly aesthetic enabled a fast and solid art production pipeline. We used heavily post-processing effects and an aggressive approach to lightning to compensate for the lack of detail in a low poly aesthetic. In the end, this meant we could produce all the assets needed in a short time without sacrificing quality.
Early in production, we decided that our top priority in design was the game feel surrounding the main character. It needed to feel good to move, dash, shoot, throw, aim… For months we iterated over it, as much and as long as we needed until it met our expectations. Although we knew it was a risky approach (we were tweaking core gameplay systems one month before release), we think it was a correct decision, for, in the end, we ended up with a better game because of it.
Working in 4-6 members scrum groups in one week-long sprint has to be one of the best decisions we have made. Problems were detected early and solutions were offered even faster. However, the best part of it was that if someone was burned out of their current position, we could accommodate them in less than one week without any process or feature being delayed or affected because of it.
Having a small code team meant that we had to keep to a minimum the time spent rewritten old code or fixing unintended mistakes. Despite the aggressive deadlines, the code department had the skill and perspective to take things at their own pace, making sure to produce robust and trustable systems.
We started playtesting early, and we had a playtest & review pipeline well before that. Multiple members of the design team were focused on playtesting for multiple milestones. Although a substantial loss of workforce, this proved to be a key decision in the result. Having multiple playtest sessions with re-appearing testers and having multiple design meetings to discuss the results proved to be an excellent decision.
Being young and inexperienced as we are, none of us had prior experience of working with a lead, much less being one. Despite that, we were quick on our feet, combining research of prior projects, constant communication between us, and direct communication with the team.
In the end, we are extremely proud of our game. We think it reflects the amount of work, illusion, and emotion the team has poured into its development and we hope every player feels it too.