O multiplayer do Construct é baseado no WebRTC DataChannels. Ou seja, uma tecnologia de rede entre computadores. Os jogadores conectam diretamente com os outros, não necessitando de um servidor central para isso.
Resumidamente, os jogadores ainda utilizam um servidor para jogarem uns com os outros, entretanto, isso é feito a partir da conexão entre seus computadores. O primeiro jogador a criar uma partida se torna o anfitrião (host), enquanto os demais são chamados de pares (peers). O anfitrião age como o servidor do jogo, ou seja, todos os outros participantes se conectam diretamente a ele, que mediará o recebimento e o envio das informações de cada um.
A principal diferença entre ele e um servidor central é que o anfitrião tanto "roteia" a partida quanto participa dela. Portanto, não há a necessidade de um servidor mantido pelo desenvolvedor do jogo, uma vez que cada anfitrião será responsável pela intermediação das informações entre os jogadores da partida enquanto este ainda participa dela.
.
Mesmo assim, é possível utilizar um servidor central no seu jogo: você impedirá a formação de anfitriões (todos os participantes serão apenas jogadores comuns). Porém é necessário lembrar que isto requer a contratação de um servidor central para rodar constantemente seu jogo, logo, a conexão entre os participantes é vantajosa por ser mais barata.
Para que os pares consigam se conectar ao anfitrião eles precisarão saber onde eles estão e como conectar a ele. Isto envolve a utilização dos endereços de IP, existentes com a utilização de qualquer roteador.
Atualmente roteadores restritos (uso pessoal) são muito comuns (a internet ficou sem endereços IPv4 por muitos anos), o maior trabalho é utilizar um único endereço de IP para vários usuários - algo feito pela NAT, sigla em inglês que em uma tradução literal fica "Tradução de endereços de rede".
Por exemplo, em sua casa ou escritório provavelmente há um roteador que é compartilhado pelas pessoas que moram/trabalham com você. Nesse caso, uma variante do NAT faz com que cada usuário possua o mesmo IP, diferenciados apenas pelo valor de sua "porta" (A,B,C,D etc.).
Há várias variantes de NAT por aí: de larga escala (que são utilizadas para regiões inteiras), ISPS, ou até redes de celulares, sendo algumas mais restritivas que as outras.
Infelizmente isso significa que em alguns casos a tentativa de conexão entre os jogadores não irá funcionar, principalmente se tanto o anfitrião quanto o(s) par(es) utilizarem NAT's muito restritivas.
Contudo, caso as configurações estejam corretas, os jogadores conseguem conectar entre si na maioria das vezes, e geralmente quanto mais próximos estes estiverem geograficamente, mais provável será de haver uma conexão de boa qualidade. Essa é uma das razões para recomendarmos a utilização do sistema peer-2-peer (conexão host-pares) em computadores que estejam ao menos no mesmo continente.
A conexão será realizada automaticamente pelo WebRTC. Ele tentará estabelecer uma conexão com o anfitrião através das restrições do NAT. Isso significa que o jogo não será "roteado" a partir de uma porta específica, mas sim a partir da(s) porta(s) que o WebRTC identificar como funcional/funcionais.
Por exemplo, no diagrama acima temos três clientes que dividem o mesmo endereço de IP, portanto, caso um par se conecte a um jogo pelo IP mas seja direcionado à porta A ele irá se conectar ao primeiro computador, à porta B ao segundo, à C ao terceiro e por aí vai. Tenha em mente que em alguns casos dois desses jogadores (que compartilham o mesmo IP em portas diferentes) não irão poder se conectar um no jogo do outro (pois será identificado como 2 anfitriões), sendo necessário, portanto, que outro computador com um IP diferente atue como anfitrião e esses jogadores se conectem apenas como pares.
O IPv6 tem ganho crescente adoção na internet, com um espaço de endereços muito maior. Isso permitirá que cada aparelho conectado na internet tenha um IP único, tornando o NAT desnecessário e permitindo conexões entre quaisquer aparelhos na rede. Até lá, esses problemas de conexão serão uma consequência infeliz do IPv4.