Second Post in as Many Days

I'm working my towards a new record here.

     So, I'd ask for help from my readership with getting pygame to work properly, but, since my readership still consists of fewer than three people, I already know that none of you know how to fix my problem.  Since I'm trying to keep up with a post a day (so that I at least have one post a week since I'm sure I'll forget/be lazy a lot), so I guess I'll just ramble on about the game I'm working on.
     The Color Revolution:  Sometimes Things Aren't Always Black and White (cleverly suggested by one of the two [or possibly the one] readers of my blog and Chief Executive Accounting Orderly Somethingorother of said game) is an RTS set in the world of Flatland.  I won't go into detail about the premise, since, as I seem to keep saying, there are only one or two readers.  What I've been thinking about is that units ought not to be recruited during a skirmish.  In all the RTSes and turn-based strategy games I've played except one, the player recruits units during the battle.  I think that's a bit unrealistic, considering the time-frame of most of these games.  The problem is, it would be a little difficult to make a game where one does not recruit units interesting.  Both sides would normally start on equal footing, I suppose, with equal numbers of units (or at least units with an equal number of point values [foot soldier = 1, Chuck Norris = ∞, etc., etc.), and, if the players were both not stupid and trying to win, would both quickly set up camp in easy-to-defend locations and wait for the enemy to attack.  Whoever got bored first would lose and matches between professionals might take years.  I've been considering the problem and I may have a solution, though it's one I find to be less than ideal.  That solution is to not allow the production of units but allow the production of buildings and vehicles which the units can then control.  I've lost my train of thought; I apologize for the abrupt ending.  Perhaps I will be able to finish this at a later date.