<html>

<head>

<title>loonygames - print happy version</title>
</head>

<body leftmargin="10" topmargin="10" bgcolor="#FFFFFF" text="#000000">
<table width="100%" border="0" height="58" bordercolordark="#000000" bordercolorlight="#000000">
  <tr> 
    <td height="57" width="26%" align="left" valign="top"> 
      <div align="left"> 
        <h1><font face="Arial, Helvetica, sans-serif"><b><i><a href="../../index.html">loonygames</a><br>
          <font size="1">a <a href="http://www.bluesnews.com">blue's news</a> 
          publication</font></i></b></font></h1>
        </div>
    </td>
    <td height="57" width="74%" align="center" valign="top"> 
    </td>
  </tr>
</table>
<p><a href="../2.3/btc/index.html">&lt;&lt; Back to Normal View</a></p>
<p>URL: <a href="../2.3/btc/index.html">http://www.loonygames.com/content/2.3/btc/</a><br>
</p>
<p>&nbsp;</p>Vol. 
                2, Issue 3<br>
                November 25, 1999<br>
                </b>
              <b> 
                </b>
              
                <b><i>Behind 

                  the Curtain:</i></b></p>
                <b><i> 
                  We don&#146;t need no steenkin&#146; technical design!</i></b></p>
                by 
                  Matt &quot;Thraka&quot; 
                  Gilbert</p>
              
              

<!--
       function gotoSite(obj)
          {
          var s;
          s=obj.options[obj.selectedIndex].value
                         location.href=s;
          }
// -->


              <?
              
              include("/home/loonygames/loony.timedoctor.org/includes/btc.htm"); 
              
              ?>
              
              
              
               Hello 
                again, and welcome. Thanksgiving is almost upon us, so forgive 
                my brevity; I have a ton of work to get done if I want to enjoy 
                my holidays.</p>
              Before 
                you can build anything, you have to have some idea of what you&#146;re 
                building. There is an aphorism that goes around programming circles 
                that goes something like this: &#147;If builders built buildings 
                like programmers build software, the first woodpecker to come 
                along would destroy our entire civilization.&#148; (No, I don&#146;t 
                know who said it. I&#146;m not sure anyone does. Nobody I asked 
                knew, either, but we&#146;ve all heard it.)</p>
              </p>
              Hyperbole, 
                sure, but not entirely unwarranted. There are plenty of people 
                who have the idea that you can just sit down and begin programming 
                &#145;the game&#146;, and somehow, it will all come together. 
                In fact, not all that long ago, this used to be pretty much how 
                the industry thought things should work, too. And there was a 
                time when it did, frankly. When you only have 16k of ROM to work 
                with, you can afford to skip the organization, after all. If the 
                art format changed, you had the artist redo all eight frames of 
                animation for the one character you could display, and it was 
                no big deal.</p>

              </p>
              But that 
                was then, and honestly, it didn&#146;t work very well. Once more 
                than two people were involved, it just became a mess. Add to that 
                the volume of resources required by a modern game, which is rapidly 
                moving toward <i>terabytes</i>. It&#146;s not hard to understand 
                that &#145;redo the art&#146; is a phrase likely to inspire the 
                art and production staff to see that your life comes to a painful 
                end after the project ships.</p>
              </p>
              So, imperative 
                number one is to communicate the capabilities of your system to 
                the art and design staff. Of course, how you arrive at this information 
                is the tough part. You consider what you believe the hardware 
                is capable of, and factor in the fact that it might be capable 
                of Feature A if it is not combined with Feature B. You have to 
                think about the fact that while ordinarily feature A will coexist 
                just fine with feature B, inevitably, someone will want to push 
                both features to their limits <i>at the same time</i>. Someone 
                else will also want a thousand Feature C&#146;s in the same scene. 
                Finally, you have to factor in how much time you actually have 
                to implement the feature set. Feature A might be really cool, 
                but take a long time to implement; is it cool enough to put in 
                Feature A, and cut Feature B and C to make it happen? Does the 
                design team really want Feature A, or would they rather have the 
                other stuff? What features <i>absolutely must </i>be available 
                to the design team, and which can they live without?</p>
              </p>
              Now that 
                you have this feature list, and have communicated some tentative 
                specs to the design staff, you come to imperative two: figure 
                out how to do it within the limited resources of the system, and 
                write down Da Plan.</p>
              </p>
              Da Plan 
                consist of a breakdown of all the small tasks you feel it will 
                take to complete a given feature, and the amount of time you expect 
                each task to take. Here is where I inevitably screw up, and adding 
                up the task times shows that I think I can do the entire game 
                engine in one month. I can&#146;t help it. Somehow, I always think 
                I am superman, and that nothing will go wrong, and that I have 
                a clear understanding of every fine point that will go into the 
                game.</p>
              </p>
              Needless 
                to say, I am always <i>wrong</i>. So I go back and try to find 
                the spots where I have underestimated the time it will take to 
                do the job. It&#146;s a multi-pass process, and the worst part 
                of it is that, inevitably, you get the feeling that you&#146;re 
                artificially stretching out the tasks, like the old Scotty principle, 
                where Scotty confesses to multiplying his time estimates by a 
                factor of four to maintain his reputation as a miracle worker. 
                Don&#146;t fall into this trap. The truth is that you are far 
                more likely to underestimate the time a task will take. Leave 
                yourself room to make mistakes, because they will happen. When 
                in doubt, be conservative and leave yourself some breathing room. 
                For every task that you overestimate, you are likely to have underestimated 
                another. Any slack you manage to pull out of the schedule during 
                the actual implementation, you will find a way to utilize. If 
                somehow you manage to pull it all off ahead of schedule, there 
                are still additional features, changes, etc., that someone will 
                want: I promise, you will never find yourself sitting idle, wondering 
                what to do.</p>
              </p>
              Then you 
                wrap it up and tie a bow on it. You put it all down in a professional 
                looking package, and present it to the publisher&#146;s technical 
                people, usually in a face to face meeting. You will be expected 
                to have answers for a variety of questions that they may have, 
                so it behooves you to prepare ahead of time with a list of things 
                that might be asked of you. The more questions you anticipate, 
                the better you will look, and the more confidence you will generate 
                with the publisher. And, especially in the early stages of a project, 
                when it is still cost effective for a publisher to pull the plug 
                on a project, it is imperative that you not look like you don&#146;t 
                know what the hell you are doing.</p>
              </p>
              Assuming 
                you did your job right, the publisher will green light the Technical 
                Design, and production will begin in earnest.</p>
              </p>
              Next Time: 
                The Game Design</p>
              </p>
              </p>
               </p>
              <i>- 
                Matt 'Thraka' Gilbert is a console programmer, currently working 
                at StormFront Studios. These are his own ravings, and have nothing 
                whatsoever to do with his employer.<br><p>&nbsp;</p> 
<p><a href="../2.3/btc/index.html">&lt;&lt;Back to Normal View</a></p>
<table width="100%" border="1" height="29" bordercolordark="#000000" bordercolorlight="#FFFFFF" cellspacing="0" cellpadding="0">
  <tr> 
    <td height="20" width="99%"> 
      <div align="center"><font face="Arial, Helvetica, sans-serif"><b><i>loonygames 
        - the best damn gaming magazine online </i></b></font></div>
    </td>
  </tr>
</table>
<p><i><font face="Arial, Helvetica, sans-serif" size="-2">Credits: Print CGI is 
  &copy; 2000 <a href="http://www.square8.com">Square Eight</a>. Used with permission. 
  Article is &copy; 2000 its original author. All other content is &copy; 2000 
  loonyboi productions. Unauthorized reproduction is prohibited. You got that??</font></i></p>
 