Internal Quality Process & Learned Lessons

• David Franco Alonso

Internal Quality Process

Acceptance criteria document

In order to make it everything easier for everyone inside the team (not only in the art team, but the whole development team), a document with a series of was created. This file explained all the steps that any member should follow in order to submit an asset. In order to avoid confusion as much as possible, all the steps are explained, going from the most basic ones, like the name the file should have, to more technical stuff about the asset. You can check it HERE..

Lead reviews & Repository distribution

The lead artist has the final word, so that means there is always somebody reviewing the work done. The lead, following the acceptance criteria document, will determine if an asset is accepted or not, so the team can know for sure without having to test it, that the asset is fully functional and it has passed the quality control test. It is important to note that there were two repositories. One for the art team, where the assets that are done are uploaded so the lead artist can review them, and another where the reviewed assets are uploaded. This creates a clear environment, and avoid problems caused by missunderstandings.

Different versions

In order to react as fast as posible in case any problem appeared, there were different versions of the most important assets, ordered by chronological order. In case some asset would be giving problems for an unkown reason, the team can always go back to the other one, or use the old one in extreme cases.

Meetings & Periodic checkouts

Communication is very important when it comes the final quality of an asset, and that is because it is very normal to need help from other people in the team to do what you want to do. In order to avoid this problem we chose to do periodic reunions. Apart from the scrum meetings, which are useful to comunicate with the rest of the team very fast, we also did some internal meetings where we would discuss topics more on depth. These meetings were once or twice every delivery. Another thing that was done was to have periodic checkouts where the lead would go to every person in the art department and see how the task was going. These task were weekly, but in the later stages of the development, they were every day or every two days. This allows the team to have the lead and his team connected at all time, and not only have a general vision of the process, but be aware of every problem the person doing the task may have. Thanks to that, decisions like changes in the asset or cancelling the task could be done much earlier. Also, allows the lead to give direction if he or she thinks it is necessary.

Github Issues

Github tool offers us the possibility of communicating different bugs in the game as quickly and as clear as posible without losing any time.

Lessons learned

Don't try to reinvent the wheel. If something works, it is for a reason

Consider the others' opinions, but don't take them as the truth. If everyone tells you the same maybe you should consider to change what you are doing, but don't let the opinion of one person change your vision.

Prioritize. Don't think about tasks as a list, but as a pyramid. Make sure, everything in the lower level is done before going to the next one.

Iterate. Don't pretend to have the final asset on the first 10 days, things may change. Make sure every iteration matches the specifications of every milestone.

You need your team but your team needs you as well. Don't be afraid of asking for help nor offering it. Remember you won't be judged by your personal effort but the final game.

Keep yourself motivated. The game has to be done either way, so better enjoy the journey even if you don't like the destination. Find ways to motivate yourself if the project is not doing it for you.