This repository has been archived by the owner on Oct 19, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathARCHITECTURE
executable file
·78 lines (67 loc) · 3.55 KB
/
ARCHITECTURE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
SimpleMMO Architecture
Charles Nelson
%%date
SimpleMMO has a rather complex server architecture, but this allows us to
separate concerns and have well-defined servers of specific information.
This also allows servers to be spread out across the internet, or optimized
or rewritten without rewriting the rest of it.
=== AuthServer ===
The first server a user comes into contact with is the AuthServer.
It handles all the authentication of users.
It also is capable of retrieving all the characters a user has associated
with their account.
Since these two handlers require authentication, the user who owns a given
character is hidden from end users.
This allows us to have separated characters by default, which means that
when one character adds another to their 'buddy list', or similar, all their
characters may not necessarily have the same 'buddy' magically appear in their
list.
This however, is all up to the implementation of the buddy list that the game
developer decides to use.
=== CharacterServer ===
This is a server that retrieves information about characters.
It is mostly unauthenticated and information served by this is considered "open"
to all.
This will allow not only the user to fetch what zone they may be in, but also
to retrieve all statistics and information about a character.
This could be used in the UI to show levels, or allow you to "inspect" a character.
Data:
Important and should use a 'safe' database.
Should a character's row go missing, that character would effectively be gone forever.
Players will be upset.
=== MasterZoneServer ===
This server allows a user to look up where the server for a given instance ID like
"playerinstance-GhibliHills-Groxnor" is located.
In doing so, it either returns a URL for the user to connect to, or it starts up
a server, and also returns its new URL.
Data:
Not very important.
If a row goes missing here or there, we'll just end up with a very lonely zone server.
Even this is mitigated by the zone servers which shut themselves down if they
don't get requests for 5 minutes.
==== ZoneServer ====
This one allows the player to retrieve objects' information that live inside this zone.
There is support for getting all objects, getting all objects changed since a
given timestamp, or a list of specific objects' information.
In the future, there may be a built-in WebSocket handler that does the job of
the PhysicsServer (see below), which will make it read/write, and will feed the
client a stream of player movement updates.
Data:
Not incredibly important.
If a row for a character position disappears, they will just show up at the (re-)spawn point.
If a row for event statuses disappear, that zone's scripts might break, all or
just some things might reset, and the whole experience of that zone may be broken.
Loot may appear to re-spawn, which may lead to duplication of special items, or
allowing for extra loot from chests without having to kill all the trashmobs.
===== PhysicsServer =====
The PhysicsServer manages player input for movement.
Player keys are sent directly via WebSockets, and interpreted accordingly.
This is a write-only server, not being queryable.
It manages each player's movement, and persists this to the database every ~200ms.
Player positions are queried from the ZoneServer just like object positions.
Clients are responsible for motion interpolation.
Data:
Not important at all.
Only manages in-memory player positions and mob positions, so if those are lost,
things just revert back to wherever they were persisted to the database last.
This needs to be fast and not reliable. It shouldn't be persisted at all.