Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Tractor tracks

Most studios have a lot of deep tractor tracks running through their ways-of-working. These are remnants of past times, ways you did it back in 2005. It causes friction to try to change them, and why should you even bother?

Samuel Rantaeskola, Blogger

December 2, 2014

4 Min Read

The world moves at a hysterical pace today, new methods, tools, ideas are available at an unprecedented rate. The games industry is probably among the fastest changers. The competition is insane, everyone wants to make games, right?

In my past I worked at a studio that had been around for a long time. We had a large number of deep tracks running through the studio. Tracks that had been formed throughout years and years of working as a team. Some of these tracks were really helpful as they were lessons from the past that we could use over and over again, such as our pipeline for producing high quality cutscenes. But some of the tracks were really slowing us down, we had to work around them all the time.

Every studio has their own set of tracks that has been cultivated over the years. As mentioned, some of them will be very helpful but a lot of them will get in the way of improving. If left unattended, they become trenches where parts of the team defend their old ways with teeth and nails.

In our case there were plenty of those tracks, I would like to bring up some that had turned into trenches.

Animation department

Our animators sat together and worked as a team on all animation related work. In some cases this made perfect sense, for example in the aforementioned cutscene pipeline. But in other instances this lead to really awkward workflows, mainly around gameplay which was highly dependent of animations. The nature of gameplay means that it has to be iterated frequently, you want a rapid flow of animation tweaks when building such features. However, the department structure worked heavily against us, as requests had to be given to the animation team. Then you had to wait until it was done. Sure, there were ways to fast track animations, but this was just a workaround around the tracks, it cost a lot of time and effort. A smarter solution would have been if some animators were sitting near and working in close collaboration with the programmers that were building these features.

Engine versus gameplay

Since we had our in-house engine we had an engine team maintaining the core systems. On top of the engine we were building game play systems that utilized the core engine features. After years of development on this code base, the gameplay layer and engine code had become quite entangled. Which meant that we were always struggling in the gray-zone between the two layers. Within this area, both teams were inclined to push the work over to the other team. A regular ping-pong game of tasks. In turn this often led to a slow turnaround and outside involvement from people that shouldn’t have been involved in sorting it out. There are a million ways of solving this problem, but we really didn’t get anywhere with that.

Do it yourself

As many other game studios we took great pride in doing everything ourselves. We had few dependencies on external middlewares, and almost never evaluated any off-the-shelf solution. This worked fine when games were smaller, but when the previous generation of consoles came out (Xbox 360 and PS3) the game sizes ballooned. Then we had two options, either we scaled our team a lot or we would start focusing our attention on a few things that we do really well. We chose the former. Given the studio location, it was hard for us to find enough skilled people to grow the team at the pace needed. Even if we could have grown, it would probably not have been a wise choice, as a bigger team means more complexity. The smarter option would have been to start integrating middleware that solves parts of the problem for us and kept developing the areas where our core skill was. However, the tractor tracks were deep and we never really took the leap.

If my current employer, Simplygon, would have visited our studio, it would have most likely been rejected at the door for the above reason. Now, with the benefit of hindsight, I know that it would have been very helpful in our asset pipeline.

Eliminating the bad tractor tracks

Unfortunately I cannot give any good advice on how to get rid of the tractor tracks, every studio have their own set. The first step is however realizing which tracks are running through your studio. If you aren’t aware of them they might be leading you in the completely wrong direction, when the rest of the pack has come up with smarter paths. Even worse, they could lead to internal conflicts with bitter trench wars within your team.

A final word of caution is that some of those tractor tracks are part of your secret sauce, some things you do better than everyone else, those you should be very careful of disturbing. 

What tracks do you have in your studio? Are they for good or bad? Feel free to share your experiences in the comments below.

Read more about:

2014Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like