Virtual world in torque

#1 1) Totally depends on your hardware specs, bandwidth, internet lag at any given point in time, how much data your game uses, etc. It's a question that can only really be answered when you start stress testing your servers.

2) For the first part, you need a master server system. For the second part, see #1.

3) Teleport as in spell? I can write a script function to do that in under 5 minutes, as all you'd change is the player position. Zoning? A bit harder, but not that hard in the great scheme of things.

4) There are functions for calling commands from client to server and vice versa. TGEA also uses HTTP objects, which you can use for backend communication.

5) Not sure what you mean. If you mean how fast will the browser-game load, then that depends on your game and how much content has to load. If you mean page switching during browsing, I see no problems.

And below is some more advice:

#2 This is my standard MMO blurb when people talk about making virtual worlds and ask "end of cycle" questions. You may find it helpful or not, but it's just mean to be helpful:


Golden Rule: Do not look for a team until it is absolutely necessary. What you should do is:

1) Understand what an MMO is: By that, I don't just mean that you should have played a bunch and know what you would like out of your own MMO, but you should read books about what it takes to create and- most importantly- maintain an MMO. That means hardware costs (more than just a "sick rig", unless you want hackers crawling up your server's wazoo at 2am while you're sleeping), software costs (server OS, antivirus, dev apps, database apps, etc), web hosting (you need a front end website), and community management (who's going to answer the help desk at 2am when the hackers turn your server off?).

That means you need to build up knowledge of the business side of MMOs, and it's not easy. It's not impossible either, so go get the books and start reading.

2) Understand what you want your particular MMO to accomplish: After you understand exactly what it takes to build an MMO, and you're still confident that you have the desire to have a go at it in an indie fashion, then it's time to sit down and flesh out your ideas.

The first thing to realize here is that this is NOT the point to go get a team. This is the point where you need to have a by-yourself-meeting and come up with a backstory for your world, the areas, factions, and what makes the world tick at a high level. Find out what kind of gameplay you want to have in the game (if you can only describe that gameplay in terms of a half-dozen games it would be "like", then you're nowhere near done). Sketch out GUIs, NPCs, weapons, towns/cities, or even scenarios. Realize also that these sketches can be horrible or done on napkins, but it helps you understand what you want.

If you don't understand what you're building, you cannot expect anyone else to build it.

3) Understand your skills: It takes more than just an idea to build an MMO, and I can tell you that there are 1000 MMOs slated to emerge by the end of 2009, all with ideas. About 95% of them will fail miserably. But by this point, you know what they go through to make those games, and you know what you want yours to be like. Now it's time to look in the mirror and see what you have to offer a team.

To be blunt, if all you have is an idea, then you'll get nowhere unless you have an idea and several million dollars. Don't be offended, but it's a fact that applies to us all, for all business ventures large and small. If you're a writer, then you can use writing to some degree to get your visions across to the team, and you can write content for the game. Better still, if you have a bit of sketching skill (and if you practice, you'll probably find that you have enough to communicate to a better artist that you'll bring on board later), or even better if you can pick up scripting and/or coding. Since we're talking about MMOs, you should also know some things about database design, SQL, installing, configuring and maintaining operating systems, and business. These last skills are must-knows.

What coding offers is that you can sit down and bend the game engine you choose to your will, or with scripting you can test out or implement gameplay features, which is invaluable if you want to be a designer. It's absolutely essential, in my (and many others') opinion. But again, you need at least one (preferably two or more) of these skills.

#3 4) Understand what game engine is best for you: So, by this point, you have a grip on the work involved in MMO projects in general, the scope of your own project in specific, and you have some skills that you bring to the table. So now look for a game engine that suits your needs. Not all game engines are equal, and no engine can be termed "the best". They all have slightly different feature-sets, and that means that you'll spent a couple of weeks comparing engines or reading their documentation to understand what they have to offer you (because just asking if they do on their forums will not yield as good information as if you understand what the docs tell you directly).

After you sort through a bunch and narrow them down, you can compare costs, licensing, and support. Then make your choice, but make it well, because if you choose to switch engine in mid-production, it may sink your project.

5) It Begins! Start scripting/coding... By YOURSELF: Seriously, you should start scripting or coding the gameplay without a team at first. Don't worry if you don't have the best graphics in your gameplay tests, as long as the gameplay is fun. Graphics will come, but icons with stick-figures, placeholder art like cubes, or "stock" art that comes with your engine or purchased for cheap can stand in for better, custom art that you bring in later.

Right now is when you need to be laying the foundation of the game. You do this without a team for as long as you can, because when you finally need a team, you'll have working features, and artists can see their assets in the game right away. If you bring a team on with no functionality to test their assets against, they'll get bored and leave!

6) You have gameplay, now you need a team! If you've done everything right, you have some skills, documents, and knowledge to attract a team, and a list of working features (maybe backed up by screenshots or vids) to show them the gameplay that they need to make look good!

Here's the business part: Make sure you have equity agreements in place, as well as NDA's for intellectual property (and that means that you better not be stealing another game for your own, or you'll get sued from here to the moon!). DO THIS RIGHT

Here's the other business part: Make sure you see 3d artists' portfolios, hear musicians' samples, read writers' samples, and get a feel for the knowledge of coders, dba's, and scriptors. If you don't, you'll get sub-standard people, and with no one to blame but yourself.

7) Get to it: So you have a team. Good for you. Get to work, and push until you hit the finish line. Don't be a dick to your team- they're probably working for free, and they'll leave you. Don't deviate from your vision, or you may get lost. And keep development communities aware of your progress, because they can be the start of your viral marketing (and be your first customers!).

8) Done! LOL. No, you're not. Now that you're ready to launch, you need to build the network infrastructure to handle it (you did network stress tests right? Load-balancing? Do you have payment software set up or are you going through a 3rd party solution? Security? Community managers?).

Launch day is the roughest, and expect lots of problems. Knuckle down and get to it. You might be awake for the next 48 hours... And then the real work of maintaining the game begins :)

There you go. It's not pretty and sounds discouraging, but if you can't take reading that, then you have no business doing this. Odds are, if you're reading this, you've made it through okay, so go back to step one and start doing it. You may fail. There's nothing wrong with that. Failure is a learning experience, and if you understand your failure and have enough chutzpah, then you might be able to take another swing at it. Or maybe you'll succeed, and I might be a customer. Who knows.

But if you just jump right at your project before you know anything about it, your odds for failing go way up.

#4 Ted, you should make resource out of that to point people to who are interested in creating an mmo out of Torque. It seems that questions regarding creating an mmo pop up quite frequently so it would be good to be able to point people to a document that answers the most frequent questions.

But, then again, if people would do a little searching they would find that all their questions have already been answered, and probably several times.

#5 @fireVein: Yeah, I think I'm going to try and submit it as a sticky for the forums...

#6 @Ted: I second fireVein, your post here should be there the first thing that pops up when someone searches for the term "MMO".

#7 Thanks a lot Ted. I really appreciate your timely support.

#8 Can anyone give me a good server configuration to host a virtual world using Torque?

Thanks in advance :)

#9 @Saravanan: You'll need multiple servers- actually, a small network, to deplot a VW. You'll need a database server, master server, zone servers (how many depends on how many zones and how many users you can fit in a zone), character servers(aka login servers).

Depending on if you went for it, you may implement clustering or load balancing, and that adds servers as well. I know that Minions of Mirth ran on something like seven physical boxes at one point (don't know what it has now).

For hardware specs, that depends on what you put in your game, so all this is pretty much putting the cart before the horse. Any game logic you add to the engine will increase your hardware needs, while any you take out lowers them. And in order for you to be able to get an idea of what you need, you would have to test your game.

#10 I don't think the server situation is quite as as mentioned in Ted's post. I'm also pretty sure that Minions of Mirth runs on a single box with multiple zone servers, character server, master server, etc on that box. Though I also don't believe it's ever had more than a couple hundred simultaneous players. It all will depend in the end on how many simultaneous players, how many entities, how fast the server, etc.

#11 @JC: I just reread Josh's blog on MoM server architecture, and it indeed shows seven physical boxes, each with a number of logical servers. This blog related to the presentation he gave at the first IMGDC in which he talked about how he was running two shards (the architecture shows 3 boxes per shard).

Your point is still correct: It can be done on one box if the player population is low enough, but that opens you up to several problems relating to redundancy and scalability (unless you build with the intent of scaling from one server to many from the start). The best way to do it is for several physical boxes to be used.

#12 You are the only person that can answer your questions.

Out of the box, Torque cannot handle more than 100 - 200 clients using the provided starter kits. Anything beyond that completely depends on your skills as a programmer and software architect.

Instead of asking us "How hard is it to do xyz with Torque?" you should ask yourself "How hard is it to do xyz?"

If you can figure out how to do it without Torque then you will be able to figure out how to do it with Torque.

The converse is true as well. If you cannot figure out how to do it without Torque then you will not be able to figure out how to do it with Torque.

Torque is not going to make things easier for you. The only thing it does is save you time.