Hi everyone, Trails into Reverie is releasing soon, so we want to provide some more information about the specific features of our PC port, and also a bit of a behind-the-scenes tour regarding its development -- for those who are interested in that kind of thing, and in hearing why Reverie's PC port was quite a bit more challenging than we initially expected. [h1]PC Feature Overview[/h1] Since Trails into Reverie is, at a game systems level, a clear descendant of the Trails of Cold Steel series, I think it makes sense to start with a list of [b]PC features returning from our ports of those games[/b]. I'll try to keep this one short since it's nothing new, and you can read up on our ports of these games elsewhere: [list] [*][b]Arbitrary resolution[/b] support, including all secondary render targets [*][b]Unlocked framerate[/b] support up to 360 FPS [*]Support for [b]MSAA[/b], and optional transparency supersampling [*][b]Ultrawide[/b] aspect ratio support [*]Additional and [b]improved shadow filtering and quality options[/b] [*][b]Extended draw distance[/b] options (including an option for unlimited draw distance) [*]A [b]FoV adjustment[/b] slider [*]Various smaller graphics settings, to e.g. toggle individual post-processing effects, increase their quality, or enable anisotropic filtering [/list] [img]{STEAM_CLAN_IMAGE}/40784472/a03ef373eb955fec025d3cd291bfabf531225f08.png[/img] In addition to these returning features, we have made the following [b]major improvements compared to the Trails of Cold Steel ports[/b]: [list] [*][b]Fully action-based input rebinding[/b]: for our port of Trails into Reverie, we completely replaced the input system, moving from a controller-focused underlying system to a semantic-action-based system. What this means in practice is that you can e.g. have different contextual mouse/keyboard bindings in many different contexts, which do not always have to follow the controller layout in a uniform fashion. It also means that you can bind additional direct actions not available on controllers due to lack of space (e.g. directly using S-breaks in battle). Of course, all menus [b]and[/b] help/tutorial screens will still show the correct button prompts for whatever binding you chose. [*]An [b]in-game settings menu[/b], with all [b]options applying immediately[/b]. This also includes some other new options that you might recognize from our recent Crossbell releases, for example the ability to customize the behavior of the game when it loses focus (e.g. when you alt-tab out). [*]Greatly improved [b]arbitrary aspect ratio[/b] support, now also supporting aspect ratios narrower than 16:9. The latter primarily targets 16:10 as found on some monitors and notably the Steam Deck, but even 4:3 should generally work, so knock yourself out with that CRT! (Take care not to do so literally, given the weight of those things.) More about the trials and tribulations of actually making this happen later. [*]Further improved graphics options, including higher quality and more appropriate HBAO+ integration than any of the previous titles, and a specific setting for minimap multisampling. The latter might sound a bit silly, but it is basically free in terms of performance, and a substantial enhancement given that the minimap renders a lot of thin high-contrast lines). [*]Some other features with more niche applications, such as Steam dynamic cloud sync, and a hack which enables Steam Deck and WINE players on Linux to directly import their saves from previous games without any manual work. [/list] I probably missed a few things, but this should cover most of it. If you were just looking for information about the port, then you can stop reading here -- we'll now dive into a bit of behind-the-scenes information on the port development. [img]{STEAM_CLAN_IMAGE}/40784472/b1643176b07ffb746d293c6cb6c9a28a62046650.jpg[/img] [h1]Behind the Scenes[/h1] As I mentioned earlier, Trails into Reverie is built on the same technical basis as the Cold Steel games (especially 3 and 4), and as such, we were pretty confident in being able to add even more features to the port, including some that are actually more labor-intensive than they might at first appear. That is especially true for features that might seem obvious, but which neither the game nor the engine were ever really built for -- and three of the headline features I mentioned above fall squarely into that category: action-based rebinding, immediate in-game settings, and above all arbitrary aspect ratio support. Arbitrary framerate support is somewhat similar, but to me, that is non-negotiable, so unlike the other three the complications arising from supporting high and variable framerates are not extra work that we freely choose to make for ourselves. The biggest problem we ran into, and that we didn't fully account for when starting the project, is [b]just how absolutely [i]massive[/i] Trails into Reverie is[/b]. Most people reading this are probably aware that all the Trails games are [i]pretty long[/i], but when it comes to the effort involved in porting and especially the features I mentioned previously, we have to distinguish between what I'll call "content size" and "system size". The former is basically length of the game based on content, but which uses the same underlying systems, i.e. basic map traversal, battles, and events. This type of size does increase QA overhead, and obviously relates directly to e.g. localization and asset adjustments, but doesn't really affect the core port engineering effort much. On the other hand, what I dubbed "system size" refers to the number of individual, distinct -- at an implementation level -- [b]systems[/b] which comprise the game. And here Trails into Reverie is without peer in my experience. There is a cohort of mini-games, with some being sufficiently substantial to require an entirely separate action set. And not just that, there are unique battle systems, render paths, and even story sequence display schemes which might only be used once in the entire 100 hour game. [img]{STEAM_CLAN_IMAGE}/40784472/54d6a19282f46a0a40189b826dff8f763020f6c3.png[/img] How does this affect the challenges I talked about previously? It increases them tremendously: regardless of whether a given system or graphical effect in the game is a core component or only used for 10 minutes and never seen again, it will still require roughly the same amount of work to e.g. make it display correctly across arbitrary aspect ratios. In essence, the system size of the game multiplies with the PC feature surface we want to provide -- which is [i]also[/i] more substantial than anything we ever did on the ToCS line of games (and, if I can be allowed to say so, more substantial than many PC ports with much higher budgets). To give you some final idea of how all of this comes together, here is some data directly from our bug tracker: [list] [*]We tracked [b]138[/b] tickets related to (ultrawide or narrow, mostly both) aspect ratio support. As of writing, a week before release, 125 of these are solved, and we'll probably get to a few more before the release. Of course we prioritized these according to severity, so what remains are mostly things like "one part of one effect of one spell is stretched/squished". [*]We tracked [b]36[/b] tickets related to button prompts. All 36 are fixed as of now. 11 of them were related to mini-games or other non-core functionality. [*]We tracked [b]27[/b] tickets related to arbitrary framerate support, which are often among the most time-intensive to fix. Of these, 22 are currently fixed, and most of the rest are miniscule to the extent that it's unlikely anyone who is not specifically looking out for them and comparing would notice (e.g. cards in the Vantage Masters minigame might be served slightly more quickly). [/list] I should note that all of these are tickets, which can potentially aggregate several issues each. Even more importantly, this only captures problems found after the start of QA, at which point we had of course already fixed all the most severe problems with the core game. Also, the counts in each category aren't really comparable in terms of how much effort fixing them is on average. Still, I hope this gives you an idea of how much effort needs to go into these seemingly innocuous features, if they have to be added after the fact to a massive game that was not built with them in mind. [h1]VR Support[/h1] [img]{STEAM_CLAN_IMAGE}/40784472/a7d4ebca84f85f6cabf8c9c1a349e3693bf67b8e.png[/img] There's still one more thing to talk about: VR support. On PS4, Trails into Reverie included support for PSVR, and while it is only available in the model viewer and a single minigame, we are still happy to provide a complete port including both of these VR modes. This did involve a significant engineering effort that went into making VR work and perform well on PC -- without that work, it would e.g. have consumed 3 times as much VRAM for the eye framebuffer in VR than what is actually strictly necessary, and with high VR resolutions this can be a lot. That said, there are a few key facts that anyone interested in trying these VR modes should be aware of: [list] [*]There is a specific setting for VR subtitles. The default should work well on most HMDs, but if the subtitles are hard for you to read then please check out this setting. [*]The game offers a re-centering action which you can use in case you find yourself aligned or positioned strangely. [*]VR uses the resolution reported from SteamVR (and it immediately updates, so you can adjust scaling in the SteamVR overlay), but mostly relies on the normal game's graphics settings for the other features. If you experience performance issues in VR, you might have to adjust these settings, such as anti-aliasing level or shadow quality. [*]SteamVR is not really built for games which only have small, transient VR segments. Even though we did everything we can to streamline the process, this still means that there are potentially two manual steps involved: [list] [*]If the game starts SteamVR (since it is not already running) upon selecting a VR mode, Windows will switch the focus to the SteamVR window. You might need to manually return the focus to the game in order for it to receive inputs. [*]When you exit VR in-game, SteamVR does not automatically shut down but keeps running. You have to close it manually to e.g. return your audio device assignment to normal in case it was changed by SteamVR.[/list][/list] [h1]Conclusion[/h1] Trails into Reverie was a challenging project not so much because of its target platform or underlying technology, but because of the large cross product between its huge number of systems and the volume of features we set out to support on PC. I'm proud of the resulting product, and as always I want to note that it wouldn't have been possible without our excellent QA testers, all the people at PH3, and our partners. In that context I want to give a special shoutout to Peter Zangerl whose inexorable crusade against hundreds of small niggles is a large part of the polish of this release. I hope you enjoy the game, and found this small look behind the scenes of the port interesting! - Peter "Durante" Thoman, CTO, PH3