There seems to be a lack of tutorials on using sockets, I am wondering how people here learned them. I’ve noticed many other game engines have sockets and guides written for them, are they all pretty universal?
I guess they are universal? Does this help?:
http://old.haxe.org/doc/neko/client_server
http://old.haxe.org/doc/neko/threadserver
Btw, I’d need some tutorials too. My multiplayer system is kind of working right now, but it generates most of the hard-to-trace errors.
That is helpful, thanks for the link. I’ve got it working somewhat, and am doing a lot of testing on it, I’ll post some code when I get home with what I’ve got so far.
This is what I’ve got so far, connects and is able to read the servers writeValue() data. This is non-blocking so the server can run in the background alongside the client, but it would be optimal to thread this somehow so that the server can run in the background.
import sys.net.Socket;
import sys.net.Host;
import haxe.io.Bytes;
import haxe.io.Bytes.ofString;
import sys.net.Address;
import haxe.Timer;
class NetworkServer{
public var socket:Socket = new Socket();
public var c:Socket = new Socket();
public function new(){
var port = 4028;
socket.setFastSend(true);
socket.bind(new sys.net.Host(Host.localhost()), port);
socket.listen(10);
socket.setBlocking(false);
c.setBlocking(false);
}
public function acceptConnection(){
try{
trace("connecting..");
c = socket.accept();
trace("connection accepted");
} catch (err:Dynamic){
trace("No connection to accept");
}
}
public function writeValue(){
try{
c.write("hello");
} catch (err:Dynamic){
}
}
----------
package;
import sys.net.Socket;
import sys.net.Host;
import haxe.io.Bytes;
import haxe.io.Bytes.ofString;
import sys.net.Address;
class NetworkClient{
public var socket:Socket = new Socket();
public function new(){
socket.setFastSend(true);
socket.setBlocking(false);
}
public function acceptConnection():Void{
var host:Host = new Host(Host.localhost());
var port = 4028;
while(true){
try{
socket.connect(host,port);
trace("Client Connected");
break;
} catch (err:Dynamic){
trace("Cannot Connect Client to Server.");
}
}
}
public function readValue():Void{
for (i in 0...100){
try{
var l = socket.input.readLine();
trace(l);
} catch (err:Dynamic){
//trace("none to grab");
}
}
}
----------
networkserver = new NetworkServer();
networkclient = new NetworkClient();
networkclient.acceptConnection();
networkserver.acceptConnection();
networkserver.writeValue();
}
public function update(dt:Float,keysPushed:Array<Bool>):State {
networkclient.readValue();
}
I’m left wondering how to best structure the server though, is it better to run every “game” as an individual Haxe application, spinning one up to handle each client? Or is it more efficient to run one application on the server with many threads for each different game?
It depends on what you want to do. If you are doing something huge like WoW, you will probably have more applications serving different things, but for 95% of the games (number which I just made up) you will have one application with non blocking sockets serving many players. Look at ThreadServer in Haxe library, I use that and it works very well.
EDIT: I’ve read your post again and think, I didn’t understand it at first completely. As to the last question – I’m going for one “game world” per server application instance, I guess most of the games are like that but I could be wrong. With this you have better scalability and if one “game world” crashes, it doesn’t influence others, just to name few. It again depends on what are you doing – if the server is doing extremely simple stuff and you need it fragmented, i.e. to have many small “worlds” (for example poker tables), you could go with multiple games per instance. If server is doing more complicated stuff and you don’t need to divide your world too much, I’d go for game per instance.
1 Like
I have it on good authority that 241.3% of statistics are made up on the spot 
2 Likes
Though I do feel like there is a lot of data that can be shared between game instances, like game variables that should be static in memory and should not be redundantly duplicated for no reason.
I think with threads you could use semaphores and pass the variables to the server instance, though I’m still such a newb at multithreading I really have no idea.
I’m never did game server programming before my current game either, but my concept works somewhat like this:
Clients send commands to server. Server and clients are synchronised in a way, where clients know in approximately what tick will be executed on server, when data from them arrive there (best case scenario). Server then executes one tick of game simulation, i.e. takes all commands which arrived from last tick until this moment, simulates one tick of game and sends current game state (collection of all variables, which tend to change from tick to tick) to clients. Clients until then run their exactly same own simulation (I literally have same code running on server and clients, thanks to Haxe) using client side prediction (so the interface is more responsive and don’t wait for data from server to arrive – it just uses them to know, what authoritatively happened in the past and every tick it recomputes all steps of prediction until this moment). Static data, which need to be shared are shared only when they need to be shared.
I have network part of the server running as Haxe ThreadServer in several threads and simulation running in it’s own thread independently of this.
That’s the general idea I figured out yet, I could surely use some help here. I heard that guys from Kha are working on multiplayer support in their framework, so I’ll probably get some inspiration there. And of course, if your game is for example turn-based, this will all be different because you don’t have to do with real time execution.
What are you needing help with? Sounds like you got most of it figured out, what is giving you trouble?
Be very careful here that you are not: “re-inventing the wheel, merely because y-o-u have not encountered a wheel before.”
Game-server programming would be “voodoo” … were it not for the fact that (say …) a search for “game server” on GitHub today produced 5,391 results.
For the most part, today, “don’t assume that you have to write it. Assume that you can steal it, more-or-less, from somewhere (else), then kit-bash it into exactly what you need it to be.”
“I simplify,” of course, but the maxim still holds true:
Actum Ne Agas: “Do Not Do A Thing Already Done.”
The same principles hold true for client-side programming, as well. Even though the target-language of the package you might have stumbled-upon is probably not Haxe or OpenFL, the lessons-learned will be directly comparable.
Well, I’d normally agree, but sometimes, when you need something highly optimised (e.g. game server, especially when you are running it and therefore paying money to have it running), it can be better to learn how it works from existing good solutions or tutorials (for example Valve has some) and make it yourself. Optimised game server isn’t something cryptic and difficult once you know how existing solutions work and Haxe makes implementing one a lot easier with things like ThreadServer, cryptography libs, auth libs, database libs, etc. I’m not for reinventing the wheel, just saying sometimes is less time and money consuming when you make one yourself (if you know how), than trying to find one that suit your needs.
2 Likes
Nothing major. I just sometimes get headaches when I’m trying to polish out client prediction / server reconciliation. I’m working on this game, where I have pixel art graphics, procedurally generated parts of the world need a lot of computations and potentially every slightest entity move can modify the game world, so it is a little painful process. Not mentioning optimising it, so it can run at least 15 ticks per seconds with considerable amount of players… I already got too much offtopic there, back to the thread.