Design QA and Lessons

This is an overview of the Quality Assurance process that has been followed in the design team. We have divided it in Internal, and External QA.

Internal QA

All the features that are going to be implemented, or those that already are in the game, go through our internal QA process. This process usually consists on a team meeting, where after testing the game, we dicuss and give feedback about the feature. When deciding if something stays, or it's removed, we always have in mind the game pillars, and the game vision. If we are having a difficult time reaching a conclusion, the Lead makes the final decision.

External QA

For external QA we've set up QA sessions with the whole team (Art, Code, Design). In this sessions each member has been submitting bugs, and balance problems to GitHub Issues. This sessions have been specially useful for the Code team, but we have found a lot of balance problems thanks to them.

Learnt Lessons

To conclude, we have put together a list of some of the mistakes we've made, and what we have learnt from them:
Scope: The scope of the project was way too ambitious, we underestimated the difficulty of putting everything together, and we overestimated the work speed of the other team members. We've learnt that knowing what tools we are working with, and the workload our teammates can handle is essential.

Engine: Related to the previous one, we underestimated the difficulty of working with a custom engine that isn't feature complete, and that is not completely stable. The engine set us back in a lot of the early tasks, until we learnt to predict better how much time it takes to put something in it.

Minimal Parts: Dissecting the core of the game in minimal parts has been essential in the pre-production phase. At the beginning we didn't do it and we had a lot of focus problems, because of this, we had a session where we went back to the basics, and with the help of references, we focused on completing the smallest parts, to later expand the scope.

People: As mentioned in the scope section, not everyone works the same, so it's always useful to have a plan B, and in case this one fails, a plan C that will minimize the risk.

GDD: We have found that very few people have consulted the GDD. They prefered small documents with the specific information they needed, than a whole document full of information that contains the information they need in one of the sections. Even though it worked great for solidifying the game vision, to implement things separate documents have worked much better.

Organizing Method: We found out that for some tasks that were shared between teams, the method we used to estimate tasks, wasn't working. We decided to switch to Gantt Charts for some of this tasks, and we've had really great results with this method.