MMO Development Process

Hi all, thank you for reading.

While developing and creating this MMO FPS game, I’ve obviously had an idea. Put the Idea on paper, story board, concept etc… Initially there would be a team in place, and the sections were broke up into development phases and so on. Of course, with low to nil budget, I’m completing the game with the help of the Unity Community (haha that rhymed) Anyway, Im sorta at a loss for what I should do next… This is where I would like suggestions from people who have been to this point and found creative ways around it.

So far I have a complete level, controllable animated character, weapons, affects etc… Im at a point now, where I need to write more scripts to add back end functionality to stats, damage, and so on. This is of course an MMO, and there will be a Database involved. I have very little experience scripting, and even less with databases, so that said, this portion of my project development will be a long process.

Do I begin immediate work on the Database. If so, can I make a local one with functionality for test purposes, and move it to a server later?

Do I begin setting up the server immediately and begin the process of testing through the server and server database now?

When I write the scripts, do I add the functionality of calling and submitting information to the database as I write them?

For functionality purposes… when I write the scripts, do I write one script that is applied to each bullet (or player), and each time that bullet is fired (or player fires the bullet), or hit something or whatever, to call another script that handles the entire damage, experience, points etc… system and properly puts the information in the database?

I know this is a lot, and its totally up to me in which direction I should go, but I would like some feedback to head in the best direction possible.

Thanks all!!

That’s sort of the issue. I don’t know of a single small, indie dev team, Unity or not, that has yet thought a clever way around the myriad problems that face a modern-day MMO.

If my life absolutely depended on getting an MMO out by myself, I’d focus on establishing the barebones of what an MMO is – a graphical user chat.

Logins, chat functionality and moving around on a scene from which multiple users can connect and disconnect from.

Once I had that down, I’d move to some kind of persistence – ie: users have tokens (objects, items, etc) that they save every time they log on or off.

Personally, I don’t know of a single “low to nil” budget indie team that has even gotten that far.

Forget about the elves and orks, they come later.

Here: http://www.pathofexile.com/

I agree that its not going to be easy, but It WILL be completed!!! :slight_smile: Your suggestion on what you would do first seems logical for sure. I don’t mind rinse and repeating, as this is all a learning process at the same time. Naturally with Unity’s prefabs and asset controls, I can always plug back in that which was already created. Thanks for your suggestion!

Anyone else?

Looks like an interesting game.

But how large a budget does this company really have? (Or had, when it started out) They’re definitely paying people from the looks of their ‘Careers’ page, so I’m not sure it would classify in the “nil” bracket.

Plenty of small studios (10-20) people have pushed out MMOs, but they usually had some operating budgets.

That looks great Muffin!, created low budget indie with Unity 3d?

Nope it’s not with Unity
But it is a small indie company
Admittedly they do have a huge budget :stuck_out_tongue:

But they are a small indie dev team ^^

http://www.eternal-lands.com/

2 guys, no budget, no engine.
I think that after release the team increased, but you can read the post-mortem here http://www.devmaster.net/articles/mmorpg-postmortem/part1.php

Thoroughly enlightening and entertaining read you posted scarp. Thanks for the link, and thanks to Radu for documenting his experiences.

None of what you’ve listed is “the hard part”. Sorry. Server handoff, bandwidth management, security, etc are far harder than what you have so far. If you want to get over the hardest parts, learn those. It’s good to have a story and such, but the technology is the problem.

Im diving into the server / sync now. Im quite stumped on how to create the database, where the database is stored, and so on. But we’ll get there for sure.

Thanks for the info!

There is a lot of good information on this, but basically each object is managed by one server and possibly ghosted onto other neighboring servers. To start, you’d need two servers and a boundary between them. When an object nears the boundaries, you begin ghosting; when it crosses the boundary the client traffic should go to the new server and the old server has the ghost. As the object goes further into the 2nd server, then it will no longer be known to the first server.

I guess, looking back I believe I made this mistake…

When I started the project, I believed that I would be able to tackle a few issues at a time to keep the pace and move forward. Though the Unity Community (haha made a rhyme again) has a plethora of great information, quickly I realized that the ideas and suggestions are good starting points, but by no means the answers to anyone’s problem. The one and only true answer is to dive in, make mistakes, learn, make more mistakes, read and avoid other developers mistakes and then go make some more mistakes. All the while learning.

I believe I went from, “wtf is programming” to an “OK C# programmer” in approx 6 months. Much trial and error, and still no where near others. At the same time, I went from “wtf is a server” to, “OK I have a grasp” on how it operates. “I went from wtf is a database”, and how to use it, to … “how to use it”. Yeah yeah, i know what a DB is now :slight_smile:

So again, at this juncture, I decided to STOP making my project look pretty (that’s the easy part to me) to dive into the server / database / functionality. Connecting the dots here. I suspect that in a few months, I will be past this portion and back onto making it look pretty again.

Anywho, when I can make 5+ cubes login, talk to each other, store and retrieve information on a database, I will have achieved this portion of my goal :wink: Next I will figure out how to beat up a cube in conversation, and have that information saved so that it remember that I beat down a cube and so on… Thank you Andorov, i believe you pointed me in the right direction :slight_smile:

BTW, be careful not to save players position in the database as they change every frame. Generally speaking don’t send information that change every frame to the database, because you are going to run out of connections and eventually block the DB server. Store them in a buffer and write big chunks of data in a single operation rather than each object in one sql update.
I remember back in the days wow started when the server crashed after reset all my progress was the one i had 5 mins before crash.

Ok, as I get a grasp on the database, lingo and functionality… are you suggesting to store the updates localy (buffer), and lets say after each map/level/zone, then update the database for each player id? Or perhaps store them at 5 min intervals?

Thanks

Reading or writing to a database are costly operations in terms of time and maybe cpu. In mySQL for example, writing is more expensive than reading. So the perspective of doing a sql write operation (INSERT, UPDATE) each time a character changes his position is scary.
Lets say your script updates the players and mobs/npcs positions at 1/10 of a second (bear in mind you shouldn’t update that every frame because then the traffic on the server will increase dramatically, instead you are doing it at a determined period and interpolate in between). So every 1/10 seconds you are sending a request to write something to database. Thats 10 req/sec. Multiply this with the number of users connected to your server and in a very short time you will have a flood of requests to the DB. MySQL and for sure the rest of DBs have a limited number connections allowed. Each time you do a discrete sql request a connection is created and after success it is closed. This means your server have to maintain a connection pool.

As for what data should be written immediately and which one should be kept in a buffer and only be written in DB at 1/2/3/4/5 mins (the period also depends on a great deal of factors, like how many players are on server, how important is to have the game restored after a crash, think here of normal map roaming/questing and dungeons), this decision is up to developer. For example you don’t need to keep mobs position in the DB for general maps. In case of a crash you just reinitialize the area. But player position is important so i imagine having an array of players maintained by server for each zone/room where you keep player id and his last position.Ofc you can extend this list/array/dictionary to something more complex, lets say keep the whole info of the player in the memory in a special designated class, but i somehow believe that keeping so many info which doesn’t change often is a waste of server memory. Then is going to be easy to dump the info from memory to DB in a single operation.

When designing server side code, you have to be Scrooge because server resources are limited. Not to mention you have balance between memory consumption and cpu cycles. Too much pushing of data in memory will increase the need of RAM, too much and too clever algorithms will stress the processor. But at the beginning is important to have something working than working perfectly so dont try to optimize too much. Just keep in mind that at some point you have to make it better :slight_smile:

Different MMOs have handled it in different ways, but yes. Saving the character every few minutes is very common. Saving the character at scene changes is common in offline games, but less common in online games.

hello all
i am new with unity.
i am using unity ver-3.3.
i want to use sqlite as local database in my game.
can anyone tell me thee way to do so.

here is the scripts that i am using for this.
i put them in my project/assets/plugin

718025–26036–$dbAccess.js (6.07 KB)
718025–26037–$TheDataBase.js (4.02 KB)

Great info Scarp, thank you!

To expand on what your saying and to ensure that I make a decent first move…
In a game such as “Call of Duty” lets say. I would UPDATE the player positions several times per second. But updating stats and so on can be saved locally and then “tallied” and UPDATED to the DB at match end?

This in theory would work, and according to what wccrawford is saying?

Thanks!

What do you mean by saved locally?
If you intend to use client machine for that, remember that in a client-server configuration, the client cannot be trusted.
You should not use any data sent to server by client without check it for potential abuse, better yet, your client should run only data sent by server. Think to the relation between client and server like the relation between a puppet and master puppeteer. Even so, there is plenty of room for cheating.
For example, your client is exploring a dungeon, fighting the mobs/bosses and such. You are storing the data on his computer and save it to DB when he exit from dungeon. How are you going to be sure he made 1 million gold coins and found the Sword of a thousand truths, instead of 10 gold coins and Copper Sword?