An Argument for the Elimination of Setup Programs

Origin Research Fellow White Paper #3

Zachary Booth Simpson
Origin Research Fellow
14 Dec 1998

(c)2002 ZBS. http://www.mine-control.com/zack
Please sign my guestbo0k if you find this work useful.

Observations

Copying / Deleting files

Configuring System

Network Related

Miscellaneous

Proposal

We should move all functionality of setup programs into the primary application. The advantage of this is simplicity both for the developers and the users.

It should be a goal that our game CDs are placed into the CD drive, auto-run should start the real game, and the customers start playing. The following enumerates what needs to happen to do this following the list of setup features listed above.

    Copying / Deleting Files

  1. Cache files to HD. The usual copying of files should be considered at HD cache, not an install. When the program runs, it simply begins a thread copying the necessary files to a temporary directory (such as \windows\temp). By the time the user has looked at the flashy title screen, the other thread will probably be done with the vital files. (This is currently being addressed by Microsoft, see below). If the thread is not complete, it displays a wait status message.
    Don't create save-game directories immediately. Delay the creation of permanent directories (save game files, etc.) until the users actually have something to save. The save game menu should be able to create the directory wherever the user wants it. It should, of course, assume a reasonable default.
  2. Demand-cache optional components. Few games even include optional installable components anymore since disk space demands have been reduced. However, in the cases where some components can be avoided the solution is again solved by treating the entire file system as a CDHD cache.
  3. Uninstall save games / flush cache option in main menu. The main menu should simply contain an option "Clean System" which explains that all save games will be lost and requests verification. There should be nothing special about uninstall, the next time you stick in the CD, it is just like it always is. It may be desirable to allow the users to delete the save games via the uninstall option on the control panel without the CD. In this case, we should just point the uninstall key off to a simple batch file in the save game directory which deletes the files eliminating the need for an additional setup-like user interface.

    Configuring System

  4. Run profiling in game. Most games have already moved profiling and hardware configuration in- game to avoid customers having to re-run setup when they install new hardware. Thus, this is already a mute point.
  5. Select hardware in-game or not at all. Ideally, the PC would be treated like a console system - there would be no hardware to twiddle. More realistically, the hardware twiddling should be done via the appropriate control panels and hardware selection should be automatic or at least very simple. Like profiling, this too has already moved in-game so again, this is already mostly mute.
  6. Avoid creating shortcuts on the Start Menu / do it automatically. In most games the CD is required, so simply stick the CD in and start. (For systems which have auto-run disabled, the user can double-click on the CD icon under My Computer). Some people may disagree with this approach, in which case the application should just create the shortcuts automatically the first time it runs in a default place. If the users wish to change the location from default, they can do so easily within the OS GUI.
  7. Check for necessary drivers at startup. During game load, the game should always check for the correct DX drivers and other required files. If they don't exist, they should be copied and a reboot offered if necessary. No special code is needed after reboot since the check is performed every time.

    Network Related

  8. Move network diagnostics / configuration in-game. Like most hardware configuration enumerated above, this functionality is already moved in-game in most products. It is usually more convenient to write this in-game anyway since it requires game network protocol code which would annoyingly have to be linked into the setup program if it weren't in-game.
  9. Create/register character. Ditto 8.
  10. Check feature limit keys automatically. Again, already in-game in most products.
  11. Offer electronic registration via the web. The internet is becoming the universal digital communication system. E-reg programs that supported internet-less modem connections should be phased out and replaced with URLs. The main-menu in the game should offer a shortcut to the registration URL at all times (so it can be updated if person wished) which simply launches the web browser to the appropriate page. This has the extra advantage that the sales department can maintain the e-reg system totally independently of the developers since there will never be any code on the client side and it obviates the need for maintenance of backward compatibility on the server side.

    Miscellaneous

  12. Allow language changes dynamically. If the game has multiple language support on the same CD, the language should be changeable dynamically in-game. This is usually fairly easily done by reloading resources and keeping all language dependent variables in a hash-table. This is good coding practice in general since it keeps these strings out of static data and eases translation. As mentioned above, the desire to reduce gray-market sales usually means that there isn't language selection on the same CD so this may rarely be an issue.
  13. Provide links to optional software in-game. Games and other systems are usually simply forked in separate processes in most setup programs today. Moving this in-game is trivial.

Technical Details