Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


DirectPlay and non-win32 platforms


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 felonius   Members   -  Reputation: 122

Like
Likes
Like

Posted 05 April 2000 - 09:16 AM

Hi, I am building a networked game and I would like to fulfill user expectations and user DirectPlay for this. I would like, though, to be able to let non-windows versions of the game communicate with the windows versions. One purpose of this is to create a Linux server version of the game to act as a dedicated server. This should be able to interact with the windows clients. Is this at all possible, except by abandoning DirectPlay totally and relying on some lower level protocol stack such as TCP/IP? Any suggestions would be appreciated? B.S. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/




Sponsor:

#2 SiCrane   Moderators   -  Reputation: 9662

Like
Likes
Like

Posted 05 April 2000 - 09:25 AM

In a nutshell, you have to abandon DirectPlay in order to communicate across platforms. The DirectPlay protocol hasn''t been (and mostly likely won''t be) released or ported to other platforms.

#3 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 05 April 2000 - 04:06 PM

DirectPlay doesn''t give you that much over sockets anyway.

An alternative you may want to explore is Apple/Bungie''s OpenPlay, and open-source game networking library. I believe that there are Mac, Win32 and linux implementations.



-vince




#4 felonius   Members   -  Reputation: 122

Like
Likes
Like

Posted 05 April 2000 - 10:21 PM

You are both probably right. I have to use something else than DirectPlay then.

It is a shame, though. DirectPlay is service provider independent while others (including OpenPlay) only supports TCP/IP on all platforms. This is the most important protocol but I would still like to support direct modem connections, IPX, null-modems, etc.

I took a look at OpenPlay. It is given in source code meaning that in principle can be ported to any system (providing that to proper drivers are written). A Linux version is under development but is not done. For know only Mac and Windows versions exist.

If anybody knows any other programs for platform/service independant commiunication please let me know.

B.S. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/




#5 Void   Members   -  Reputation: 126

Like
Likes
Like

Posted 05 April 2000 - 10:47 PM


Not very sure if it''s platform independant..

http://www.rogerwilco.com/

#6 felonius   Members   -  Reputation: 122

Like
Likes
Like

Posted 05 April 2000 - 10:59 PM

I just looked at Roger Wilco. It is not a communication protocol, but a application layer program for sending voice information over networks. It only works for Mac and Windows and only work on TCP/IP.

In conclusion, Roger Wilco is not what I need. Apple OpenPlay is then a better solution.

B.S. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/




#7 SiCrane   Moderators   -  Reputation: 9662

Like
Likes
Like

Posted 06 April 2000 - 03:53 AM

Nothing is preventing you from abstracting out your session/transport layer from the application. Create an network encapsulating interface for your network calls, and write a DirectPlay implementation and a TCP/IP implementation. Then you can still have your server in linux.

#8 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 06 April 2000 - 03:42 PM

Uh, that won''t work. DirectPlay uses its own protocols and the protocol spec is not public. So a DirectPlay client will not be able to talk to a non-Windows server.



-vince




#9 SiCrane   Moderators   -  Reputation: 9662

Like
Likes
Like

Posted 06 April 2000 - 04:34 PM

vince, I know that DirectPlay protocols haven''t been released. I said so myself above. I think you missed my point. The point is to abstract out the networking code by protocol. ex:


class NetStuff {
public:
virtual void CreateConnection(int address) = 0;
virtual int SendData(char * buffer, int size) = 0;
};

class TCPNetStuff : public NetStuff {
};

class DPlayNetStuff : public NetStuff {
public:
void DPlayLobbyConnect(void);
};


Then a network interface will be either an instance of TCPNetStuff or DPlayNetStuff. So just don''t compile the DPlayNetStuff implementation for the non-windows clients. You''ll still have the TCPNetStuff network interface to communicate over with other OS''es.

#10 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 06 April 2000 - 05:15 PM

But my point is that DPlay clients can''t talk to non-DPlay servers/clients.

What''s the use of having a DPlay implementation if it can''t talk to anyone else?

I agree abstraction of the networking API is a good thing - it has already saved my butt many times. It''s just that for this scheme to work all the clients/servers would have to be DPlay.




-vince




#11 SiCrane   Moderators   -  Reputation: 9662

Like
Likes
Like

Posted 06 April 2000 - 05:25 PM

Of course a DPlay interface won''t be able to talk to a TCP interface. But you don''t expect an IPX interface to talk to a TCP interface, do you? There''s still a point to including both, don''t you think? Treat DPlay as just another transport layer. So if the Linux box doesn''t have DPlay don''t try using DPlay to connect to it, simple as that. But if you''ve got a null-modem connected to your friend''s windows box you can still use the DPlay interface to communicate.

#12 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 06 April 2000 - 05:51 PM

Ah, OK, I see what you are getting at now.

I forgot that he wanted to use null modems and stuff. Why, I have no idea (does anyone even use a modem like that anymore?)

Of course, even with that solution, only Windows clients will be able to play against each other on null modems/normal modems.

IPX presents a problem, although he could use OpenPlay w/TCP/IP for LAN play.


-vince




#13 felonius   Members   -  Reputation: 122

Like
Likes
Like

Posted 06 April 2000 - 11:06 PM

The suggestion by SiCrane isactually the one that I have already described in my design document, but I hoped to avoid it.

I guess it simply is not possible to get both platform and service provider independence. Such is life.

The game I am writing is not a massive multiuser game so users should be able to find other people to play with even if two different ways of communicating is possible. I think that I will go for this solution. Thanks, everybody.

B.S. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/




#14 SiCrane   Moderators   -  Reputation: 9662

Like
Likes
Like

Posted 07 April 2000 - 06:14 AM

Vince, not to keep knocking you down, but why does IPX present a problem? In Linux you can program IPX with sockets, and in WinSock you you can open IPX sockets.

#15 Plutt   Members   -  Reputation: 122

Like
Likes
Like

Posted 09 April 2000 - 12:42 AM

I think the best solution may be to write your own protocol. It shouldn''t be too hard...

/Pelle


#16 felonius   Members   -  Reputation: 122

Like
Likes
Like

Posted 09 April 2000 - 06:14 AM

I do not think so. If I only wanted to use TCP/IP then you are right, but if I wnat to be service provider independant then you are not.

Writing a new protocol that works with multiple service providers is a lot of work. The connectivity API in Windows (i think it is called that) makes things easier.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS