Seamless MMO World - TGEA
by RedOctober · in General Discussion · 05/19/2007 (10:39 pm) · 16 replies
I did some forum searching for this but never found anything that exactly answered my question. I found some posts that said people had modified the Torque network code so that they thought they could hold 200 or so people in a zone. I was wondering if it would be possible to make a Torque MMO a seamless world, with no zones and no load times after you enter the game, as opposed to being forced into splitting an MMO world into zones due to the network issue. The type of seamless world I am talking about would be like Star Wars Galaxies or Shadowbane, if you have ever played them, but in the case of Star Wars Galaxies I suppose each planet is a separate zone in a sense.
Thanks, and I sincerely apologize for the annoying, cliche, MMO question.
Thanks, and I sincerely apologize for the annoying, cliche, MMO question.
#2
05/19/2007 (10:53 pm)
A Source code license would just mean buying the Indie Version of TGEA for $295, yes?
#4
Look at WOW vs SWG. And SWG's problems. Sony split there customer base in 2 or 3
with some decisions. Such as telling people like me I am dumb for wanting EQ in Space.
I.E. I wanted Sony to make star wars with EQ'1's engine and level style.
Instead of making both they push back 2 years to add the insta zone and guess what...
It didn't help. in the end gameplay and content rule.. insta load means what??
With .45 nm production CPU's and CUDA blah blah blah etc.. your gonna zone in a nano second anyway
with future machines...
Just enough time to run to bathroom and nuke more junkfood...
Ok i'll admit.. I am in the zonelines 4 the win crowd....
EQ1 had it right...
05/20/2007 (2:56 am)
Customers don't really care about that. It's nitpicking.. Look at WOW vs SWG. And SWG's problems. Sony split there customer base in 2 or 3
with some decisions. Such as telling people like me I am dumb for wanting EQ in Space.
I.E. I wanted Sony to make star wars with EQ'1's engine and level style.
Instead of making both they push back 2 years to add the insta zone and guess what...
It didn't help. in the end gameplay and content rule.. insta load means what??
With .45 nm production CPU's and CUDA blah blah blah etc.. your gonna zone in a nano second anyway
with future machines...
Just enough time to run to bathroom and nuke more junkfood...
Ok i'll admit.. I am in the zonelines 4 the win crowd....
EQ1 had it right...
#5
05/20/2007 (7:10 am)
I agree, zones definitely have their place and were great in EQ1. But, for certain gametypes they aren't as viable or desirable, especially for a 100% PvP game. That's why I was just curious if it would be possible to have a seamless/zoneless world on Torque.
#6
05/20/2007 (8:41 am)
Atlas maps in TGEA are going to give you the largest possible seamless game play. Limiting visable rendering will give you the speed, but breaking up the maps are going to give you better performance. It's quite a bit harder technically to span a seamless maps across several machines and thats not a limitation of the engine either.
#7
05/20/2007 (3:41 pm)
Here's a response I got from someone else on another forum. What do you guys make of it, is this accurate?Quote:
Well anything is possible, however if you plan to make it seamless thats the only thing your gonna be working on for the next year or so. The terrain code as I understand it is woven so tightly in Torque that unraveling it and changing it is a task of monumental proportions. I believe there was one GG associate who worked on doing this for a while and abandoned it due to the amount of time that he eventually found out it was gonna take. And its not just the terrain. The serverback end will also have to be rewritten as it is designed to balance loads with zones being seperate processess that can be distributed to different machines. Atlas for TGEA is still a diamond in the rough as I understand it and think about how long they've been working on that.
http://www.mmoworkshop.com/trac/mom/phpbb?page=viewtopic.php&t=224
This was a system I thought of make the best of the situation. If you are using TGEA and Atlas you could do this without the drawbacks of losing vital land real estate.
I don't believe you will see this technology in Torque until the write a new engine from the ground up.
Thak was on the money. Many of the worlds that have it implemented have vast barren landscapes filled with nothing. Not that I haven't seen my share of zones that were empty as well.
I do love seemless worlds though.
#8
Understand that your problems are bigger than whether to use large terrains or not. Zoning is a small issue compared to all the back-end stuff.
05/20/2007 (8:43 pm)
MMO Workshop will save you lots of work. I haven't gotten it myself, but the money is put aside.Understand that your problems are bigger than whether to use large terrains or not. Zoning is a small issue compared to all the back-end stuff.
#9
05/20/2007 (9:21 pm)
The issue with large seamless maps is long standing among many games. First it takes a lot if art assets to fill em, it takes a really organized server set up and coding and it makes for a some what less organized world. None the less integrating a seamless world does have many advantages too, especially if you're trying to enforce some realism. It will take a good amount of tweaking the torque engine to get a truly seamless world, i don't think the mmo kit even has a truly seamless world map either. The easiest way to get a very large map and be able to fill it enough not to look barren is to zone it. At an 8 square size thats a 2km map in the tge and well it's pretty unlimited in the tgea.
#10
Please note that the specific technology challenge he was referring to taking all that time was with the original legacy terrain block (not Atlas), around TGE 1.3/1.4.2. I spent several months trying to get the original terrain model to stream, and while I did get it working eventually, it wasn't particularly capable or performant.
Atlas makes the terrain/landscape portion of the challenge trivial for you (it already seamlessly streams pages of terrain), so your major issue becomes one of networking. Server to client, Torque already is designed for a "seamless" creation and removal capability of managing objects in a seamless environment, so your big issue becomes handling the back end server architecture, and allowing players to migrate from server instance to server instance, as well as being able to ghost objects from one server to the next.
That comment however is flat out misleading. Nothing whatsoever in the entire concept of an MMO requires a "new engine from the ground up"--in fact, Torque's networking makes about 90% of the work needed relatively trivial in effort of implementation (it's just the design and working through a few critical issues that's tough).
EDIT: BTW, my observation about the comment (being misleading) wasn't intended to be abusive/aggressive, just stating that regarding networking, it's not as difficult a transition as implied--taking network ghosting "to the extreme", combined with a mechanism for moving a control object from one server to another across a transition boundary, and you've solved the most complex challenges--both of which are directly inline with the current network code.
05/21/2007 (6:47 am)
For the record, I'm the "associate" mentioned in the quote from that forum.Please note that the specific technology challenge he was referring to taking all that time was with the original legacy terrain block (not Atlas), around TGE 1.3/1.4.2. I spent several months trying to get the original terrain model to stream, and while I did get it working eventually, it wasn't particularly capable or performant.
Atlas makes the terrain/landscape portion of the challenge trivial for you (it already seamlessly streams pages of terrain), so your major issue becomes one of networking. Server to client, Torque already is designed for a "seamless" creation and removal capability of managing objects in a seamless environment, so your big issue becomes handling the back end server architecture, and allowing players to migrate from server instance to server instance, as well as being able to ghost objects from one server to the next.
Quote:
I don't believe you will see this technology in Torque until the write a new engine from the ground up.
That comment however is flat out misleading. Nothing whatsoever in the entire concept of an MMO requires a "new engine from the ground up"--in fact, Torque's networking makes about 90% of the work needed relatively trivial in effort of implementation (it's just the design and working through a few critical issues that's tough).
EDIT: BTW, my observation about the comment (being misleading) wasn't intended to be abusive/aggressive, just stating that regarding networking, it's not as difficult a transition as implied--taking network ghosting "to the extreme", combined with a mechanism for moving a control object from one server to another across a transition boundary, and you've solved the most complex challenges--both of which are directly inline with the current network code.
#11
1. Ability to create multiple TerrainBlock's in a grid.
2. An "Editor" and "Release" texture setting. When in editor, it behaves as in regular Torque. In Release, the blender is disabled and a unique texture is created based on the opacity map and textures of the terrain. Increases mission load time, increases video memory usage but decreases the time spent each frame for blending.
3. A loader thread which loads TerrainBlock's as they get inside View Range * 1.10.
4. Rework the visibility/culling functions as they did not work well with water in our tests.
5. A texture map which holds pixel data corresponding to range between any waterblocks and the terrain vertice, to be able to blend the water and create foam.
6. Mess around with the vertex buffers in the wish for better performance.
Of all these, we managed to nail 1 - 4 before it got put on the backburner. There are still some issues with video memory getting eaten quickly when you have high view ranges, or when the loader thread does not get enough time to read in the textures.
Another problem was (and still is) mipmapping. We had to disable it as I messed up the code for that somewhere. Torque TerrainBlock's are easy to get working as seperate objects, but AllocatedTexture and all that junk wasn't as easy IMO.
Recently, Matt Vitelli's work on shaders have motivated us to resume work on this, but it's been slow and tons of effort. One does not know how much you forget before you take a look at the code again.
Eventually (ie. after the summer) our intention is to release parts of this as a resource, or to a closed group of developers who want to help maintain it.
05/21/2007 (7:32 am)
Reworking legacy terrain into something more useful has been a goal in our project for the last few months. Basically, these were our milestones:1. Ability to create multiple TerrainBlock's in a grid.
2. An "Editor" and "Release" texture setting. When in editor, it behaves as in regular Torque. In Release, the blender is disabled and a unique texture is created based on the opacity map and textures of the terrain. Increases mission load time, increases video memory usage but decreases the time spent each frame for blending.
3. A loader thread which loads TerrainBlock's as they get inside View Range * 1.10.
4. Rework the visibility/culling functions as they did not work well with water in our tests.
5. A texture map which holds pixel data corresponding to range between any waterblocks and the terrain vertice, to be able to blend the water and create foam.
6. Mess around with the vertex buffers in the wish for better performance.
Of all these, we managed to nail 1 - 4 before it got put on the backburner. There are still some issues with video memory getting eaten quickly when you have high view ranges, or when the loader thread does not get enough time to read in the textures.
Another problem was (and still is) mipmapping. We had to disable it as I messed up the code for that somewhere. Torque TerrainBlock's are easy to get working as seperate objects, but AllocatedTexture and all that junk wasn't as easy IMO.
Recently, Matt Vitelli's work on shaders have motivated us to resume work on this, but it's been slow and tons of effort. One does not know how much you forget before you take a look at the code again.
Eventually (ie. after the summer) our intention is to release parts of this as a resource, or to a closed group of developers who want to help maintain it.
#12
Going to test it out and see how things go, the main thing I am looking at is a seamless world, even in the case of dungeons, caves, buildings, etc.... You would enter and it would dither the materials over you, much like in many isometerical games I am sure you are familiar with. I was told that their may be some issues with dungeons, caves, and that sort of thing. So, I guess I just want a flat answer, is TGEA a good choice for a PvP based seamless MMO world with the intent that there will be large numbers of players in concentrated areas at times?
05/21/2007 (2:36 pm)
I'd definitely be interested in this code if you ever get it worked out. I won't have time over the summer to really start coding much, but I do plan on purchasing the TGEA Indie license as soon as I get the cash in a few weeks, at this point. Going to test it out and see how things go, the main thing I am looking at is a seamless world, even in the case of dungeons, caves, buildings, etc.... You would enter and it would dither the materials over you, much like in many isometerical games I am sure you are familiar with. I was told that their may be some issues with dungeons, caves, and that sort of thing. So, I guess I just want a flat answer, is TGEA a good choice for a PvP based seamless MMO world with the intent that there will be large numbers of players in concentrated areas at times?
#13
TGE-A has it's strengths and weaknesses just like any other engine does for the specific requirement you have. When you throw in the "seamless" however, you are describing a fundamentally different service than any engine is going to provide, at any cost, and there are fundamental barriers that you will have to overcome by implementing solutions.
In my personal and professional opinion, based on extensive research, design, and understanding of Torque networking theory and implementation, TGE-A covers a lot of the underlying design requirements for the individual server--client issues, and it's networking layer does not fundamentally prohibit you from making seamless transitions across server instances, but TGE-A does not in any way provide for this, nor does it provide an extensive back end server architecture that will be required to support a game of this nature.
And development of that type of back end architecture is a multi-personnel-year task that many AAA companies have failed miserably at, and may very well be far out of reach of an "indie" budget or skillset, depending on your background.
05/21/2007 (2:44 pm)
There is no flat answer :)TGE-A has it's strengths and weaknesses just like any other engine does for the specific requirement you have. When you throw in the "seamless" however, you are describing a fundamentally different service than any engine is going to provide, at any cost, and there are fundamental barriers that you will have to overcome by implementing solutions.
In my personal and professional opinion, based on extensive research, design, and understanding of Torque networking theory and implementation, TGE-A covers a lot of the underlying design requirements for the individual server--client issues, and it's networking layer does not fundamentally prohibit you from making seamless transitions across server instances, but TGE-A does not in any way provide for this, nor does it provide an extensive back end server architecture that will be required to support a game of this nature.
And development of that type of back end architecture is a multi-personnel-year task that many AAA companies have failed miserably at, and may very well be far out of reach of an "indie" budget or skillset, depending on your background.
#14
05/27/2007 (1:41 am)
So, what are my options? They seem to be pretty slim, either attempt to work on TGEA, or use some other engine. I'm at a loss, I have looked at a number of different ones, none of which really meat standards. TGEA is impressive for everything but the seamless world issue.
#15
That was my statement. And don't worry I don't take what you said negatively.
I realize that it can be done with Torque as just about anything can be done given the skills and time. The shaders being added to TGE by community are a great example of this.
I just don't think we will see this technology implemented into Torque. I'm hoping Stefan Lundmark proves me wrong. I don't think this is anywhere on GG's radar for implementation into TGE/TGEA. Other things just seem to be more important. But obviously I'm not privy to the radar screen and could be very wrong.
I would think at some point GG will make a new engine from the ground up. Implementing the lessons they've learned over the many years. And at that point seamless worlds may be on the check list of things to be included.
Cheers to the person or team that proves me wrong.
05/27/2007 (10:30 am)
Quote:
I don't believe you will see this technology in Torque until the write a new engine from the ground up.
That was my statement. And don't worry I don't take what you said negatively.
I realize that it can be done with Torque as just about anything can be done given the skills and time. The shaders being added to TGE by community are a great example of this.
I just don't think we will see this technology implemented into Torque. I'm hoping Stefan Lundmark proves me wrong. I don't think this is anywhere on GG's radar for implementation into TGE/TGEA. Other things just seem to be more important. But obviously I'm not privy to the radar screen and could be very wrong.
I would think at some point GG will make a new engine from the ground up. Implementing the lessons they've learned over the many years. And at that point seamless worlds may be on the check list of things to be included.
Cheers to the person or team that proves me wrong.
#16
This is just one thing of all those, the terrain.
05/27/2007 (12:48 pm)
Seamless terrain won't make your game seamless. You still have to work with scoping objects and loading assets for them before they are visible, as well as coordinating objects that are close to a "border" of one node, so it's visible on the other, and even then you have priority issues to deal with. Which of the two (or more!) nodes is authorative, and what happens when more than one node wants to interact with the object? Keeping key areas out of the border areas is one thing, but when a player goes there and interacts with another (ex: hunting the other player) you'll run into issues, especially so with FPS gameplay. I will probably never get my head around that, sadly.This is just one thing of all those, the terrain.
Torque 3D Owner Stephen Zepp
It's quite a bit of both design work and implementation.