Opening discussion on Terrain Paging
by David Dougher · in Torque Game Engine · 06/02/2004 (2:48 pm) · 56 replies
This thread will be used to discuss Terrain Paging.
First of all acknowledgements are in order.
J. Donavan Stanley did most of the updates to the Terrain Manager after its initial creation those changes became the project known as Gorpe.
Fredrik Svensson did a great deal of work on my first iterations of the Terrain Paging. Although the final version of the code is mine he provided a lot of useful feedback and helped with much of the hashing that goes into working out everything that was being touched and where.
Briefly then,
My Implementation is quite simple. It assumes a 3x3 tile system with the player at the center. As the player moves from one boundary to the next the appropriate tiles are loaded and the tiles furthest from the player are dropped.
Worst case scenario is moving at a diagonal from corner tile to corner tile. This causes the loss of five tiles and the loading of five.
A couple of simple checks are run to determine which tile the player is on and entering a new tile initiates a page check. Depending on which direction you are moving the further tiles are let go. The the new tiles are loaded. There are special tests for edge conditions and corners.
Essentially, if you run to an edge or a corner of the world the tiles you currently have are retained and you move off of the center tile. The reason for this is simplicity - it is easier to maintain the 3x3 matrix then to special case all the differences. Also, if you run into a corner you will still have to come back out -- meaning that we have already cached the tiles you will run to eventually when leaving.
As you return from a corner or edge we move you back the center tile.
First of all acknowledgements are in order.
J. Donavan Stanley did most of the updates to the Terrain Manager after its initial creation those changes became the project known as Gorpe.
Fredrik Svensson did a great deal of work on my first iterations of the Terrain Paging. Although the final version of the code is mine he provided a lot of useful feedback and helped with much of the hashing that goes into working out everything that was being touched and where.
Briefly then,
My Implementation is quite simple. It assumes a 3x3 tile system with the player at the center. As the player moves from one boundary to the next the appropriate tiles are loaded and the tiles furthest from the player are dropped.
Worst case scenario is moving at a diagonal from corner tile to corner tile. This causes the loss of five tiles and the loading of five.
A couple of simple checks are run to determine which tile the player is on and entering a new tile initiates a page check. Depending on which direction you are moving the further tiles are let go. The the new tiles are loaded. There are special tests for edge conditions and corners.
Essentially, if you run to an edge or a corner of the world the tiles you currently have are retained and you move off of the center tile. The reason for this is simplicity - it is easier to maintain the 3x3 matrix then to special case all the differences. Also, if you run into a corner you will still have to come back out -- meaning that we have already cached the tiles you will run to eventually when leaving.
As you return from a corner or edge we move you back the center tile.
About the author
Owner - Pariah Games, Adjunct Professor - Bristol Community College, Mentor - Game Design - Met School Newport, Mentor - Game Design - Met School Providence
#22
i.e. If you wanted to do a gigantic bitmap defining your entire landscape, then stream it into the heightmap from your randomly accessed file you could. It beats the hell out of dynamically deforming landscapes and gives you true streaming.
For out purposes that wasn't enough since a 256x256 mile world would be about 5.5 Gigs of data and we want to go continent-sized
I've seen a lot of argument elsewhere about how perlin noise for large landscapes generates overly generic landscapes, but...
I downloaded a tool called World Machine (in beta) which allows you to combine, filter and so on perlin noise graphs then view the final output and by using combined perlin noise at different scales (large general noise with smaller and smaller noise blended) you get complex and diverse landscapes.
We intend to take this further, having a large, low res "contintent" fractal, then procedurally filtered noise to take height, longtitude and latitude, as well as fractal distribution, into account to get a serious variance of hills, mountains, ridges, beaches and so on.
The idea isn't new and I've seen people bitching that that would require so many overlaid calculations that you'd get a big hit and might as well go custom designed, but
a) my own calculations from preliminary test for our described method suggest otherwise (I think the folks bitching tried to gen entire landscapes all the time rather than streaming the calculations)
b) There ain't any other way you're going to get continents of 1000's of miles with adequate local detail
06/07/2004 (11:45 pm)
This technique (of having a larger heightmap bitmap and transferring to terrainblocks on boundary crossings) can be used to stream actual massive landscapes too.i.e. If you wanted to do a gigantic bitmap defining your entire landscape, then stream it into the heightmap from your randomly accessed file you could. It beats the hell out of dynamically deforming landscapes and gives you true streaming.
For out purposes that wasn't enough since a 256x256 mile world would be about 5.5 Gigs of data and we want to go continent-sized
I've seen a lot of argument elsewhere about how perlin noise for large landscapes generates overly generic landscapes, but...
I downloaded a tool called World Machine (in beta) which allows you to combine, filter and so on perlin noise graphs then view the final output and by using combined perlin noise at different scales (large general noise with smaller and smaller noise blended) you get complex and diverse landscapes.
We intend to take this further, having a large, low res "contintent" fractal, then procedurally filtered noise to take height, longtitude and latitude, as well as fractal distribution, into account to get a serious variance of hills, mountains, ridges, beaches and so on.
The idea isn't new and I've seen people bitching that that would require so many overlaid calculations that you'd get a big hit and might as well go custom designed, but
a) my own calculations from preliminary test for our described method suggest otherwise (I think the folks bitching tried to gen entire landscapes all the time rather than streaming the calculations)
b) There ain't any other way you're going to get continents of 1000's of miles with adequate local detail
#23
On another topic - I bought the 3d all in one book - I recommend it.
06/10/2004 (4:50 pm)
This sounds like what I've been looking for. I need to map about 150 x 150 miles. On another topic - I bought the 3d all in one book - I recommend it.
#24
Is anyone still working on terrain paging for their project?
Also, David (D.) are you still active in Torque?
After quite a long delay, my project is currently in the process of patching in a version of the TerrManager resource described above (generously provided by David), so if anyone else is working on something similar, would love to hear about problems you've found or solutions you've discovered!
10/26/2004 (9:36 am)
Thread Revival:Is anyone still working on terrain paging for their project?
Also, David (D.) are you still active in Torque?
After quite a long delay, my project is currently in the process of patching in a version of the TerrManager resource described above (generously provided by David), so if anyone else is working on something similar, would love to hear about problems you've found or solutions you've discovered!
#25
Yes I am still active. And Adellion is still going strong. Like many here I am watching to see just how the situation with TSE is going to work out since the new terrain system that Ben Garney is working on seems to have great promise.
Our first effort with torque and terrain paging is prety much set to go, but we are looking at TSE and trying to gauge just how much longer it will be until it is ready for primetime. It seems to be making progress and I suspect that it may even be a possibility before we are ready to ship, though not before we are ready for Alpha testing.
Haven't tried to do a port of our code to TSE in a couple months. Last time it went pretty well. I suspect that, if I left out the terrain alterations and focused on the other major features I could get most of it in.
I did get your letter but I haven't had a chance to reply. Will try and do so later today.
10/26/2004 (10:22 am)
Nice to be missed. Yes I am still active. And Adellion is still going strong. Like many here I am watching to see just how the situation with TSE is going to work out since the new terrain system that Ben Garney is working on seems to have great promise.
Our first effort with torque and terrain paging is prety much set to go, but we are looking at TSE and trying to gauge just how much longer it will be until it is ready for primetime. It seems to be making progress and I suspect that it may even be a possibility before we are ready to ship, though not before we are ready for Alpha testing.
Haven't tried to do a port of our code to TSE in a couple months. Last time it went pretty well. I suspect that, if I left out the terrain alterations and focused on the other major features I could get most of it in.
I did get your letter but I haven't had a chance to reply. Will try and do so later today.
#26
There were also not a few things I luffed (stabbed at until it compiled) with little to no clue of what actually needed to be done, but for a patch from such wildly different sources it went pretty well.
Right now, our big issue is getting objects to synch on login from client to dedicated server, but I expect a decent portion of that is having some TManager style mission/terrain files to work with.
10/26/2004 (12:45 pm)
Sounds good! FYI, our patch of the code you provided against 1_3_0 worked pretty well (had to apply manually however, and 5400 lines of patch was a bear). I noted that there were some "migrations" of style (I had never seen friend methods in TGE before, guess I'm still real new ~) ), and I imagine it's going to be a bit of a task to get things stable.There were also not a few things I luffed (stabbed at until it compiled) with little to no clue of what actually needed to be done, but for a patch from such wildly different sources it went pretty well.
Right now, our big issue is getting objects to synch on login from client to dedicated server, but I expect a decent portion of that is having some TManager style mission/terrain files to work with.
#27
10/26/2004 (9:21 pm)
I'm working on terrain paging stuff too. I'm targetting this work primarily at TSE though so it may not be suitable for you. I'm trying to organise this work so there's not too much crossover with what Ben's working on. This is part of a library which aims at adding handy MOG stuff like persistent objects, distributed servers and terrain paging to TSE. I'm looking to release this stuff to the community eventually - but not for quite a while yet.
#28
Adellion has already covered a lot of this territory and we have some interest in porting it to TSE. Our plans also call for releasing parts back to the community to enable people who want to do MOG with a "Pack" that could be used to update their systems to do this.
However, (and Ben can correct me on this) the current terrain system that is in TSE is not anything like what he plans to use. This terrain system is pretty close to the one that is currently running in torque. The new terrain system will use a different algorithm and will have paging and include editor modifications to "glue" terrains together. I believe he has also stated that he plans on letting people who have created terrains in TGE update them to TSE but the number of steps to do that is certainly very much up in the air.
In addition to terrain changes there are also waterblock modifications coming as mentioned by Brain Ramage in his latest .Plan file.
Perhaps we should consider pooling our material - first for a TGE "Pack" and then revisit the situation for TSE?
It seems to me that GG has set the pattern for this with their intent to release a RTS Pack. MOG code is not something everybody will want, so making it an add-in seems the best way to go. This much code is also likely to be considerably more than a regular "patch" or resource update.
If people are interested in this they should contact me at ddougher@pariahgames.com and we can see what we already have and perhaps pool our resources to complete the rest.
The goal would be to complete a minimal set of pieces so that it could be used on a variety of projects with some work on the developer's part - rather than make a giant, "this will do everything!" project that will collapse under all the requirements heaped on it by the community.
It should also be "minimally invasive" to torque - patching only what needs to be patched and placing code in separate files that will be easier to maintain.
10/27/2004 (5:31 am)
@Zik, & StephenAdellion has already covered a lot of this territory and we have some interest in porting it to TSE. Our plans also call for releasing parts back to the community to enable people who want to do MOG with a "Pack" that could be used to update their systems to do this.
However, (and Ben can correct me on this) the current terrain system that is in TSE is not anything like what he plans to use. This terrain system is pretty close to the one that is currently running in torque. The new terrain system will use a different algorithm and will have paging and include editor modifications to "glue" terrains together. I believe he has also stated that he plans on letting people who have created terrains in TGE update them to TSE but the number of steps to do that is certainly very much up in the air.
In addition to terrain changes there are also waterblock modifications coming as mentioned by Brain Ramage in his latest .Plan file.
Perhaps we should consider pooling our material - first for a TGE "Pack" and then revisit the situation for TSE?
It seems to me that GG has set the pattern for this with their intent to release a RTS Pack. MOG code is not something everybody will want, so making it an add-in seems the best way to go. This much code is also likely to be considerably more than a regular "patch" or resource update.
If people are interested in this they should contact me at ddougher@pariahgames.com and we can see what we already have and perhaps pool our resources to complete the rest.
The goal would be to complete a minimal set of pieces so that it could be used on a variety of projects with some work on the developer's part - rather than make a giant, "this will do everything!" project that will collapse under all the requirements heaped on it by the community.
It should also be "minimally invasive" to torque - patching only what needs to be patched and placing code in separate files that will be easier to maintain.
#29
After 5 days and a lot of assistance from David, I've got a non-crashing dedicated server/client environment working with build 19 of the Terrain Manager. I've yet to test a wide variety of things, and my next goal is to get some functionality for monitoring paging actions (and even having the .ter files and .mis file setup for a bigger grid than 1x1).
I agree with David regarding the concept--I would guess that TSE is far enough away from stable full functionality release that it might be worthwhile consolidating and polishing what is currently being worked on and possibly provide as a resource.
One thing to keep in mind however, David's project has been around for quite a while, and does have some older code. Since he had the best starting point for the GORPE/TerrManager resource for terrain paging, it made the most sense to use, butI wound up completely guessing at a -lot- of things, and had to apply the patch manually (as mentioned above) to get it integrated with current TGE head--and I -know- I have a long way to go to fix what I broke in the process--not to mention things that simply aren't finished yet. Just off the top of my head, lighting, shadows, collision, a -lot- of the editor functionality all were affected, in some ways drastically.
The other thing that would concern me is that from a SDK design perspective, the terrain paging concept is a rather drastic change from stock Torque (which isn't a bad thing, don't get me wrong), so keeping a good resource available might be difficult.
Ultimately, it comes down to what it would be worth to the community as a whole (exactly how many people would be wanting something like this, since it really does only apply to very very large RTS/RPG type games), compared to the work required.
I would certainly be willing to finish testing what I'm working on now and with David's permission make it available as a more updated resource, but along the way I -know- I'll need help resolving conflicts.
10/27/2004 (9:52 am)
Update:After 5 days and a lot of assistance from David, I've got a non-crashing dedicated server/client environment working with build 19 of the Terrain Manager. I've yet to test a wide variety of things, and my next goal is to get some functionality for monitoring paging actions (and even having the .ter files and .mis file setup for a bigger grid than 1x1).
I agree with David regarding the concept--I would guess that TSE is far enough away from stable full functionality release that it might be worthwhile consolidating and polishing what is currently being worked on and possibly provide as a resource.
One thing to keep in mind however, David's project has been around for quite a while, and does have some older code. Since he had the best starting point for the GORPE/TerrManager resource for terrain paging, it made the most sense to use, butI wound up completely guessing at a -lot- of things, and had to apply the patch manually (as mentioned above) to get it integrated with current TGE head--and I -know- I have a long way to go to fix what I broke in the process--not to mention things that simply aren't finished yet. Just off the top of my head, lighting, shadows, collision, a -lot- of the editor functionality all were affected, in some ways drastically.
The other thing that would concern me is that from a SDK design perspective, the terrain paging concept is a rather drastic change from stock Torque (which isn't a bad thing, don't get me wrong), so keeping a good resource available might be difficult.
Ultimately, it comes down to what it would be worth to the community as a whole (exactly how many people would be wanting something like this, since it really does only apply to very very large RTS/RPG type games), compared to the work required.
I would certainly be willing to finish testing what I'm working on now and with David's permission make it available as a more updated resource, but along the way I -know- I'll need help resolving conflicts.
#30
This won't be for hundreds of thousands of players but it will be good for "big worlds". You want to go a lot larger you better have the money for the server clusters and the bandwidth expenses.
A bit different than Adellion's design but it involves a lot less code rewrite than the way we are doing it.
I have discussed this with HonourBound Ltd. which holds the copyright for the additional pieces and they are agreeable to the release. It won't be for a while though. Too much stuff in the pipeline to do this right away.
10/27/2004 (11:47 am)
We plan on releasing a number of resources and anything I have sent you can also be released with your work. We are also looking at a real low cost "Pack" to take a game to an MOG in a manner similar to DaoC with several terrains linked and additional terrains on different servers for big cities or dungeons. The idea is a kit of various parts you will apply based on what you need for your game. Database linkages, inventory system, login servers, character servers, multiterrain system, global weather, etc. We will also release some pieces separately to the community. The idea is that the "kit" will simply tie all this stuff together into a coherent picture that will work together.This won't be for hundreds of thousands of players but it will be good for "big worlds". You want to go a lot larger you better have the money for the server clusters and the bandwidth expenses.
A bit different than Adellion's design but it involves a lot less code rewrite than the way we are doing it.
I have discussed this with HonourBound Ltd. which holds the copyright for the additional pieces and they are agreeable to the release. It won't be for a while though. Too much stuff in the pipeline to do this right away.
#31
Where did you get build 19 of the Terrain Manager? I thought it was lost as any links to any TerrainManager ended with 404 errors.
10/27/2004 (11:59 am)
Quote:
After 5 days and a lot of assistance from David, I've got a non-crashing dedicated server/client environment working with build 19 of the Terrain Manager.
Where did you get build 19 of the Terrain Manager? I thought it was lost as any links to any TerrainManager ended with 404 errors.
#32
When the GG CVS went south I gave them my copies of the various baselines to help them with the rebuild. They decided not to try and resurrect Gorpe because it was seeing no development and Ben Garney, Brian Ramage and Co. were already pushing on to new territory with TSE.
10/27/2004 (1:17 pm)
I am a bit of a Pack Rat when it comes to old code. I kept a set of running baselines for torque from when it was first laid down as well as a number of the more interesting variations - including some Terrain Manager versions and Gorpe.When the GG CVS went south I gave them my copies of the various baselines to help them with the rebuild. They decided not to try and resurrect Gorpe because it was seeing no development and Ben Garney, Brian Ramage and Co. were already pushing on to new territory with TSE.
#33
10/27/2004 (1:46 pm)
I, for one, am interested in this. I wish I had the experience with TGE to help out. My project would benefit from this.
#34
10/27/2004 (4:25 pm)
David, pooling resources sounds great! Let's do it. My target platform is TSE so I'd be keen to get things working there too. I'll contact you via email.
#35
10/27/2004 (4:34 pm)
Just so you know TSE is about to overhaul the terrain engine so might want to be patient and see what the new terrains can do, if you target platform is TSE that is.
#36
10/27/2004 (4:45 pm)
Thanks Anthony, I'm aware of this. Ben has mentioned this in the past so I'm trying to work around the edges of where I'm guessing his new terrain work will be.
#37
10/27/2004 (6:12 pm)
David, an MMO code pack would be awsome. You guys could sell it like TGE itself, via a CVS server, and update it with new code/improvments. You could sell it for $60+, and it would start alot of people on thier MMOs(everyone wants one, I know I do).
#38
This isn't specifically directed at you Josh but this is a button that gets pushed around here way too much.
We can sell you the basics to get started. But people don't realize just how much money it costs to run a real MMO - not to mention the amount of work to get one started. That's why I suggested that this is not for the hundreds of thousands of players of a DaoC. We can give you the code to get such a game started for perhaps a few hundred and depending on how you tackle the problem perhaps significantly more.
But the reason that GG discourages MMOG is not what everybody thinks. Yes, it is a huge amount of work to make an MMOG - the next generation of MMOG will be on DVD's! - think about how long it would take you to make that much content.
But beyond that, do you seriously have any idea how much it costs to run an MMOG?
MAJOR publishers can afford a couple. They are that expensive. The costs are dropping for the hardware. Within these next few years you will be able to host far more than you could on a single machine - but - the bandwidth costs are not changing very much - and they are hugely expensive - not to mention the people. Anybody here wondering why EA has announced they are moving all their MMOG art operations to China? It isn't cause they like the cooking.
The "Pack" we envisage is to help you make BIG persistent worlds - not Massive Multiplayer games. There is a distinction.
GG knows that a real MMOG costs $$$ - and you guys don't have it. Let me quote some numbers at you from the book, Developing Online Games.
for a TINY MMOG with only 30,000 players. You require ten server clusters at $80,000.00 a piece or $800,000.00.
12 people for player relations will add $144,000.00.
3 people for community relations is $36,000.
Your Live development team will be 12 people at $216,000.00
Management team is 4 people at $96,000.00.
Billing and accounts is $60,000 for 5 people.
Server team is 5 people for $75,000.00
Office space is $250,000.00 for all these people and hardware.
About $80,000.00 dollars for incidental expenses
Did I mention that this is the cost for 3 months of operation? That's right - 3 months.
Now maybe your game is going to be the greatest thing since sliced bread, but - if you hit a slump none of these costs go away. And we haven't touched on your bandwidth costs yet. For a tiny game - where you KNOW it is tiny it would be about $320,000.00 for those same three months.
For those of you at home keeping score thats a bit over 2 million dollars - for three months.
Now what happens if your game is successful just as you envisioned it and it gets the 30,000 people you wanted in the end? No major MMOG has opened in the US with LESS than 60,000 people to start. The numbers in some cases have fallen rapidly after launch. So you need double your capacity - double your people - double your hardware to launch. If you are shooting for a small game you lose half your people - did they go away happy? No. Fire half your team see how much fun it is. And you lost half your customers - according to plan. They went away unhappy with something you did - you will hear about it as HALF your player base walks out. Think the press will not notice? So you start out with a bad rep for a successful game. Bizzare? Yes, but that is the dilemna of the small MMOG.
But what happens if you are really successful? A hundred thousand people at launch is not uncommon for a good game and you were making a great game right?
Well now you need four times what I quoted just to launch and run for 3 months.
And if you hit a slump - just a three month soft spot you can lose as much as I have shown you - quadrupelled - anybody here afford to LOSE eight million in a 3 month slump? Say, World of Warcraft takes your people for a bit, a new version of SWG? EQ2 coming out draws your fantasy base for a bit...
10/27/2004 (8:07 pm)
Oh God I like you people! I don't want you to try and make MMOG's!!!This isn't specifically directed at you Josh but this is a button that gets pushed around here way too much.
We can sell you the basics to get started. But people don't realize just how much money it costs to run a real MMO - not to mention the amount of work to get one started. That's why I suggested that this is not for the hundreds of thousands of players of a DaoC. We can give you the code to get such a game started for perhaps a few hundred and depending on how you tackle the problem perhaps significantly more.
But the reason that GG discourages MMOG is not what everybody thinks. Yes, it is a huge amount of work to make an MMOG - the next generation of MMOG will be on DVD's! - think about how long it would take you to make that much content.
But beyond that, do you seriously have any idea how much it costs to run an MMOG?
MAJOR publishers can afford a couple. They are that expensive. The costs are dropping for the hardware. Within these next few years you will be able to host far more than you could on a single machine - but - the bandwidth costs are not changing very much - and they are hugely expensive - not to mention the people. Anybody here wondering why EA has announced they are moving all their MMOG art operations to China? It isn't cause they like the cooking.
The "Pack" we envisage is to help you make BIG persistent worlds - not Massive Multiplayer games. There is a distinction.
GG knows that a real MMOG costs $$$ - and you guys don't have it. Let me quote some numbers at you from the book, Developing Online Games.
for a TINY MMOG with only 30,000 players. You require ten server clusters at $80,000.00 a piece or $800,000.00.
12 people for player relations will add $144,000.00.
3 people for community relations is $36,000.
Your Live development team will be 12 people at $216,000.00
Management team is 4 people at $96,000.00.
Billing and accounts is $60,000 for 5 people.
Server team is 5 people for $75,000.00
Office space is $250,000.00 for all these people and hardware.
About $80,000.00 dollars for incidental expenses
Did I mention that this is the cost for 3 months of operation? That's right - 3 months.
Now maybe your game is going to be the greatest thing since sliced bread, but - if you hit a slump none of these costs go away. And we haven't touched on your bandwidth costs yet. For a tiny game - where you KNOW it is tiny it would be about $320,000.00 for those same three months.
For those of you at home keeping score thats a bit over 2 million dollars - for three months.
Now what happens if your game is successful just as you envisioned it and it gets the 30,000 people you wanted in the end? No major MMOG has opened in the US with LESS than 60,000 people to start. The numbers in some cases have fallen rapidly after launch. So you need double your capacity - double your people - double your hardware to launch. If you are shooting for a small game you lose half your people - did they go away happy? No. Fire half your team see how much fun it is. And you lost half your customers - according to plan. They went away unhappy with something you did - you will hear about it as HALF your player base walks out. Think the press will not notice? So you start out with a bad rep for a successful game. Bizzare? Yes, but that is the dilemna of the small MMOG.
But what happens if you are really successful? A hundred thousand people at launch is not uncommon for a good game and you were making a great game right?
Well now you need four times what I quoted just to launch and run for 3 months.
And if you hit a slump - just a three month soft spot you can lose as much as I have shown you - quadrupelled - anybody here afford to LOSE eight million in a 3 month slump? Say, World of Warcraft takes your people for a bit, a new version of SWG? EQ2 coming out draws your fantasy base for a bit...
#39
This might seem like hypocritical advice from a guy who is making an MMOG with volunteers and code snippets, but I have a plan that is NOT the MMOG plan and it is a gamble the principals are willing to take to get what they want. We have a publisher who has other MMOG games and the hardware and the bandwidth and they are willing to take the chance. If it works I will be happy to share it all with you for free. If it fails, I hope to make a few bucks and some notoriety out of the Post-Mortem article in Game Developer.
Big persistent worlds are a possibility and that's what the MOG Pack would be about. You still would need a LOT of content and a game plan - something beyond - "I'm going to make a fantasy game like Everquest, only better". Because there are already games better than Everquest out there. But they are not as big, and they are never going to get as big, because they don't have the cash to put themselves where Sony can put Everquest, namely on the back cover of every game, sci-fi, and fantasy magazine in the world for months on end if they choose to do so.
So with that giant caveat nailed firmly into place...
I was thinking that it would be something I would discuss with GG when it gets made. I have already had one project I wanted to do with them go south because my time got chewed to hell and the next time I talk with them I will have the project done. Its more risk for me to complete a project before I go looking for somebody to sell it. But, if its good then people will be interested in buying and I don't mind a little rework to make something better.
And I am interested in this for TGE first, and we will see how much of it is necessary in TSE. Big terrain is only the tip of the iceberg for these games so even if TSE has a beautiful multi-terrain tiling system it will simply be one piece we don't need to put in TSE vs. TGE. There is till LOTs more that could go into such a Pack.
10/27/2004 (8:07 pm)
I am grossly oversimplifying this. Turbine at last count I heard has over 120 people and they are still hiring. It is a LOT more complicated and it gets much more scary. But the bottom line is simple. Stay Away from MMOG's. This might seem like hypocritical advice from a guy who is making an MMOG with volunteers and code snippets, but I have a plan that is NOT the MMOG plan and it is a gamble the principals are willing to take to get what they want. We have a publisher who has other MMOG games and the hardware and the bandwidth and they are willing to take the chance. If it works I will be happy to share it all with you for free. If it fails, I hope to make a few bucks and some notoriety out of the Post-Mortem article in Game Developer.
Big persistent worlds are a possibility and that's what the MOG Pack would be about. You still would need a LOT of content and a game plan - something beyond - "I'm going to make a fantasy game like Everquest, only better". Because there are already games better than Everquest out there. But they are not as big, and they are never going to get as big, because they don't have the cash to put themselves where Sony can put Everquest, namely on the back cover of every game, sci-fi, and fantasy magazine in the world for months on end if they choose to do so.
So with that giant caveat nailed firmly into place...
I was thinking that it would be something I would discuss with GG when it gets made. I have already had one project I wanted to do with them go south because my time got chewed to hell and the next time I talk with them I will have the project done. Its more risk for me to complete a project before I go looking for somebody to sell it. But, if its good then people will be interested in buying and I don't mind a little rework to make something better.
And I am interested in this for TGE first, and we will see how much of it is necessary in TSE. Big terrain is only the tip of the iceberg for these games so even if TSE has a beautiful multi-terrain tiling system it will simply be one piece we don't need to put in TSE vs. TGE. There is till LOTs more that could go into such a Pack.
#40
Personally I have no aspirations of running the kind of big operation you've described. I'd be happy with a single server and a few friends playing. Maybe some of the other MOG people around here have similar interests to me?
10/28/2004 (1:12 am)
Hey David, your point about the costs of running big MMOGs are well taken. Still, not all of us are doing this expecting massive commerical success. Some of us just love writing games!Personally I have no aspirations of running the kind of big operation you've described. I'd be happy with a single server and a few friends playing. Maybe some of the other MOG people around here have similar interests to me?
Torque Owner Farren Hayden
We're planning a big world single player like morrowind, with limited multiplayer (because MW players have endlessly whined about it - we did a simple trading app for MW players to trade between their save game inventories online and it generated a lot of excitement at the time)
Essentially it will not be an MMORPG but a single/multiplayer where multiplayer has 2 aspects
1. You can play with friends online as friend or foe. When doing so multiplayer saves and loads are advised (i.e. everyone starts at the same time from a Warcraft like "forum" and saves at the same time) to prevent the huge amount of data that an ongoing RPG generates having to be shared across the net each time.
In this multiplayer mode we're rather going to alter the server architecture so servers have peer-to-peer dialogue and each player serves themselves. That way we can allow people to be spacially far apart.
The fact that you'll be playing with friends should address cheating/hacking issues, but I can concieve of a question/response dialogue at startup where servers ask each other to simulate something and produce the result and/or provide checksums for randomly chosen data on disk as a cheating check. The random choice of simulation or data would make it hard to fake the response.
2. The second multiplayer scenario would be a closed 3x3 block (say a big city) that can't be exited from and serves centrally. The point of this would be a sub-game where lots and lots of people can gather, trade, have gladatorial fights and so on with their main game character. It would serve as a chat forum too for strangers who want to gather, boast and fight on the web. It wouldn't be a whole world, but it would allow people a sense of greater community
We also started down this road with MW modding, trying to read NIF file formats for character models and using open source 3D for a little town for peeps to gather in (I'd already written an advanced editor for MW called the Enchanted Editor so I had a full library of code for reading save files under my belt and we were just going to write back to save files). However, we decided we'd rather do our own game.
As far as dynamically deforming landscapes go, that's not our plan at all.
The way it works is this:
You've got a heightmap (bitmap) in memory that always contains a fractally generated heightmap equivalent to 5 x 5 terrainblocks in size, with you in the center at all times. This is NOT the terrainblock data, its seperate heightmap data.
You've got an array of 3 x 3 actual terrainblocks with you on the center one at all times. When you cross a boundary, all the height data is transferred into the new terrain blocks that need to be loaded at very low processing cost. No file access, just converting height to grid data. The new heightmaps that must be generated are then generated in the background as you carry on moving.
So on a cell change only heightmap transfer from memory occurs and heightmap data is being calculated all the time.
The heightmap calculations are really spread out. Every time you move by one square on the terrainblock it bitblts the entire 5 x 5 heightmap array one pixel to the left/right/up/down etc and just calculates a single new row of height pixels, so while you're not always dead center in the 3 x 3 terrainblock grid, you're always dead center in the heightmap.
This does mean 3x256 or 768 perlin noise calculations every few steps, but for a smooth loading continuous landscape we feel the FPS hit is probably going to be worth it. Simple fractal landscape tests using complex prodecurally altered perlin noise yields a 512x512 landscape in under a second, and thats 262,144 calculations, orders of magnitude higher than what I've described above