[NO CCU LIMIT] Forge Networking now OPEN SOURCE

Welcome to Forge Networking!

​

01/08/2019
There have been very many updates from both myself and the community on the GitHub repository, please make sure you jump over to the github page and get the latest stuff. The build pipeline to the asset store is a bit slow so all the best stuff usually is on Git for a bit before it makes it to the asset store.

Also make sure to join the discord, there a lot of awesome helpful community members there!

06/23/2017
Forge Networking Remastered is now open source! Let me quickly address common questions:
- This project is not abandoned, just embracing open source like Box2D or Linux
- We (the developers) will continue to work on the project just with the community included now
- We are looking for contributors, we are not closed off to mods/contributors
- The community is open and all about network games/apps, so you can join even if you are not using Forge Networking

10/29/2016
Forge Networking Remastered Release Candidate 1 (RC1) will be released in our private channels (Slack) to those who own Forge Networking tomorrow. If you purchase Forge Networking now, you will receive Forge Networking Remastered for free . Come on over and join our global community of developers!

05/28/2016
We have uploaded 2 videos today about progress on Forge Networking Remastered (free to everyone who owns and purchases Forge Networking). Our hope is to move into an Alpha build next week to get early adopters testing out the system . Please provide us with any feedback, and we are NOW taking requests to join the closed alpha just testing mentioned. Please us a message on Slack with the request as we have a private channel there for the group!

05/16/2016
Websockets Alpha released!

04/12/2016
Subreddit is back up - https://www.reddit.com/r/ForgeNetworking/

02/22/2016
Moar development! We have had many things come up since Christmas and they are amazing and will push our efforts as a business far beyond what we would have hoped! What does this mean? You get @Cranick as the new full time developer of Forge Networking as well as the knowledge that our studio is funded (albeit from Forge and other things). This frees me up to do more video tutorials - as seen here and other sorts of documentation.

GitHub access for all registered developers! Are you using Forge Networking? Did you register on the developer site? You are eligible to get GitHub access! As we develop on GitHub you will get the latest commits and can test out things before they go out. Check out bug fixes, check out others pull requests, collaborate with other developers, report issues and use the wiki there. GitHub has tons of tools that help everyone out and we have decided that this will be our public issue tracking instead of EpicJoin. We just enabled all of that on our repo! We currently have about 41 developers who are a part of our GitHub so lets push that number to the hundreds! *Can you say mega-feature sets and pull-request fixes? Of all of the networking systems we are the only from scratch one with the developer network and willingness to give full source code and GitHub repository access, you just won't find that from a third party anywhere else! Come join the party!

New twist on old angle! For us it has always been about building a community, and with hundreds of people registered on our Slack that has been a great feat for any system. Seeing everyone collaborating and communicating with each other has been such an awesome experience for the team here. We wish nothing more than to build the community further, we will be less controlling with our GitHub Access (outside of requiring to be registered with Forge), we will use more open communication tools like MediaWiki and GitHub issues/wiki rather than pushing our own "EpicJoin" agenda. We will also encourage everyone to contribute to the wiki, to GitHub issues, via code pull requests, and more! After all, thousands of brains are better than 2 no - at least in most cases (hiveMind--) XD?

Note: Our support email is severely backed up and we may move to only go through critical emails or request those still interested or still having problems to re-iterate. This way our email doesn't become an infinitely growing old response system.

Thank you so much to the huge amount of you who stuck through the silence and continued to make great things!

07/29/2015
Happy Windows 10 everybody! We now have a private chat room for our Forge Networking Owners BUT if you are not an owner you can get access to chat with the developers to learn more about the system! If you would like access to the chat to ask the community questions please send an email to support@beardedmangames.com with the subject "Forge Networking Chat Request". We have a very strong and helpful community. Hope to see you all there soon!

07/8/2015
We have just released version 10.6 and have been working on finishing NAT Hole punching and the Load Balancer

06/23/2015
Announcement: Asset Store Version Released!

06/12/2015
We have released Forge Networking on our website!
This is a price per developer, not per project! Use it on as many projects as you wish!
Announcement: Website Release!

Reasons to use Forge over UNET or other solutions:

• We provide full source code for every platform
• No plugins needed, all source in native Unity C# code
• Fast support. We focus on our system and can get bugs fixed in days, not months. Also since full source is provided, the community can submit bug fixes or features
• No CCU or DAU limitation
• Support for Unity 4.6+ as well as Unity 5+
• Built in server browser
• Built in local area network server finding
• Support for TCP communication
• Read why we love this project
  
• Others thoughts

Come join our Global User base!
​

-------------------- BEGIN ORIGINAL POST --------------------

HOW EASY IT IS TO GET STARTED

I have been able to get my Networking library working for all supported platforms of Unity. This includes the following:

TCP (required for any reasonable playability in the Web Player)
UDP/R-UDP (unreliable and reliable)
HTTP/HTTPS (includes GET, POST, PUT, and DELETE)
Multi-Threaded structure (while still holding main thread variable integrity)
Event driven (register events for almost anything, including: player disconnection, message sent, errors, etc.)
RPC (remote procedure calls) even including private methods (must be called from the specified type).

Automatic serialization of common types
Allows for custom type serialization (expansion)
A serialization class that has any property marked with the [NetworkSerialized] flag sent across the network (must be networking serialized type)
A base networking serialized class to extend from in order to serialize any data type

This package will also include the Master Server for host listings. The Arbiter Server keeps track of open hosts running your specified game (separated by key) for super easy match making host lookup. Includes player counts, ip/port, password (via comment), and auto dropping of cached hosts that don't UDP ping within a specified TTL (time to live *in seconds*).

I am posting here to get feedback on what people would like to see as well as what people expect to see in a networking library. I will be uploading some videos soon to show the basic workflow as it currently stands.

------------------
NOTICE: We have heard that some people using other networking systems are spreading some rumors. We have been asked about this enough times to post here. Lets iron out the facts!

Q: Do you use ASCII to send data over the network?
A: NO We have not ever nor ever wills send data as ASCII this is a complete fabrication. We did send a couple of RPC calls as a string very, very early in development which no longer happened after we implemented our mapping layer. This is probably where the rumor started.

Q: So and so "ripped them a new one"
A: NO In fact, if you continue reading, we actually corrected Mr. So and so as he said things that were just not true and any faults we had in our first 3 weeks of development were ironed out. Please look at our update changelogs and velocity.

Please ask us if you have any questions and thank you to everyone who corrected these misconceptions on our behalf.
------------------

To access the developer portal, please got to: http://developers.forgepowered.com

 

sounds good. What is the server running on?

 

The server is running in Unity so you can run the server from any platform, Linux (including headless), PC, Mac, windows phone 8, iPhone, Android -- basically you can have the server hosted on any of the Unity platforms that support sockets

 

Hi farrisarts,

I am interested on your library especially the WP8 support.
Do you know when will you release your library.
Can i get it now ?

regards,
Mathieu

 

Hello @zapoutix,

I have been working really hard to get this networking system out as soon as possible. The package has been stable so far through my various testing, however there are more features that I am adding to the system. I could probably start kicking off the developer registrations for a beta of the system though. Would you be interested in testing out the system in Beta or would you rather wait until the system has the rest of the features finished up?

 

Does the server run in a Unity instance?

So I could run the server in the editor, and connect another editor as a client for debugging?

 

Yes, in fact that is how I have been testing a lot of the work. The way that the system works is that it allows you to let your players host the games (just like built in Unity) however, you can also host room instances yourself for MMO or any other style games (ie: SmartFox or Photon). So the flexibility of this system is much more grand than just having one or the other. I will make some videos demonstrating how the system works on both local and via "cloud"

 

Sounds good!

If you could also put together a little demo of your system using authoritative physics that would be great.
So Physics are calculated on the server and the resulting transforms are synced to the clients.

If your system could support this I'd be interested in helping out with the beta.

 

Sounds good, I actually have started working on a part of the system that will deal with making the server calculate all of the physics and just sending the positions and rotations to the clients! I'll see about getting a demo of it up and going asap

Also, I have recorded a very rough and quick video showing an example of it running in the editor and on a build client.

 

Looks really good and easy to setup, good job!

I noticed a Plugins folder was created when you imported the package, was the DLL in the Plugins folder just a stub for Windows Store Apps?

So it will work fine with Web Player and Web GL?

I'm keen to get my hands on the beta, I want to implement it in my racing game, I've sort of implemented uLink already but my main concern is its lack of Windows Store and WP8 support.

Any ETA when a beta will be available for testing?

 

Thanks!

Yes, the plugins folder is just for the support of WP and Windows Store. The other DLL in there is just a completely managed DLL that is the code for all of the other platforms. I have tested this a lot with the Webplayer as it is yet another unique platform to Unity (like WP and Win Store). I have taken a lot of the heavy lifting away from how networking is normally handled in the Webplayer and there actually is no extra code or work you need to do to get it working on the Webplayer (however there are some things you can do to customize how it works in the Webplayer).

I will make another video to talk about (show) the Webplayer implementation. It is a bit of a unique platform and so there are some things to note about how web browsers like Firefox, Chrome, etc deal with plugins (like Unity Webplayer and Flash) in what they are allowed to do with Sockets and what they are not allowed to do.

As for Web GL, it currently is in an experimental stage as that is yet another beast, it is requiring us to write yet another extension to the library for "WebSockets" since the default networking will not work with it. So that one is in the development stages, however it probably will be our goal after the initial release.

Lastly, we are wanting to get the beta out asap so we can get new feature requests, bug reports and so forth. We have a couple more technical features to throw into the system and we want to stress test a few things on heavy usage such as the instantiation of objects on the Network in volume, high volume connect and disconnects, etc. So hopefully we can get a beta out within a week!

 

Hi farrisarts,

i just watched your video, your plugin look great.
I am interested to try the beta version, but actually i am not sending position, rotation or scale on my project, i am more interested on the RPC functionality

Regards,
Mathieu

 

Awesome! I actually have a full demo of a game (Tic-Tac-Toe), as well as a Chat demo, that does nothing but use our RPC functionality. I can make a video demoing this as well as it is another powerful feature in the system. You can even use the RPC functionality on private functions, that way you can keep your code as clean as you wish it to be.

 

Ok great, let us know when the beta is available.

 

@zapoutix,

I have created a video to show the TicTacToe (Pure RPC) game. It uses the "SimpleNetworkedMonoBehavior" class that is a part of the system to do this. Also notice that by using the "SimpleNetworkedMonoBehavior" it cuts out all of the fat of the other script that was shown with interpolation and variable serialization.

 

@Meltdown I have created that video to show it working in the Webplayer and to talk a little bit about what internet browsers do with plugins.

 

I notice in the server start method you specify a networking mode, i.e TCP.
What happens if you need unreliable UDP for object synch, and TCP for RPCs?

 

The system at it's current state allows multiple connections and connection types. Basically there is a global "Networking" static class that is used to manage only 1 connection (which you would use for your primary connection). This particular static class was created only to make the system very easy to use for those who don't want to get too technical. However if you need to use multiple connections for things like VoIP, Chat, RPC only channel, HTTP request, and so forth you can actually create a new connection by making a new instance of one of the connection classes. (Note: HTTP has its own class that fires off a separate threaded connection when doing a HTTP request, so there isn't really a need to make an instance of this particular class).

I haven't tested how many connections you can be running at a time, but I have had somewhere around 3-5 running at a single time thus far without any issues. In fact, the system actually uses these classes itself for the helper classes that are built in to communicate with the Arbiter server (master server/server (room) starter delegater).

I would also like to note that you can actually write your own byte serialization of any content type so that you can easily extend it to do things like VoIP, which this also comes with events that you can register to listen for this data.

 

I should probably say that you can do RPC calls over UDP as well. However, in the backend of the system, it automatically makes it a R-UDP (Reliable UDP) since I figure that RPC calls are high priority and are required to get to the other end. I chose to use TCP in that video just because I wanted to give good ol' TCP some love after testing in UDP all day. ;D

 

Yes, RPC's definately need to be reliable

 

Thought I would post a video of it working on Windows Phone and Windows Store

 

Hi guys,

RPC over UDP should be added i think,

In the "standard" Network classes , it allows to send an RPC message to a specific connection ("NetworkPlayer")
Is there a possibility to same with your library ?

I have another question, will it be possible to use "Good ol' Sockets" plugin ( https://www.assetstore.unity3d.com/en/#!/content/13166 ), to use your library with a FREE version of Unity3D for IOS and android ?

 

RPC over UDP is a part of the system (it uses R-UDP to do so). Yes, I have an overloaded function for the RPC that allows you to send a message to a given player (either with a reference to the NetworkingPlayer or via the ulong player id).

As for using our plugin with Unity Basic (the Free version of Unity), we are working on our own version of sockets for Mono which will work on Unity Basic. Then there will be no need for "Good ol' Sockets".

 

Ok perfect

don't hesitate to contact me if you need beta testers.
Did you think about price already ?
Will you do 2 versions :
- One with binaries only
- One more expensive will full source code ?

Regards,

 

I am trying to compose a list of beta testers and you are on the list!

We will be releasing the binaries to start. The source code we may consider licensing out. As pricing model we are thinking of is the following:

• Binaries (default networking I have been showing off) will be a one time purchase (per major version if multiple)
• "Arbiter"[1] will have a standard licensing applied to it divided up between indie and large business (based on yearly income).

I do not have the exact number in mind yet, however I will note that we will have a special release price for the people who beta test though as a special thanks

[1] The "Arbiter" is the master server with room instancing + tons of new features, we can't discuss at this moment. The Arbiter is designed to change the way we all do large scale multiplayer and room instancing (master server/mmo). We will have more on this new tech soon enough.
Note: The Arbiter is NOT required to do standard peer-peer or custom hosted server networking (the binaries). It is meant for large scale networking at an industry served standard level (like the other guys)

 

Any update on the beta??

I'm coming to a cross-roads where I need to commit to a specific multiplayer library pretty soon

 

Bookmarked.

Ready to purchase when this hits the asset store. (Unity Basic version, but happy to use Good ol Sockets)

If you are still looking for Beta Testers. I would be happy to help out

 

We actually will be doing one big pass tonight to check out the core part of the networking system and the network traffic. I think we are at a stage where we can release a beta this weekend! What are the core parts of your game so that we can make sure to make some documentation for the system around your needs (I know you are doing a racing game)? Are you looking for RPC calls over UDP/TCP, are you looking to have TCP and UDP running in parallel or just UDP, etc.

Awesome!

For the beta you may have to use Good ol' Sockets to get everything going; however we are developing our own networking layer so that you can actually use it on Unity Basic without Good ol' Sockets, as it will use our own proprietary setup. I suppose there is the same question for you as well. Are there any areas of networking you wish to see in this system (even ones not found in other systems)?

 

HI Farrisarts,

That is great

My project has been moth balled for a while, but I am now ready to start on it again. It is a FPS, written using Smartfox.

I want to modify my game using your asset so that game is peer to peer with the person who starts the game being authoritive server. This will avoid the issue of requiring a large enough centralised server.

I will still need a server sitting out on the web for a match making foyer, I would like to get more details on your Arbiter server:
- Above you say the server runs in Unity. Does that mean it sits on the desktop of the web server? i.e. it is not a service or runs in IIS/Apache?
- Can it handle foyer messages?
- Support Friend Only Servers? (System would need to track registered users and their friend groups)
- Does it keep details about game servers, e.g. number of players in game, game mode, "Your" ping response time to server.
Edit: I won't need Arbiter server for Beta testing.

The in-game features I will use are: (Note, if not available, I can write most from scratch)
- In game messages (Team or Game)
- Room/User variables
- Passing Serialized classes around for player and world updates
- Send updates via TCP or UDP
- Spawning/Destroying world objects
- Animations
- I am particularly interested in the "Network Mono Behaviour" and interpolation. I have struggled with this aspect of multiplayer, eg: When player falls and appears to partially go through floor when predicting position. I also have a car racing game I have been kicking along in my spare time. This is particularly difficult to make car collisions appear similiar for both players due to the speed of the cars.

Thx.

 

Right now the most important would be unreliable UDP for synch and of course reliable RPC.
And yes, it will be used for the racing game I'm working on.

 

Just made a video for how to set it up with Unity Basic for those that do not have Unity Pro.

 

We have UDP working with reliable RPC and I tested with Brent the reliable buffered RPC. The reliabled buffered RPC is the latest addition to the reliable UDP framework. We will be release the beta hopefully tomorrow, we would like to keep in constant contact with you to make sure that everything is running smoothly. If there is any bugs we would like to fix them quickly, so that they will not be in the initial release.

Feel free to message me or Brent on the forums any issues you may have.

 

@Zaddo67 thanks for the awesome in-depth response.

The server is fully authorative to prevent any form of cheating between the clients (which is the industry standard), so you shouldn't have many worries there.

This is one of the jobs of the Arbiter once it is complete by the way, that way we support both models .

I am sorry for the miss-communication. The individual servers do run instances of Unity so that they are 100% compatible with unity in every way shape and form. As for the Arbiter server it is what controls the instancing of Unity as "rooms". The Arbiter server itself is completely independent of Unity and has been (and is being) tested on Windows, Linux and Mac. Also on those platforms it has successfully constructed and destructed rooms (unity server instances) at runtime. The current state of the Arbiter is not a service, however it is planned to be ran as a service.

The Arbiter currently does support password protected servers via the comment line of the registration of the server. At it's current state, it does not support individual tracking of users through a login. That is one of our primary goals though so that we can extend the system to be much smarter when doing match making and persisting data across different games. We most likely will communicate with a MySQL server for this. We actually have some big plans for user login, user data, and analytics (and possibly bigdata) . The arbiter has a working plugin interface so that you are able to alter its behavior as well!

Yes. It also uses this player cap not only to send down for the server lookup, but also for the centralized server to create new instances of rooms when needed.

Awesome, I wouldn't feel right giving you it at its current mangled state. It is our top priority with flushing out the network bugs though!

You are good on these, and we have some samples/tutorials we will be doing to show how to use them.

We have the structure in place to create your own serialized classes (will serialize entire classes across the network) however we will not have it in the initial beta as we need to completely check that this works well with child classes and do correct checks against reference objects that are not built for serialization (i.e: GameObject).

Yes

To save on network traffic, by binding the animation calls and actions to variables, you can easily get animations working across the network. We have a demo and video tutorial of how to convert the new Beta Unity 4.6 animated character with mechanim across the network with all the animations in less than 5 minutes.

If we could work closely with you on making sure that we have all of these cases flushed out, that would make us very happy. As of right now we haven't had any issues with objects getting stuck in other objects and the physics simulations thus far have been ... stimulating

 

Wow, great response. I was just expecting a couple yes or no's

Can't wait to start using your library. It sounds great.

 

Awesome, can't wait to get my hands dirty with the beta

 

I am windows phone developer, hope to see that! <3

 

Ah! Welcome brethren! We love every platform in Unity and I have been a Windows Phone developer for quite some time myself . I've even given a couple of talks and porting labs with Microsoft on getting started with Unity on Windows Phone 8 and Windows 8. Feel free to ask anything that comes to mind about our system!

 

Update: We have done huge work on fixing out major bugs that we have discovered in its use and are doing our testing trials tonight. If things go smoothly everyone will have this Beta slip like butter in their email with all the bells and whistles along with it.

For those that have not asked already who want to be part of it, please message me or @farrisarts (Brent) your email address so that when the beta is available we can send it to you as well. We need your feedback and testing to make this the best networking solution for those that are wanting true cross platform dependencies.

Thanks!

 

The beta is officially out! Those that want to participate please contact us.

This is one of the most advanced networking systems out there, so don't be shy and participate to get to know one of the next best networking solution to ever touch Unity!

We have documentation in the works on our website www.beardedmanstudios.com for those that are already in the beta. Please take a look at the sample code and videos to help get you started. Any bugs please report them to me or @farrisarts (Brent).

 

OK this got my attention. Seems really cool!

 

We have new tutorials up on the site, feel free to check em' out!
http://beardedmanstudios.com/

 

PM'ed
sign me up for beta testing please.


Quick questions,
have you already implemented or have plans for adding mmo features like:
-AOI(Area of interest)/Automatic network LOD/culling so only network objects near certain radius around the player
will sync data to save bandwidth for large ccu servers instances?
-are you planning to add server to server player had overs for seamless server to server zoned mmos player/networkviews movements setups?


thanks

 

Welcome aboard!

To answer your question, absolutely, and more.

 

Also to mention to everyone that Forge Networking Beta V2 has just been released, if you have not already received the update via email, please contact me or @farrisarts and we will quickly get back to you.

 

Some MMO features are in, they are not in the Beta build yet, but they are designed in the core system and implemented in the Arbiter (which will be our main focus after Beta).

Network culling has it's scaffolding in place and should be implemented in tonights Beta V3. It is controlled network culling so you can specify which objects are culled at all times and which ones are updated at all times independant of positioning.

One of our main focuses with the Arbiter is to optimize for MMO games since the initial package (what is being Beta tested) will already have all of the real time gaming stuff implemented outside of MMOs and centralized servers. This means we will critically analyze bandwidth reduction and algorithms that have various options to allow flexibility on the developers to be able to control data flow.

The Arbiter at it's current state actually handles zone/room communication for seamless transfer of players from one server to another in order to make a seamless and even depending on your hardware, endless world. More on this with the Arbiter beta .

Thanks for the awesome questions! Feel free to ask anything else, you will notice that we are moving super fast to solve any issues and add any features that are requested!

-- Note: Prepare for the Arbiter, it will be a pretty big deal once it is officially released. We have massive plans for it and can't wait for it to be released.

 

Awesome,
thank you guys for allowing me to beta test your product,

to start, it is sweet music to my ears knowing that your networking library will support mmo features like
network lod and seamless zoned player transitions between servers.

to me a networking library server that runs inside a unity game instance is a delight to work with,
for many reasons, but most important are:
- c# coding for client and server , 1 programming language for the whole game.
- debugging in unity is a very easy thing to do , specially with the available existing debugging tools. so it is very sweet to debug the server the same way like the client, a god send.
- server side collisions /physics at your fingertips, everything using default unity physics, no need to third party mambo jumbo physics engine nightmare installs.
- to me this all help to have a tight authoritative server to avoid nasty cheats.

i in particular learned multiplayer /networking with default unity networking, which was so easy and a pleasure to work with, so knowing that forge networking will do all that plus the mmo extra features that unity networking lacked, then i think forge is heading to the right direction.

but there is 1 feature that caught my eye about your library which is room instances that the other competitors do not support yet. unity usually supports 1 room per unity instance server.

in my case i am prototyping an open large world with player joinable within ingame pvp/arenas minigames and
dungeons(matchmaking).
so a roomed based server is needed too for this private dungeons/ pvp battlegroungs. which none of the existing networking plugins that work for unity server instances support natively, ulink uses an aproach which uses uzone to fireup unity instances on demand, but 1 room per unity instance can become too much resources overhead in any harware node.
so I was wondering if Forge arbitrary server does the same? or will create a multi session/network groups within a unity server instance to avoid too much hardware resources overhead instantiating dozens of unity instances as private minigames.

-can you please elaborate a little more what is the current functionality of forge to handle rooms instances for private mini game sessions?
-also an eta on when can we expect to beta test the arbitrary server and the network lod and seamless player handover transitions between servers/zones?


thanks guys, keep up the good work.


BTW, did not know where to post feedback for the beta testing, so to startup i will do it here:
-seems there is a loop somewhere in beta 2 which right after one starts the server, my pc experience intermittent freezing/unresponsiveness.
all my pc cpu cores go full trottle 100% usage which causes freezing right after clicking the start server button.
either in editor mode or standalone windows built mode.
i even covered all the dafault unity quality settings all the way down to minimum, Vsync to every vBlank to restrict fps to avoid cpu usage, even disabled the use DirectX 11 in the player settings.
and all this tested in an empty game project with empty scene but the cube used to follow the getting started tutorial.

maybe i am missing a step, but so far that was as far as i could go with the testing, hope this feedback helps in anyway.

cheers

 

Of course!

Awesome to hear your feedback! So to your inital post. Yes, we are developing a system to run multiple rooms in one Unity instance as well as 1 room per instance for those who want that.

Currently, (outside of the Beta) the Arbiter allows registering of servers with comments (much like unity) to be used as password protection.

We are getting great feedback on the current Beta and are moving fast on all of it! We will be releasing Beta V3 tonight, we released V2 last night and V1 the night before (just to show how fast we are moving). So if we keep this pace I am hoping to begin the Arbiter beta rounds in about a week or two!

Now on to your usage feedback:

We are aware of the hanging issue with the Beta. We have discovered that there is an issue with Beta only code that is doing some tests in the background on start. We will be working on fixing this ASAP, it seems to only happen every now and then.

That is one issue that is separate from the CPU problem you are having. I will double check the V2 Beta thread control to make sure there are no threading issues. The system is fully multi-threaded and I will check tonight to see if there is anything going crazy with them. Thank you for pointing that out!

 

We have discovered the CPU usage issue and will have it resolved in tonight's Beta V3 release.

We actually found that our thread controller had a bug in it that cause the threads to consume as much of the cpu as possible. Currently we are using octa-core CPU's, so the tests we were doing didn't fire off enough threads to use all the CPUs. Recently we have ordered more hardware to help us find these issues and will start making use of virtual machines as well.

Sorry for the issue and expect it to be resolved by tonight.

 

awesome,

glad you found the issue.

ill be waiting for b3 tonight.
good day.

 

There is very little overhead in creating numerous instances. It's also good practice to isolate the processes, so if one room has a crash it doesn't effect any other rooms.

If you setup your server scene correctly, i.e only game logic and physics information, and cut out any textures/shaders etc, you can end up with very lean server instances.