The Truth Behind Why Modern PC Ports (Usually) Suck

An Insider’s Look at the Challenges of PC Game Development And Why Your Favourite Games “Suck” on PC

Hello World, in this post we’ll be diving into a topic that has been a source of frustration for many of you — poorly executed PC ports.

I’ve been at the front lines of these challenges, and today, we’ll try to dissect why some PC ports just don’t usually stick the landing.

For the uninitiated, porting a game essentially means taking a game that was designed for one platform (like PlayStation or Xbox) and adapting it to run on another, like PC. Simple enough, right? Well, not exactly. Not exactly at all.

Standardization (Why every PC being unique is a pain in the ass)

One of the biggest hurdles we face is a lack of standardization in PC gaming. Consoles are fixed platforms. When we’re designing a game for, say, PlayStation, we know exactly what hardware we’re dealing with. Every PS5 out there has the same components and operates in near enough the same way. This makes the job somewhat predictable.

PCs, however, are a different beast entirely. The sheer variety in hardware — CPUs, GPUs, RAM, you name it — makes standardizing a game for PC an uphill task.

Each PC configuration interacts with the game in a different way, and catering to all these possible configurations is not always possible.

It may sound silly to some but everything from having certain applications open to having a bit too much dust on a fan can seriously affect the performance/outcome of a PC port.

There’s also the issue with certain APIs like DirectX 12.

DirectX 12 has a feature called Pipeline State Objects (PSOs), which can cause “shader hitching.” For those lucky enough not to have seen shader hitching, imagine you’re watching a movie and every few minutes it freezes for a second. That’s hitching in gaming — a momentary pause or stutter that can disrupt gameplay.

In terms of graphics, a “shader” is essentially a program that tells a game how to draw something in detail. PSOs, intended to make rendering more efficient, can sometimes cause these shaders to hitch.

This hitching problem can be especially noticeable in fast-paced action games where even a momentary stutter can completely throw off your experience. It’s like you’re in the middle of a high-octane race and suddenly your car freezes for a moment. Frustrating, isn’t it?

There’s a great post on Reddit that goes into detail about this issue: https://www.reddit.com/r/Amd/comments/zitv7x/people_dont_understand_shader_cache_stuttering/

The long story short is because you can show up to the party wearing whatever you like, the shaders in our games need to support many different combinations of “clothing” to the hypothetical party.

DirectX 12 likes to do this there and then in the moment, stopping the action to make sure all the shaders are compiled for you prior to continuing.

In theory, sounds great. In actuality, we have limited control on when this can happen — meaning it’ll usually happen at the worst possible times.

We’ve tried many things to get around this too, it’s not like we just threw our hands up and gave up. For example, in Ghostwire Tokyo, did you know that certain “problem” meshes are loaded in the main menu?

Obviously, the whole game can’t be loaded there but the worst offenders are loaded in at the main menu to try and mitigate the shitstorm DX12 likes to give with the PSO caching.

But What About the Steam Deck?

In terms of standardization, the Steam Deck was a great step in the direction. Finally, a single platform we can target like a console and cover all basis on!

However, due to its overwhelming popularity, a number of clones almost immediately hit the market. Just as quick as the glimmer of hope arrived, we were thrown straight back to square one with too many platforms with no form of standardization between them outside of some funky APIs that’ll morph, shift and change based on the platform.

Stupid Permutations (aka “Who is going to pay to support ultrawide?”)

This industry runs on money. It’s a bitter pill to swallow, but that’s the reality. Each line of code, each pixel rendered, each hour of development time costs money in a AAA game.

Publishers usually agree to a budget upfront, typically dispensed upon achieving certain milestones. It’s a system that encourages progress and adherence to timelines, but it can also place stringent limitations on what we can and can’t do within the scope of a project.

So, picture this: we’ve received a budget of X amount to make a game, and development is well underway. Then, a new piece of technology suddenly gains traction in the gaming community. Ultra-wide screens, for instance, providing an immersive, panoramic gaming experience.

In an ideal world, we’d leap at the chance to incorporate this new tech. After all, who wouldn’t want to offer gamers an even more breathtaking view of the worlds we’ve painstakingly created?

But we’re not working with an endless budget here. The money’s already been allocated to a laundry list of priorities, from core game mechanics to graphics, sound design, debugging, and so on.

In order to support this new technology, we would need to adjust aspects of the game — the user interface, the graphics, perhaps even the gameplay itself — to ensure compatibility. That translates into additional development hours, which means more money.

But who foots this bill? The initial budget wasn’t designed with ultra-wide support in mind. Publishers, who’ve already agreed upon and portioned out the funds, aren’t always willing to cough up extra.

It becomes a cost-benefit analysis at this point — is the percentage of players using this new tech significant enough to justify the additional expenditure?

This is not to say that game developers are averse to innovation or don’t want to offer the best possible experiences. It’s simply an example of the real-world challenges we face when new technologies emerge midway through a game’s development.

In a perfect world, every game would support every technology and cater to all gamer preferences.

You might be thinking to yourself “Well doesn’t this mean that publishers would rather take a knock to a review score rather than make sure the purchaser is happy?” In a sense, you’d be right.

The fact of the matter is, this is a numbers game. Publishers need to weigh the potential benefit of supporting a new technology against the cost it would entail.

If only a small fraction of the gaming population uses that technology, the return on investment might not justify the additional cost. So they’ll take the negative reviews and take it out on the dev team, even if we fought tooth and nail to get that weird feature you really like into the game.

And yes, while the absence of support for that technology might lead to a lower review score or a few unhappy customers, the unfortunate reality is that pleasing every individual customer is just not feasible in a market as broad and diverse as the PC gaming market.

It’s a catch-22. People will complain about a bad PC port — we know it’s because the publisher didn’t let us do X (but we can’t say that), the publisher hears “game is bad” and decides “Nope, not doing that again.”

What is feasible, though, is for us devs to continue to strive to deliver the best gaming experience to as many players as possible within the given budget and timeline.

This might not be an easy truth to digest, but it’s an essential part of understanding the game development process. It’s not always about cutting corners or neglecting the customer’s needs.

So Console Gaming Is Better?

Console Gaming comes with its own challenges. Whilst we get standardization which makes things a lot easier in that regard — the console owners know that they make the rules and rule the roost.

Each of the major consoles have a “certification” process that you must follow (unless you’re one of the big, big studios that can pay for blind eyes to be turned). “Cert” is a word that strikes fear into any developer and we’ll talk about it some day in the future.

The important takeaway with Cert is BRUTAL and one of the benefits of PC game development is not having to deal with the draconian rules and systems of the major platform holders.

Steam, as an example, does have specific rules that need to be followed but they don’t go nearly as hard as Sony / Microsoft — who’ll force you to change content inside of your game.

An example I’ll never forget is “the main menu took 0.032 seconds too long to load, therefore you’ve failed this cert round. Fix it and pay up to do the review process again”.

Cert can be brutal. You’d think it’s for the betterment of players but when the biggest offenders of the cert rules have deep pockets and get around the rules, it does nothing but make everyone look bad.

So is PC Gaming Bad?

Now, I’m not saying that all PC ports are bad. I mean when they work, they can offer versatility and options that you can’t get on a console. But it’s important to understand that making a PC port is not as easy as flipping a switch. There’s a lot of work that goes on behind the scenes, a lot of decisions to be made, and a lot of obstacles to overcome. And a lot of cash required.

Ultimately, the goal of every game developer is to deliver a smooth, engaging, and immersive gaming experience, regardless of platform. As with most things in the industry, it usually comes down to money or politics (or a mixture of both).

If you want the closest to the “developer’s vision” of a game then yes, the console version is the way to go. There are just too many variables (literally and figuratively) on PC which means that unless the publisher actively wants to win you over or unless you’ve got a popular setup — you’re going to run into issues that we just don’t have the budget or go-ahead to fix (no matter how trivial the fix would be!)

Closing Thoughts

So next time you encounter a hiccup or two in your PC port, know that there’s a team of developers out there who are just as frustrated as you are, and are working tirelessly to fix it.

Until next time,

Anon