[NIGHT OF THE LIVING NERD], SpeedHack 2007
by 
Dennis Busch (Concept,Code,Graphics,Samples)
Pedro Avelar Gontijo (Music, Name Of The Game)

A.cc Names: 
Dennis
PedroAGontijo

Website: http://www.dennisbusch.de/notln.php


 Tools and Libraries Used
-----------------------------------------------------------------------

 Compiler/IDE: MSVC

 Platform: Windows (should compile for everything else that has Allegro support)

 Language: C++ (well, kind of, not using proper classes or anything fancy)

 Tools used:
   * PSP8
   * Personal Paint (under Amiga Emulation)
   * TTF2PCX
   * Audacity (and a mic)
   * Guitar Pro 5

 Other libraries used:
   * none


 Notes on Compiling
-----------------------------------------------------------------------

No specific notes. Just run the makefile. 
Note that STATICLINK=1 did not work on my system(with MinGW), got a lot of undefined references with that.
Without it though, it compiled without any warnings.


 SpeedHack 07 Rules
-----------------------------------------------------------------------

   1.
      Genre requirements
      Evilness
      You must be the evil bad guy, destroying all the good guys who oppose you. Evil deeds and acts are to be rewarded in the game, regardless if the actions affect the outcome of the game.
      Mercy and compassion have no place in the game.
   2.
      Technical requirements
      There are three technical requirements:
         1.
            Radius of Influence
            Some objects must have a property that will affect other objects within a given radius. The effect must be proportional to the distance between the objects.
            (The radius doesn't literally have to be implemented as an exact, geometric circle. Neither does the proportionality have to follow any precise, continuous formula.)
         2.
            Get a Grip
            The game must feature characters or objects that are affected differently depending on the amount of friction of the surface with which they are in contact.
         3.
            Ratio, Respect!
            Many LCD screens have a widescreen format instead of the traditional 4:3 ratio. You must support at least one widescreen and one fullscreen resolution. Widescreen is defined to be any width:height ratio equal to or larger than 1.5:1; fullscreen is anything less than that. There must be an option to switch between resolutions inside the game. (It could be via a keypress, a config menu, etc. It doesn't have to take effect immediately.)
            So, for example, if your game supports 1024x768 and 1366x768 (a common LCD TV resolution), it would satisify this requirement because 1024/768 < 1.5 and 1366/768 >= 1.5.
            Preferably for the default resolution, you would detect the current ratio via get_desktop_resolution() and make a best guess based off of that. (The ideal solution would be to support the desktop's resolution, whatever it may be!) If you set an arbitrary widescreen resolution, it is recommended that you choose a common one.
            It is up to you to determine how you want to use the space. If your game is meant to run at 640x480, a widescreen resolution of 768x480 would give you 128 extra columns. You should try to use this space to display additional status information, a larger view, etc. (Alternatively, your game may be designed to run in widescreen natively, in which case you'd have to chop content out for the full screen or scale it down.)
            There is one restriction: you cannot simply use a solid (eg: black) bar to fill the "extra" space. If you choose to use meaningless filler, at the very least it must be some sort of graphical "chrome" or pattern.
   3.
      Artistic requirements
      There are two artistic requirements:
         1.
            Reverse Stereotypes
            Ignore traditional roles for characters of a given gender/race/species/age and make something novel out of it. For example, you could implement this as a spoof of a specific game (eg: the princess rescues a plumber) or as a reversal of typical, real-world stereotypes.
         2.
            Dialogue
            The game must feature interactive dialogue, and the choices made by the player must affect the gameplay, even if only in a small way.
   4.
      Bonus rules
      There is one optional bonus rule:
         1.
            Act of Generosity
            You may disregard one technical or artistic requirement without penalty.
            If you choose to invoke this Act, you must explicitly state in your readme.txt which requirement you have ignored.
   5.
      Other Important Info
      All entries must comply with all requirements except where made void by the Bonus rule.
      All entries must be submitted via the online form on or before 12:00 UTC on Monday 17th September 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.2 (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! :-)



 About the Game
-----------------------------------------------------------------------
(details on how the rules were implemented are in "rules_applied.txt")
(make sure you read that "rules_applied.txt" file to get what the game is about as repeating it all in here would be silly and a waste of space)

You need to defend against the enemy.
Game will be over when the first enemy reaches your "code safe".

Now, really, if you haven't read "rules_applied.txt" yet, do it now! :)
Have fun!


 How to Play
-----------------------------------------------------------------------

CURSOR LEFT = move left
CURSOR RIGHT = move right
CURSOR DOWN = stop moving
click (in upper screen area) = move
click (in lower screen area) = shoot (if inside range)
rightlick or SPACE = cycle weapon