Jump to content
  • Advertisement
Sign in to follow this  
disks86

MMORPG client/server structure idea

This topic is 4069 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, so here is the low down I had an interesting idea and I wanted to see if anyone has tried it or anything like it. If so will it work and will it be scalable enough for an MMORPG. First off this idea is based off of postgreSQL so if you don't know and can't guess it is a database. Anyway what I was thinking is that you could bypass a traditional server and have a client connect directly to the database. Of course the client would have to access things through procedures to validate input to prevent cheating but as I see it the advantages are as follows. 1.Instance data is in the database so no roll back. (as a user I don't like roll back) 2.The protocol should not need modified to change functionality only query/procedure changes should be required. 3. PostgreSQL allows tables to inherit from one another for targeting could be handled via an EntityID or something of that nature. 4. Information could be sent back to clients via a trigger. On a side note the chat would likely need to be handled by a different server maybe jabber protocol or something. My question is more about speed and scalability but any other constructive comments are welcome.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by disks86
...Of course the client would have to access things through procedures to validate input to prevent cheating...

That's mostly what a game server does in my understanding, so you're back to needing one. Also, relational database access is generally slow, so normally you'd want to reduce it somehow, not increase it.

Share this post


Link to post
Share on other sites
1) Roll-back is a must-have feature. What happens, when developers leave a bug that allows a certain action to duplicate items, or crash the economy through money duping? Go through millions of records, fixing them by hand?

2) This is true for traditional architectures as well. Hopefully you're not proposing clients to connect directly to SQL server?

Complex actions require locking or transactions. While fast, doing several of those at the same time can bring down the entire database.

Scalability here depends on number of requests. Traditionally, SQL servers have proven incapable of such processing on MMO scale. But it would work for small game.

It's perfectly possible to write a multi-player game solely on an SQL server. In many ways, it's a good idea, especially if you add various GIS extensions to do spatial queries.

But since you still need to provide a front-end process as a proxy to database, it quickly becomes feasible to add more features to it. And eventually you end up with current design, where database is backing store, most of logic is in scripts, and updates and multicasting is handled by the proxy.

Share this post


Link to post
Share on other sites
So possible but not a good idea got it. That is kind of what I thought but I thought I would check because it would have been cool if it would work.


Thanks for the feed back though.



I really wish it was easier to make MMORPGs seems like everyone wants to make one but few make it to a usable state but that is another topic for another most thanks again all.

Share this post


Link to post
Share on other sites
Quote:
Original post by disks86
I really wish it was easier to make MMORPGs seems like everyone wants to make one but few make it to a usable state but that is another topic for another most thanks again all.


That's a big can of worms to open [grin]. If you are so inclined, there are some middleware solutions out there, not least the current hot topic of the Java gaming community, Project Darkstar, which promises to make the scalability and persistence problems go away but not the networking, although multiplayer networking is a well-explored domain from what I've read on it so far. But it limits you to Java on the server-side, which is actually not a big problem.

Even if you somehow get the artistic and development talent together to make a semi-decent RPG, there's still the issue of hosting it though. But if you re-define MMO to mean "around a hundred concurrent players or so", it should be easier to fund hosting for it.

Share this post


Link to post
Share on other sites


MMORPGs usually have entities that execute independant of the players (ie- NPCs/Monsters ). They usually wont operate too well only off events cascading from player actions. Thus you generally cant have only a DB for your 'server'.

I suppose if you had a game where the world changed (reactively) only from player actions, you could do something like that. Consider though that as your game mechanics grow in complexity, your 'business logic' will have to grow accordingly to carry them out.

Share this post


Link to post
Share on other sites
I am currently doing something very similar to what you propose! So far I have had only anecdotal evidence to support its scaleability and security. Basically I have the DBMS perform most of the actions a client can take through stored procedures and triggers. I do have a server, but it is very small, and its role minimal. It is akin to a thin-server in my implementation and all it does is do updates to update non-player controlled events and npc controlling. if you would like more infor on my very small server, robust DB implementation please feel free to visit my open source project! :)

http://sourceforge.net/projects/jabtools

I hope this helps. Dream and think big, or don't bother doing either ;)

Thanks!

Share this post


Link to post
Share on other sites
Quote:
Project Darkstar, which promises to make the scalability and persistence problems go away


It is important to note that Darkstar is only a transactional methodology (similar to an app server), and cannot do server-side physics.

In general, you want the database in the MMO to store persistent things when they change, but you don't want ephemereal things like player location to be persisted each time they change. Thus, you have to design your data model to include elements that are "checked out" of the database, and only written back in at certain times. Which data elements are "checked out" (and thus owned in-core by the separate simulation/game servers) and which data elements persist directly in the database is a schema design problem that you'll need some experience to get right.

Also, connecting clients directly to a RDBMS like PostgreSQL is always a bad idea. The reason is that the clients must be given some permissions to alter the database (else, what's the point?) and a hacked client can then use those permissions to alter the database in their favor. That's why you always put a game server or application server of some sort in front of the persistent database storage; it enforces the "business rules" (game rules) and access/privileges control at a much finer-grain level than the DBMS can do.

Share this post


Link to post
Share on other sites
Quote:
Original post by disks86
I really wish it was easier to make MMORPGs seems like everyone wants to make one but few make it to a usable state but that is another topic for another most thanks again all.


Think of it this way, if everyone made their own MMORPGs then there wouldn't be anybody to play them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!