Move quit event handling to the interface and flatten the Action class
hierarchy. There are no longer any actions that don't take an Actor. This has
the happy side effect of resolving some pylint errors too. :)
- Rect and Room method objects no longer need to know the map size up front
- The Map object has lists of interesting map features (I don't like this)
- Room and corridor generators take the map itself as an argument to their
generate and apply methods
- Create a Corridor object to hold a list of points
- Add a bunch of documentation here and there
Events start in the Interface. The interface gets first crack at any incoming
events. If the interface doesn't handle the event, it is given to the
engine. The engine has an EngineEventHandler that yields actions just
like the event handler prior to this change.
The interface's event handler passes events to each window in the
interface. Windows can choose to handle events however they like, and
they return a bool indicating whether the event was fully handled.
Use the new map generator mechanism to generate rooms via cellular
atomata. Create a new CellularAtomatonRoomMethod class that uses
the Cellular Atomton class to create a room. Add a FreefromRoom class
that draws a room based on an ndarray of tiles.
Along the way I discovered I have misunderstood how numpy arrays
organize rows and columns. The numpy array creation routines take an
'order' argument that specifies whether arrays should be in C order (row
major) or Fortran order (column major). Fortran order lets you index
arrays with a more natural [x, y] coordinate order, and that's what the
tutorials I've read have shown. So I've been using that. When I was
developing the Cellular Atomaton, I wrote some code that assumed row-
major order. I think I want to move everything to row-major / C-style,
but that will take a bit more time.
A RoomGenerator is now made up of two "method" classes that do separate
things:
1. A RectMethod takes the size of the area to generate and creates an
iterable stream of Rects to fill that area.
2. A RoomMethod takes a Rect and creates a room inside of it.
These two components are composable in interesting ways, and allow a
more data-driven approach to map generation, though I don't yet have the
ability to make this mechansim entirely data-driven.
There was a bug in how MapWindow was calculating the numpy array slices
when drawing the map. Redo how this works so that MapWindow can draw
maps of arbitrary size and center maps that are smaller than the window's
drawable area.
- Add Point.numpy_index to simplify converting Points to indexes
- Update the doc string of Point.direction_to_adjacent_point
- Add a Rect.__contains__ implementation for another Rect
- Refactor the contains implementations above into helper methods
First pass at a cellular atomata map generator.
Add map.grid and a make_grid function to make it easier to make
numpy arrays for Map purposes.
Add ca.py to test the generator.