A bit of status on my implementation stuff so far first:
I've set up a basic rendering framework implemented in Xna as a game library project which my Winforms app and a regular Windows Game project each utilize. I've done this by modeling the Winforms app off of the sample on the Creators Club site. It was pretty straightforward, so I probably won't go too deep into detail there. Basically my framework is an empty shell with the standard init, update, and draw methods exposed, and also access to a scene graph and various other content managers. It is up to the clients of this framework to create and set up the GraphicsDevice and supply the framework with a reference to it. In the Winforms app, I've created an XnaControl which subclasses System.Windows.Forms.Control, sets up the GraphicsDevice and supplies it to the framework. In the Game project, the Game class initializes and supplies the GraphicsDevice. It is also up to clients of the framework to maintain a 'heartbeat' and call update and draw regularly at their discretion. I hook the Application.Idle event in Winforms and use a Stopwatch to keep time there, and just let the Game class do its thing in the Game project. So I've got three projects set up in a single solution, the framework core, the Editor and a TestGame project. I fire up the Editor and see my wonderful hardcoded spinning triangle, and when I fire up the TestGame, I see the same thing. So far, things are pretty solid.
For the past few days I've been researching the Content Pipeline (which I'll probably be typing alot and refer to as the cp) and trying to figure out how it best fits into my level editor design. Or any Xna based level editor design for that matter. The cp probably has no place in a standalone level editor as there's way too much on the fly loading and editing of content going on to gain any benefits from it. However, in my case my level editor's sole purpose is to produce what I'm calling a 'game pack', or a bunch of content that my Xna engine can load in and run as a game. Also, to add another variable to the equation, my editor and engine both share the same core rendering engine, so the in-memory format of loaded resources has to be consistent.
Hopefully the problem is starting to become apparent. With the editor and engine being driven by a common game library, there needs to be a common in-memory format for things they use, models, textures, terrains, maybe even cool stuff I haven't even thought up yet. Loading content from disk is fine, its in the little xnb format, I can use the cp to load it up, and spit out my in-memory objects to send to the scene graph. Content generated out of nothingness or edited on the fly by the editor, I'm not so sure about. What do you input to the cp to generate the xnb files?
Using a terrain for an example, suppose I create a custom content processor and whatnot to handle turning a heightmap and a few textures into a nicely packaged xnb file, and loading said xnb file into an in-memory object. Now using the editor's tools, I adjust the positions of some of the vertices, paint some roads and stuff, and generally change the in-memory object all around. How do I store those changes back to disk? Further, what if you have content that has no source files, that's just created out of nothingness using the editor? There seem to be a few paths forward.
I can store all these things on disk in some format that I come up with to be able to save my level editing progress. This format is useable by nothing other than the editor. Then I would have to write a utility to use the cp to read in that format, and produce a game pack, a set of xnb's and descriptor type resources that can all be read into the game by the cp. This provides a nice disconnect from the editor and the cp. Maybe down the road, I can write a different exporter and export to a useable, well documented format, and be able to share my editor with the rest of the world.
Another route is to follow a blog post I found on invoking only the write half of the cp to write out in-memory objects to xnb format. (found here: http://nickgravelyn.com/2008/10/creating-your-own-xnb-files) I could go this route and have the editor's default save format be my mythical 'game pack'. A few drawbacks with this include the pretty shady way you have to invoke pieces of the cp using reflection to access internal and protected methods and constructors, and that doing so would mean the editor is now dependent on the full Game Studio install and not just the Xna redistributable.
Maybe the solution is a hybrid of these two. The default save operation writes out to some format I come up with, and maybe I write a separate plugin exporter (or even standalone converter utility) that is able to export to a 'game pack'. That way the plugin alone depends on the Game Studio install and if you don't want that, the editor only requires the Xna redistributable.
The more I consider it, and consider what the cp was intended for, it seems some variation of the external utility to process content is less square-peg-round-holey than trying to have an editor whose save format is a compiled binary format optimized for loading on a console.
I'd be interested to know if anyone else is attempting the same kind of thing I am, or if there are much easier ways to go about this. Also, I should point out I'm very hesitant to totally strip out the cp because I do have intentions of one day running games created with the editor on the Xbox and it seems to be the consensus that loading content on the Xbox is much too involved without the cp, something about only having access to file io functions and reinventing the wheel several times over.