Post

Folks have mentioned teams need to stick together over long periods, to make sure they can keep their knowledge and expertise and apply that to future games. This is true. Similarly, the tools & pipeline also needs to stick together. You cannot just grab an FPS game pipeline and make an RPG.

There are always tradeoffs to be made in pipelines. Some things will be easier, which will make other things harder to do. This is also a big reason so many different editors and engines exist: They all make different tradeoffs, and so different people prefer them for different projects.

Often times a studio gets to ask not to make the games they are good at, but instead to 'Fill up the portfolio' from the publisher. So the studio is asked to, for example, make a live service game even though the studio is very good at singleplayer games.

Sometimes this is reflected back on the studio, because the studio pitches a bunch of games, some of which they are very good at, but others they know their pipeline and experience isn't good for. But it's the publishers that greenlight. If they decide you do live service, now you have to do it.

This isn't just a problem for the experience of folks at the studio, who haven't made games like that before, but it's also the pipeline. For example: A cinematic FPS pipeline is very good and focused on first person perspectives, blending those into cinematics, and up-close environmental detail.

If you suddenly decide to make a live service racing game with that same FPS game pipeline, it will seem like it's functioning on the surface, but it's not. There are actually loads of workarounds present. Hidden workarounds. Those are Watermelons: www.youtube.com/watch?v=mQGO...

It is very easy to look at a pipeline and say "You have code, you have node graphs, you have a VFX editor and a material editor, so just use those!" But that's inexperience talking! Anyone who has been in the depths of pipeline development will know this is not feasible without a lot of time.

Because while you are able to use that code, suddenly for a racing game you have to re-adjust cameras, which also means adjusting the 3Cs, which requires a lot of testing and iteration for user adjustable camera angles: Third person, in-car, and front bumper. This is very time intensive work!

We have seen many studios run into these problems over the last few decades. Yes, decades. This is an ancient pipeline problem that somehow keeps being repeated, similarly to how well function teams getting separated despite it being an obviously bad thing to do.

I mentioned tradeoffs earlier: When you switch genres, suddenly the tradeoff discussions that you had about the pipeline 5 years ago, do not make sense anymore moving forward. You have to revisit literally years old code, to now make a different tradeoff. Which has a domino effect. It costs time!

When entirely switching genres it can sometimes literally be better to build a new pipeline from scratch rather than use an existing one, because an existing one is a ball of yarn in which you now have to surgically insert yourself to fix the bit of yarn at the middle. Possible! But time intensive.

Now insert the problem of it being 'For the portfolio': The portfolio can adjust at any moment. Finance people work in quarters and yearlies. If in any particular quarter or yearly 'the portfolio' needs to be adjusted, that means the game may switch genres again, even subtly.

If at that point you think "Well, they have code, a node graph, a VFX editor..." etc, then the ask to switch the game around will look on the surface as 'Just switch things around slightly!' Especially if Unreal is involved, which folks then think is 'Able to do everything!'

And Unreal can do many things, and it is really fast at doing many things, but remember how every editor and engine has tradeoffs? Even Unreal itself does! Nanite has huge tradeoffs, where depending on what you make, it can be either amazing, or slow you down. It requires adjustment.

Let's look at positives instead: If you have a team that is used to building certain games, and used to working with a certain pipeline, things can work out great. I think Hazelight is a wonderful example of this. They make split-screen co-op games. They've had 3 and 4 year development times! Nuts!

So I know this sounds banal, but keeping teams together is important, and keeping pipelines together is important. The moment you split a pipeline up, or you suddenly ask a pipeline to reverse course, you are mangling a pipeline that took years to set up. And now it will take years to redo.

Also, the absolute work case scenario is letting a bunch of people go, and then requiring the team to change genres. Remember that ball of yarn I mentioned? Now everyone who knows what's at the center of it, no longer works there. Which means your pipeline is now rotting at the core. It will die.

The pipeline will die when you least expect it, because nobody can even smell that it is rotting at the core. Sometimes you may not even notice until right before you ship, a few months out, that suddenly you cannot debug or QA all the incredible detail that you need to polish. It's too late.

Oftentimes my work as a consultant is literally to look at what the pipeline needs, at the concept phase. It's to look at these issues as someone who has worked on many games, with many timelines. You can see what's missing, or what will cause issues. But fixing it takes time.

The other way around, of trying to squeeze a game through an unfit pipeline to try and achieve a 'vision' no matter what, usually ends in crunch, delays, and a worse quality experience. There is no upside.

While I can't recommend super specialised engines/pipelines due to e.g., maintenance cost when shipping different types of games (like in large devs/publishers), I completely agree that trying to fit a cube on a sphere hole more often than not causes trouble and wasted resources. Tough problem.