I'm building a Civilisation type game, but with simultaneous Turns / Real-time. I went with C# in the end. I'm loving the language and I'm at least familiar now with all major language features if far from experienced in their application. From the start I've tried to completely separate the core functionality from the GUI. For a short while I had 3 projects in my VS solution, the core, a windows forms project and a WPF one. For the time being I've got rid of forms and am just using WPF without XAML. It does what I want for the time being: puts Hex Shapes and Rectangles on the screen where I want them and allows me to easily interact them with clicks and context menus.

So I have built a very basic scenario editor and am starting to build some very, very basic game play:just allowing units to move around. I've separated the description of the scenario, how things really are from the view of the scenario that the player sees. The player may not see everything and may even see units in the wrong place etc. So far I'm just working on Single Player on one machine. Now with the scenario editor, I'm happy that you can only edit a scenario on the local machine. However Game-play is different. I want the Player User Interface to work the same whether its on the same computer as the Core scenario Game processor or if its on a remote machine across the internet. So am I right in saying that I need to use messages? I presume there is no way to make it look like you're directly accessing methods on a local instantiated object unless you actually are. My thinking is that simple messages can be passed out by event. For the time being those messages can be passed on to the Core by the Player message handler using a simple method call. In the same way the Core can pass out messages to the player without knowing their destination by event and handled by the Cores Message handler. This way at later point hopefully I can write the networking functionality without having to touch the rest of the games functionality.

Comments on the above appreciated, but also how easy is it to network some messages in C#? Is networking easy enough that you might as well introduce it earlier. Or should I simulate Multilayer through multiple processes on the same machine for the time being? Should I use Windows Communication Foundation or is it unnecessarily complicated? WCF does seem incredibly difficult to penetrate, worse even than C++ and DirectX 11.

Ah thanks for the advice.

Aren't proxy objects better than messages then? As they allow you to programme your components Player interface, Core functionality AI, etc in an object orientated manner. Don't messages to some extent break the heavy type checking of c#. Which is its great beauty. Although I haven't done networking, obviously it must be able to deal with messages. I'm just a bit worried about designing around proxy objects and then discovering down the road that they don't work quite like how I imagined and having to rewrite non-network functionality. With proxy objects can I just pass in the proxy via a method/ constructor parameter same as a non proxy object.

You recommend separate processes, if one is going to start playing around with multi-player? is it better to start with completely separate processes as opposed to multi threading or multiple application domains within the same process? I just checked and visual studio will seem to allow 2 versions of the project solution to run at the same time, so that should help.

edit: Perhaps I should say that I've already got the multi-player infrastructure in place. so I could simulate multi-player just by opening another (non dialogue) window in WPF. As I'm learning, I don't mind restructuring and partly rewriting my code multiple times as my understanding and knowledge of the best solution increases, but I'd like to at least aim for the correct solution to start of with and I guess on reflection its the networking aspect rather the multi player aspect itself that concerns me.