Hi PiscesMike, thanks for the comments! Yeah… there are a lot of tutorials here. And I'm working on more.
In your question, when you say, "render", what exactly do you mean? In graphics, that term has the specific meaning of turning a scene into pixels, either to form a picture or to form the image that will be displayed on the screen. But… it doesn't sound like that's what you were actually saying. Are you just referring to using a content pipeline like system to manage content?
Assuming that's what you were asking about, the answer is yes. That kind of process is the most typical. XNA's content pipeline is a great example of that, but it isn't the only possibility. Getting content loaded from whatever program the artist used to create it, over into the running game, requires a fair amount of pushing and transforming data. A content pipeline is what does this work for you, and if you're smart about it, you can hook into an existing content pipeline (again, like XNA's) to add functionality for your own types of content.
If you look at the credits for most AAA games, you'll often see people who are called Tools Developers, or maybe Tool Chain Developers or something to that effect. This is one of the things they would work on. (Things not directly a part of the game code, but that are still software programs that are needed to get the game going.)
Of course, any code you've got that does this could be called a content pipeline unto itself, even if it is rudimentary. When possible, you'd probably want to use an existing content pipeline/content management system (and add on to it, in the areas that don't quite give you what you need) just for the sake of allowing you to spend more time on your game.
At any rate, taking the time to understand XNA's content pipeline will likely be meaningful and give you interesting insight, regardless of where you go in a game development career (or general software development career).
PiscesMike (guest) 06 Sep 2013 11:12