UNet/Forge/Bolt/uLink...so confusing. Another "What's for me?" post.

I am building a pvp space combat flight simulator where players can cooperatively act as pilots or crew on single and multi-crew ships in mission-based space battle arenas.

I've spent a few days researching the various networking solutions available, compare-contrasting what I'm able to find about each one, and marking off those I know won't work for me. Primary requirements:

• Easy to use. I'm not new to software engineering, but I am brand new to networking games and mine doesn't follow a typical model where I can easily copy others' work (like an fps).
• Authoritative server. Even ignoring cheating, this is the only way forward that I can see for allowing anyone to control anything, such as swapping pilots mid-game.
• Supports 10-30 users in a single arena.

UNet originally captured me as the best solution. It's free, it's built-in and supported by Unity, and appeared to have a large community. It's as flexible as I need it to be. But after spending two weeks struggling to network my game, I'm having significant doubts. So far I've only been able to network the player avatars and most of the ship movement and control. I've had marginal success getting help from the community. I'm finally jumping into game dev after losing my previous job and deciding to see this as an exciting opportunity...which means I'm not excited about paying $150/hr for Unity Premium support. If it was more reasonable like $60, sure, but it's not. So I'm looking into other options.

Forge and Bolt both nail my required list, and appear to have largely identical feature-sets as far as my game is concerned. The current differentiators that I can see is that:

• Forge currently has much more responsive support.
• Bolt has recently been aquired by Photon. While this means nothing for me now, if Photon did support the features required for my game I'd be going with them because they can also provide services such as hosting that I'd otherwise have to do myself. I expect before long Bolt will also have similar services to Photon Cloud. Of course, that's just an expectation and not solid ground on which to make a decision.

uLink looks like it has a fantastic featureset and great tutorials/examples, but I've read numerous times that they aren't very responsive or supportive of their product. This is worrisome to me. They also cost more but have a trial so I can at least test first.

Um...what should I do?

I've read through this entire thread which is prefectly relevant but I didn't want to necro:

• http://forum.unity3d.com/threads/mu...oton-ulink-darkrift-forge-and-playfab.294852/

 

Hello there!

I am glad that our system (Forge Networking) nailed your requirement list. I would be happy to invite you to our slack chat channel so that you can ask the devs on our system what they think of Forge. Some are long time network programmers and some are brand new users.

Do not go off of this... They have nearly abandoned Bolt from what I have heard. Their reviews have said as much and we have a pretty large Bolt user base that moved to Forge. Don't take my word on it though, you can ask the users in our chat channel

Please ask us any questions you may have and we would be happy to help! If you want to join the chat, just send us an email to support@beardedmangames.com or send me a pm with the email you wish to use

 

From your description it sounds similar to a game I started writing using my DarkRift Networking, its certainly possible and it wasn't that hard to do as I remember, it just dropped out of my scope due to work!

From your primary requirements list it suits all those:

• Easy to use: DarkRift is designed to be as simple as possible, whilst that doesn't always translate directly to easy of use, it does mean that there's very little to learn in terms of the APIs and how to use it - everything else can be built on top of that.
• Authoritative server: Yup! It's authoritative, usually you would use it as a standalone server without Unity but with the next version you'll be able to host it within Unity to make use of the inbuilt physics etc. if you want them. You'll obviously lose a bit of performance due to the threading bottleneck in Unity but that's a trade off you'll have to decide for yourself
• 10 - 13 Users: Easily

DarkRift doesn't have quite the community that the others do but send me a PM or an email and I'll be able to get back to you usually the same day

Jamie

P.S. Thank you for not necroing

 

I would appreciate if you not spread false/wrong info: We believe in Bolt and continue to drive it forward. We just released a new version. Nevertheless Bolt may be hard for networking beginners - it is for ambitious indies with networking experience and professionals.

We are around since 2003 now building networking technology and we have seen a lot of solutions come and go. Bolt will be an integral part of our Photon Cloud: Realtime, Turnbased, Chat, Voice and Bolt. It is here to stay.

We always respect other networking teams and their work. So I would recommend you do the same.

 

Hmmm, I am very sorry about this. I didn't know it was still being worked on. We have a huge user base who left Bolt and claimed it was dead. We were even told by developers that fholm has been missing, they are not getting any responses from a guy named "Christof" or fholm. They were super angry about it. We also were told that there has been no activity on the repository in 30 days.

I deeply apologize for the misunderstanding, my goal is not to make other systems look bad, it is to just give information that I have been personally told by others. If this information is false or wrong I am glad you told me about it, that is why I said "Don't take my word on it though, you can ask the users in our chat channel ". If the information I have been given by users is correct, then it is not me who is making the system look bad, it is the creators/owners of the system.

 

@bertelmonster2k - Great to hear that you guys are pushing forward with Bolt. As a Bolt license holder, that gives some renewed hope for Bolt as a possibility

@Palimon - I'm kind of in limbo myself as far as what networking option to go with. I really liked Bolt up until the point that fholm seemed to disappear. I had bought the license in hopes that it would eventually support a larger user base. Even though it didn't fit my needs at the time, I really thought it was going to be a good project to get behind. Hopefully teaming up with the Photon folks will breathe some new life into it. I do know of a couple of teams who are still heaving vested in Bolt within their projects and are still moving forward with it.

With that said, I have been watching other projects with interest as well. I know some folks who have adopted Forge and like it. So I have been watching it. Not a big fan of them bashing other network options. Would kind of rather see posts based off of what it can do more than posts about where others fail. Regardless, I am still receiving good feedback from teams that I'm friends with who are using it.

The other one that I'm watching, although maybe still a bit skeptical, is uNet. I really like that Unity is putting development into a base networking option. However, skepticism comes into play regarding the timeline. How much are they going to put into it and will they maintain development on it. I hope so. But time will tell.

My thoughts are, the only two mature options out there are uLink and Photon. The problems with those are, the licensing and sometimes the support, especially if you are an indie and don't have loads of cash to throw at the networking option while you are developing your first game. And I have heard a lot of the same stories as you touched on in your uLink mention about their support. Unfortunately the other options are still kind of new and still being developed. So it is really hard to make a recommendation for those who need a networking solution right now.

To me, the ones to watch if you aren't in a hurry are Bolt, Forge, and uNet. Hoping Bolt pushes forward since I already own that license, but I'm still watching the others and talking to their users in case I need to change my thinking when the time comes that I need to start dealing with networking.

 

I took some time browsing your forums to see if I can find any updates on what Brent was talking about and saw a lot of emails questioning the purchase of Bolt.

http://forum.photonengine.com/categories/bolt-engine

It would seem from the lack of responses that the customer is always right in this regard; so I will say that they seem sadden by the development exit games has given Bolt customers. Taking a look at the asset store page there is a lot of reviews that say it has 'Died/Dead' with being marked as Most Helpful. End users have been hurt by this obvious lack of care, we do hope that they are still able to finish their amazing projects.

 

Bear in mind that the public release of Unet is just over two months old, and as well that it's apparently Phase 1 of 3 in Utech's master plan for networking in Unity. This makes it tough to get community support, since it seems like much of the community is still figuring it out. (That said, props to @seanr for his usual prompt responses to threads)

I started learning networking about 3 weeks ago, so while I can't give you an opinion on the other options available I can provide you feedback from the point of view of another first-timer. I've done two prototypes (on my second) for a first person battle arena game, and overall Unet's HLAPI probably doesn't have my stunning endorsement. I'm not sure how deep you've gotten into it, but I've gotten as far as client-side prediction and server reconciliation, and the cracks in Unet are already pretty huge. The difficulty in sending RPCs to specific clients, or even client communication to the server (only allowed through the player object if you're using [Command]s!) have convinced me it's probably better to give up on the HLAPI and work with the LLAPI for my third prototype.

An important part of networking in Unity is realizing that true client-side prediction and lag compensation (a good article available about that here) are essentially impossible using Unity's physics, as you can't "rewind" them to a previous state to verify hits on the server and whatnot. So if you're planning on having your spaceships shoot precisely and move at fast speeds, this may be an issue for you. Bolt does have rewinding built in (I think fholm just uses OverlapSphere and Raycasts for everything), but I don't know about the others.

 

Well you can have multiple player objects, you need to use the playercontroler id. I think the biggest downside for me is that we need to use a NetworkBehavior for the HLAPI. I probably just use the LLAPI and see how it goes.

 

Btw, thanks all for the reviews/dialog, keep'em coming! It's been helpful to get a lot of up-to-date opinions.

 

How is this not possible using Unity's physics? You'd only have to store the physics related game state of "rewindable" objects in a sort of list and index it based on time (ie position, rotation, animation keyframe, etc). That sort of functionality isn't inherently tied to the physics or the networking engine, but instead sits on top of them.

Whenever you need to verify a hit, (ideally at the end or beginning of the frame that you received the shoot packet), set the state of the relevant objects (players and rigid bodies) back to their states as according to the list, process hits, and restore their positions.

Obviously easier said than done, but the argument isn't that lag compensation is easy now is it?

Note: It seems the article you linked is saying that rigid body simulated extrapolation is not possible because of the fact that you can't rewind the time increment (which I'm not 100% sure that's what any game does). He is not referring to lag compensation. Not sure his argument is valid since I've never personally looked into rigid body prediction, though my gut tells me it's very possible with unity.

 

Awhile back I was doing some tests relating to using OverlapSphere for a custom character controller, and I ran into the issue that Unity didn't actually update a collider's position immediately upon moving it (whether directly through the transform or using Rigidbody.Move), but rather only at the end of the physics update loop. Here's the code I used to test this:

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class PhysicsTest : MonoBehaviour {
6.  
7.     [SerializeField]
8.     Transform target;
9.  
10.     [SerializeField]
11.     float radius;
12.    
13.     // Update is called once per frame
14.     void Update () {
15.         // Cache the target's original position
16.         Vector3 previousPosition = target.position;
17.  
18.         // Move it directly overtop the sphere's position (we can't miss!)
19.         target.position = transform.position;
20.  
21.         Collider[] cols = Physics.OverlapSphere(transform.position, radius);
22.  
23.         foreach (var col in cols)
24.         {
25.             Debug.Log(col.name);
26.         }
27.  
28.         // Return to the original position;
29.         target.position = previousPosition;
30.     }
31.  
32.     void OnDrawGizmos()
33.     {
34.         Gizmos.DrawWireSphere(transform.position, radius);
35.     }
36. }
37.  

The target object is anything with a collider on it (I have a trigger BoxCollider in my example). This moves the target object (which is not colliding with the overlap sphere at the start of the frame) directly on top of the sphere, runs the check, then moves it back. So when the check is done, the overlap sphere SHOULD detect the collider, right? Apparently not. If you comment out the final line (returning it to it's original position) it detects it as normal, so we are sure the method itself works properly (if updating the colliders does not). You can see why this would be a major problem for lag compensation and rewinding, since you wouldn't actually be able to run any verification "immediately" upon rewinding colliders to a specific position, none of the tools available would actually detect them having moved. (I don't recall if I tested Raycast or SphereCasts, but I probably did and they likely follow the same rules).

...or at least, that's what I thought happened. I ran this in Unity and it actually worked as intended. Convinced that I was completely insane, I downloaded Unity 4.x and ran the exact same script, where it does not work (no collisions are recorded). Apparently from Unity 4->5 this has been updated...which is very nice, since the only other alternative would be to write a simple collision detection system by yourself.

 

any1 still have uZone files?