TDDing a Card Game - The Why and What

I've noticed, while reading the previous three entries, I haven't made very clear my plan. I've described the game, and jumped right into the code. I haven't given a clear direction for this project. Also, I haven't explained why I'm writing this. So I'm going to spend this post explaining the Why and the What of this series.

First, the Why

I was first introduced to TDD over two years ago. Since that time I have regularly tried to apply it in the work that I do, but often the code base and time constraints conspire against my efforts to work in a completely test driven fashion. While I am often impressed by the simplicity TDD helps me create, I regularly find myself stuck against something I don't know how to test. In the face of looming deadlines I often buckle and just code up a mess that kind of works for now.
Chad Fowler's book on architecting your career is the reason I started this blog. As result of that first exercise from the book, I realized that publishing could provide a good way of reflecting on why and how I do the things I do. This reflection will be a crucial part of improving my skills and abilities. I decided I needed a project to practice in a completely test driven way.

Now, the What

In the first post in this series I described the card game Spit. I then jumped right into implementing it. I kind of had in my head where I was planning to go, but it is not as clear as it could be. Since my time to devote to writing this is limited, and I am often absent minded, I need to write down a high level path that will help me resume when I need too.
The first three entries in this series are headed towards a player versus AI on the command line type game. One of the primary goals for me in writing this program is to stretch my ability in places where I think TDD will be hard. With that in mind, I want a full GUI player versus AI mode to help explore the difficulties I imagine for test driving GUIs. A player API to allow custom AI players would be neat. Player versus player mode would expose some of the perceived difficulty in testing network interactions. A web application for player versus player mode right in a browser would allow me to explore Ruby on Rails.
Whew! Did I leave out anything? I know all that is extremely ambitious. In fact, it seems a lot like that first meeting with a customer when they have a great new idea. Well good. Sometimes I think I will put a customer hat on and review the work I've done and strategize about the next steps. For now I'll put the hat away and in the next entry I'll work towards the command line version of the game.