Hey, nice to have you here!
What could your company achieve if your pipeline delivered builds every hour with huge amounts of changes based on director feedbacks? When would you deliver your current project? Maybe next month or one year less.
So, I have been working in Vietnam for around 3 months now and it has been quite a ride!
But, the main goal of this article is to tell you how I managed to make a rusted and a bit “off” game development pipeline into a lightning-fast iterative production pipeline with instant feedback adjustments and art iterations on builds in an on-demand fashion.
So, there I came to Vietnam, work on a mobile company for a really nice brand based word game.
At first, there were a lot of obvious mistakes that made the art team pipeline struggle to achieve its creative potential on a production scale. Sometimes they were caped by the engineer’s team, other times they needed to rely on engineers to make their artwork properly.
I mean, there is nothing wrong with art and engineer work together to solve issues, actually, that is good(!). But there is the right balance on that interaction that needs to be maintained on a recurrent basis.
The art team prepared everything for the engineers to reconstruct the VFX and UIs as best as they could, with detailed mockups, split sprites, VFX previews already approved by the art director, everything.
Unfortunately, the engineering team kept delivering variable results, with few to none related to the actual targeted quality.
Why?
Well, this is where I came in, with this single objective in mind:
Make the art team result reach the build level with minimum hassle, rework or engineer input.
Me, I guess…
In the first month, I spent the most time talking to the art and code team, fiddling with the project files, testing changes, looking for anything that could be breaking the pipeline.
In the first month, I spent the most time talking to the art and code team, fiddling with the project files, testing changes, looking for anything that could be breaking the pipeline.
At the end of the month, I had a clear picture of what was going wrong and making the visuals go south.
There were 3 main solutions for achieving better results in this particular context:
- Interpersonal Communication
- Technical Empathy
- Delivery Medium
Believe it or not, 2/3 of the problems were interpersonal. That made me realize how important the people in front of the computer, making the game, really are. They can break or build a good game!
So, being a technical guy, I had never thought that I would need to talk to people and convince them to help me solve their own problems, that was a big barrier that I would need to overcome within a matter of days, and I was up to it. Wanting it!
I was in love with the idea that I could help people understand how precious their time is and how can they work smarter giving better results.
But, obviously, just talking was the easy part, everybody was on the same page, and now what? This is where software comes to unite the art and code tribes! Yeah, you read it right, UNITE!
Have you heard about GitHub? Or any kind of version control software really. These can do magic, like time travel, but that is another story.
Now, let’s focus on how I managed to make an art team use git and increase their process speed by hundreds.
When somebody needs to learn GitHub, that can become a burden, I know, I was an artist once in my life (really!), and because of my previous knowledge I knew the mind blockers that artists usually have when using too technical stuff (software), but I needed to make them understand why and how they would benefit from it.
My first attempt was with a VFX artist, was a nice moment, we just had a prepared week, she had an intro animation to put in the game so art director could evaluate. So:
- Let’s use Git! – I told her, and she looked scared to me – Everything will be fine! – I reassured her.
Well, after cleaning the necessary assets and prefabs, it was time to make the jump, and it went really nice!
Went nice because at the same time she went to tell the engineers that it was ready to add in a demo scene, and they did it right away and 15 minutes later we had a functional build that played her animation on the device.
Then the art director gave her some feedbacks and she iterated on them and within an hour we had a second build with her changes, and the best part is that she did not need the engineers to fiddle with her stuff again, so they just needed to run the Jenkins server to make a build, and they were going to do it anyway so it felt like a glove.
In 2 hours we had an almost release ready intro animation.
Me, again…
Why this is a big deal? Well, these type of things used to take 1 or 2 days to come to fruition, they sent files through Skype! Do you know how much time it takes for somebody to remember that you sent something important that they will use? Well, guess what, when they need it!
And an engineer can be held on a task for so long that it makes impractical to iterate art on this speed and granular level without any pipeline optimization.
Ok, I covered 2 of 3 issues.
Now, what is Technical Empathy? Does that exist?
Hm… Yes, it exists and is really important.
Technical Empathy is the ability to relate to the technical knowledge of another person and see the technical world through their eyes.
Workiva
So, having noticed this issue, how I would explain to artists how engineers see the world? I mean, really?
Believe it or not, that is possible, with a bit of love and creativity! Whenever I needed to make a guideline for the artist to have a look and readjust their process accordingly, I added a bit of the engineering perspective like modularity, optimization, organization. Just a few bits so they could digest it slowly and put that on practice on their own.
Overall, these three steps turned out to be really successful and now the team iterates faster than I can follow. With a lower amount of rework and better quality of life.
In a future post, I will share more in-depth processes and how everything went so smooth.
🙂