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

Modern C++ gamedev: thoughts and misconceptions

vittorioromeo.info

Post reply on HN
Print view View original

41–50 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#41

Post by throwaway8941 »

lazypenguin wrote: post #15
PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

Matches my experience as well in the hobby gamedev realm. I can give an anecdote, I’m involved in a “private server” dev community for an old niche MMO from 2003. There exists 3 codebases: first the original code written in a windows-style C++ with heavy use of inheritance, custom collections, Hungarian notation, etc. The second is a collaborative open source version that is written in a naive/basic C++ style (e.g. c…

Could you please share the name of the game?

Re: Modern C++ gamedev: thoughts and misconceptions

#42

Post by vbezhenar »

PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

I agree wholeheartedly. I spent so much time needlessly trying to be smart.

Re: Modern C++ gamedev: thoughts and misconceptions

#43

Post by Koshkin »

gordaco wrote: post #32
deepaksurti wrote: post #23

Earlier quoted context omitted.

> Not always, though. See every bug and exploit with C arrays ... That can also be perceived as a a flaw of the language design in that it does not allow one to write dumb, safe and fast code. Which are such languages in existence today? edit: fixed typos

I would say Java, which I suspect is bound to be a bit of an unpopular opinion here (I expect more startup people than enterprise denizens in HN); but the more I think about it, the more sure I'm that it fits the bill: - Dumb: you bet. The inclusion of lambdas has shaken things a little, but usually Java code is straightforward with little space for "cleverness". The counterpoint to this, of course, would be the meme…

Indeed, despite all criticisms Java as a technology is one of the best things that has happened to the software industry, next to Linux.

Re: Modern C++ gamedev: thoughts and misconceptions

#44

Post by [deleted] »

microtherion wrote: post #27
lazypenguin wrote: post #15

Earlier quoted context omitted.

Matches my experience as well in the hobby gamedev realm. I can give an anecdote, I’m involved in a “private server” dev community for an old niche MMO from 2003. There exists 3 codebases: first the original code written in a windows-style C++ with heavy use of inheritance, custom collections, Hungarian notation, etc. The second is a collaborative open source version that is written in a naive/basic C++ style (e.g. c…

So, naive code attracts naive programmers? I'm not sure this is the ringing endorsement you take it to be. I should also add that Hungarian notation is the prototypical example of dumb, verbose code, that wants to make individual lines easier to understand by dragging type information into every single variable name.

[deleted]

Re: Modern C++ gamedev: thoughts and misconceptions

#45

Post by klodolph »

PezzaDev wrote: post #36
microtherion wrote: post #26

Earlier quoted context omitted.

> Make your code simple, dumb and verbose all the time This is a frequently encountered argument, and sure, if you look at any single line , it looks very obvious what it does. But I would argue that verbosity and lack of abstraction has severe drawbacks for a programmer's ability to understand the overall codebase , and it is disastrous for long term maintainability. You start out with 20 identical pieces of boilerp…

No coding approach will ever solve an issue caused by a lack of discipline.

I no longer think that saying is helpful.

The problem is that every problem is caused by a multitude of causes, and there’s usually no clear way to distinguish issues caused by lack of discipline from issues caused by the wrong coding approach or style.

Different styles make different demands on how disciplined a programmer must be in order to write correct code. My experience in well-managed large code base with decent-size teams is that the recommended approaches and coding styles will evolve to address problems that could be solved by asking programmers to be more disciplined.

So that’s the problem with saying “no coding approach will ever solve an issue caused by lack of discipline”—it only makes sense if you already have a good idea of which issues are caused by a lack of discipline, and if you already understand that, then the saying doesn’t help you. The key insight here is to understand when changing your coding approach may allow you to write correct code with less effort (and discipline). But this can’t be distilled into an aphorism, so it won’t get quoted.

An example is holding a lock to access a certain field. If you’re “disciplined” you can just leave a comment on the field that lock X must be held to access it. But in practice, you want to solve that with code analysis. Another issue is using scoped locks so early returns don’t screw you. You can easily argue that these issues aren’t caused by lack of discipline—but if you travel back in time 20 years or so, “discipline” might be the only tool you have to solve them.

Re: Modern C++ gamedev: thoughts and misconceptions

#46

Post by Koshkin »

PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

The tool is only as good as the one who uses it.

Re: Modern C++ gamedev: thoughts and misconceptions

#47

Post by leni536 »

I feel that most of the problems with debuggability is tooling (still). No, I do not want to debug the standard library most of the time, please let me optimize that, while I keep my part unoptimized.

Hopefully modules will allow mixed optimization levels for template headers.

Metaprogramming also lacks a good debugging story, but I would be happy to be proven wrong.

In my opinion these are not language problems, but tooling problems.

Re: Modern C++ gamedev: thoughts and misconceptions

#48

Post by fsloth »

microtherion wrote: post #26
PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

> Make your code simple, dumb and verbose all the time This is a frequently encountered argument, and sure, if you look at any single line , it looks very obvious what it does. But I would argue that verbosity and lack of abstraction has severe drawbacks for a programmer's ability to understand the overall codebase , and it is disastrous for long term maintainability. You start out with 20 identical pieces of boilerp…

I think you confuse simplicity with overt verbosity.

There is no reason simple code can't have higher-level constructs. The interface to them is just likely very domain specific, and you don't start with them.

But after you notice you are copying the same sort of code to a third place, you usually notice a pattern, extract that pattern (with no abstract frills attached) to a unique implementation that can be used everywhere, and move along.

Re: Modern C++ gamedev: thoughts and misconceptions

#49

Post by vbezhenar »

KallDrexx wrote: post #39
badsectoracula wrote: post #31

Earlier quoted context omitted.

I've worked on a bunch of engines, both big AAA and small indie scaled ones and i agree with you. It is actually from this experience that i have a hard dislike for C++'s "auto" outside of cases where you can't do otherwise - it makes the code you didn't write hard to understand exactly what is going on (and sometimes error prone). Sure IDEs can show you the type if you mouse over (at least some of them), but if the…

I wonder how wide spread dislike of "auto" is in c++ (I've seen that a few places) when the equivalent type inference has become fairly standard and preferred in other languages like C#, Rust, Go, etc...

With Java I've seen coding standards that you can use `var` only when type is obvious from declaration. For example:

    var person = new Person();
    var car = selectCarById(carId); // Car
if type is not obvious, it should be explicitly declared.

Re: Modern C++ gamedev: thoughts and misconceptions

#50

Post by yahyaheee »

PezzaDev wrote: post #17
pansa2 wrote: post #12

Earlier quoted context omitted.

> I find that the dumbest code is the best code. This is the idea behind Golang, isn’t it? That everything should be written out explicitly and not hidden behind abstractions. Some people love that, others hate it.

I'd love to try Golang, but as a game developer, the gc makes it a no go due to perf. I begrudgingly accept C# due to unity. GC is a different topic altogether, but has also always been a pain. You end writing code to avoid allocations, which at that point you ask "Why am I not just writing C++?" I also discovered GC makes bad programmers worse by allowing them not to care about ownership, enabling them to develop sy…

Not to mention acceleration is an issue with the go/c ffi
Post reply on HN