I have to +1 on networking. What also goes with networking is saving/loading games if you have a lot of state. It's the same problem all again: serializing your structs into binary blobs, and hoping they come back out the same way. Networking is all this, plus trying to keep multiple parties synchronized on the state of affairs.

And there's GUIs. Trying to us a library for it, such as Qt, with something like OpenGL ends up being pure crud. Qt creates a Window, and you get a GLWidget, which is just a rectangle you can draw into. You can't put Qt buttons on top of the GLWidget window (because the graphics card will obliterate anything drawn there in software), so you have two choices: You can draw menus and stuff with plain Qt (no GL), and when the game plays, fill the window with the GL Widget. Or, in the case of a level editor type thing, you have all the menus and buttons at the top/bottom/sides of the window, and the scene is drawn into the GL Widget. (not too bad if you want a OpenGL app with lots of controls, buttons, etc, but no good for a game). There is a third option for Qt, where Qt will let you draw a widget (which can be a frame of other widgets) onto a QImage which updates an OpenGL texture, and then redirects keyboard/mouse events to the OpenGL widget to the GL Widgets "inside" the openGL widget, but using it was even more awkward than this sentence trying to explain it.

When I just want a simple menu GUI, where you have a mouse pointer with clickable regions, and a mouseover or keyboard arrow highlights a selection, I just do it myself. A simple mouse/keyboard menu is very little code to get right.