I agree with Mark Kughler, it is very good code.
Some minor niggles to consider:
1. void Game::analyze()
It's a long function, with several blocks where you perform some check. There is however no clue what check you're doing in each block. In a year, you'll have to reverse-engineer the blocks to understand what they do.
You can avoid that in a few ways. One option is to move a check in a separate function, so you can attach a name to the block, like "bool Game::is_board_filled()" which immediately explains that the code is doing.
Another option is to add a line of comment above each block:
/* Check 1: Is there any space left at the board? */
This makes you can make high-level jumps from one such comment line to the next, making it easier to find some case that doesn't work, for example.
2. Your editor can't make up its mind whether to use spaces or tabs for indenting:
[attachment=35277:mixed-spaces-tabs.png]
This is how it looks in my editor. I have tabstops at multiples of 8 positions, and it's jumping back and forth. (The dark-grey >----- is a tab character.) Your code has it too, but it is less noticeable there.
3. using namespace std; (in various files)
This is not universally accepted as a good idea, for two reasons. "std" is very big, so you are running the risk that you use a seemingly harmless name, and then the compiler fails and gives a weird error, because it was also used in the std:: name space.
Another reason for not recommending global import of std is that "string s;" looks like a local string type, while "std::string s;" is clearly not in your source code. In other words, the fact that you have to write a prefix "std::" makes more clear where things are coming from. You use only one namespace, so the search isn't that complicated, but imagine you import 15 name spaces in this way. Now find me this "f" function I have.... a prefixed name like mathlib::f resolves that search in about half a second.
All suggestions are mostly "next level" ideas for you rather than things that are wrong.
Good work!
