next »

[kamac]

I'll add it later, then. Not yet too late to switch. (Because I haven't started on implementing it)

@EDIT

I love how Go has all those things PHP has built-in (except mysql, but it wasn't a bigger problem to get it). I mean hashing like sha256, base64_decode and encode. Nice.

[Lynx]

Good lord.  I'm sorry I didn't spot this topic earlier.

I used to work at Mplayer, a multiplayer game network company, then at There, a virtual reality community company similar to Second Life, so I've got a bit of experience in these things.

Most important thing I'd suggest here is, abstract and separate your systems' interaction.  Get away from the idea of 'servers' as huge do-everything programs.  View them as small black boxes, similar to subroutines.  They take requests and return responses.  When you want to scale up to hundreds or thousands of users simultaneously connected, you can just throw more machines at the problem, where you actually need more capacity.

The database will be your bottleneck if you're talking about a real MMO.  Eventually you will want to shard it so that, say, world information for sector A lives in this database, world information for sector B lives in that database, or characters A-M are in one database, N-Z are in another, et cetera.  Protect yourself from scaling blues by putting database access behind servers that will know the details of how exactly you're sharding your database, and will talk to the right databases.

The client is in the hands of the enemy.  Never blindly accept whatever is sent back from the player, i.e. when you're having the player move around, don't just have the player send you his or her new location and set that.

Sanitize your data.  Run it through a MySQL character escape going into the database and the reverse when retrieving it.  The same applies to accepting and displaying any text the user inputs in a webpage, lest you create XSS (cross-server scripting) vulnerabilities.

When prototyping, you don't need a database, you could just have your 'database server' create a fresh in-memory copy of everything you need and update that.

I'm much more used to Linux servers, so I'm not sure what you'd do for Windows server development, but as I see it you basically want:

* login server - accept user login and issue a session cookie for validating the user.
* user data server - stores user login information (be sure to encrypt passwords and store only the hashed passwords, you don't have to decrypt them, just make sure whatever password a user sends hashes to the same value, thus no plaintext passwords)
* world server - handles the game physics, only talks to users with valid session keys.
* game data server - handles fetching and storing updated game object data.  Talks to the *world server*, not the user.
* web server - hosts the pages the player will use to connect to and interact with your game.  Even if you're making it Flash based, you might want to make things like user account management be separate pages rather than all done through the game.

Diagram your servers out on paper and make sure it makes sense to you!  Multiplayer game coding isn't really very friendly to seat-of-the-pant coding, especially when it comes to things like multiplayer game physics, handling lag and packet drops, data consistency issues and race conditions between servers.

[Dacke]

That's some good advice, but it doesn't fully apply to the current situation. He has too little time to do things properly, so what he needs is probably some crazy shortcuts (for example using in-memory databases).

He is planning to run a Linux servers though, so your advice is applicable to that.

[kamac]

Thanks for those, I am happy that I could experience some of those before, though.

The client is in the hands of the enemy.  Never blindly accept whatever is sent back from the player, i.e. when you're having the player move around, don't just have the player send you his or her new location and set that.

That's something that is obvious to me (luckily), so I try as hard as possible to secure things down. Ofcourse, I won't be able to make it 100% enemy-protected, but I wish I can get it to some proper level.

Sanitize your data.  Run it through a MySQL character escape going into the database and the reverse when retrieving it.  The same applies to accepting and displaying any text the user inputs in a webpage, lest you create XSS (cross-server scripting) vulnerabilities.

Again, luckily I spent some time reading about websites' vulnerabilties, so I know those popular terms like XSS, mySQL injection, most common PHP vulnerabilities like injecting your own code. I hope that will let me protect the whole thing to some extent.

* user data server - stores user login information (be sure to encrypt passwords and store only the hashed passwords, you don't have to decrypt them, just make sure whatever password a user sends hashes to the same value, thus no plaintext passwords)

Another thing I lately read about, I sent you a PM with few questions. I hope you don't mind answering them.

* web server - hosts the pages the player will use to connect to and interact with your game.  Even if you're making it Flash based, you might want to make things like user account management be separate pages rather than all done through the game.

Yes, account management ( like previewing your in game characters ) is a thing I thought about, but I think I'll leave it for now.


In general, you've mentioned a lot of different servers, while my project is aimed to be minimalistic for now, and I will have to stick with two "servers" running in one machine. (Website handling [apache/nginx] & game server [coded in Go])
Making that many servers would take too long, I think.

[Chromanoid]

Just replace "server" with "service". It is more about decoupling and being able to scale vertically by placing separatable components on different physical servers.

[Gregg Williams]

Yeah all of that is about horizontal scaling, vs just throwing more hardware specs at the problem (vertical scaling) which is limited.

Though honestly if your doubtful of 10 players, let alone 100, or 1000 all of that is likely overkill for your problem. Unless this is all just for academic/learning sake.

[Chromanoid]

Just as a side note, I think there are two different meanings of being able to scale horizontally and vertically.

In context of hardware:

Yeah all of that is about horizontal scaling [more machines], vs just throwing more hardware specs at the problem (vertical scaling) which is limited.

In context of architecture:
Scaling vertically: Components/layers of functionality are placed on different nodes.

Code:

 node0
|AAAAAA|      node0    node1    node2
|BBBBBB| --> |AAAAAA| |BBBBBB| |CCCCCC|
|CCCCCC|

Scaling horizontally: Work can be equally distributed between nodes.

Code:

 node0       node0     node1    node2
|AAAAAA|     |AA|      |AA|     |AA|
|BBBBBB| --> |BB|      |BB|     |BB|
|CCCCCC|     |CC|      |CC|     |CC|

Being able to do both is naturally the most scalable way. Real horizontal scalability is superior. Vertical scalability finds its limit when the work of an atomic component can't be computed on one node in the required time.

[BorisTheBrave]

Guys, stop giving Kamac good advice. Pros care about scaling. Kamac's circumstances have made quite clear he neither needs nor can afford to do things properly. You'll load him down to the point there's a 10% of a good product instead of 90% of a kinda-works one.

[kamac]

Guys, stop giving Kamac good advice. Pros care about scaling. Kamac's circumstances have made quite clear he neither needs nor can afford to do things properly. You'll load him down to the point there's a 10% of a good product instead of 90% of a kinda-works one.

But why? Those information are always good to know. For example, I didn't know what horizontal & vertical scaling could be - but no longer

he neither needs nor can afford to do things properly

Properly atleast for MMORPGs. I am building somewhat a MORPG. Not that massive. I guess that matters.

[Gregg Williams]

Just as a side note, I think there are two different meanings of being able to scale horizontally and vertically.

Hahah yeah I could feel when I posted that, I was going to get hit with that . It's totally true separating the components does allow a sort of vertical scaling. Just usually when you go through all the trouble to separate custom coded services and invest the additional time to allow them to communicate as needed, your ideally heading towards horizontal scaling.

[Lynx]

My view is, think ahead, put in groundwork but don't /implement/ the servers, just have placeholders and stubs for everything but what you actually want to test.

So for example, you can abstract the login servers.  Don't actually have login servers/user database for your test, just accept whatever username the player gives you and let the player right in.

For the game server, make stub methods like 'GetPlayerState' and 'GetWorldState', but have those refer to an in-memory model so it starts fresh every time you restart it.

Stuff like that!  Then when you're ready to plug in a database, you can implement a world database server that issues queries to the database and returns the result, and then implement database versions of GetPlayerState and GetWorldState, and you're rockin'.

It's much easier to change code that lives under an API than redesign your code because you need to change the whole system, is what I'm getting at.

[Sir Wolf]

My view is, think ahead, put in groundwork but don't /implement/ the servers, just have placeholders and stubs for everything but what you actually want to test.

While I agree with the general notion, I also find that it's the designing process that takes most of the time as opposed to making the actual implementation. For this kind of thinking ahead approach, the design still would need to be relatively robust (and thus take more time).

I'm also not a fan of thinking ahead just in case. Only think ahead if you know for sure the stubs you make are going to be needed and expanded upon later. If you might or might not need something later, I'm usually an advocate of considering it not needed until it turns out otherwise. Potential time saved in the future can easily turn into actual time wasted right now.