   XNA project/solution layout options
  So I'm looking at XNA again and what always seems to throw a spanner in the works is that I really don't grasp how XNA and Visual Studio 'want' to organise my code. In Eclipse I'd have something like a 'Common' project with shared base code, and then separate projects for each specific game. And this would be in one workspace so everything can be open at once and I can easily switch between things.However I can't seem to translate this into XNA land. Content pipeline extensions seem to have to live in their own projects, so I end up with a 'Texture atlas pipeline' project, and a 'Texture atlas runtime' project alongside my 'Game' project. And I seem to have to duplicate my solution once for Windows builds and once for 360 builds. And that's just with one pipeline extension and one actual game, adding more pipeline extensions and dependant games and the whole thing becomes an unmaintainable mess.I'm hoping I'm just doing something incredibly stupid and I'm missing a much more intuitive way of laying out my projects and solution(s). All I want really is my common code in one place and to have multiple games that reference it, and be able to build the whole lot for Win32 and 360, preferably in one solution.So questions are 1. how are you laying out your XNA projects/solutions, and why, and 2. is there a good way to lay things out for my particular setup?Thanks.
  When I was doing XNA stuff I had things laid out like this:-1 project for all content pipeline extensions, Windows only.-1 "Engine" project with all common code. I created an Xbox 360 copy of this project, there were actually Windows and Xbox versions. However when you do this the projects are linked, and so any changes you make to one get made to both (it makes this issue much easier to deal with). This project also had the runtime components for any content pipeline extensions.-1 "Game" project with an Xbox 360 Copy-1 "Map Editor" project, Windows only-1 Content project, nested inside the "Engine" project. This was so that they same Content could be loaded by both the Game and the Map Editor, but you could nest them inside each Game project if you wanted to. Actually in XNA 4.0 Content projects are no longer nested inside XNA projects, which makes the whole issue moot.I then had all of those projects in one solution, but I also kept solutions that just had the Game projects, the Map Editor projects, and the Game with only the Windows versions of the projects. Solutions really just act like containers of projects, so it's pretty easy to organize them however you want. Even the VS UI fails you, they're just XML so you can always just go on in with a text editor.The Content Pipeline extension stuff is a little nasty, since you have the build side that you only want referenced by your Content project and the runtime side that you want referenced by all of your game/engine components. So you can't just have it all in one project. But it's not too bad since you can have multiple importers/processors in the same extension project.   ;  That sounds more reasonable, I didn't know if the content pipeline actually required each processor / runtime to be in their own projects. Grouping them together should help a lot. What do you do when you've got multiple games, do you add their projects into the same solution? Can you do that without breaking the whole build process?I'm still not comfortable duplicating the projects for Win32 and 360 though. It feels ugly and unwieldy and I'm not sure why it's really necessary - VS already has the configuration manager which lets you specify multiple targets / platforms / build setups, so why can't it be used for XNA games? It feels like a hack that's covering up for some lazy corner cutting inside XNA or VS. [sad]I should upgrade to 4.0 as well, is there any particular advantage/disadvantage to having an embedded Content project or not?Edit: Turns out 4.0 doesn't support deploy/run on 360 yet, so I guess I'll be sticking to 3.1 after all. [sad]   ;Quote:Original post by OrangyTangWhat do you do when you've got multiple games, do you add their projects into the same solution? Can you do that without breaking the whole build process?Personally I'd probably have a solution for each game, but I don't think there's any reason you couldn't group them all together. Shouldn't break anything build-wise.Quote:Original post by OrangyTangI'm still not comfortable duplicating the projects for Win32 and 360 though. It feels ugly and unwieldy and I'm not sure why it's really necessary - VS already has the configuration manager which lets you specify multiple targets / platforms / build setups, so why can't it be used for XNA games? It feels like a hack that's covering up for some lazy corner cutting inside XNA or VS. [sad]Gotta agree with you on that one. It's way more annoying than it should be to work across multiple platforms. And while having the projects linked takes care of most problems, it gets annoying once you want to have different files built only on one platform. I get the feeling that they just aim for making it easy for simple projects/games, at the expense of making it awkward for more complex setups. Quote:Original post by OrangyTangI should upgrade to 4.0 as well, is there any particular advantage/disadvantage to having an embedded Content project or not?Not that I know of. 