Show HN: The DNA of DOOM – How code structure survives across 44 ports

Copy is written by Claude. No thanks

At a glance the analysis seems like it could be interesting, but digging in, I'm struggling with the article.

First of all, I can only take so many "the hard case", "the fun part" and "the real test" before you've exhausted my attention to what these phrasings suggest are exceptionally interesting things.

Second,

> Scramble the Go program's wiring, keeping how many calls each function makes, and it drops to 39%: the wiring itself carries much of the signal.

What wiring? What signal? The rest of the article refers frequently to these completely useless analogies without ever clarifying what they mean. After scratching my head over it for a while I'm only guessing that the "wiring" refers to function names and "signal" to their bodies? Why not refer to these very basic, simple concepts as they are? I could understand coming up with analogies (good ones though, not awful ones like these) if you were writing for a non-technical audience, but you're not.

> Across languages only the wiring carries a signal, and only for the closer translations.

WTF does this even mean?

> he Scheme and Go translations keep the original's wiring as far above chance as Chocolate Doom does. The Dart translation keeps some. The Fortran, Java, Kotlin and C# translations keep none, and programs written from scratch, or not related to DOOM at all, sit at chance, as they should. Don't take our word for it: draw the maps yourself.

Sit at chance? Why shouldn't I trust your word for it if I can trust your diagrams?

Please, if you want me to think something is interesting, the least convincing thing you can do is to offload writing about it to whatever trite generator shat this out.

It would be nice to have a measure of how much a function changed. A change can be meaningful yet leave the overall shape of a function unchanged. Fixing a slightly off calculation or a corner case, adding a case for a new feature...

DOOM draws very little. An entire level is 3000-5000 polygons and on the screen, it rarely draws more than 1500 (polygon based ports)

Whatever it's architecture is, porting in is trivial because it's not a hard problem.

It's a great game and its geneious is undeniable. But porting a 1993 game is not really going to tell you anything interesting about "How code structure survives across 44 ports".

... I think this is a fun experiment.

And, I like the article, once I got through the 'jolt'. (Not gonna call it slop, I can tell it a good amount of effort on your part to make it present the data well.)

I love Doom, and I love the genealogy of it; dealing with doom modding and dehacked was probably my first foray into any sort of concept of 'programming' (after all, you could do some curious things with dehacked, as far as 'next frame' and how that sometimes could change things in curious ways)

I think, to give some constructive feedback;

1. Consider taking a markdown/output from analysis and writing your own starting scaffold.

2. Make sure to review the output and tweak it.

3. Hand refine what the end result is.

I'm not saying you shouldn't use AI to help with some of this, I'm just saying, that will help so much more. Cause this is really cool, but yeah it would be nice to have more polish around it.

Interesting project. Out of curiosity, have you done more work studying the engine, eg, an architecture breakdown or programming pattern analysis?

> …survives…

Slop.

[flagged]

Author here. Fair hits on the writing; I leaned on an LLM too heavily for the prose. The data and method are mine, and they're all in the repo. Happy to answer questions about how the extraction works.

[flagged]