Live data from Hacker News

Modern C++ gamedev: thoughts and misconceptions

vittorioromeo.info

131–140 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#131
post #114

Earlier quoted context omitted.

That's the thing though. Gamedevs aren't throwing shade, it's a strawman. Look at the twitter threas mentioned in the introduction and you'll see a bunch of civil gamedev industry veterans offering constructive criticism, only to be shut down with "that's misguided" and no counter argument. It gets old fast and it's been like this for dozens of years. I'm not surprised that they stop caring.

If you are making the point that Twitter arguments are counterproductive, I agree. I will concede all objections about tone because my life is too short to get dragged into Twitter tone policing. I do find the recommendations interesting and would like to keep the conversation about them. I would especially like to avoid gatekeeping and No True Scotsman arguments in a thread about code.

No, I did not make the point that Twitter arguments are counterproductive at all o the contrary this one looks very productive EXCEPT for the author.

So now you're straw manning me as well, then say I'm gatekeeping and no true-scotsmanning. I don't appreciate that all and am therefore out.

Re: Modern C++ gamedev: thoughts and misconceptions

#132
post #48

Earlier quoted context omitted.

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

"no abstract frills attached" I can't tell what you think a frill is, but I can't square that statement with the rest of your post, and with the OP. Higher-level constructs might require language features like template metaprogramming, or a level of indirection. There are a few ways in which you can have "the same sort of code".

A 'frill' in this case is any construct that is not obvious to a person a who has programmed a few years in the particular language. For example, this definitions makes most C++ templates used outside of STL-like usage very frillic.

"Higher-level constructs might require language features like template metaprogramming, or a level of indirection."

I think we have different definition what a "higher level" means. To me it means a particular pattern has been identified in the code and lifted to an implementation that needs less thinking and fewern lines of code.

You can have quite high level clever program logic using the basic algorithmic toolbox - the basic containers and large zoo of well known algorithms to operate on them - the array, the list, the map and the graph.

Re: Modern C++ gamedev: thoughts and misconceptions

#133
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…

Nobody thinks "I hate having simple code, I'm going to replace it with a complex one!"

It's always "ugh, this code is a copypasta convoluted mess. I'm going to replace it with a simple solution".

Re: Modern C++ gamedev: thoughts and misconceptions

#134
post #12
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 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.

There is always a middle ground as there are other native languages. In regards to C++ you can limit yourself to convenient feature set you are comfortable with.

C++ can be a real bitch and commit one to a mental institution or it can be very helpful if one does not try to play PhD.

I write servers and some other stuff in C++ and find it incredibly easy to use. I just do not do any esoteric things.

Re: Modern C++ gamedev: thoughts and misconceptions

#135
post #131

Earlier quoted context omitted.

If you are making the point that Twitter arguments are counterproductive, I agree. I will concede all objections about tone because my life is too short to get dragged into Twitter tone policing. I do find the recommendations interesting and would like to keep the conversation about them. I would especially like to avoid gatekeeping and No True Scotsman arguments in a thread about code.

No, I did not make the point that Twitter arguments are counterproductive at all o the contrary this one looks very productive EXCEPT for the author. So now you're straw manning me as well, then say I'm gatekeeping and no true-scotsmanning. I don't appreciate that all and am therefore out.

- winterismute questioned qualifications to have a position on writing C++ for game dev. That is gatekeeping and No True Scotsman.

- At least someone on Twitter called some tweets "retarded", etc., so OP thought to continue the conversation by ignoring nonsense and restating concerns in a healthier tone. This post is his attempt to be productive, apparently.

- Any perceived slight against you, you have inferred. No offense intended.

- Perhaps HN discussions are only marginally better than Twitter if people can't avoid making discussions about fold operators personally.

Re: Modern C++ gamedev: thoughts and misconceptions

#137

Earlier quoted context omitted.

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.

I sometimes see people stating exactly this, but then writing:

`doSomethingToACar(selectCarById(carId));`

Kind of weakens the argument. I'm not sure what's the best approach, but I'm usually ok with autos even when the type is not explicitly known - when reading code, I do not really need to know what exact type a variable has ("it's a car, goddamnit, it says so in the name!"), just how it's used (and then meaningful function names become very important).

Re: Modern C++ gamedev: thoughts and misconceptions

#138

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…

Could you please share the name of the game?

ROSE online

Re: Modern C++ gamedev: thoughts and misconceptions

#139
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…

That's not really giving the full picture of ROSE online!

- The official server (arcturus) is awful to work with code-wise. But all the decently big private servers uses it because at one point we only had the binaries of it and it worked out of the box. When the source started to leak too, it was easier to continue forward with that thing.

- The "simple version" which I am assuming you refer to is os(i)rose. This was the only thing you would get BEFORE the official server got leaked. It had some momentum simply for being there since roughly 2006. It was based on Brett19's code which at the time was a 14-something teenager. The same brett that now works on a fully modern C++ codebase that is decafemu.

- The Modern C++ version which if I remember is worked by few folks from osrose came out something like 2 years ago. Passing 2015, the momentum for the game is close to none. So yes, no one will even spin that codebase.

Re: Modern C++ gamedev: thoughts and misconceptions

#140
post #126

Earlier quoted context omitted.

Most people hate const at first (myself included) but once you get used to it, it really does reduces mental load. Not having to glance around is precisely the point, its not a big thing but it does help.

I stopped using it for locals after it increased my mental load. The maintenance cost of const for all local variables is huge during refactor like you're fighting it just to get things done. And in most cases where the type of a variable matters I do have to glance around like when I need to remove a variable or change its type or refactor its dependent variables so const doesn't really for those cases.

So you prioritise the writing of the code instead of the reading.

In that case, it makes sense.

Post reply on HN