Networking and UI Questions

Newbie & Debugging Questions
#1

  1. Is it possible to set up a LAN without internet? If so, how do the peers who do not know each other’s addresses find each other?

  2. What is good cap on how many local players can be using the same connection to connect to a server?

  3. When sending request through sockets, is better to send an object with code or send data for the server to interpret?

  4. Is it possible to have a interface to the scene without the UI knowing whether or not the scene is on a client or server?

  5. If I wanted to program a split screen system where the screens split when players are far apart and rejoin when players are close, how would I do so without noticeable delay when splitting and joining?

  6. What are some graceful ways to disconnect from a server without disturbing gameplay. Let’s assume that we are working with a game that trusts the client, mostly because the server doesn’t not save any changes to the scene and doesn’t gaf if the player hacks.

#2

  1. LAN means local area network, a LAN can be something as simple as two computers connected via a cable. You can find each other by broadcasting small discovery messages with your local ip address.

  2. There shouldn’t be such a cap. It’s just annoying if you can’t join the same server from the same ip, because of artificial limitations.
    A cap on how many players can be on the server at once in total is very important though.

  3. You never send code to the server, sending code would be the funkiest thing ever for a game.
    All you need to do is send small serialized, predefined messages containing only the needed data.

  4. Can you make this question a bit less vague, what are you trying to achieve?

  5. http://www.java-gaming.org/index.php?topic=5661.0 or “Render to Texture”
    In a 2d game, this would be possible without opengl stuff by just rendering the scenes accordingly.

  6. Just announce it via a packet before closing the application and also implement a timeout.

#3

@VaTTeRGeR

Regarding #4,

Let says that the player can play 3 ways:

  1. Single player
  2. A client in multiplayer
  3. A server-client in multiplayer

In a single player game, the ui can get information immediately.
In a multiplayer, the ui has to wait if it isn’t the server. As a far as I know, the ui makes a request, and some time later, some piece of code updates the ui’s data.

By encapsulation, the ui shouldn’t know whether the game can supply information immediately or not. The only way that I can think of doing this is apply the request system universally. Some interface determines whether the request can answered now or later.

My question is whether there is an easier or simpler way of doing this.

#4

That seems like a good idea, you could supply the UI with an object, that contains mock-data and some status flags, then an underlying system updates the object with the real data.
The UI just displays the mock data or reads the status flags and hides until the real data is there.
This could easily be used in singleplayer and multiplayer.

But there are multiple ways how to do this, maybe there’s a better solution.

#5

Isn’t encapsulation the matter of private/public? You can simply construct the Game object when all the necessary information from the server has been received. Until then, you can display a loading screen with Einstein quotes, an intro video, or a beautiful screen effect.

But this is probably future music, let me see your game first ;D

#6
  1. and 3. should be identical. In fact, I would try to deal with 1., 2. and 3. exactly the same way.

The reason: it can be a development nightmare to model different environments. It’s probably much easier to implement everything as client-server, so that for 1. and 3., it’s just a client “connected” to a local server in the same process.