mmo


How to make a MMO (server side)?


I had tried to search about how to make a MMO and always find the same replies, it is impossible or need a lot of money, but never gives a guide on how to make one.
I want to build something very scalable, my current idea on how to build up the MMO is the following:
Components:
Login Server: client sends username&password to this server and if successful gives to the client which Game Server to connect.
Game Server [1..N]: all the game logic goes here, clients are connected to this one.
Position DB: stores data of currently logged users and active monsters, in which Game Server they are, their positions on the map and action they taking (move, attack, etc.).
Account Data DB: stores all data about the user (username, password, characters, items, quests, etc.)
Chat Server: since users that are on the same place can be in different servers, it is necessary to make an extra one so players can communicate between them.
Monster DB: a database with the attributes, base positions and AI scripts of all the monsters.
Monster Server [1..N]: all active monsters in the server
Log DB: stores all actions taken and chat texts.
Actions:
Login:
Client sends Username&Password to Login Server.
Login Server verifies the data with Account Data DB and checks that is not currently logged (Position DB), if successful go to 3, if not, sends back a unsuccessful login message.
Login Server updates the Position DB adding the new connected user with the server he will be connected (lowest amount of people/nearest)
Position DB informs the corresponding Game Server that the user has been connected.
Login Server sends to the client the Game Server is connected to.
Main loop(client):
Client checks in Position DB his current position and action and those near him (players and monsters), within the data received also includes a time of last update (gears or level) of the players.
Client compares the date of the players received with current players saved on memory, if the player was not on memory or the date is not the same, Client asks Account Data DB for lvl, gears, etc.
Client renders the players
after a time go to 1.
Chat:
Client sends a message (pm/normal/all) to the Chat Server
If pm, Chat Server sends the message to the target
If normal, Chat Server checks with Position Server the players in the area (same as main loop (client).1 when checking players near) and sends the message to those.
If all, Chat Server broadcasts to all the players
Confirms that sender&receiver got the message
Action:
Client sends action (crafting, moving, attacking, etc.) to Game Server.
Game Server processes the action and updates Position DB with the effects of the action (client will know what happened with the main loop action).
In case of crafting or looting, Game Server returns to client the item gained.
Main loop (game server):
Checks all received data from clients and processes them.
Sends to the clients the results of the process (damage, xp, item gained, etc.) and updates Position DB with the effects of it (new position, etc.).
After a time go to 1.
Main loop(monster server):
Checks if an active monster there is a player near, if not removes it from the Monster Server and Position DB.
Checks to all players in Position DB if there is any monster near (from monster DB) and is not active and activates it (updating Position Server and Monster Server).
Monster takes action (attack, move, do nothing, etc) based on a script stored on monster DB.
After a time go to 1.
and the questions I have:
Would this way of implement work? (considering a big map with lots of monsters and players)
I have the feeling that the Position DB will be quite stressed if things grow up. would be better if:
make multiple Position DB
make a DB that links (player/monster, Game Server, Position DB)
make a DB that links (Position DB, area)
So that a Position DB is based on an area (or areas) and when a player moves to another area, his data is moved to another Position DB; and the last DB (Position DB, area) would be in case that if an area have too many players few Position DBs could share the same area (and if areas do not have many people, a Position DB can hold some areas)
About technologies used, I was thinking on the following:
Login Server: scala/django
Game Server: raw programming in C++?
Position DB: scala/django for communication and DB with SQL
Account Data DB: scala/django for communication and DB not sure if either using a NoSQL like mongoDB or accounts saved on files (wich would be better?)
Chat Server: raw programming in C++ or should I try to adapt an IRC server?
Monster DB: SQL
Monster Server: like Game Server
Log DB: SQL
Communication between client-server should be UDP for faster communication? and TCP for login? or should keep an open TCP socket always between the client and server? also, for chat, TCP or UDP?
Around every how long should the main loop run so that the game goes fluently? every 0.5 seconds, 0.1, something near a 60fps? also to make the timer would be better throwing a thread every loop? (controlling the amount of threads, so if the loop is taking longer than it should)
And I don't think I am forgetting anything for the moment to ask about and sorry for this big post...
I don't think your solution would scale. The issue is your position DB that needs to be updated for every player action.
You probably use this method to allow game servers to share data, which is a bad idea since databases are not meant to enable distribution of a system.
Treat databases as real offline storage, only to load state when players or objects are activated.
You need to get rid of the position DB and store the players states distributed among the game servers.
Also consider having a front-end server that keeps one connection to the client at all time, relaying messages to the right game server etc. In this way you can avoid clients having to connect to the "right" game server and all the problems that comes with that level of trust.
Distributed programming is pretty hard, but the programming language Erlang makes it easier for you than Python/C++ etc.
Christian is right, you're relying on the DB too much. Typically the current state of the game and its players is stored in the actual server during run time. You can make a feature that automatically updates the DB of a player's position or state frequently, which is very common in MMOs, but ultimately a Database is just a reference to pull data during Start up, not run time.

Related Links

Myth of Soma MMO game Bot - Memory Address for Items on floor contains garbage and constantly changing info
How to make a MMO (server side)?
how to implement a relative timer in a game
What kind of database in regards to cap theorem should be used for an mmo?

Categories

HOME
oauth-2.0
http
formatting
popover
opencv4android
reference
crash
coordinates
esxi
msbi
procmon
google-api-oauth
unreal-engine4
ldap-query
expo
hdf5
web-testing
brightway
vivado-hls
virtuemart
summernote
include-path
policy
scrapy-spider
mongoose-im
pydub
stack-trace
android-6.0-marshmallow
multiple-inheritance
launchd
pushpad
delphi-2010
jboss-arquillian
choco
ports
availability
angularjs-resource
android-geofence
cocoa-scripting
mkdir
console.readline
rtsp
mongoid5
var
google-cloud-powershell
contenteditable
peerjs
firefox-developer-edition
superclass
inner-join
jks
runner
remap
stream-socket-client
stanford-nlp-server
nservicebus6
aot
typewriter
selection-sort
multi-targeting
petapoco
tsc
iban
robotc
nls
qt3d
vertex-shader
qudpsocket
computed-properties
settext
foreground
falcon
clique
ideavim
bluetooth-lowenergy-4.2
google-finance-api
clear
nonblocking
gtkwave
gnu-sort
libgcrypt
bootstrap-tabs
consul-template
litedb
playn
photogrammetry
teamwork
minko
radgrid
mathics
applinks
tigase
powerpoint-2010
sendy
iwork
fastcgi-mono-server
kuka-krl
android-jack-and-jill
nativequery
nomachine
codio
lastinsertid
infinity.js
dd4t
proj4
architectural-patterns
expresso-store
netbiscuits
derived-class
certificate-revocation
flatten
django-1.4
mvcmailer
commonsware
visual-leak-detector
wdm
sipdroid
cinder
nscharacterset
system-analysis
atmega16

Resources

Encrypt Message