During the latest gaming press release, Square Enix released remastered versions of all of the classic Final Fantasy games excluding Final Fantasy VIII. The alleged reason is due to the lost source code. Ignoring SE's failure to archive the source of their very own historical, if not also lucrative software, I want to ask about the historical practices of oldskool gaming platforms (from console development to home computers) for archiving and version controlling.

It seems that version control and cloud archival has become tightly integrated into today's software development cycles. Were there other tools that contributed to the archival in its broadest sense of source code. If so, no what extent did these tools preserve changes.

EDIT: From the comments, it seems that version control has existed since the 80s in the realm of microcomputer development. It would seem more suitable then to focus the scope of the question on archival practices. I am also not looking for "It didn't happen" because the fact is people today continue to fail to archive code for many reasons.

  • 3
    Git is a red herring here, source control systems have existed since at least SCCS in 1972. Jul 2, 2019 at 4:10
  • 3
  • 3
    Anecdotally I think most developers didn't use any kind of version control. Occasional backups is about as close as they ever got.
    – user
    Jul 2, 2019 at 8:01
  • 4
    Source control systems are only useful when all the data is on-line accessible. Before that, "lost source code" meant exactly what the words say - "there is probably a deck of punch cards or a tape cartridge somewhere in the building, unless somebody threw it in the trash bin by mistake, but nobody can find it." Mainframe systems used to employ full-time tape librarians whose sole job was to make sure that didn't happen!
    – alephzero
    Jul 2, 2019 at 10:45
  • 4
    The problem here is using FF8 to start the topic. FF8 has been released in 1999, that's not oldskool gaming at all.
    – motoDrizzt
    Jul 2, 2019 at 11:14

5 Answers 5


There is some anecdotal evidence that often there was no real source control or archival system in place, just ad-hoc backups.

For example, a number of machines from 90s developers have been recovered recently, particularly Amigas. One belonging to Psygnosis and one belonging to Team 17 have surfaced. No evidence of any version control or systematic backups appears on either.

  • 1
    Just because I'm a curious sort; I found vintageisthenewold.com/… on the Psygnosis machine you mention — did anywhere provide any more detail on the Team 17 machine?
    – Tommy
    Jul 2, 2019 at 21:10
  • 2
    @Tommy There is a Youtube video for the Team 17 machine: youtube.com/watch?v=rcyHqJ6ZHXs
    – Jan
    Jul 3, 2019 at 9:19
  • Yah, in the 90's source control was all but unheard of in game development. Many game developers would literally have no clue what you were talking about if you brought up the subject. It wasn't until the early 2000's that source control started to become mainstream in game development.
    – user722
    Jul 7, 2019 at 16:51

The recent release of the stack of Infocom source code is more the norm than not. Simply, backups of source code stored someplace rather than a formal source code version system.

Part of the issue was that teams were very small. A great boon of VCS (version control systems) is the share of code among team members. The larger the team, the more the necessity of such a system. But many games were very small teams, and even then, most of the coding was done by one or two people with the rest being part of content development (stories, sounds, graphic art, etc.).

Operationally, they would just be thrown over the wall for the developers to integrate in to their latest builds.

I didn't start using version control professionally until the mid-90s, even though I was a one-man team working on the software. I used to simply to get rid of the "progv1 progv2 progv3" directories that were showing up organically in the system. This was especially frustrating when we have 3 versions of the program, but discover that only the second version was being used.

At that time I used raw RCS. Instead of something more sophisticated like CVS. I've never used SCCS. We were developing on HP-UX at the time, and I downloaded the RCS code and built it. I don't think HP-UX came with RCS or SCCS. If it came with SCCS, I probably would have just leveraged that. I wrote my own scripts to make RCS usable for me, since it really only worked with individual files.


Developing in the 1980s, we stored the work in progress on a floppy disk, and made a backup copy of it. No more than that. Source control was for corporations, and for people with hard disks.


One method used for backing up data in the early days of home computers is the Grandfather, Father, Son technique. This approach is most relevant to data stored on floppy disks, or similar removable media.

Acorn Computers advocated it for use with their System (and later BBC Micro) computers, initially referring to it as an Ancestral File System (*1).

In the BBC Disk Filing System User Guide (*2), they describe it as follows:

Another way of protecting important information is to keep several copies of it on different discs. Where computers are used in business, industry or other activities which use large volumes of information, a standard routine for this has been evolved. It is often called the `grandfather, father, son' principle of copying information, and is good practice for anyone using a disc storage system. It works as follows:


Day 2, MASTER copied to FATHER

Day 3, MASTER copied to SON

As you can see, it involves keeping three separate discs, each with a copy of the information from the master disc on it. On day 4 the master would be copied to the grandfather again and so the cycle continues. In business, where information on disc changes from day to day, this regular routine is important. For personal computing it may not be so vital, but you will want to keep several copies of important programs and information which you have worked hard to produce.

This approach would keep up to three days worth of changes (assuming no media failures), at which point the oldest backup would be overwritten. One could keep more previous versions by adding more disks into the cycle, but at a cost of $5-$8 each (at 1978 prices (*3)) the appeal would be limited.

  1. See the System 5 Handbook, section 2.10.5

  2. First published July 1983

  3. As quoted in the New York Times


Reasonably effective source code control has been around for a long time, and used in a disciplined way in large projects since long before Final Fantasy VIII started development. For example, the initial import of 4.4BSD-Lite2 source code into CVS to start the NetBSD project was done in July 1992 (growing within a few months to over 6500 files and 2 million lines), and the revision history has been maintained continuously since then.

The problem here is that computer source code is only a small fraction of the assets needed to build a game: you also have all the graphical and sound content, in comparison with which the source code is trivial in size. These are nowhere near as easy to compress as multiple substantially similar versions of text files, and even that aside have generally been too large to keep in a standard source code revision control system without slowing it to a crawl. (There have been attempts at addressing this, such as by Perforce in the mid- to late-'90s, but not all game development houses had the time or money to try to implement such solutions.) Thus, large assets are usually stored separately, sometimes without any real revision control on them at all.

Further, for non-code assets the distinction between "source" and "built" products is less clear. For example, the article to which you linked pointed out:

...but the gorgeous pre-rendered 3D backgrounds look grainy and pixelated. This is because these pre-rendered backgrounds have, for the most part, been lost. All of the backgrounds in FF7, 8 and 9 were created at a far higher resolution than needed then compressed down to fit into 320×240 or 640×480 resolutions.

It would be normal during the development for a particular platform, such as PlayStation, to do the compression and downscaling once and always use that product when doing a build, rather than spend the extra time and disk storage to do the compression and downscaling with every build.

Disciplined use of source code control was not truly widespread in the industry in the '90s anyway, and that in combination with the particular problems and barriers posed by relatively massive game assets and the generally high pressure of game development schedules meant that most games development tended to take an ad-hoc approach without a lot of effort and expense put into archiving.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .