Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Best approach for simple network game

  1. #1

    Best approach for simple network game

    I must admit that I have absolutely no idea about networking. So let's assume I have a simple snake clone for two players via network using synapse. What protocol would I use? TCP/IP, SSH or anything else? At least both computers/games should communicate to each other but how to achieve this?
    Best regards,
    Cybermonkey

  2. #2
    1. Use TCP for "realtime" communication, use HTTP for webpage-like stuff.
    Snake -> TCP.
    Chess -> HTTP.
    2. You should have server.
    2.1. In local network any PC has IP address, so if two ppl connected to same home router, either wired or Wi-Fi, they both have IP address in local network, so there should be no problem.
    2.2. To play over the Internet, either one of PCs should have static IP address, or you should provide one additional PC which would then act as an intermediate server in case u can't rely on players having static IP address. It is not even important if IP address is static or not. One of the PCs should be able to accept connections. When you view website, remote server accepts connection. When you play online game, remote server accepts connection. If there's no intermediate server, then one of player's PCs should act as server. To accept remote connections, configure your home router to accept connections & redirect them to ur PC, then look up your Internet IP address. Even then you can't be sure that you will be able to accept connections, the only way to be sure is to test it. Whether you will be able to accept incoming connections over the Internet or not depends on your Internet Service Provider.

    Most modern online games provide intermediate servers. Because in most cases you can't expect players to accept connections. Because to accept connections you should configure router, and then in most cases you also should pay your ISP additional fee, otherwise you won't be able to accept connections.

    U can still develop a game to be played using local area network, then there should be no problem.

    This all could change when IPv6 becomes more widely used. In IPv6 u have more addresses, so ISP's won't have to restrict IP addresses exposed to the Internet. Currently shortage of IPv4 addresses is the reason why every PC can't have static IP address. Same with mobile phones. However, what I said earlier about local area network is also true for Wi-Fi powered phones. Each phone in local area network has IP, so it can accept incoming connections....

    Lawl. I hope I managed to make some sense
    Last edited by dj_sharp; 20-05-2014 at 12:20 PM.

  3. #3
    Yes, thanks. I forgot to mention that this snake "demo" should only work in a local network. I heard something about using UDP, though ...
    Best regards,
    Cybermonkey

  4. #4
    I believe that there is no good reason for using UDP. If you try to use UDP for this, you will only complicate things for yourself. If you use UDP, you will have to implement connection control & data delivery checking yourself. TCP is the way to go. I spent some time trying to figure out how to transfer data over TCP using synapse.... It is not that hard, but lack of detailed documentation complicates things, I had lots of WTFs before I got it working in my application

  5. #5
    Would you mind posting a small (console) example? Do I need a web server installed on one of the computers? If not, how can I "catch" the socket connection? (Do I really need two computers to test, or are two programs on one computer enough?)
    Best regards,
    Cybermonkey

  6. #6
    Well, why don't you look through examples included in synapse library
    Examine these files: synapse40\source\demo\echo\echo.pas & main.pas
    echo.pas should give you idea about how to implement tcp client & tcp server

    To make your applications transfer data over TCP you do not need a web server. Just include code for both server and client parts in your application, then one of users will click "create game" in your app and tell the other one something like "go; I created! IP is 192.168.1.2", so the other one will click "connect" button of his instance of app, enter IP and hopefully it will work lawl. Sever or "Creator" accepts connection, client connects.

    In example source I mentioned above TTCPEchoDaemon class is a primitive server, while TTCPEchoThrd is a primitive client.

    I can give you link to my code, but I doubt it will help you much. I can post the code I already have, but I am too lazy to create a tutorial-example from ground, sry lawl
    https://bitbucket.org/hinst/paslog/s...pas?at=default
    https://bitbucket.org/hinst/paslog/s...pas?at=default
    https://bitbucket.org/hinst/paslog/s...pas?at=default
    These are files I use for my logging library, but not all of them, not sure if it will help.
    BTW I assume u use FreePascal

    u can test everything on one PC at first, use loopback IP address then: 127.0.0.1 or "localhost" to connect
    Last edited by dj_sharp; 20-05-2014 at 08:42 PM.

  7. #7
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    I think I'll have to agree with dj_sharp on that one - synapse and TCP are probably the best way forwards. I've personally played with a few ideas for a data client & server system for use in games and other projects. What worked best for me was to standardize like crazy. And I laid it out like this (first is lowest level, application stuff at the bottom of the list)
    -Common, standard protocol
    -Standard network functions (ie. we send blocks/strings/stuff so that the recieveing command knows what to expect)
    -Protocol encoder (converts the data from the application into packets)
    -Backend (client interface for the client / core server code for the server [think connection management, authorization, protocol negotiation and so on])
    -Custom code.

    As for testing, I run the server on my machine and connect to 127.0.0.1 as dj_sharp suggested. Synapse has some pretty good documentation, but I found the examples most useful IMHO. All that said - I once tried to do all that directly on top of sockets and although I did get it working in the end it was EXTREMELY unreliable and just not nice to use.

    Edit: If you'd like I can PM you the relevant files out of a project of mine (its not open source code yet for a whole bunch of reasons) which is what I use in our ground control software that uses synapse. It isnt the best way to do things but is serviceable.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  8. #8
    Quote Originally Posted by dj_sharp View Post
    2.1. In local network any PC has IP address, so if two ppl connected to same home router, either wired or Wi-Fi, they both have IP address in local network, so there should be no problem.
    Every networked PC or device has an IP assigned to it.
    Any two networked PC's that are on the same network can directly comunicate between each other without any problems.
    But if you have two PC's on two different networks then direct comunication between them are not posible without those two networks either being bridged together or data is being routed from one network into another.
    Now due to security reasons most networks are protected by firewals which prevent all information to be routed into it. So in order to comunicate with a PC on such network you need to open (unblock) proper port in firewall for data to get through.

    Quote Originally Posted by dj_sharp View Post
    2.2. To play over the Internet, either one of PCs should have static IP address, or you should provide one additional PC which would then act as an intermediate server in case u can't rely on players having static IP address.
    Static IP is not required. You only need to exchange IP adresses between players. Static IP adress only comes usefull if you are hosting presistance multiplayer game so that in case of server conection loss you don't need to manually send your new IP adress to other players.
    And even this could be making your PC to become part of an domain (PC IP is provided by domain server).

    Quote Originally Posted by dj_sharp View Post
    Whether you will be able to accept incoming connections over the Internet or not depends on your Internet Service Provider.
    ISP providers don't block incoming connections. Incoming connections are only blocked by built-in firewall of your internet gateway. But in most cases you can configure firewall settings of your gateway and add proper exceptions to it.

    Quote Originally Posted by dj_sharp View Post
    Most modern online games provide intermediate servers. Because in most cases you can't expect players to accept connections.
    The main reason why modern online games rely on intermediate servers is to provide a game lobby through which players can easily find desired multiplayer sesion, join or create one. This eliminaes the need to manually share IP adresses between players.

    Quote Originally Posted by dj_sharp View Post
    Because to accept connections you should configure router, and then in most cases you also should pay your ISP additional fee, otherwise you won't be able to accept connections.
    Paying additional fee to able to accept incoming connections? What? I have never heard anything about it.
    The only aditional fee that ISP providers are known to charge is to get a static IP asigned to you. But nowadays more and more ISP providers assing static IP adress to their users by default (athleast here in Slovenia). I myself had to ask my ISP provider not to asign me a static IP adress.

    Quote Originally Posted by dj_sharp View Post
    However, what I said earlier about local area network is also true for Wi-Fi powered phones. Each phone in local area network has IP, so it can accept incoming connections....
    Only if those connections are comming from that local network.


    As for deciding between TCP or UDP:
    UDP protocol is intendet for general broadcasting of data to multiple computers. Becouse it doesen't have data delivery checkings system integrated it is mostly used for broadcasting non esential data (video or audio streaming).
    TCP on the other hand has built in packet delivery checking system which makes sure that packet was delivered. If not the packet is resended. With the difference of the UDP TPC protocol can deliver its packets to only one computer in time. So if you are sending data to let us say 1 computers you will have to send that data ten times (once for each computer).

    So since yin your game you will probably be sending data only between a few computers and you need to know wheter data arrived to another computer or not using TCP is the best choice.

    As for how you implement multiplayer functionality into your game I gues you would want to have one computer to act as server.
    This computer will also take care about game simulation. So it will be constantly sending information of game state to other clients.
    Clients on the other hand will be only sending input information (which keys were pressed/released).

  9. #9
    TCP is connection-based. You establish a connection between two hosts, and then send data over that. The protocol guarantees that data arrives whole (any packets lost are automatically re-sent) and in order, but obviously, this comes at a price - managing and re-establishing the connection, re-sending the packets et cetera takes some time, so TCP is generally slower than UDP.

    UDP is connectionless. Kinda like snail-mail, you just slap an address on a packet and hurl it into the vast void of the network in hope that whatever intermediate servers will be able to successfully forward that to desired destination. Downside is that, obviously, the packets may get lost or arrive out of order. But this also an advantage - if you send player position data over the net, you always want the latest data. If an old packet gets lost anyhow, there's no need to resend, because you probably got fresher data, anyway. And if old data arrives later than newer data - you can insert a timestamp into packet data, then compare timestamps and ignore all old packets coming in.

    On LAN, TCP should suffice, as the ping on local network will most likely be <1ms anyway, and you get all that guaranteed data integrity benefits. Heck, on low ping networks you can even do this the archaic way: send player X packet to player Y, and don't advance the game for player X until he gets the packet from player Y.

  10. #10
    Nice to see this thread, as we will need it in a future project.

    BTW, I read about synapse at FPC wiki and I see this is a general-purpose networking library. Does nomebody made any gaming using it, or there's any tutorial about how to use it in games?
    No signature provided yet.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •