Jump to content
  • Advertisement
Sign in to follow this  
Rich Brighton

Developing MultiPlayer functionality with c#

This topic is 2624 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

So am I right in saying that I need to use messages?


Need? No. You'll need something though and messages are as good as any.


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.
[/quote]

Sure, WCF will do that. Other systems allow proxy objects to behave like this.


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?
[/quote]

You should design for networking from the start. As a beginner, I would avoid it since it complicates a lot of things. If you're going to ignore that advice, I'd suggest always doing the multiple processes to make sure you're keeping things separate that need to be.


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.
[/quote]

It's certainly a good starting point. A little awkward to setup, but once its there then you don't really ever have to worry about serializing objects, message format, retry behavior, and a pile of other things that you would if you did the communication yourself.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.


Depends on what you consider a message and how they're implemented. Under the hood, it's all bits over the wire... WCF (and some other libraries) are nice that they hide all of the un-typed bits away from the programmer and are well tested so you don't need to.


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?
[/quote]

For beginners, yes. It forces you to not 'cheat' and re-use memory or method calls or state that won't be there in a multiplayer environment.

Share this post


Link to post
Share on other sites
To get a basic networked application in C# running is quite easy. But I would say that you need to design your game/application with Multiplayer in mind because trying to add it at the end can be a nightmare if the rest of the objects are not designed properly. A great (introductory) C# book about networking is this.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!