LucasFilm development machines ; and some Sierra influence

[ZvikaZ]

Well, it's actually an expansion to my comment on another thread (http://sciprogramming.com/community/index.php?topic=2034.msg15053#msg15053), but since it'd be quite off topic over there, I write it here...

I said there:

IIRC, I once read an interview with one of Lucas developers, and he said that they developed on another machine

So, I just (re-)found it: https://www.gamedeveloper.com/design/the-scumm-diary-stories-behind-one-of-the-greatest-game-engines-ever-made, it's an interesting reading.

And while looking for it, I've found some other piece (https://gamesnostalgia.com/story/170/legendary-game-designers-ron-gilbert), about Ron Gilbert, where he mentions the influence KQ had over him, and Maniac Mansion design:

that was the first time I had seen any of the King’s Quest games and the first time I had ever seen an adventure game with graphics. ... I just watched him play, and it was like this epiphany moment... Like “Oh, this is what Maniac Mansion needs to be. It needs to be an adventure game with these pictures on it.”

It's interesting to compare this to Ken Williams' claim in his book that he (and Sierra) was never interested in what was done in other companies.

[AGKorson]

Thanks for posting this. A lot of really interesting content that i have never seen before. And all the links to other content is a rabbit hole I am more than happy to jump down!

[HWM]

It's interesting to compare this to Ken Williams' claim in his book that he (and Sierra) was never interested in what was done in other companies.

Not sure about Ken, but it seems that someone at Sierra had a copy of Maniac Mansion. These are directory entries found in unallocated parts of the first disk of Police Quest 2 v1.001.006 (added human-readable details):

Code: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00046680  44 4F 53 20 20 20 20 20 20 20 20 10 00 00 00 00  DOS        .....  SUBDIR
00046690  00 00 00 00 00 00 40 BF 52 10 29 00 00 00 00 00  ......@¿R.).....  1988-02-18 23:58:00
000466A0  46 41 53 54 42 41 43 4B 20 20 20 10 00 00 00 00  FASTBACK   .....  SUBDIR
000466B0  00 00 00 00 00 00 D4 00 53 10 52 00 00 00 00 00  ......Ô.S.R.....  1988-02-19 00:06:40
000466C0  47 41 4D 45 53 20 20 20 20 20 20 10 00 00 00 00  GAMES      .....  SUBDIR
000466D0  00 00 00 00 00 00 99 43 ED 10 54 00 00 00 00 00  ......™Cí.T.....  1988-07-13 08:28:50
---
000466E0  4D 41 4E 49 41 43 20 20 20 20 20 10 00 00 00 00  MANIAC     .....  SUBDIR
000466F0  00 00 00 00 00 00 E2 49 89 11 53 00 00 00 00 00  ......âI‰.S.....  1988-12-09 09:15:04
---
00046700  53 43 49 20 20 20 20 20 20 20 20 10 00 00 00 00  SCI        .....  SUBDIR
00046710  00 00 00 00 00 00 EA 44 21 11 55 00 00 00 00 00  ......êD!.U.....  1988-09-01 08:39:20
00046720  55 54 49 4C 53 20 20 20 20 20 20 10 00 00 00 00  UTILS      .....  SUBDIR
00046730  00 00 00 00 00 00 48 07 53 10 46 00 00 00 00 00  ......H.S.F.....  1988-02-19 00:58:16
00046740  41 55 54 4F 45 58 45 43 42 41 54 20 00 00 00 00  AUTOEXECBAT ....  FILE [1308 bytes]
00046750  00 00 00 00 00 00 E9 A4 66 11 8E 01 1C 05 00 00  ......é¤f.Ž.....  1988-11-06 20:39:18
00046760  43 4F 4D 4D 41 4E 44 20 43 4F 4D 20 00 00 00 00  COMMAND COM ....  FILE [25276 bytes]
00046770  00 00 00 00 00 00 01 00 F8 0E 1C 00 BC 62 00 00  ........ø...¼b..  1987-07-24 00:00:02
00046780  43 4F 4E 46 49 47 20 20 53 59 53 20 00 00 00 00  CONFIG  SYS ....  FILE [90 bytes]
00046790  00 00 00 00 00 00 7C B8 67 11 B4 09 5A 00 00 00  ......|¸g.´.Z...  1988-11-07 23:03:56
000467A0  41 54 2D 31 30 4D 48 5A 20 20 20 08 00 00 00 00  AT-10MHZ   .....  VOLUME LABEL
000467B0  00 00 00 00 00 00 B8 6E 89 11 00 00 00 00 00 00  ......¸n‰.......  1988-12-09 13:53:48
000467C0  43 4C 41 53 53 44 45 46 20 20 20 20 00 00 00 00  CLASSDEF    ....  FILE [14440 bytes]
000467D0  00 00 00 00 00 00 4E 4B 8C 11 F7 00 68 38 00 00  ......NKŒ.÷.h8..  1988-12-12 09:26:28
000467E0  52 45 53 4F 55 52 43 45 54 58 54 20 00 00 00 00  RESOURCETXT ....  FILE [13491 bytes]
000467F0  00 00 00 00 00 00 45 60 7E 11 6C 02 B3 34 00 00  ......E`~.l.³4..  1988-11-30 12:02:10

The inclusion of this internal system data on disks is probably caused by "RAM slack" and/or "drive slack", a phenomenon (in old versions of MS-DOS?) that's not entirely clear. For more about this, Lance has researched it in this topic: http://sciprogramming.com/community/index.php?topic=1418.15

The presence of subdirectories "SCI", "FASTBACK", etcetera, proves (to me) that this the root of an internal system at Sierra. That said, "MANIAC" doesn't necessarily mean "Maniac Mansion", but it seems obvious and fits the May 1988 release date.

Another thing; a quote from the interview with Aric Wilmunder linked above:

For a short time we had a tool called SMEGMA.  One of the programmers had a child and told us that when babies are born, their first bowel movements consist of this.  Well, he was mistaken and it turns out that substance is called Meconium.  We hadn't bothered to look up Smegma, we just liked the sound of it.  Once we did, the name changed a few days later.

I've checked some Lucasfilm disks on slack with directory entries as well. It seems the name stuck anyhow:

Code: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000212E0  50 4C 41 59 53 46 58 20 45 58 45 20 00 00 00 00  PLAYSFX EXE ....  FILE [23653 bytes]
000212F0  00 00 00 00 00 00 59 2D E8 12 38 05 65 5C 00 00  ......Y-è.8.e\..  1989-07-08 05:42:50
00021300  52 4D 20 20 20 20 20 20 45 58 45 20 00 00 00 00  RM      EXE ....  FILE [13039 bytes]
00021310  00 00 00 00 00 00 46 55 2F 13 3E 05 EF 32 00 00  ......FU/.>.ï2..  1989-09-15 10:42:12
00021320  53 43 55 4D 4D 20 20 20 45 58 45 20 00 00 00 00  SCUMM   EXE ....  FILE [232371 bytes]
00021330  00 00 00 00 00 00 BB 65 43 13 42 05 B3 8B 03 00  ......»eC.B.³‹..  1989-10-03 12:45:54
00021340  53 45 54 53 4F 55 4E 44 45 58 45 20 00 00 00 00  SETSOUNDEXE ....  FILE [13293 bytes]
00021350  00 00 00 00 00 00 72 70 B1 12 7B 05 ED 33 00 00  ......rp±.{.í3..  1989-05-17 14:03:36
00021360  53 4B 45 4C 52 4F 4F 4D 45 58 45 20 00 00 00 00  SKELROOMEXE ....  FILE [13855 bytes]
00021370  00 00 00 00 00 00 53 7A CD 12 7F 05 1F 36 00 00  ......SzÍ....6..  1989-06-13 15:18:38
---
00021380  53 4D 45 47 4D 41 20 20 45 58 45 20 00 00 00 00  SMEGMA  EXE ....  FILE [27973 bytes]
00021390  00 00 00 00 00 00 08 68 F8 12 83 05 45 6D 00 00  .......hø.ƒ.Em..  1989-07-24 13:00:16\
---
000213A0  53 4D 53 50 55 54 4D 20 45 58 45 20 00 00 00 00  SMSPUTM EXE ....  FILE [102339 bytes]
000213B0  00 00 00 00 00 00 8B 75 64 14 8A 05 C3 8F 01 00  ......‹ud.Š.Ã...  1990-03-04 14:44:22
000213C0  53 50 49 54 20 20 20 20 45 58 45 20 00 00 00 00  SPIT    EXE ....  FILE [24721 bytes]
000213D0  00 00 00 00 00 00 AA 9D F6 12 A3 05 91 60 00 00  ......ª.ö.£.‘`..  1989-07-22 19:45:20
000213E0  53 50 55 54 4D 20 20 20 45 58 45 20 00 00 00 00  SPUTM   EXE ....  FILE [141401 bytes]
000213F0  00 00 00 00 00 00 A5 75 64 14 AA 05 59 28 02 00  ......¥ud.ª.Y(..  1990-03-04 14:45:10


[Kawa]

Doesn't need to be a particularly old version of MS-DOS. Or even MS-DOS. Leftover data on disks Just Happens.

For example, deleting a file in DOS is very fast because instead of actually wiping the data, it just sets the high bit in the first character of the file name, marking that entry in the file allocation table as free for reuse. All the other information (until you alter the disk any further!) is still right there, allowing you to undelete the file. This is obviously not what happened with these disks, considering they all have perfectly readable file names, but I feel it'd add a bit of perspective on how easily these things can happen.

[HWM]

Doesn't need to be a particularly old version of MS-DOS. Or even MS-DOS. Leftover data on disks Just Happens.

For example, deleting a file in DOS is very fast because instead of actually wiping the data, it just sets the high bit in the first character of the file name, marking that entry in the file allocation table as free for reuse. All the other information (until you alter the disk any further!) is still right there, allowing you to undelete the file. This is obviously not what happened with these disks, considering they all have perfectly readable file names, but I feel it'd add a bit of perspective on how easily these things can happen.

Fully agree, but I was aiming at FAT directory entries ending up as padding to fill a sector. This does seem to be something related to MS-DOS (although it might be restricted to certain versions) and is probably an example of what some sources call "RAM slack".

[Kawa]

I don't know how much clearer I could make it that "deleted" files are just an example of something similar but apparently this wasn't clear enough.

Oh well.