thanks, commenting those lines fixed the issue,
now the server starts ok, but…
can not connect to it from the client project.
the client project by default seems to try to connect to lobby standalone console server, right?
I fired up the lobby standalone server console and did not see any signs of connection from client, using the client default host 127.0.0.1 and default port 12345 configuration.
unless the lobby is setup for another port? no idea since no way to see.
now, you mentioned the lobby standalone app is not necessary, but can you state how to connect client to server directly without the lobby?
also, can servers intercommunicate between them to hand over players for a zoned mmo? or is this a one unity instance server per game setup?
thanks again.
The hardcoded port for the Lobby Console Server is 10002
And the App ID for connecting to the Lobby Server must be UniVerseLobby
got it, thanks.
so now we getting somewhere 
so far got the following :
fire up the lobby console and unity server instance using the above hardcoded ports and lobby server name, the lobby now registers the newly connecter server.
then fire up the client using the above info for port and lobby server name and get successful connection and see the server ready in the gui layout.
so now the next step, when i try to connect to the available server i get the login screen,
so new step ahead, where shall i look for this new step of persistance db, is there any mysql dump or which file shoudl i look for to learn about it and get the authentication setup?
sorry , too many question but i get exited with new server apps to test.
thanks again for your support.
lol No problem. It would be easier with Documentation I just haven’t had time to work on it yet.
For everything related to Database is in the AccountPlugin or AccountClient. I believe it’s in the Client Script.
You also have the following in the ServerManager script:
MySQLManager.Instance.CreateConnection(“localhost”, “citylife”, “root”, “”);
Right there you have the DB host, DB name, then username and password.
You can then get records from the Database with the following:
MySqlDataReader reader = MySQLManager.Instance.Select(“Select * FROM accounts WHERE username='” + user + “'”);
Put in the query you want to make there. I’ll prob. look into making this more user friendly so that you don’t need to know the actual syntax for the query but for now it works.
ok,
thanks, ill look into it.
Also the account table that I currently use with that just has an id which auto-increments, username field, and password field. Should be very easy to setup.
got it,
now, how can this setup be able to create an mmo setup,
i mean, the server registers with the lobby server, client selects the server as some sort of room to join, but once in the room or server, how can this take it to the next level of handling several hundreds of players in the same world/ instance?
since we know that it is not feasible for a unity instance server to handle more than 100 ccu without beaking/ freezing the server, in other words how can this be made as an scalable seamless world?
unless a zoned type with being each server a different zone to join, but again how does player jumps from one zone to another, do we need to logout then join another zone/server.
still trying to understand your initial point of view to achieve this scalable setup for mmo like game.
perhaps you can enlighten us on how you planning to achieve this setup.
thanks again for your time and support
Haven’t really gotten that far yet. I have Server Designs running through my head and down on paper but nothing implemented yet. We know it can handle Lobby based MMOs like LoL or MMOFPS like Combat Arms just haven’t tested it to see how many players can be supported on a single Server.
For true openworld MMOs first of all developers are free to setup their own System for going between Servers as for an officially supported way of doing that the design I’ll be implementing to test out involves a Relay Server.
You have your Unity based Game Simulation Servers. Each one handles a section of the world. You then have Relay Servers which connects to the different Simulation Servers. The Clients then connect to the Relay Servers and are associated to whatever Region they are currently in. The Relay Server then relays messages back and forth. If the Simulation Server goes down the Relay Server can transport the player back to their home or some predefined location and a message having some remark about why they were teleported. If you need to allow more players to connect you would just start up a new Relay Server which would be cheaper to run then a completely new Sim. Server. This would also prevent the players from gaining access to the IP addresses and ports of your actual Simulation Servers so it would be harder for them to try and externally hack the Sim. Servers.
On paper it all looks good but it will be interesting to see how it actually works when it’s implemented.
James,
what will be the license model for this framework? will it be free to use and distribute with any game as in the current binary state?
or will you sell source as optional?
or you just releasing binaries while in beta for non commercial games, then will sell a release at a price when this is completed?
or the base framework will be open source and you will sell plugins as extras?
i am intrigued on how you gonna market this product.
thanks in advanced
For testing during Alpha at the very least it will be free for development/non-commercial products. After Alpha or Beta there will be a paid commercial License. Not sure how much yet though. The license for Universe will also get you a UniStream Pro (My Asset Streaming Plugin) License which alone I’ll be selling for $100.
A Update on Universe… I’m in the process of integrating a new Messaging System which allows for distributed Messaging. Meaning you will now be able to create different Servers for your different Game Play Features and have them hosted on different Server Hardware. So Games will now scale by adding more Physical Servers.
Awesome,
now, when you mentioned “Games will now scale by adding more physical servers”:
can you elaborate more on this, like will it be the same lobby style where the servers connect to the lobby then players can select which server to choose from lobby? or you mean that the servers will be able to intercomunicate between eachothers to hand over players for a zoned mmo setup?
Like I’ve said in the past The Lobby System has always been and always will be 100% optional. There’s nothing forcing developers to use the Lobby. It’s just one more added features that’s available if you want to use it.
With the new Distributed Messaging System you will be able to have Plugins/Servers that can intercommunicate with each other. So you could have a Communication Server which is the ONLY Server that players would connect to and then you can have an Account Server, Character Server, Area Simulation Server, ect. which the communication Server passes messages to and receives messages from for the Player.The Messaging System is fast:
There are some test results for messaging in DotNetMQ:
Messaging:
- 10,000 messages in ~25 seconds as persistent (~400 messages/second).
- 10,000 messages in ~3.5 seconds as non-persistent (~2,850 messages/second).
Method Calls (in DotNetMQ Services)
- 10,000 method calls in ~25 seconds as persistent (~400 calls/second).
- 10,000 method calls in ~8.7 seconds as non-persistent (~1,150 calls/second).
Test Platform: Intel Core 2 Duo 3,00 GHz CPU. 2 GB RAM PC. Messages/calls are made between two applications running on the same computer.
Those are just some baseline stats from the testing they have done on it.
And here are some of the features of DotNetMQ:
DotNetMQ is an open source Message Broker that has several features:
- Persistent or non-persistent messaging.
- Guaranteed delivery of persistent messages even in a system crash.
- Automatic and manual routing of messages in a custom machine graph.
- Supports multiple databases (MS SQL Server, MySQL, SQLite, and memory-based storage for now).
- Supports don’t store, direct send style messaging.
- Supports Request/Reply style messaging.
- Easy to use client library to communicate with the DotNetMQ Message Broker.
- Built-in framework to easily construct RMI services upon message queues.
- Supports delivering messages to ASP.NET Web Services.
- GUI-based management and monitoring tool.
- Easy to install, manage, and use.
- Written entirely in C# (using .NET Framework 3.5).
This kit is being redeveloped using the MassiveNet Networking engine… A MassiveNet license will now be required in order to use this framework.
We are also on Steam GreenLight:
http://steamcommunity.com/sharedfiles/filedetails/?id=296524257
Looks interesting. Would you see any problems running this in an Azure instance for the server? Also, can I tie into my own authentication system?
Another question, how is threading handled? For example, does it spawn a thread per player? Will it shard across servers if too many people join?
MassiveNet handles the whole Seamless Server to Server handoffs and everything. Basically your world is broken up into Zones, You run each zone on it’s own Unity based Headless Server and the Server handles transferring the player between Servers seamlessly as the player moves around.
Being a Headless Unity Instance the Server can be run on Mac, Windows, or Linux based Servers.