There Exists A Native Linux Port Of CryEngine 3

[downer]

I've also heard almost no one liking to work with Unreal in the past, but it may not be true anymore with UDK. Unreal Tournament 2004 is a little unstable on Linux, but does look nice and some of its mods like UnWheel also made it to Linux, which isn't always the true for mods.

Edit: What GreatEmerald said.

[entropy]

The UDK is another thing that makes it so popular - anyone can try out the tools that game developers themselves used, in a free (as in beer) manner, without any limitations, with the exception of selling your game and revealing proprietary code.

The Cryengine seems to be available as well for free under a non-commercial license: http://mycryengine.com
At least there are some header files present hinting some kind of Linux support, taken from this thread (aug. 2011).



Of course, this does not necessarily mean that the Linux port is included in the SDK.

[russofris]

No it doesn't. Yes, the PS3 supports a form of GL ES. No, no serious game on the PS3 actually uses it. It's a bit like how Windows supports GL but most games using D3D, except even worse.

A very large part of this is because GL (and GL ES) are horrifically crappy APIs that have a lot of limitations in regards to contemporary PC graphics hardware, much less the very non-PC-like architecture of the PS3 (or XBox 360 or Wii, for that matter). No general-purpose graphics API is going to match the hardware of the consoles well, hence nobody uses general-purpose graphics APIs on the consoles.

A lot of games on the consoles partially eschew any API and make use of directly writing opcodes to the GPUs. This works only because the hardware is completely locked to a specific architecture, unlike the PC.

While I understand that much of the OGLES API is often bypassed during the optimization phase, I do not believe that this disqualifies the the game from being an OGL game. The example of windows OGL/D3D is confusing to me, as I am unaware of any other API available on the PS3 (aside from the direct-to-hardware optimizations and cuda).

Ultimately, I agree with what you've said, but do not feel that optimized-for-PS3 titles no longer qualify as being "OpenGL Games". Perhaps my knowledge of the topic is simply dated and no longer accurate (It's been approximately 4 years), and there is some new fancy pants-to-the-metal API for PS3.

[mememe]

The Cryengine seems to be available as well for free under a non-commercial license: http://mycryengine.com
At least there are some header files present hinting some kind of Linux support, taken from this thread (aug. 2011).

AFAIR linux headers were already a part of the CryEngine SDK when it was the Far Cry Mod SDK. These files are needed to build game binaries for Linux-based servers.

[ciplogic]

Linux may be used simply because it shares semantics with OS X, so developers that are distributed over the team, can use Linux as a surrogate in testing phase. At the end, OS X I think may be the target.

[russofris]

Linux may be used simply because it shares semantics with OS X, so developers that are distributed over the team, can use Linux as a surrogate in testing phase. At the end, OS X I think may be the target.

You may be partially right. Mac shares the x86 architecture and OpenGL API. I'm not certain that mac games would use SDL and OpenAL though.

From a software-platform standpoint, I believe Mac has more in common with a PS3 than a Linux86 PC, including the Mach-O binary format (not ELF like linux). A couple days ago I took a look at my PS3, and it appears to be running a Mach kernel with some components taken from BSD (networking). Think of it as a powerPC mac with Mach-kernel+sony-gui and a funky memory layout, which is divided into two areas. I do not imagine that the thing is easy to develop for.

On the plus side, I have heard rumors that Microsoft, Nintendo, and Sony will all use ATI's tech in their next offerings. If they all use SI tech, then PC SI users may start to see titles ported over more easily.

F

[mememe]

Linux may be used simply because it shares semantics with OS X, so developers that are distributed over the team, can use Linux as a surrogate in testing phase. At the end, OS X I think may be the target.

That doesn't really make any sense to me as the monthly cost of a programmer is about the same as the price of three high class Macintosh computers. I personally think it's dangerous to use Linux as a surrogate for OS X while testing (and vice versa), as XNU and Linux may handle some things differently.

[elanthis]

Ultimately, I agree with what you've said, but do not feel that optimized-for-PS3 titles no longer qualify as being "OpenGL Games".

They're not programmed with OpenGL. Simple.

Even if you want to focus on PSGL (the GL-derived API Sony offers on the PS3), understand that it has a ton of completely non-standard, non-portable extensions that must be used to actually do anything interesting with the PS3 GPU. The games written with it are NOT GL games, because they aren't using any remotely standardized, portable, usable version of the API's managed by Khronos. The API looks like GL ES 1.x at first glance. That's where the similarly ends.

You might as well claim that XBox360 titles qualify as OpenGL games. Hell, it's actually _easier_ to port XBox360 titles to GL, since at least the modified D3D9-based API is closer to desktop D3D/GL than the crazy PS3-specific APIs used on Sony's console.

@Eleanthis, sometimes your comments annoy me,

You're such a sweetheart.

but on the technical side I am reading them with great interest.
This time I don't want to be a dick,... just of curiosity - What is wrong with UEngine, and how you compare it to Source or IDTech4 for example?

I haven't seen Unreal4's internals, so they may have finally gotten their act together, but I can't say. Also keep in mind that my "niche" is an engine lead, so I'm particularly critical of unsexy internal architecture things that certain other classes of developers don't notice, understand, or care about (graphics programmers in particular; yet to meet a graphics dev who doesn't write code that makes me want to gouge my eyes out with a rusty spoon, even if that code does produce ridiculously amazing results I could never replicate; graphics is all hacks).


Regarding Unreal, the problem largely stems from Unreal being over a decade old and originally built back in the bad-old-days. The engine's code is messy. The engine's structure is inflexible and at times incomprehensible. Like most old, monolithic, feature-packed codebases, it's just a nightmare to work with unless you've already been knee-deep in for years. It's also not designed for making things besides shooters, and doesn't have flexibility in the places you want it if you're trying to make anything that's not a shooter.

One of the more depressing aspects of the engine -- which I presume has been curbed somewhat given its ports to mobile platforms -- is how its object model works. (Aside: That's a long discussion in itself; I'll point you to http://www.objectmentor.com/resource...offeeMaker.pdf and http://cowboyprogramming.com/2007/01...your-heirachy/, and then just note that Unreal, Source, and idTech all do the complete opposite of what those links suggest. CryTek is a hybrid.) In Unreal, the base game object class used to take up around 2 kilobytes of memory. Every character, dynamic object, hell even every single bullet. Why? Well, those bullets had code to support a shitload of features that never ever would make any sense to have on a bullet, but because inheritance was used and abused to implement design-side hierarchies of object types, the base game engine had to have the features that any game object might want to use. Like camera bobbing, for instance. Every bullet had data members (and methods) to support camera bob, among a billion other features that couldn't be slapped onto a specific game object subclass because you never know where or when someone might want to use it. The end result is that most serious large games you saw developed with Unreal spent the first 3-9 months literally just rewriting, hacking, slashing, and fixing a giant mess of a codebase that was really only ever meant to be used for Unreal Tournment.


Source is actually related to idTech, being forked from the Quake 2 engine iirc. I have never used it myself, but a number of developers I know -- including a few Valve employees -- have quite unflattering things to say about it. Valve, however, has a rather interesting coporate culture, one which does not prize or seek out people that could be considered "tech leads" in the traditional sense. The engine is very organic; if someone needs something, it gets hacked in, and then they move on. The pile of hacks and hardcoded game-logic gets left in, which is why you can find bits and piecesof Valve's past game's game logic in their newer games. The engine has a huge technical debt. If you want to build a new game on it, you had better get ready to dive into the guts and hack it together with duct-tape and prayers.


The idTech engines are made for simplistic shooters. They are also inflexible. They are old. They are built like early 1990's game engines. Also, nobody actually licenses them anymore. idTech4 was only used in about 8 games. 6 of those were id's own titles. Of the other two, one flopped commercially ("bad graphics and repetitive gameplay" being one of the bigger complaints) and the other got cancelled before release. idTech5 also currently has no announced licensees, I believe. The old engines are now FOSS and so seem "cheap" to use, but even a small skilled team of game programmers can (and should!) spend a few months rebuilding the base tech and give themselves more flexibility and efficiency further along in the development process.

It's very cool and all that id Open Sources their old engines. I love it. All games should do that, IMO. The tech is old, but still valuable for those who want to see gaming art and culture live on for ages to come, and id should keep doing it.


All that said, keep in mind that these engines obviously still all work. That any of them is a pain in the ass to work with is not the same as saying that they're unusable, though I do know I tend to speak in absolutes and I've probably come close to outright saying that a few times. Unreal gets the job done. Source obviously can be used for some awesome games. CryTek has things going on. idTech has been used for great games like Doom3^WPrey^WRAGE^WQuake3.


One of the things that really irritates me when a lot of non-developers talk about engines is how everyone fawns over graphical tech demos, like Unreal or Unigine or idTech. You can slap amazing graphics into _any_ game engine. You don't even need a game engine at all to do amazing graphics, which is why projects like OGRE can even exist in the first place (don't take that as a recommendation for OGRE; never used it myself, so I have no opinion on it, could be great or it could be horrible). Graphics is 80% art assets, 15% smoke and mirrors, and 5% insane math code that has nothing to do with anything else in the game engine. Don't judge an engine based on how good its content people are; judge an engine on how easy it was for those content people to make that amazing-looking game/demo.

When you ask, "what is a good game engine," the answer _should_ be something that makes it very easy for developers, artists, and designers to quickly build new and interesting games with a minimal of bullshit. That means that the engine should not require months of heavy tweaking to get slight variations of functionality in. That means that designers should not need to ask programmers to write new C++ code for new uses of behavior that already exists in the engine. That means that artists should not be forced to learn new misdesigned/incomplete tools built-in to the engine that sounded good on paper; it also means that if external tools are used, artists should not be required to go through a 10-minute export/import process to get asset tweaks into the engine. The really good game engines allow designers and game logic programmers to build large, highly diverse, innovative games with lots of content while requiring no changes at all to the core engine code for each project.

[entropy]

Great post, thanks!

When you ask, "what is a good game engine," the answer _should_ be something that makes it very easy for developers, artists, and designers to quickly build new and interesting games with a minimal of bullshit. That means that the engine should not require months of heavy tweaking to get slight variations of functionality in. That means that designers should not need to ask programmers to write new C++ code for new uses of behavior that already exists in the engine. That means that artists should not be forced to learn new misdesigned/incomplete tools built-in to the engine that sounded good on paper; it also means that if external tools are used, artists should not be required to go through a 10-minute export/import process to get asset tweaks into the engine. The really good game engines allow designers and game logic programmers to build large, highly diverse, innovative games with lots of content while requiring no changes at all to the core engine code for each project.

So in the end, if I got you right on the rest of your post, this engine doesn't exist yet by far?

[baffledmollusc]

Game engine summary snipped

Thanks elanthis; that was informative.