Live data from Hacker News

Cryengine Source Code

github.com

21–30 of 149 posts

Re: Cryengine Source Code

#21
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?

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

I feel like this Cryengine example may be a bad example of that, though.

Re: Cryengine Source Code

#22

Earlier quoted context omitted.

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?

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.htm... I feel like this Cryengine example may be a bad example of that, though.

[deleted]

Re: Cryengine Source Code

#23
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?

Sometimes with inherently complex performance code it gets nickel and dimed over time yet maintains so many cross-cutting concerns and state that there are no clean extraction points.

So function extraction ends up taking a bunch of "unrelated" state with it where, in the end, it feels like you accomplished nothing but split the code into arbitrary concatenation points, not logical units.

Re: Cryengine Source Code

#24

Earlier quoted context omitted.

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?

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.htm... I feel like this Cryengine example may be a bad example of that, though.

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.

Re: Cryengine Source Code

#25
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 (?)

Is it an example of bad code? Should we avoid using Cryengine?

Re: Cryengine Source Code

#26
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 (?)

Is it an example of bad code? Should we avoid using Cryengine?

If it works, it's an example of ugly code. Plenty of game code is ugly as sin, though.

Re: Cryengine Source Code

#27
post #26

Earlier quoted context omitted.

Is it an example of bad code? Should we avoid using Cryengine?

If it works, it's an example of ugly code. Plenty of game code is ugly as sin, though.

The code for VVVVVV infamously has switch/case for every possible screen/level in the game[0], which I think is hilarious. Best example of "it works!"

[0] https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-cod...

Re: Cryengine Source Code

#28
post #24

Earlier quoted context omitted.

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.htm... I feel like this Cryengine example may be a bad example of that, though.

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.

Re: Cryengine Source Code

#29
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?

Games are certainly the most popular piece of end user software.

Software that a lot of people use a lot of time looks like this because the bugs are found and the bugs get fixed. The code for fixing a bug has to live somewhere.

What about bugs that computers find? Fuzzers are rarely recommending to fix bugs that are affecting human users. Part of that is also that the kinds of bugs that computers can find are not in, literally, "user interfaces," they are in APIs and formats.

Anyway, end user business software also has code that looks like this. It's not just all tools and infrastructure, I mean it certainly feels that way. But there are 800+ line SQL statements. 800+ line transactional method bodies. I don't want to call this "real code" but the surprise comes from... well eventually you have to make something the end user touches. And it's going to be gnarly.

Re: Cryengine Source Code

#30
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.

Post reply on HN