The Rules

1. Genre requirements

   Survival

   The objective of the game must be to stay alive. Ideally there will be difficult situations that must be overcome. The game could be unbeatable, only ending when the player dies, or it could have an achievable end—it doesn't really matter :). As long as staying alive is a priority...

2. Technical requirements

   There are two technical requirements:

   1. Make it a Classic

      You must implement at least one of the following:

      • Maximum of 320x200 game resolution and maximum of 16 simultaneous colors. For compatibility reasons, the screen resolution may be whatever you want to use. For instance, you could use a 160x120 internal resolution that is stretched to 640x480. If your graphics are scalable, it is fine to include higher native resolutions—but the default settings must be no higher than 320x200 and the game must be designed to play well at that resolution.
        
        
      • A palette of six “gray scale” colors. You must use a single hue with up to six different combinations of saturation and brightness. Don't worry, we aren't going to have the fashion police analyze your colors. The key is to use a single color, like all blues or all greens or all grays.
        
        
      • Four button joystick with no mouse or keyboard support. The only way to control the game is via a NES style joystick: start, select, A, B. Only two of the buttons can be action / core game play buttons. You may (and should) emulate the joystick via the keyboard. The mapping is up to you, but the arrow keys could be used as the digital pad, CTRL and ALT for the fire buttons, and Tab and Enter for select and start. For example, if you have a high score list, the user must enter his name by selecting a letter via the cursor keys and then pressing a fire button to select it.

      Again, you only have to implement one of the above restrictions. If you want to be adventurous, try all three.

   2. Randomness

      Games that play exactly the same every time quickly get boring. Considering you only have 72 hours to complete your game, you won't have much time to design huge sets of levels.

      Some part of the game must be generated randomly and be different every time you play. It should noticeably affect the game (like a randomly generated landscape or maze), but it could be as simple as a random color scheme.

3. Artistic requirements

   There are two artistic requirements:

   1. Dichotomy

      Dichotomy is defined as "division into two usually contradictory parts or opinions." Incorporate opposites into the game.

   2. World Map

      Implement some type of world map, if applicable to your game. You may opt out of this rule if your game has no concept of location. However, if you think hard enough you should be able to come up with something.

      It could be in the street-fighter style where you are shown flying to the next country. You could also have a world map that allows the gamer to pick from a list of challenges. If the game has a linear path, you could show how far the gamer has progressed.

4. Bonus rules

   There is one bonus rule:

   1. Act of IP

      You may opt out of one other rule if you choose to implement networking. It must dynamically affect the game play. Simply having your entry download a static file or doing something trivial does not count. If you have any questions, ask before you get working on it!

5. Other Important Info

   All entries must be submitted via the online form on or before 12:00 UTC on Monday 15th August without fail. All entries must be supplied in a ZIP file equal to or less than 250 KB in size. All source code, makefiles, documentation, and references to additional libraries used must be supplied in the ZIP file.

   You can assume that everyone will have a copy of Allegro 4.0 (standard installation) installed. You do not need to supply one. It is okay to use a more recent version of Allegro, but if someone is unable to compile your game because of that, it's your fault. You should consider uploading binaries for people who have problems compiling the source onto your own website. I will be checking that the binary and source match up, so adding enhancements to the 'competition binary' is not permitted.

   If source code is reused from legal sources (your own, GPLed, public domain) you should declare this and what changes have been made, so that your work can be assessed for the voting.

   People should keep a informative and interesting account of their development through the competition. This can be sent after the competition for those people with no Internet access over the weekend. This does not affect your space requirement.

   A web-based "blog" update page is available. This will allow spectators to see what is going on :-)

   You can make use of all information sources, mailing lists as you see fit. This is not an exam! :-)