Some progress with UDP

Hey guys, welcome to the third progress report on NeREIDS development.

When I left you last Monday, I had designed and coded a connection and authentication system in my network library. This system enabled the server to allow clients to connect to it using UDP, provided they knew the server’s secret (a password on the server side, that you can tell your friends if you want them to be able to join your game), and to authenticate clients. The first time a client connects, it may register on the server with a name and personal password, and then no client can log in with that user name if they don’t also know the password. Those passwords are not, of course, sent in clear with UDP (they’re encrypted first).

That was all good in theory, but I had not tested it very far, as I ran out of time the week before. Thus, I started debugging this stuff over the next two days. I had just a few hours to spend on NeREIDS, but I guess I didn’t hit pretty far from the nail the week before, because on Wednesday :
ConnectionAuthentication

Tadaaaa !
Yea, I know, this test was on my local machine only, using the network loopback. I tested it extensively for sure, but hey, obviously lag wasn’t much of a problem for a client on my own PC speaking to a server on that same machine, right ?
Well, the system seems quite robust anyway, as half an hour later, with the helping hand of my dear Keriel who hosted the server executable, I had the same stuff working, and this time over the internet :
Connection600Km2

… I was running the client 600 kilometers away from the server.

A solo NeREIDS session would use the same mechanics as a multiplayer game : The only difference is the server being run on the local machine in the case of solo, and not allowing other incoming connections. This decision will certainly make the development of any new content a little bit harder (always thinking of the game as in a client-server relationship), but at the same time should save me from going through the headache of a later injection of multiplayer functionality into a single-player design. My solo connection test reacting the same way as the connection to Keriel’s server was the first step towards that goal.

So, that was quite encouraging, even if there’s not much to see on the client screen so far, just the same old ugly placeholder for the main menu.
Over the following days, I spent my free time actively checking ALL allocated memory for leaks, found some, and fixed every single one of them. I also successfully tracked down the Direct3D object that annoyingly refused to release since like a month ago (I can assure you, finally finding that guy was quite a relief). With this stabilized version of NeREIDS, I had then the whole weekend for the cool part of the networking system : The in-game protocol.

Well, I thought it was the cool part. No wonder I procrastinated the networking part thus far… this stuff is difficult. I wish I had some character moving on the screen for you to see, and be able to tell that the moves are synchronized between server and client… Truth is, I don’t have anything new on screen yet.

I got stuck for quite long with the problematic of keeping client and server step-locked together in time. My initial tests were not exchanging anything else than empty frames and acks, yet it was quite difficult to make the protocol react well to small pauses in the frame advancement capacity, such as when alt-tabbing the client. I then need to smoothly catch up with the server again, and not go too far in the process : I don’t want to allow a client to simulate its frame ahead of the server. Or at least I want to limit these cases. There was little information about the very issue of time synchronization in the networking papers I have at hand. Or maybe I just have to deal with an issue that happens to nobody else, cause my design sucks. Well, I don’t know for sure, but I think I got this part finally solved.

Now, about exchanging real in-game data such as character positions and moves, I guess I tried for too long to plan ahead some of the long-term features and add all those into my early design. This is not the way to go. Release early, release often should be the motto, so I’d rather try to implement some very basic functionality first, and deal with additional features and nice abstract classes later.

On the plus side, I secretly did some tooling along with my failed attempts. The FLCore library for NeREIDS now offer two new containers, improved classes for logs and debugging, and a handy serialization package.

I also gave my initial intuitions for NeREIDS terrain system some more thoughts last week.
I think I’m starting to see a path to a plausible design for terrain, one that has everything I wish it had. (No, it should not be made out of Voxels :p). But for the week to come, I’ll try to stay focused on the networking stuff anyway, and I should have a very basic… (understand a very boring, perfectly flat terrain) and one… thing… (anything… could be a rectangle for that matter) which moves around by reacting to player input.

See you next week, then !

One Comment:

  1. Great job (you crazy crazy fool) ! Coding the fun part seems to be getting closer now, keep on !

Leave a Reply

Your email address will not be published. Required fields are marked *