NO EXPERIENCED PUBLISHER BEHIND IT: Why SCS largely had to learn the console port itself

Many game developers choose a considerably more convenient route for a console project. A publisher or specialised porting team understands the technical requirements of the platforms, maintains contacts with Sony and Microsoft, supports certification, and knows which documents, testing procedures, and store information are required at each stage. Age ratings, translations, marketing material, release planning, and update coordination are added to this. Anyone who has already completed these processes several times does not have to discover every shortcut and dead end during a new project.

SCS has not publicly stated that it deliberately rejected such a partner. What is certain is that the studio is listed as both developer and publisher on the current store pages and is building a large part of the necessary expertise within the company. Jakub Mráz explained that other studios frequently rely on publishers or experienced teams for such projects. SCS, by contrast, spent approximately two years learning the details of this new console ecosystem.

This statement makes clear that the port does not only involve programmers and graphics. Quality assurance has to learn how to test problems under the conditions of different consoles and document them clearly. Production has to account for new approvals, schedules, and platform requirements. Marketing needs different store pages, image formats, texts, and approvals. Localisation has to translate not only the game, but also store descriptions, system messages, and platform-specific terminology correctly. For a studio that has supported its games mainly on PC for many years, this almost creates a second publishing operation.

Jan Križák explained that SCS also hired new specialists for this project. However, the original console team was built strongly around existing employees. This combination makes sense: New colleagues can contribute experience with platform procedures, technology, or certification, while long-term SCS staff already understand the games, their engine, and many unusual special cases. An external porting studio would first have to acquire this knowledge.

Internal game knowledge is particularly valuable with ETS2 and ATS. Neither title is a completed campaign that is ported once and barely changed afterwards. Both receive continuing updates, maps, vehicles, features, and DLCs. A team that only creates a one-time console version would need to become involved again with every major change. When the knowledge sits directly inside SCS, future content can be considered for every platform from an earlier stage.

The price is a greater burden at the beginning. Anyone building console expertise during a major active project is not collecting experience through a small exercise, but directly through two extensive games. New procedures may prove impractical. Responsibilities have to be redistributed. Teams may only discover late that a seemingly small PC feature requires additional work on console for the interface, save management, testing, or certification.

An experienced partner could begin faster in these areas. It already has templates, internal checklists, and employees who understand typical problems. However, this does not automatically mean that the complete port would be finished more quickly or at a higher quality. External teams need information, priorities, and regular coordination. Decisions move between companies. A partner may also be working on several contracts at the same time and may not understand SCS’s long-term product strategy as well as the internal team.

SCS would also surrender part of its direct control through complete outsourcing. This concerns not only technical decisions, but also schedules, quality, and the order in which new functions are introduced. For a studio intending to continue developing its two most important games over the long term, this dependency could become problematic. Every new DLC and major update would have to fit reliably into the same external process.

The internal route can therefore be more attractive in the long term even when it appears slower during the first project. Once SCS fully understands publishing on PS5 and Xbox, this knowledge remains within the company. The next update does not begin from zero again. The teams know the requirements, typical problems, and necessary approvals. New employees can also rely on existing documentation, tools, and experience.

Whether this will genuinely allow later updates to arrive more quickly on consoles cannot yet be guaranteed. Platform checks and technical differences will not disappear. Nevertheless, an established process should be more reliable than a first release in which many questions still have to be answered for the first time. The console port is therefore not only a new product, but also a major internal training programme.

Other departments can benefit from it as well. QA learns about new hardware and testing methods. Developers have to standardise functions more strongly. Marketing and localisation build knowledge of two additional platforms. Production learns how to coordinate releases between PC, PlayStation, and Xbox. Even when this knowledge initially costs considerable time, it can later be used again for DLCs, further projects, or potential new games.

This strategy is not without risk. Internally developed knowledge frequently depends on individual specialists. When important employees leave the company, experience and contacts can be lost. SCS therefore has to document its processes and distribute them across several people. New colleagues and experienced SCS staff have to learn from one another so that the console project does not remain permanently dependent on a small number of central individuals.

The route is also a major economic bet even though we do not know the specific costs. New positions, additional testing, and years of preparation create expenses before the first console version is sold. In return, SCS may not have to purchase a complete external port again for every expansion. Whether the investment is worthwhile therefore depends not only on the first day of sales, but on the long-term use of the knowledge created.

Careful wording also remains important: SCS is not proven to be working entirely alone. It is not publicly known which technical service providers, consultants, or other partners may be involved behind the scenes. The absence of an external publisher handling the complete process does not mean that the studio performs every individual task without support. The important point is that responsibility and publishing expertise apparently remain largely within SCS itself.

The independent route therefore offers more freedom, but also demands patience. A publisher with an established console team could probably have accelerated certain phases. In return, part of the knowledge would have remained outside the company. SCS is now investing more heavily in its own structure and turning the first port into a foundation for whatever may follow.

For us as a community, this difference matters. The lengthy preparation is not automatically evidence of missing competence. It is partly the result of SCS attempting to build a new capability permanently. This does not excuse every delay and does not replace a finished release date. However, it explains why the console port is changing the company much more deeply than an ordinary technical conversion.

In the end, the question is not whether internal or external work is fundamentally better. What matters is whether SCS turns the experience of these first years into a stable process that can genuinely be reused after release. If that succeeds, later updates, DLCs, and further console projects could become considerably easier. If knowledge transfer within the company fails, the advantage built at great expense may remain tied to individual people and this one project.

Do you think it is better that SCS is building the expertise itself, or should an experienced console partner have accelerated the process?