When I first started this mapping project, my goals were grandiose. I had a vision of the dclient showing a very high level map with the location of cities and perhaps roads between them, updating a small amount in real time as you walked from place to place.
This large vision seemed so close, and yet so far - while easy in principle, the biggest issue was in generating the maps. Mud areas in general do not have to respect linearity. You can arbitrarily connect any room to any other room; in short, generating a cartesian, mappable layout becomes a builder constraint, not a tool constraint.
When faced with 20k rooms of previously built nonlinear content, the task seemed ridiculous and daunting. Initially, I tried piecemeal mapping: each area would have an internal, generated layout, and we'd try to move them around like puzzle pieces to get everything to fit. This didn't really work that well, but some new mapping tools were built and I was able to collect a lot more data.
The next idea was to try a form of annealing, where rooms would update their x/y/z coordinates based on what rooms they were connected to. This worked slightly better, in that it tended to smooth out big gaps and it forced areas to fit in places they didn't before. But it had the drawback of taking a very long time to settle, and it still didn't deal with nonlinearities.
Around this time, the idea of the big/small room distinction came about. Cities on maps are generally very small compared to the surrounding landscape; in Alter Aeon, this was definitely not true. The main city of Ralnoth was easily half as long as the Great Southern Road. I decided to declare cities, towns, buildings and other terrain as 'much smaller' than outdoor/wilderness/linkage areas.
This big/small transition appeared to work very well on the few initial areas I tried it on. Older areas required the most rework, but a lot of 'small' areas had limited linkage to their surroundings anyway, and the transition was easy. The southeast portion of the continent was hit the hardest, as it was designed on a unified grid. It had to be extensively retconned, but even that work happened quickly thanks to the dedication of Draak and Shadowfax.
As part of the big/small experiments, I extended the previously failed area map code to cross all zones, and used that to generate some cheesy room maps showing absolute and relative positions of everything. After a bit more work, I was able to show nonlinear linkages on the maps as well - and this is when things really started to get done. Seeing the problem spots, it was surprising how few of them there really were. We began to aggressively target those.
Meanwhile, the annealing/smoothing code was running in the background, continuously updating the 'real' positions of rooms, as opposed to where we thought they should be. The most recent advance was the realization that the 'perfect' and 'real' maps should be as close to each other as possible, and in fact the 'real' map should try to match the 'perfect' map. I made a few very minor changes to the algorithm, and the global map consistency (not to mention convergence speed) has increased greatly.
After all of this, I'm almost to the point where I can generate the high-level maps I originally wanted in the first place.
The lesson to take away is that invention happens in bursts and is often triggered by random things. Ideas are easy, but implementing them is hard; further, you never know which experiments are going to fail or succeed until you spend time on them. There were several dead ends along the way in this project, but each provided tooling or insight into new things to try.
Overall, if I had known the final form of things at the beginning, all of the code work could probably have been done in a couple of weeks, and all of the area work to follow in another month (with builder help of course). As it stands now, the mapping saga has been going on since the beginning of the year, with breakthroughs and advances from time to time.
Showing posts with label automapper. Show all posts
Showing posts with label automapper. Show all posts
Saturday, November 28, 2009
Thursday, September 17, 2009
The mapping saga continues
While in the dentist's office yesterday, I had a brainstorm regarding mapping: why not run a real-time simulated annealing algorithm to automatically generate the global coordinate grid? When I got home, I took a few hours to implement it, and last night I booted an initial version into the game.
These new position values don't currently do anything, as I'm still working out the bugs and looking for general problems. One thing that appears to cause quite a bit of trouble are nonlinear 'portal' links that bridge a large distance; another major problem are god/builder rooms that link to unusual locations for plot device reasons.
Flagging these troublesome exits isn't something we can currently do, but it's become clear that we will need to do so in order to make the grid coherent.
Finding the problem exits is also difficult, but it's made somewhat easier by an extension to one of our existing mapping routines. By calculating a 'stress energy' for the linkages in each room in the map, I can get a pretty graph showing where maximum grid distortion occurs. These points of maximum distortion usually occur near a positional anchor, which are used to set the position of continents or isolated zones.
However, once the map for a given area has stabilized, the maximum distortion points typically indicate one of the nonlinear links described above. Once the approximate location is known, finding and marking the link is substantially easier.
All in all, I think this is working well enough that we may be able to use it globally for all area placement. Over the next week or two I'll be generating some area and room maps based on this data, and we should be able to refresh the god area and room maps on the web pages soon.
These new position values don't currently do anything, as I'm still working out the bugs and looking for general problems. One thing that appears to cause quite a bit of trouble are nonlinear 'portal' links that bridge a large distance; another major problem are god/builder rooms that link to unusual locations for plot device reasons.
Flagging these troublesome exits isn't something we can currently do, but it's become clear that we will need to do so in order to make the grid coherent.
Finding the problem exits is also difficult, but it's made somewhat easier by an extension to one of our existing mapping routines. By calculating a 'stress energy' for the linkages in each room in the map, I can get a pretty graph showing where maximum grid distortion occurs. These points of maximum distortion usually occur near a positional anchor, which are used to set the position of continents or isolated zones.
However, once the map for a given area has stabilized, the maximum distortion points typically indicate one of the nonlinear links described above. Once the approximate location is known, finding and marking the link is substantially easier.
All in all, I think this is working well enough that we may be able to use it globally for all area placement. Over the next week or two I'll be generating some area and room maps based on this data, and we should be able to refresh the god area and room maps on the web pages soon.
Thursday, April 23, 2009
Remapping of cities
In the quest for linearity and mapping in the game, the answer for towns and cities is clear and obvious: all rooms are the same size. I remapped and expanded the main city in Alter Aeon today, which really cleared up a lot of conflicts and has left no rooms on top of each other. It maps clean, and it wasn't even a lot of work. Here's an example of the client map for the new version:
There's lots of roads, lots of places for shops and other stuff, and a few dead spots to allow for expansion. Most of the player comments have been positive, which is surprising - generally anything that messes up someone's directions causes all kinds of havoc.
This doesn't address the issue of how to handle large expanses of space though, for example forests and other linkage areas. You really don't get an idea of how big the world is until you put into perspective the relative size of cities.
Take for example, my home town. It's a small town of 5-10k people, and from the recent Google maps it's a little over a mile in diameter. Meanwhile, the state in which in which it's located is around 250 miles in diameter (except that its squarish.) Take a penny and tape it to your wall. That's the size difference, and that's just one state, not an entire continent. For a continent, tape a quarter to skyscraper.
I'd like to think Ralnoth in the game is probably about the same size. The currently expanded Ralnoth is about 12 rooms wide and 25 tall; let's say 15 for the sake of argument. Meanwhile, the entire game is perhaps 400 rooms across and tall, neglecting portals to islands and the like. This makes the entire Alter Aeon mainland around 30 miles in diameter.
We have entire mountain ranges, jungles, swamps, other cities, and the shores of two oceans on the mainland. All within 15 miles of the central city of Ralnoth. Starting to see the picture?
A more reasonable continent size is on the order of 500-1000 miles. Even for a 500 mile wide continent, the scale of Ralnoth would imply walking through a minimum of 7500 rooms to get from one side to the other. This is probably not reasonable from a gameplay standpoint, so we need to find a different approach.
The simplest and easiest is to simply define cities to be much larger than they are. If we declare Ralnoth to be ten miles across instead of 1, we end up with a much more reasonable room count. But in that case, even the smallest house represents half a square mile of land area.
A better approach seems to be to change the size of roads and paths, such that the desired distances can be achieved. This kills the dull/boring wilderness areas and gets people out into the world to do something interesting.
I think there's a couple of different ways to handle this. One is to have different sized rooms and render them as best you can. Perhaps using terrain or other flags you can automatically decide what rooms are what size.
But it seems to me that a far better and easier way is to separate large and small sized zones from each other. When you leave one, you end up in the other with a different set of maps. For example, leaving a town shows the town zooming to a small size relative to the forest you're walking in. So many games have done this in the past, that it's a trivially obvious feature. It also happens to be a very good candidate for my overall mapping problems.
I'll let you all know if it works out.
There's lots of roads, lots of places for shops and other stuff, and a few dead spots to allow for expansion. Most of the player comments have been positive, which is surprising - generally anything that messes up someone's directions causes all kinds of havoc.
This doesn't address the issue of how to handle large expanses of space though, for example forests and other linkage areas. You really don't get an idea of how big the world is until you put into perspective the relative size of cities.
Take for example, my home town. It's a small town of 5-10k people, and from the recent Google maps it's a little over a mile in diameter. Meanwhile, the state in which in which it's located is around 250 miles in diameter (except that its squarish.) Take a penny and tape it to your wall. That's the size difference, and that's just one state, not an entire continent. For a continent, tape a quarter to skyscraper.
I'd like to think Ralnoth in the game is probably about the same size. The currently expanded Ralnoth is about 12 rooms wide and 25 tall; let's say 15 for the sake of argument. Meanwhile, the entire game is perhaps 400 rooms across and tall, neglecting portals to islands and the like. This makes the entire Alter Aeon mainland around 30 miles in diameter.
We have entire mountain ranges, jungles, swamps, other cities, and the shores of two oceans on the mainland. All within 15 miles of the central city of Ralnoth. Starting to see the picture?
A more reasonable continent size is on the order of 500-1000 miles. Even for a 500 mile wide continent, the scale of Ralnoth would imply walking through a minimum of 7500 rooms to get from one side to the other. This is probably not reasonable from a gameplay standpoint, so we need to find a different approach.
The simplest and easiest is to simply define cities to be much larger than they are. If we declare Ralnoth to be ten miles across instead of 1, we end up with a much more reasonable room count. But in that case, even the smallest house represents half a square mile of land area.
A better approach seems to be to change the size of roads and paths, such that the desired distances can be achieved. This kills the dull/boring wilderness areas and gets people out into the world to do something interesting.
I think there's a couple of different ways to handle this. One is to have different sized rooms and render them as best you can. Perhaps using terrain or other flags you can automatically decide what rooms are what size.
But it seems to me that a far better and easier way is to separate large and small sized zones from each other. When you leave one, you end up in the other with a different set of maps. For example, leaving a town shows the town zooming to a small size relative to the forest you're walking in. So many games have done this in the past, that it's a trivially obvious feature. It also happens to be a very good candidate for my overall mapping problems.
I'll let you all know if it works out.
Sunday, March 29, 2009
Clients and Newbies
I recently released a new client update for Alter Aeon, one that includes (but is not limited to) the following cool changes:
- vastly upgraded automap
- vote menu
- 'last command select'
- various settings now save
- function key alias mapping
This really is a big step forward in the evolution of the client, and I've received a lot of compliments on it. Unfortunately, there is a problem with this client release, and it all goes back to the problem of newbie retention. But before we go into that, here's some background on the current state of newbies on the game.
-----
There appears to be three primary types of new player right now:
1) Sighted players from mudlists, who generally already have a client. These players usually don't download the custom client, and if they did they probably would go back to their own client anyway.
2) Blind players who use blind clients. They generally don't use the AA client, as it has crap for blind player support.
3) True new players who probably have never mudded before. These people are the long-term future, as the number of mudlist players is shrinking and blind players will eventually get their eyes fixed. This is also by far the largest market to tap. You don't compete with World of Warcraft unless you're hitting up ordinary sighted people.
The mudlist players will pretty much do their own thing. There's a limit to how much you can do with them, as they have their own opinions already. Many are unrecoverable, as they have been damaged by some other mud.
Blind players we seem to be doing reasonably well with. I have no complaints here, other than making the AA client work really well with readers would probably help a good amount.
The third category, by far the biggest market, is the problem. Since they have no prior mudding experience, odds are very good they downloaded the client, which shows up easily in my stats. I can also track logins based on web page hits. If this class of player is sticking around, I'll see it by looking for newbie players using the client.
This is exactly what I don't see. I see the expected players log in with the client, just as they should. There's a large initial dropout rate, but a good percentage of them level and play for a while. After that they all disappear. We're not keeping people entertained.
I suspect what's going on is they play for a while, run out of stuff to do or don't see the point, and bail. That pretty much describes my first mudding experiences; I got a low level character and basically just wandered around looking at stuff. None of the text meant anything in particular to me, and I would wander ridiculous places because I didn't know where to go or what to do. I didn't even know what the point of the game was.
I clearly need to add a lot more statistics tracking and try to see where the dropoffs are occuring - what level ranges, number of logins, etc. With this information in hand we can improve the introductory areas; but so far, my initial numbers indicate that the dropoffs happen for the newbie areas that are well tested and considered in good shape. So what is really going on?
-----
The final piece of the puzzle revolves around the massively improved automap function in the new client. I tried really hard to play with the mouse for a while, and it worked as well as could be expected. Unfortunately, when using and concentrating on exploring using the map, the entire text window (which contains everything that's important) disappears. Not from the client, but from your mind. It simply isn't as important as the automap. Looking back at it takes effort.
So say you're exploring with the map. You see unexplored spots on the map, you know you can go that way, and you click the button to go there. Nothing happens. You click the button again - you just want to go explore that part of the map - and nothing happens again. How irritating.
Nothing happens because you're fighting. But unless you take your eyes off the map and look back to the main window, you don't notice it. You just get irritated that you didn't move when you clicked the button. And all the scrolling crap in the main window, highlighted and all, really doesn't mean anything to you.
I've got a few things in the works to combat this, including audio sounds for fighting, changing the buttons in combat, and changing the area description to list various positions such as "Combat!", sleeping, resting, etc. That will have to wait until next week though, as I've got a lot of web work to get caught up on as well.
It's definitely a good problem to chew on.
- vastly upgraded automap
- vote menu
- 'last command select'
- various settings now save
- function key alias mapping
This really is a big step forward in the evolution of the client, and I've received a lot of compliments on it. Unfortunately, there is a problem with this client release, and it all goes back to the problem of newbie retention. But before we go into that, here's some background on the current state of newbies on the game.
-----
There appears to be three primary types of new player right now:
1) Sighted players from mudlists, who generally already have a client. These players usually don't download the custom client, and if they did they probably would go back to their own client anyway.
2) Blind players who use blind clients. They generally don't use the AA client, as it has crap for blind player support.
3) True new players who probably have never mudded before. These people are the long-term future, as the number of mudlist players is shrinking and blind players will eventually get their eyes fixed. This is also by far the largest market to tap. You don't compete with World of Warcraft unless you're hitting up ordinary sighted people.
The mudlist players will pretty much do their own thing. There's a limit to how much you can do with them, as they have their own opinions already. Many are unrecoverable, as they have been damaged by some other mud.
Blind players we seem to be doing reasonably well with. I have no complaints here, other than making the AA client work really well with readers would probably help a good amount.
The third category, by far the biggest market, is the problem. Since they have no prior mudding experience, odds are very good they downloaded the client, which shows up easily in my stats. I can also track logins based on web page hits. If this class of player is sticking around, I'll see it by looking for newbie players using the client.
This is exactly what I don't see. I see the expected players log in with the client, just as they should. There's a large initial dropout rate, but a good percentage of them level and play for a while. After that they all disappear. We're not keeping people entertained.
I suspect what's going on is they play for a while, run out of stuff to do or don't see the point, and bail. That pretty much describes my first mudding experiences; I got a low level character and basically just wandered around looking at stuff. None of the text meant anything in particular to me, and I would wander ridiculous places because I didn't know where to go or what to do. I didn't even know what the point of the game was.
I clearly need to add a lot more statistics tracking and try to see where the dropoffs are occuring - what level ranges, number of logins, etc. With this information in hand we can improve the introductory areas; but so far, my initial numbers indicate that the dropoffs happen for the newbie areas that are well tested and considered in good shape. So what is really going on?
-----
The final piece of the puzzle revolves around the massively improved automap function in the new client. I tried really hard to play with the mouse for a while, and it worked as well as could be expected. Unfortunately, when using and concentrating on exploring using the map, the entire text window (which contains everything that's important) disappears. Not from the client, but from your mind. It simply isn't as important as the automap. Looking back at it takes effort.
So say you're exploring with the map. You see unexplored spots on the map, you know you can go that way, and you click the button to go there. Nothing happens. You click the button again - you just want to go explore that part of the map - and nothing happens again. How irritating.
Nothing happens because you're fighting. But unless you take your eyes off the map and look back to the main window, you don't notice it. You just get irritated that you didn't move when you clicked the button. And all the scrolling crap in the main window, highlighted and all, really doesn't mean anything to you.
I've got a few things in the works to combat this, including audio sounds for fighting, changing the buttons in combat, and changing the area description to list various positions such as "Combat!", sleeping, resting, etc. That will have to wait until next week though, as I've got a lot of web work to get caught up on as well.
It's definitely a good problem to chew on.
Wednesday, February 4, 2009
Graphical automap
After a long hiatus, I got a new version of the Alter Aeon Mudding Client built and released for Windows. This version fixes a lot of bugs, but is still subject to the quirks and peculiarities of whatever version of Windows it runs on. This is really irritating, as the URL linking is black (and hence invisible) on some versions of windows, but not on others.
The big update is the graphical automapper, which renders squarish blocks based on terrain and some flags. Auto-generated tiles are what I'm using right now, and all things considered it's not terrible, though it's also not great. Here is a link to a screenshot of the Linux/X version of the client, to give you a rough idea. The Windows version looks similar, with slightly different font sizes and different borders/edges.
As usual, with a new release comes new bugs: the control keys appear to no longer work, the 'vanishing url' problem is still present, diagonal exits don't work (this requires a server and protocol change), and a number of more minor bugs have been reported. It's also lacking blind/visually impaired support, though the default support is already much better than for the old client.
All this (except for blind support, which may be impossible) needs to be fixed before it's suitable to take over the place of the old client. It's getting a lot closer though.
One thing I'm grudgingly coming to terms with is the player desire for triggers and variables in the client. Normal mudders aren't going to use it until it has reasonable features for scripting. I really don't want to encourage scripting, but it may be a necessary evil to getting people to use it.
My hope with this project is that low quality graphics and a visual display are better than no display whatsoever. The game is complex, well balanced, and solid - people who play it tend to stick around and find it entertaining for long periods of time. Getting people into it seems the hardest part.
A possible vote in favor of a bad client being better than no client comes from friends of existing players. I can't even remember how many times I've been told some version of the following:
"I tried to get my friend into it, but he/she just couldn't understand how a game that's only words could possibly work."
Even if it's just a cheesy icon indicating where you are, it at least gives non-mudders a reference: everyone's played old school tile-based games. I hope.
Another major concern I have is that I'm now officially encroaching on what I'd call the territory of other, vastly better funded games. This marks the first real foray into adding graphics to the system; right now that consists of low quality, autogenerated graphics, using a mapping system which doesn't even work reliably (due to area linearity and such.) What I have is crude, primitive, and unartistic.
People can get low quality graphics anywhere; and attempting to compete with modern high-quality rendered 3D games is a non-starter, unless you have a reasonably large budget. Further, the game as it stands is fundamentally not designed to be 3D rendered. It would take a major rework to add support for that, and likely result in the destruction of most of the interesting game content.
So the big question becomes: what is the next step for the client, after it's stable and usable by the default population?
Right now, the only big hitter I have on my list is another type of automap, one that uses the generated area maps from the Alter Aeon World Maps page. The server would send approximate X/Y coordinate pairs, and the client could map them to the appropriate position on the generated maps. This would give people an idea of which areas they were near, and approximately where they were at.
Beyond that, I really don't know. I'm sure something will present itself.
The big update is the graphical automapper, which renders squarish blocks based on terrain and some flags. Auto-generated tiles are what I'm using right now, and all things considered it's not terrible, though it's also not great. Here is a link to a screenshot of the Linux/X version of the client, to give you a rough idea. The Windows version looks similar, with slightly different font sizes and different borders/edges.
As usual, with a new release comes new bugs: the control keys appear to no longer work, the 'vanishing url' problem is still present, diagonal exits don't work (this requires a server and protocol change), and a number of more minor bugs have been reported. It's also lacking blind/visually impaired support, though the default support is already much better than for the old client.
All this (except for blind support, which may be impossible) needs to be fixed before it's suitable to take over the place of the old client. It's getting a lot closer though.
One thing I'm grudgingly coming to terms with is the player desire for triggers and variables in the client. Normal mudders aren't going to use it until it has reasonable features for scripting. I really don't want to encourage scripting, but it may be a necessary evil to getting people to use it.
My hope with this project is that low quality graphics and a visual display are better than no display whatsoever. The game is complex, well balanced, and solid - people who play it tend to stick around and find it entertaining for long periods of time. Getting people into it seems the hardest part.
A possible vote in favor of a bad client being better than no client comes from friends of existing players. I can't even remember how many times I've been told some version of the following:
"I tried to get my friend into it, but he/she just couldn't understand how a game that's only words could possibly work."
Even if it's just a cheesy icon indicating where you are, it at least gives non-mudders a reference: everyone's played old school tile-based games. I hope.
Another major concern I have is that I'm now officially encroaching on what I'd call the territory of other, vastly better funded games. This marks the first real foray into adding graphics to the system; right now that consists of low quality, autogenerated graphics, using a mapping system which doesn't even work reliably (due to area linearity and such.) What I have is crude, primitive, and unartistic.
People can get low quality graphics anywhere; and attempting to compete with modern high-quality rendered 3D games is a non-starter, unless you have a reasonably large budget. Further, the game as it stands is fundamentally not designed to be 3D rendered. It would take a major rework to add support for that, and likely result in the destruction of most of the interesting game content.
So the big question becomes: what is the next step for the client, after it's stable and usable by the default population?
Right now, the only big hitter I have on my list is another type of automap, one that uses the generated area maps from the Alter Aeon World Maps page. The server would send approximate X/Y coordinate pairs, and the client could map them to the appropriate position on the generated maps. This would give people an idea of which areas they were near, and approximately where they were at.
Beyond that, I really don't know. I'm sure something will present itself.
Tuesday, October 14, 2008
Maps and area layout
One of our players, Woem, mailed me a handful of area descriptions and maps a couple of days ago. I finally managed to get through my email, and have put them online here:
http://dentinmud.org/maps
They're the maps of the Aggerazzi Swamp, the Fire Plane, and the Ice Plane. They're hand drawn, but really well done.
This got me thinking about mapping in general. Muds are particularly difficult to map because of the ad-hoc room linkage and arbitrary room sizes, not to mention lack of sanity checks to detect overlapping rooms. I'd like to be able to do it anyway because people are so visual, but there are some problems.
One of the biggest problems is that building is already so restricted, in that we generally have cardinal directions, without any real ability to place slopes or other such three-dimensional constructs. Another really big problem is that we don't build rooms with any regard for size; rooms just are, and they hold whatever we need them to hold. Further, we can hook them up to anything else without regard for space constraints.
To top this all off, Alter Aeon has over 30k rooms that are -already built-, and over two thirds of those are in working, sane areas. Rebuilding those areas with some (as yet ill-defined) positional features is really out of the question in the short term.
This has brought me back to thinking about automatic determination of room sizes, or at least room positions within areas. Some of this can be done based on terrain types; most individual areas can be mapped pretty well using a simple combination of flags and terrain to give rough sizes. The real clobbering comes when you attempt to glue areas together.
So, assuming I can automatically place the rooms in individual areas, how do we place areas overall? It turns out that we happen to have positional information for most areas anyway, so all that remains is to tie the area coordinates to the room positions within each area. The game can then scan for room linkages where the areas are markedly disjoint, and log it as a typo or bug.
Ta-da! With that, we should be able to correlate the real room position with the real area positions, and while the hookups wont be perfect, it will give us a very good idea of where the worst disconnects are.
Hopefully I can get some time to try this out in the near future. It's probably a handful of hours to do it and get it right, then I can hand off the cleanup to some of the worldbuilders and let them straighten out the worst of it.
http://dentinmud.org/maps
They're the maps of the Aggerazzi Swamp, the Fire Plane, and the Ice Plane. They're hand drawn, but really well done.
This got me thinking about mapping in general. Muds are particularly difficult to map because of the ad-hoc room linkage and arbitrary room sizes, not to mention lack of sanity checks to detect overlapping rooms. I'd like to be able to do it anyway because people are so visual, but there are some problems.
One of the biggest problems is that building is already so restricted, in that we generally have cardinal directions, without any real ability to place slopes or other such three-dimensional constructs. Another really big problem is that we don't build rooms with any regard for size; rooms just are, and they hold whatever we need them to hold. Further, we can hook them up to anything else without regard for space constraints.
To top this all off, Alter Aeon has over 30k rooms that are -already built-, and over two thirds of those are in working, sane areas. Rebuilding those areas with some (as yet ill-defined) positional features is really out of the question in the short term.
This has brought me back to thinking about automatic determination of room sizes, or at least room positions within areas. Some of this can be done based on terrain types; most individual areas can be mapped pretty well using a simple combination of flags and terrain to give rough sizes. The real clobbering comes when you attempt to glue areas together.
So, assuming I can automatically place the rooms in individual areas, how do we place areas overall? It turns out that we happen to have positional information for most areas anyway, so all that remains is to tie the area coordinates to the room positions within each area. The game can then scan for room linkages where the areas are markedly disjoint, and log it as a typo or bug.
Ta-da! With that, we should be able to correlate the real room position with the real area positions, and while the hookups wont be perfect, it will give us a very good idea of where the worst disconnects are.
Hopefully I can get some time to try this out in the near future. It's probably a handful of hours to do it and get it right, then I can hand off the cleanup to some of the worldbuilders and let them straighten out the worst of it.
Subscribe to:
Posts (Atom)