home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus Extra 1996 #3 / AmigaPlus_CD-ROM-EXTRA_Nr.3.bin / aminet-spiele / denk&grübel / multris / tetris-programmers.doc < prev   
Text File  |  1979-12-31  |  8KB  |  247 lines
  1.  
  2.         100010 01010 010100 00010  01  010
  3.           10   00      00   00  00 00 00
  4.           00   0010    01   00100  10  010
  5.           01   10      00   11  00 00    00
  6.           00   01101   10   00  10 00 0010
  7.  
  8.           "A programmers' guide to galaxy"
  9.  
  10.  --------------------------------------------------------------------------
  11.  By S. Raaijmakers in 1993      Release 1.0      E-mail:  stijnr@sci.kun.nl
  12.  --------------------------------------------------------------------------
  13.  
  14. WHY READ THIS?
  15.  
  16.  If you haven't had any experience in programming Yourtris, you are (sorry)
  17.  bound to fail. Although you have spend hours and hours planning your game,
  18.  you will encounter some --- hard to correct --- problems.  So here is this
  19.  guide to your rescue, or, prevention of you needing rescue, actually ...
  20.  
  21.  
  22. USED NAMES
  23.  
  24.  Figure        These are the things you move  around,  like  [][][][],  the
  25.                long red figure in the Arcade version of Tetris.
  26.  Block         This is what these figures are built of,  the red figure is
  27.                built out of 4 blocks.
  28.  Pit           This is what you try not to fill with figures.
  29.  Line          One layer in the pit (if filled with blocks it disapears).
  30.  
  31.  
  32.  --------------------------------------------------------------------------
  33.  PART I: Programming difficulties
  34.  --------------------------------------------------------------------------
  35.  
  36. PROBLEM 1: Representation of the figures.
  37.  
  38.  The  easiest  way  to  represent a figure is by a square matrix.   Square,
  39.  because this is the fastest and easiest way to work with.   The red  block
  40.  would look like this:
  41.  
  42.     ....        .#..
  43.     ####    and    .#..    a.s.o.
  44.     ....        .#..
  45.     ....        .#..
  46.  
  47.  If your programming-language supports resizable  arrays,  a  3 x 2  figure
  48.  would look like this:
  49.  
  50.     ##.
  51.     .##
  52.     ...
  53.  
  54.  If it doesn't it would look like this:
  55.  
  56.     ##..
  57.     .##.
  58.     ....
  59.     ....
  60.  
  61.  It doesn't really matter which one you use;  they are equally complex  and
  62.  the amounts of memory involved are essentially small.
  63.  
  64.  But this isn't all; before you start,  you should think of what properties
  65.  a figure has.   One property your figures are bound to have is a diameter.
  66.  This is the (virtual) size of a block. So, wether you use resizable arrays
  67.  or not,  the diameter of the 3 x 2 figure above is 3 and that of  the  red
  68.  block is 4.  Here are some other properties a figure might have:
  69.  
  70.  - Color
  71.  - Score (factor)
  72.  - Probability of occurance
  73.  - First level of appearance
  74.  - Index for corresponding sprites in spritetable
  75.  
  76.  
  77. PROBLEM 2: Rotating.
  78.  
  79.  A small yet irritating problem.  Here's the answer:
  80.  
  81.     Counter-clockwise    Normal            Clockwise
  82.  
  83.     #....            ####.            ####.
  84.     #.#..            #....            .#.#.
  85.     #.#..            ###..            .#.#.
  86.     ####.            #....            ...#.
  87.     .....            .....            .....
  88.     (y, d + s - x)        (x, y)            (d + s - y, x)
  89.  
  90.  Where <d> is the diameter of the block, <md> the diameter of the matrix it
  91.  is in and <s> the index number of the first element in the array (which is
  92.  usually 0).  In this example, <d>=4 and <md>=5.
  93.  
  94.  
  95. PROBLEM 3: The edges of the pit.
  96.  
  97.  Suppose somebody tries to move the long red block when it touches the left
  98.  edge of the pit:
  99.  
  100.     |       |
  101.     |       |
  102.        ..#.       |
  103.        ..#.       |
  104.        ..#.       |
  105.        ..#.       |
  106.     |       |
  107.     +----------+
  108.  
  109.  Immediatily you see the problem:  when you start checking if it is allowed
  110.  to rotate the block you have to check positions that are 2 positions  away
  111.  from the pit-matrix.   So if <md> is the width of your  figure-matrix  and
  112.  <wpit> is the width of the pit (on screen,  measured in blocks), the width
  113.  of the actual matrix should be 2(<md> - 1) + <wpit>,  if you assume  every
  114.  figure contains at least one block.
  115.  
  116.  At the top of your on-screen-matrix no extra space is needed in the actual
  117.  matrix, but at the bottom there is.  Look at this picture:
  118.  
  119.     ...##########...   In this picture, # represents one block in both
  120.     ...##########...   on-screen-matrix and the actual matrix.  The
  121.     ...##########...   dot . represents one block in the actual matrix.
  122.     ...##########...
  123.     ...##########...   This example belongs to a pit of width 10 and
  124.     ...##########...   depth 8.  The (maximum) figure-matrix size is 4.
  125.     ...##########...
  126.     ...##########...
  127.     ................
  128.     ................
  129.     ................
  130.  
  131.  
  132. PROBLEM 3: Next on/off
  133.  
  134.  Of you want to make this possible, think of it before you start hacking.
  135.  
  136.  
  137. BOTTOM-UP PROGRAMMING
  138.  
  139.  For those of you,  who don't know what this means,  here's what it  means:
  140.  Bottom-up  programming  is a certain way of setting up your program.   The
  141.  idea is to start by thinking of all the procedures you'll probably need to
  142.  make the program you want.  Next, you make these procedures, which will be
  143.  added as new commands to your programming language (in some languages, you
  144.  can't  see  any  differance  between  home-made  procedures  and primitive
  145.  commands, but in some you can,  anyway:  imagine there is no differance at
  146.  all).
  147.  
  148.  It  isn't  easy  to find the right procedures.   But once you're past this
  149.  stage, programming was never so easy.  Here's some examples:
  150.  
  151.  - Block_can_be_on (x, y)
  152.  - Put_block (x, y)
  153.  - Draw_block (x, y)
  154.  - Rotate_left
  155.  - Rotate_right
  156.  - Move_to (x, y)
  157.  - Move_left
  158.  - Move_right
  159.  
  160.  In this set <Move_left> could be defined as follows:
  161.  
  162.     PROC Move_left:
  163.        IF Block_can_be_on (x-1, y)
  164.        THEN Move_to (x-1, y)
  165.        END IF
  166.     END Move_Left
  167.  
  168.  
  169.  --------------------------------------------------------------------------
  170.  PART II: Decisions to be made
  171.  --------------------------------------------------------------------------
  172.  
  173. VARIABLES VS CONSTANTS
  174.  
  175.  With  things like the pit width and score per figure you can decide to use
  176.  either variables or constants.  You can also choose to type actual numbers
  177.  in your program,  but this is simply stupid.   I chose to put almost every
  178.  value in a variable, because that's what makes Multris Multris.
  179.  
  180.  
  181. PIT SIZE
  182.  
  183.  The traditional width is 10 and the height depends on  the  speed  of  the
  184.  figures; if the blocks fall at low speed, you might want to consider using
  185.  a shallow pit, te keep the game from getting to easy.
  186.  
  187.  
  188. COLOURS
  189.  
  190.  I used 2 colors, so that one can easilly distinguish
  191.  
  192.     ##    from      ##
  193.      ##         ##
  194.  
  195.  There isn't really a general colour code for Tetris,  except for these two
  196.  figures:
  197.  
  198.     ####    and    ##
  199.             ##
  200.  
  201.  The left one is always red and the right one is mostly blue.
  202.  
  203.  
  204. NEXT ON/OFF
  205.  
  206.  If  you  ask  me,  you shouldn't show the next figure.   It makes the game
  207.  easier in the first levels, but it doesn't make it any easier in the later
  208.  levels, as you don't have time to look at the it than.  But if you do want
  209.  to implement this OPTION (!!!!!) consider showing the next <n> figures, as
  210.  this will make it easier for you to make it look nice on the screen.
  211.  
  212.  
  213. ANTI-MONITOR
  214.  
  215.  Monitors (espially old ones) are not flat.   This makes it hard for you to
  216.  guess where your block will end up if you drop  it.   You  might  want  to
  217.  compensate this.  I know four ways of doing this:   (1) - Place the pit in
  218.  the middle of the screen, where the monitor is flattest      (2) - Use big
  219.  figures       (3) - Make a gridded (not nessesarily horizontal) background
  220.  (4) - Draw a shadow of the figure at the bottom of the pit, like this:
  221.  
  222.     |    |            |    |
  223.     |  ##   |            |  ##   |
  224.     | ##    |  or even like this:    | ##    | (the * is the same as
  225.     |    |            |    |  #, but brighter.)
  226.     |     # |            |     # |
  227.     |#  ####|            |#  ####|
  228.     +-------+            +-------+
  229.       ###                  ##*
  230.  
  231.  
  232. LUCK
  233.  
  234.  Good luck programming Yourtris!!!
  235.  
  236.     S. Raaijmakers,
  237.     Student Computer Science (informatica)
  238.     University of Nijmegen (KUN).
  239.  
  240.  If you have any suggestions, questions or comments, please contact me.  If
  241.  you have access to Internet, use E-mail; this will insure you of getting a
  242.  reply.  Here's my adress:
  243.  
  244.     Heijendaalse weg 54
  245.     6524 SP  Nijmegen
  246.     HOLLAND
  247.