Multiplayer
Moderator: Moderators
Multiplayer
Greetings, NMDANGE from PhoeniX WorX Here
I have to say Spring looks really cool, although I haven't had much time to look at it. A user on PW asked me if PW could support Spring. I've downloaded the code and I'm going to look it over soon, and if anyone at Spring is interested in helping me out, please let me know
The PW server is designed to handle multiple client protocols, so while I don't think our current client (which is getting a bit old) will work very well, Spring can use something built into itself to access the service. I don't know who's in charge of multiplayer, but I'm definitely interested in collaborating
Cheers!
I have to say Spring looks really cool, although I haven't had much time to look at it. A user on PW asked me if PW could support Spring. I've downloaded the code and I'm going to look it over soon, and if anyone at Spring is interested in helping me out, please let me know
The PW server is designed to handle multiple client protocols, so while I don't think our current client (which is getting a bit old) will work very well, Spring can use something built into itself to access the service. I don't know who's in charge of multiplayer, but I'm definitely interested in collaborating
Cheers!
- [K.B.] Napalm Cobra
- Posts: 1222
- Joined: 16 Aug 2004, 06:15
Phoenix Worx, and late GBL, are very good. I'd be happy to have NMDANGE work on spring lobby, and give us iGW.
While we're at the IGW, as in the idea sprung here, having the iGW system generate custom scripts for each game, based in report from other game, could lead to a much awesome meta-game.
While we're at the IGW, as in the idea sprung here, having the iGW system generate custom scripts for each game, based in report from other game, could lead to a much awesome meta-game.
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
- [K.B.] Napalm Cobra
- Posts: 1222
- Joined: 16 Aug 2004, 06:15
Oh goody
I'm working on rearranging some of the code on the server so I can distribute the bits necessary for the client without distributing the whole server. I think to start I'll just take what you have and swap in the PW server, which shouldn't be too hard. Not sure about doing ranked games until there is some handle on anticheating.
End of the semester is this week, so I may not have too much time until next week, but then lot's of free time
I'm working on rearranging some of the code on the server so I can distribute the bits necessary for the client without distributing the whole server. I think to start I'll just take what you have and swap in the PW server, which shouldn't be too hard. Not sure about doing ranked games until there is some handle on anticheating.
End of the semester is this week, so I may not have too much time until next week, but then lot's of free time
- Michilus_nimbus
- Posts: 634
- Joined: 19 Nov 2004, 20:38
TA:S client
So, you guys are rewriting the client program that creates the setting.txt file? If so, the people planning the Linux port are doing the same thing. I'd like to share the work and make sure everything is cross-platform. Let me know how I can help.
Thanks
Cory
Thanks
Cory
I am also in charge of porting the current client over. The problem here is that I am porting the old client right now, so what are you guys planning on changing?
I guess it doesn't matter a whole lot, since we will just keep on working on this port. Once the port is done though, you can help us with integrating the changes you mentioned? At that point, it should be a simple copy and paste just like you said above with the current client (except that it will use C++).
Anyways here is our porting wiki...
https://opensvn.csie.org/traccgi/taspri ... nt#preview
I guess it doesn't matter a whole lot, since we will just keep on working on this port. Once the port is done though, you can help us with integrating the changes you mentioned? At that point, it should be a simple copy and paste just like you said above with the current client (except that it will use C++).
Anyways here is our porting wiki...
https://opensvn.csie.org/traccgi/taspri ... nt#preview
Well since our server is modular, I just need to know the protocol and you can have the client you are working on talk to the PW server. There probably would be some modifications to the protocol to handle different behavior. Is your port Linux only or will it be cross-platform? If it's cross platform I'll just help you guys talk to the PW server, save myself the trouble of doing the rest of it myself
Btw, Two things that are good for cross-platform C++
http://www.wxwindows.org for GUI
http://www.cs.wustl.edu/~schmidt/ACE.html for Sockets/Threads
Btw, Two things that are good for cross-platform C++
http://www.wxwindows.org for GUI
http://www.cs.wustl.edu/~schmidt/ACE.html for Sockets/Threads
Ya, its going to be cross-platform. I have been looking into wxWidgets to see if I can transfer the work from glademm. I currently don't like how glademm generates the code either, its kind of 'meh'....
We mostly would need your help with some of the features you want to add. Coryrc is working on the protocols and stuff, and I am working on the look of the GUI mostly (and making it work of course).
We mostly would need your help with some of the features you want to add. Coryrc is working on the protocols and stuff, and I am working on the look of the GUI mostly (and making it work of course).
Thank you, thank you, thank you! Any reasons you like ACE over the network i/o in wxWidgets? While it will probably be somewhat complicated to set up, it looks like it will help in the long run.NMDANGE wrote:Well since our server is modular, I just need to know the protocol and you can have the client you are working on talk to the PW server. There probably would be some modifications to the protocol to handle different behavior. Is your port Linux only or will it be cross-platform? If it's cross platform I'll just help you guys talk to the PW server, save myself the trouble of doing the rest of it myself
Btw, Two things that are good for cross-platform C++
http://www.wxwindows.org for GUI
http://www.cs.wustl.edu/~schmidt/ACE.html for Sockets/Threads
What about ICE?
http://www.zeroc.com/ice.html
After a quick look at ACE, it looks like both are aimed at the same thing (high-speed featurefull RPC over a network). Note however that ICE was written by ZeroC, a company composed of CORBA experts, who have spent most of their professional lives worrying about network RPCs. They designed and implemented ICE following their experience with CORBA and various other systems, to make a NRPC system that avoids the earlier errors. That, for me, makes a fairly powerful statement about ICE's qualities.
...
Okay, I admit it, so I found ICE recently and want a chance to mess with it, it doesn't mean it isn't good :D
http://www.zeroc.com/ice.html
After a quick look at ACE, it looks like both are aimed at the same thing (high-speed featurefull RPC over a network). Note however that ICE was written by ZeroC, a company composed of CORBA experts, who have spent most of their professional lives worrying about network RPCs. They designed and implemented ICE following their experience with CORBA and various other systems, to make a NRPC system that avoids the earlier errors. That, for me, makes a fairly powerful statement about ICE's qualities.
...
Okay, I admit it, so I found ICE recently and want a chance to mess with it, it doesn't mean it isn't good :D
ACE is distributed with a BSD-style license, instead of a GPL license, and has been around a long time. Also Boneyards used the ACE toolkit for its network code, so that speaks about the quality to me a bit. Though truth be told I hadn't heard of ICE before
I haven't really used the network i/o in wxWidgets.
Coryrc, since you are working on the protocol side of things, perhaps you can make a protocol spec document and I can implement it for the PW server.
I haven't really used the network i/o in wxWidgets.
Coryrc, since you are working on the protocol side of things, perhaps you can make a protocol spec document and I can implement it for the PW server.
What info do you want?
Okay, so you want to write up:NMDANGE wrote:ACE is distributed with a BSD-style license, instead of a GPL license, and has been around a long time. Also Boneyards used the ACE toolkit for its network code, so that speaks about the quality to me a bit. Though truth be told I hadn't heard of ICE before
I haven't really used the network i/o in wxWidgets.
Coryrc, since you are working on the protocol side of things, perhaps you can make a protocol spec document and I can implement it for the PW server.
a password authentication dialogue
new account
get galaxy
IRC
get news
...etc, just like your client?
Do you have your existing one available? What about code for your client being available? (If you want I'd do NDA on the code)
Re: What info do you want?
The current client is in Delphi, but it probably wouldn't help that much to see it. The server can load multiple dlls for different client protocols (well .net assemblies since the server is in C#). So the protocol can be whatever you want as long as I know the byte formats. I don't really like the current client's format that much anyway, since it's strictly text.coryrc wrote: Okay, so you want to write up:
a password authentication dialogue
new account
get galaxy
IRC
get news
...etc, just like your client?
Do you have your existing one available? What about code for your client being available? (If you want I'd do NDA on the code)
If you have VS 2005 beta 2, I can give you the code needed to make the protocol plug-in on the server side, but I can just as easily make it if I know what the protocol is. I haven't decided if/how I will release the code yet. We can just start with login and chat, then go to games/galaxy stuff.
XML? Can't we use something that's a little less bloated
It's all fine and dandy if you want to use HTTP, but this is byte-level TCP/IP; we can come up with something a little more compact
Something simple like...
[2 byte size][2 byte id][body]
While Delphi is hard to use with any kind of network format besides ASCII text, C# and C++ are a bit more flexible
Unless you have a compelling reason to use XML...
Can't say that I've used XML in C# beyond a SOAP-based web service.
It's all fine and dandy if you want to use HTTP, but this is byte-level TCP/IP; we can come up with something a little more compact
Something simple like...
[2 byte size][2 byte id][body]
While Delphi is hard to use with any kind of network format besides ASCII text, C# and C++ are a bit more flexible
Unless you have a compelling reason to use XML...
Can't say that I've used XML in C# beyond a SOAP-based web service.