I don't believe anyone just drew their final breath in the last scenes.
Trails Of Cold Steel III
- Thread starter cm2
- Start date
Read Interview on porting the game to PC and Switch by Rpgamer:
RPGamer: What are the hardest/easiest parts of the ports?
Ruud van de Moosdijk, VP of Development @ Engine Software: Compared to ‘regular’ game development there are a lot of challenges that don’t come into play when porting a game: design, flow, story, asset creation, so I would say the easiest part is that all that hard work has been done and you know you have a robust and complete product to work with. Obviously, there is always some redesign and specific asset creation needed for any good port, but even then, you have a solid reference point in the existing material.
The hardest parts – on the Switch side – are usually performance and size. Ideally you want solid and consistent FPS throughout the game in both docked and handheld mode, while a lot will be asked on the optimization side of things to keep the total size of the game as small as possible. On the PC side this is not much of a problem, but on the Switch side it directly correlates to higher production cost.
Peter “Durante” Thoman @ PH3: When working with a large RPG like this, the sheer volume of content is always a challenge. On a technical level, specifically on the PC side, there are two challenges that stand out, one of which is unavoidable and one of which we, to some extent, brought upon ourselves. The first one is maintaining compatibility with the variety of hardware and software platforms that exist in the PC space. For many modern games using well-established multiplatform engines such as Unity or Unreal, that work has already been done, and they are well tested on a huge variety of platforms. For Trails of Cold Steel III, we had to completely revamp and even largely rewrite the audio and video playback modules after beta testing on a wider range of platforms.
A second challenge comes from all the features we added to the PC version, especially regarding rendering.
CP @ RPGamer: With multiple time zones in play, how do the teams communicate and stay
connected?
RVDM @ ES: Most communication between the teams is done via Skype or E-mail. On the development side everyone is in the same time zone, so it really is not an issue. There is also enough of an overlap with US time zones that direct communication with NISA is never a problem, and if there is something urgent to discuss it is a small effort to set that up. We also have a presence in the US (me!) so we have a couple of hours of overlap with the dev team in Europe and then the entire work day in the US.
PT @ PH3: For Engine Software and us, time zones aren’t really an issue, since we are both in Europe. That said, many programmers keep strange times anyway, and I’ve had Skype discussions with some developers at Engine at 11 pm local time (for both of us). With NISA, there usually isn’t anything that requires up-to-the-minute responses, so things like Skype or traditional email work well. For beta testing, we use a bug tracker and a Discord server. We have some great long-term beta testers who are extremely active and help a lot with managing things, especially now that we expanded the beta to more people.
RVDM @ ES: I’d like to add to Peter’s comment about programmers’ strange times that I regularly leave messages for one of our programmers at say 9pm CST so that they will see it right away in the morning… just to get an answer back one minute later (which is 2am in The Netherlands).
CP @ RPGamer: Given the different hardware targets, is there much overlap between the
things that the two teams are doing? Are there areas where one has managed to
help out the other?
RVDM @ ES: As soon as we started working with PH3 we set up a joint codebase that we would both be working with so anything that is not platform specific that is added, or optimized or fixed is immediately beneficial to both teams. Overall, I think it is fair to say we benefited the most from the collaboration initially as Peter had the prior experience with the series and the engine, and specific tools that were very useful.
PT @ PH3: One thing we knew when we started to work on ToCS3 is that we needed better compression. With the approach we took on ToCS2, the third game would have required over 70 GB, which is a bit ridiculous. So we investigated a variety of compression algorithms and ended up implementing several of those, and a new package format. It actually turned out to be a good thing that we implemented several different algorithms, as we settled on lz4 for PC (after evaluating lzss, lzma, lz4 and zstd), while I believe Engine settled on zstd for the Switch version. We decided to go a bit larger in terms of disk size on PC for slightly better cached loading times.
In the other direction, Engine did the full localization integration, which saved us a lot of work. And of course, both teams fixed many bugs that are not target-platform-specific.
CP @ RPGamer: How did the teams ensure that the experience on both platforms would be
comparable? Do you feel that you’ve succeeded?
RVDM @ ES: We are working with a shared codebase for the actual game, so the only difference between the two versions are non-gameplay-related changes. In that regard I think wanting the experience to be comparable is not what you should strive for. A port should be the best version of that game on that platform. If that means that there are differences between the Switch and PC versions because a different solution or approach works better for one platform, we are making the right choices.
PT @ PH3: To us, the goal when creating a port for a given platform is to make the best version of the game possible on that platform, given the existing time and engineering constraints. This means that the PC version will obviously have a much larger variety of graphical options and supported framerates than the other versions.
Of course, the actual gameplay should be identical, which we ensure by using basically 100% shared gameplay code across both platform versions.
CP @ RPGamer: Was it more difficult to port to the Switch, given the hardware limitations, or to PC, given the variety of different hardware targets?[/B]
RVDM @ ES: It is different, but I don’t think you can just call one more difficult or easier than the other. On Switch (and any console really) you work with fixed hardware so once it works, it will work the exact same way for everyone. On the other hand, since you work with fixed hardware there is no wiggle room in terms of performance, memory usage and game size… Switch ports generally require more optimization compared to PC ports.
PT @ PH3: I talked about the issues with different hardware/software targets above. Overall, I’d say the challenges are different and not directly comparable. For example, when you get a report about a given graphical or performance bug on a console, it’s very likely that you can recreate that same behavior locally. On PC, you might have to perform some more “speculative” debugging. On the other hand, it’s much easier to push out builds on PC, and you are not as constrained in general.
CP @ RPGamer: Where do you start when you begin a port? Is there a general process to follow? Do you start (i.e. gameplay first, then audio, graphics, etc.)?
RVDM @ ES: You start by looking at your source material, even before you sign on for a project. The technical evaluation is an important step in the process…do we have all the source materials? Is it complete? Readable? Buildable? Does it use existing or custom engines?
The next step would be to get the game “as is” running on the target hardware… so without platform specific changes. Everything else follows from that point… what needs to be optimized, what controls need changing, what UI needs changing, what feels unnatural on this platform.
PT @ PH3: For us, we generally start our actual work with getting a minimalistic version of the game running on the target platform. “Minimalistic” here means no new features of course, but also entire easily separable modules (like video playback or even audio) might be missing. After that (or concurrently, depending on project team size), we start working on those modules.
CP @ RPGamer: What are the differences between fixing ports in your free time and doing it with the oversight of a publisher?
PT @ PH3: Well, for one, you get paid
More seriously, it’s much easier to make improvements to a game when you have access to its source code. However, when you are working on it in an official capacity, that also comes with some constraints you don’t have while modding. E.g. in a mod, it isn’t really a big deal to add a feature that crashes for 15% of the people – you just tell them not to use it. That’s obviously not an option for an official port.
CP @ RPGamer: You provided clear Legend of Heroes fan bona fides upon the port announcement with your copy of Dragon Slayer. How has being a fan of the series help with creating the port? Is there added internal pressure to get it right because of it?
RVDM @ ES: Ah, you saw that did you? It’s not even the Legend of Heroes specifically: we have been trying to work with Nihon Falcom since the early 1990s; back then communication with Japanese studios was a lot harder, and it didn’t help that they (Falcom) had no idea their games were popular at all in the West. In 1987, Ancient Ys Vanished Omen was the first RPG I ever played, so you could literally say that Falcom introduced me to the genre.
As far as pressure goes, we always feel pressure to deliver the best port we can regardless of what game it is, so professionally there is no change. Emotionally it can be taxing to work on a project you are a fan of: on one hand it is great motivation and it is only human nature to put just that little bit of extra effort into it when you are passionate about something. On the other hand, it can have a significant personal impact if something goes wrong for whatever reason.
CP @ RPGamer: Can you share some of your best “moments” when working on the port?
RVDM @ ES: Best moment in any port is to see the graphics coming alive on your target platform after working ‘blind’ for a few weeks. Ports often literally look like a long list of compiler errors at first, then a first green, pink, or even textured triangle. So, when all the pieces of the puzzle start to fit together and your team’s effort renders the title screen, and then the first scene or intro… the feeling is hard to describe, but it is always very special.
PT @ PH3: My favourite moment was probably when the localization was first merged. I’m a huge fan of these games, and that was the point when I could finally start actually playing it. I also always enjoy the moment when I get PCSS shadow filtering working on these games. It’s very expensive performance wise, it’s subtle, and no one should care this much about it, but I just love variable penumbra shadows. I’m weird like that.
CP @ RPGamer: What’s one thing you would add to the Switch version if you had just a bit more processing power?
RVDM @ ES: Honestly, we have not yet run into a situation where we were not able to achieve what we wanted on the Switch. Raw processing power is not a holy grail when it comes to these games, smart architecture and smart engineering solutions can get you a long way.
CP @ RPGamer: Are there any locations, characters, events, etc. that have particularly gratifying to see working?
RVDM @ ES: This might be almost too specific, but I got chills the first time I saw Saint-Arkh in handheld mode! It’s just such a beautiful place and even though it’s in lower resolution in handheld mode it looked stunning all over again.
PT @ PH3: I really enjoyed all the “introduction scenes” for the recurring party characters from ToCS1 and 2. It’s funny how they are more and more over-the-top and seeing how the new characters react to them.
CP @ RPGamer: What been your favourite parts to work on in the game?
RVDM @ ES: Some parts of a port are straightforward, like general game design and audio – you just go with what the original product provided. For porting to Switch the challenging work is usually the most fun to do – so optimization for performance and size – unless it doesn’t work!
PT @ PH3: I’ve always been into graphics and optimization, so my favourite parts are generally when I can implement new graphics features or optimize some component. Working on optimization is especially rewarding if you have a clear, measurable target, a fast feedback cycle, and a well-separated component that makes it unlikely for optimizations to break anything elsewhere. Recently I spent a few hours optimizing video color space conversion and greatly improved its throughput, that felt great.
CP @ RPGamer: Does the Switch having handheld and TV modes introduce any additional difficulties?
RVDM @ ES: The game was written for PlayStation 4 and since no PlayStation Vita version was made (unlike the previous two games) a lot of assets were very heavy for the Switch handheld mode (less for the TV mode as it features a boosted GPU). Previous games in the series were better optimized for handheld consoles, but for ToCS3 we could not rely on optimizations from the original developers and had to open Pandora’s box ourselves.
CP @ RPGamer: Are there particularly funny or noteworthy bugs that you’ve seen during the porting process?
RVDM @ ES: We usually get the funniest results when we tinker with the frame rate, and the game is not set up to work with variable frame rates. For example, we had one scene in the elevator where the entire party just kept jumping around like mad and it was too funny.
PT @ PH3: There are some amusing things that can go wrong graphically and/or with frame rate issues. For example, I recently had a situation during development where playing on an ultrawide screen messed up the aspect ratio for character head/bust shots in dialogue, which resulted in some very wiiiiideeee faces.
RPGamer: What are the hardest/easiest parts of the ports?
Ruud van de Moosdijk, VP of Development @ Engine Software: Compared to ‘regular’ game development there are a lot of challenges that don’t come into play when porting a game: design, flow, story, asset creation, so I would say the easiest part is that all that hard work has been done and you know you have a robust and complete product to work with. Obviously, there is always some redesign and specific asset creation needed for any good port, but even then, you have a solid reference point in the existing material.
The hardest parts – on the Switch side – are usually performance and size. Ideally you want solid and consistent FPS throughout the game in both docked and handheld mode, while a lot will be asked on the optimization side of things to keep the total size of the game as small as possible. On the PC side this is not much of a problem, but on the Switch side it directly correlates to higher production cost.
Peter “Durante” Thoman @ PH3: When working with a large RPG like this, the sheer volume of content is always a challenge. On a technical level, specifically on the PC side, there are two challenges that stand out, one of which is unavoidable and one of which we, to some extent, brought upon ourselves. The first one is maintaining compatibility with the variety of hardware and software platforms that exist in the PC space. For many modern games using well-established multiplatform engines such as Unity or Unreal, that work has already been done, and they are well tested on a huge variety of platforms. For Trails of Cold Steel III, we had to completely revamp and even largely rewrite the audio and video playback modules after beta testing on a wider range of platforms.
A second challenge comes from all the features we added to the PC version, especially regarding rendering.
CP @ RPGamer: With multiple time zones in play, how do the teams communicate and stay
connected?
RVDM @ ES: Most communication between the teams is done via Skype or E-mail. On the development side everyone is in the same time zone, so it really is not an issue. There is also enough of an overlap with US time zones that direct communication with NISA is never a problem, and if there is something urgent to discuss it is a small effort to set that up. We also have a presence in the US (me!) so we have a couple of hours of overlap with the dev team in Europe and then the entire work day in the US.
PT @ PH3: For Engine Software and us, time zones aren’t really an issue, since we are both in Europe. That said, many programmers keep strange times anyway, and I’ve had Skype discussions with some developers at Engine at 11 pm local time (for both of us). With NISA, there usually isn’t anything that requires up-to-the-minute responses, so things like Skype or traditional email work well. For beta testing, we use a bug tracker and a Discord server. We have some great long-term beta testers who are extremely active and help a lot with managing things, especially now that we expanded the beta to more people.
RVDM @ ES: I’d like to add to Peter’s comment about programmers’ strange times that I regularly leave messages for one of our programmers at say 9pm CST so that they will see it right away in the morning… just to get an answer back one minute later (which is 2am in The Netherlands).
CP @ RPGamer: Given the different hardware targets, is there much overlap between the
things that the two teams are doing? Are there areas where one has managed to
help out the other?
RVDM @ ES: As soon as we started working with PH3 we set up a joint codebase that we would both be working with so anything that is not platform specific that is added, or optimized or fixed is immediately beneficial to both teams. Overall, I think it is fair to say we benefited the most from the collaboration initially as Peter had the prior experience with the series and the engine, and specific tools that were very useful.
PT @ PH3: One thing we knew when we started to work on ToCS3 is that we needed better compression. With the approach we took on ToCS2, the third game would have required over 70 GB, which is a bit ridiculous. So we investigated a variety of compression algorithms and ended up implementing several of those, and a new package format. It actually turned out to be a good thing that we implemented several different algorithms, as we settled on lz4 for PC (after evaluating lzss, lzma, lz4 and zstd), while I believe Engine settled on zstd for the Switch version. We decided to go a bit larger in terms of disk size on PC for slightly better cached loading times.
In the other direction, Engine did the full localization integration, which saved us a lot of work. And of course, both teams fixed many bugs that are not target-platform-specific.
CP @ RPGamer: How did the teams ensure that the experience on both platforms would be
comparable? Do you feel that you’ve succeeded?
RVDM @ ES: We are working with a shared codebase for the actual game, so the only difference between the two versions are non-gameplay-related changes. In that regard I think wanting the experience to be comparable is not what you should strive for. A port should be the best version of that game on that platform. If that means that there are differences between the Switch and PC versions because a different solution or approach works better for one platform, we are making the right choices.
PT @ PH3: To us, the goal when creating a port for a given platform is to make the best version of the game possible on that platform, given the existing time and engineering constraints. This means that the PC version will obviously have a much larger variety of graphical options and supported framerates than the other versions.
Of course, the actual gameplay should be identical, which we ensure by using basically 100% shared gameplay code across both platform versions.
CP @ RPGamer: Was it more difficult to port to the Switch, given the hardware limitations, or to PC, given the variety of different hardware targets?[/B]
RVDM @ ES: It is different, but I don’t think you can just call one more difficult or easier than the other. On Switch (and any console really) you work with fixed hardware so once it works, it will work the exact same way for everyone. On the other hand, since you work with fixed hardware there is no wiggle room in terms of performance, memory usage and game size… Switch ports generally require more optimization compared to PC ports.
PT @ PH3: I talked about the issues with different hardware/software targets above. Overall, I’d say the challenges are different and not directly comparable. For example, when you get a report about a given graphical or performance bug on a console, it’s very likely that you can recreate that same behavior locally. On PC, you might have to perform some more “speculative” debugging. On the other hand, it’s much easier to push out builds on PC, and you are not as constrained in general.
CP @ RPGamer: Where do you start when you begin a port? Is there a general process to follow? Do you start (i.e. gameplay first, then audio, graphics, etc.)?
RVDM @ ES: You start by looking at your source material, even before you sign on for a project. The technical evaluation is an important step in the process…do we have all the source materials? Is it complete? Readable? Buildable? Does it use existing or custom engines?
The next step would be to get the game “as is” running on the target hardware… so without platform specific changes. Everything else follows from that point… what needs to be optimized, what controls need changing, what UI needs changing, what feels unnatural on this platform.
PT @ PH3: For us, we generally start our actual work with getting a minimalistic version of the game running on the target platform. “Minimalistic” here means no new features of course, but also entire easily separable modules (like video playback or even audio) might be missing. After that (or concurrently, depending on project team size), we start working on those modules.
CP @ RPGamer: What are the differences between fixing ports in your free time and doing it with the oversight of a publisher?
PT @ PH3: Well, for one, you get paid
More seriously, it’s much easier to make improvements to a game when you have access to its source code. However, when you are working on it in an official capacity, that also comes with some constraints you don’t have while modding. E.g. in a mod, it isn’t really a big deal to add a feature that crashes for 15% of the people – you just tell them not to use it. That’s obviously not an option for an official port.
CP @ RPGamer: You provided clear Legend of Heroes fan bona fides upon the port announcement with your copy of Dragon Slayer. How has being a fan of the series help with creating the port? Is there added internal pressure to get it right because of it?
RVDM @ ES: Ah, you saw that did you? It’s not even the Legend of Heroes specifically: we have been trying to work with Nihon Falcom since the early 1990s; back then communication with Japanese studios was a lot harder, and it didn’t help that they (Falcom) had no idea their games were popular at all in the West. In 1987, Ancient Ys Vanished Omen was the first RPG I ever played, so you could literally say that Falcom introduced me to the genre.
As far as pressure goes, we always feel pressure to deliver the best port we can regardless of what game it is, so professionally there is no change. Emotionally it can be taxing to work on a project you are a fan of: on one hand it is great motivation and it is only human nature to put just that little bit of extra effort into it when you are passionate about something. On the other hand, it can have a significant personal impact if something goes wrong for whatever reason.
CP @ RPGamer: Can you share some of your best “moments” when working on the port?
RVDM @ ES: Best moment in any port is to see the graphics coming alive on your target platform after working ‘blind’ for a few weeks. Ports often literally look like a long list of compiler errors at first, then a first green, pink, or even textured triangle. So, when all the pieces of the puzzle start to fit together and your team’s effort renders the title screen, and then the first scene or intro… the feeling is hard to describe, but it is always very special.
PT @ PH3: My favourite moment was probably when the localization was first merged. I’m a huge fan of these games, and that was the point when I could finally start actually playing it. I also always enjoy the moment when I get PCSS shadow filtering working on these games. It’s very expensive performance wise, it’s subtle, and no one should care this much about it, but I just love variable penumbra shadows. I’m weird like that.
CP @ RPGamer: What’s one thing you would add to the Switch version if you had just a bit more processing power?
RVDM @ ES: Honestly, we have not yet run into a situation where we were not able to achieve what we wanted on the Switch. Raw processing power is not a holy grail when it comes to these games, smart architecture and smart engineering solutions can get you a long way.
CP @ RPGamer: Are there any locations, characters, events, etc. that have particularly gratifying to see working?
RVDM @ ES: This might be almost too specific, but I got chills the first time I saw Saint-Arkh in handheld mode! It’s just such a beautiful place and even though it’s in lower resolution in handheld mode it looked stunning all over again.
PT @ PH3: I really enjoyed all the “introduction scenes” for the recurring party characters from ToCS1 and 2. It’s funny how they are more and more over-the-top and seeing how the new characters react to them.
CP @ RPGamer: What been your favourite parts to work on in the game?
RVDM @ ES: Some parts of a port are straightforward, like general game design and audio – you just go with what the original product provided. For porting to Switch the challenging work is usually the most fun to do – so optimization for performance and size – unless it doesn’t work!
PT @ PH3: I’ve always been into graphics and optimization, so my favourite parts are generally when I can implement new graphics features or optimize some component. Working on optimization is especially rewarding if you have a clear, measurable target, a fast feedback cycle, and a well-separated component that makes it unlikely for optimizations to break anything elsewhere. Recently I spent a few hours optimizing video color space conversion and greatly improved its throughput, that felt great.
CP @ RPGamer: Does the Switch having handheld and TV modes introduce any additional difficulties?
RVDM @ ES: The game was written for PlayStation 4 and since no PlayStation Vita version was made (unlike the previous two games) a lot of assets were very heavy for the Switch handheld mode (less for the TV mode as it features a boosted GPU). Previous games in the series were better optimized for handheld consoles, but for ToCS3 we could not rely on optimizations from the original developers and had to open Pandora’s box ourselves.
CP @ RPGamer: Are there particularly funny or noteworthy bugs that you’ve seen during the porting process?
RVDM @ ES: We usually get the funniest results when we tinker with the frame rate, and the game is not set up to work with variable frame rates. For example, we had one scene in the elevator where the entire party just kept jumping around like mad and it was too funny.
PT @ PH3: There are some amusing things that can go wrong graphically and/or with frame rate issues. For example, I recently had a situation during development where playing on an ultrawide screen messed up the aspect ratio for character head/bust shots in dialogue, which resulted in some very wiiiiideeee faces.
Seems brighter?
and dreamier with the extra bloom effects (dreamy Rean time lol) but maintaining the darkness needed in darker zones/areas.
Last edited: