MMORPG design and problems!
by Pierre (DragoFire) Hay · in Torque Game Engine · 02/11/2005 (2:01 am) · 8 replies
Hi all,
I'm in the "look at engine options" mode, for an upcoming MMORPG. So far I've looked a number of possible engines, some including all the "bells and whisles", others just the "bones", with prices ranging from $0.00 to $1mil + royalties.
I'd like to hear some desent feed-back on what others have found.
As I reqire support for a "very" large map(basically a true world map) made up of 16x 10,000x10,000x16 image maps, so I've been reading though topics about large maps and the such.
And looking at an multi-server setup to support key features of the game with fail-over support, to reduce the amount of down time(if a problem happens).
There will be need later on to intergrate full 3d travel/placement into the game, there-by making it a multi-format game (ground based external and internal, air based, and space based external and internal).
At the moment, I'll looking at Torque as a test-bed to test out the key features, and bug hunting. And then select a plan of attack for the final release, whether to stay with Torque, buy a better per-made client/server product, or build a complete new engine to meet the requirements I have.
I look forward to any worth while feed-back to help me make a choice.
I'm in the "look at engine options" mode, for an upcoming MMORPG. So far I've looked a number of possible engines, some including all the "bells and whisles", others just the "bones", with prices ranging from $0.00 to $1mil + royalties.
I'd like to hear some desent feed-back on what others have found.
As I reqire support for a "very" large map(basically a true world map) made up of 16x 10,000x10,000x16 image maps, so I've been reading though topics about large maps and the such.
And looking at an multi-server setup to support key features of the game with fail-over support, to reduce the amount of down time(if a problem happens).
There will be need later on to intergrate full 3d travel/placement into the game, there-by making it a multi-format game (ground based external and internal, air based, and space based external and internal).
At the moment, I'll looking at Torque as a test-bed to test out the key features, and bug hunting. And then select a plan of attack for the final release, whether to stay with Torque, buy a better per-made client/server product, or build a complete new engine to meet the requirements I have.
I look forward to any worth while feed-back to help me make a choice.
#2
02/13/2005 (11:14 am)
TSE (currently in Early Adopter release mode, and at milestone 1 of 5, with milestone 2 expected in the next month or two) would be your best bet in my opinion for terrain sizes that large. By design, TGE uses a smaller terrain map (2k x 2k is what most people have the most success with), and then tiles the terrain itself for larger play areas.
#3
02/13/2005 (11:22 am)
Stephen do you know what the largest number of tiles that anyone has done?
#4
In TSE, as far as I am aware, "tiles" aren't the ways things are done (that's simply a guess by the way, no technical details have been disclosed publically--I can only guess that there would be additional information in the private TSE forums available to those who purchased the TSE early adopter release). It appears that Ben Garney has used an entirely different design for terrains in TSE, but again, that's a guess.
There are projects that have implemented true terrain tiling within TGE, but it is a very extensive process, and requires strong knowledge of dozens of subsystems within TGE. To my knowledge, no one has released publically any information about how many tiles they have set up.
I'd also like to point out that there is a design team working on a "MMOG Starter Kit" that is intended to work with both TGE and TSE that provides a lot of MMOG specific functionality (specifically multiple game servers, and probably load balancing of some sort, although specific details aren't available at this time) that will be a great benefit to MMOG developers using TGE/TSE in the future. Be advised however that this project is just getting started, and it will be a long time before it will be available to the public.
02/13/2005 (11:28 am)
In TGE? Stock TGE, you can only do 1 "tile" in a particular mission. However, as I mentioned, buy default that tile repeats endlessly, giving you a repeated set of "tiles" that allows the player to move to the limits of your mission area (or floating point precision, whichever becomes limiting first).In TSE, as far as I am aware, "tiles" aren't the ways things are done (that's simply a guess by the way, no technical details have been disclosed publically--I can only guess that there would be additional information in the private TSE forums available to those who purchased the TSE early adopter release). It appears that Ben Garney has used an entirely different design for terrains in TSE, but again, that's a guess.
There are projects that have implemented true terrain tiling within TGE, but it is a very extensive process, and requires strong knowledge of dozens of subsystems within TGE. To my knowledge, no one has released publically any information about how many tiles they have set up.
I'd also like to point out that there is a design team working on a "MMOG Starter Kit" that is intended to work with both TGE and TSE that provides a lot of MMOG specific functionality (specifically multiple game servers, and probably load balancing of some sort, although specific details aren't available at this time) that will be a great benefit to MMOG developers using TGE/TSE in the future. Be advised however that this project is just getting started, and it will be a long time before it will be available to the public.
#5
I'd would be interested in more details on TSE, but as you say no-one has said much about it's features.
02/13/2005 (12:01 pm)
Times not a major problem at the moment, as currently fine tuning database, then working on models and textures. So if I get an engine at the moment it'll be just for basic testing proposes, e.g. weapon fire, effects, vehicle movement/handling, etc...I'd would be interested in more details on TSE, but as you say no-one has said much about it's features.
#6
From the tech base you've posted, it looks like you'll have to make some massive modifications to any engine that you utilize. Have you sat down and scoped out necessary features versus desired features versus kitch features? For example, in 99% of the games I've played in my life, I'd have to say that physics is the biggest kitch feature available. Unless it is a game like pool or bowling or Half-Life 2 or Resident Evil 4 (finally a use for ragdoll physics...to knock one character into other characters semi-realistically), they haven't been necessary. They're less necessary than glow-shaders, which are commonly used to show items that people can use versus decoration. Most driving simulations only have the base physics necessary, and usually they're good enough (though I often wonder why changing to a grass texture slows your car down exponentially more than driving across grass would in the real world). Physics, while interesting from the tech perspective, has been one of the most useless features in games for a long, long time. I'm glad that Half-Life 2 gave them a reason for being in the engine, unlike most games out.
How do you want to handle streaming world data? Will NPC, vehicle, character paths cross chunks gracefully? Will moving between wide-open grasslands move quickly, but a sprawling metropolis teaming with NPC's and vehicles and pathfinding and scheduling data slows to a crawl. Where are you willing to sacrifice performance for features?
AFAIK, Ben's been working on more accurate view culling for long/short distance rendering and huge mission sizes rather than streaming terrain/missions. With something the size of what you're looking at, I'd say that coming up with a streaming solution is necessary, but is specific to your implementation since you'll know the scale of the project and adjust accordingly for load-balancing issues. But then, it's been a while since I've seen this referenced so my memory may be shooting Ben in the foot.
Torque wasn't designed with MMOGaming in mind, but it can be used to create MMOG's. But it will taked talented and dedicated programmers wih a load of network, threaded programming, and CPU balancing development experience. Systems programmers used to creating processor scalable programs would be extremely beneficial.
02/13/2005 (2:09 pm)
If you have the capital for the million dollar plus engines and hundreds of thousands of dollars worth of failsafe hardware for the back end, then that might be a good direction to go. Most of the engines have a strong support base as well as partnerships with existing publishers. Unfortunately, they either want your pie for themselves or they wouldn't touch your pie because the MMOGaming market is up in the air right now.From the tech base you've posted, it looks like you'll have to make some massive modifications to any engine that you utilize. Have you sat down and scoped out necessary features versus desired features versus kitch features? For example, in 99% of the games I've played in my life, I'd have to say that physics is the biggest kitch feature available. Unless it is a game like pool or bowling or Half-Life 2 or Resident Evil 4 (finally a use for ragdoll physics...to knock one character into other characters semi-realistically), they haven't been necessary. They're less necessary than glow-shaders, which are commonly used to show items that people can use versus decoration. Most driving simulations only have the base physics necessary, and usually they're good enough (though I often wonder why changing to a grass texture slows your car down exponentially more than driving across grass would in the real world). Physics, while interesting from the tech perspective, has been one of the most useless features in games for a long, long time. I'm glad that Half-Life 2 gave them a reason for being in the engine, unlike most games out.
How do you want to handle streaming world data? Will NPC, vehicle, character paths cross chunks gracefully? Will moving between wide-open grasslands move quickly, but a sprawling metropolis teaming with NPC's and vehicles and pathfinding and scheduling data slows to a crawl. Where are you willing to sacrifice performance for features?
AFAIK, Ben's been working on more accurate view culling for long/short distance rendering and huge mission sizes rather than streaming terrain/missions. With something the size of what you're looking at, I'd say that coming up with a streaming solution is necessary, but is specific to your implementation since you'll know the scale of the project and adjust accordingly for load-balancing issues. But then, it's been a while since I've seen this referenced so my memory may be shooting Ben in the foot.
Torque wasn't designed with MMOGaming in mind, but it can be used to create MMOG's. But it will taked talented and dedicated programmers wih a load of network, threaded programming, and CPU balancing development experience. Systems programmers used to creating processor scalable programs would be extremely beneficial.
#7
So one server could host 4 external map sections, and 4 servers might host one city map section (including the nearby external map area, eg 1-2km radius outside of city limits).
I think this is do-able!
As for physics, yes plan to have a detailed physic system running client side. It'll include correct terrain movement mods(eg. gradule increase of drag on vehicle movement, depending on terrain).
So vehicles leaving a concrete road will have a decrease in speed over time depending of terrain and vehicle type(eg. entering grass will have slow if entering at high-med speed(but verylow handling), a little faster at low speed(but low-med handling), entering mud will decrease speed faster and handling would be worst for wheeled vehicles, tracked vehicles would be different again).
As for a team of programmers, I do have few very good group, but will be looking for more as time goes on.
02/13/2005 (3:23 pm)
I have idea's on the streaming world data, basic idea is to monitor the number objects(player character, NPC, vehicle, etc...), and if the number increase above 1k within a set area controlled by an server, then it'll slip across to another server(basic load balancing). So one server could host 4 external map sections, and 4 servers might host one city map section (including the nearby external map area, eg 1-2km radius outside of city limits).
I think this is do-able!
As for physics, yes plan to have a detailed physic system running client side. It'll include correct terrain movement mods(eg. gradule increase of drag on vehicle movement, depending on terrain).
So vehicles leaving a concrete road will have a decrease in speed over time depending of terrain and vehicle type(eg. entering grass will have slow if entering at high-med speed(but verylow handling), a little faster at low speed(but low-med handling), entering mud will decrease speed faster and handling would be worst for wheeled vehicles, tracked vehicles would be different again).
As for a team of programmers, I do have few very good group, but will be looking for more as time goes on.
#8
2) I would suggest you highly reconsider modelling physics client side, regardless of which engine/SDK you go with (Torque or not). From network propagation to security flaws (hacked client executable) to player state management through a host of other issues, client side physics is going to be very troublesome to implement. Just my opinion, but it's at least a semi-educated one!
02/13/2005 (3:35 pm)
1) Load balancing is actually the (relatively) easy part of the issue..with TGE at least, the primary issue is that from the very lowest level of code, a design assumption was made that there is only 1 terrain block, period. Modifying this assumption, plus putting in all the rest of the streaming/tiling code, is in the neighborhood of 6k lines of code, not counting editor scripts, across roughly 20 files.2) I would suggest you highly reconsider modelling physics client side, regardless of which engine/SDK you go with (Torque or not). From network propagation to security flaws (hacked client executable) to player state management through a host of other issues, client side physics is going to be very troublesome to implement. Just my opinion, but it's at least a semi-educated one!
Torque Owner Pierre (DragoFire) Hay
RedlineIT