37 ms·

Cryengine Source Code

212 points by TiccyRobby 6y ago

reykjavik 6y ago
Used to work with cryengine some time ago. That is by far the worst c++ codebase i've ever seen.
- deleted 6y ago
  [deleted]
- halotrope 6y ago
  While your opinion is appreciated. It would be more helpful, if you could point out sone of the reasons why it was so bad in particular.
- Roritharr 6y ago
  Interesting sentiment, I sometimes wonder if a "messy" codebase can have advantages for performance. Many very highly performance tuned applications I saw in the wild would fall into the category of "horrible codebase" when looked at through that lens.
  - nocturnial 6y ago
    It falls more in the category of having a lot bugs which could've been caught if they used static code analysis, code review, etc... I understand that you might think that messy could mean it's fine tuned for performance. In this case, I highly doubt it and think it's more reasonable to think it's messy because they had deadlines. The messy part isn't about performance optimizations. It's more about things that got crammed in there and only works for a very specific subset of parameters. And even then you can't be sure it'll work... I don't blame the programmers, it feels they had deadlines to uphold from managment.
    - gentleman11 6y ago
      What sorts of static code analysis tools do people here use in their game projects? I know carmack is a big fan of them
      - nocturnial 6y ago
        Here are the results for cry engine specifically: https://www.viva64.com/en/b/0417/ https://www.viva64.com/en/b/0417/ https://www.viva64.com/en/b/0495/ https://www.viva64.com/en/b/0495/ https://www.viva64.com/en/b/0574/ https://www.viva64.com/en/b/0574/ I'm not endorsing pvs studio nor am I saying it's bad. Try out some tools and see what works best for you.
        projektfu 6y ago
        It's funny because many of these are the exact possible errors you expect when someone is swimming in a large code block doing lots of copy and paste. Large blocks of code are very hard to test thoroughly, so I imagine the testing was mostly looking to see if things look right followed by play-testing.
      - gameswithgo 6y ago
        I have used the Rust compiler, which will catch all memory errors, data races, and null pointer exceptions and buffer overflows at compile time as a matter if course. then you can add cargo fuzz if you like.
    - noarchy 6y ago
      >I don't blame the programmers, it feels they had deadlines to uphold from managment. This is my own experience. The teams that spent the most time on standards usually had the least pressure, in terms of things like deadlines. Once the focus of the team shifts to having to ship things, there is less time to worry about having 100% code coverage (to pull out an arbitrary number), and so forth. Code review can slip into flagging only things that really matter, and leaving nitpicks for another day.
  - mhh__ 6y ago
    I don't think it's necessary. With modern C++ it's possible to encapsulate high performance code. The issue with games in particular is probably partly due to the performance optimizations being directed at a moving target (it's not just your supercomputer nodes, it's every computer CPU). C++ doesn't really help you much in that regard (or at least better know but certainly not 10 years ago)
  - wwright 6y ago
    Let’s assume that when code is first written, the cleanliness and performance is somewhat random within a broad range. If we want the code to be clean or performant, we will likely have to spend time iterating on and pruning the code. Let’s assume that improving performance and improving cleanliness are at best orthogonal, at worst opposing. The project has a limited amount of time, particularly for games, which often have a relatively low roof for how much maintenance the code will need. The project has a budget on time to spend between cleanliness and maintenance. Games need high performance and relatively little maintenance, so they are more likely to spend their budget on much more performance than cleanliness. (Game engines meant for heavy reuse such as Frostbite and Unreal Engine would likely have a much more even split, and similar for games which are likely to receive recurring and invasive updates. I would expect Fortnite’s code to be fairly clean as games go, for example.)
- jokoon 6y ago
  Generally, things that are not open source are rarely not well written, since there are less programmers who will read your code, and all questions on the code can be done internally, so developers only write code so it works. Open source generally leads to better quality code, since it's the best way to attract other developers to contribute to it. So I'm rarely interested by any accomplished project that opens its code. For example, if microsoft opened its OS, I doubt developers would really try to do things with it. The windows kernel would obviously be high quality code, but a lot of the rest is probably short lived garbage.
  - dman 6y ago
    I disagree with this line of reasoning. I have seen good/bad examples on either side. I think it actually comes down to someone on the developer team having a high set of standards that they push everyone to subscribe to.
    - mhh__ 6y ago
      It's only tangentially related to code quality but I do think open/free source is the only way to write sustainable software if your aim is to change the world rather than ones bank account (so to speak). There's terrible code all over the place, although it is definitely true that no one's going to clean up - even source available - proprietary code out of kindness of their heart.
    - gentleman11 6y ago
      All the open source projects I have personally seen were ones meant to live a long time. When there were code issues, there were always awkward discussions on github about “there should be unit tests here” or “this code makes no sense,” and weeks later the developer announcing a cleanup or some sort. Anecdotal but public scrutiny and pressure is a real thing. Just as an example, this is why Bitwarden started getting some automated testing - lots of propelled bumping github issues about it in order to get it more visibility
  - remram 6y ago
    > things that are not open source are rarely not well written I think you got lost in your triple negative there
misnome 6y ago
Would it be an overreaction to not want to touch this licence with a barge pole? Even ignoring the “We may change this licence at any time and it applies to you” parts, there seem to be serious restriction on usage and basically have to ask them to do _anything_ beforehand. Maybe it makes sense if you are already in a project that is using this Licenced? Is this intended as a general engine licence rather than viewing the source code?
- _bxg1 6y ago
  Unreal shares its source purely for the sake of people who already license it and need to know how something works/fix something/customize something. Wouldn't be surprised if the same is true here.
gentleman11 6y ago
I considered using cryengine recently but there was an almost total lack of learning resources: I could barely find a tutorial that was newer than 5 years, especially one that involved it’s c++ APIs. I suspect that lumberyards greatest advantage over cryengine in the future will simply be usable documentation provided by amazon. Cryengine is simply not usable without better docs or else an incredible amount of time. Crytek is having financial troubles but I bet their engine would have 10x adoption if they hired a team technical writers Unreals docs are fairly bad also, but at least there are some third party resources to turn to
- mhh__ 6y ago
  Unreal docs are fairly good for making games but if you want to modify the structure of the engine it's quite annoying/nonexistent. Case in point: Vehicle physics is no where near as good as the docs imply (not a toy but still 20 year old vintage), but there is almost no documentation of how PhysX interacts with the Unreal engine proper i.e. you can get the PxRigidWhatever handle but you can't easily replace PhysX with a proper MB package. Epic seem to be transitioning to Chaos but it's not documented yet. If I ever get good Vehicle physics working I'll write it up (it's definitely possible but I'm not sure how ACC does it)
  - djmips 6y ago
    People customizing the UE4 engine professionally or on large projects put a lot of work into the areas they are interested to the point where it's not really UE4 anymore in that area. Gears of War is a good example where areas of the rendering system would be almost unrecognizable as they have put in countless man years of work diverging from the base engine.
    - mhh__ 6y ago
      I'm sure it's possible I'd just rather not read thousands of lines of code to find the nitty gritty. I want to make the basics of an open source (sim)racing game (as a test bed for writing tyre models), without using the fairly lacklustre offerings included by default (e.g. no sprung mass, no carcass stiffness etc., idealized suspension etc.). I have no need to go into the bowels of the rendering engine but it struck me that the interactions between PhysX and the actual actor model for the vehicle is almost not documented at all. I assume it's possible to do it solely with PhysX (proper suspension) but I cannot find any case studies of people doing it with the possible exception of their drive project which is under $$$ and NDA I'm guessing. I was also slightly surprised that I had to go looking for the option to connect to the PhysX debugger. It wasn't hard to find but I was half expecting it to be included with the engine.
zamalek 6y ago
That license looks like a minefield. Any lawyers able to chime in on the reality of becoming tainted? Given their recent history, this is one codebase you really wouldn't want to risk becoming tainted by.
- gear54rus 6y ago
  What is their recent history?
  - zamalek 6y ago
    Crytek v. Cig, which the court ruled largely in favor of Cig, and even called out Crytek's behavior (which was an absolute circus). Crytek will prosecute given even the most questionable grounds. The consequences of taint are a very real risk here.
ebg13 6y ago
Many of the filed issues are "X not work" and not very interesting, but this one...this one is a real gem. https://github.com/CRYTEK/CRYENGINE/issues/763 https://github.com/CRYTEK/CRYENGINE/issues/763
- duncan-donuts 6y ago
  I’m gonna go with this is a feature not a bug
Nican 6y ago
This is on the front page again. Please take some time to read this wonderful function: https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1300 https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEng... EDIT: That whole function is a minefield. Just taking a quick look: * 814 lines of code * goto inside 3 nested for-loops * macros * commented out code * new/delete, with no RAII * thread specific variables and locks (?)
- deleted 6y ago
  [deleted]
- gentleman11 6y ago
  800 lines long. The movement component class in ue4 is about 10k lines. Why do game engines separate their code so much less than in other software?
  - Trasmatta 6y ago
    Here's a good article from John Carmack on why that can be a good approach in game development: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... I feel like this Cryengine example may be a bad example of that, though.
    - deleted 6y ago
      [deleted]
    - smaddox 6y ago
      Not just in game development. If you have a function that is only called once, it shouldn't be a function yet. Make it a function when you have a second or third use for it. Then, and only then, you will know what the parameters should be.
      - oever 6y ago
        I disagree. Splitting a function up can help with readability and testability. The parent function becomes shorter and the child function can have a descriptive name. The parameters to a function are the fields that are needed for the function to perform its function.
rurban 6y ago
The real issue is clear from their announcement post. master (now main) was not always stable (of course, stable code are in the stable and release branches) so silly people complained, and the silly PM reacted by closing down pushes to main, and hereby closing down issues and PR's. He clearly has no idea how open source code development works. Now they have to maintain two repos, the internal one and thd public one, and get no feedback from outside. Well, feedback on one year old code.
dang 6y ago
If curious see also from 2016: https://news.ycombinator.com/item?id=11760298 https://news.ycombinator.com/item?id=11760298 Related significant threads: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Cryengine%20comments%3E10&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

212 points by TiccyRobby 6y ago

reykjavik 6y ago

Used to work with cryengine some time ago. That is by far the worst c++ codebase i've ever seen.

deleted 6y ago
[deleted]
halotrope 6y ago
While your opinion is appreciated. It would be more helpful, if you could point out sone of the reasons why it was so bad in particular.
Roritharr 6y ago
Interesting sentiment, I sometimes wonder if a "messy" codebase can have advantages for performance. Many very highly performance tuned applications I saw in the wild would fall into the category of "horrible codebase" when looked at through that lens.
- nocturnial 6y ago
  It falls more in the category of having a lot bugs which could've been caught if they used static code analysis, code review, etc... I understand that you might think that messy could mean it's fine tuned for performance. In this case, I highly doubt it and think it's more reasonable to think it's messy because they had deadlines. The messy part isn't about performance optimizations. It's more about things that got crammed in there and only works for a very specific subset of parameters. And even then you can't be sure it'll work... I don't blame the programmers, it feels they had deadlines to uphold from managment.
  - gentleman11 6y ago
    What sorts of static code analysis tools do people here use in their game projects? I know carmack is a big fan of them
    - nocturnial 6y ago
      Here are the results for cry engine specifically: https://www.viva64.com/en/b/0417/ https://www.viva64.com/en/b/0417/ https://www.viva64.com/en/b/0495/ https://www.viva64.com/en/b/0495/ https://www.viva64.com/en/b/0574/ https://www.viva64.com/en/b/0574/ I'm not endorsing pvs studio nor am I saying it's bad. Try out some tools and see what works best for you.
      - projektfu 6y ago
        It's funny because many of these are the exact possible errors you expect when someone is swimming in a large code block doing lots of copy and paste. Large blocks of code are very hard to test thoroughly, so I imagine the testing was mostly looking to see if things look right followed by play-testing.
    - gameswithgo 6y ago
      I have used the Rust compiler, which will catch all memory errors, data races, and null pointer exceptions and buffer overflows at compile time as a matter if course. then you can add cargo fuzz if you like.
  - noarchy 6y ago
    >I don't blame the programmers, it feels they had deadlines to uphold from managment. This is my own experience. The teams that spent the most time on standards usually had the least pressure, in terms of things like deadlines. Once the focus of the team shifts to having to ship things, there is less time to worry about having 100% code coverage (to pull out an arbitrary number), and so forth. Code review can slip into flagging only things that really matter, and leaving nitpicks for another day.
- mhh__ 6y ago
  I don't think it's necessary. With modern C++ it's possible to encapsulate high performance code. The issue with games in particular is probably partly due to the performance optimizations being directed at a moving target (it's not just your supercomputer nodes, it's every computer CPU). C++ doesn't really help you much in that regard (or at least better know but certainly not 10 years ago)
- wwright 6y ago
  Let’s assume that when code is first written, the cleanliness and performance is somewhat random within a broad range. If we want the code to be clean or performant, we will likely have to spend time iterating on and pruning the code. Let’s assume that improving performance and improving cleanliness are at best orthogonal, at worst opposing. The project has a limited amount of time, particularly for games, which often have a relatively low roof for how much maintenance the code will need. The project has a budget on time to spend between cleanliness and maintenance. Games need high performance and relatively little maintenance, so they are more likely to spend their budget on much more performance than cleanliness. (Game engines meant for heavy reuse such as Frostbite and Unreal Engine would likely have a much more even split, and similar for games which are likely to receive recurring and invasive updates. I would expect Fortnite’s code to be fairly clean as games go, for example.)
jokoon 6y ago
Generally, things that are not open source are rarely not well written, since there are less programmers who will read your code, and all questions on the code can be done internally, so developers only write code so it works. Open source generally leads to better quality code, since it's the best way to attract other developers to contribute to it. So I'm rarely interested by any accomplished project that opens its code. For example, if microsoft opened its OS, I doubt developers would really try to do things with it. The windows kernel would obviously be high quality code, but a lot of the rest is probably short lived garbage.
- dman 6y ago
  I disagree with this line of reasoning. I have seen good/bad examples on either side. I think it actually comes down to someone on the developer team having a high set of standards that they push everyone to subscribe to.
  - mhh__ 6y ago
    It's only tangentially related to code quality but I do think open/free source is the only way to write sustainable software if your aim is to change the world rather than ones bank account (so to speak). There's terrible code all over the place, although it is definitely true that no one's going to clean up - even source available - proprietary code out of kindness of their heart.
  - gentleman11 6y ago
    All the open source projects I have personally seen were ones meant to live a long time. When there were code issues, there were always awkward discussions on github about “there should be unit tests here” or “this code makes no sense,” and weeks later the developer announcing a cleanup or some sort. Anecdotal but public scrutiny and pressure is a real thing. Just as an example, this is why Bitwarden started getting some automated testing - lots of propelled bumping github issues about it in order to get it more visibility
- remram 6y ago
  > things that are not open source are rarely not well written I think you got lost in your triple negative there

misnome 6y ago

Would it be an overreaction to not want to touch this licence with a barge pole? Even ignoring the “We may change this licence at any time and it applies to you” parts, there seem to be serious restriction on usage and basically have to ask them to do _anything_ beforehand. Maybe it makes sense if you are already in a project that is using this Licenced? Is this intended as a general engine licence rather than viewing the source code?

_bxg1 6y ago
Unreal shares its source purely for the sake of people who already license it and need to know how something works/fix something/customize something. Wouldn't be surprised if the same is true here.

gentleman11 6y ago

I considered using cryengine recently but there was an almost total lack of learning resources: I could barely find a tutorial that was newer than 5 years, especially one that involved it’s c++ APIs. I suspect that lumberyards greatest advantage over cryengine in the future will simply be usable documentation provided by amazon. Cryengine is simply not usable without better docs or else an incredible amount of time. Crytek is having financial troubles but I bet their engine would have 10x adoption if they hired a team technical writers Unreals docs are fairly bad also, but at least there are some third party resources to turn to

mhh__ 6y ago
Unreal docs are fairly good for making games but if you want to modify the structure of the engine it's quite annoying/nonexistent. Case in point: Vehicle physics is no where near as good as the docs imply (not a toy but still 20 year old vintage), but there is almost no documentation of how PhysX interacts with the Unreal engine proper i.e. you can get the PxRigidWhatever handle but you can't easily replace PhysX with a proper MB package. Epic seem to be transitioning to Chaos but it's not documented yet. If I ever get good Vehicle physics working I'll write it up (it's definitely possible but I'm not sure how ACC does it)
- djmips 6y ago
  People customizing the UE4 engine professionally or on large projects put a lot of work into the areas they are interested to the point where it's not really UE4 anymore in that area. Gears of War is a good example where areas of the rendering system would be almost unrecognizable as they have put in countless man years of work diverging from the base engine.
  - mhh__ 6y ago
    I'm sure it's possible I'd just rather not read thousands of lines of code to find the nitty gritty. I want to make the basics of an open source (sim)racing game (as a test bed for writing tyre models), without using the fairly lacklustre offerings included by default (e.g. no sprung mass, no carcass stiffness etc., idealized suspension etc.). I have no need to go into the bowels of the rendering engine but it struck me that the interactions between PhysX and the actual actor model for the vehicle is almost not documented at all. I assume it's possible to do it solely with PhysX (proper suspension) but I cannot find any case studies of people doing it with the possible exception of their drive project which is under $$$ and NDA I'm guessing. I was also slightly surprised that I had to go looking for the option to connect to the PhysX debugger. It wasn't hard to find but I was half expecting it to be included with the engine.

zamalek 6y ago

That license looks like a minefield. Any lawyers able to chime in on the reality of becoming tainted? Given their recent history, this is one codebase you really wouldn't want to risk becoming tainted by.

gear54rus 6y ago
What is their recent history?
- zamalek 6y ago
  Crytek v. Cig, which the court ruled largely in favor of Cig, and even called out Crytek's behavior (which was an absolute circus). Crytek will prosecute given even the most questionable grounds. The consequences of taint are a very real risk here.

ebg13 6y ago

Many of the filed issues are "X not work" and not very interesting, but this one...this one is a real gem. https://github.com/CRYTEK/CRYENGINE/issues/763 https://github.com/CRYTEK/CRYENGINE/issues/763

duncan-donuts 6y ago
I’m gonna go with this is a feature not a bug

Nican 6y ago

This is on the front page again. Please take some time to read this wonderful function: https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1300 https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEng... EDIT: That whole function is a minefield. Just taking a quick look: * 814 lines of code * goto inside 3 nested for-loops * macros * commented out code * new/delete, with no RAII * thread specific variables and locks (?)

deleted 6y ago
[deleted]
gentleman11 6y ago
800 lines long. The movement component class in ue4 is about 10k lines. Why do game engines separate their code so much less than in other software?
- Trasmatta 6y ago
  Here's a good article from John Carmack on why that can be a good approach in game development: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... I feel like this Cryengine example may be a bad example of that, though.
  - deleted 6y ago
    [deleted]
  - smaddox 6y ago
    Not just in game development. If you have a function that is only called once, it shouldn't be a function yet. Make it a function when you have a second or third use for it. Then, and only then, you will know what the parameters should be.
    - oever 6y ago
      I disagree. Splitting a function up can help with readability and testability. The parent function becomes shorter and the child function can have a descriptive name. The parameters to a function are the fields that are needed for the function to perform its function.

rurban 6y ago

The real issue is clear from their announcement post. master (now main) was not always stable (of course, stable code are in the stable and release branches) so silly people complained, and the silly PM reacted by closing down pushes to main, and hereby closing down issues and PR's. He clearly has no idea how open source code development works. Now they have to maintain two repos, the internal one and thd public one, and get no feedback from outside. Well, feedback on one year old code.

dang 6y ago

If curious see also from 2016: https://news.ycombinator.com/item?id=11760298 https://news.ycombinator.com/item?id=11760298 Related significant threads: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Cryengine%20comments%3E10&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...