Anticipation
I just bought a UK import of the Collectors' Pack of Family Guy (Seasons 1 - 5) from Amazon. I now am feeling the painful sting of waiting. On the plus (or neutral, cancelled out) side, though I paid 20eu more than I would have had to if I simply bought all of the DVDs individually, I will get them all at once sometime next week. Had I bought them separately, one would've come next week, two would've come in 4-6 weeks, and the others would have come in an unknown amount of time due to not being in stock. I figured it was worth the extra money to get all 5 "auf Lager" rather than mess with this. Not to mention the shipping was free, whereas with different ship dates sometimes Amazon.de will split the shipping costs among the items based on availability thus disqualifying you from the free shipping promotions they're always running.
In other news, I've finished the first stable version of my full-featured playing card library written entirely in ISO Standard C++. I'm working on a separate graphical version using SDL to speed up the process of writing graphical card games (as the card games available in the FreeBSD ports collection for the most part leave something to be desired). Well, let's face it. The games section of /usr/ports in general leaves a lot to be desired. And that time I installed PySol just because it claimed to have "Tarock" only to turn out to be "solitaire with Tarock cards" left me feeling a little burned. My kingdom for a free version of Zwanzigerrufen. It wouldn't be that hard to write, actually, it's just that Zwanzigerrufen (and other forms of Tarock to an even greater extent, but I prefer XXrufen because it has the fewest rules to have to memorise) has a lot of strategy that changes depending on the type of game you're playing.
If you're wondering why I didn't just write a graphical version to begin with, or alongside with the standard version, that's simply because the base library is 100% portable to any compiler that supports the 1999 C++ standard. It doesn't use any non-C++ headers except for two, which are only necessary for randomised shuffling and as they are part of the C standard, there should likewise be no portability problems there. Also there are some cases where it pays to have an object-oriented card handling library, but the actual implementation of those cards is either irrelevant or is better left to the developer. As an illustration of some of its uses in the normal console, the source includes some examples that do simple things such as a Faro Shuffle, the Hi-Lo card counting method that people used to use in blackjack before casinos got wise, and a simple, automated implementation of the children's game War. I'm also working on some examples for the SDL version as I find the best way to test the maturity and stability of a library is to work on actual programs that are built alongside. It's only in that way that one can try something and say, "Hm, that's not working the way I expected," or "Man, I wish this had feature X" or "You know, on second thought I really don't need function Y in this class." One of the benefits of putting all of the card handling into a library is that I don't need to worry about it now when developing a game. If I want to create a standard Go Fish table I just have to do something like the following:
const unsigned int uiHandSize = 5; // number of cards per hand
const unsigned int uiNumberofPlayers = 4;
cards::Deck deckGoFish; cards::Pile pileGoFish;
std::vector
deckGoFish.shuffle();
deckGoFish.dealOut(&vGoFishHands, &pileGoFish, uiHandSize);
...blah blah blah...
As you can see, I've shuffled, dealt out the cards, and am ready to establish the rules of the game after only 6-7 lines of rather easy to read code. The aforementioned War game example took me perhaps 20 minutes to write, produce a Makefile for, and debug.

