For the server of my Star Trek game, I need someone to teach me the ropes when it comes to making an application of this caliber. I bought a book about it and started learning the basics of doing math, data structures, and the like... but creating something that can remember connections, open data streams, and many of the things that this game will require might currently be beyond me. Thus, I'm opening this topic so I can ask for help where needed, and even let people walk me through basic networking? Just a note: In the beginning this might entail showing me how to do some of the things I'm trying to do, but as I learn how to do it, I'll need less and less things exemplified.

The first thing I have to ask is when you open a socket in python and bind it to "something". Is a socket a connection to one specific other device, or is the socket what's being used to listen? I'm assuming one you get a listening service, you'll need to create separate connections for each device? How does this work?
ACagliano wrote:
The first thing I have to ask is when you open a socket in python and bind it to "something". Is a socket a connection to one specific other device, or is the socket what's being used to listen? I'm assuming one you get a listening service, you'll need to create separate connections for each device? How does this work?
A socket is one end of a connection, where a connection (at least in TCP) is globally unique in the quad ((address, port), (address, port)).

When serving, the usual procedure is to bind to a port, then start listening on it and repeatedly accept connections from the listening socket. accept gives you sockets that communicate 1:1 with clients that connected to your listener, where it's common to fork off a new thread for each accepted connection.
Are you making a game in Python? If you're actually making it in Python, just ignore my post. If you're making it for 84+, read on.

Well, you don't really want to be reading about Python networking for a game you're making from scratch in assembly. The reason is not an obvious "well they're different platforms," but rather that conventional networking involves a TCP/IP stack, which you do not have the luxury of in embedded hardware unless you have a network card attached.

Because of this, the majority of terminology and architecture you would find in a TCP/UDP networking design simply does not apply to your situation. You have to build up your own peer-to-peer networking protocol from scratch, unless of course you decide to use CalcNet or something like that.

In TCP, every connection has handshakes and acknowledgements to assure the packets are sent reliably and to make sure to know when a peer connects and disconnects. In UDP, packets are sent without having established a connection and with no guarantee of reliability.

If this is going to be a 2-player thing, I wouldn't bother with any of this mimicking of TCP/IP, not even a client-server model.
oldmud0 wrote:
Are you making a game in Python? If you're actually making it in Python, just ignore my post. If you're making it for 84+, read on.

Well, you don't really want to be reading about Python networking for a game you're making from scratch in assembly. The reason is not an obvious "well they're different platforms," but rather that conventional networking involves a TCP/IP stack, which you do not have the luxury of in embedded hardware unless you have a network card attached.

Because of this, the majority of terminology and architecture you would find in a TCP/UDP networking design simply does not apply to your situation. You have to build up your own peer-to-peer networking protocol from scratch, unless of course you decide to use CalcNet or something like that.

The game is a multiplayer game, with CALCnet. The client side is in assembly. The server side is in Python.

oldmud0 wrote:

In TCP, every connection has handshakes and acknowledgements to assure the packets are sent reliably and to make sure to know when a peer connects and disconnects. In UDP, packets are sent without having established a connection and with no guarantee of reliability.

If this is going to be a 2-player thing, I wouldn't bother with any of this mimicking of TCP/IP, not even a client-server model.

This is going to be an n-player thing, but use a 2 player model, where the only things clients interact with is the server, and the server handles making sure things get where they need to go.

It seems to me that actually routing packets is one of the easier parts of this undertaking. The harder part is perform loops, position updating of various entities in the "map", and, at times, generate structures and terrain. It has to do this while simultaneously routing chat messages, and sending clients map and entity data at regular intervals (some of which may involve data streams larger than one CALCnet packet).
If all the clients are correctly synced, most movements should actually be implicit if it is reproducible on all clients. For example, if a ship is just drifting (conservation of energy yes??), very few packets should need to be sent since nothing is acting on the ship (just some packets to make sure the clients are in sync). You also don't want to wait on the server for an action to be registered and your ship to start moving. That's how lag problems start. Instead, as you maneuver your ship, send your actions that caused the ship to move to the server.

Now you encounter a new problem: the lag isn't caused by the wire's distance, it's caused by the calculator having to process packets and play the game concurrently! That's why you'll want to make your packets as tiny as possible, at most 16-32 bytes. With such a slow CPU, you'll want the optimization everywhere.
oldmud0 wrote:
If all the clients are correctly synced, most movements should actually be implicit if it is reproducible on all clients. For example, if a ship is just drifting (conservation of energy yes??), very few packets should need to be sent since nothing is acting on the ship (just some packets to make sure the clients are in sync). You also don't want to wait on the server for an action to be registered and your ship to start moving. That's how lag problems start. Instead, as you maneuver your ship, send your actions that caused the ship to move to the server.

Right. I would basically send speed and direction updates to the server, and then just have the server occasionally let the client know where it thinks the ship should be.

A related concern I have is objects. For the purposes of the game, anything that is non-static is an object. This includes your ship and all fired weapons. I'm not sure whether to have the server only send the current position of the weapon, its direction, and velocity, and let the calculator handle its movement, or to have the server control its movement. I might need to do the latter bc I need the realism of, for example, a weapon missing a ship and hitting something else, or being intercepted by another weapon. So when shooting at someone, a simple PTP transmission still won't be what I need.

oldmud0 wrote:
Now you encounter a new problem: the lag isn't caused by the wire's distance, it's caused by the calculator having to process packets and play the game concurrently! That's why you'll want to make your packets as tiny as possible, at most 16-32 bytes. With such a slow CPU, you'll want the optimization everywhere.

Yea, this is the reason I am trying to get as many of the heavier computations onto the server as possible, leaving the calculators to essentially just process Cn2 packets, handle keypresses, render graphics, and deal with things like collision with self.

**

I suppose I should ask, in the code for the Cn2 server (I think Kerm shared it as a skeleton), what is the "loop" within which all other coding should occur?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement