How to create a MMORPG?

Hey all. So I have been reading a lot of:
"I want to make a MMORPG", "You can't", "Sure he can", "No, it costs too much", "Oh, another noob", "Man I hate these kind of posts".

I have also found a few of these threads that actually go into WHY they say it costs too much and why it can't be done etc etc etc. Surely it CAN be done if you have the bucks and the manpower, but that is not what noobs want to hear.

How about we start this thread, and hopefully turn in into a sticky even, and highlight (not discuss) what is required to actually build a MMORPG. I for one am busy just doing my own thing but when I try to define what I am doing I have to define it as a small scale MMORPG... but then I read that if it's not massive then it's not a MMORPG. So what am I doing? I don't know :P

I have picked up on a slight confusion in terminology also and this in turn confused me also in terms of what is the difference between a MMORPG and an online multiplayer game?

For example, say you setup a VPS to host a copy of your game that will always be active and act as a central host. Now you configure Badumna to use that as the first client. Now you release your game and everyone who runs it will see each other in the same virtual world thanks to the combination of a persistent game and the networking provided by the Badumna library.

Now imagine the game has a multiplayer challenge system in it whereby teams can challenge each other to a match of (whatever) in which they are transported to another scene and then play against each other and then return to the original scene that they were in. The battles are multiplayer but the world persists while they are not there and people can connect and explore the world... heck you could even drop a few crates for people to collect to make the 'lobby' less boring... So wouldn't this multiplayer game then be more of a MMORPG than a multiplayer game?

This is purely an example, though. So why not create an actual list of what IS required to make a MMORPG so people who come here looking for someone to help them make their game can check this thead, check the list of requirements and check off what they have and don't have...

I would request that this not be a sarcastic : 'You will need a few million dollars at least' thread, but instead a 'When you start off small, you will need at least a VPS from Godaddy at $99 p/m but you will later have to get a dedicated server for around $250 p/m from GoDaddy also. if you want to host on a Mac machine then you will have to look at their $150 cloud hosting package.' thread.

Be constructive, lay out the required tools and costs and give aspiring WoW beaters a definite checklist of what they need.

I'll start the list of with what I have gathered thus far:

  1. At least a VPS when you start. I have found various VPSs ranging from 8GBP to $250 and more. Each offers something the others don't so just check around for what you can afford. If your game fails then this might be all you will need, but if it picks up you will definitely have to look at getting a dedicated server

  2. Unity's MasterServer system has not given me the experience I was after in terms of networking. On paper the idea sounds good but in reality you simply have to find another networking library. So far Badumna sounds like a good option.

  3. To store people's account info you will need to get a database installed on your VPS. There was a thread about what system works best and it sounds like Oracle is the best (??? No idea what I just typed) but it sounds like it is very expensive. Unfortunately I can't give an exact name here but I gather databases are essential. I am not sure wether something like DimeRocker would be sufficient in terms of this but it sounds like you can store your info there but speed wise it would be better to store the data WITH the server side game...

  4. Lots and lots of art work. Either create it yourself or buy from places like the3DStudio and TurboSquid. You will need as much as you can fit in to your world because there is nothing that will kill your game faster than a boring world...

Please feel free to add to this list...

1 Like

Hi ho,
a good example, that you dont need lots of people or money for a successful mmo, is cipsoft.
They created a 2D MMO more than 10 (!) years ago as students in their university.
Afaik they were 3 or 4 students at the beginning and they started off with their game. It still runs successfully:

Of course you have to mention that tibia "just" has about 500-1000 players on one server. But it's using lots of independent servers with independent instances of their gameworld.
IMO it's still a mmo, because you have really crowded cities and everything ... i think you don't even notice if there are 500 or 50.000 players one your server, because it depends on the world-size.

I think this is the way to go for indies.
Setup your rootserver with let's say a raknet server which uses SQLite for persistent gamedata and the possibility to talk to your MySQL webserver database for user-accounts.

The rest is just networking stuff and how to optimize sent and saved data.

This is the REAL problem in a MMO.
How to do things smart, fast, efficient and SECURE.
For this you have to be a real experienced programmer i think.

My 2 cent :)

Wurm online is another good example.

My definition of an MMO is a game that's online, but not match-based. I.e., when you log into a server, you're not there to play a couple matches on a single map, but to explore and fight in a complete world.

I would be very interested to see the actual breakdown of hosting costs. I haven't been interested in creating an MMO for a while, but maybe if it's not too expensive I'll start proof-of-concepting that dream MMO idea I had a few years ago...

Hello everybody

I'm development a sample project to show the concepts behind a MUD. Wich I have developed so far can be viewed in my youtube video.

I created a project named UnityMUD at google codes and I want know if I can find some help here, it is available in svn:

I'm using netbeans to program the server. The java server project is 30% (+/-) documented, it's a MIT license project.

Here's a working sample:

Open both projects, client and server, with netbeans and run server project first.

Currently I'm working with MySQL authentication system, so I'm going to use MySQL, but it could be easy to adapt the code to use Oracle, just change the part from in svn:

            conn = DriverManager.getConnection("jdbc:mysql://localhost/mud?"+

To something like:

            conn = DriverManager.getConnection(
                    "jdbc:oracle:thin:@" + (String) root.getAttribute("host") + ":" + (String) root.getAttribute("port") + ":" + (String) root.getAttribute("database"),
                    (String) root.getAttribute("user"), (String) root.getAttribute("pass"));

Btw, hostgator hosting service is better than godaddy. Godaddy is better for domain purchase.

Can anyone confirm if there is any way at all to run a headless version of a Unity game on a Linux VPS?

The way I understand it we have 2 options:
1. Get a Windows VPS
2. Pay quadruple the price for an OSX VPS

I really think it's not possible.

I'm thinking in creating a simple 2D physics in java server, and then use server and unity physics in client side, so if the client physics is hacked, it would not affect the server, just the client, because client sends only messages like "up", "down", "left", "right" to server, not real coordinates. The server sends the position of the player in 2D coordinates, then the client should know the position the player should be, if the player is not in the right position, he should walk into the right position. I'm still thinking about how Unity client will works, so I'm not sure and I have almost no unity client code.

This should be a sticky. AT LEAST

A lot of people come on and go "Omg an MMO, I would make Insert Ridiculous amount of $ Here Then they see a big brick wall of text on how to do it and go…

“Meh not worth the effort”

MMO’s are possible! With effort, dedication and hard work.

Hard work will get you the reward.

Thanks a lot for clearing the whole issue up.

Even the human brain was possible, all is just a question of time, all we have to do is start simple and keep evolving. So I'm develpoing a simple kind of graphical mud, when I say mud, I'm thinking in the early days of graphical mud, when it was not called mmorpg, so when I say mud, I mean low qualy mmorpg.

We have to start with basic network communication, don't care about all the good physics stuff in a basic mud, just a 2d tiled physics would be great. When it gets support up to 100 players, walking and chating, and a server with persistence, the first milestone will be done.

[Off]Just found a nice related youtube video

FWIW, I have been doing research on this topic during my spare time for the past 5 years, literally, trying different things out, buying models, buying art, buying music and sound effects, note my list so far shows me buying a lot of stuff, the reason is, I am a single developer, and only a developer, I have ZERO talent in all of the other categories.

Furthermore, I am now running 2 VPS servers for my game, one is a VPS2 and the other is a VPS3 (both virtual servers, thus VPS) both running Windows Server 2003, both from 1AND1, with both in total I am spending < $100 a month for the servers. Another investment that I finally settled down on was purchasing a license from ExitGames for Photon. I consider this one of my strongest assets for my game at the moment. The network backbone is built to handle the growth.. or lack there of.. for my game. That said, this poses some issues because I literally have to do the programming myself on several logical layers that is already taken care of with Unity's version of RakNet.

That cost was in the ball park figure of $1500 for Photon with the license model I choose, and it is just for 1 game and only 1 game. Honestly I have started, written, rewritten, and reworked that 1 game now at least 12 times, if not more. I am always buying code from other people here in the forums also, for items that would take me a while to do, I figure why re-invent the wheel, if someone has written it, it is good and works, I will buy it, saves me time.

Now, beyond the networking piece, the storage and retrieval of the data used in the game. This takes on a new world of meaning and no one really here has gone into the true depths to what is inside this monster and why or how it works. You really have little choice here if you think about it. The things to consider are well beyond a database.

1) maintainability
2) expandability
3) up front cost
4) long term cost
5) administration
6) expansion

That said, what or when to patch something and why.. What takes up processer power, how much and what for? What do you do about tables, expansions, corruption, backups, this list is huge. Cost is one major factor, but what goes into cost is blindingly harsh.

A few secrets:
1) databases are a PITA to maintain, although powerful, eat power to work
2) it takes skilled dba's to properly set them up anyway, let alone deal with structural changes

With that said, although you can do small games with MySQL, SQL, Oracle, DB2, etc, the question then is why. I know in other threads I mention a database to use for the games being either Oracle or SQL, but that is mainly understanding that the majority of users in these forums who begin to ask that question do not know what a database is, how it works, why it works or what it is for and if I can get them to pick up a book and read about the different systems, download them, install them, play with them and learn what a table is, how it works and how data is handled in general, then the truth to an MMO becomes clear.

Data is stored as flat files for practically all MMO's on the market in SAN's, understanding how to create tables and understanding how table relationships work will help you to understand how to use a flat file as if it was a row in a table. Backup / restoration of flat files takes nanosecond, expansion is as simple as adding another drive array with zero down time, when you add more fields, guess what, no table manipulation and your serialization / deserialization of the information doesn't change, it reads in the same old data and just appends to it any fields missing and ignores obsolete fields.

Mirroring costs next to nothing, so lets say I need to mirror my entire system from one server to another, I do not need another license from Oracle, or Microsoft, I just use XCOPY while the game is running, starting to see the big picture here?

Also, DIFFMERGE is a good tool to look for changes and you can get last date/time stamps between files along with many other aspects I can barely scratch the surface of in this long post.

Scalability in a flat file system is so easy, you can sleep through it, cost you only hardware, and the faster the drives, the faster data is returned to you and no CPU overhead. I do not think I need to go into details on storing datatable information into flat files, retrieving it and comparing load times of the data, lets just say, what you can do with a stream once you have the information in memory and what little memory it takes up compressed.. well..

man, I hate these kind of post :p

What always strikes me in these types of threads is the seeming "lack" of an overall plan/design document for what will be made. Personally, I think a "content limited" MMO is doable by a small team, or even one person if they can code and do art, or at least buy what they need of one or the other. However, I don't think ANY game type has a high likelihood of success without some plan, unless it's a copy, or the most basic of game functionalities.

I can't speak from "exact" experience, but I have worked on design projects with small to medium teams engineering for products with anywhere from 5-100 parts, to upwards of 10K parts. I've been quite successful in the past "doing things that others said couldn't be done, by myself, or by a small team. However, to do this, you NEED A PLAN.
Far more things are possible if you can clearly see/put together a plan that closely describes what the game will be like, and therefore what "tasks" need to be accomplished, for both programming and art.

It always seems that the fundamental step is missing by anyone asking (or answering) these types of questions. Which is natural as everyone wants to "jump in" and do the part they enjoy, coders start making tests of specific functions, art people make models and textures, but few seem to have the entire idea worked out to reasonable completeness.
For instance, you're already talking about networking and server costs, and yet I don't have any idea what it is you're going to make, with any specificity. Others post and ask about how to make a monster/vehicle/AI, or whatever specific topic seems the most confusing to them, and yet no one seems to have an overall design plan in place, for what most will agree is a large project that really requires one.

Here's how I'd go about a design plan, which would be an iterative (can change as things evolve) type of document.

Decide on all the "big picture" stuff, and then do a detailed list/description of more specifically what will be in the game (this eventually translates into specific art) and how it will function (this eventually translates into specific code and/or animation). It shouldn't be as hard as it sounds, as you can use any existing game(s) that is/are similar as template(s) for the "overall functionality" and then just add/make changes for what will be in your game that isn't in other games.
I'm pretty confident that if you spend a few days/weeks doing all that, you'll "at least" have a reasonably good idea of what needs to be done, and some indication of how long things will take. Then you can start picking individual tasks to complete yourself, or, maybe successfully recruit others to help because you have "specific" things you can ask people to do. I'd suspect this would help plan out what kind of tech you need (server or client side) as well.

In summary:
Hash out, in words/lists or even better, schematics, what will be in the game and how it will function, then come ask for help with something specific OR, bring the plan in, and people can try to point out specific things that need to be done, or things you may have missed.

I think for just a concept mud project we could use MySQL. Btw, if someone is going to use files, for a real mmo project, instead of a db, the best to do is implement a b-tree, almost all other algorithms ( sequential access, binary search ), will loose in performance to a db, depending on the size of the file.

If we forget all about the server costs and try make somekind of mud that could be tested by, lets say, 5 friends, each one with a computer, and each computer running 5 clients, it would be 25 clients connected to our test mud project. The main idea of the topic, in my opion, is just create a concept mmo project, not a high quality mmo project. So we could learn about: networking, chat system, battle system, data storage and retrieval, login/logout system, etc.

How about a very simple and limited "mmo", the main use cases are:

Player can login.
Player can logout.
Player can view other logged players.
Player can move ( just up, right, down, and left).
Player can chat.
Player cannot move towards other players or obstacles.
Player can fight monsters.
Player gain exp every time he kills a monster.
If player hp goes 0, he dies and disconnect from the server, he has to wait 5 minutes to connect again.
The system has to store player pos and exp when player disconnect.
The system has to retrieve player pos and exp when player connect.
The world is just a small flat map with few obstacles.
There is just one type of monster in this mmo, trolls, because trolls are funny.

Again, the main topic idea, in my opinion, is create a proof of concept mmo project, not a WoW killer.

The problem with a flat file is that when something gets corrupted you don't have a journal to roll back. Users tend to get quite pissy when they lose that fancy sword that they obtained yesterday.

Anyone who ever ran a MUD or played on a flat file driven mmo has experienced those headaches.

All of the private wow servers use some form of a free SQL. There's a lot of lessons to be learned about rolling your own MMO from those projects other than just database or flatfile. Looking through their source would be valuable.

If someone is serious about a small production game generating revenue then there are certainly budget versions of products like DB2.

Four cores is more than enough for a small project.

The major problem with flatfile is that they lack one of the most, if not the most important feature unless you invest a lot of time: true transaction based changes.

going without that is like handing out greencards for world state fuckups as every single case of a node crash could corrupt the whole datasets it was using at that time

So, MySQL is a good option, right?


I just got Unity client working with a java server:

In an older video I was trying make a Unity client:

I guess I should have stated a few more things but I tend to get a tad windy in my posts and this topic can get huge. You only need a transaction based system for players, aka saved player state, etc. You see, all of my NPC's of every kind are flat files from template files. example of a monster spawned from a template:

There is absolutely zero purpose to store that spawned creature in a database, everything that has just been created about that creature is stored in that xml file, there is a log file that goes with that xml file that is tagged as a battle log, once that creature is dead, it is dead in my system and I have a process that pulls dead creatures to a dead folder based on that date. This way I have a tool that can check the logs for any arguments as to who attacked it and what it carried.

My finance system that houses everything to do with billing is in a transactional system (SQL server 2005), I guess my point is, there is no purpose to house things like non static or volatile data in a transactional database. Even my dialogue system is flat files which allows me to have editors with one click deployment .net packages that I can have others work on and have a housing for their projects and never have to deal with the database, do you know how easy it is to check flat files for spelling errors vs having to check a database nvarchar field? First you have to extract the data from the field, run it through a spell checker and grammar checker, then update the information, then update it back in the record, this is totally bypassed by a service program that I wrote that is running on the server that looks through all of the dialogue folders and does what I need it to do using a spellcheck API.

You need to think farther outside of the box for maintainability and administration.

It make sense. I was going to put in the code all npcs, game settings, and monsters data, but creating a xml would be better, so, I will not need to recompile all my code every time I need to tweek some variable related to those classes, thanks for the advice.

No problem, I personally think the key to success for the game really does boil down to how easy it is to maintain and expand. If you use a database, here is what you are looking forward to, in the event you need to add a new field to a table, when you alter that table and save the new schema, at that moment, anyone attached to that table via a view will have invalid view results until the view is rebuilt for that attached person, now the field will contain a null initially and you have to have the field set to allow nulls when it is created. The table data for all existing entries now has that field with a null across the board.

Now you have to write a quick sql statement to do an update on that field to set a default value if you want one otherwise you have to have in your program code, a way to handle that new field with or without a value, with or without a null, and the index for that table is now invalid and needs rebuilt. But now it gets better, any routines or procedures along with triggers for that table need to be manually updated to include the new field, especially for error checking purposes, not to mention if you have anything that is transactional based against that table, all transactions are now invalid in the transaction log for that table. Furthermore, your code for the game, anywhere that you are using that table via readers and have defined your select query around the fields would have to be updated, not to mention, anything you have done for anything server specific for that table needs updated.

This however, is totally bypassed using XML reader / writer. You can write an iterator that builds up the XML based on templates that you create and is able to handle changing things without the headache of all that crap I just mentioned for the database. Another thing I use consistantly is datatable ReadXML, thats is a beautifil invention. You can use datatable.WriteXML and datatable.ReadXML or even datatable.WriteXMLSchema

The out of the box concept here, is that you can write a core system that others can maintain without touching the code. MUD's were built on this concept. Folders contained files that defined rooms, creatures, even events, all of this read from these files that can be added or modified ad-hoc without a reboot of the server or a redistribution of the client.

Also, the server will house the files, period, so this means that if some new zone is added to your game, it is like a drag and drop event, copy and paste a similar zone, do some tweaks to the files, have a switch in the zone.xml file that states whether it is in development, active, or inactive and the players can be streamed the assets of that zone when it becomes active and they get to a point where they are near it or the object of that zone trigger is now enabled. Life becomes sooo much easier.

Player maintainability becomes easier also, here is why, if you use a database for the player information, sure it has transaction level events to roll back or commit, but think of this instead, using a folder for that player account, with XML files describing the player, then xml files describing each inventory item, you no longer have to have a table for inventory, but it gets better, backups can happen with a single service routine that runs on the server that snapshots the player data folders to a backup folder on a different server, can be for all players or just one, and text documents or binary files are TINY as all get out so that means the copy is fast. Restoration, simple copy /paste and done, no transaction rollback code to need to be written.

I am still torn between using a database for player characters or not, I have written it both ways and have found that for expandibility, binary files or xml files for the players is easier to work with. Zero database modifications when I add an expansion, say I add a totally new skill tree, well, no big deal, I have a flag that can show which expansions the player ownes and based on that flag will determine which player template to use for reading the data back into the system, every player has the full schema for all the fields for every expansion, but not every player has the expansion so reading that data will depend on which expansion they get.

There I go rambling again.