The coding techniques.

So the coding inspiration came from this rubyquiz:
http://www.rubyquiz.com/quiz71.html in which a basic structure was
specified simply by making a player object and each location the player
can enter is an object that has a handle_event method that takes the
player as an argument:

	loop { player[:location].handle_event(player) }

The quiz had people independently implement sectors, stations, planets,
etc and share API details for others to abuse.  The one common factor in
the whole affair is that the game was assumed to be a text-only
single-player game.  So there's only one player object and all the game
UI is gets/puts lines entered manually into location methods.

My plan is to have I/O handled through player methods provided by a
mixin.  This way you can have text, curses, gui, whatever based on what
mixin gets loaded.

So the sector handle_event might call player.display_sector(stations,
planets, uncloaked_ships) or whatever (maybe invoke some sensor accessor
to roll for scanning success on cloaks) and then mark the sector as seen
and return.  The next time handle_event happens it might just poll the
player object for an action taken.

And naturally that loop will manage events seen by AIs, creation and
exit of AIs and players, turn rollover events as well as non-turn, etc
etc etc.

Since input is either keystroke input from a telnet interface or
line-at-a-time via some network protocol, we'll probably just do a big
select on input fds and pass input along to handling functions of
players they came from.  

So at the top level we handle three things:
	1. Locations handling events and passing info on to AI/players
	2. Passing player input to player objects, and the results of
any of this goes to player locations.
	3. Disconnections and other errors

The player object provides methods for displaying an entire location's
data, displaying an update to the current display, and returning an
action chosen by the player.  

So let's say the Player View API (defined as a mixin module) is:
	Player.display_location(attributes, contents)
	Player.update_event(event)
	Player.get_choice()

events will be a symbol for type, and some event data (like what object
acted, what on, by how much, what result, etc.)  The display_location is
a sort of full-frame "look" command, that shows you the location you're
in and the state of all its contents.  Finally the get_choice() method
returns the next bit of player input (however valid or invalid) or nil
if nothing's been chosen.

My thoughts so far have had a very simple plain-text log structured
output as the reference/base module for the view mixin.  This will just
do puts of one-line messages.  Then the more advanced display methods
can start by wrapping the base in some sort of log window output, and
slowly replace the methods that need more advanced display
characteristics.  This way