You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can support us on Paypal and Liberapay!

Sad news, as it seems there's just no chance of Killing Floor 2 coming to Linux any more as Tripwire can't find a developer.

Going back to February of last year, Knockout Games sneaked out before that they were working on it, but not all contracts work out of course. I assumed they had parted ways, since later in August of last year Tripwire then said it wasn't in active development. I was hoping Knockout Games (or anyone) was just quietly working on it, but I guess not.

Here's what Tripwire have now said about it:

Currently all progress on a Linux Client is indefinitely on hold. While progress was made towards getting the game client to run on the platform, we have been unable to find a person or persons to finish the work needed to make a client.

The major bottleneck has been getting the rendering system up and running (the key part of the client) as the engine now works on platform (the server is the engine minus a client and loading assets it doesn't need to render/trigger). During Killing Floor 2's development a choice was made to rewrite the DirectX rendering system. This in turn means many of the "turn key" Unreal porting solutions that existed do not apply to Killing Floor 2, as they all assume that the game is using the default Unreal 3 rendering pipeline. 

So far the third parties we have talked to either do not want to undertake the creation of a new OpenGL rendering pipeline from the ground up (due to time and effort involved) or have quoted a price that makes it beyond consideration (the cost versus estimated return math does not come even close to making sense based on previous Killing Floor 1 Linux sales when charted against Killing Floor 2). 

If that changes, we will be happy to re-open development of a Linux client, but until that point it is on hold.

I was really looking forward to playing Killing Floor 2 one day, but it seems like it's not going to happen. Thankfully we have a lot of other great games, but it still stings a bit to hear this.

It's genuinely sad that a developer has again locked themselves into one single closed API. The annoying thing, is that they're using the sales of the original in their considerations of Linux being worth it or not for the new game. This is after previously confirming they will do it, multiple times. The problem I have with that, is Killing Floor was released for Windows in early 2009 and released for Linux in late 2012, that's well over three years after the original release when many people will have already owned it. Heck, even I already owned it, as I knew many people already did. This is part of the problem with Linux versions coming late—you will lose sales and then you will look at it like Linux sells even less than expected.

Thankfully, with game engines now having better support for OpenGL (and Vulkan support is slowly getting better), this is less of a problem for newer games—if they use an up to date version that is.

I still hope one day either someone like Ryan "Icculus" Gordon or another Linux porting champion can take another look, but considering how much work they've made for themselves, it doesn't sound likely.

9 Likes, Who?
40 comments
Page: «4/4
  Go to:

Whitewolfe80 11 January 2018 at 6:01 pm UTC
kalinCan we ask Ryan C. Gordon or Ethan Lee for help

Ethan cant help its not built around xna, Ryan C is a good shout but i doubt his patron sub would cover the hours required to overcome that problem.
johndoe 11 January 2018 at 9:12 pm UTC
Changing/Modifing the source code of an application is always a bad idea.
An engine is not different - it's still a piece of software.

Some years ago I have worked for a big selling platform in germany and the heads of it decided to change the source code of MySQL 4.x and failed lousy when MySQL 5.0 arrived. The many changes could not be ported to MySQL 5.x anymore.
Today this company is owned by others - what a surprise

I think the guy (project leader) responsible for the decision to make changes to the rendering engine was forced by the publisher to that.
I'm sure he showed a way to do things right but the publisher decided to go the cheaper and faster way.

OpenGL (before Vulkan) is much better/stronger than DiretcX when you know how to use it. Think of Id Software.
But OpenGL is more complex. You need a lot of experience to do the right thing.
OpenGL has many ways to do the same thing but not all lead to best performance.
Id Software has this experience - most developers nowadays do not.

Vulkan WILL change this. But this takes time.
kalin 11 January 2018 at 10:35 pm UTC
johndoeChanging/Modifing the source code of an application is always a bad idea.
An engine is not different - it's still a piece of software.

Some years ago I have worked for a big selling platform in germany and the heads of it decided to change the source code of MySQL 4.x and failed lousy when MySQL 5.0 arrived. The many changes could not be ported to MySQL 5.x anymore.
Today this company is owned by others - what a surprise

I think the guy (project leader) responsible for the decision to make changes to the rendering engine was forced by the publisher to that.
I'm sure he showed a way to do things right but the publisher decided to go the cheaper and faster way.

OpenGL (before Vulkan) is much better/stronger than DiretcX when you know how to use it. Think of Id Software.
But OpenGL is more complex. You need a lot of experience to do the right thing.
OpenGL has many ways to do the same thing but not all lead to best performance.
Id Software has this experience - most developers nowadays do not.

Vulkan WILL change this. But this takes time.

Do you ever use opengl? OpenGL was and still is abomination. There is a reason for people to prefer direc3d. Why opengl is so fucked up is another topic. Currently I learn vulkan and don't have opinion on it for now.
Please be informed and don't trow statements just like that. Negativism never help. The studio is free to do what ever they want to do with their products. Stop blame them for not porting game that you probably never buy anyway.
mirv 11 January 2018 at 11:08 pm UTC
View PC info
  • Supporter
kalin
johndoeChanging/Modifing the source code of an application is always a bad idea.
An engine is not different - it's still a piece of software.

Some years ago I have worked for a big selling platform in germany and the heads of it decided to change the source code of MySQL 4.x and failed lousy when MySQL 5.0 arrived. The many changes could not be ported to MySQL 5.x anymore.
Today this company is owned by others - what a surprise

I think the guy (project leader) responsible for the decision to make changes to the rendering engine was forced by the publisher to that.
I'm sure he showed a way to do things right but the publisher decided to go the cheaper and faster way.

OpenGL (before Vulkan) is much better/stronger than DiretcX when you know how to use it. Think of Id Software.
But OpenGL is more complex. You need a lot of experience to do the right thing.
OpenGL has many ways to do the same thing but not all lead to best performance.
Id Software has this experience - most developers nowadays do not.

Vulkan WILL change this. But this takes time.

Do you ever use opengl? OpenGL was and still is abomination. There is a reason for people to prefer direc3d. Why opengl is so fucked up is another topic. Currently I learn vulkan and don't have opinion on it for now.
Please be informed and don't trow statements just like that. Negativism never help. The studio is free to do what ever they want to do with their products. Stop blame them for not porting game that you probably never buy anyway.

Well.....I have and do use OpenGL. And yeah, it's damned powerful, with about only one real drawback (lack of API level threading support). Even then, GL4.5 and DSA started to overcome that (emphasis on "started". D3D had, and has, a lot of non-API features however. Tutorials, test suites, debuggers, etc. Reasons aside, Microsoft at least did understand that an API alone is insufficient if they wanted masses of developers.
OpenGL had a lot of new features first, well before D3D. Simply easier for hardware vendors to do that really - it was a good place to test out something new, without having to wait for the next revision (aka OpenGL extensions). Id was quite into that, and got a lot of extras out of it....but yeah, they were kind of special in that a lot of things were just a playground for Carmack.

I also use Vulkan. I wouldn't call myself an expert with it, but understanding the fundamentals of modern graphics via some of the advanced features of OpenGL helped a lot. Khronos are doing a really nice job with Vulkan, and really listening to developer feedback.

My, hmm, "shaking head" with Tripwire in this case is not them choosing D3D. It's their communication - as in saying they'll be doing a GNU/Linux version when it's clear now that they never intended to do so. If they'd said "we're doing all this for windows only first; we're not against the idea of a GNU/Linux port but it's not a priority" then I'd be singing a different tune. If they came out and said "we're abandoning a custom rewrite and going to support something with wine", I'd also be ok with that (the key word being "support". But that's not what's been communicated.
Ultimately though, it doesn't matter much. I might well have bought the game because it's a gameplay type I normally enjoy, but I haven't bought the game, I'm not out of pocket, and I'm simply going to not really care. Unhappiness with tripwire indicated, moving on.
Purple Library Guy 12 January 2018 at 7:24 am UTC
jayceeI see the usual garbage and slagging off the developers is being posted...

Why did they use Direct3D ? Simple. It's the best API for the desktop platform. Doesn't matter about "vendor lock in" when 90% of your market is on the platform where that doeesnt matter.

If they had just used Direct3D, that would be normal and fewer fusses raised. Porters are used to working from Direct3d-->OpenGL and surely have tools for doing so. The issue here is that they apparently took Direct3D and heavily modified it, resulting in a custom thing that nobody has any idea how to port from. I would be willing to bet that's caused plenty of problems besides just difficulty porting to Linux; it sounds like a really dumb move.
Further, they apparently did this while claiming quite positively that they intended to do a Linux port, even though one would think it pretty dashed obvious that those two things were unlikely to be compatible.

I think a few facepalms are quite justified. I also think one current in this discussion is very strange--there have been a couple of people saying basically, "Stop the criticism! They're engaged in moneymaking activities so they can't possibly be making mistakes!" Um, what?! Some people haven't been reading their Dilbert. People, markets are not efficient and lots of moneymaking companies make plenty of boneheaded mistakes. People do not get anointed with infallibility by the market fairy as soon as they start working for a profitable corporation.
mirv 12 January 2018 at 8:44 am UTC
View PC info
  • Supporter
Purple Library Guy
jayceeI see the usual garbage and slagging off the developers is being posted...

Why did they use Direct3D ? Simple. It's the best API for the desktop platform. Doesn't matter about "vendor lock in" when 90% of your market is on the platform where that doeesnt matter.

If they had just used Direct3D, that would be normal and fewer fusses raised. Porters are used to working from Direct3d-->OpenGL and surely have tools for doing so. The issue here is that they apparently took Direct3D and heavily modified it, resulting in a custom thing that nobody has any idea how to port from. I would be willing to bet that's caused plenty of problems besides just difficulty porting to Linux; it sounds like a really dumb move.
Further, they apparently did this while claiming quite positively that they intended to do a Linux port, even though one would think it pretty dashed obvious that those two things were unlikely to be compatible.

Sorry if it's not what you meant, it just sounds (to me) like you're misunderstanding. They didn't modify D3D at all. They changed how they used it inside of the engine code.
It can still affect D3D -> OpenGL effort, especially if done from a source code level where some porters were familiar with the "old" Unreal3 engine code only, but it's not like a new graphics API is created.
knro 12 January 2018 at 9:27 am UTC
Well, given Linux users are like %0.25 of Steam users, why would they even care? They chose D3D which can target over 90% of the potential users out there.
nox 12 January 2018 at 9:38 am UTC
View PC info
  • Supporter
knroWell, given Linux users are like %0.25 of Steam users, why would they even care? They chose D3D which can target over 90% of the potential users out there.

I understand that part, and I agree.
But don't forget that they announced it with linux support - and kept promising it. Breaking promises isn't justified by saying "small user base"
Purple Library Guy 12 January 2018 at 5:02 pm UTC
mirv
Purple Library Guy
jayceeI see the usual garbage and slagging off the developers is being posted...

Why did they use Direct3D ? Simple. It's the best API for the desktop platform. Doesn't matter about "vendor lock in" when 90% of your market is on the platform where that doeesnt matter.

If they had just used Direct3D, that would be normal and fewer fusses raised. Porters are used to working from Direct3d-->OpenGL and surely have tools for doing so. The issue here is that they apparently took Direct3D and heavily modified it, resulting in a custom thing that nobody has any idea how to port from. I would be willing to bet that's caused plenty of problems besides just difficulty porting to Linux; it sounds like a really dumb move.
Further, they apparently did this while claiming quite positively that they intended to do a Linux port, even though one would think it pretty dashed obvious that those two things were unlikely to be compatible.

Sorry if it's not what you meant, it just sounds (to me) like you're misunderstanding. They didn't modify D3D at all. They changed how they used it inside of the engine code.
It can still affect D3D -> OpenGL effort, especially if done from a source code level where some porters were familiar with the "old" Unreal3 engine code only, but it's not like a new graphics API is created.

My mistake.
scaine 15 January 2018 at 8:33 pm UTC
View PC info
  • Contributing Editor
  • Supporter
jayceeI see the usual garbage and slagging off the developers is being posted...

Why did they use Direct3D ? Simple. It's the best API for the desktop platform. Doesn't matter about "vendor lock in" when 90% of your market is on the platform where that doeesnt matter.

It matters entirely when you a) claim to support Linux/SteamOS, b) later tweet about that support, AND c) your founder and president even advocates SteamOS in an interview.

In the same interview, Gibson even claimed to believe that "almost every PC game will end up on Linux eventually". Yeah. That won't really happen unless he does something about that shoddy engine decision, will it?

It's nice that you defend developers, Jaycee (you are one, I seem to remember?), but Tripwire don't deserve it in this case. Another broken promise.

Icing on the cake for me was that they locked their Steam forums such that you may only post if you already own the game. Just why? So frustrating, cos until recently, we didn't even have any way to show support for a Linux client. I've got it wishlisted now, but honestly, after the extent of both their broken promises and lack of communication regarding this, I'm not sure I can bring myself to support them.

And finally, Yashiro, in his update closing the 450+ odd comments requesting a Linux client... actually has the bare-faced gall to suggest that Linux sales of KF1 didn't justify the investment... just, holy shit. He's using a 2009 game released solely for Windows and which got an indirect port TWO YEARS later, plagued with texture issues, as an additional justification for not porting KF2?!?

Nope. I'm out.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon or Liberapay. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations and subscriptions! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Official Livestreams
  • Company of Heroes 2 (join in!)
  • Date:
Community Livestreams
  • Story Time: Inherit the Earth
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Forum Posts
Facebook