[NO CCU LIMIT] Forge Networking now OPEN SOURCE

Hi there! First of all, thank you for all of your support and your support in testing the beta!

1 Perpetual license per developer . Go ahead and make a million projects with it!

So, since the beta was using compiled .DLL files, it may be a little bit tricky to update a few things. Basically, anywhere that you used the raw scripts (I will list a few common ones below) you will need to replace them with the new open source script. If you derived your script from any of the built in scripts, then you will not need to update those.

List of scripts to fix:
SimpleNetworkedMonoBehavior
NetworkedMonoBehavior
NetworkingManager
NetWorkerKiller

Be sure to check your prefabs for these scripts as well. It may be best to write them down as I think that if you import the new stuff in you will just get a bunch of compile errors and not be allowed to replace them.

 

Release Version 3 Available!

Thank you @tatoforever
You requested an awesome feature last night. Basically it was asked to make something like [NetSync] which will be added above a variable that you as a developer want to sync across the network. It is simple, it is clean and it is now a part of the system!

Video Tutorial:

Usage:

Code (CSharp):

1.     [NetSync]
2.     public int myNumber = 0;

or:

Code (CSharp):

1.     [NetSync("Print", NetworkCallers.Everyone)]
2.     public int myNumber = 0;
3.    
4.     public void Print()
5.     {
6.         Debug.Log("The value of myNumber has changed to " + myNumber + "!");
7.     }

We are proud to announce that Forge Networking V3 is up! If you already purchased the package, just jump over to your profile page and download it!

Release V3 ChangeLog:
Fixed warnings with Unity 5 and the platform checks in StartGame
Added new [NetSync] attribute so that it is easier than ever to replicate a variable across the network
[NetSync] Now can have callbacks so that you can execute methods upon change of the value of the variables!
Added more comment documentation into NetworkedMonoBehavior
Commented NetRef
Added new global NetworkCallers enum
New Ping methods implemented in the core system to better track network latency
Added license (seat) count to your profile page on the developer portal
Fixed runtime warning in NetWorker for editor catch exception e log

 

I should add that the NetSync automatically already works with all of the data types that we currently support for serialization. To learn more or see the current serialization list visit: http://developers.forgearcade.com/Tutorials/MasterClassBeginner/Serializing-Fields-And-Properties

 

You guys are lightning fast! Feature request added almost instantaneous!
More feedback soon!

 

How often is the netSync object updated? If I have something which is changing rapidly, say health and someone is being attacked a lot or have a Damage over Time being done on it. Would it flood the network, or would it be limited to a certain rate?

Phil

 

Hi there! Yes, in Forge we actually let you control the speed (per network object) in the inspector. So if you want a particular object to serialize slower across the network (controlled). To control the speed that an object is serialized across the network you just need to change the float value in the "Network Throttle" of the NetworkedMonoBehavior. This value is in seconds. I will updated the message above this value to state that it controls the speed of the serialization of the [NetSync].

 

What does NetworkReceivers.Others do? I thought it would refer to all other connected instances (excluding the current one), but it appears that that isn't the case. Does it refer to all the clients?

 

How is your implementation done? It should send it to everyone but the caller.

Thanks!

 

if (Input.GetButtonUp("Fire1")) {
if(gameOver) {
clickReset = true;
gameText.text = "Waiting for other player to accept...";
RPC ("resetRequest",NetworkReceivers.OthersBuffered,xPlayer);
}
}

When the client clicks and activates this code block, I have a debug.log showing that the RPC request is being fired on both the client and server.

 

Does Others without others buffered produce a different behavior?

 

No, it does not.

EDIT: I realized I had a misunderstanding of how Debug.Log works. I thought the Unity console log would only show logs from the instance running from within Unity, but it actually only shows logs from the server instance! My issue was caused by something other than Forge, which I managed to fix. Sorry to waste your time, and thanks for the assistance!

 

Haha no worries. Glad I was helpful (hopefully) and please do feel free to contact us with any problems or feature requests. We want to make this as easy to understand and use as possible!

Thanks!

 

Guys, some questions before payment
1)Is it supported unity 5?
2)is it supported work in webplayer(plugin) and webgl?
3)Is it suitible for 3d slasher game like Rune ? Fast damaging, rotation. And i need supported rigidbody replication for throwing melee weapons like hatchets for damaging.
Thanks

 

Hi there!

Yes, we write the system in Unity 4.6 and then port it to Unity 5 to do tests before we upload our Release

There is Webplayer support because we support TCP connections. This was the primary reason we support TCP connections. Though others only use UDP (the standard which we primarily support too). See the Unity documentation on why TCP is preferred over UDP for Weplayer: http://docs.unity3d.com/Manual/SecuritySandbox.html

Currently we do not have support for WebGL. We have experimental code for WebGL but there are two major reasons we do not announce official support.
1) Unity 5 WebGL is still preview (not official) and therefore not complete (where websockets are the last of their worries)
2) Websockets themselves are not stable yet. See: https://developer.mozilla.org/en-US/docs/WebSockets

That being said. We are actively testing WebGL and Websockets. Once we have a mostly stable implementation, we will be releasing it. Even if Unity 5 WebGL is still in preview and the stability of Websockets is still questionable.

Yes . We worked with our beta testers on a variety of games from RPC (message only) games, to racing games, to First Person Shooters, builders, strategy and simulation and more. We support Rigidbodies because our server runs in a Unity instance so native Rigidbodies are built in .

Please let me know if you have any concerns, other questions, or need me to go further into detail on these topics! Thank you so much for the great questions!

 

I just purchased Forge and had a couple quick questions.

-Is there any support yet for Tokens (for storing/accessing generic user info)?
-Is there a list of all networking events in Forge for ease of access? (OnPlayerConnect etc.)
-Can you assign ownership of an object to another user? (Server spawns players and then assigns control)

I am just curious if the functionality stated above is already implemented or in-development, otherwise it is working great!

 

Hi there! Thanks for the support!

Is this in relation to the current running session or are you asking more about a data store (database or persistent data system)?

If you are asking about the current running session, we are adding a transient key-value store on the server . As for a persistent data store, we will have that as the arbiter is being developed. We are hoping that the transient key-value store will find its way into Release 4 which will be coming very very soon!

We actually got this request recently as well. We are currently working on various documentation and videos and will be sure to make a list of these events that are available.

We started working on this feature and hope to have it in release version 5. We received this request via our feedback portal on the website some time ago and it was pushed back for some other key features. We recently started going back through our feature requests and came across this one.

Edit: I have mistaken what my meant by this question. Actually we already do this by default as part of the authoritative server design. I thought you were referring to re-assigning the ownership from one player to another.

Awesome! Thank you so much for taking the time to leave us some feedback so we can determine what is important to the Forge user base

 

Release Version 4 Available!

Please note that we will have new video tutorials to demonstrate how to use the new Cache system soon!

Whats new in version 4:

• Added some helper messages and exceptions for new users
• Fixed bug where Type byte was having issues being sent as a parameter of RPC
• serverDisconnected event is now called on client when the host forceully closes with a string message
• The main player is now accessable statically through NetworkedMonoBehavior.Player
• Added new BeardedManStudios.Network.Cache static class for easy transient key-value storage (to become persistent)
• Added a indexer for the BMSByte (opperator overloading for the [])
• Fixed WriteRaw to prepend with proper byte before sending
• Added an optional bool to the BMSByte constructor to prepare for raw
• Cache class now communicates with server/client and allows for storing of data bound to a string key
• Fixed bug with using alternative BMSByte constructor
• Now WriteRaw can be reliable if a reliable key string is provided
• Updated documentation to use NetworkedMonoBehavior as to not confuse new users

Quick example of cache system:

Code (CSharp):

1. // Server code
2. Cache.Set<int>("test", 9); // Saves the key "test" to be the value 9 which the client can retrieve
3.  
4. // Client code
5. Cache.Get<int>("test", (object x) => { Debug.Log(x); }); // Prints out 9

Thank you all so much for your great feedback and suggestions! If you are having any issues, have any more requests or find any bugs, please let us know! We are really happy to see all of the things everyone is doing with the system and are super thrilled with the support we have been getting so far!

Just because we didn't post version 3's changelist from Friday, here is what was new in version 3:

• Fixed warnings with Unity 5 and the platform checks in StartGame
• Added new [NetSync] attribute so that it is easier than ever to replicate a variable across the network
• [NetSync] Now can have callbacks so that you can execute methods upon change of the value of the variables!
• Added more comment documentation into NetworkedMonoBehavior
• Commented NetRef
• Added new global NetworkCallers enum
• New Ping methods implemented in the core system to better track network latency
• Added license (seat) count to your profile page on the developer portal
• Fixed runtime warning in NetWorker for editor catch exception e log

We have also created a fun new demo to help new users create their first ever networking game (TicTacToe). This is completely done with RPC methods. Just head on over to http://developers.forgearcade.com/Profile to get the latest version of Forge Networking and try out the Tic Tac Toe demo found at: http://developers.forgearcade.com/Tutorials/Walkthroughs/Tic-Tac-Toe

 

Your latest videos have a tiny resolution (360p).

 

I saw that happen as well. I just checked them in a different browser and they were then at HD resolutions. Very strange, looks like our browsers may have cached only the lower version? It may quite possibly be that I may have posted this video on here before it was fully processed on YouTube and so the resolution got cached for any who saw it before then. Thanks! I'll test these on a couple other machines just to double check.

 

Just want to let you guys know that we are really happy with the support and feedback we are getting! This has been an awesome experience for us and are so glad to have you guys and the community join in on us for our networking solution. Please keep sending your feedback either through the forums or emailing to support@beardedmangames.com and we will respond to you asap. We want to put everything we can to make sure your game can work and that it is as easy to use as possible.

Thank you so much!
Bearded Man Studios, Inc.

 

Guys, i have some strange behaviour: when testing serverbrowsing button join didn't wok.

 

Hi there! I am just curious, have you opened up your port on your router firewall to point to the host machine? We will look into this issue asap as well! I am guessing that you are working with Release Version 4?

 

I never changed router settings, but have switched off my firewall. Other examples with local host works well. Used Release Version 4. And after disconnectiong and closing unity still
Online Servers: 1 in profile.

 

You have turned off your router firewall or your machine's firewall? If your router firewall is disabled then this is definitely a bug, if your machines firewall is disabled, you will still need to do port forwarding on your router firewall.

Oh awesome! Have you tried to connect to your server from outside of the network with your static ip address? (Can be found at http://www.whatsmyip.org/). If this is working then there is definitely a bug with the server browser. Do you get any error logs or warnings? Feel free to send me a private message on this if you would like to attach screenshots or would like to go into further details on this.

Thanks!

 

Hey, I'm new to Unity development and I've been loving Forge so far. I'm trying out NetSync but it doesn't seem to be working for me.

I have this in a NetworkedMonoBehavior:

Code (CSharp):

1. [NetSync("CheckInitialWaiting", NetworkCallers.Everyone)]
2. public int connectedUsers = 0;

The CheckInitialWarning() function logs the current connectedUsers count. I do the following to increment the connectedUsers on connection:

Code (CSharp):

1. if (Networking.PrimarySocket.Connected)
2.     connectedUsers++;
3. else
4. {
5.     Networking.PrimarySocket.connected += delegate()
6.     {
7.         connectedUsers++;
8.     };
9. }

If I connect as the server, it does increment the count and log it, but nothing gets logged when I connect as a client.

I'm using the UDP protocol and I'm connecting using the join with IP address button. I'm using this code to show a "waiting for another user" overlay if there are less than two connected players. I feel like I'm doing something silly.. I'd appreciate any help! You've been doing an awesome job with the support so far

 

Hello there! If you don't mind, could you send me a unitypackage via a message or email and we can see if we can get it all sorted out? It seems like the logic here is fine, however it also may depend on some other setups.

Thanks! We are doing our best to implement as many feature requests and fix as many bugs as possible

 

Release Version 5 Available!

Whats new in Version 5:

• New enforced input based authoritative server controls (including mouse) on NetworkedMonoBehavior
• NetworkedMonoBehavior now has client side prediction as an optional boolean
• Updated the layout for the NetworkedMonoBehavior editor (Will make it look pretty very soon)
• New disconnect method for when application quits on SimpleNetworkedMonoBehaviors
• New destroy on disconnect option for NetworkedMonoBehaviors
• New documentation layout on the website so that it is easier to look through
• New autostart scene and script. Now you can have unity auto build and start (N) clients for testing

Hello all! We are proud to announce that we have created a full authoritative design for the NetworkedMonoBehavior. What do you have to do? Just click the box that says "Server Is Authority". Well what about client side prediction? We have you covered here too, just click the box that says "Client Side Prediction".

This is our first step towards frequency based updates. In Release Version 6 we will attempt to have a fully functional (and optional) frequency based update system in place. What is this? This is to say that the server updates at a specific interval of time. The server will track the [maximum] previous steps and then receive time stamps with input requests. With this the server will be able to reconstruct the world at that moment in time to be able to determine the events that were to happen then. This should make all of our First Person Shooter developers quite happy .

Once this system is achieved, we will be starting to work on an optional "lockstep" implementation which will require signatures for requested actions to make for a more secure model (though this inevitably will produce time related issues that will need to be handled by the design of your game when compared to the non signature method).

Also a new text tutorial is up for the Cache system: http://developers.forgearcade.com/Tutorials/MasterClassIntermediate/Using-The-Cache-System

We will have a tutorial on Authoritative input and client side prediction very soon!

We will be doing a tutorial for the new Autostart feature soon. Basically:
1) You put the Autostart scene in your build settings along with the scene you wish to autostart
2) Put the name of the scene you are wanting to autostart in the scene name field of autostart scene object
3) Put in the number of clients you wish to autostart
4) Pick the system you wish to run on (Need to double check Mac and Linux)
5) Click Compile and Run
6) Pick a build folder
Done!

Thank you all for your continued support and feature requests. Both of these major features were requested by users yesterday and today. Enjoy and test out the new features as we begin our work on release 6!

Thank you all!
- Bearded Man Studios, Inc.

 

Really good amount of new features! Gotta try v5 tonight.

 

Thanks, we are really having a ton of fun with these features! Once I get back to my recording gear, I should be making new video tutorials rather than just the text ones we've been working on.

I would also like to state that we have pushed some critical features into Version 6! In Release Version 6 we will allow you to simulate network latency and packet dropping. You will be able to specify a packet drop percentage (between 0 and 1). This will automatically drop that percent of packets to and from the server. Network latency is a number (time in milliseconds) that you can simulate latency. When you input a latency amount, the server will delay reads on packets for that amount of time before processing them.

We are super excited to give you guys these tools. When we made some simple tests of a packet drop rate of 50% with a network latency of 500 milliseconds we could really tell how awesome this simple tool would be for developers. We ourselves are going to be using it to test all our new features!

 

I'm almost done with EC2 instances. This week, I'm going to do a massive test with 32 players and 100 networked objects that updates in real time and see how it goes. Your new tools in v6 will come quite handy!

 

Release Version 6 Available!

So I'd hate to be that guy... but... Release version 6 is available! What's with these nightly updates? Well our system is designed in such a way that we have the tools we need to easily extend the system at any point! We are actively developing the system because we are using it to develop our own games

• Updated the exception text when instantiating objects not in the lookup for better steps to fix
• New packet loss simulation for UDP (Can be set in StartGame script inspector *See StartGame.cs for implementation*)
• New latency simulation for UDP (Can be set in StartGame script inspector *See StartGame.cs for implementation*)
• Fixed error with Unity 5.0.1 having issues with the editor window
• Made time in between pings longer, it was just too short
• Added experimental frame number on inputs for authoritative input

Using the packet loss simulator is easy! Just go to the start menu scene (or look at the StartGame.cs script if you have your own connection method). Then on the Start Game script just input a number between 0 and 1 (as a percentage). This will drop that percentage of packets when communicating.

Using the latency simulator is easy! Just go to the start menu scene (or look at the StartGame.cs script if you have your own connection method). Then go to the Start Game script and just input how many milliseconds you wish to simulate of latency.

​

Edit: We also have a new text based tutorial up on how to use the authoritative input design, we will be making a video tutorial soon. http://developers.forgearcade.com/T...iate/Working-With-Authoritative-Server-Option

 

Version 7 will have a new Networking.Instantiate callback with the created object and there will be a new NetworkStart function to override that is called when an object is setup on the network.

 

My programmer already purchased the package. Thanks!

 

Mind adding how it will look like?

Code (CSharp):

1. Networking.Instantiate(objectToSpawn, NetworkReceivers.AllBuffered, PlayerSpawned);
2.  
3. private void PlayerSpawned(GameObject playerObject)
4. {
5.     Debug.Log("The player object " + playerObject.name + " has spawned at " +
6.         "X: " + playerObject.transform.position.x +
7.         "Y: " + playerObject.transform.position.y +
8.         "Z: " + playerObject.transform.position.z);
9. }

Lambda expression:

Code (CSharp):

1. Networking.Instantiate(objectToSpawn, NetworkReceivers.AllBuffered, (GameObject playerObject) =>
2. {
3.     Debug.Log("The player object " + playerObject.name + " has spawned at " +
4.     "X: " + playerObject.transform.position.x +
5.     "Y: " + playerObject.transform.position.y +
6.     "Z: " + playerObject.transform.position.z);
7. });

 

What about standart instantating like object = Networking.Instantiate ?

 

Is not possible (at least for now, not sure in the future). The reason is Forge being multithreaded.

 

Awesome, thanks for the support! They can shoot us a message if they need any support!

 

I am sure he will if he needs something. Your documentation, compared to others we have tried, is great and the support seems good as well. We are currently using uLink but tired of the lack of communication. We figure for $64, we haven't a lot to lose, other than time.

Still considering Unet but tired of always waiting for something. lol

 

Thanks! For those who are looking, I sent @tatoforever this in a PM so it is how it will look

Yes, this is true, we don't block any threads to create the object, however our system is completely authoritative so the server will verify the spawn async.

If you are needing to spawn an object on the network that does NOT derive from SimpleNetworkedMonoBehavior (and NetworkedMonoBehavior) then you should use a BRPC call and create the object normally with GameObject.Instantiate. The Networking.Instantiate is only allowed for derivatives of SimpleNetworkedMonoBehavior and to spawn a normal object in this fashion would be overkill.

 

Haha, yeah. We actually have a few people who are using the system that came from UNET as well and were unhappy with the design and direction of it. We are gladly taking all feature requests that you have from any other networking system that you have used so that we can implement common features if we are so lacking. This is how we gained some pretty cool features recently like our [NetSync] which comes from UNET's [SyncVar] as well as our Autolauncher which comes from Bolt's automatic scene launcher and connector. Please feel free to make any suggestions and you will find them work their way into the system at a pretty fast pace .

 

Honestly, Farris, our biggest concern is that you will either shut down, as three other networking solutions have done on Unity, or that you won't deliver what is promised, not through anything nefarious, but life happens.

At least with Unet and uLink too, there is a certain security in knowing they will deliver, no matter how slowly. But right now, we need something so willing to take the risk. I am Unet will be a stable usable solution someday, just have no idea when.

Later, we will see.

 

A very valid feeling, if not only because so many others have packed their bags and shut down. I am excited that you have chosen to take the risk and our hope is not to fail you or any other awesome developer using Forge Networking. We were aware of similar fears with developers and that is the main reason we offered full source code, to help ease that feeling a bit. Personally, I don't see us dropping this project, not because we have already gained so many users, but because we are using the system to develop games and applications for our studio. This is one of the main reasons that the updates are so swift, we have a "horse in the race" or "skin in the game" if either of those idioms are properly used.

 

The source code is why we went ahead. If nothing else, we can get something out of it to use.

Glad you are committed! Hope you stay that way when the going gets tough.

 

We expect the going to get tough and are working hard to earn everyone's trust. We really want to build a community of developers who enjoy or are working on networked games and applications. We are honored to see support even with such concern.

 

Brent, when is Bare Metal expected along the timeline of production?

Thanks

Phil

 

Source code is also what got my attention. I actually implemented the same requested feature in no time thanks to the source code but revert it back as it was added the same day and didn't really wanted to manage this change forever, specially now that the library is young and will probably evolve with users feedback.
I'm still in the testing process of Forge, we are setting some testing environment in which 32-64 players will receive synchronization and other network data from around 100-200 real-time entities (+ players itself). The environment is authoritative. I'll post my results later on.
And yeah uLink is quite attractive but is a giant elephant when it comes to updates. It's moving forward extremely slow.
Regards,

 

Please do post back! I would be very interested in your results.

 

I am amazed at how fast you guys are cranking out builds.
Are you able to setup an email system to send out notifications when a new build goes live for registered users on the site?

 

Release Version 7 Available!

Fewer updates in this iteration as there was a little more work to do and we were a bit distracted updating some of our tutorials. Also I am glad that we came across a pretty sneaky critical bug that happens rarely when you have 2 scripts that derive from SimpleNetworkedMonoBehavior on a single object (see why making video tutorials are good?). This has been corrected.

• New callback method allowed for when you do a Networking.Instantiate
• New NetworkStart virtual function that can be overridden and used rather than doing networked based things in the Start function
• Fixed rare critical bug where 2 classes that derive from SimpleNetworkedMonoBehavior are sorting differently on different builds

Also, new video tutorials are up!

Cache System: http://developers.forgearcade.com/Tutorials/MasterClassIntermediate/Using-The-Cache-System
Authoritative Input & Client Side Prediction: http://developers.forgearcade.com/T...iate/Working-With-Authoritative-Server-Option
Packet Drop and Network Latency Simulations: http://developers.forgearcade.com/T...e/Packet-Drop-and-Network-Latency-Simulations
Network Instantiate: http://developers.forgearcade.com/Tutorials/MasterClassBeginner/Network-Instantiate

Why thank you I blame our software architecture.

This is a pretty good idea! I will see about setting up a mail bot to shoot off an email to anyone who has it set in their preferences to get updates when new versions are released. Thanks!

 

Downloading v7 now.
PS: Got my cloud instance running on Windows Azure, setting up policy group and firewall settings! The massive test will start soon!