home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / games / 13560 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  2.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!cronkite.Central.Sun.COM!texsun!exucom.exu.ericsson.se!s09a05!exuhag
  2. From: exuhag@exu.ericsson.se (James Hague)
  3. Newsgroups: comp.sys.mac.games
  4. Subject: Re: Mac Game Programming Secrets?
  5. Message-ID: <1992Dec28.201718.9648@exu.ericsson.se>
  6. Date: 28 Dec 92 20:17:18 GMT
  7. References: <Bzp0F5.8B4@news.cso.uiuc.edu>
  8. Sender: news@exu.ericsson.se
  9. Reply-To: exuhag@exu.ericsson.se
  10. Organization: Ericsson Network Systems, Richardson, TX
  11. Lines: 40
  12. Nntp-Posting-Host: s09a05.exu.ericsson.se
  13. X-Disclaimer: This article was posted by a user at Ericsson.
  14.               Any opinions expressed are strictly those of the
  15.               user and not necessarily those of Ericsson.
  16.  
  17. Just a few late additions:
  18.  
  19. - Game programming for *any* platform takes a lot of hard work
  20.   and inspiration.  There are no exceptions.  If you are inspired
  21.   enough you can get past any obstacles.  There were quite a few
  22.   classic Apple II games that were written by people who were driven
  23.   to learn to write games.  They found out that they needed to
  24.   learn assembly language to do it, so they did.  Hi-res graphics
  25.   required all sorts of weird programming to get proper colors, so
  26.   they figured it out.  Writing games requires solving problems on
  27.   your own, things you aren't going to find in books.  It is only
  28.   natural that the sort of person that can design games on their
  29.   own can also figure out the programming aspects without outside
  30.   help.
  31.  
  32.   [I've always found it interesting that there is no correlation
  33.   between quality games and ease of implementation.  Look at the
  34.   sticks and mud used to create Asteroids, Star Castle, Tempest,
  35.   Defender, etc.  Programming tools are much better these days,
  36.   computers are way faster, optimizing high-level language compilers
  37.   are the norm, yet overall game innovation and design seems to
  38.   have declined.  More effort seem to be expended cloning those
  39.   old games than writing new ones--and most times the original
  40.   is still superior.] 
  41.  
  42. - Don't concentrate solely on the technical aspects, just do what
  43.   you need to write a game.  Most popular IBM shareware games are
  44.   technically brilliant, but just plain awful in terms of concept
  45.   and design.  Rec.games.programmer is filled with discussions
  46.   of VGA registers and blit routines ad nauseum.  Everyone is
  47.   concerned with technical junk and the games really show it. 
  48.   
  49.   A related "rule" is:  every game does _not_ have to make some
  50.   sort of technical innovation.  There are lots of pleasant
  51.   little games (john calhoun's stuff comes to mind) which aren't
  52.   cutting edge and don't need to be. 
  53.  
  54. --
  55. James Hague   
  56. exuhag@exu.ericsson.se
  57.