In 3 years, 50% of all computers capable of playing AAA games will be Macs

[leman]

I'd also be careful with Vulkan. You depend on MoltenVK. I've also heard stories about Apple rejecting apps using Molten. I don't know for what reason or it's not true at all. But it is clear that Apple wants to push Metal and I can see them rejecting anything that isn't native Metal in the future.

Apple works with game studios that use MoltenVK, helping them optimizing their titles (there was an entire WWDC session about it), so they don’t have any problem with MoltenVK itself. After all, it’s just a static library linked into your app.

The story with rejected apps has to do with a certain version of MoltenVK using a private API which caused the app to fail the review. That has long been fixed. Nothing to do with MoltenVK as such, just a potentially buggy implementation.

Depends on the optimizations I guess. Based on hardware alone, it's more in the ~30fps range at 1080p, with low settings. Medium settings should drop to ~20fps. Apple needs more than this for AAA games and I'm sure they'll get it in time.

I’d expect much better performance with TBDR-optimized rendering engine and partially resident textures (AFAIK Apple has the only virtual texture implementation on the market that actually works, as others have performance issues).

Look at Baldurs Gates 3: M1 is capable of getting around 50 fps (with some dips to 40 here and there) in most areas at highest settings. That is much better than one would expect from the hardware. My 5500M in Windows doesn’t even get close.

 

[theorist9]

Sounds about right. I would remove OpenGL from the list to be honest because it makes absolutely no sense to use it for a new project.



Well, there is a bunch of options. I'll try to summarize the basic ones:

Approach	Advantages	Disadvantages
Vulkan for all platforms	Only one API to deal with	Need to optimize for various hardware + MoltenVK, most likely will end up having platform-dependent paths or partial rewrites to make sure it runs well everywhere
DX12/Vulkan on Windows, Metal on Mac	Can take full advantage of each platform	Need to be proficient with both APIs, dealing with shader cross-compilation
Use a middleware engine (Unity, Unreal etc.)	Low level stuff and platform abstractions are taken care of for you	Might need to work around engine limitations, performance potentially lower than doing it yourself

For new projects where you want to achieve highest quality, I'd go DX12 on Windows and Metal on Mac. The funny thing is that with some advance planning, using two different API backends is not that much more difficult than using one API but making sure it works well on all hardware. Also, using two APIs allows you to chose the optimal rendering path on every platform.



You don't have to deal with TBDR if you don't want to. There is one caveat though — TBDR can benefit a lot from having some information about how your framebuffer resources are used (e.g. do you need the color/depth buffer after the rendering is done etc.). Having this knowledge can help the driver to optimize memory allocation and transfers. Now, all modern APIs (including Vulkan and DX12) have ways of specifying this information, and it's in general a trivial thing to do, but since devs have little experience with these things, mistakes in describing render passes are common. Testing and profiling is important. Fortunately, it's a low hanging fruit and can be basically fixed up in a single afternoon if your codebase is sane.

If you are using Metal and want to achieve maximal performance on Apple Silicon, you have access to advanced tools that let you take low-level control over on-chip caches and per-tile processing, potentially allowing you to get much better performance.



For some projects, it is. If you are developing a graphically demanding game for example, there will be a minimal hardware configuration target.

Thanks, great answer (sensible and on-point, as is usual for you)!

So let's suppose the developer decides to go Metal for Mac and DirectX for Windows. Roughly much does that increase their costs vs. making a Windows-only game (as a percentage of the total cost of deploying a game, including storyboarding, advertising, etc.). I ask because the answers I'm seeing thus far are all over the map.

And if the developer decides to also deploy the game for consoles (PS3/XBox), would that change things, or is development for those entirely separate?

 

[theorist9]

You already got a good reply from @leman, but I think you're looking at it from the wrong perspective. There's more to game development than choosing a graphics API. Think about the game you want to do first, check what tools/engines are available to you, if they meet your requirements and then decide.

I'd also be careful with Vulkan. You depend on MoltenVK. I've also heard stories about Apple rejecting apps using Molten. I don't know for what reason or it's not true at all. But it is clear that Apple wants to push Metal and I can see them rejecting anything that isn't native Metal in the future.

I don't disagree, since you're just stating the obvious/sensible ["Think about the game you want to do first, check what tools/engines are available to you, if they meet your requirements and then decide."] But I'm afraid I don't see how that makes any sense as an answer to my question. Perhaps you didn't understand it.

It's as if I asked "What are the best places in Seattle to buy Japanese Gyokuro?", and you replied "I think you're looking at it from the wrong perspective. You want to make sure the tea you buy is fresh."

Good info. on Vulkan, though.

 

[leman]

So let's suppose the developer decides to go Metal for Mac and DirectX for Windows. Roughly much does that increase their costs vs. making a Windows-only game (as a percentage of the total cost of deploying a game, including storyboarding, advertising, etc.). I ask because the answers I'm seeing thus far are all over the map.

I really would not know, since I was never involved in a large commercial project of this kind. Actually, I have never been involved in ay commercial software product, all stuff I write is either on my university payroll or private hobby projects.

If you have the talent (good software designers, experienced GPU programmers who know the platform), the extra cost basically boils down to personal costs (macOS/Metal devs) and Mac testing. Depending on the company structure, this cost can be very small or it can be very high.

I have a strong suspicion that the biggest real problem is going to be communication and access to talent. The team responsible for the Mac version is likely a smaller group (possibly contractors or a separate company) that is brought into the process late, once the basic game engine structure has already been decided on, and who don't have much decision-making ability. Basically, you get a car designed for the desert and you are tasked with making it feasible for Alaska. That's why ports suck.

If one designs with multi-platform deployment in mind, one can make decisions which will greatly simplify the process going forward. But this requires having access to talent — highly skilled software architects that know the platforms. And those folks are fairly rare.

And if the developer decides to also deploy the game for consoles (PS3/XBox), would that change things, or is development for those entirely separate?

I think it is similar to the problems I have outlined above. AFAIK Xbox uses DX12, which should make porting simpler. Still, consoler make very different performance guarantees, so even using the same API does not mean that you can get best results out of different hardware using the same code.

I remember how it was to work with OpenGL back in the old good days. One would always praise the fact that OpenGL was multi-platform, but one forgot to mention that if you wanted to have good performance you essentially ended up coding different render patches for different hardware, using various proprietary extensions. It was extremely complex, time-consuming and error-prone mess. Modern APIs are luckily much simpler, so you can get a lot of done without touching vendor-specific stuff. Vulkan extensions are still intimidating though.

 

[GrumpyCoder]

I don't disagree, since you're just stating the obvious/sensible ["Think about the game you want to do first, check what tools/engines are available to you, if they meet your requirements and then decide."] But I'm afraid I don't see how that makes any sense as an answer to my question. Perhaps you didn't understand it.

Simple, if Unreal engine works for you, you don't have to write shaders at all, you can just use the node editor. If you need limited custom material then you can use a custom expression node. If you need simple custom shaders and Unity works for you, then your choice is Direct3D 11 style HLSL for Windows and macOS, as long as you don't use a subset of features that is platform dependent, as this can be cross compiled to OpenGL (ES), Metal or Vulkan. So it's not so simple as DX for Windows and Metal for macOS, it always depends on the situation. If you want to create absolute cutting edge stuff and push graphics in games to the limit or next level, money no object, then sure... DX for Windows and Metal for macOS.

I blame the 32X for Sega's demise. The Saturn was actually fine as was Dreamcast but by then EA (read all the sports games) decided they didn't want to support Sega's console (the Dreamcast) cause Sega was too wishy washy on hardware. Well that and the PS2 was more powerful and could play DVD's (once you bought the remote, lol).

I forgot about the 32X. That was a big mess and the only game that was worth it (to me) was Virtua Racing. The Mega-CD wasn't such a hit either. The Saturn was nice, but the Playstation just dominated back then. Saturn and Dreamcast were niche consoles back then for me, even more than the Neo Geo and PC Engine / Grafx. More on a level with Jaguar and 3DO for me.

Look at Baldurs Gates 3: M1 is capable of getting around 50 fps (with some dips to 40 here and there) in most areas at highest settings. That is much better than one would expect from the hardware. My 5500M in Windows doesn’t even get close.

Not sure about BG3. It's nowhere near as polished as Cyberpunk, particularly lighting. But I've not seen everything of BG3 and Cyberpunk, so take it with a grain of salt.

 

[GrumpyCoder]

So let's suppose the developer decides to go Metal for Mac and DirectX for Windows. Roughly much does that increase their costs vs. making a Windows-only game (as a percentage of the total cost of deploying a game, including storyboarding, advertising, etc.). I ask because the answers I'm seeing thus far are all over the map.

You won't find an answer to this, anywhere. It highly depends on how complex the game is and what technological features you're utilizing. For a game close to the $100M mark or above with custom everything (think Diablo, Starcraft, etc.) it's common to end up in the 50% to 70% range in addition to the Windows only costs. But this can drop below or be more.

It also depends to what level of quality/optimization you will go. Have a look at Path of Exile and the very poor macOS port. That surely wasn't close anywhere to 50%. On the other hand, look at how much time and effort Valve put into optimizing the Source engine for other platforms. Your best bet is to go by experience on this, how much did it cost you the last time and how does your game differ this time. I know that's not the answer you want to hear, but that's how it's done.

 

[leman]

Not sure about BG3. It's nowhere near as polished as Cyberpunk, particularly lighting. But I've not seen everything of BG3 and Cyberpunk, so take it with a grain of salt.

To clarify — BG3 is far less demanding than Cyberpunk of course. But I think that Cyberpunk's renderer could fly on Apple hardware with some Apple-specific optimizations. Especially given the amount of light sources in the game, tiled shading with transient g-buffer attachment could probably save a tremendous amount of bandwidth and achieve better ALU utilization compared to the classical state of the art GPUs.

P.S. I think what I am trying to say is that it can be difficult to estimate performance of Apple GPU simply because we lack experience with this kind of architecture. Some traditionally expensive techniques (like deferred rendering with complex materials and plenty of dynamic lights) might end up being surprisingly cheap using programmable tile shading, while some things that we are used to being fast might end up slower because of the lack of bandwidth/geometry spilling.

 

[quarkysg]

Actually a case could be made that more games were ported during the days of MacOS 9 and PPC than lately.

The base PPC Macs is good enough to run games, just like the M1 being the base Apple Silicon Macs. Targeting PPC Macs means all PPC Macs customers are potential games customer.

Same thing cannot be said of Intel Macs.

I think that’s the point of OP.

 

[Mr. Bear]

I was working at a Certain Big Game Developer 25 years ago, and we ported most of our stuff to the Mac. The cost was usually about 1/10th of the cost for the PC version. But for the most part we had our own game engines which were cross-platform. Obviously things have changed since then. I do remember Apple coming to visit us once, and it was me, our lone Mac developer and a pro-Apple exec who met with the guy. This was back when Game Gears was a thing.

 

[leman]

I was working at a Certain Big Game Developer 25 years ago, and we ported most of our stuff to the Mac. The cost was usually about 1/10th of the cost for the PC version. But for the most part we had our own game engines which were cross-platform. Obviously things have changed since then. I do remember Apple coming to visit us once, and it was me, our lone Mac developer and a pro-Apple exec who met with the guy. This was back when Game Gears was a thing.

This stuff has to come back. Apple's developer support is really atrocious. They are taking some half-assed measures, like those weird forums where one sometimes gets an answer from an Apple engineer, but it's fairly obvious that the communication channels are not working. There should focus on building specialized developer relation teams.

 

[theorist9]

This stuff has to come back. Apple's developer support is really atrocious. They are taking some half-assed measures, like those weird forums where one sometimes gets an answer from an Apple engineer, but it's fairly obvious that the communication channels are not working. There should focus on building specialized developer relation teams.

Why do you think it hasn't?

Sometimes Apple is clueless in a way that's obvious to everyone except Apple (e.g., providing the pro community with the Trashcan Mac Pro, and then taking years to fix their mistake; or losing sight of functionality in their pursit of thinness, resuting in the butterfly KB) but, generally speaking, they are very sophisticated in their decision-making, as evidenced by how enormously successful they've been.

So I'm wondering what's the case here. Is Apple again missing the obvious, or did are they not allocating resources for more developer support because they've done the cost-benefit analysis and decided it's not worth it?

 

[theorist9]

You won't find an answer to this, anywhere. It highly depends on how complex the game is and what technological features you're utilizing. For a game close to the $100M mark or above with custom everything (think Diablo, Starcraft, etc.) it's common to end up in the 50% to 70% range in addition to the Windows only costs. But this can drop below or be more.

It also depends to what level of quality/optimization you will go. Have a look at Path of Exile and the very poor macOS port. That surely wasn't close anywhere to 50%. On the other hand, look at how much time and effort Valve put into optimizing the Source engine for other platforms. Your best bet is to go by experience on this, how much did it cost you the last time and how does your game differ this time. I know that's not the answer you want to hear, but that's how it's done.

But even if you are doing high customization for both Mac and Windows, doesn't the added cost still depend heavily on whether you're including a Mac port from the beginning vs. adding one after the fact? I would think this would be a key qualifier, but you've not mentioned it here.

And it's not about getting the answer I want to hear, it's about getting the clearest picture. In my field everyone gets this is the motivation for closely questioning something—outside my field most folks misintepret it as being argumentative or fishing for the answer they want to hear.

 

[leman]

Why do you think it hasn't?

Sometimes Apple is clueless in a way that's obvious to everyone except Apple (e.g., providing the pro community with the Trashcan Mac Pro, and then taking years to fix their mistake; or losing sight of functionality in their pursit of thinness, resuting in the butterfly KB) but, generally speaking, they are very sophisticated in their decision-making, as evidenced by how enormously successful they've been.

So I'm wondering what's the case here. Is Apple again missing the obvious, or did are they not allocating resources for more developer support because they've done the cost-benefit analysis and decided it's not worth it?

It can be surprisingly difficult to change things in a large corporation. Behavior and communication patterns emerge, become conventionalized and resist new ideas. This is such a huge problem that it has it's own field of study (change management).

Imagine the following: you are a huge software corporation, with hundreds of talented, very smart engineers. Then one day you realize that you could offer more support to the dev community so you tell your engineers "ok, we have put up a new support forums, it's now your job to occasionally read the posts there and help people out". How do you think the engineers will feel about it? Put yourself in their shoes. Firs, you probably have more fun things to do. Second, you go on the forum, and there is this ranting user who can't provide a proper minimal bug report. You try to help by escalating it to the team, but thy brush it off saying that they are already working on a long list of bugs and the report is unclear. Some things you can't even talk about because you might get in trouble with your manager for divulging too much technical detail. In the end, you don't feel responsible for any of this, get frustrated, and just limit your partitipation to some very obvious questions to tick things off and tell the managers "look, I did my thing". That something like this is happening is already clear from Apple's documentation. Their Metal shading language reference for example is a long PDF, obviously typeset in Word, without any hyperlinks and partially incomplete. Trying to look stuff up there is very painful and annoying.

What they need are managers who are passionate about both engineering and communication (and those people are already super hard to find), who would own the commutation process and have dedicated teams that work across various projects and areas. The bug reporting system has to be completely revamped, the documentation process has to be revamped — these are all major revisions that would require insane amount of effort. I wouldn't even know where to start.

 

[theorist9]

What they need are managers who are passionate about both engineering and communication (and those people are already super hard to find)...

Then maybe they need to hire scientists with experience in both coding and teaching. There are lots of those around, and they readily combine technical expertise with a passion for communication.

They'd need some training in the specifics of the software, but they certainly have the background to pick it up. It's certainly a lot easier to teach the scientists coding specifics than to get an engineer with no communications skills to be a good teacher.

 

[leman]

Then maybe they need to hire scientists with experience in both coding and teaching. There are lots of those around, and they readily combine technical expertise with a passion for communication.

They'd need some training in the specifics of the software, but they certainly have the background to pick it up. It's certainly a lot easier to teach the scientists coding specifics than to get an engineer with no communications skills to be a good teacher.

That‘s an interesting option that could be explored. Although, having worked with scientists for over a decade now I have to say that most of them make terrible software engineers

 

[theorist9]

That‘s an interesting option that could be explored. Although, having worked with scientists for over a decade now I have to say that most of them make terrible software engineers

Interesting. Could you expand on that? What type of scientists are they, and in what way are they terrible?

Coding is central for the work of many scientists, particuarly those that do large-scale computational modeling. And many other scientists leave science to become data scientists, which of course also requires a lot of coding. But perhaps you had something more specific in mind when you said "software engineers".

 

[4743913]

no Planet Zoo no care.

 

[MysticCow]

This thread is still going?

 

[leman]

Interesting. Could you expand on that? What type of scientists are they, and in what way are they terrible?

Coding is central for the work of many scientists, particuarly those that do large-scale computational modeling. And many other scientists leave science to become data scientists, which of course also requires a lot of coding. But perhaps you had something more specific in mind when you said "software engineers".

It’s just that most scientists I have met are more interested in achieving results than writing good code. The majority also have very little formal education or understanding of programming fundamentals. Data scientists and statisticians are often among the worst offenders The code they write works, but is often an unmaintainable mess that does not follow good programming practices.

Not that most university-educated programmers are better though… they tend to get lost in their framework of choice (usually some sort of vanilla OOP) and have little capability to make abstractions.

 

[diamond.g]

This thread is still going?

In a few months we will only have 2 more years to go to see if the OP prediction comes true. Coincidentally two (to three) years is also the average time it takes for an AAA game to be made.

 

[JMacHack]

or losing sight of functionality in their pursit of thinness, resuting in the butterfly KB)

my personal theory about the butterfly keyboard is that they “tested” the preproduction models by having a machine press the mechanism a million times in a nice, clean room.

And they didn’t account for dirt and grime and such.

 

[leman]

And they didn’t account for dirt and grime and such.

They tested the wrong kind of dirt

 

[JMacHack]

They tested the wrong kind of dirt

Jony Ive insisted they sifted their dirt through ever finer filters to make it 20% thinner.

 

[theorist9]

my personal theory about the butterfly keyboard is that they “tested” the preproduction models by having a machine press the mechanism a million times in a nice, clean room.

And they didn’t account for dirt and grime and such.

Well, they didn't account for a lot of things. They didn't account for dirt, they didn't account for noise (their butterfly KB measures ~10 dB louder than their scissor KB's, which means it's perceived as twice as loud; see link below), they didn't account for the role that key travel plays human proprioception, and they didn't account for physical comfort.

Is Apple’s 16-inch MacBook Pro keyboard quieter? - 9to5Mac

The new 16-inch MacBook Pro marks a return to form for Apple’s keyboard design. It features a scissor switch mechanism...

9to5mac.com

 

[senttoschool]

In a few months we will only have 2 more years to go to see if the OP prediction comes true. Coincidentally two (to three) years is also the average time it takes for an AAA game to be made.

I'm not making any predictions that all or most AAA games will get a Mac version in 2-3 years. All I'm saying is that in 3 years, 50% of all gaming computers sold yearly will be Macs. Feel free to fact check my math.

I'm, however, implying that AAA games will follow after that. If developers are smart and are looking at the numbers, they will be planning Mac versions of their future games being released in 2-3 years.