[NO CCU LIMIT] Forge Networking now OPEN SOURCE

Hello @imgodot

So @jpthek9 is correct. Especially for projectiles you will want to do something along the lines of an RPC to let all the other clients know that there is a projectile being fired. In the case of an automatic weapon, you can get away with only sending 2 RPCs. One will be when the firing has began and the other would be when it stops, the other clients will simulate the timing and everything in-between. Having network traffic per projectile would be very expensive. If you think about it, many AAA games really only have around 16-32 (64 in BF4 case) actually synchronized objects in the scene. Simulations being slightly off for projectiles on other client's isn't such a bad thing (unless it is a "hero" object). In BF4 an algorithm that may be used to sync sniper bullets might be the following:

If you are looking at a sniper and they shoot while you are looking directly at them, then sync the bullet position and rotation across the network. Ever notice why you don't see sniper bullets flying around all the time but yet the sniper bullets when you look at a character that shoot at you look huge?

If you can simulate an action on another client without it directly affecting the gameplay or visual design, it is best to offload as much as possible to the clients simulating the action and you just telling it when to start/stop.

 

Okay, we will design some tests to get exactly this effect happening on our side. I do hope that we are able to replicate it quickly!

This must be a bug, I will make sure that it gets fixed. The initial start position should be 1 (since there is only a 1 byte header)

Thank you for the code block, I'll make sure to fix that index issue.

The bms.Size should be myObjectSize + 1. Not sure if this was a typeo because you have it as + 1 as well in your code?

Well, we definitely can design a second WriteRaw to have reliable headers. This will add our standard 15 byte reliable header overhead. So you will be looking at about 16 bytes extra on this new write raw. If this isn't a problem then we can prioritize this request as well

 

That would be fantasitc And the nicest gift I received this valentines weekend.... don't ask

 

Just wondering: what would be the difference between a reliable WriteRaw() and reliable WriteCustom()?

 

WriteCustom has some extra bytes associated with it as it goes through the normal flow of the header system; adding around 17 bytes on top of the 15 bytes for normal headers. When we develop the WriteRawReliable, it will be sending the minimum amount of headers needed for reliability. This will leave out any connections to networked objects and various sub-systems so you would save on that space.

 

D: I shall not ask, and no worries, my best gift today was that I finished the Beta for the Developer portal *gift to one-self ftw*. After I release the Developer Portal Beta email I will start work on our bug and feature request backlog, including this one.

 

Hello all, this is the official forum announcement of the Developer Portal! We have completed our Beta Phase 1 for our Arbiter API and it is ready to be given a spin and have bugs found for it. With this release we are officially (that we know of) the only Networking+BaaS system out there that is all first party. We still have HUGE plans in place for Forge and this is "only the tip of the iceberg".

I would like to take this moment to publicly thank you all for taking the time to test out our system and give us great feedback. It seems like only yesterday we were cooking up this plan to making a networking system that fit our needs when it came to games we dreamed of. We quickly went to action on developing this networking system that would not only empower our games but a system we could share with others as well. There are a few active posters here on the forums but I would like you all to know that we have reached our 40+ beta tester mark and we receive emails on features, bugs and general feedback quite often. We are really happy to be a part of a community that is like-minded and just as passionate as we are about developing games.

Enough of the mushy stuff! I am now going to send this email out Please keep on sending us your bugs and features. We are going to begin work on our bug/feature backlog that we have accumulated over this past week since we were greatly focused on the developer portal at the time.

Getting Started With Developer Portal YouTube Playlist
http://www.youtube.com/playlist?list=PLaMPnrbpanJ44chHm7mXfMuPciV8i7WCA​

 

jp, You seem well-versed in all of this, but I am relatively inexperienced in multiplayer programming and Forge especially. I am finding it difficult to understand what the code should look to work as you suggest. You don't happen to have a small demo project implementing your architecture, do you?

The Forge website has demo videos of numerous features but nothing in the way of examples showing how to actually implement any of them in a working project. I was working off of their networked instantiation videos.

How is that architected?
How does each player get notification to create a new object in the game? RPC?
How are you sending these information packets to each player?
Is the server keeping track of all this information and sending it to all the clients?
Are you using IsServer/IsClient to know who sends the packets and who receives? How does that change if the server is also a player?

What would the "or something" be?

Thanks for taking your time to respond to all my questions.
-- Paul

 

another things, is it possible to add the NetworkingPlayer argument to the rawDataRead event like you did for the dataRead event ?

Did you add time to add the NetworkingPlayer into the rawDataRead event ?
it seems i cannot see in the V12 version.

Code (CSharp):

1.  
2. private void Start()
3.     {
4.         Networking.PrimarySocket.rawDataRead += PrimarySocket_rawDataRead;
5.     }
6.  
7.     private void PrimarySocket_rawDataRead(BMSByte data)
8.     {
9.     }
10.  

 

Okay, I understand using an RPC to trigger the clients about an event.
However, in the case of an automatic weapon, if you are turning and moving while firing, the bullets will have an ever-changing starting position. If the client receives a shooting-started RPC, does the client sync the start-position and velocity vector of the bullets to the muzzle of the other player's weapon?

For my current project, the player avatars are all network instantiated locally on the owning client. I was trying to allow them to shoot a missile by network instantiating those locally as well. In this very specific case, there would not be very many synchronized objects.
However, I do want to change this project to make it an authoritative server (though, I have no example to follow; nudge, nudge, say no more), so I will probably implement it as you suggest, assuming I get the authoritative server actually working.

I do understand all of what you and jp are saying, conceptually, but my problem becomes one of having no samples of working code to look at and work off of. Without any samples, it feels like I am reinventing the wheel, as it were, for what may already be a well-established design pattern.

Thanks for your responses.
-- Paul

 

awesome,
so, i did not know the arbiter server we talked about was going to be a web based app backend as service like playfab?
am i reading correctly?

if that is the case then all i can say it is sweet music to my ears

but hold on , this arbitrer BaaS web app will be also self hosted aswell, as you mentioned before, meaning we wont feel our client base be highjacked like playfab makes you feel since you can not self host it.. So we will be able to host it anywhere we want meaning we will use it for our own game(s) only,? right? or wrong?

btw, found the first bug in the web app.
- when you click the red button "download latest beta" nothing gets downloaded (tested in firefox latest 35.0.1), no biggie since you can always click download previous version link and download the latest manually.


cheers

 

It open a new Pop-up window, check your adblock module

 

you right,

i had my pop up blocker enabled. no wonder.

sorry , my bad.

 

AN RPC QUESTION:
If client X sends an RPC to the server telling it that client X wants to launch a missile, the server then sends an RPC to all connected clients that client X launched a missile with vector Y, etc.
When the clients receive the RPC from the server, what will tell the clients that it was their missile to launch?
Do I send some network ID (unique to that client) in the original RPC to the server who then echoes it back to the clients?
If so, what Forge-specific value would I send?

Thanks.
-- Paul

 

Hey there! Sorry for the miss communication, you will see in this post that we hijacked the Arbiter name. So the Arbiter's name was re-used for the backend service as it is acting as a master server. Once we provide load balancing and a couple other features, then the original Arbiter design will be built into the whole system

We actually will be providing a database for each developer that we host ourselves so that we can keep the connection with the master database extremely fast and keep the players happy. That being said, you will have full control over this database and all of it's tables. What we will be doing is:

1. Providing an out of the box Web Application to manage database design (for those new to relational database systems)
2. An API to access your database and cross link it with the accounts in the main database
3. Full database login and control over the database

With these features I do hope that you will not feel "hijacked" as you will have power over everything, even the ability to create your own accounts table if you do not want all of the features, tracking and balancing that we have built into ours (though that is not recommended).

Glad this was just a pop-up blocker issue

 

Hmmmmmmmmmmmmmm... I sware I added it in the code. It should have went with this build. I did it when I was away from home so let me make sure that the fix actually got pushed to the repository, if not I'll push it to the repo and make a build for 12.1.

Thanks for pointing this out!

 

The bullets will fly based on the player's position. I'm not sure how the authors feel about this, but I think this is very general and not directly related to Forge. If you don't mind, could you create another thread to ask about your general design questions?

 

Hey Paul!

So there are a couple of things you can do. You can do the method you suggested where you send the player ID across the network via: NetworkedId which is found in anything that derives from SimpleNetworkedMonoBehavior/NetworkedMonoBehavior. Then on the clients you can check if (NetworkedId == passedId), you then can pass that id to your missile class and the missile can track the id of who owns it. Then when the missile hits, the sender can call an RPC for damage and such OR you can make it so that your server is the one that checks this as it has the owners ID as well and can do the RPC itself.

You can also use the (IsOwner) check inside the body of the RPC when you create the missile to set the logic for the owner of the missile.

 

ok, there is the catch, just as suspected.

so, in short, you will not allow us to self host the arbiter web server app any where we want, right? :-(

so that makes the same deal as playfab, where we have to use their cloud,
the only difference is we get to download our users database or even add tables to it, but it still feels the server is being hostage like any other existing cloud service like photon or playfab.
well playfab also lets you save your db too.

sad, at least will you even consider offering a self hosted license. of the arbiter?
last week you said the opposite that we will be able to host it anywhere we want and you mention the clod was just for beta testing , and once finished you will release it so we could host it anywhere,

you changed your mind now?
:-(

excuse my insistance, by now you know i really hate depending on third party service to be able to launch or maintain my game,
i want to host it anywhere i want and not depend on anything or anyone.
that was the reason i have left heroengine since they get your server as a hostage in their cloud.

cheers.

 

Ouch :'(

D: Catch is not a word I would like to be associated with. I was just giving our current design, haha. Okay so yes, you will be able to host everything yourself, basically we will open up the API to the main server. If you choose to go the route of self hosting then you will find your latency to be higher when using our proprietary accounts system coupled with your system. Originally I felt that having it on our server was a win/win as you would not have to worry about hosting, you get the fastest response time with the master server, imbedded security, and full access to every part of the database as if you were hosting it yourself without the self hosted cost.

Since you hate depending on third party, we can open up the Arbiter to be licensed. We will need to re-think allowing the connection to our main server though for security purposes. We want to work with you as much as possible. If needing it to be isolated from the master environment is a need then we would like to help accommodate that.

Thank you for your honest feedback. We want to make sure that we don't turn into "the other guys". SO Yes, you will be able to host yourself.

 

Also, please note that last week we were referring to the Arbiter we talked about before (which is now being packaged into Bare Metal).

 

thanks for the clarification.

but here is the part i dont completely understand, sounds like a contradiction.
"yes you can self host all but you still need to go thru our propietary account system hence the latency increase issue.

so that means we still depending on a third party app which is hosted somewhere else.


unless i am very confused about your arbiter server dependencies?

can you please elaborate?

 

Yes, I am sorry for not being clear. I should have used the word "if". We still want to be able to allow you to access the accounts and any other services. If you choose to do this then there will be latency. If you choose to host absolutely everything yourself then there is 0 dependencies as you are not accessing anything from the master server.

We do plan on cloning our master server with slaves in different regions so that we can have the fastest connection possible in many countries. This is probably the only thing you will lose out on if you were to self host it completely.

So in summary. You will be able to host with absolutely no dependencies. We will most likely create a repository for you to get all of the latest Arbiter updates. For self hosted, of course, there will be a separate license and agreement since it will be providing our source code.

 

got it,

thanks for clarifying.

 

No problem! Thank you very much for the feedback, I am sure there are others who were wondering the same thing and I wasn't very clear. Please feel free to give us critiques at any time! We want to make this system as easy to use and powerful as possible for everyone. Your honest feedback is critical to the success of that design

 

Is there any info on how Forge compares to Photon and Bolt, I am just starting to research the options for our racing game and I am just wondering what advantage Forge has over other more established systems? And any idea when you will be making the pricing public as that will also be a factor in our plans.

 

Hi there! Being the creator of the system it is not fair for me to relate Forge to other networking systems. Others may be able to put in their opinions on that That being said, here is a review link: http://forum.unity3d.com/threads/mu...oton-ulink-darkrift-forge-and-playfab.294852/

Here is my quote on pricing for the system:
http://forum.unity3d.com/threads/su...ows-universal-apps.286900/page-7#post-1947697
Note that we are providing a backend as a service (BaaS). When we integrate with your data it will be cost by bandwidth not by evil CCU or DAU. Here is the link for that one: http://forum.unity3d.com/threads/su...ows-universal-apps.286900/page-8#post-1952635

Things that are unique key features of our system:

• TCP support for webplayer (UDP works on webplayer but it is not a good decision as noted in Unity docs: http://docs.unity3d.com/Manual/SecuritySandbox.html)
• iOS, Android, PC, Mac, Linux, Webplayer, Windows 8.1 Store application, Windows Phone 8.1, and any other platforms that work with normal Sockets in Unity
• UDP
• Reliable UDP
• Raw data writing (1 byte overhead)
• Event driven
• Lan discovery
• Fully authoritative server design
  
• Fully functional RPC stack
• Threaded workflow (call functions on main thread from separate thread)
  
• Run multiple instances locally for testing
  
• Runs in Unity instance so you get Physics out of the box
• Runs in Unity independent mode (Bare Metal) for no engine overhead
• Backend as a Service (BaaS)
  
• Player accounts
• Player currency (free and premium separated)
  
• Player items (coming soon)
• Player achievements (coming soon)
• Server registration
• Server Browsing
• Fully Multi-threaded
• Fully Multi-threaded HTTP
• Custom class serialization
• We like to think of ourselves as very fast on support
• Developer portal
• Server statistics via developer portal
• Interact bug and feature requesting on developer portal
• Very, very fast feature development and very flexible with developers

 

+1 for self hosting

One of the big draws for me was the ability to self host.

As I mentioned previously, I was using Smartfox, which is essentially free for a small indie developer. The only downside of smartfox is it needs a dedicated host. i.e. you can't start hosting a game from within Unity. Forge allows hosting within Unity, as well as server side hosting, Forge Wins!!!

Cost is going to be a key factor. I just hope that pricing of Forge allows small indie developers to get started at a small entry cost. Some sort of tiered pricing based on number of concurrent connections to Server?

Edit:
I read your subsequent posts and I am a little confused.
- Bare metal server is not Arbiter server?
- Will bare metal server have functionality for Foyer, listing hosted games, user registration, etc?

 

Thanks for the reply, what is the process for joining the beta assuming there are places left

 

We are still accepting Beta users All we would need is for you to send us an email at support@beardedmangames.com with the subject "Forge Networking Beta" and then we can get you setup in our system. Otherwise you can send me a PM here with your email and we can get you setup from there

 

Yes, this has become quite confusing so I'll just attempt to wrap it all up into one explanation.

What is the Arbiter:
The Arbiter in the beginning was a very vague idea of hosting servers and such. This idea was mostly realized upon further development and the invention of Bare Metal.

What is the Arbiter now?
The Arbiter is now a BaaS (Backend as a Service). The Arbiter is responsible for Player accounts, login, coins, exp, levels, items, and server listings.

Do I need to have the Arbiter to use Forge?
No

Can I host a server without the Arbiter?
Yes

What is Forge, what is Bare Metal and what is the Arbiter?
Lets begin with the bread and butter, Forge Networking:
Forge Networking is a set of core networking libraries developed as a plugin for Unity for communication between multiple devices over a network or the internet. Forge Networking is stand alone, you can develop networked games with this one time purchase plugin. This will allow you to create all of the network communications you have enjoyed (and bug found) since day one of the beta. You can host servers at no cost with this system. The catch is that you host them all yourself, manage them yourself and so forth. This plugin runs in a Unity instance . The price for this stand alone plugin (Forge Networking) will be below $100 as stated before.

Later on came Bare Metal:
Bare Metal is an extension to Forge Networking. It is an application that you can run as a stand alone server without the need of running anything through Unity. This extended server can be self hosted and is an add-on feature that will also be a one time purchase. The cost for this system will be very low (ranging between $10-$25), the cost for this is because it is a separate development cost for us as it has a lot of stand alone features from the networking system. Also not everyone needs this system and the main networking package will work just fine for them since they can run it headless with the Unity Instance.

Now came in the newly renamed Arbiter.
Arbiter is a Backend as a Service (BaaS). This service is to enable developers to have user accounts, login, currencies, leaderboards, achievements, items, trading, and more built into their game without the need to worry about all the backend development. This service is a pay by bandwidth or better known as "Pay for what you use" service which pulls away from the evil CCU and DAU pricing. This service will be extended to allow developers to have FULL control over a relational database that is hosted, backed up, and regionalized with our servers. That means you can design your own table structures, queries and more.

Will forge have cloud hosting?
Yes, in the future we plan on offering another service that is pay for what you use with us hosting your servers. Since you can host your own servers at no cost, this is an optional service that will be available for those who do not want to manage and pay for their own dedicated servers.

 

In Forge, how do I differentiate between:
A) A server that is not hosting a player?
B) A server that is also hosting a player (acting as a client and a server)?
C) A remote client hosting a player?

The reason I'm asking, is that I want to log debug info to disk files for each client and the server, therefore, I need to know where the debug info is being generated.

Also, If I send an RPC to the server, and the server is also hosting a player, does the player also get the RPC?
I guess I'm really asking if RPCs on Forge work any differently than is std. Unity.
I know there's no NetworkMessageInfo structure passed automatically into a Forge RPC.

Thanks.
-- Paul

 

is it possible to have an estimation of 1000 DAU pricing if I use forge networking+bare metal+ arbiter?

it was interesting to me as it was a "paid once solution" but if some features will be paid every month it important to know as soon as possible if i should stick to my Bolt+playful solution because it has no additional fee in my case or very cheap over 1k DAU

 

Forge Networking = 1 time price as mentioned
Bare Metal = 1 time price as mentioned (ranging between $10-$25)

The only feature that is a monthly payment is the Arbiter BaaS. This is pay by bandwidth which will always be lower than paying by DAU.

If you are having a very low payment on PlayFab with your current solution we will either match or be even lower because you are paying for the cost of bandwidth and not DAU.

 

A) A server that doesn't host a player is just a server receiving input of data being sent to it (i.e. does all dedicated logic and evaluates it for the other players and sends it back) and sends out the data back to other players. So if you don't spawn a player on a server, you can determine that it is hosting.
B) A server that is hosting a player lets the server interact with the game in a way. (i.e. Say you host a game that is the server and are acting as the primary host for the other users that connect. Lets say that after 15 minutes of playing you decide it is time for you to quit the match and the other players are still connected. When you disconnect, the other players will disconnect as well).
C) A client player is a person who has connected to the game but is sending and receiving input from the server. If the player leaves the server that is running, the player will not affect the other people still on the server after leaving as the server is still hosting. The server in this case would still be running and hosting the other players, while the client is free to join a different type of server or re-join the same one.

The RPCs can be sent in many different forms, you can chose to send it to the server only, others, all, others buffered (which is others who join after the game that is started), all buffered (for all players who join the game that is started). You can define how you would like to send your RPCs to be used and we have a few examples of them being used in the example scenes provided in the beta. If you would like a particular example I am sure we can make one for you that would help others understand it as well.

The process of the RPCs are the same as Unity's Standard RPCs. There is no NetworkMessageInfo that is passed as part of the RPCs currently, if it is something that you would want, then it can be updated in our feature requests to be a higher priority.

 

Cranick, You gave me very clear definitions. Thank you.
But how do I differentiate between the types.
Regular Unity networking has Network.IsServer and Network.IsClient, which seem to always return false in Forge.
How is this done in Forge?

Thanks.
-- Paul

 

Sorry about that, there are few ways you can use to determine which type is being used.

On any NetworkedMonoBehavior derived class will have a "OwningNetWorker". This NetWorker will have a "IsServer" which will determine if it is a Server Object. This also can be checked if it is the client by simply doing a check like below.

Code (CSharp):

1. if (!OwningNetWorker.IsServer)
2. {
3.    Debug.Log("I'm the client!");
4. }

Also there is "IsOwner" property to determine if that object belongs to the player or not, so you are only controlling one object at a time. In our ForgeHelloCube scene we use this for updating the position of a particular cube while not affecting any other clients that join the server. In the script "ForgeExample_Move", you will see that we use the method like so.

Code (CSharp):

1. protected override void Update()
2. {
3.     base.Update();
4.     if (!IsOwner)
5.         return;
6. }

That way only the owner of the object will be allowed to make any further updates past that point.

Here is our tutorial video of this on our website on how to use this information.

I hope that answered your question and if not please let me know.

 

Cranick, You answered beautifully!
Now, I seem to have an RPC issue. Note: This is all running on one PC.
I set up a simple project with two players both created by Networking.Instantate() one from the server and one from a second client window. When a key is pressed whether on the client or the server an RPC is sent to the server ONLY.
The only RPC parameter is the NetworkedID.
When I examine my logged results, it looks wrong:
*************** START OF LOG SNIPPET ***************
11:12:40.876 Client: SENDING RPC from player-owner net ID 3
11:12:40.885 Server: TESTRPC received: Net ID = 3
11:12:40.892 Client: TESTRPC received: Net ID = 3

11:13:04.496 Server: SENDING RPC from player-owner net ID 2
11:13:04.502 Server: TESTRPC received: ID = 2
*************** END OF LOG SNIPPET***************
First, I triggered an RPC from the client, but it is received by the client AND the server.
It should have been sent to, and received by, ONLY the server.
Second, I triggered an RPC from the server and it was received only on the server, which looks correct.

Any idea what I'm doing wrong or what to look for?
Thanks.
-- Paul

Here's the relevant code from my script on the player object:

Code (CSharp):

1.    
2.     [BRPC]
3.     private void TestRPC(ulong argNetworkID) {
4.         pgm.Log("TESTRPC received: ID = " + argNetworkID);
5.     }
6.  
7.     protected override void Update() {
8.         base.Update();
9.  
10.         if (!IsOwner)  return;
11.  
12.         if (Input.GetKeyDown(KeyCode.R)) {
13.             pgm.Log ("SENDING RPC from player-owner net ID " +this.NetworkedId);
14.             RPC("TestRPC", NetworkReceivers.Server, this.NetworkedId);
15.         }
16.  
17.      ... more code here ....
18.  

 

Hi guys,

is it possible to overload the ObjectMapper.Map<T>(...) method to take a BMSByte as argument ?

For my side it should be logical, because the ObjectMapper.MapBytes(...) return a BMSByte

Regards,

 

That looks correct, taking a look at it now to see the issue and I too am noticing it. It seems like a bug, this will be resolved in a hotfix. Thank you for pointing this out.

 

Thank you for the bug report, we have fixed this issue and will be uploading version 12.2 along with a couple other bug fixes to the developer portal within the hour

 

The ObjectMapper just breaks down objects into their bytes. Rather than adding BMSByte as an option to this you can just append the BMSBytes to the end of the list:

Code (CSharp):

1. BMSByte tmp = new BMSByte();
2. BMSByte other = new BMSByte();
3. other.BlockCopy(tmp.byteArr, tmp.StartIndex(), tmp.Size);

Please let me know if you have any questions.

 

Version 12.2 hotfix with a few new bug fixes (listed in the email and on the site) has been released. Please let us know if you have any issues with the download or any other questions Thank you!

 

Guys, Thanks for the amazingly quick fix.
I'm just really glad it wasn't something obviously stupid that I was doing.
-- Paul

 

I can't remember if this is a regular Unity restriction or not, but I would like to be able to call RPCs that are defined in a NetworkedMonoBehavior attached to an empty game object sitting in the scene.
The empty gameobject + script would be there for server-only processing that doesn't need to be part of a specific player-object.
Is this possible to do?

-- Paul

 

Hi guys,
My code is working on beta V12.2 finally but not on V12.1 ,

You fixed something on WriteCustom ?

Regards,
Mathieu

 

No problem . It looks like we introduced this bug a couple of updates ago when we were updating the transport layer to support some new write methods.

 

Yes sir All you would need is a reference to the object. Once you have a reference to that object you can call any RPC method on it with (psudo-code) myObject.RPC("MyMethod"...

Please let me know if this makes sense or not. We can also make some sample code to show if needed.

 

Hey that is great news. I thought we made the V12.1 mainly to fix your bug... :/ It worked in my test, maybe I messed up something in the build process. Good to know that it is fixed in V12.2

 

Maybe it was already working in V12.1, versions are release so fast