Sunday, February 19, 2012

Networking in UDK

Alright, here goes. My first somewhat educational post, and I declare that it shall be on the illusive topic of networking. This will primarily cover the basic issues of creating a server, connecting to that server and also creating a combination between a client and a server. But first, an introduction to the concept of a client and a server.

Clients and Servers
When you play a multiplayer game, the application you are running is a client - it is in constant communication with the server, which is the central element that makes all the decisions. You don't communicate directly with any other clients - only the server. For example, if you were playing a first person shooter and you shot at another player, the fact that you fired your weapon would be registered first with the server. The server would then determine your position, fire a bullet from there, and then figure out whether or not another player is hit. If another player is hit, the server contacts that client and delivers the bad news.

Now, that is an ideal situation, where there is no lag and your server is running on a very powerful machine - then again, it's not that taxing of a scenario. Regardless, every message sent to and from the server will cost time - a few milliseconds, perhaps, but it adds up. Therefore developers need to make the decision of what functionality rests in the client's hands, and what rests on the server. Perhaps you will give the responsibility of figuring out whether or not a player is hit by a fired bullet to the client of the player who fires. This would take a bit of load off of the server - but at what cost? Perhaps a modded client is being used, allowing the player to merely tell the server that it hit everyone in the match and dealt a boatload of damage. It's unsafe and extremely exploitable.

That's kind of irrelevant to what I want to discuss, though, but keep it in mind.

Creating a Server in UDK
Pretty easy. You can do it through the command line. Navigate to the folder that contains your UDK.exe ( UDKFOLDER\Binaries\Win[32 or 64]\ ) and run the application with the following command:
UDK.exe server
Surprisingly easy, isn't it? I spent a ridiculous amount of time trying to hunt down any documentation on UDN, and that was all it required. Infuriating, almost.

Of course, you can be a bit more flexible - the above command opens the map you've currently set in your config files, along with the corresponding game type and whatever else. You can extend it to the following:

UDK.exe map_name?game=game_type
There are other parameters, but I'd sooner send you to the UDN Page.

Connecting to a Server in UDK
Also very easy. Once you've got a server running using the instructions above, open up your UDK game (don't play through the editor, for some reason it doesn't work there - you have to load it up using UDK.exe). Once your game's loaded, open up the console (tilde key ~ by default) and type in:
open your_ip_address
I'm guessing that in this case you're running both the server and the client on a local network (or on the same machine), so you're probably going to be using your internal IP. If you don't know what that is, go into your command prompt and type in "ipconfig". It'll (probably) be listed as your 'IPv4 Address'. In my experience, most of them follow the format 192.168.*.***

Of course, if you were using this approach over the internet, it could get a bit more complicated. You'd have to use the server's IP address, although I imagine there may or may not be some port forwarding required. That's just a guess on my part, but be aware.

Once you've used the console command in UDK, it should load you directly into the level. If you want proof that you've connected to the server, switch over to the server's log window and look at the title bar. If it says (1 players), you're doing something right. If it's still at (0 players), you're not connected and you've probably done something horribly wrong.

Creating a Server that is also a Client
But what if I want to host a game, but play in the same window? Well, you're in luck, because I discovered how to do this an hour ago. Specifically what I discovered was how to start a server from the console instead of the command prompt. For those who need a refresher, the console is something you run inside of UDK, the command prompt is part of your Windows OS, through which you pass parameters before actually loading up UDK.

Now I'm not completely sure about this, but it seems to me that if you want to allow players to host a server from inside of your game (probably through your UI), you'd have to do it through the console, since the command prompt only comes into play before you've opened the game program. Luckily, there is a way to do this.

Once you've loaded up your game (once again, not through the editor, but through UDK.exe), open up the console and type in:
open your_map_name?listen
If you're running UDK with the log window open, you should see the title bar change to list the number of players (which should be 0). Furthermore, your game window will load up the map and place you inside. I'm not sure why it counts the players as 0, despite you being in there, but that's just how it works.

Listen is the mode for the server itself - as opposed to Dedicated. When we were opening a server using the command prompt, it was dedicated because it was not doubling as a client. Please note - it does consume more resources to run a listen server than a dedicated one - but then you're also gaining the ability to exist as a player on the server, so it seems fair.

That pretty much covers it. Now, I'm starving and my eyes are a bit fried from staring at the screen too long - I think it's time to boil some spaghettini and warm up the leftover meatsauce. While that last bit was completely irrelevant to you, the next is not - since networking and replication go hand in hand, I will be posting a brief overview of the main components in replicating variables across clients, and how this can be used in your multiplayer game.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.