Scalable Server Software for MMORPG Maker XB!

[Administrator]

Dear MMORPG Maker XB Users,

Recently, we have been building the game server software which will power MMORPG Maker XB games.

In order to do this, there were several challenges we had to overcome:

1. Standard web servers are built to serve web pages ONCE and will sever the connection once the request has been completed. As such, web servers cannot handle multiple concurrent connections, and, especially, the high bandwidth of MMORPG games. In layman's terms, when HTTP and web servers were built, no one was expecting data transfer to proceed beyond a certain point. This is an architectural design problem, and we determined we could not build a web game server on top of this architecture as the demands are drastically higher for gaming. Unlike web pages, games (and especially MMO games) process hundreds to thousands of times more data PER SECOND than HTTP web servers.
   .
2. Both the multi-threaded and asynchronous server design models would result in difficult-to-track bugs such as "race conditions" ( http://en.wikipedia.org/wiki/Race_condition ). The multi-threaded model would also reduce vertical scalability due to operating system or hardware limitations.
   .
3. The bandwidth overhead of HTTP (and, additionally, the underlying TCP layer) was too expensive from both a technical and monetary perspective. Due to the limited data we can send down the pipe, a custom game server was absolutely necessary because some form of TCP throttling needed to be implemented to avoid network congestion. Otherwise, your ISP or server host will kick you off the network, or, if they have the infrastructure to manage it, you will end up with a very large excess bandwidth bill -- think of it as your phone carrier charging hundreds to thousands for all those extra minutes of calling or text messaging on a much larger scale.
   .
4. Since HTTP is built over the TCP protocol, we have to deal with the limitations and design of TCP. For example, due to the guaranteed delivery nature of TCP, network connectivity errors can cause the entire server to lag down in a queue of latency trying to handle dropped connections and the like. Additionally, there is a limited amount of data which can be sent simultaneously regardless of your connection speed, and, to avoid this, TCP buffers data which can cause latency (known as "TCP delay"). Without a custom server design, low-level TCP options like this cannot be disabled.
   .
5. A standard HTTP server does not provide game-specific security. For example, if you obtain an item, a notification would be sent to the server noting that you've obtained the item; however, this notification can be easily crafted and sent by a hacker even if he did not actually obtain the item in-game. This creates server-wide security holes in the game whereby movement hacking (walking over mountains, rivers, and other obstacles) and more can become possible. A custom server allows for custom security settings. For example, the server needs to make sure the player was in front of a treasure chest before the item in the chest is granted to him; in an unsecured architecture, the player position can be sent to the server and checked, but hackers can easily spoof the position, and encryption of messages to the server has always been notoriously useless in the MMO industry because client-side encryption is nothing more than security through obscurity which isn't secure at all.
   .
6. Memory efficiency is absolutely necessary. If your server runs out of memory, it will go down. Knowing the differences between various I/O techniques and speeds are also very necessary, and, with a non-blocking design like what we use in our server, race condition security holes can easily pop up with poor design or complete malfunctioning can occur whereby data is assigned or sent to the wrong players.

Thankfully, we have designed a prototype custom scalable server. With chat only, it will scale to well over 10,000+ simultaneous users. Of course, due to all the in-game action, this number will lower. A standard web server cannot handle 10,000 simultaneous connections even for a program as simple as a chat which uses very little bandwidth; when you throw in all the data processing and bandwidth an MMO requires, the web server will break down. Additionally, we would like to announce all of the above problems have been solved in our prototype thus far.

Here are more features in our server which have already been completed:

• Hosted on port 8081, separate from the standard HTTP port (80) so you can also run an HTTP server to serve web pages on a single server.
  .
• Programmed from scratch with scalability in mind
  .
• Asynchronous I/O
  .
• Instantaneous request processing. The server does not buffer data for reduced memory overhead and more efficient vertical scalability.
  .
• Real-time data handling (we do not waste bandwidth by sending requests to the server every 5,10,30 seconds even if there is no data to receive)
  .
• Connection limits
  .
• Authentication system
  .
• MMO security foundation
  .
• "Zoning" system
  .
• "Lazy broadcast:" The server will send data only to the users whom should receive it instead of sending to the entire server (i.e. a common poor practice is to pre-pend the username or ID of the players which should receive the data and filter it out on the client-side so it "appears" data was only sent to certain users -- this is both insecure and bandwidth-heavy); thus providing you tremendous cost savings in terms of bandwidth.
  .
• Much, much more!

In the future, we may even include revolutionary methods to enable UDP and other protocols over the browser with the server handling the response.

Conclusion: We would never recommend you run a web game server using a standard HTTP web server. It will crash and burn. There are operating system and hardware limitations, and standard HTTP web servers are designed SOLELY to serve web pages -- not games. There are memory problems, blocking calls, slow I/O, latency, TCP networking issues, and so on. A web server can handle a certain number of connections, but the game will never be a "true" MMO because it will never be "massive." With MMORPG Maker XB, we solve all the headaches in building scalable server solutions for you.

Sincerely,


MMORPG Maker XB

[Valosity]

Yay
But... so we have to pay for our servers, correct?

~Valo

[Administrator]

We are planning a shared server plan where many games will be hosted on a single server for smaller developers. The shared server will utilize our connection limits so you will only be able to have a limited number of players online at a time. This is only in the planning stages, and we cannot guarantee whether the shared server plan will make it to the final version.

If your game is huge, you will need to purchase your own dedicated server or even server farm. Although, if you are running a large MMORPG, you should be making enough money to easily afford your own server anyway (World of Warcraft makes over $1 billion+ per year).

[Nebelstern]

game set up on a server seems like a complicated procedure to me.
( having never done anything like this before)
i hope you'd provide support if there are difficulties... : )

[Administrator]

This is actually more of a technical overview of the server features. The server is very easy to run and use! All you have to do is enter a single command and the server will start!

[Nebelstern]

aah, so you were writing about / introducing the shared mmorpg server to host the first mmoRPGs?
haha - ya sorry i must have kinda missed that, thought you were trying to explain how to set up the game on some other server.
well anyway - you hosting it that is a wonderful idea too - i hope it will work out as well and simple as planned then.

[glitch]

so am i to understand this correctly you will host all servers at a fee, we can not run our own severs at our locations?

[Administrator]

There may be a free server plan later, but you are correct in saying that you cannot run your own servers at your own locations unless you license our technology via our game studio licenses, but the prices for these licenses start at $10,000 USD and are primarily aimed at professional game studios that have the budget. If you are interested in licensing, please contact us at:

http://www.mmorpgmakerxb.com/p/contact

The main benefit to having us run the servers is that you don't need any server administration expertise (we run Linux servers only) and we're responsible for the maintenance and upkeep.

[glitch]

but if I plan on doing an Item mall and you charge per person that plays. it kinda makes me have to charge for play

[Administrator]

Hello glitch,

We do not charge you on a per player basis. You don't have to charge your players to play. You can make your game entirely free if you want.

I'm not sure where you got the notion we are charging you per person. We have never stated this, and it's definitely not mentioned anywhere in the forums. Whoever told you this is wrong.

There are indeed royalties on all the payment plugins where we automatically shave a percentage of the earnings to pay off our expenses so if that's what you're referring to: you control the price and subscription amounts. Our prices and royalties are constant, predictable and always fair. We prosper when you prosper. You don't have to charge any subscriptions if you don't want to; again, your game can be entirely 100% free. However, the royalties exist so we can provide you cost savings (e.g. Adobe Flash will cost you $699 USD, we charge $37 USD for the beta access), but you don't pay a single dollar in royalties unless you made a sale.

Our servers go for a monthly fee. Currently, we're planning for servers to start at just $4.95 USD/month. A decent server will cost you $25.99 USD/month, and this "mid-tier" plan should be more than enough for most amateur MMORPG games.

Any job (even the minimum wage jobs in the USA) will provide enough to handily cover these fees. If you're concerned about profit margins due to royalties, consider contacting us about our licensing deal for game studios I previously mentioned. We let these licensees run their own independent servers as well. Otherwise, we don't charge anything until you make a sale, and you will always hit a positive net profit even after automatic, worry-free royalty payments.

In order to put the costs in perspective, you need to know how much it takes to run an MMORPG with proper, stable infrastructure. You also further need to put things into perspective and realize MMORPG Maker XB is the first download-free web MMORPG engine - and we have patents pending to halt competition. The web as a distribution platform is superior to the desktop in every way; therefore, in most cases, you should expect more and faster growth.

I hope you weren't thinking of running a home server, but just in case you were, here it goes (and this may get technical):

Yes, there are competing offerings that offer a home server, but they've never built a real MMORPG or scaled anything significant.

If you want to compare offers, ask them what DBMS they are using to power their/your back-end. Chances are they aren't using one. So are they re-inventing the wheel? Are they delivering an inferior, unscalable product? Or do they have the resources of Google and built a BigTable on top of a GFS?

Are they using MySQL? Memcached? Redis? Oracle? Cassandra? SQL? NoSQL? Have they even heard these terms before? If they're using one of these, ask them why they chose to. If they can't explain why, they don't know the first thing about scalability.

Can you run the database on a different, separate dedicated server? Do they use a message queue? Or are they just arbitrarily blasting data to these servers? If there's a message queue, which one? Microsoft? RabbitMQ? 0MQ?

Where does their security logic sit? Do they have any security logic? Is it up to the user/developer? How well abstracted is it? What were their design principles for their security architecture? Do they know how to secure an MMORPG? I'm not talking about securing TCP/IP or UDP communications - that should be a given; I'm referring specifically to MMORPG game security. Security checks can be CPU intensive; how are they handling that?

Which parts of their design are blocking? Is there a good reason for doing so? Are they familiar with asynchronous design patterns? Do they have a protocol for testing race conditions or a set of best practices to mitigate them?

Are they load balancing? Can you load balance? Is there a single point of failure?

Do they have high performance server software? Was it built with scalability in mind? Was it built using an interpreted language? An interpreted language would be something like PHP, Visual Basic, etc. It's too slow for MMORPG servers. Is it compiled? Statically compiled or JIT compiled? Method JIT? What does it compile to? MSIL/CIL? Machine code? Are they statically linking? Dynamically linking? Why? Do they have at least a rudimentary understanding of how the compiler works?

Unlike scaling standard web systems, scaling an MMORPG requires strong front-end development skills (mainly in game programming) and an in-depth knowledge of how the specific game operates. There are back-end specialists; there are front-end specialists; however, being able to combine and excel in both in an MMORPG environment, one of the most difficult areas of programming, is a very rare and highly specialized skill which would be very expensive to contract or hire.

This only scratches the surface of the programming side of things. I can go on and on. The benefit of having us host the servers is that you don't have to worry about ANY of the above - we set it up and we maintain it; it doesn't get any easier than that and simplification for non-professional developers is our goal. Anyway, you (or they) also need to think about the business and economic side of things:

How much does the server cost to deploy? What are the fixed costs? What are the variable costs? How are they working to provide you cost savings? From a business perspective? From a technical perspective?

Do they have a contingency plan? Are they taking advantage of economies of scale? Do they have a plan for that? Does it equate to cost savings passed on to the end user? Do they have a monitoring system? How do they respond during an outage? If their answer is to reboot the systems, they don't know what they're doing.

At the very least, it should give you an idea of what we're thinking about and how much detail we go into during actual organized planning. Our competitive analyses show our competitors have not thought things through on a business or even technical level, and the vast majority of them have zero years of professional development experience and no knowledge of scalability. Can you really trust your mission-critical applications and back-end software to that - especially when our prices start at $4.95 USD/month?