Difference between revisions of "Recommended Procedures for SCI Game Programming Coordinators"

From SCI Wiki
Jump to navigationJump to search
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
<blockquote>
 +
<blockquote>
 
{|
 
{|
 
|-
 
|-
−
|Subject: ||Recommended Procedures for SCI Game Programming Coordinators
+
|Subject: &nbsp; ||Recommended Procedures for SCI Game Programming Coordinators
 
|-
 
|-
−
| ||
+
| ||&nbsp;
 
|-
 
|-
−
|Date: Monday January 30, 1989
+
|Date: ||Monday January 30, 1989
 
|-
 
|-
−
| ||
+
| ||&nbsp;
 
|-
 
|-
 
|From: ||Pablo Ghenis for SCI Development Group
 
|From: ||Pablo Ghenis for SCI Development Group
 
|-
 
|-
−
| ||
+
| ||&nbsp;
 
|-
 
|-
 
|To: ||Scott Murphy
 
|To: ||Scott Murphy
Line 23: Line 25:
 
| ||All Game Programming Coordinators
 
| ||All Game Programming Coordinators
 
|-
 
|-
−
| ||
+
| ||&nbsp;
 
|-
 
|-
 
|cc: ||Ken Williams
 
|cc: ||Ken Williams
Line 34: Line 36:
 
|}
 
|}
  
−
As we approach the release date for some products currently under development, we can expect a greater potential for conflict among the following equally worthy goals:
 
  
−
* To fix system bugs or shortcomings and provide enhancements in order to facilitate further game development.
+
 
 +
As we approach the release date for some products currently under <br />development, we can expect a greater potential for conflict among <br />the following equally worthy goals:
 +
 
 +
* To fix system bugs or shortcomings and provide enhancements in <br />order to facilitate further game development.
 
   
 
   
−
* To isolate game developers from system instabilities while the above goal is being met by the system developers.
+
* To isolate game developers from system instabilities while the <br />above goal is being met by the system developers.
 
   
 
   
  
−
The Programming Coordinators for each game can avoid disruptions
 
−
in their projects by taking the following steps:
 
−
 
−
# Create an isolated system directory for each project and load
 
−
a stable copy of the system into it. Also create a backup for
 
−
it and a directory for executables.
 
−
 
−
Example:
 
−
<code><nowiki>></nowiki>md \games\ice\system<br />
 
−
<nowiki>></nowiki>md \games\ice\system\old<br />
 
−
<nowiki>></nowiki>md \games\ice\tools
 
−
</code>
 
−
 
−
# Make sure that all "where" files are written in terms of s:
 
−
instead of \games\sci\system. Everyone's autoexec.bat file
 
−
should contain the line "set sinclude=s:"
 
−
 
−
# To save a version of tools such as the compilers and
 
−
interpreter, just copy them to your project's tool directory.
 
−
 
−
# To give your project's tools precedence over the main version,
 
−
type in a line like the following one, which should be
 
−
appended to all project members' autoexec.bat files:
 
−
 
−
pushpath g:\games\ice\tools
 
−
 
−
# To freeze a version of the system for your project, type in a
 
−
line like the following one:
 
−
 
−
pushsys \games\sci\system \games\ice\system \games\ice\system\old
 
−
 
−
This action might require the game to be rebuilt.
 
−
 
−
Everyone working on the project should have s: mapped to the
 
−
project's system directory. This can be done by editing the
 
−
user login file using SYSCON on the net, or by appending to
 
−
autoexec.bat a line like the following one:
 
−
 
−
map s:=g:\games\ice\system
 
−
 
−
# If the above step is determined to be premature, it can be
 
−
undone by typing a line like the following one:
 
−
 
−
<code>savesys \games\ice\system\old \games\ice\system</code>
 
−
 
−
This action might require the game to be rebuilt.
 
  
−
# Software updates should be performed and tested by the project
+
The Programming Coordinators for each game can avoid disruptions <br />in their projects by taking the following steps:
−
coordinator at times that will not hurt the team's
+
</blockquote>
−
productivity, with enough time to rebuild, test and even revert
+
# Create an isolated system directory for each project and load <br />a stable copy of the system into it. Also create a backup for <br />it and a directory for executables.<br /><br />Example:<br /><blockquote><code><nowiki>></nowiki>md \games\ice\system<br /><nowiki>></nowiki>md \games\ice\system\old<br /><nowiki>></nowiki>md \games\ice\tools</code></blockquote>
−
and rebuild again if needed.
+
# Make sure that all "where" files are written in terms of s: <br />instead of \games\sci\system. Everyone's autoexec.bat file <br />should contain the line "set sinclude=s:"<br />&nbsp;
 +
# To save a version of tools such as the compilers and <br />interpreter, just copy them to your project's tool directory.<br />&nbsp;
 +
# To give your project's tools precedence over the main version, <br />type in a line like the following one, which should be <br />appended to all project members' autoexec.bat files:<br /><br /><code>pushpath g:\games\ice\tools</code><br />&nbsp;
 +
# To freeze a version of the system for your project, type in a <br />line like the following one:<br /><br /><code>pushsys \games\sci\system \games\ice\system \games\ice\system\old</code><br /><br />This action might require the game to be rebuilt.<br /><br />Everyone working on the project should have s: mapped to the <br />project's system directory. This can be done by editing the <br />user login file using SYSCON on the net, or by appending to <br />autoexec.bat a line like the following one:<br /><br />map s:=g:\games\ice\system<br />&nbsp;
 +
# If the above step is determined to be premature, it can be <br />undone by typing a line like the following one:<br /><br /><code>savesys \games\ice\system\old \games\ice\system</code><br /><br />This action might require the game to be rebuilt.<br />&nbsp;
 +
# Software updates should be performed and tested by the project <br />coordinator at times that will not hurt the team's <br />productivity, with enough time to rebuild, test and even revert <br />and rebuild again if needed.
  
 +
<blockquote>
 +
While the SCI development team will carefully test all system <br />changes to avoid introducing problems, its very flexibility makes <br />it impossible to test all cases. It will be the responsibility of <br />each project's coordinator to follow the above (or equivalent) <br />procedures.
  
−
While the SCI development team will carefully test all system changes to avoid introducing problems, its very flexibility makes it impossible to test all cases. It will be the responsibility of each project's coordinator to follow the above (or equivalent) procedures.
+
I have provided the push*.bat and save*.bat files mentioned <br />above to facilitate this task; they are available in <br />x:\public\tools. We strongly recommend that all projects update <br />to the current system version as quickly as possible, since the <br />purpose of system changes is to correct bugs and provide <br />significant enhancements.
 +
</blockquote>
 +
</blockquote>
  
−
I haveprovided the push*.bat and save*.bat files mentioned above tofacilitate this task; they are available in x:\public\tools. Westrongly recommend that all projects update to the current system version as quickly as possible, since the purpose of systemchanges is to correct bugs and provide significant enhancements.
+
[[Category:SCI Documentation]]
 +
[[Category:Scripting]]

Latest revision as of 19:13, 2 March 2018

Subject:   Recommended Procedures for SCI Game Programming Coordinators
 
Date: Monday January 30, 1989
 
From: Pablo Ghenis for SCI Development Group
 
To: Scott Murphy
Corey Cole
Chris Iden
Warren Schwader
All Game Programming Coordinators
 
cc: Ken Williams
Rick Cavin
Dale Carlson
All SCI programmers


As we approach the release date for some products currently under
development, we can expect a greater potential for conflict among
the following equally worthy goals:

  • To fix system bugs or shortcomings and provide enhancements in
    order to facilitate further game development.
  • To isolate game developers from system instabilities while the
    above goal is being met by the system developers.


The Programming Coordinators for each game can avoid disruptions
in their projects by taking the following steps:

  1. Create an isolated system directory for each project and load
    a stable copy of the system into it. Also create a backup for
    it and a directory for executables.

    Example:

    >md \games\ice\system
    >md \games\ice\system\old
    >md \games\ice\tools

  2. Make sure that all "where" files are written in terms of s:
    instead of \games\sci\system. Everyone's autoexec.bat file
    should contain the line "set sinclude=s:"
     
  3. To save a version of tools such as the compilers and
    interpreter, just copy them to your project's tool directory.
     
  4. To give your project's tools precedence over the main version,
    type in a line like the following one, which should be
    appended to all project members' autoexec.bat files:

    pushpath g:\games\ice\tools
     
  5. To freeze a version of the system for your project, type in a
    line like the following one:

    pushsys \games\sci\system \games\ice\system \games\ice\system\old

    This action might require the game to be rebuilt.

    Everyone working on the project should have s: mapped to the
    project's system directory. This can be done by editing the
    user login file using SYSCON on the net, or by appending to
    autoexec.bat a line like the following one:

    map s:=g:\games\ice\system
     
  6. If the above step is determined to be premature, it can be
    undone by typing a line like the following one:

    savesys \games\ice\system\old \games\ice\system

    This action might require the game to be rebuilt.
     
  7. Software updates should be performed and tested by the project
    coordinator at times that will not hurt the team's
    productivity, with enough time to rebuild, test and even revert
    and rebuild again if needed.

While the SCI development team will carefully test all system
changes to avoid introducing problems, its very flexibility makes
it impossible to test all cases. It will be the responsibility of
each project's coordinator to follow the above (or equivalent)
procedures.

I have provided the push*.bat and save*.bat files mentioned
above to facilitate this task; they are available in
x:\public\tools. We strongly recommend that all projects update
to the current system version as quickly as possible, since the
purpose of system changes is to correct bugs and provide
significant enhancements.

Retrieved from "http://sciwiki.sierrahelp.com/index.php?title=Recommended_Procedures_for_SCI_Game_Programming_Coordinators&oldid=13451"