Hacker News Reader

Hacker News

Comment by sacnoradhq | Hacker News Reader

Parent Full thread

sacnoradhq

Let's see how many antipatterns:

- Multiple inheritance

- Over-abstraction

- Excessive identifier prefixing and suffixing

- Use of friend

- Use of bit fields instead of bools

- Inconsistent mixture of custom and built-in int types

- Direct storage of pointers instead of reference-counted containers

- Custom (and likely broken) _smart_ptr

- Cancerous coding style that adds too many lines

- Functions with 7+ arguments

- Lots and lots of duplicated code

- Inadequate use of const

- Inconsistent coding styles

- class name and base classes at the same indentation level

- Redundant prefixing of directories ~~and namespaces~~ with the name of the project

Edit: My bad, they don't use namespacing at all. It's a flat namespace. At least they don't using namespace std.

View on HN

Sounds like a real world project that focused on shipping a good game rather than have perfect code.

There is a reason perfectionist devs do not run big projects. They focus on minutiae rather than the big picture.

Even in my own experiences, one of my most successful projects (eventually acquired by Amazon) was a quickly written hacked together project that solved a big issue well. Over time it became better engineered but it taught me successful projects are about market fit, not code quality, especially super minor things like antipatterns.

Or maybe, just maybe, 'good practices' simply changed over the span of literally 20 years?

Naah, it must simply be those 'perfection vs practicality' dichotomy again.

...Not to mention that your point is the definition of survivor ship bias. Maybe the devs actually were super mad at themselves how the codebase looked cause it slowed down their development. Maybe they initially had 3 more times the ammount of anti-patterns, but they reduced them. Or maybe that's how their roll, but the fact that this code shipped is almost insignificant when it comes to judging its quality. We could spin infinite ammount of examples where bad code works, where good code fails, where bad code fails and were good code works. How about we actually talk about arguments instead, though?

I don't really think good practices changed that significantly in the last 20 years. Good practices must be seen like guidelines, not a strict dogma. They are mostly for the benefit or other humans to read and modify it without introducing (many) bugs. So, it's always a balance between the time you can reasonably imagine that code base will still be relevant, the number of people changing it, how much harder certain bending of the guidelines make it to change the code in future, etc.

About half of those are because of "performance", which in game engines is more important than future-proofing for maintenance that will likely never occur.

And it still was very successful as a game. I think this is a great example of "perfect is the enemy of good", especially for game development.

Makes me think I shouldn't care as much about perfect code and best practices and focus more about actually shipping things.

It matters 17 years later if you’re still in the same code base.

Best practices evolve. This code base predates modern smart pointers, and from experience bit fields were a requirement on some of those... tougher platforms.

It was a little bit tongue in cheek. But I'm currently in a code base that is almost exactly 10 years old. And of course all of the developers have personally grown in that time. But some of the practices were dependent on the technology choices available at the time.

Bit fields saved me an immense amount of pain when packing together state variables for a renderer, so I wouldn't write them off as being bad myself.

> - Direct storage of pointers instead of reference-counted containers

Overuse of reference counting is an anti-pattern and a performance killer.

Half of listed antipatterns are completely valid strategies in some situations.

Have you shipped many game engines?

Pretty much everything you mentioned is also in Unreal Engine and they affected it so much that companies left and right throw away their own engines to switch to it. My favorite part of UE5 is that its "base of all classes" object class (UObject) has its own base object class (UObjectBase).

Actually not just UE, but almost everything you mentioned was in every single engine i worked on (to be clear these were all engines that started long before i worked on them and designed by completely different people). With a single exception they were all used to release well received AAA games.

None of that stuff actually matter at all in practice.

If anything, this is a perfect example of how little these things actually matter in the real world. This game alone sold over 2.5 million units and kickstarted one of the most popular franchises in gaming today.

I always have a feeling this type of comment must be necessarily written by someone who hasn't shipped anything of substance in the industry. It's trivial to point out irrelevant minutiae like this as opposed to having an in-depth discussion about the merits of the terrain rendering system or, you know, literally any of the hard problems the game is solving and that actually contribute to making it a technical success.

Who cares? Clearly the gamers, reviewers, etc don't care.

Only pontificating armchair field marshals giving their take of 'anti-patterns' in game engines built decades ago.

That game made millions. Went on to release multiple sequels after the first and still made millions.

Is your game engine making millions?

Nothing wrong with bitfields.

How did this negatively affect the project?

Don't do that unless you want a random commenter shitting on the code you wrote 20 years ago when it finally leaks it.

Good today is better than perfect tomorrow.

People who work on such projects tend to focus on finding solutions to difficult problems and many things that you would consider weird or bad could be there because they were part of a solution, either at the time or sometime in the past in a previous project.

It's weird to criticize all this stuff considering modern dev companies often have teams like 'billing' that have more people in them than the dozen or so developers who have built the entire video game (plus editor) from the ground up.

Reply on news.ycombinator.com