Our series of podcasts continues. This time with Timothee Besset, now working for Valve after a long experience of porting games to Linux when working with and at id software from the late 1990s till late 2000s. As usual we are offering you with both audio versions in MP3 and OGG (Opus codec this time around), and a full transcript of our discussion. We hope you appreciate this work! If you do, have you considered supporting us on Patreon?

[podcast_episode episode=“3836” content=“title,player”]

Download: [MP3 File] | [OGG File] | Podcast RSS Feed

It was early morning in Tokyo. I was drinking hot coffee, looking at the horizon turning brighter and brighter, spreading shadows over the numerous towers of Shinjuku. In a moment, I was going to speak with Timothee Besset about his career and his work supporting Linux through id software and more recently at Valve.

While Tim has certainly seen its share of the spotlight for his work at id, his name does not pop up as often as Ryan Gordon for example in the Linux world. This may be about to change as he is now working with Valve, spreading the good word about SteamOS and the importance of a Linux-based platform for gaming. But before going there, we need to go back to what brought him to Linux in the first place. This is where our story begins.

Timothee Besset (referred to as Tim afterwards): First, I started with UNIX systems really before Linux was really very popular back in school. We had access to a mainframe system, I think it was HP UX. I had access to it but we were we were pretty limited. We didn’t have root access, the machines were kind of shared resources, with a bunch of other students. The PhD students would always kick us out of the machines, because they needed the compute cycles. Someone mentioned that we could probably abuse the abusable machines in a computer lab, and set up something called Linux that was very similar to UNIX on them, to more interesting things out of them. It was early 90s. I had a buddy, and we figured a way to repartition the hard disks of the lab PCs with a hidden Linux partition, and you had a special key that you could press during boot to run Linux. It was old technology for networked Windows machines, and it would reinstall the machine every night, except the changes we made, saved in 100 Meg or 200 Megs in a hidden position. And that ended up surviving the nightly reboots.

So we ended up adding our personal Linux systems, hidden away on the cool computers and kind of that’s how I kind of got interested and start hacking away doing fun things. It wasn’t especially gaming it was just computer science stuff and it was a very interesting time. A new OS, new system it was really in the middle of .Windows was everywhere and it was Windows 95, I mean it was absolutely terrible in terms of reliability and speed so I think for a young engineering students it was pretty interesting to be able to do things with Linux. That’s kind of how it all started.

Tim’s first job had nothing to do with video games, but he was not living too far away from the offices of a still small developer, id software. Of course, id software was far from unknown at the time - they had already developed Castle Wolfenstein and the hugely successful Doom series. He started paying them visits.

Tim: Then I finished my studies, got my Master, and went to went to work for Oil Field company in Houston for a year and a half. Back then I was already interested in what id was doing and they were in the middle of finishing Quake 2 and starting Quake 3 actually. Houston-Dallas is a four hour drive so I got a chance to drive up and visit them a few times. Back then the company was pretty small. John was already seeing a lot of the source code for Quake 1. Rob Duffy at the time had taken maintenance of some of the tools, some of the open source level editor. And he had released his own modifications to a source which I grabbed.

Tim would later modify this project to turn it into GTK Radian, his first foray into coding related to commercial games. That was all possible because everyone was very approachable then.

Tim: Back then it was not even GTK Radian. It was really MFC based, which is what id had released but it was sort of a straight port to windows of the level editor that was already running on NeXT workstation. And Robert Duffy had taken that, he had made some changes to the OpenGL code and it could run on consumer cards. Then I took that as a side project and started making my own modifications to it, doing some bug fixing and implementing a bunch of features. Then I was interested in geometry generation so I had written a plugin to automate making corridors and stairs and things like that. They were looking at folks to maintain the open source stuff they released and so on. That’s how I was in touch with them. Back then it was a small team, it was just a few programmers, it was free flowing, you could just email them and get an answer.

While he was getting closer to id software, he had the opportunity to escape his current job to join the more exciting world of video games, with Loki software. Ryan Gordon was there as well, and came back in length on our previous podcast with him on how things worked in this unique porting company. Tim had no hesitation at that time to make this move:

Tim: It was pretty easy. The company I had worked for here in Houston, they wanted to keep me on board, mostly in IT and kind of customer-facing development. It was very big corporate environment. It was just not very appealing. When you’re what 19, 20 years old, you have an option of going working for a big corporate company or you can just go work in video games, that’s kind of a no-brainer.

Even though Tim was involved with id games known for their remarkable technical design, he was not involved, until recently, in rendering. This is because of how id designed their games in the first place.

Tim: I don’t consider myself a graphics programmer. Throughout my career, I mostly focused on network, net code, on low-level platform abstraction, and game code essentially, and dealing with performance, with memory, with stability, that sort of thing. Through my years at id, I knew enough about rendering to be able to understand the basics, to understand performance implications, to understand a high level of the API. But I was I was never a renderer programmer. And only now, I’m really getting more involved into rendering over these past few years. Carmack would write an OpenGL renderer that was kind of cross-platform from the start, and very different from what Epic has been doing for instance, where Epic designed an engine where you had different backends, so you would still have DirectX being the main focus and OpenGL kind of always being a second-class citizen unfortunately. So if you wanted to make ports with an Unreal based game, you had to have a pretty in-depth knowledge of the renderer architecture, the OpenGL API, and all those issues of portability and compatibility between DirectX and GL. I mostly escaped all that because John wrote very clean, very solid OpenGL code and that was the only render path for the entire game. So as long as it compiled fine and you had the right bright structure sizes and cellulizationed disk and all that stuff, you were good to go. The renderer would come up and work just fine.

At some point, Loki’s activities were not sustainable anymore… too few sales on Linux led the company in a downward spiral. Yet even after Loki went under, Tim’s support proved essential for id software, for multiple reasons.

Tim: I started doing contract with id after Loki software went under. So Loki software had essentially convinced id and convinced John to do a commercial release of Quake 3 for Linux.[…] Loki had done the core of the porting work. They were distributing Quake 3 Linux, it was even a fairly collector’s edition, in a little tin metal box […] but then the company eventually went under. Id found themselves with Quake 3 out there, and Quake 3 costumers on Linux and no company to kind of maintain the game which still had a pretty hefty audience etc. So they rung me up “hey we will contract you out to take over the maintenance for that?”.

This was the beginning of a long and productive partnership with the guys at id software.

Tim: So I started by freelancing. I freelanced for several years for them, I freelanced until 2004, and then eventually I was involved in more and more projects, I started getting involved with id licensees and every time a licensee would license the game… the deal back then was really you get a code dump of whatever the latest of engine is, you get a few hours talking to John and asking him questions and that’s it. Id didn’t have any licensee support or anything like that it was really “this is it”, you just get a dump of the source code, you ask a few questions and then you’re on your own. And for some projects that were a little more important to id, to the company, I started being kind of the contact point on a lot of things to address some of the issues or propagate some other concerns So I ended up being involved in projects that were not done internally at id, but were on id’s intellectual property. So that’s how I got involved with Return to Castle Wolfenstein that was being done by Splash Damage, and then Quake 4, Enemy Territory, Quake Wars etc. so all those I was kind of id’s contact point for a lot of his work. I was essentially working using Linux as my development environment and that was that was the easiest way to keep an eye on stability, performance, quality. [To do that it was just easier] to keep the engine running on Linux during development. I think that’s something we have to hope for as an evolution in the near future for games on Linux: seeing more and more developers using Linux as a target I think that’s the key for broader Linux market.

Despite what it may sound like, Tim was pretty much the only person developing on and for Linux within id and even outside with the licensees. Their main OS, you might ask?

Tim: Oh they were Windows guys. I was really the only one running on Linux. One thing is I was usually in charge of the dedicated servers so I can at least had to get the dedicated server but usually what I was doing that I was also making sure that the full client would work it made things easier for me I didn’t need to dual boot or things like that for testing so it all made sense.

What made the ports relatively easy is that Tim never had to touch anything about the rendering part, as mentioned earlier. Only the other parts of the game had to be abstracted.

Tim: id tech never had multiple back-end renderers. It was just OpenGL so then you had the platform abstraction layer, the networking and the file system access and that’s it most of code was a portable from the get-go. It did influence not using various SDKs etc. because of course at the time a lot of middleware SDK were Windows only. So as long as as well as the tech didn’t require a lot of external SDKs then the Linux ports were fairly easy.

At that time, the Linux ports had to rely on a single vendor for GPUs. You could forget about AMD or Intel.

Tim: It was pretty much nVIDIA only. It was the only company with drivers that were stable and featured enough to the support the games. I don’t remember encountering particular problems with the drivers. For me the nVIDIA drivers were always very reliable. That’s why we kept telling people “get a nVIDIA card!”. And the situation’s changed drastically now.

I have always wondered why nVIDIA was so much ahead of the curve in terms of OpenGL support. After all, the gaming world has been focusing on DirectX for a very long time now on PC, and there seemed to be no great reason for nVIDIA to spend so many resources on their OpenGL drivers. Tim does not know for sure, but suspects it may be B2B related. Yet who knows, maybe id software had some kind of influence as well on that topic…

Tim: I suspect it was maybe looking more towards corporate customers and non gaming applications rather than games. But I don’t have really have any details on that. […] There was the fact that John kept pushing for cross-platform, kept pushing for OpenGL, kept saying that OpenGL was really an important API, that the industry needed some kind of balance to Microsoft’s influence. So I think the nVIDIA folks were sensible to that but they probably had the financial incentives too. I don’t think that was the gaming market, there’s professional customers probably. I wasn’t involved in those discussions and I sure was just happy to get the drivers.

At some point, id software stopped provided Linux clients for their games. The first game for which it happened was Rage. While we may think there was some kind of dark conspiracy against Linux, actually the explanation is rather simple. The company had shifting priorities.

Tim: The company probably changed to follow the evolutions of the market. Games were getting bigger and bigger with bigger budgets and the studio had to kind of change its practice change its approach to match. id went from a very small studio, back in 2004 until 2008 the company was maybe between 30 and 50 people max. We had ten programmers really. When I started I think we were five or six of us. So it’s very different, in a small company and then growing to a studio with 100 to 150 people.

One interesting thing that I heard once is that id never saw themselves in the business of turning Linux into a viable gaming platform. I think that’s the main thing. It was interesting from a technology standpoint to release native Linux ports. It helped get higher engine quality, it helped with debugging on a number of issues. For dedicated servers it just helped in terms of product. But id never never saw its role as trying to turn Linux into a viable commercial platform.

So when the company got bigger, really why no Linux port happened for Rage is because I was busy on other things. I progressively moved on. I was involved with Quake Live and Quake Live we still maintained a native Linux client for several years. Then I moved up in the company, I had a lot more responsibilities in being lead multiplayer programmer. So that kind of killed any time I could give to keeping a Linux port up and releasing it.

Carmack had always given the impression to be a champion of Linux gaming. There were times where he was a vocal supporter. But in reality, John Carmack had virtually nothing to do with the Linux ports at id software, because Tim was reliably taking care of them:

Tim: […] We never had a conversation about that, but I assume he was pretty happy with me taking over the release of Linux ports and generally taking care of processing the source code when we got around to releasing the source code for one of the tech iterations. He didn’t see the need to be more involved. He was working on Windows, Windows has always been his main platform. I think he was pretty happy with the state of things. I don’t think he’s the guy who would be overly concerned about commercial viability. He certainly never blocked Linux port from happening. It’s just with general pressures of working in a game studio on a deadline to release games, that killed Linux releases.

So in 2017, and soon 2018, id software shows no sign of Linux support, despite the fact that they still do not rely too much on DirectX. So, not all hope is lost…

Tim: They are mostly focusing on Vulkan. Doom 2016 supported both OpenGL and Vulkan. If you go and look at Twitter from the id developers, Wolfenstein is Vulkan only. No OpenGL, no DirectX. They fully embraced Vulkan. So in terms of portability, it’s pretty good. Now someone has to convince them to actually make the release happen. We are still in pretty good terms with id. I have done some contract work with them after I left.[…] We talk every now and then. I know a lot more than I can say [about] what’s going on internally. But I really hope they get around to releasing native Linux binaries again. Wolfenstein too, obviously, but I would love to see Doom 2016 as well.

In the Linux gaming community there is usually a strong resentment against Bethesda who is sometimes seen as the evil mother company of id software, preventing them from ever releasing or hinting of any Linux port. Tim thinks the reality is a lot more nuanced, and their thinking could change over time.

Tim: I cannot really comment a whole lot on this. I think it’s true that with Bethesda in the picture, there are certainly more attentive to the business case, than the id from the early 2000s might have been. It’s to be expected. It’s a very different age. Now the good news is: there’s a lot of good reasons now to release your game on Linux. It’s always the chicken-and-egg type of issue between what games are available on the platform and in what kind of sales you’re gonna make etc. but Valve has done tremendous good to the platform with the distribution, Steam and SteamOS on Linux. So it’s gotten a lot easier, the experience has gotten a lot easier. The Steam Machines are not going away. You regularly see a lot of concern about what Microsoft is generally doing with Windows, where they might want to take Windows 10. For Microsoft the obvious business case is to push everyone towards Xbox. They could even argue that they don’t really need to support gaming on Windows at all. “Hey, we can sell more Xbox’es! Isn’t that awesome?”. For companies, for publishers and games studios, it’s smart to target Linux. It also helps you to target PlayStation, to target Switch. If you want to push your game on consoles, making sure you can run on Linux is probably a good idea. Especially now if you’re working with Vulkan. Vulkan is supported on the Switch, so you can go everywhere, you would target Windows, but you would try to be pretty quickly try to target Linux, because it’s an easy platform to work with compared to a console with a heavier development kit, that sort of thing. So I think there are a lot of good reasons for companies still to target Linux outside of commercial success. But the platform still needs to grow, and the big companies that have triple-A titles are the ones with the best chance of growing the platform, so they should see what’s in it for them and try to go onboard. I’m rehashing a lot of old stuff here, it’s stuff that hasn’t really changed so for the last 15 years.

While the jury is still out for Bethesda, there are clear supporters of Linux out there, and Croteam not the least of them. Their ongoing support for Day-1 Linux release as well as Vulkan and VR for Linux is still pretty much unique in the industry.

Tim: Croteam has embraced Linux and VR. They did a great job with the various series. I get lost in all the Serious Sam’s, there is like four of five of them, but I’ve got them all installed here. And I know they have VR support. So I got to meet with some of the Serious Sam devs at the Valve offices. We’re really happy with what they’re doing on Linux. Games studios should really look for that balance between the decisions driven by marketing and revenue, but they should still be true to an engineering core, an engineering tradition. Usually the core engineers, the core developers in the games studios are usually pretty supportive of Linux and writing portable code, and things like that. You do encounter every now and then lead developers who are hard core Windows-only people. But, usually, I come to the conclusion pretty quickly that they are narrow-minded. They may be very talented. They may have a very in-depth knowledge of Windows, but they just don’t seem to have a kind of long-term horizon view of things. Game Studios really need to listen to some of their core engineers, when they’re telling management, when telling marketing that “we should really get a port of these going, because we want to have a foothold, we wanna keep an eye on portability”. I think it’s very important.

In this environment, we were wondering if Vulkan was really having a real impact or not on Linux gaming prospects. Tim had no hesitation whatsoever.

Tim: Oh yeah! Oh yeah! OpenGL has always suffered from being a little slower than DirectX 11. OpenGL over the past ten years has become this kind of agglomeration of extensions and extensions and extensions, and there’s always two or three different ways to do the same thing in rendering. I’m not gonna go into details, because I don’t have a huge grasp on the details, just a top-level experience, but you know you’re looking at Unreal Engine, and on the same game the OpenGL back-end will always be a few percents slower than the DirectX backend. There’s a multitude of reasons for that. DirectX gets more eyes, gets more focused on performance. Some architectural decisions are made for DirectX, and don’t map particularly well for OpenGL. You get all those compounding problems, so that’s why you end up with GL back-end being always a few percents slower, or having some rendering issues that are difficult to tackle in OpenGL. So I think Vulkan changes a lot of things there. We finally get an API with a clean fresh start, that doesn’t carry a lot of baggage, or backwards compatibility and incremental evolution. If you’re new to rendering, and you start learning a new API, picking up a Vulcan tutorial, going through the Vulkan tutorial makes a lot of sense. It’s a really great way to start learning rendering, to start learning about GPUs. The API makes a lot more sense because it doesn’t try to abstract things as much as GL did. And then if you try to transfer this knowledge to learning OpenGL, it becomes very complicated very quickly. Because of API design reasons, the years of evolution of a different sub languages of OpenGL, a kind of different dialect. So Vulkan is making a huge difference. But a lot of the porting work right now… I see a lot of things like Vulcan renderers. That seems to happen a lot right now. And just companies that start writing a Vulkan rendered directly from their existing DirectX code. And Vulkan beats both DirectX and OpenGL in performance. At least DirectX 11. So we have that little in-fighting between DirectX 12 and Vulkan, but for companies we have to do whatever we can to convince them to try to do Vulkan first. Vulkan on all platforms, then target the Xbox One as its own renderer, the PS4 as its own renderer, but really look at Vulkan as your main back-end. Because the Vulkan structure maps pretty well to the consoles anyway. […] Once we start seeing a few major titles on the market that do well, and that are Vulkan only, then let’s hope that the rest of the industry starts to follow suit. “hey this makes sense, those big publishers have major technology that is Vulkan only, let us do the same”.

Tim has had a hiatus in his porting career on Linux. After leaving id software behind, he moved to a very different kind of activity. But he could not stay away from games for too long…

Tim: I went into mobile development for a few years and mostly server backend kind of stuff. I got a little tired of doing client game engines. I have always had some interest in back-end and cloud technologies, so I spent years doing back-end for mobile games, things like that. It was pretty good. Then a few years ago, I started freelancing. I have my little company here in Dallas, and initially I was going to do technology in general, but as it turns out, I have good contacts in the game industry, and people that enjoyed working with me, or know me by reputation. Most of the phone calls I would get were about doing game related stuff. I started working again with various game studios and my main involvement right now is with Valve. I am kind of helping out behind the scenes, with Valve’s efforts on SteamOS, on Steam Machines, VR on Linux. What I’m doing right now is really Valve stuff.

[…] I really disappeared from looking at Linux and looking at the games on Linux. I kind of stopped looking at it for maybe eight years between the time I left id and then time I started working for Valve again. It’s very different now. There is Feral Interactive, there are a few other companies that seem to be financially stable, as much as a company working in high tech can be. But they’re there, they’re porting titles, the library keeps growing, you feel that there is a really ecosystem of companies looking to get SteamOS releases done, or just Linux releases done, and there’s companies that can work on those problems with them, and there’s a Linux audience that is looking at all the upcoming tiles, and you know consumes news about the release or non-release of those titles. It’s a very different environment from what it was seven eight years ago. I don’t see any reason why it wouldn’t continue to grow. The Indies seem to have embraced the platform. That’s a lot thanks to Unity for making the release of the Linux version of your game kind of “click the button and upload binaries”… in practice, it doesn’t always work that simply.[…]

I was lucky these past few years to do a bit of work, on various projects, various technologies. I worked with id some more to kind of get the ball rolling on Quake champions and a few other projects. It’s been really great having access to those different game companies and game studios, and kind of seeing from the inside their development process, and looking at many different game engines. Ryan and I are probably lucky to be in that situation, where we’ve seen source code for many different engines, and it’s very interesting to compare the different structures, the different way they are written, the different kind of design decisions they made. It’s a very very healthy industry in gaming, when you look at the variety of game engine that are out there.

Tim has been one of the key persons behind the Rocket League port. Ryan Gordon was credited to get it working at first, but the whole optimization work and what Icculus described as “making sure the port does not suck” was basically the work of Tim.

Tim: I’m very happy I got to work on it, thanks to Psyonix team for working with me on that, and being very responsive and very involved in making it happen. And Pierre-Loup at Valve bringing me in. Ryan did some of your early heavy lifting. Rocket League is an Unreal 3 engine game, and Ryan has significant experience with Unreal Engine 3, so he had done a lot of the heavy lifting when I took over. […] I had to take a crash course in learning a bit more about rendering while making the port which also counts for the fact that it was a little late. […] I would track a number of OpenGL renderer issues, we were able to kind of narrow them down and get a pretty good release out. […] The thing with Rocket League, most of the issues we ran in had to do with game code. We had a few rendering bugs but not that many. We had a few crashes due to the game code, we had a few crashes due to the scripting system. The scripting system in Unreal Engine 3 was all scary. […] We still shipped with known issues, in particular the Linux client needed a new WY SDK client. WY is a sound library. There was a crash that was a race condition inside WY. It was good enough I think that Psyonix decided to go ahead with it. I assume that in the end they may have upgraded the SDK. SDK that are closed source are still an issue when doing Linux ports. We are in a better place than a few years ago. You can go talk to a lot of those middleware companies, and even if they don’t have an official SDK for Linux, they sometimes have an unofficial one.[…] That situation has improved but whenever you start a new game port, the first thing we do is look at all the SDKs they might be using, see what is missing, see what’s gonna be a problem. You’re always running around the same handful of SDKs, it’s Scaleform, WY, it’s always the same ones.

When doing Linux ports, it is not rare that the quality of the overall code for all platforms improves, as it is integrated upstream.

Tim: I found a few bugs that were definitely present on all platforms. That’s an argument you when we try to convince a company to do a port, is that there are some bugs that will be more obvious or easier to track on a different platform. I know we fixed a memory corruption issue. It wasn’t causing a crash on Windows, or it was causing a crash but that would have been more difficult to track, that would be happening at some other point, and on Linux it was pretty reproducible and it was crashing the stack so we find it pretty quickly. So there were a handful of issues, that just generally improved the overall quality of the game. That’s also one thing that you always try to do with a port, is to try to get your changes integrated back upstream. It’s a very difficult situation to find yourself with a branch of the code with modified assets, and try to keep up with the main development. I guess for a single-player title that could be a solution, but as soon as you’re looking at multi player title and games that are still being actively developed, you want to be able to to push that work back. Rocket League was the first game to do a cross-platform play between PS4 and Xbox. It was also a big challenge while putting the port together because we were gonna do SteamOS, Mac, PS4, Xbox, everyone together. That worked well. I haven’t heard from them in a while.

And, as you have probably figured by now, the Linux port of Rocket League was pretty much a push organized by Valve in order to promote SteamOS.

Tim: That was part of the work with Valve essentially. Valve is working to promote SteamOS and Linux as a platform. Going back to what I said earlier. Back when id didn’t consider itself in charge of Linux’s success as a gaming platform, I think Valve took the opposite approach, to truly embrace the platform, and do the best they can to turn it into a viable identifiable gaming platform and a viable experience. And obviously for Valve with Steam it makes a lot of sense for them commercially, to be a real platform play. Whereas id was always a game studio “we’re making games we’re not making a platform”. So part of my role, and part of Pierre-Loup’s role is to talk to the various game developers that publish games on Steam, and tell them the merits of Linux and SteamOS and convince them that they should be on the platform, that there are benefits for everyone in having in having their titles on SteamOS. And so the Rocket League work was a part of that effort. Valve had a pretty good relationship with Psyonix, and convinced them to let us do a Linux essentially. The approach is really to try to educate those studios, in really having them discover that Linux is not that hard to support, giving them the tools, doing some of the early heavy lifting. The hope for each of these projects is that the company takes over the cross platform release and they maintain it moving forward. I think something that happens pretty often in those Game Studios, is that you got at least have one or two engineers who are very friendly to Linux, who may have some amount of experience already, but there is no Linux release because they don’t have time to do the initial heavy lifting of the port. Or they’re still missing a few pieces in terms of compiler knowledge, some low-level API knowledge of how to make it happen. So they are missing that little bit. That’s where we try to make a difference, to bring that knowledge to those companies. To do some of the work, show them the process, and help them deliver a working port, with the expectation that they’ll take over and they’ll start maintaining.

That’s what happened with Psyonix. The port has been in their hands since two months ago now. They’ve embraced it and they maintain it in-house, it’s really out of my hands now. That’s the ideal situation, that’s what Pierre-Loup and I work towards, to get those companies to take over the SteamOS release and start treating it as just another platform. Obviously this one is a great success we’re very happy with it, there are projects that I cannot talk about, where it’s a little more difficult. We still have some convincing to do, we still have some bugs to resolve. But we’re continuing to talk those developers and push towards having a port released.

Rocket League is one of those games that many of us (BoilingSteam included) believed to be either dead or vaporware since the release was pretty much delayed compared to the initial estimations. It did come out, but what about games like Street Fighter 5, which seem to be stuck in the same kind of limbo?

Tim: There’s very little I can say about that. The only thing I can say is: “it’s not dead”. It definitely falls into that category I mentioned earlier, of some that are more difficult. But I think that’s the challenge that you have to face up to. What we’re trying to do with Pierre-Loup is we’re trying to go after these big titles. We’re trying to go after these big companies with big titles, because there is more uncertainty into getting a port out, because bigger company means there is more red tape, there are bigger challenges, but the payoff, the impact on a platform is significant, much bigger. Valve is in this position where they can have an impact there, so that’s that’s what we’re trying to focus on. It can be a little frustrating, because you know we cannot talk about it until the publisher is ready to actually say something. Rocket League was in the same situation. We were a little too excited, and we announced it too quickly and gave a release schedule and a timeline and we missed it by six months or something. The only thing,I can tell about Street Fighter is “it’s not dead”.

In terms of what brings companies to port their games to Linux, it’s rarely “immediate financial returns”. The attraction of a Linux port goes way beyond simple ROI calculations, and seems to be more likely some form of investment that bring you new opportunities.

Tim: I think you really have to play it by ear and listen to what they say and what is important to them. You come across different companies with very different outlook. Some of them will just want to make it happen. They have a strong engineering influence where they like Linux as a platform and they would like a port to happen, and they mostly look at it from the benefits of possibility and a clean stable code and that sort of thing. Some companies will be more concerned, want to future prove themselves a little bit. Some companies will be more sensitive to arguments about uncertainty about what’s going to happen with Windows as a gaming platform, the argument of portability. And some companies are also more sensitive to getting up a presence on a potentially expanding market and not missing up. To be an early adopter. Valve will always make that point that they are behind SteamOS for the long term. It’s not gonna explode exponentially, but it’s a platform that they are going to be behind for years. […] So depending depending on the company you talk to, you have to do that pitch and convince them that it’s a good idea, and depending who you talk to and what company, different arguments will have a different impact. A lot of cases, it comes down to how to to make it happen. It really comes down to logistics. That’s really what you often hear. It’s not that we don’t want to do it, or that it doesn’t make sense financially. It’s really more of no, we’d like to do it but just from logistics perspective we can’t. Because we’ve got this other title to do, we have got these two patches, these two fixes, so that where we’re able to say “hey we can help with that, we you can put some of our resources.” After making it happen, the idea is that the company has to generally agree to take over at some point.

While we don’t really hear from Valve at that level, Tim mentions they are clearly behind a lot of initiatives to help making Linux development easier for game developers.

Tim: Valve is also doing a lot of work to to generally make Linux development easier. It’s not something I can expand a lot on. But the goal would be to look at Steam machines as another console. Unreal engine 4 has been doing great work in that direction, where they’re able, and Unity as well, to cross compile and target different platforms, so Valve is looking to improve in those areas as well. So the logistics, the obstacles of the logistics get progressively reduced.

Somehow this seems a little contrary to what you might expect. After all, Valve did miss the opportunity to showcase the Steam Machines when they were released. It looks like they have pretty much given up on it from the outside, Yet this seems to be far from true. It’s simply that they are tackling a very large surface problem, and it’s going to take time:

Tim: […] I’m in a delicate position because you know I’m a contractor, freelance, working for Valve, but I am also still fairly on the outside, and certainly one thing I’ve noticed is they’re very ambitious about the future for SteamOS. But they are tracking a lot of different features. You look at Linux and you look at everywhere where the platform could be improved. That goes from the graphics drivers, to the general desktop and the X system, to the file system, to hardware and controllers. There is a enormous amount of areas in which SteamOS and Steam Machines can be improved for gamers. And they are very involved in pretty much everything.

Valve is involved in supporting GPU driver work, they’re involved in supporting over kernel features, they are involved in userland software stack, in issues of managing run time libraries, in the distribution and packaging of binaries across Linux distributions. They are involved in the hardware aspects, like HDR rendering on Linux for instance, and of course the Steam Controller, all the VR hardware technology. So that’s the challenge. When Steam Machines were released two years ago, that was just one aspect of everything else they’re doing for the platform. You have got a company that is very driven by engineering. I’m really talking about my outside view of Valve. Sometimes a company that is very driven by engineering, and that is chasing so many challenges might not do the exact marketing that they need to on a new feature, because maybe they don’t realize that this new feature is certainly very public. The release of Steam Machines was probably a very public thing, they are something you can buy in a store. But big improvements in quality of the drivers and things like that, when you are an engineer it’s just as important. You don’t necessarily understand it from a marketing point of view. Maybe there are some misses sometimes in terms of promotion and things like that. I think what’s important to keep in mind is that they are involved in so many aspects of improving the platform.

As usual, we are always interested to know where the Linux gaming market is going. Just like Ryan Gordon in our previous podcast, Tim thinks Linux gamers are not your typical gamers.

Tim: The gamers that play on Linux that consume Linux games, I think are a little different than the standard Windows PC gamer or the console gamer. I wonder if we are not building a different audience. It’s not even a matter of having people that were Windows gamers move to Linux. It’s finding a different audience. […] Something I have noticed about Linux and maybe it’s just an impression it’s not actually backed by numbers. Linux seems to be doing relatively well in areas where people have a little less extra cash to spend. If you’re a young student and you’re struggling a little bit to buy a computer you’re going to get a little more value if you run Linux, performance-wise and in terms of software, the experience you get, you are going to get a little more value. North America Linux as your everyday desktop may not be such a such a huge penetration, but in central South America, in Central Europe, you seem to see very dedicated, very active Linux communities. I don’t know how they’ll impact the growth of a platform. I mean it would be nice if China suddenly decided to get everyone on Linux. That would be an interesting move. It was nice for me as well really, because when I started working with Valve again, and I started being involved in a Rocket League port, it was kind of a good chance for me to go back to Linux as my main my main environment. I always dual-boot all my machines anyway, because a lot of porting work involves actually compiling the Windows version, and making sure you didn’t break the Windows version, exploring performance, implementation on the Windows version. I work in both. But it was great going back to Linux on a more permanent basis.

Now at Valve, Tim is more than ever involved in making our platform a better place for developers, and focusing mainly on Unreal Engine support.

Tim: My work right now is really focusing on Unreal, on improving the Linux support in Unreal Engine and in particular VR on Linux with Unreal Engine. I’m certainly not the only one working towards that end, but that’s been my main focus these past few months. Any companies out there doing VR, definitely get in touch! If you are doing VR, if you are shipping on Steamworks, definitely get in touch to talk about VR on SteamOS. We love to hear from you and see if we can can work together.

As you can see Tim is pretty much at the center of what Valve does to support Linux nowadays. Having someone of his experience in this role can only be beneficial for what Valve has in mind for Linux/SteamOS, and the improvements regarding SteamVR for Linux.