[Released] Bolt, The new generation of networking solution for unity!

Yes, like I have said many times in this thread Bolt is targeted at pretty much any type of 2-128 player game, but it does have a few facilities which are targeted specifically at fast paced fps/tps games, for example lag compensation and hitbox recording.

Correct, bolt comes with a simple character motor which demonstrates how to use this.

Yes this is correct, for using a normal dynamic rigidbody you would need to be able to re-simulate one by itself, which unity does not support.

Yes, but I would suggest that you use the Character Controller even for your vehicles, as it will work *a lot* better then trying to shoe-horn it onto a kinematic body (I know a bunch of AAA games use the normal CharacterController stuff from PhysX for their multiplayer vehicles)

Getting ready to package up the next release

 

Also just getting through the tutorial and learning but I was under the impression that we basically just sync the transform?

 

If you do all the simulation on the server and just relay the transform to the clients (and make the rigidbodies kinematic there), then yes - that's all you need to do. This is what the vehicle sample does.

But if you for example want to use client predicted movement with a rigidbody, which requires local simulation of a rigidbody on the client - but also on the server... things get pretty complex.

The way I usually attack this problem is in the context of the game I am building, because there is no generic solution which works for all cases here - so you look at your game, how it works and what you can do to "design out" all the issues syncing rigidbodies causes and then try to patch it together the best you can.

 

That was quick! Thanks for the answers and the tip on the character controller, I'll give it a go and see how it works out.

 

Sure, I see how that works now. Thanks.

I suppose I should wait until I finish the tutorial and understand things better before I explode with networking questions (first run at implementing it).

 

Ask away as much as you want, but yes reading the tutorial will answer "most" questions, at least the ones directly about Bolt

 

I still hope there will be some toturials(or features) for making room-based game!

 

Yes, there will be a lobby server (in the works), and tutorials on how to use it.

 

Yeah, I'm calling GiveControl. Here you go. The code is on the ServerObject, just like in the tutorial.

 

Again, I have to inquire about that second paragraph. What is the point of moving things on the server? That doesn't seems like a realistic scenario to me. There won't be a player on the server right? I mean they would be using a separate client instance even if it's on the same device, no? You haven't addressed this question that I've tried asking before (maybe it wasn't clear). Or I could be extremely confused (likely).

 

I think you are confused... what kind of server doesn't do a simulation? How does it know what to forward to all the other clients without one?

If one client is running as the server, there would be only one instance... the client is also the server.

This paragraph didn't really make sense. Maybe you could be more clear and think about what you want to ask.

 

I was thinking each client would send their movement data to the server, which would then send it back out to the other clients so they can show the same movement synchronized.

But as I said I don't understand the purpose of moving player objects on the server since normally in the real deployed game each player would be on a client - right or wrong? I have zero fundamental knowledge of multiplayer workings, that's just what makes sense to me logically.

 

If you want a simple relay then don't use bolt... that isn't what it is for really.

The server is supposed to act like the authority. In your situation... what happens if one player hacks the client to allow him to send messages to move him across the map or spawn one million gold in his inventory? Without server side simulation and sanity checking it will simply be passed on to all the other clients.

What bolt does:
- Send the user INPUT to the server
- Server takes the input and calculates the movement (can check for cheating)
- At the SAME TIME the client calculates the movement (client side prediction)
- Server sends back the movement result to all clients
- If the client produced error results (cheating, drifting, lag, etc), the server result overrides the client result and is corrected

 

Ignore most of what I wrote above. Re-reading it, I think I misinterpreted fholm's post...regardless my clients do not reflect changes in movement from other clients. That's still my blocking problem.

I don't think anyone was suggesting to manually move objects on the server actually. But letting the server move things automatically based on info it receives from clients.

 

Hello fholm,

I have a couple question about Bolt.

1) First question is what if you want to support more that 128 players on one sever is that possible with Bolt?

2) Second, Does bolt support load balancing, which would help in having more than 128 players on a server?

3) Third question, is there a culling or LOD system in place as in don't receive data from other players that are not remotely close to you or players who are not in your view making a significant reduce in bandwidth.

4) Fourth, Instead of sending vector3 for example, for the rotation could you just send a float angle and use it to rotate the player which also reducing the amount of bandwidth being used?

5) How do you make the server authoritative, in your tutorials everything you've shown seem to be non- authoritative or is ti automatic....I'm confused?

Other than that you seem to have created a really good system, really impressive really good job!

 

Being able to "directly" move things and the fact that you can render the server's view is actually extremely useful for debugging purposes. Seeing the server's view in realtime is difficult to overestimate. Just wanted to note that use case, as it's not something that most people consider until you've used it, and then you never want it to be unavailable again.

 

Thank you sir! It makes sense as a debugging thing, but not as the general method to test.

 

^ @jasonMcintosh +1. Also when you are ready for production, you can just run the server in batchmode (only available in Unity Pro, causes the server to run as a commandline with no graphics rendered) - that way you can run it on a headless set up on a server.

I am too also having a bit of difficulty understanding the issue. From what I can gather, it seems like you are trying to do a P2P (Peer to Peer) networking set up which I think is not really what Bolt is suited for. I can't see what purpose the server would have if it isn't simulating anything and just relaying client info. If that is the case clients would just send their positions, health, etc to everyone else and you would skip having a server completely. There is no authority in a set up like this. Perhaps we are misunderstanding your intentions?

Authority is in the server. The server must replicate actions done on the client's side in order to validate whether they are indeed valid commands. If an action is deemed fraudulent, then the server is there to correct the user, and or punish. As @jaybennett stated, this is done to prevent cheating on the client's side. But in order for that to happen, the server must simulate these actions or run some sort of sanity checks against them.

Also seems like you are one of the authors of Master Audio? Just wanted to slip in a quick thanks for a great plugin

 

Yes, we make Master Audio. Thank you

I'm so new to multiplayer that I may not even know my intentions lol. It sounds like it's best to use Bolt as you stated and have the server simulate everything, including physics. That's fine. But still I haven't seen my server copying my Transform's replication yet for some reason. Trying to figure that out. I'm sure fholm will help me figure it out soon.

 

It depends on if you are doing authoritative movement or not, if you are doing authoritative movement then the server will do the same simulation as the client controlling the character. If you are not, then you should spawn the entity on the client and and move it around with transform.position and that will replicate to the servers.

And I think this is where you have gone wrong: If you have the setup you have in these screenshots - trying to move the player by changing it's transform will not work (as it's not supposed to work, on basis of the authoritative movement this implements). You need to use SimulateController + ExecuteCommand like I do in the tutorial.

If you want, you can upload your project to dropbox or something and can take a look and explain exactly where you have gone wrong.

This will depend on your game, as the limitation here ends up being unitys single threaded simulation, so if your game does not use a ton of CPU then yes it should be possible - but if you're trying to do an FPS or TPS or an RPG, this wont work.

You can of course run several servers next to each other, but they will be stand-alone instances which are not connected or load balanced, that part of the infrastructure would be up to you to build.

Yes, on the BoltEntitySerializer you can override two methds: InScope and CalculatePriority, InScope lets you decide if an entity should be visible to a connection at all and CalculatePriority lets you get a priority (per entity per connection) to order all entities in regards to of how important updates are.

Yes you can compress a lot of things by toggling different options on and off, you could for example compress the rotation for your characters in an FPS down to two bytes (one byte for X and one byte for Y rotation) and still get very good representation.

The entire tutorial on the boltengine.com site implements an authoritative movement scheme.

 

You're welcome. That is alright. Networking can be very daunting and confusing especially in the beginning. Once you finally wrap your head around normal peer to peer networking, then you realize there is also authority and all the concepts that go with it... it can cause a great deal of frustration and confusion.

Here was an invaluable resource for me when I started learning about networking (only about 6 months ago)
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
It is from valve and introduces you to the way they did networking for the source engine (Counter-Strike, Left 4 Dead, you already know) They have links at the bottom and throughout the article that goes into deeper understanding on the topics. You will find most if not all of the topics there are what Bolt handles for you. (unlike most other options)

That should help in better being able to understand why certain things are done and in the ways that they are. I hope it helps. I'm no expert in the matter but I am sure if you need further clarification or help we would be more than happy to assist you. A lot of the heavy lifting and head scratching is already done for you with Bolt though, so rest at ease. And as always fholm provides great support.

 

How would you go about destroying a client's entity when they disconnect? Here is the current code that I am using:

Code (csharp):

1.  
2. public override void ClientDisconnected (BoltConnection arg) {
3.         BoltEntity entity = arg.userToken as BoltEntity;
4.      
5.         if (entity)
6.         {
7.             BoltNetwork.Destroy(entity);
8.          
9.         }
10.         BoltConsole.Write ("Destroy Client");
11.     }
12.  

This is attached to the Server Callbacks script for the RootMotion scene. I even added a Console write message, which seems to never gets called, even on disconnects. I am disconnecting the client by simply exiting the client window.

 

Hey!

So this is caused by the fact that bolt on debug mode has a timeout of 600 seconds (10 minutes) for connections, so that you can pause either the client or the server with a breakpoint while debugging without loosing the connection between them.

I will make sure to add this as a configuration option for the next release so you can easily set your own timeout. Other then that your code looks fine, and it should work properly.

 

For now you could do this simple fix in OnApplicationQuit on a script somewhere:

Code (CSharp):

1. void OnApplicationQuit() {
2.     BoltNetwork.ShutDown();
3.     System.Threading.Thread.Sleep(100); // wait 100ms so that we are sure bolt disconnects in the background.
4. }

 

Thanks, I'll read that

 

If I Instantiate the player on the clients - why does that cause different behavior than Instantiating them on the server and giving control away? And lastly how do I know whether I'm want to use authoritive or not? Or is that a dumb concern and I just should use authoritive It sounds like others on this thread definitely prefer that.

I can do all the commands like the tutorial if that's necessary. I was hoping to just do the movement copying like the youtube video #1, which doesn't use commands. Can you explain the difference between the two methods?

 

Code very similar to yours actually works for me, although it takes a few seconds for the client connection to timeout. But once the timeout hits, the entity is removed and I get debug output. I'm using Debug.Log() instead of the Bolt version.

The timeout gives this, which I guess is normal:

Code (csharp):

1. 23:23:26:327 | thread #001 | debug | error 'SendWindowFull - ' on connection to 127.0.0.1:58241[code]

 

The whole authoritative vs. not authoritative thing really depends on your game, non-authoritative is simpler to build straight up as there's less pitfalls - but you give up the servers control.

I would recommend you to go through the tutorial top to bottom if you have not, since it will explain *a lot* of questions about authoritative movement, etc.

The code to the video on youtube is located in bolt/samples/rootmotion, so if that is what you want then just take a peek there.

But to explain a bit more, if you instantiate the object on the server and then give control away to the client - the server will be the one which decides everything for this object. If you try to move the object directly on the client using transform.position - this will not replicate to the server (and it should not, since the server makes all decisions). If you want to move an entity which is spawned on the server and given control of the client, you need to use the ExcuteCommand functionality, this is explained in detail in the tutorial.

If you spawn the entity on the client directly, then you can move it around freely with transform.position (or however you like, mecanim root motion like the example).

 

This is fine (the debug error message), but i will make sure to implement functionality on bolt for disconnecting when the app shuts down automatically.

 

I just added that code and it does not fix the main problem. When a client disconnects it leaves the character behind for ~10 seconds which causes a null pointer (BoltAssertFailedException: object was null) if I am sending any sending any input whatsoever.

 

On the server? or on the client? I assume on the server? Can you paste the full log error thrown (should be in the unity log also)

 

The server receives the null pointer if a client is disconnected.

BoltAssertFailedException: object was null
Assert.False (Boolean condition, System.String message) (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/utils/Assert.cs:86)
Assert.NotNull (System.Object a) (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/utils/Assert.cs:41)
Assert.Same (System.Object a, System.Object b) (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/utils/Assert.cs:23)
BoltEntityChannel.Lost (.BoltPacket packet) (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/entity/BoltEntityChannel.cs:265)
BoltConnection.PacketLost (.BoltPacket packet) (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/BoltConnection.cs:419)
BoltCore.PollNetwork () (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/BoltCore.cs:391)
BoltCore.FixedUpdate () (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/BoltCore.cs:472)
BoltPoll.FixedUpdate () (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/BoltPoll.cs:10)

 

Thank you for that extra info. This is starting to make some sense. I had no idea why the commands were in the tutorial as the video didn't have them.

You also recommend to only have gravity rigidbodies on the server, for simulation purposes. How is this accomplished? Does one of your example scenes have this setup?

 

Good catch here, this is actually a straight out bug. The fix is easy, so I will have it fixed for todays 0.2. Yes, it is coming today - I know I've been saying "todays release" for 2 days, and it should have been done yesterday but ran into a few regressions on iOS that I had to fix.

 

The car you can drive in the vehicle sample demonstrates this.

 

Followed the tutorial, I think there was a typo with the fireworks event name/script part but I downloaded the page and was following it in an area without internet so maybe its been fixed now. kudos for the in depth tutorial!

I also just tried to give the fireworks prefab from the tutorial a serializer & state, and Im getting a repeated nullreference exception when I run the server/clients. Im assuming you would setup the fireworks prefab like the player if you want them to exist for players who havent yet joined the game right? Or does the event system do this(not sure if it was covered in the tutorial). Anyway as an artist coming from a bit of photon and tnet, although it seems like more to learn than tnet, I really appreciate how things like mecanim are taken care of, and the event system is really really interesting!

NullReferenceException: Object reference not set to an instance of an object
BoltEntitySerializer`1[T].UpdateRender () (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/entity/BoltEntitySerializerState.cs:42)
BoltEntity.Update () (at c:/Users/Fredrik/Documents/bolt/src/bolt/bolt/entity/BoltEntity.cs:712)

 

thelabaron: Hey!

So, the error you're getting is a bit hard to debug, basically it's saying that the state doesn't exist for the serializer, the line which crashes looks like this (line 42): _state.UpdateRender();

That's it, so it's obvious that _state is null for some reason, this can happen in a few different ways but most likely it's due to the object being instantiated invalidly (are you SURE you always instantiate through BoltNetwork.Instantiate for example?)

And yes to make the fireworks appear for players that join later, you would need to make them a persistent prefab. I'm actually planning to add functionality for this - basically "replicated props" which lets you deal with everything in an easier manner for things you drop on the ground, etc.

 

I have found another potential interesting bug that (I think) causes the server to call "MapLoadDone" twice. I have a incredibly high replication rate in making this bug appear.
To replicate this bug you click Start in the Map Launcher window and as it is building click and drag your mouse left to right repeatedly. I am not sure as to why this causes this bug to appear, I merely found it by accident.

Map Launcher Settings:
Free Launcher = false
Server Port: 54321
Editor Mode: Server
Client Count: 1

If you want, I could replicate the bug for you on Skype or I can post a video of it.

 

O.O Now that is weird, a video would be best I think as I cant get on skype right now

 

I got a null exception, too, though now I don't recall if it's exactly the same one, and I am not at my dev machine to try again.

But it's easy to reproduce:

1. Implement the disconnect/destroy code.
   
2. Run the tutorial project with two clients.
3. Move the robots close to each other.
4. Close one client.
5. While the timeout is building up, constantly move the remaining client robot into the other, so that they are colliding.

At some point during this, you should see a null reference exception.

 

Hey, yeah this is with 99% certainty related to the same null ref that LightSky got.

 

As seen from the video the bug causes the server to essentially spawn a Player twice (which the server owns both entities) when it should only be spawning one per player. It also only outputs the BoltConsole.Write message once, which makes me wonder how it is calling SpawnAvatar the second time..If you need any more information or details I can provide them, I can replicate this bug essentially 90% of the time.

Hope this helps.

 

Try just Moving the server robot, I don't even think colliding is the primary cause of the crash. It seems that just moving the server robot as the timeout is running out will cause the null exception. At least that happens when I was experimenting with the bug.

 

So, finally 0.2.1.0 is out, you can find the release notes here: http://www.boltengine.com/Releases.aspx#Beta_0_2_1_0

Other then that use the same link as always to download.

Beta 0.2.1.0
Important: UdpKit source code is now included in the source package, note that this source code is under the same license as the rest of the Bolt package, it is not open source. For the open source version of UdpKit go to http://github.com/fholm/udpkit.

Fixed: The BoltDebugStartNonPro script will now correctly select the proper configuration file.
Fixed: Prefabs should no longer accidentaly be marked as Scene Objects.
Fixed: Resolved numerous issues in the native sockets code for mobile free users.
Fixed: Resolved an issue where uint32 and int32 values of 9-16 bits would not serialize correctly

Changed: Reworked the entire build system, it's now a lot easier to build on both OS X and Windows. All build scripts and other tools are also bundled with Bolt now. The new system uses the F# FAKE build tool which allows for easier building of the entire project at once, run the Build.fsx script with FAKE. Requires Mono 3.4.x on OS X.

Feature: Local LAN/WiFi discovery is now available. A simple example is available in bolt/samples/lanbroadcast. The new methods available are:
BoltNetwork.EnableLanBroadcast(): Enables the lan broadcasting feature, call this on both the client and server.
BoltNetwork.DisableLanBroadcast(): Disables the lan broadcasting. When you connect to a server on the client this is called implicitly, on the server you have to call it yourself to stop broadcasting your session.
BoltNetwork.GetSessions(): Call on the client to get a list of sessions found on the local lan, note that this method allocates a new array every time you call it because the data comes from the UdpKit background thread.
BoltNetwork.SetSessionInfo(string serverName, string userData): Call on the server for setting a server name and custom data that is transmitted with it's session broadcast, which can then be found on UdpSession.ServerName and UdpSession.UserData on the session structs returned from GetSessions() on the client.
Feature: Two new overloads for BoltNetwork.Raise exist: Raise(IBoltEvent evnt, IEnumerable connections) and Raise(IBoltEvent evnt, params BoltConnection[] connections), this lets you raise a specific event on your own local machine and on the specified remote connections.

 

When is it an appropriate time to send bribes for creating a method to transfer networked objects in between scenes? Do you accept lingonberries, fermented fish, or just money?

In all seriousness, I would send a bribe. I know you have a ton of other features to work on though, hence the bribe. No one has to know.

 

Too late. I already bribed him with a shrubbery.

 

Check out this post. Give it a like to show your interest.

 

So, I have actually looked into both host migration and player-transfer, since they both sort of rely on the same concept: To be able to transfer ownership of an entity to another computer.

I think I have come up with a way to do this, because of how UdpKit works you can just "switch" the connection point and the client will not notice anything (sort of, you're going to have to have a sort of "transfering ..." fade out over the screen, it's not instant.

Also, transferring a player to another server is a lot easier then full on host migration (and I mean proper host migration, not the kind you'll find in TNet). I will start working on this in a separate branch for now, and will fiddling with it for a while until I have something that works (expect maybe ~1 month).

I have one question for you guys asking for this: Would you prefer me to get it completely done, and then release it, or would you like to have alpha and then beta releases of this functionality and give feedback? This does put a bit of extra work on those that want to test it as I really need proper feedback.

 

Also, I want to highlight that if you need "live" support for Bolt, the easiest way is to join this jabbr room: https://jabbr.net/#/rooms/bolt

You can log in with your twitter/facebook/google account. I try to be in there about ~14-15 hours per day (7AM CET to 22PM CET)

 

Hi fholm,

i just got a quick question for you. Since this nice "Fracturing & Destruction" Asset is on Sale, I wanted to integrate it in my game, which should also have a multiplayer with Bolt. The game schould only have a peer-to-peer Multiplayer with a kind of lobby server (when its done). Is it possilbe to sync this kind of fracturing with Bolt? What would be a good approch for this (every client calculat the fracture on its own? Just sync the position of the fragments (much traffic?)?)

Thanks a lot!

Cheers!