P.A.I.N.T. is an online cooperative shooter where you and your friends can take control of the PUNK’s, rebels who despise the evil grey corporations that take away all colour from the world. Fight them with your paint blaster and bring down the corporation!
Progress was slow when I joined, the team was focussed on creating their own portfolio pieces and a clear direction was missing. They had never made the step to proper Scrum and were stuck in a abstract form of Scrum combined with a Kanban board, I named this Scrumban.
The team needed clear guidance on how Scrum is supposed to work and what their role would be within their Scrum team. To avoid confusion I created a Scrum manual which helped clarify the most efficient production method for the team.
Early 2020, after returning from the internship at Royal IHC I joined project P.A.I.N.T. at Breda University. The team existed of many ambitious developers who had already spent half a year creating a prototype which formed the base for P.A.I.N.T..
The team had fantastic plans for shooting paint which would leave all kinds of effects throughout the map. One colour paint could speed up the player and another caused damage to the enemies. Soon I was to notice that the 7 paints which were created in the prototyping phase were not working properly and they had to be rebuild.
What we learned was that we’re chasing quality and not quantity and so we started build it back up from basic. Could we make a working gun which would inflict damage to the enemy? Yes, but doing this well took time. Once we established that solid base we were able to build from there.
At some point during the project we came across a problem. We had too many character artists and too little environment artists. I had a very strong feeling that some characters wouldn’t be finished due to time constraints, and they weren’t a key element of the game either way. The simple solution would’ve been to abandon one character and move an character artist to the environment art team.
The only problem was that the artist had become very attached to his concept and was convinced he would be able to finish it in time. I could’ve chosen to start the discussion with him in which he would tell me he would be able to make it and I would tell him that that is impossible. Instead I had him make an personal planning, which turned out to be extremely tight on time. We both agreed that he wouldn’t make it if he would come to run behind on schedule. Within a few days the inevitable happened and he ran behind on schedule. We both agreed it would be better if he would work on environment assets.
My learning point was that, if collected, data could be decisive for certain decisions and would help avoid discussions on subjective decisions. That is one of the reasons why proper scrum and time tracking is vital for projects on a tight schedule.