Hacker News Reader

Comment by fennecfoxen | Hacker News Reader

> their own private code framework that is too complicated for anyone else to make use of

Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. The real sadness is when you get corporate websites, technology platforms, and the like that decide they need their own framework to make their own set of tradeoffs, and do a mediocre job of it, and end up with a slow buggy bastardization with 15% of the capabilities of a common well-understood framework. If I had a dollar for every minute I wasted on something like that... it'd be an accurate description of a nontrivial portion of my career :b

Bonus points for making this framework to optimize performance, without actually measuring the performance or setting explicit goals.

View on HN

> Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed.

i feel like this is somehow perpetuated like folklore, but there shouldn't be any reason why game code should be inherently less reusable than other areas of software development. For example, code that deal with geometry data shouldn't really be any different for games, or code that deal with setting up a rendering environment ought to be the same for most, if not all games (i can't imagine initializing directx or opengl would be different for different games).

Game logic is one area that is going to change a lot between games. However, if you partitioned your game logic well, wouldn't it make the next game easier since you're "just" swapping game logic?

> code that deal with geometry data shouldn't really be any different for games

Counter-example: http://jonathanwhiting.com/games/knossu/ (Highly recommended if you have 20 minutes to spare.) The geometry of this game is unlike any I have seen so far. There is common logic with that of a Doom-like ray caster, but I'd argue not much. The time spent rewriting the generic parts of a ray caster probably pales in comparison to the specific parts of his graphics engine.

(Of course, your point stands in general. But for Jonathan Whiting in particular, I have the feeling that it may not.)

Great game, thank you!

That sort of code does get reused a lot, when games are built on third-party (or in-house) engines. But I don't think it would make sense to just consolidate all of it- engines make different tradeoffs on how geometry data is formatted, laid out, and processed, and that continues to be an area of optimization and innovation.

As far as initializing the hardware, that's a relatively small, one-off piece of code that's different for every platform (including consoles) anyway.

The framework level stuff is definitely reusable. Anything that involves rendering or collision touches on design decisions and thus impacts engine reuse. The off-the-shelf systems do conventional designs and workflows well, basically. But you go around them as soon as you want to explore in depth, no matter how big or configurable the engine is.

This leads to a situation where copy-paste at the start of the project may be the best way to reuse good stuff. Otherwise too many assumptions change. If you try to make it a parametric problem, you usually just find out you introduced accidental coupling later.

Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed.

Huh? I don't know what the numbers are but I'd hazard a guess that the majority of games out there (at least those written by more than one person) use a 3rd party commercial game engine.

I am relatively sure that we've lost the code reuse wars outright. The problem isn't Yet Another Framework. the problem is mediocrity itself.

Reply on news.ycombinator.com