Dogcows Code - chaz/yoink/blob - README

   1
   2 Yoink - The alien-smashing action game
   3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   4
   5 Contents:
   6
   7 I.   Users
   8   a)   General information
   9   b)   Requirements
  10   c)   Installing
  11   d)   License
  12 II.  Developers and Packagers
  13   a)   Notes regarding the code
  14   b)   Packaging
  15   c)   Sending patches
  16
  17
  18 I. Users
  19 ========
  20
  21 a) General information
  22 ----------------------
  23
  24 Yoink is a game created by Neil Carter for Mac OS.  You play the part of a
  25 flying alien heroine who must defend her home on Earth from other airborne
  26 alien invaders.
  27
  28 This version of the game uses all new code and modern frameworks to bring
  29 this simple, fast-moving action game to a wider audience.
  30
  31 b) Requirements
  32 ---------------
  33
  34 boost headers
  35 libpng
  36 libvorbis
  37 Lua
  38 OpenAL
  39 OpenGL (including GLU)
  40 pkg-config
  41 SDL
  42
  43 c) Installing
  44 -------------
  45
  46 To build and install Yoink yourself, you should first make sure you have
  47 all the required libraries.  Then, issue these commands at a command-line
  48 prompt:
  49
  50  cd /path/to/project
  51  ./configure
  52  make && make install
  53
  54 where /path/to/project is the path to the directory where this file is.
  55
  56 That will compile and install Yoink into the /usr/local directory.  To run
  57 Yoink, issue this command:
  58
  59  /usr/local/bin/yoink
  60
  61 or just ``yoink'' if /usr/loca/bin is already in your PATH.  You can also
  62 install Yoink to a different directory or change a lot of build options
  63 using the configure script.  See ./configure --help and the file INSTALL
  64 for details.
  65
  66 d) License
  67 ----------
  68
  69 The new code is released under the 2-clause BSD license.  The old code and
  70 original resources are provided under the zlib/libpng License.  See file
  71 COPYING for complete details.  The full texts of applicable licenses can be
  72 found in doc/licenses.
  73
  74
  75 II. Developers and Packagers
  76 ============================
  77
  78 a) Notes regarding the code
  79 ---------------------------
  80
  81 The code is a complete rewrite, containing none of the original code.  I've
  82 made some effort to put the more generic or reusable code into a separate
  83 library called libmoof.  I've also made an effort to incorporate 3rd-party
  84 code that happened to fit well into what I needed.  So, generally, the
  85 source code is separated into these three categories:
  86
  87 1. Yoink-specific code.
  88
  89 This is the code in the directory src.  These classes reside in no explicit
  90 namespace.
  91
  92 2. Reusable code.
  93
  94 The code is in src/moof, and it is compiled as a convenience library.
  95 These classes and helper functions reside in the moof namespace.  Since I
  96 wrote this code alongside the Yoink-specific stuff, there is somewhat of a
  97 blurry line between the two categories, unfortunately.
  98
  99 3. Third-party code.
 100
 101 This is made up of free code from other projects or libraries (aside from
 102 the explicit dependencies above), the licenses of which are also noted in
 103 the file COPYING.  This code resides in various namespaces and in various
 104 subdirectories of src.
 105
 106 b) Packaging
 107 ------------
 108
 109 Here are some tips to help packagers:
 110
 111 *  The build scripts are written in Lua, so make sure the Lua interpreter
 112    is installed.  That shouldn't be a problem since Yoink depends on the
 113    Lua library anyway.
 114
 115 *  The makefile will probably only work well with GNU make.  On some
 116    systems, this is installed as gmake.
 117
 118 *  The configure script supports most of the useful options that an
 119    autoconf-generated script would have, and the makefile supports DESTDIR.
 120
 121 c) Sending patches
 122 ------------------
 123
 124 I'll gladly entertain patches if you want to help out.  Just email me your
 125 stuff or tell me where to pull if you use git.  If you're interested in
 126 that, please observe the following:
 127
 128 *  Stick to the coding style of the source code files you edit.  Follow the
 129    general style of method and variable naming, as well as white space
 130    formatting.  In particular, use literal tabs with an assumed tabstop of
 131    4 characters.  Also, try to limit line lengths to 75 characters.
 132
 133 *  For legal reasons, don't include other peoples' code with your patch.
 134    You must also agree to license your changes according to the same terms
 135    and conditions as the files you edit, usually the 2-clause BSD license.
 136
 137 *  If you want your name and contact information in the file AUTHORS,
 138    please make it so in the patch you provide.
 139