ソフトウェアプロジェクトの系譜を特定することは、開発者が頻繁に関数名を変更したり、ロジックを書き換えたり、あるいは全く異なるプログラミング言語に移植したりするため、しばしば困難を伴います。これらの系譜を追跡する従来の手法は、ソーステキストや関数名の照合に依存することが多いです。しかし、オリジナルのDOOMソースコードから派生した43の作品を調査した研究では、これらのラベルが誤解を招く可能性があることが示されました。例えば、「Chocolate Doom」はオリジナルの関数名の87%を保持していますが、それらの関数内部の実際のコードのうち変更されていないのはわずか35%です。また、「Doom Retro」のようなケースでは、名前は維持されているものの、内部コードのほぼ100%が書き換えられています。
人間が読めるテキストの限界を克服するために、研究者たちは名前やコメントを完全に無視するコード測定エンジンを使用しました。代わりに、このエンジンは、各関数の長さ、分岐パターン、および他のどの関数を呼び出すかを含む数十の測定値を記録することで、プログラムの「形状」を分析します。測定値が偶然とは思えないほど酷似している「似たような」関数を特定することで、このエンジンは93%の精度でコピーを識別できます。この構造的な指紋は、DOOMを、DOOMの形状を0%から0.6%しか共有していないQuakeやQuake IIといった無関係なCプログラムから区別するのに十分な堅牢性を備えています。
この画像は、異なるバージョンや移植を跨いで生き残るプログラムの「形状」または構造的指紋の概念を説明している。
プロジェクトがGoやSchemeなどの新しい言語で完全に書き換えられた場合、個々の関数の形状は消失する可能性がありますが、どのゲームサブシステム（レンダラーや物理演算など）が互いを呼び出すかという「配線」——マップ——は、多くの場合生き残ります。すべての名前を隠したブラインドテストにおいて、Goへの翻訳版は依然として関数の60%を正しいゲームパーツに分類することができ、ランダムな推測の20%を大幅に上回りました。しかし、この構造的な設計図は普遍的なものではありません。Java、Kotlin、C#などの言語による移植では、コードが非常に小さく断片化されたピース（多くの場合3行以下）に再構成されたため、元の設計のシグネチャーが事実上消去され、系譜を検出することができませんでした。これは重要なトレードオフを浮き彫りにしています。構造分析はほとんどの移植において系譜を追跡できる一方で、翻訳プロセス中にアーキテクチャの「形状」が根本的に解体された場合には機能しないのです。