Messages

1

Network / Re: Peer-to-peer example

« on: July 11, 2014, 10:50:32 am »

There isn't really much difference between "client <-> server" and "peer-to-peer" in terms of programming your network layer, other than that the "client <-> server" model allows you to make assumptions which simplify discovery and connection. In P2P, you just have one of the clients acting as the server for the other client, rather than a dedicated "server".

The main complication is that many clients on the internet are behind firewalls and/or NAT which prevents them from receiving direct connections. This is particularly applicable if your clients will be on the internet. A secondary complication is having a client on one PC discover the address of a client on another PC it can connect to.

For testing on a single PC, you'd really need to be able to run two copies of your program at the same time. Then you need them to connect to each other which is where you run into the main technical difference/hurdle: deciding which client will listen for the inbound connection, and of course, how the other client goes about finding its address.

Generally speaking, there's three approaches:

• Make the user do it: one player selects "new server" and the other player selects "join server" and has to enter the IP address of the other player. Fairly easy to code, but assumes the players have the knowledge to do this.
• Use local network broadcasts: this only works for LAN play. Basically the 'server' client will broadcast its existence to the local network, and any other clients on the same network can listen for those broadcasts.
• Central metaserver/server browser: use a standard client-server model to have clients connect to a central server and provide information about themselves; other clients can then retrieve this list and use it to allow the player to select a 'server' (another client) to connect to.

You could also do a "mesh" P2P where all clients connect to each other, but that starts making things very complicated so it's rarely done in games. Usually you just have one client acting as a server for the other clients, while also showing the UI for its player.

2

System / Re: example program SFML segfault on redhat 6.4

« on: July 07, 2014, 03:06:38 pm »

How are you building SFML? As a completely uneducated guess it looks like maybe the glew library was somehow specified as a path to its location rather than the library name?

3

Graphics / Re: Window clear? Trying to shoot a bullet

« on: July 07, 2014, 12:56:31 pm »

SFML is doing exactly what you told it to do:

• Clear the display buffer
• If the mouse button is pressed: render 800 bullets along the top of the screen, each 1 pixel further along than the previous one
• Render the player sprite
• Display the new scene

The basic problem here is that you're running the entirety of the bullet animation within a single frame. What you need to do is set the position of the bullet the first time the mouse button is pressed and make a note that the bullet is now active (should be displayed). Then as long as the bullet is active, move the bullet in a similar manner to how you move the player position each frame, and then draw it ONCE at the new location (like with the player sprite). Once the bullet goes outside play, make a note that it's no longer active.