Hi there, I am currently in the process of planning to develop an mmo rpg, and was wondering if

anyone could assist me in choosing what engine/tools would be best for such a project.

To get started I am a pretty competent programmer, I have been programming for 6+ years now

and know how to program in c++, c#, java and some other high level languages and I do know the

basics of writing a network architecture to accept and handle multiple clients.

I am currently stuck on what tools I want to develop with however, my most preferable option would

be to develop the client in unity, and program some sort of server that handles all player data, hooked

up to a database etc.

My first issue with this was considering how the world will be built with unity, because unity would host

the client the server should send the information of what stuff/people to render around them, while

sending input data back to the server. I thought about using scenes in unity to represent maps of the

server, perhaps completely building the map in unity, but how do I handle the collision in this setting on

the server? considering that the server would control the update process of all the players, like moving

them according to there input data, the server needs to know about the world in some way to manage

collisions properly, ie not letting them walk through walls and not falling through the world if I apply gravity.

If I was however to allow unity to manage all the physics of a player, and just upload the players position to

the server rather than pass input data, isn't this a security risk?

Considering these factors I then thought well what if the server stores all the maps data, passing it to clients

that connect to specific maps, and having a script in the maps scene build the environment when it starts up,

I would however have to program the collision and physics logic myself on the server, but I think I could

program a server capable of doing those things, something along the lines of having a file for a map which

stores objects by name, giving them a position in that map and a bounding box or collision mesh, then unity

can just can just load a prefab object with that name at said position.

Another option I have is rather than using Unity I could program the client using OpenGL, as I have been using

OpenGL for around 3 years now and can write an efficient renderer with it, then in this case I would probably

program the server in a similar way to what I am already thinking, however this would create more overhead

in having to write graphics code on top of network and general mechanics, I would only take this route if unity

provides more trouble than its worth in development.

I also do have a question about general mmo network architecture, how many threads should a server have for

clients, the way I have considered it is to:

* have a thread on the server listening for and connecting clients

* have a thread that is updating all maps/players within the maps

* have a thread for every client that is reading there input data

* the main map/player update thread would send out render data to all clients at the end of each update frame?

That is about as far as I have got in the considerations for developing my project, and would like to know if I am

thinking about it correctly, and any other suggestions are greatly appreciated :)

The language/IDE issue is not relevant to multiplayer programming - all the tech you mentioned is suitable. So use what you like.

My short answers to the rest are:

• Collision on server vs. geometry on client - you could export a simplified version of the geometry for the server to process. I've also heard of some people trying to use a Unity process for the server itself but I don't know anything about that.
• Send positions vs input data - this is a common misconception here on Gamedev.net. It's perfectly fine to send positions providing you verify them server-side. I would argue that this method is significantly preferable to trying to replicate client-side input on the server, which comes with a bunch of problems regarding jitter, dropped messages if you use UDP, etc.
• Threads - have as many or as few as you like. There's no right answer or standard approach. In fact it depends somewhat on the languages and libraries you use, as some will make threads for networking virtually mandatory whereas others will happily run in an event-driven manner. Personally I would advise that anyone who has to ask about threads should probably not be using any yet.
• Also, you wouldn't send out "render data" to clients. You send out information about what has changed in the world and the client works out how to change the rendering.

I am currently stuck on what tools I want to develop with however, my most preferable option would be to develop the client in unity, and program some sort of server that handles all player data, hooked up to a database etc.

Look into Unity, and for networking/server development look into darkrift. You need to create proxy servers to talk to each other for your own sort of load distribution.

I thought about using scenes in unity to represent maps of the server, perhaps completely building the map in unity, but how do I handle the collision in this setting on the server?

Don't use scenes, just use 1 scene and tell the client where they are/what to load.

You can handle collision by running a unity instance per zone, if you want to use default collision. With a good algorithm to occlude collision checks it should be fine enough.

If I was however to allow unity to manage all the physics of a player, and just upload the players position to the server rather than pass input data, isn't this a security risk?

Yes. The client should only send input, and use client side prediction to determine their location. The server should handle the actual logic for movement, and occasinoally send corrections to the client.

Considering these factors I then thought well what if the server stores all the maps data, passing it to clients that connect to specific maps, and having a script in the maps scene build the environment when it starts up,

Why? Just have the maps on both the client and server, and check them with a basic crc hash to make sure they match. If people cheat the system/modify their maps, the server should send them correction updates anyway.

You could always give HeroEngine a spin, I think it's free to start. It's basically a MMO engine. I've only puttered with it, so can't give much of a true opinion of it though.

Do you really need a seamless roaming world (like WoW or GTA,) or are smaller separate zones OK (like EverQuest and City of Heroes)?
If you can get away with smaller zone levels, and a loading screen when walking between them, your options become a lot more tractable.
The other good news about zones is that you can instance them when you get higher player counts -- there could be five "central market" level instances, and players are by default funneled into the least-crowded instance.
(Even WoW does this, for instanced dungeons -- you'd just be making every area of your game like an instanced dungeon.)

Heroengine is a great tool.
If you want to try:
https://community.heroengine.com/forums/
In the Skype chat some devs are willing to share their experiences and more

Thanks for the input guys, iv heard about hero engine but thought it was only a paid licence, if I can get my hands on a trial I'll definitely give it a try.
I do have a better idea now atleast how to program the client and server.
On the note of having zones/open world I know people prefer open but I would probably just implement zones as it's easier to manage from a programming standpoint.

So, with zones, you can probably make do with the existing support in Unreal Engine, or with something like Proton for Unity.
(You'll still need to add database persistency and logins and such.)
The good news of using an existing game engine with built-in networking is that you can focus on the game aspects!