If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

For same reason why companies contribute to Linux kernel: because it's expensive to support own branch of engine and it's easier to push some features into mainline so it's Epic will support this code in future.

Also keep in mind that % of budget spend on programming is pretty small in game development. Most of money going into assets creation so for studious/publishers that's don't have middleware licensing business it's not critical to return some changes to Epic.

I don't think you can compare it with linux kernel (which has an open source license that encourages contribution). I also would think that games would stick with a certain engine version, due to time and budget constraints, so that possible patch maintenance should be trivial. Some guesswork on my side here of course...

Comment

I also would think that games would stick with a certain engine version, due to time and budget constraints, so that possible patch maintenance should be trivial.

Many development studious and publishers use Unreal Engine not for one particular title, but for multiple and in same time they want to use latest version of engine because it's benefit performance that extremely important on consoles.

They don't really care about sharing their code because they can't sell it anyway and code don't actually give any advantage to competitors because code it's not that important for games. Game development industry is pretty open related to sharing of knowledge, you can check SIGGRAPH as example.

Comment

Many development studious and publishers use Unreal Engine not for one particular title, but for multiple and in same time they want to use latest version of engine because it's benefit performance that extremely important on consoles.

They don't really care about sharing their code because they can't sell it anyway and code don't actually give any advantage to competitors because code it's not that important for games. Game development industry is pretty open related to sharing of knowledge, you can check SIGGRAPH as example.

Still they don't share the code or collaborate openly. And again, given the low budget for programming and time constraints, why should anyone even care to contribute back to the engine (and then have to pay to be able to ship that code, which even more funny). That is pretty much the only thing I am questioning here, I don't see how this open development is supposed to work.

Comment

Algorithms is everything while code is useless outside of project. Game development companies have no real interest in open sourcing whole code while some bits of in-home proprietary engines are useless. Before all AAA engines like EU had extremely strict agreement that nothing can be shared and now with Epic initiative it's become basically possible.

Comment

Still they don't share the code or collaborate openly. And again, given the low budget for programming and time constraints, why should anyone even care to contribute back to the engine (and then have to pay to be able to ship that code, which even more funny). That is pretty much the only thing I am questioning here, I don't see how this open development is supposed to work.

Yeah, you're missing the point.

The point is that major companies can push their changes back upstream, which reduces their work. That way they don't have to port all their patches to each new version that comes out.

I don't think anyone is expecting much real development to come out of this, in terms of moving the engine forward. It's just a convenience thing for their customers.

Comment

I don't think you can compare it with linux kernel (which has an open source license that encourages contribution). I also would think that games would stick with a certain engine version, due to time and budget constraints, so that possible patch maintenance should be trivial. Some guesswork on my side here of course...

Compare it to Qt or LLVM then. Or just trying to upstream kernel developments vs keeping downstream patches. In the end, it is what pushes corporations contributions in open source projects: reducing the burden of maintenance. That's what they get out of it, they don't do it "for free".

Comment

Question: If one company create a game written in HLSL, there will be enforced by the engine a compatibility layer like GLSL bytecode or source extensions, that will allow the D3D renderer to be seen by an OpenGL driver, or not? There will be dead cases between a D3D renderer and an OpenGL one? It will allow MS friends to play with as adding overhead, or it will stop unnecessary shader compilations and will move Api calls inside shaders to offload Cpu work into the Gpu? Will it be a previous century "MS slave" garbage, or something new? Any game engine that allows for a closed source game to be compiled non JIT (for a specific Cpu architecture) is an "Intel slave" garbage anyway.