[Sigma Tau] Dev Log 02

I have taken a break of a couple weeks, filled with a vacation and my other projects.

The networking structure I have built is proving to be fantastic.  (I guess I hope it is, the first code was made 2 years ago… and it is very different now than then.)  The way the networking is handled now, it is trivial to make a port with any value I want to sync (exist on the server and on terminals).

It is time to put some effort into actually being able to do things in the world.

In developing the world, I need to be able to see it, and make changes to it.  I already have a radar for viewing the world.  I implemented a simple spawnerport and ui so I can spawn entities ships from the terminals for ensuring things are working.  Implementing this was a breeze--proving the effectiveness of the networking structure.  Interestingly it exposed some problem with the http/websocket library I was using (or how I was using it), which I was planning to replace at some point anyway, with a much lighter weight library, so I spent some time doing that.

Currently the work will continue making objects move and interact correctly, after some of that, I will make the player ships thrusters work.

Comments

  • The way the networking is handled now, it is trivial to make a port with any value I want to sync

    I did that for EE as well, and I can tell you, it's awesome. No need to think about low level communication protocols, just "I want this variable/member on the client as well"

    Making sure your communication library is always working properly is important. One of the major EE bugs was that it dropped data when networks where congested. SFML's TCP Packet stream was just corrupting itself. Which was never noticed during initial testing, and only happened when we scaled up to 2 ships on LAN (10 players)

    Sound like you are making decent progress :) wouldn't mind seeing screenshots as well, even if it's early and really developer art/ugly, screenshots are always nice.

  • Well, decent progress (:

    I did that for EE as well

    Oh cool, I haven't actually dug into EE's networking code, so I haven't seen what you did. It does work really nice, I wish there were more libraries doing it, or maybe I just have not found them... (I think Unity does something like that, but I am not sure)

    SFML's Packet stream corrupting itself

    That is disappointing, but I have not become a very big fan of SFML anyway. I am not a big fan of catch-all libraries either, what is SFML? a graphics library, windowing, system, sound, networking, or all of those. What if I don't like how SFML does one of those?

    I will keep an eye on that kind of problem with the library and networking code I am using.

    screenshots

    Well, um, here is a screenshot then

    That black circle is the so-called UI Radar. The black square is a slider (the background is white...)

    As a developer you know to look past the surface, it is just the tip of the iceberg of the code underneath. ...but code is not fun to look at.


    I did get a client going on my computer and on each of my phones (one of which is a PinePhone running Linux which I just got!); it is cool to see the networking working with the slider and radar moving/responding on all three.

  • edited July 11

    It does work really nice, I wish there were more libraries doing it, or maybe I just have not found them... (I think Unity does something like that, but I am not sure)

    Oh cool, I haven't actually dug into EE's networking code, so I haven't seen what you did.

    Well, the details are a mess of templates and function pointers, but the usage is really simple:

    The concept I got from the unreal engine (older 1999 version) where you could just mark variables are "replication" and they will be send to clients.

    One of the things I never got working in EE was replication of "pointers", so that always requires an ID which is then looked up on the client side. With my newer engine I actually implemented pointer replication properly, which makes code even cleaner on the usage side.

    That is disappointing, but I have not become a very big fan of SFML anyway.

    Well, I have not become a very big fan of SFML after using it for EE. I recommend against it for anything serious. Like this bug was known, but not documented or fixed for years. (It is sort of fixed now) but also the keyboard input handling is a mess where all kinds of small details are problematic. Their rendering functions have all kinds of small "hidden" things, where certain features might not work on certain hardware. And cooperating with OpenGL is a mess.

    I've dropped SFML for SDL2 in all things I did after EE. And will never go back.

  • edited July 11

    With my newer engine I actually implemented pointer replication properly

    Out of curiousity, how? My guess: allocating parallel blocks on clients and servers, then sending offsets into it which get converted back to pointers on the receiving side? Taking into account differing arch's on client server could introduce complexity to that, but could be overcome by sending array indices as the "offsets". Might be additional complexity around avoiding sending offsets to things the receiver hasn't initialized yet. Sending a batch of pointers that form a cycle could introduce races if sufficient care isn't take, etc. But I'm just guessing. (I suppose the same is true of sending IDs though.)

  • No, I just send over IDs, each object has a multiplayer unique ID. But it's all "invisible" when you use the engine. What the hard part was to make sure an object exists before you send over an ID that references it.

    When I talk about pointers, I'm talking about my own breed of smart pointers, which have a bunch of useful properties for game engines.

Sign In or Register to comment.