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

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...

 

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: www.tibia.com

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...

 

http://forum.unity3d.com/viewtopic.php?t=63061

Here's a working sample: http://unitymud.googlecode.com/files/DemoMUD01.zip

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 MySQL.java in svn:

Code (csharp):

1.  
2. Class.forName("com.mysql.jdbc.Driver");
3.             conn = DriverManager.getConnection("jdbc:mysql://localhost/mud?"+
4.                     "user=root&password=");

To something like:

Code (csharp):

1. Class.forName("oracle.jdbc.driver.OracleDriver");
2.             conn = DriverManager.getConnection(
3.                     "jdbc:oracle:thin:@" + (String) root.getAttribute("host") + ":" + (String) root.getAttribute("port") + ":" + (String) root.getAttribute("database"),
4.                     (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 http://www.youtube.com/watch?v=2eslYlbe3gw

 

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

 

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:
MAKE A PLAN
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.

http://www-01.ibm.com/software/data/db2/linux-unix-windows/edition-express.html

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 F***ups 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?

Edited:

I just got Unity client working with a java server:
http://www.youtube.com/watch?v=GKfe6brdIEg

In an older video I was trying make a Unity client: http://www.youtube.com/watch?v=_Zz4Tq443tU

 

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:
Trogmog_seed_stamp.xml

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.

 

Question is : how to make a MMO? or how to make a successful MMO?

Because as I can see, all the kids coming here launching themselves in a MMO project aim at a World of Warcraft scale..

Everybody can make a MMO, like a simple Massively Multiplayer Online chatroom (lol). But kids always want to replicate something as big as the biggest thing on earth.
Unfortunately, MMO is a long term gaming model, so you need tons of regular content to make it roll.
Cherry on the cake : the MMO players want dedication to the game, long term investment and neverending endgame. Which means they will mostly play one MMO.

So in short, be the best, or die like the rest.

Imho the problem you're talking about is not knowing how to make a MMO, but how big.
And as the "MASSIVELY" in the name massively points at how big massively is, it is fair to say : the best thing we could say to kids is to stop using the term MMO until they got a 30 men team, 5 million of budget and a 3 years dev plan.

 

All fair points. I suppose if you drop the first M from the acronym then it falls into what can be done by indies. In fact it sounds sooo much more doable. "Multiplayer Online RPG". Create a full blown RPG but on a small scale...

Hell that is something I would be interested in doing. So let us focus on that then. Creating a non-first-M MORPG. What is required to set up that first MMO Chatroom? Surely that can then be expanded into a MORPG?

Making my first RPG a FinalFantasy killer or my first online game a WoW killer or a simple platformer that will make Mario old news... I think it is safe to say that noobs dream of it and some actually believe it is possible but for the most part I think noobs have a certain (unbeatable) confidence, coupled with delusions of grandeur, mixed together with some feelings of doubt and lingering thoughts of "accepting the inevitable".

So they want to want to kick Mario out of the brains of everyone who has ever seen him and come on here asking "How do I take the platformer example and make it do this?" and they get help. Then they come and ask "I want to create a MMORPG that will kill FF off for good" and everyone here seems to go: "To hell with your aspirations"

I say, show them the way, let them try, let them see how far they get. Hell, even if they get 3% done before they quit, they have learnt about programming during that time and are now more skilled doing whatever they decide to do next... Instead of helping them learn Unity when they want to do one genre and simply shoot them down as soon as they mention another genre, just show them the way once and for all...

I asked that this thread become a list of requirements, not a discussion but this has clearly become a thread for people's experience and thoughts. Can you imagine if this thread started out with me replacing my introduction with a 5 page long list of "this is what you will need"? Now Unity makes it a sticky and everyone who comes onto the forum sees this thread and quits before they even start or ask a single person... They didn't waste their time and none of us got upset about yet another thread about a noob asking for help to do the impossible.

Let us get together an extensive list of requirements, put it up for the world to see and let the chips fall where they may... that was the purpose of this thread...

If I were to ask you how to create a successful platformer that will kick Mario into kingdom come, could you give me an answer? The question is "How to create a MMO". Even Mario started as a cube running on a rectangle... Let them start off with a chatroom and build the Final Fantasy killer... or give up... their choice, their problem... but HOW to do so... that is the burning question... What is required to begin ? THAT is the main question...

 

N0mad:

Not to burst your bubble on "massive" games:
As of 2006, Dragon Realms was 10 years old
http://www.play.net/dr/news.asp
Thats right, 1996 the game was released and is still going strong. Creator started out, if I recall, as a single person on a mission to make a cool game.

There is more history about the creators of that company, and s child prodigy but based on your post, you have no faith or belief that some kid can come along and make the next best thing unless they have tons of money and tons of people.

I do not recall the full history that was told to me about the owners, or the first game that went live, but the fact is, that company is now making money hand over fist, has a strong list of products and games, and it all started out because 1 person had the idea, made a game, and went massive, everyone else came later.

 

@n0mad

I think the best is break these question into smaller ones, and assign some priorities to all formulated questions. The first question we need to break into smaller question is "how to make a MMO", so, we can break into something like:

How to create an UDP chat server/client?
How to create a login system to that UDP chat client?
How to create commands based in chat text?
How to create commands based in a byte array?
How to convert a byte array into variables?
How to create a character in the server and control him in the client using UDP?
How to create a MUD?

And so on... After all question about creating just a simple MMO was answered, we can start the list about "How to create a successful MMO".

Btw, Could somebody check what I'm doing, here's the svn: http://unitymud.googlecode.com/svn/trunk/ , here's a youtube video: http://www.youtube.com/watch?v=_Zz4Tq443tU

 

My post was not meaning that I have no faith until reaching a 30 devs studios, but that doing something "massive" requires massive resources
And that it's selfish for one kid to consider himself being massive, indeed.

@Zumwalt : your example wasn't massive at first, but became
productions resources scaled gradually, which is not the same as the "I want to make a MMO now ! " we're talking about.

Well sorry I don't want to hijack the thread as MrDude said, so I won't go further

Anyway only one stuff can be massive.

The Junglist !

 

Ohhhhh.... seems my words don't convey my intentions clear enough and I am beginning to upset some people... Not intended. Nomad: Anyone who posts images of da G has GOTs to be wicked, ahhhhaijt?

But to get back on topic again:
TimViana has started pointing this thread in the direction I intended it to go with his last post. (Although I wish he would stop with the MUD already cause every time I see that word I think of the old text based adventures where they explain the scene to you in words and wait for you to type in a command before explaining to you where you are... uggggh! Can you just imagine using Unity to write a text based adventure with 0 graphics in 2D or 3D? So yeah, i really wish he would write MUD in a way that I can't see it any more )

(p.s. Yes, I have read and understand that his is a 2D game, it's just a personal connectation with the word MUD... It's just me )

If those kinds of answers could be posted here and more be added on to then I think this thread is going to become a major resource.

Okay, so I think you guys understand what this thread is about. I am not going to jump in after every post and correct you for not staying on topic. I started this thread so people who know can help those who want to learn. Since I only know what I have already said in my first post, I am going to end my contributions here also as anything else I add will be nothing more than chatter distracting from the purpose of this thread.

Ta

 

All MMO's are nothing more than a MUD with a graphic interface. They even include a text parser!

If you want to learn how to implement networking for your MMO, how to develop data structures for a spell system, equipment handling, etc...then there exists no better resource or reference than a MUD.

p.s. They're especially handy when learning as they compile clean in osX when using the bsd makefile.

 

I'm just waiting for 'File/New Project/MMO...'. It should be in the free version though, then it would be a great advertisement for Pro.

 

This is the point, the best way to start learning how to create a MORPG, Multyplayer Online RPG, is learn a little about MUDs, you will not loose anything if you try understand how MUDs works before trying to create your MORPG, let's assume we are trying make some tinny MMORPG, so we can call this MORPG. We will not create a text MUD with Unity, of course not, we will create a kind of graphical MUD, so we can see the software architecture of a MUD to help us solve the question, "How to create a MMO?".

This is a feature request for Unity 4.0, let's wait David Helgason do some magic about this.

 

http://www.escapistmagazine.com/videos/view/extra-credits/1906-The-Future-of-MMOs

This video is about the future of MMO's and about how they are designed and made today. Interesting stuff and very important information to any MMORPG or MMO game designer.

 

Hi

I watched this video, it basically says that the future of MMOs is the exploration of other genres, like a MMO FPS, MMO puzzle, and so on, also it talks about small MMORPGs as a possible solution to compete with bigger ones, and how is difficult to compete with the big developers in the MMORPG biz.

 

Good synopses however it also covers about why WoW is popular and how difficult it is to grab part of its user base. Also, it explains why it is so difficult to get into the MMO biz as an indie.

 

Indeed, there's also good comments in that video about MMOs.

 

Question is, are any of those wanting to make the next WoW going to take any of the points made in that video seriously? Or just dismiss it as "well that doesn't include us cause we're srs bsns"?

 

I just want to comment that I think this thread is not for whose that wants to create the next WoW, is just for the people that wants to learn the basics about online multiplayer game development.

 

The starting point for any mmorpg is to start.
Doesnt madder what or where.
It is true most people come on the forums and say where do I start to make an mmorpg or try to build a team.
We tell them either give up or "Start Small"
Really what we mean by start small I think is to just start, start with something very simple like getting your camera to work. Then move on from there.
Most people wont even start if you tell them start with something as simple as that. They may say well lets start with the multiplayer part of mmorpg, the "hardest part". Well when they have no experience they may as well give up. They dont want to take the time to build something small and learn slowly.
Really you can start anywhere, the hardest part is getting out the door and just starting.
What I think is most parts of the mmorpg are easy but when it comes to online/multiplayer/database it becomes hard. There is no full how to start the multiplayer part of mmorpgs and thats what most people need, the people who are going to stick with the project already have a clear vision and something to show and have made a few games or something before but get stuck on mmo.
All the brains on the forum need to not just say ok start with a database and your networking in a generalized way, what you need to do for pretty much everyone is say start anywhere but when it comes to networking do this and exactly this.
Now I realize that most mmorpg games are different and require many different things however if you "the brains of the forum" make a starting list and starting tutorial that is extremely well documented for the mmo part this would be the ultimate.
I guess what I am trying to say through all this rambling is this: Doesnt madder where you start, just start, however if you start with networking your S*** out of luck. That is until one of the "brains of the forums" makes a complete how to do networking for mmorpg and either sells or gives for free. The rest of mmorpg is easy. You dont need to know much to pickup blender and start modelling, you dont need much to start with unity and drag and drop a camera.
You do need a crap load of knowledge to start with networking.

Dang I am really terrible at trying to convey what I want to say.

Anyway I would pay for a how to network/database/all that stuff for mmorpg and im pretty sure a ton more of people would because that is the only true hard part or the part that takes the most knowledge to start.

The rest you can start without needing a great deal of knowledge.

Gosh I really hope you guys read and understand what I am trying to say.

Having a full list of where to start to make an mmorpg is pointless. If you cant make a simple single player game then its pointless to try an mmorpg.
I think most people if they have not already done so is to start by making a single player game. Then once you have something that is really decent and you want to further you game into an mmorpg. You then must seek advise on how to make an mmorpg and thus how to start in the networking side of making an mmorpg.

 

I was talking about the video, as I kinda hinted at when I said video, not thread.

But the same applies to this and other threads. Go up to any random person and ask them what an MMORPG is, and the majority will say World of Warcraft. Because, as the video points out, it's become so darn successful that others don't get a look in, and as far as most people are concerned, MMORPG = WoW. Even the mighty Everquest or Ultima rarely get mentions anymore, and the previously mentioned MUD's are scoffed at and ignored due to them being text based.

I would say the first step to making an MMO would be to snap the person out of the mentality that ALL MMO's have to be like WoW.

It all comes down to three things

1) They think it's easy money
2) Playing God
3) Think they can do better

1) They think making an MMO will make them megarich.

2) People seem to have the need to "be the leader", look at how many extra pointless IRC channels crop up because everyone wants to run it their way. Or forums. You'll always find lots of little forums about the same subject, they rarely last long, or contain much of anything. You'll see tons with lots of admins and moderators, but no content. Same goes for many online game servers, lots of private servers for WoW too, lots and lots of them, so many of them empty except for the leader.

The one thing most of them have in common, is none of them know what to do once they are the leader.

http://www.poemhunter.com/poem/the-leader/

3) So many clones, copies, remakes and attempts. Where individuals think they can do better than the pros at their own game. Case in point, tell someone wanting to make an MMO to do one like Runescape and they'll laugh at you, call it childish and crappy looking, because they think they can do better. Five minutes later they'll be asking how to do the most basic things.


Notice the MMO's that have survived in some way, were never intended to be what they became. They either began life back when nobody really knew what an MMO was, or just got lucky by being there at the right time. Or they started small and just "happened" over time.

Notice those that didn't survive, were the ones going outright from the start to be "an awesome MMO that would take the world by storm". These days everyone is making an MMO, the market is already oversaturated and there's always more on the way. Will any of those last? Probably not.

The video made a good point about how people will often just play one MMO and invest their time in that. To drag someone away from something they practically live and breath, and have paid a lot of money on, is difficult at best. These things are addictive enough to destroy relationships, even provoke people into killing others. So realistically, what are the chances of an amateur MMO getting noticed in a sea of far higher quality MMO's, when even those will last a couple of years tops before being shut down.

 

Some code snippets about networking that I think would be useful for some client/server testing.

How I would connect to a server using UDP protocol (C#):

Code (csharp):

1.  
2. ...
3. public string IP = "127.0.0.1";
4. public int port = 4445;
5. Socket mListener;
6. ...
7. // Our socket will use UDP protocol
8. mListener = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
9.  
10. // Server IPEndPoint
11. IPEndPoint end = new IPEndPoint(IPAddress.Parse(IP), port);
12.  
13. // we need to set a timeout when using function receive
14. mListener.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReceiveTimeout, 2000);
15.  
16. // connects to the server
17. mListener.Connect (end);

How we send/receive messages to/from server:

Code (csharp):

1.  
2. ...
3. // an array of char that will be our received bytes
4. byte[] receiveBytes;
5. ...
6.  
7. // I use memory stream to create an array of byte that will be sent to the server
8. // This class has Write method that is useful when dealing with byte arrays
9. // All this code can be put inside a loop that will keep sending/receiving data to/from the server.
10.  
11. MemoryStream stream = new MemoryStream ();
12. using (BinaryWriter writer = new BinaryWriter (stream)) {
13.             writer.Write ((byte)0);
14.             // nameB is an array of bytes
15.             writer.Write ((byte)nameB.Length);
16.             writer.Write (nameB);
17.             // use writer.Write to put more bytes in our byte array that we will send to the server
18.             ...
19.  
20. }
21.  
22. // the byte array we will be sent, we convert our MemoryStream to byte aray
23. byte[] bytesB = stream.ToArray ();
24.  
25. // sends the byte array
26. mListener.Send (bytesB);
27.  
28. So we receive the server response, it timeouts in 2 seconds
29. receiveBytes = new byte[1024];
30. int flags=mListener.Receive(receiveBytes);
31. // Here you will start parsing receiveBytes and updated our world with this data
32.  

Here is some code snippets to use in a Java server:

Code (csharp):

1.  
2. // We will use UDP in our server, so we use DatagramSocket
3. protected DatagramSocket socket = null;
4. // The max size of a received package
5. private static final int RECEIVE_SIZE = 517;
6.  
7. ...
8. //Creates the socket
9. socket = new DatagramSocket(4445);
10. socket.setReceiveBufferSize(RECEIVE_SIZE);
11.  
12. ...
13. // This can be put inside a loop
14. byte[] buf = new byte[256];
15. // receive request
16. DatagramPacket packet = new DatagramPacket(buf, buf.length);
17. socket.receive(packet);
18. // variable packet has packet data, packet.getData(), and some more others information like packet.getAddress()
19. ...
20. // Do something with the received packet
21. ...
22. // sends a response to the client
23. // response is a byte array
24. InetAddress address = packet.getAddress();
25. int port = packet.getPort();
26. packet = new DatagramPacket(response.array(), response.array().length, address, port);
27.  
28. socket.send(packet);

 

Great post, Oblivionfeet.

 

But what if.......
Back to the OP point, and combining all the other points, how about a MUD converted MMORPG that enables players to either be a player or a GM, ok, how cool is that? A channeled hierarchy design that takes the concepts of a MUD architecture for ease of build and maintainability, merged into a game where it uses a master server for people to join existing games in progress, OR create their own world!

Where on earth would a crazy idea like this come from anyway? Back in the day I was a Half-Life Counterstrike geek, until people started allowing BOT on their game servers, then later patches were put into place to kill those code segments, BUT there was always "official" game servers going along with player made game servers... where the rules of reality mix with the rules of some psycho kid and a computer in a closet.

So wait a second, isn't or wasn't counter strike an FPS MMO?? your sure shooting it was, it was massive, it had thousands of players playing it daily, just not all on the same box's, and you know what, it was successful do to the fact that anyone could run a server and run their own maps / worlds.

HOHO says the neighbor, idea has a light bulb on it! Unity, native networking, max 50 players per game, servers have their own player stores and wala, instant success. I bet after this post in the next 365 days, a game like this will exist.

 

Sounds like a similar approach to Neverwinter Nights. Although NWN I believe had a far smaller player cap than the 20-100 people you would find on your average mud.

In terms of the topic of using a mud to use as a reference for learning I would suggest Circlemud. It's was by far the cleanest and most minimalist codebase around.

www.circlemud.org

When osX first came out back around 2000 or so, the first thing I did was drop to a shell and compile circlemud to see if it really was Unix under the covers!

 

+1 on the Neverwinter Nights reference. Many users called it a "mini-MMO engine", and with good reason; it allowed you to build and host your own persistent world for your friends. NWN had a 64 player cap, but some creative modders managed to create external database hooks and link multiple servers together.

Doing a MOG (Multiplayer Online Game) instead of a MMOG is indeed a lot more realistic, both for the developement and for the infrastructure. It's more approachable for the players as well because, as it's been pointed out in the earlier posts, a lot of people like to be in control of their own virtual space, no matter how small it is.

 

Even with a player cap of say, 100 players, allowing the players to be able to start their own server, add rules to it, and use existing assets within the game to build up zones could in theory, end up becoming an impromtu MMO over time. A few things that would need to be in the initial engine would consist of:

1) Login system to a local, simple to understand and use database, but instead of a database since the average Joe has not a clue what a database is, would be a simple XML system where all tables are XML files, since we are talking a max of 100 players, this is fast enough.

2) Keep it simple, like 4 classes, mage, cleric, fighter, thief

3) 4 player models, one for each class, maybe 10 animations a piece, couple for movement, couple for attack, couple for defense, idle and die, or something like that

4) Basic models for a town, maybe 2 or 3, simple, nothing hard, basic low poly, free be's

5) Dungeon pieces, like simple skinned walls, floors, ceiling, doors, a single treasure chest model, maybe torches for walls, nothing too fancy, just some plugable items and an editor to throw a dungeon together

6) A static set of say 10 terrains with some open space for them to place the models for the town and a model of a dungeon enterance.

That would about to it I think, at the very least, an editor for building the world would need to be created, a server and a client. The client would be consistent, no one would be able to change the code of it that has the game, same for server and editor, they would have to use the editor to build the world, give out the client for free to anyone playing their game and run the server on some hardware.

Using Unity's Resource.Load and XML files definig the position of the objects from the game editor, that would make the games expansion, well, infinite.

Just some random thoughts.

 

I'd say it's essential to add some sort of scripting engine to your list, zumwalt. MUDS of course had dg_scripts, but there are some far better options these days.

The only problem I foresee with your idea is dilution.

There were once like 10 muds on the internet each with 100 players. Then the internet exploded in the early 90's. There were suddenly 400 muds, each with like 5 players.

Better be able to sort by population with your UnityMud's master server!

 

Leave that up to the master server player count, I look at it this way, if the game works and the players have > 1 player on their server, it is a success. Remember the movie "Core", don't try to save the world, just save 3 people. Imagine the world does not exist and the only people you want to play with are your friends (well crap, I better make that 1=1 for me then LOL, oh wait, I have my bots...)

I have started to sketch out a web based account generator for an example project, the idea is, the web server and the game server are the same box, or read from the same datastore in any case, at least for a demonstration on how this concept would work. Example XML for the player could be as follows:

Code (csharp):

1.  
2. <?xml version="1.0" standalone="yes"?>
3. <xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
4.   <xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:MainDataTable="PlayerDB" msdata:UseCurrentLocale="true">
5.     <xs:complexType>
6.       <xs:choice minOccurs="0" maxOccurs="unbounded">
7.         <xs:element name="PlayerDB">
8.           <xs:complexType>
9.             <xs:sequence>
10.               <xs:element name="ID" msdata:AutoIncrement="true" type="xs:int" />
11.               <xs:element name="Character" type="xs:string" default="" />
12.               <xs:element name="Name" type="xs:string" default="" />
13.               <xs:element name="Password" type="xs:string" default="" />
14.               <xs:element name="Banned" type="xs:boolean" default="false" />
15.               <xs:element name="Active" type="xs:boolean" default="true" />
16.             </xs:sequence>
17.           </xs:complexType>
18.         </xs:element>
19.       </xs:choice>
20.     </xs:complexType>
21.   </xs:element>
22. </xs:schema>
23.  

This of course could be created, read and written to by a single class to handle the database work, just sketched in about 3 minutes, sleepy so might not touch the code again until late tomorrow, but as follows

Code (csharp):

1.  
2. using System;
3. using System.Data;
4. using System.Configuration;
5. using System.Linq;
6. using System.Web;
7. using System.Web.Security;
8. using System.Web.UI;
9. using System.Web.UI.HtmlControls;
10. using System.Web.UI.WebControls;
11. using System.Web.UI.WebControls.WebParts;
12. using System.Xml.Linq;
13.  
14. /// <summary>
15. /// This class handles our loading and saving to XML
16. /// </summary>
17. public class dbHandler
18. {
19.     // folder to store and get our XML
20.     private string storePath = System.Web.Hosting.HostingEnvironment.MapPath("~/App_Data/");
21.     // different data files listed here
22.     private string playerData = "playerdb.xml";
23.    
24.     // to keep things simple, lets just use datatables and load/save xml from it
25.     private DataTable dtPlayerDB = new DataTable("PlayerDB");
26.     // columns that are in our dtPlayerDB, this defines the table structure
27.     private DataColumn dtPlayerDB_ID = new DataColumn("ID"); // unique ID, seed 0, incriment 1
28.     private DataColumn dtPlayerDB_Character = new DataColumn("Character"); // character name
29.     private DataColumn dtPlayerDB_Name = new DataColumn("Name"); // persons name
30.     private DataColumn dtPlayerDB_Password = new DataColumn("Password"); // password
31.     private DataColumn dtPlayerDB_Banned = new DataColumn("Banned"); // true or false
32.     private DataColumn dtPlayerDB_Active = new DataColumn("Active"); // true or false
33.    
34.     /// <summary>
35.     /// Constructor for our database handler class
36.     /// </summary>
37.     public dbHandler()
38.     {
39.         if (!System.IO.File.Exists(storePath + playerData))
40.         {
41.             // in the evfent that this is a new setup, meaning that the XML files are missing
42.             // we need to run the defaults method, otherwise load in the tables as needed only
43.             setup_dtPlayerDB_Defaults();
44.             Save_dtPlayerDB_Info();
45.         }
46.         else
47.         {
48.             // file aready exists, read it in, note, when ever we save something to it
49.             // unfortunately we need to read it in before writing it back out with changes
50.             // that said, we need to make this CHARACTER specific otherwise we could run
51.             // into conflicts, it is best to use real databases otherwise
52.             Load_dtPlayerDB_Info();
53.         }
54.     }
55.  
56.     /// <summary>
57.     /// destructor for our database handling class
58.     /// </summary>
59.     ~dbHandler()
60.     {
61.  
62.     }
63.  
64.     private void setup_dtPlayerDB_Defaults()
65.     {
66.         dtPlayerDB_ID.AllowDBNull = false;
67.         dtPlayerDB_ID.AutoIncrement = true;
68.         dtPlayerDB_ID.AutoIncrementSeed = 0;
69.         dtPlayerDB_ID.AutoIncrementStep = 1;
70.         dtPlayerDB.Columns.Add(dtPlayerDB_ID);
71.  
72.         dtPlayerDB_Character.AllowDBNull = false;
73.         dtPlayerDB_Character.DataType = typeof(string);
74.         dtPlayerDB_Character.DefaultValue = string.Empty;
75.         dtPlayerDB.Columns.Add(dtPlayerDB_Character);
76.  
77.         dtPlayerDB_Name.AllowDBNull = false;
78.         dtPlayerDB_Name.DataType = typeof(string);
79.         dtPlayerDB_Name.DefaultValue = string.Empty;
80.         dtPlayerDB.Columns.Add(dtPlayerDB_Name);
81.  
82.         dtPlayerDB_Password.AllowDBNull = false;
83.         dtPlayerDB_Password.DataType = typeof(string);
84.         dtPlayerDB_Password.DefaultValue = string.Empty;
85.         dtPlayerDB.Columns.Add(dtPlayerDB_Password);
86.  
87.         dtPlayerDB_Banned.AllowDBNull = false;
88.         dtPlayerDB_Banned.DataType = typeof(bool);
89.         dtPlayerDB_Banned.DefaultValue = false;
90.         dtPlayerDB.Columns.Add(dtPlayerDB_Banned);
91.  
92.         dtPlayerDB_Active.AllowDBNull = false;
93.         dtPlayerDB_Active.DataType = typeof(bool);
94.         dtPlayerDB_Active.DefaultValue = true;
95.         dtPlayerDB.Columns.Add(dtPlayerDB_Active);
96.     }
97.  
98.     internal void Save_dtPlayerDB_Info()
99.     {
100.         dtPlayerDB.WriteXmlSchema(storePath + playerData,true);
101.     }
102.  
103.     internal void Load_dtPlayerDB_Info()
104.     {
105.         dtPlayerDB.ReadXml(storePath + playerData);
106.     }
107. }
108.  

 

I agree 100% with that zumwalt. A MUD has a different feel altogether than most MMO's. You're not a fish in the sea, you can actually make a name for yourself in that size of a community. It's a more personal feel and far more enjoyable.

It's not the horde or alliance, the various factions of Warhammer you hate...It's that damn thief Fozymodo who just backstabbed me and looted my corpse again!

However I think that MrDude is looking for MMO sized resources and not something in the MUD range. While they certainly would share like 99% of the same internal structure I don't think Unity itself as a server would cut the mustard!

You should however fork a thread, as I think UnityMUD is a killer idea.

 

MUDs were different than MMOs.

Just out of curiosity, does there exist a tutorial for making a MMO?

 

At the moment, there are no MMO tutorials. I think what MrDude is really looking for, is for the community collective knowledge to shine through and people with different backgrounds simply contribute what they know to the thread and give examples of that knowledge to help to build some sort of MMO framework, or core shell that give new people an idea of what work is involved in the begining. Although I could be off base on that assumption. As it is, MrDude is extremely talented.

 

Could it be useful to compile a list of the following, which might better show what they have in common, and their lifetime (for those that didn't last)

Something like:

AAA MMO's
Indie MMO's
Newbie MMO's

And also a special section for the following.
Social network MMO's (think Mafia Wars)

To categorize them, and list other useful information, such as payment scheme, how long the MMO survived. Estimated number of users and so on.

Please note, the term "newbie" in this sense is not meant to be derogatory in any way. I simply view an Indie MMO as one which has some capital at least, a registered company, investors etc, while a newbie MMO would include those that want to run their MMO's on a home computer or other unsuitable system, and have little to no budget.

I think something like that could be interesting. Also it would be nice if people who've actually MADE an MMO (not thought about it, but actually finished one and made it public) could chime in with their experience. Specifically those in the Indie and newbie sections. Because we've got lots of it's easy, and lots of it's not, comments. But where are all the completed newbie MMO's if it's so easy? Surely with people wanting to make them for the past few years, there must be some out there by now, right? If it's that simple? Off the top of my head, Sherwood is the only one I can think of, but I'm unsure if that one should perhaps belong in the Indie section.

 

I'm developing a server with these features in mind:

Language: Java.

Networking: UDP.

Two database options - javadb, for a embbed database, doesn't need any kind of installer process. MySQL, needs install, but can be used with php, think in a web page that can query the server MySQL.

Support to ini settings files.

Support to xml data files.

Support to groovy scripting, I will use to control NPCs dialogs and monsters AI.

Separated threads for network code and game code.

Login system.

Save system.

The development of the following features needs to be started.

Chat system.

Shop system.

Battle system.

I plan to make a tool to update items, monsters and npcs data.

Here is the svn: http://unitymud.googlecode.com/svn/trunk/