Yes doing everything in "GameComponents" is bad, but I didnt mean "Game Components" from xna, did you read the article? Yes i have also read some c# and xna books too. Yes component based game design isnt OOP, its not supposed to be. Ive read a bit of articles on the design and it seems its better than doing strict OOP. Ofc you can have some kind of OOP design in the component design tho. My Game1.cs also has little code, only to add my component based engine to the components list - which imo isnt a good excuse for anything to be "good". It just means you put your code somewhere else. Im not saying to do anything in game components, im talking about a design pattern thats very different. I was just trying to give out some ideas, i mean ive also done a hierarchy designed engine, but component based design 'imo' is easier.
Anyways, you can serialize/deserialize data into an xml. It does take some time to load up, but its user friendly and easy to read. You can also load xml files as content into classes.
http://blogs.msdn.com/b/shawnhar/archive/2008/08/12/everything-you-ever-wanted-to-know-about-intermediateserializer.aspxyou can also just load in text files of your map. But then you'd have to parse it your self. There are other ways too, but ive only done txt files,xml, and multiple kinds of serializing. Xml being better, but slower.
An object would have an input,collision,physics, and render component. A player be an object, except with a "PlayerInputComponent" component. A npc would and an object, except with a "AIInputComponent". No hierarchy, you get what you want and you can easily make complex objects. They all are still controlled by the same sprite manager too if you want.