A very simple Perl SDL tower defense game.

To run:

> cd camel-defense/eg # or images will not be found
> perl 04-world.pl

What works:

    1- grid with waypoints and path painted (only straight lines and 90 degree
       angles allowed)
    2- creeps which follow the waypoints with enter/leave grid animations, 
       and explosions on death
    3- 3 types of fully operational towers that can be placed using the cursor
    4- a world object that lets you configure all of the above in its
       constructor

Next tasks:

   UI
   Towers cost money
   Tower selection and upgrade
   Level object
   Levels

Requires:

   aliased
   Data::Average
   SDL
   Moose
   MooseX::Types
   MooseX::Role::BuildInstanceOf
   EV
   Coro
   SDLx::Controller::Coro
   SDLx::Coro::REPL
   Set::Object

Credit:

   Explosion sprites are from opengameart.org, attributed to:
       "Iron Plague" art by Daniel Cook (Lostgarden.com)

-------------------------------------notes--------------------------------------

TODO
    range circles make rendering slow
    check why bg layer refresh trick dont work
    checks for creeps in range using better ds than list
    when FPS is very low, compute damage on creep if it passed through range during
        fire time during the last dt, because it could have jumped
    add intelligence getter on wave manager which answers how many waves left,
        what creeps, etc.
    rename Grid to Map?    
    composite waves for different creeps in a single wave
    add $ with X on it for cursor shadow when building tower and no money
    get stuff from opengameart.org
    with coro we can make slow objects update less often
    accuracy- if creep moves more than 1px per position update could be that
        we passed some tower range so look not for tower in range of position
        but of all positions passed in last sleep

Game objects, layers, and z-index in layer:

    world
        grid
1 2         markers
1 1             background
1 4         waypoints
1 5             path
        tower
1 6         sprite
1 3         range
2 1         laser
        wave
2 2         creep
2 3             health bar
        cursor
2 6         sprite 
2 5         shadow
2 4             range

   

Sorted by z-index:

1 1 background            markers
1 2 markers               markers
1 3 tower range           tower
1 4 waypoints             waypoints
1 5 path                  waypoints
1 6 tower sprite          tower
2 1 laser                 tower
2 2 creep                 creep
2 3 health bar            creep

2 4 cursor shadow range   cursor
2 5 cursor shadow         cursor
2 6 cursor sprite         cursor

Ideas    
    do it on top of a satellite map, of where you live, let the mapping service do pathfinding
    use sat map objects like cars for creeps
    smart creeps split when they think you are juggling
    smart creeps that can attack your towers if they think it will get them to the end faster
    lose the health of the creep that got through, not 1 per creep
    select your creeps from a palette
    let you select target creep priority
    make it more strategic by letting you pause and do anything while paused
    visual style- action figures
    http://kalogirou.net/2005/08/10/multithreaded-game-scripting-with-stackless-python/
    Tie::RangeHash QuadTree Array::IntSpan for keeping relationship between towers and creeps
    http://search.cpan.org/~tels/Games-Console-0.04/lib/Games/Console.pm
    http://conal.net/fran/tutorial.htm fran examples

Layers:
    1 - bg - redrawn every tower build/sell/upgrade
    2 - fg - redrawn every show handler
    3 - cursor - ditto

renderer
    has layer renderers for fg and bg

you can still call render on world, or you can call render on a layer
manager you create on it

how to connect renderer to visual objects:

1- give all visobjs the renderer, they render on it instead of app surface
   - now everybody needs to know about the renderer
   - cant display any visobj without creating and attaching a renderer

2- same as 1, but objs dont render on the renderer. instead they just register
   - not as bad as everybody needs to know renderer, but stil everybody needs to know how to register with it
   - renderer calls render methods on objs

3- renderer gets world, navigates, calls render, adds callback for dirtiness   
   - bad demeter

4- same as 3 but renderer gets world, which has role composite, navigates composition

5- renderer adds to the specific classes that need rendering a role which has a BUILD
   or better- adds role to objects in the composition

6- add aspect on any constructor called where the parent object has call flow aspect
   of code called from renderer init which is configed as world->new (problem
   with laziness). advice registers the obj , giving layer and Z index by class
   renderer keeps a heap of objects per layer sorted by z index

   
next wave
pause


seconds, and then every $repeat seconds. The timer does his best not
        to drift, but it will not invoke the timer more often then once per
        event loop iteration, and might drift in other cases. If that isn't
        acceptable, look at EV::periodic, which can provide long-term stable
        timers.