BGE Networking

Hi everyone!
For those of you who know me (or of me) you probably relate to my work on multiplayer. So I thought that, If I was going to make anything new it would have to be multiplayer, correct?
I’m not going to disappoint!

I’ve been working on support for an autonomous network library for the BGE. This differs from my previous addon in the sense that it is far more powerful, and from my previous authoritative work in that it is much more extensible, predictable and user-friendly.
I’ve been studying the Unreal architecture for inspiration, and it’s getting to the point where I can actually show something to people.

At the moment, it’s not fully complete. I’ve attempted to design this for any Python based game engine, rather than the BGE alone (Because, whilst I don’t intend on advertising to other engines (/Python environments) just yet, maintaining an abstraction helps to keep code clean and offers the option to add more platforms later on).

Here are some of the current features:

  • Automatic “replication” of network attributes from client to server
  • Primitive support for game rules which determine the higher lever game logic.
  • Automatic “replication” of RPC calls (Function replication for Unreal)
  • Broadcasting attribute callbacks (“RepNotify” for Unreal)

I have a Document describing the internals a little further here but here’s also a short summary:

  • Replicating involves taking values from one peer to another. All replicated values are static typed, meaning once you declare an Int, it must always be an Int. Network attributes are declared using Attribute() and they protect you against accidental setting of the wrong type with a TypeError.
  • Function replication / RPCs are no different. You must annotate each argument with its type, and you can choose (like Attributes) to provide additional keyword-data that the serialiser can use, like float-precision or number of fields.
  • To help reduce bandwidth, there is a conditions generator function. Use it to tell the server when variables should be replicated. There are three arguments; is_initial (the first time we send data), is_owner (the client getting the data is the one who this replicable represents) and is_complain (if the complain flag has been set by any variables that can influence it. This is used when you want to avoid heavy conditions by grouping related “base variables” so that if none of them are changed, we avoid doing unnecessary calculations inside the condition generator).
  • There is support for mutable types like Vectors, but they cannot raise the complain flag (so beware). Often these change the most frequently so it would be unwise to use a complain flag.
  • RPC calls are sent between the client who owns replicable and the server, so they are one to one mapping. Attributes have a one to many mapping relationship, and we can use a special “notify” keyword to invoke the on_notify method with the name of the attribute. See the Unreal RepNotifyPattern
  • The serialiser is interchangeable. I am using wrappers over Struct, but there is no reason why one could not use their own library, even JSON, provided that it be able to work with static-types, and provide a specific interface.

Once this is completed, I may visit a more complete version of my Addon. (I may even be able to extend this library to do so, as Logic Properties are static typed, and actuators could become RPCs, and HIVE would be even nicer!)

GitHub:

Videos / devlog:

ReadTheDocs:
https://readthedocs.org/builds/pyauthserer/
GitHubWiki (higher level explanations)


Original design document:

OMG my head is about to explode :slight_smile: You have made a lot of progress, great job !

I have to agree, the current progress views very good! :slight_smile:

[Solved!] Little question: Which URL do I have to use, to checkout the SVN via TortoiseSVN? [Solved!]

Benchmarks:
The simple replication and rpc system currently performs the processing at about 0.26 ms per client. This is assuming a fixed number of NPCs. This test was with 40 Replicable instances that were not client-instantiated. In reality, it would be far slower to use this same number of connected clients. This test roughly equates to 14 connected clients and no NPCs. (because clients incur an exponential relationship, whereas NPCs depend upon the number of clients.

This will be sped up when I can add simply checks for relevancy. I think I will try and write some simple frustrum culling for the actors when they’re not in the frustrum.

I’ve done a lot of work since the last post. There’s now native support for nearly everything you’d want to do replication-wise. However the physics integration is lackluster, because there is not enough exposure in the current BGE API. I’m going to suspend BGE-specific development in favour of Panda3D (Who have very good Python-Physics/Gameloop interaction). Once I get things useable, I’ll generalise and move back to the BGE, with the intention on exposing the API to allow more gameloop control. Keep you all posted!
(Feel free to try it out, the link above is the same. It’s fairly self explanatory. The physics sort of works, however there’s no real usage of autonomous_proxies yet (which are used for local players). To remove physics, simply delete the relevant code after the player_update() method in the game.Game class. Beware that the server game rules expect a physics object somewhere so delete that relevancy check). I’d be interested to see what people achieve! Post here for any advice :))
P.S you still need bitarray.

I did not see this post the first time! I have to say:


Added new documentation, and made many changes to the source (best check the commit logs for more detail)

go hard agoose!!!

Thats great news, as I come from an UDK background.
Will there be relevancy? Simulation?

Thanks for your work!

There is already relevancy checks, and simulation checks. But, because this is a library in Python simulated checks are only performed on library-sourced events. So there’s nothing stopping you calling a non simulated function as a simulated object as yet.

Added better support for existing features.
Reduced RPC bandwidth
Added role replication to support dynamically changing the role in game.
Better collision callback support

I tried running your examples, but I’m getting this issue:

File "C:\Users
ame\Documents\Blender\Games\blender_example\bge_network\game.
py", line 162, in make_actors_from_scene
    is_sensor = obj.physicsType in (logic.KX_PHYSICS_SENSOR, logic.KX_PHYSICS_AC
TOR_SENSOR)
AttributeError: 'KX_GameObject' object has no attribute 'physicsType'

I know you mentioned you’ve been developing special patches for BGE physics exposure. Do we need a specific build of blender to run these examples?

EDIT: Nevermind. I fixed the issue by using HG1’s build. But you might want to mention this requirement, if you haven’t already done so.

I’d mentioned in the first build that you now need a custom build. Although, HG1’s will need to update as well as I’ve changed one of my patches. (This is only needed for the later demo to work). Right now the SVN is actually rather non-functional; I’m fixing a few bugs that i’ve accidently introduced, and rewriting the demo :slight_smile: Up soon hopefully.

Fixed the bugs aforementioned, trialling the authoritative movement system

Just updated to make easier to use, fixed bugs and optimised physics

Just added forced simulation checking. Now you must declare any method as “simulated” if it needs to be run simulated. If a function cannot be executed it raises a TypeError.
Updated the error statements for simulation also. I’m now considering how best to handle Weapons.
There are two main routes; using a replicated object - and stopping simulation when picked up
Using a local object replicated using the Notifier replication. This would be easier as it avoids the need to start/stop replication, and gives the possibility of a high/low poly mesh per object, but that could be done using replaceMesh

Added physics extrapolation (smoothed) for simulated objects. This only applies to position; orientation isn’t yet supported. Added some useful property classes to tools.py

Removed the BGE bindings, but working on reimplementing them after some system changes.
Currently implemented working Patch for the internal player

Re added BGE physics (Works properly now!)
Added patch for additional features (reading physics type, and adding objects using a transformation matrix)
Fixed a lot of bugs, and hopefully ready for a basic game!

Great to hear. This library is very flexible as it stands and should allow for some interesting multiplayer aspects. Took me a couple of days to get used to as it’s more like a framework than a set of scripts for multiplayer, which is great.

I couldn’t get the examples in the SVN working at first, took some messing around to get it working, but maybe once your happy with the codebase you can write a nice tutorial or something for it. Some of the terminology in the framework is a bit difficult to understand unless you go through and figure out what everything is doing. People new to python and multiplayer coding might find the learning curve quite steep for this, but I suppose that is something you pay for, for the amount of flexibility it will give.

Your multiplayer addon is good, but this framework is really what the bge was missing for multiplayer.

Superb :slight_smile: