Your static classes appear to be the same as if you just put the globals in a namespace. The one important thing I forgot to mention about how we did globals was that all our global variables inside the globals class were pointers. When we initialized the globals class, the initialization function allocated all the global variables in the order that we chose. Also, in the globals' destroy function, all of the global variables were deleted, in the reverse order. The problem we had before we did this was that some of our global variables (or rather, class instances) were being created or destroyed in the wrong order, and we couldn't control that at all. Now that I think about it again, another solution could have been to assume nothing exists when global classes are constructed, and don't use anything external in a globally used class' destructor. Then you'd just need to be careful of how you initialize and destroy globally used classes. I think the reason we didn't do that for the first project was because we were half way though the project when it occurred, and we didn't want to re-design all the classes.

You might also want particles to be animated, which would make them a little more complex than data structures. Although I don't know how you'd animate particles yet.

Players wouldn't be the actual player objects, but more like the interface between the input and the object the player is controlling. Or.. actually networking does that more. (I'll get into that later.) So I guess players would just be information pertaining to multiplayer stuff.

Ok, so networking...
It seems to work best to design the game such that single player and multiplayer function almost identically. This means player input should be going directly to networking, and the networking stuff should update the game. One of the general rules of game network programming is that the server never trusts anything the client sends. Well, not quite never, otherwise you wouldn't know anything. Basically you want to get stuff from them with as little interpretation by them as possible. Probably not raw mouse input or keystrokes, but the level after that is generally good for clients to send. As for the server side (oh yea, I'm basing all of this on a client-server architecture), the type of updates will depend a lot on how the gameplay works.
All the networking I've worked with before has been with Winsock, and done in threads. I haven't had any experience with DirectPlay, but Winsock has none of the overhead for DirectPlay, and it's simple enough. Threading is used because several networking function can block execution. Actually, I'd need to think more of how it would be best handle the sending/receiving for networking since there are several ways to do it. But I think I'll stop here for now.