Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryengine Source Code

github.com

Post reply on HN
Print view View original

31–40 of 149 posts

Re: Cryengine Source Code

#31

Post by mhh__ »

gentleman11 wrote: post #19
Nican wrote: post #13

This is on the front page again. Please take some time to read this wonderful function: 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 (?)

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?

I feel like C++ makes it particularly difficult to jump around big projects (mainly headers especially back in the old days pre good-ide).

There is also a lot of fear of performance regressions by breaking up big chunks of code (arguably unfounded with modern compilers).

Re: Cryengine Source Code

#32

Post by dmitrygr »

Nican wrote: post #13

This is on the front page again. Please take some time to read this wonderful function: 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 (?)

> new/delete, with no RAII

There is nothing wrong with this. Plenty of people have no issues keeping track of memory in their head.

Re: Cryengine Source Code

#33

Post by gentleman11 »

oever wrote: post #28
smaddox wrote: post #24

Earlier quoted context omitted.

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.

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.

One of my professors used to encourage the heavy use of helper functions that just... well, like in A or B in carmacks article, break your code into chunks with clear names that can be unit tested.

How common is automated testing in AAA games?

Re: Cryengine Source Code

#34

Post by mhh__ »

Roritharr wrote: post #7
reykjavik wrote: post #2

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

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.

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)

Re: Cryengine Source Code

#35

Post by Nican »

stephc_int13 wrote: post #30
Nican wrote: post #13

This is on the front page again. Please take some time to read this wonderful function: 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 (?)

As a professional game developer I disagree with most of your comments. This code is clearly not perfect, but the from what I've seen, this is something I could work with. - Function names are easy to read and understand. - Indirections are kept to a manageable level.

Not going to lie, playing Crysis was a lot of fun, and I never knew this was the underneath function running it.

Re: Cryengine Source Code

#36

Post by mhh__ »

dman wrote: post #11
jokoon wrote: post #10

Earlier quoted context omitted.

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…

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.

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.

Re: Cryengine Source Code

#37

Post by gentleman11 »

dman wrote: post #11
jokoon wrote: post #10

Earlier quoted context omitted.

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…

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.

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

Re: Cryengine Source Code

#38

Post by barrkel »

Nican wrote: post #13

This is on the front page again. Please take some time to read this wonderful function: 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 (?)

If the code was separated out into functions that are only ever called once, I'd find it harder to read.

Analysing code I'm not familiar with often consists of manually tracing through calls, producing documentation that inlines all the single use function calls.

Ideally function names act as shorthand for the body of the function, but if they only have one caller they have nothing to keep them honest. In older codebases, function names are as misleading as comments; semantic drift, special cases etc. mean you need to drill into them anyway.

Re: Cryengine Source Code

#39

Post by mhh__ »

gentleman11 wrote: post #6

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.…

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)

Re: Cryengine Source Code

#40

Post by wwright »

Roritharr wrote: post #7
reykjavik wrote: post #2

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

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.

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.)

Post reply on HN