Design Decisions: Choosing an output library.

When developing in Python, the options for the output are rather limited -- only curses and SDL (via pygame) are available.  In theory there's also libtcod, which sits on top of pygame, but despite how much it touts being cross-platform unlike straight up pygame it refuses to work on 64-bit OS X, making it a poor choice for this particular developer.
Of the remaining two, curses is easier to use and is, in theory, more cross-platform.  It opens up the option to run the game in any terminal, in screen or over ssh.  It could then conceivably be adapted to run via dgamelaunch -- a definite plus.  Now, the downsides:  the output is entirely at the mercy of the terminal, and there may need to be specific code changes to enable the game to display properly on any available terminals.  It also leaves it up the user to properly configure their terminal colors, and furthermore the color options are going to necessarily be limited to xterm-colors to allow for widest support.
Pygame, on the other hand, is more challenging to develop for, as it deals with images rather than characters.  Hence, more aspects of the game would need to be written from scratch.  The benefits are huge, however -- cross platform compatibility ends up actually being greater, even as far as (in theory) running on Android devices.  Additional huge pluses are: ability to have hexagonal grids (which is something I have been seriously considering), and a multitude of colors for greater gradations (important when lighting has significant in-game implications).

For now the winner is clearly pygame.

Design Decisions: Picking a language.

Ultimately I have managed to boil it down to two choices -- C++, and Python.  While Lua is popular lately and would open up the opportunity for me to use the TOME library, I chose not to spend the time to learn a different language when I can focus on improving my expertise in a language I can use for work.
Between the two, C++ offers the advantage of static typing, and, as a result, a more rigid development structure that may be of benefit as the project gets larger.  Python, on the other hand, offers rapid development and a pleasant and intuitive syntax.  I have settled on using Python for now and perhaps delegate any potential computationally intensive processing to a C++ library I can always introduce.  Pyrex was considered, but for the time being not thought necessary.

A trivial roguelike.

Created a trivial roguelike using python + pygame.  It is completely useless as a game, but could be a good starting point for someone else trying to write something in the genre.

https://github.com/megawidget/trapped

It has begun.

I have finally broken down and decided to code up my own Roguelike, from scratch -- an idea I have been mulling over for a while now.  This blog is intended to keep track of my misadventures, solicit advice, and act as a motivational tool for me to continue this daunting task.