Dpmaster support

[Mathieu Olivier]

Hi.

I noticed in the forums several posts related to having some master server support in Glest and/or GAE. I would like to know if it's still something you want to add to the game, or if the current solutions (IRC and XFire if I understand correctly) are good enough. In other words, would you be interested if I code a patch for GAE to add dpmaster support, or would I waste my time? 

[wciow]

Please feel free to give it a go. A master server is what Glest needs to help build the community.

Internet multiplayer is pretty much non-existent atm due to the fact that it is a direct connect via IP. Current 3.2.2 multiplayer is also unstable in large games and goes out of sync after a while.

[hailstone]

I don't think GAE is at a stage where it would be beneficial to have a master server for the following reasons:
- Networking is still in development stages
- There isn't a large number of users (that I know of)
- Sometimes large differences in time zones separates the users online at a time
- The GUI needs improving
- Major changes to the source are being discussed

But if you really want to I don't think anyone will stop you.

[Mathieu Olivier]

I don't think GAE is at a stage where it would be beneficial to have a master server for the following reasons:

My initial intend was actually to code a patch for Glest. But from the quick look I took at the website, forums and SVN repository, this project seems done / dead.

- Networking is still in development stages
- There isn't a large number of users (that I know of)
- Sometimes large differences in time zones separates the users online at a time
- The GUI needs improving

From what I understand, GAE is a work in progress with no major public release yet, so it's not very surprising.

- Major changes to the source are being discussed

Again, I'm not very worried about that, unless you really plan to change all the code design. I need to add a class for UDP sockets (already done), a couple of classes for managing the network dialog with the master and the other GAE clients, and a few menu pages. But that's about it I think.

But if you really want to I don't think anyone will stop you.

Yeah sure, I guess no one is going to raid my home computer to delete my code     but I don't want to spend time coding a feature that either won't be merged into the code base or won't be used by anyone in the end.

[daniel.santos]

Sounds fun.

At currently, you can start both Glest & GAE with a -client or -server option to start it up and facilitate a game that way, but that's for an outside-of-executable lobby, like SpringLobby.  All of the GUI is going to get ripped up in a serious way.  We're probably going to use CEGUI, but it's still getting played with.  If you're going to go through with this, please follow a few guidelines to help us port it to the new GUI system when it's ready.

• Separate your "business objects" from your presentation.  Make a set of classes that perform the actual functions that are completely independent of the presentation (GUI).
• Use the networking classes (shared_lib's Socket, etc.) from branches/network, as they have changed slightly.
• Glest/GAE currently has no support for playing a network game using UDP (which is truly a crime).  If you're going to implement something UDP, please try to enhance the existing classes under shared_lib, even if you have to make Socket an abstract class and add a UDPSocket and TCPSocket -- you would be doing us a favor then. =)
• Finally, I'm planning on implementing a dedicated server eventually.  In the network re-write that's in-progress, the server hosting the game will behave like a dedicated server with a client connected to them locally (in traditional FPS form), but getting 100% there will take some time.  So just know that the networking is being radically altered.  Also, many of the core classes are being restructured (Program is turning into an abstract class with ConsoleProgram and GuiProgram sub-classing them, etc.).

If you want to wait a week or two before starting, the restructuring of the core classes (Program, GuiProgram, etc.) should be stabilized and I'll have the changes to the base networking classes merged into the trunk as well.

[Mathieu Olivier]

• Use the networking classes (shared_lib's Socket, etc.) from branches/network, as they have changed slightly.

[...]

If you want to wait a week or two before starting, the restructuring of the core classes (Program, GuiProgram, etc.) should be stabilized and I'll have the changes to the base networking classes merged into the trunk as well.

I'll use the network branch as my code base then, it will be easier. I think I can quickly port the few changes I did on the trunk to this branch. I'll go back to trunk once you'll have merged the new network code into it.

• Glest/GAE currently has no support for playing a network game using UDP (which is truly a crime).  If you're going to implement something UDP, please try to enhance the existing classes under shared_lib, even if you have to make Socket an abstract class and add a UDPSocket and TCPSocket -- you would be doing us a favor then. =)

I already did actually    although I named them DatagramSocket and StreamSocket. I'll change the names.

[Mathieu Olivier]

I'll use the network branch as my code base then, it will be easier. I think I can quickly port the few changes I did on the trunk to this branch. I'll go back to trunk once you'll have merged the new network code into it.

Well, I'm not able to compile the network branch, neither on Windows or Linux, without modifying the base code more than I would be comfortable with.    So I guess I will work on the trunk after all. It should be OK, I'll merge your changes in my code when you'll update the trunk.