What Project Should I Work On?

It’s been a week since I last posted but HotSheet has been continuing in the interim. In fact, continuing isn’t really the word because the project got its first two contributions from developers other than me and there are three more assigned to features right now!
Since HotSheet is moving along rapidly towards the end of the tunnel I find myself thinking forward to what my next project should be. Part of me wants to do something quick to get another tool that I could really use and part of me wants to work on a game. Just the other day I was telling this guy that I had lost a lot of my interest in game development websites because building one helps you learn how to build websites, it doesn’t move you along to building actual games. It’s been more than four years since I started on my first one and I don’t feel like I’m any farther down the path of building games.
So, if you are reading this, tell me which of the following I should do next:

  1. Hailstorm has as a central tenet that we should put our data “out there somewhere” on the Internet so we can access it from anywhere. This project would put that to the test with something that real people (like me) need regularly, synchronized bookmarks. Build a central server system that would allow you to have the exact same set of bookmarks no matter where you go or which browser you use. I would like to be able to go to work and use Mozilla and I use Mozilla and IE from home. It should have the following features:
    • I want the synchronization to be available cross machine and cross browser. If it can be inserted directly into the browser as a standard feature (i.e. Mozilla) it should, if not, then we need to be able to monitor for changes and update on the fly using an external process.
    • I want to be able to specify that a machine or browser has only a subset of those bookmarks available. I don’t need my game and comic book links at work.
    • The interface should be SOAP or XML-RPC so it can easily be used from a wide variety of programming languages and so it can flow through a firewall easily.
    • Export to a file formats like OPML or XBEL should be available to work with tools that don’t need direct access.
    • The server should be trivial to setup and run from any machine but Don and I could probably offer a server for anyone who doesn’t have a permanent connection on which to setup a server for a dollar or two a year.
  2. Work on a game. The one game I’ve spent the most time designing and working on the last couple of years is a standardized platform to play any collectible card game (i.e. Magic the Gathering, Pokemon, Mythos, Harry Potter, etc.) against another player over the Internet. The software would make no effort to actually enforce the rules of the game but would only:
    • Offer absolutely fair shuffling and card handling. There are methods that incorporate encryption that would prevent either player from being able to use a cheat tool to look in the memory on his/her machine and see the cards that are in the decks, the order they are in or the cards of the other player. None of the other utilities like this have any kind of cheat protection.
    • Offer the ability to place tokens, turn cards 90/180/270 degrees or flip them, flip a coin (again using fairness algorithms).
    • Save and restore games in progress.
    • Provide good chatting capability with other players. This could potentially just consist of incorporating Jabber into the game so you’ve got built in buddy list and chat using proven technology (and there are multiple Java libs to access Jabber).
    • Keep track of counters for things like score.
    • Draw the cards and draw the board.
    • Provide a simple tool for editing a deck of “cards” that you want to use in the game.
    • Look attractive. I think I got a good start on that with HotSheet and I believe it’s important. If your application looks reasonably professional and is reasonably attactive it will be more approachable by end users.