如果游戏是 1995 年的，可以肯定的是文件格式特定于该游戏和制作它的游戏工作室。那时还没有像 Unity 这样的游戏引擎；工作室用 C 语言编写他们的软件，也许是 C++，并发明了他们自己的文件和打包程序。

所以，“真实”的文件格式就是你所看到的；并且用于创建文件的软件很可能是专门为这个游戏编写的，并且已经失传很久了，尤其是如果游戏是废弃软件，这可能意味着它背后的公司在某个时候倒闭了。所以，现在不要指望能找到任何可以直接读取文件的软件。

你也许能够做的是了解如何在内部文件都挤在一起，写一些C / Perl的/ Python的/ ...代码提取什么.TXT，.3DW和.SPR内容，尝试之类的软件file以及trid如果这些内容都是一些通用的格式（可能性不大但至少并非不可能），然后在十六进制编辑器中分析这些单个文件以找到它们的结构。但是，正如malikcjm所说，除非您反汇编游戏二进制文件以检查游戏本身如何读取它们，从中导出文件格式，然后自己编写一些代码进行转换，否则您很可能无法读取文件那种格式到现代的东西。

如果可以，您可以尝试将文件上传到某个地方并提供链接，并告诉我们它们来自哪个游戏以及是谁制作的；看过类似文件的人可能会认出它们。

更新：

当我下载文件并压缩它们时，至少两个 CITY 文件的大小不会缩小太多：

gbl@roran:~/Temp/Winrace$ ls -l
total 788
-rw-r--r-- 1 gbl users  44423 Dec  1 05:10 CITY.ENV
-rw-r--r-- 1 gbl users 242641 Dec  1 05:10 CITY1.LEV
-rw-r--r-- 1 gbl users  52720 Dec  1 05:10 MINI.VHC
-rw-r--r-- 1 gbl users 462848 Dec  1 05:10 WINRACE.EXE
gbl@roran:~/Temp/Winrace$ gzip *
gbl@roran:~/Temp/Winrace$ ls -l
total 472
-rw-r--r-- 1 gbl users  38260 Dec  1 05:10 CITY.ENV.gz
-rw-r--r-- 1 gbl users 223044 Dec  1 05:10 CITY1.LEV.gz
-rw-r--r-- 1 gbl users  26003 Dec  1 05:10 MINI.VHC.gz
-rw-r--r-- 1 gbl users 186138 Dec  1 05:10 WINRACE.EXE.gz

看看 .EXE 如何比 CITY* 文件压缩得更好？因此，这些文件很可能已被压缩，但其算法比 gzip 弱一些。这将解释为什么您也无法在其中真正找到有用的字符串。

现在，让我们检查 CITY.ENV 的十六进制转储，其开头为：

00000000  43 49 54 59 2e 54 58 54 00 6b 00 00 00 a5 00 00   CITY.TXT.k......
00000010  00 03 fb 0d 0a 01 00 20 20 73 70 6f ff 74 20 31   .......  spo.t 1
00000020  20 52 55 42 42 ef 45 52 46 58 05 00 20 33 2c d7    RUBB.ERFX.. 3,.
00000030  31 37 2c 17 00 30 01 58 44 55 af 53 54 31 5f 14   17,..0.XDU.ST1_.
00000040  30 32 1d 08 35 7e 21 58 42 49 47 53 50 4c 36 08   02..5~!XBIGSPL6.
00000050  da 37 38 32 03 38 32 20 51 08 41 53 41 48 6a 00   .782.82 Q.ASAHj.
00000060  16 18 1c 10 5f 10 61 38 33 6b 08 77 41 52 4b 33   ...._.a83k.wARK3
00000070  20 36 2c 34 7a 10 03 2d 31 41 10 a2 00 43 41 52    6,4z..-1A...CAR
00000080  53 45 4c 2e 52 41 57 00 d2 6c 00 00 00 fd 00 00   SEL.RAW..l......

显然，在偏移量 0000 处有一个文件名 CITY.TXT，在偏移量 007D 处有另一个文件名。那么问题来了，解码器怎么知道一个文件有多长，下一个从哪里开始呢？它如何知道文件名有多长，因为它们的长度不同？

这两个文件名都以 a 结尾\0，这是 C 中的字符串终止符，所以我们假设这\0没有其他含义。接下来是6B000000，或者0000006Bx86 使用的小端，它比下一个文件名的偏移量小一点。所以这可能与文件的压缩长度有关。

用 007D 处的下一个文件检查这一点，我们发现长度为 6CD2。将文件名的开头添加到此，我们得到 6D4D。事实上，在这之后的几个字节，在 6D63，我们有

00006d60  03 dd d5 52 55 42 42 45 52 46 58 2e 46 54 00 40   ...RUBBERFX.FT.@

下一个文件名。

所以让我们制作一个表格 - 文件名的字节位置，文件名，文件名后的整数，字节位置和整数的总和，下一个文件名的位置，以及需要添加到总和才能到达下一个文件名的偏移量：

0000    CITY.TXT        006B    006B    007D    +0012
007D    CARSEL.RAW      6CD2    6D4D    6D63    +0016
6D63    RUBBERFX.FT     0040    6DA3    6DB8    +0015
6DB8    RUBBERFX.3DW    045F    7217    722C    +0015
722C    PSPOTFX2.TM     1CBA    8EE6    8EFA    +0014
8EFA    FDUST1_FX.FT    .....  <-- the first F might be spurious as the next file is DUST1.FX

显然，这 4 个字节是压缩字节长度的假设似乎是正确的，即使我们还不知道为什么偏移量（最后一列）不是恒定的。它们似乎也与文件名的长度无关，因为前两个长度不同，但偏移量为 4，而第 3 个和第 4 个具有相同的偏移量但长度不同。

接下来，让我们检查该长度字节后面的字节并制作另一个表：

0000    CITY.TXT        006B    00A5
007D    CARSEL.RAW      6CD2    FD00
6D63    RUBBERFX.FT     0040    0076
6DB8    RUBBERFX.3DW    045F    0BF0
722C    PSPOTFX2.TM     1CBA    C000

这个数字总是比第一个大一些。由于我们已经怀疑该文件已压缩，因此我认为这是未压缩的大小。

所以你看，你可以通过查看文件本身找到一些东西。然而，问题仍然是为什么表 1 中的偏移量不是恒定的，以及使用哪种类型的压缩。而且，这是您需要大量经验和/或运气的地方。或者，您 20 年前一直在使用压缩程序并记住其中的一些和它们的文件格式，这看起来就像其中的一部分。（对我来说，它既不是 ARC 也不是 ZIP）。或者，您需要反汇编文件并检查代码是如何执行的。不幸的是，恐怕没有其他办法了。

好吧，它可以是自定义格式。我在linux中使用命令FILE来自动识别标准类型，否则你可以在windows上使用trid。

如果你有这个旧的游戏二进制文件，你可以尝试反汇编它并寻找处理基于扩展名的加载文件的例程。