Friday Facts #139 - Wrapping Up MP UI

Posted by Tomas on 2016-05-20

Hello everybody,

the work on the 0.13 is slowly getting to the final phase and hence it feels like a good time to give an overview of actual multiplayer changes that have been implemented over past couple of weeks.

This is a recap and extension of a FFF post that mentioned the Multiplayer improvements while there were in progress.

Browsing games

Probably the biggest change is implementation of a service that holds available Multiplayer games. We call this service Multiplayer Matching Server even though the name doesn't precisely describe what it does.

This service greatly simplifies the game discovery and connectability. Player hosting the game (or a headless server) will simply publish the game to the Multiplayer Matching Server. This makes the game available to other players via the Browse Games Gui. This will make the clumsy connecting directly to the server pretty much obsolete (though the functionality stays).

As mentioned earlier there are quite a few little features to make the user experience smooth. Just to recap:

  • Games can be created as publicly listed / unlisted / LAN only
  • LAN supports automatic discovery without internet connection
  • Games can be protected by password.
  • Browse Games Gui supports searching in name of the game / description / tags.
  • Browse Games Gui shows some basic game information (game length, player names, etc.) and allows directly join the game.

User Verification

The usage (creating games as well as listing games) of our Multiplayer Matching Server will require user to be logged in with his Factorio username. If you have a Factorio account you can simply use those credentials in the in-game login dialog. If you are coming from Steam there will be an in game Factorio account creation dialog that creates a Factorio account for you the first time you need to use it.

The reasons to use strictly Factorio usernames are mostly technical. However also we have been from the beginning committed to provide all our services both to people using the Steam and those not using it as well. The same will hold for Mod Portal and other services coming in the future.

Another advantage of having user verification is that when creating the game it can be requested that all the users connecting to the game needs to be verified. Which basically means that they are connecting with their Factorio username and they don't pretend to be someone else.

Technical background for user verification

Just a little technical rant about how user verification works behind the scenes. This is to show that even a minor feature might get quite interesting. The diagrams show graphically what is happening.

  • When the server (Factorio game) is started it requests a server_padlock from the Auth Server. This is a hash of random server generated server_identifier and secret Auth Server value.
  • New players receive server_identifier when connecting to the game. With the server_identifier, its username and password (or token if he logged in previously) the player goes to the Auth Server and obtains the user_server_key. This is a hash of server_padlock (generated again on the Auth Server from server_identifier) + player's username + timestamp.
  • The User then sends its user_server_key to the Server together with its username and timestamp.
  • Server regenerates its own version of user_server_key from its padlock + given username + given timestamp
  • If the server calculated user_server_key and provided one match, the user is accepted to the game.

In this protocol the server_padlock is private information shared between server and Auth Server. The server_padlock allows to verify that the user coming with user_server_key was successfully verified by the Auth Server. All this hassle is to avoid too many requests to the auth server. This way there is one request when the game is created and one request for every new player connecting to the game while keeping a good level (in our opinion) of security.

Steam Friends

An often asked for convenience for the Multiplayer is the integration with Steam Friends. Thanks to Ondra this has been already implemented. In the Browse Games Gui you can filter games that have some of your Steam friends in them. Then in the game details you would see your friends highlighted.

But more importantly (and conveniently) you can use this feature directly via Steam. In your steam client you will see your friends that are currently playing Factorio and you can just click and join them in the game. This translates to our internal game connection mechanism which might still ask you for a password if the game requires one.

NAT punching

The final "cherry on the top" which is still in progress is NAT punching via the matching server. Basically this will allow the servers without public IP address (they are behind a NAT) to host the game. The idea is simple:

The Matching Server (or a standalone service) will provide a simple UDP API which can be pinged and it will respond with the IP address it sees the incoming packets to come from. This will be our little imitation of the STUN. The application (Factorio client hosting the game) will receive the reply with the public IP address it is visible to the Matching Server (Matching server has a public IP). This "punches" the hole to the NAT the Factorio client is behind.

The game is then published with the IP address returned by the STUN-like service and hence when players connect to the game, they are connecting to the public IP address on the outside of the NAT (if there is any). The packets are then forwarded to the actual Factorio client hosting the game via internal NAT mechanisms. As usual this might not work in 100% cases because of the special cases and oddities in NATs but should cover most of the scenarios.

Other

0.13 is a big big release. The biggest so far. So there are quite a few more "little" features that make the MP experience smoother.

  • Admin system will allow the player hosting the game to give admin commands, most importantly kicking out and banning (potentially annoying) players.
  • Console commands for the server (also via RCON connections).
  • Peer2Peer mode has been removed. This simplifies the guis as well as internal coding solutions. The player starting the game is always the server. We have thought about this quite a bit and the potential upsides of peer2peer (possibly faster on LAN and more "robust") are just not worth the hassle. For the future we might look into some peer 2 peer communication optimisations behind the scenes but there are more urgent things to be solved now.
  • Entity info shows which player has built given entity.

If you have some more ideas what how the MP User Experience could be improved please let us know at our forums. For 0.13 we are pretty much set, but we will gladly consider the ideas for the future. For instance the observer mode has been on our TODO list for a while and it is slowly getting to the top.