Question: I'd like to work on a game, but for rapidly prototyping it, I'd like to keep it as simple as possible, so I'd do everything in top-down 2D in GDI+ and WinForms (hey, I like them!), so I can concentrate on the logic and architecture of the game itself. 

I thinking about having the whole game logic (server) in one assembly, where the WinForms app would be a client to that game, and if/when the time is right, I'd write a 3D client.

I am tempted to use XNA, but I haven't really looked into it, so I don't know if it won't take too much time getting up to speed - I really don't want to spent much time doing other stuff than the game logic, at least while I have the inspiration. But I wouldn't have to abandon everything and transfer to new platform when transitioning from 2D to 3D.

Another idea is just to get over it and learn XNA/Unity/SDL/something at least to that level so I can make the same 2D version as I could in GDI+, and I won't have to worry about switching frameworks anymore.

Let's just say that the game is the kind where you watch a dude from behind, you run around the gameworld and interact with objects. So the bird's eye perspective could be doable for now.

Thanks.

Answer: 
This too long for a comment but... Your game physics world should pretty much be independent of the type of view you're using to see it. As an example, it's not uncommon for RTS (like say Warcraft III) to offer both a 3D view and a "mini map". If you think about it, Warcraft 1 that was 2D isn't that different from Warcraft 3 (which is fake 3D, but represented using real 3D).

Another example, you're talking about watching some character walking: it's not unlike CounterStrike (well, in CS you *are* the dude but anyway), where you have both your 3D view **and** also a minimap. And gameplay aside, I sure can walk around "Dust" (one of the most famous CS map) using only my minimap: I don't need the 3D view to walk around (now of course to aim I can't use the minimap). 

In a lot of game the "physics world" is not the same as the "3D world": otherwise people with different configs wouldn't be able to play in a network game.

Another CounterStrike example: I had a really old crappy celeron with a crappy graphic card that was barely enough to run the game, so I modded the game to use "low polygons" models for the characters (this greatly enhanced the rendering speed and hence made the game very playable on my crappy config). And I still could play networked. Why? Because changing the *view world* doesn't change the *physics world*. 

So the "view" really shouldn't be influencing too much your model because the view is a detail. Now of course you have to somehow decide on what you want: but if the "dude" you mentioned could be followed using a 2D top-down view as well as an isometric view as well as an "FPS-like" 3D view, then by all mean model your "physics" in a way that is completely unrelated to the view. That way you'll be able to start with something simple: 2D view, using pixels (like a CounterStrike or a Warcraft 3 minimap). And later on you can start adding a 3D view.

Now the kind of world you need to use depends on what you want: heck, there are both "2D physics / 3D view games", "3D physics / 2D view games", "2D physics / 2.5D view games" (GIYF if you don't know about the '2.5D' term in videogame development), etc.

My point is: the view is unrelated to the model/physics (once again, otherwise people couldn't be playing networked game of CounterStrike or Warcraft).
I'm not a game programmer, but I know that the difference between modeling physics problems in 2D and 3D is huge. 

I agree that it's a good idea to start with 2D, but don't expect to be able to reuse much of that code in the 3D version. 3D is a different animal.