31 Aug, 2012, Idealiad wrote in the 1st comment:
Votes: 0
I've started to play around with drawing wilderness maps (i.e. overland maps). There are many programs out there to do this but I've started with GIMP. Getting a basic outline up without drawing every jig and jag is quite fast.



This tutorial was where I started:

http://www.youtube.com/watch?v=BlYRWvpj1...

And this is a good community site:

www.cartographersguild.com
17 Sep, 2012, dnicolai wrote in the 2nd comment:
Votes: 0
I really love making these kinds of overland maps. I recently began building one for a MUD I want to build based on the D&D 4e Nentir Vale. I even am trying to get a clean version of SMAUG or AFKMud up so I can start building out the areas to make it all work.

That all aside, I really can't say how much Photoshop is a great tool for this, too. You can set the map that you drew to whatever size you want and then just start drawing, it takes a bit of practice to get it all down, but I can get a 1000x1000 map finished in about two hours now if I do it by zooming in an drawing or just 10-20 minutes using the lasso tools. For roads, I always suggest zooming in, but for stuff like mountain ranges and things like that, the lasso works great.

I also built a Pokemon map for Johnto/Kanto for a game I wanted to build way back using good ole' Microsoft Paint, but again, Photoshop did it WAY faster when I redrew the map a few weeks ago.

If anyone wants help using Photoshop to build their overland maps, just let me know.
08 Mar, 2013, KaVir wrote in the 3rd comment:
Votes: 0
I just came across this Planet Map Generator, it's pretty nifty - the maps look very good, and you can zoom and move around. Could be very cool for a sci-fi game with space travel and random worlds.
15 Mar, 2013, salindor wrote in the 4th comment:
Votes: 0
Once apun a time I wrote a java app that let you paint rom based world maps. You might have to tweak the symbols as it was based on the game I was playing at the time. If your interested and someone told me the best place to post it, I don't mind sharing it. I looked at the code repositories and those looked like muds not utilities.

Though I haven't touched it since college and my style has changed so much since then I almost cringe when I look at old code.

Salindor
15 Mar, 2013, Idealiad wrote in the 5th comment:
Votes: 0
15 Mar, 2013, salindor wrote in the 6th comment:
Votes: 0
Cool thanx. I have submitted it under the generators area. I hope it will be useful to you.

Salindor
16 Mar, 2013, Nathan wrote in the 7th comment:
Votes: 0
I downloaded your code earlier just to see what it looked like. Decided to dump it into Eclipse and I've been working on cleaning up the code, with an eye to reducing the amount of code. There seem to be an awful lot of …ActionPerformed(…) methods for having just one type of thing. I added an edit menu with a preferences dialog in where you can change the font. It seemed odd to have that in the main window.
16 Mar, 2013, quixadhal wrote in the 8th comment:
Votes: 0
How modular is the output part of the code? It might be fun to add support for other formats as well…

Or does it just dump a known ROM wilderness snippet format?

I actually think a world painter that output normal area files would be fun… you could have it output the room descriptions as either a dynamically generated text block or an ANSI map to make it look like it's a special area.

EDIT: darn typos.
16 Mar, 2013, Nathan wrote in the 9th comment:
Votes: 0
quixadhal said:
How modular is the output part of the code? It might be fun to add support for other formats as well…

Or does it just dump a known ROM wilderness snippet format?

I actually think a world painter that output normal area files would be fun… you could have it output the room descriptions as either a dynamically generated text block or an ANSI map to make it look like it's a special area.

EDIT: darn typos.


Unfortunately in the case of Salindor's code it's outputting a particular format, not sure if it's just generic ROM or more specific. If you know Java, it just uses a PrintWriter and outputs a line at a time (with some parts predetermined, like the section headers). Although the more generic save option appears to just output lots of numbers What kind of modular are you thinking? Since the "rendering" for rooms on the screen is just a colored character it would need work to get towards just the graphic output of the one mentioned below.

I've seen it mentioned on here before, but there's a similar map making tool for Realms of Kaos (http://realmsofkaos.net/forum/viewtopic....). It's pretty and does kind of the same thing. I don't know if its output format is used directly that way by their game (which I am not familiar with), but it's basically some numbers and then a 5 or 6 field comma separated line for each room. Not too different from Salindor's basic save code. Their program requires .NET framework 3.5 though.
17 Mar, 2013, quixadhal wrote in the 10th comment:
Votes: 0
Well, here's what I was thinking.

While some muds have code that reads in a map format (graphic file, text, whatever), and then has special code to recognize when you're on an "overland" map, letting the MUD render the "map" display… I'd rather generate a normal area file that doesn't require anything special to work.

In other words, just let each room have the "map" as its description string, if you want it to look like an overland map. If, OTOH, you want text descriptions, you'd need to write code to dynamically generate them from the map data, but again… just output that as description strings.

If the output routines are flexible enough, you could easily output as Rom, Smaug, Circle, or even LpMUD room/area files. In effect, you'd create templates which would take the data and plug it into the right spots for the dump.

I did something along those lines in the opposite direction, ages ago, for my own Dikurivative.

And yes, dumping a map for every room takes up space, but… 16G of RAM is not that expensive. :)
17 Mar, 2013, salindor wrote in the 11th comment:
Votes: 0
The code to generate the world file isn't that hard, basically internally to it, it is just a giant rectangle. In the mud I wrote this for the room descriptions were all auto-generated. That is why it only prints out DESC where the room description would go. Since they already had the map printing code and auto-desc I didn't see a point in reinventing the wheel.

If you look at the function jFinalSaveMenuActionPerformed, it could easily be replaced with whatever output your mud uses. The actual part that matters in the output is on line 589. The rest of it is just ROM area formatting stuff.

Sadly its output is specific to ROM… BUT, its internal representation of the world is codebase agnostic.
17 Mar, 2013, salindor wrote in the 12th comment:
Votes: 0
well I should I think ROM, it was targeting the mud I was coding for at the time which is ROM based.
17 Mar, 2013, Nathan wrote in the 13th comment:
Votes: 0
quixadhal said:
Well, here's what I was thinking.

While some muds have code that reads in a map format (graphic file, text, whatever), and then has special code to recognize when you're on an "overland" map, letting the MUD render the "map" display… I'd rather generate a normal area file that doesn't require anything special to work.

In other words, just let each room have the "map" as its description string, if you want it to look like an overland map. If, OTOH, you want text descriptions, you'd need to write code to dynamically generate them from the map data, but again… just output that as description strings.

If the output routines are flexible enough, you could easily output as Rom, Smaug, Circle, or even LpMUD room/area files. In effect, you'd create templates which would take the data and plug it into the right spots for the dump.

I did something along those lines in the opposite direction, ages ago, for my own Dikurivative.

And yes, dumping a map for every room takes up space, but… 16G of RAM is not that expensive. :)


You're saying some muds send the description for a "normal" room, but send map data as the description for overland rooms? If we use a generator like this, what's the difference between overland rooms and not anyway? It would make sense that a generator for this would do the description generation if it was dependent on the "terrain", yes. You design the output routine for flexibility, not hope it's good enough. In any case, how would the output know where to put the stuff, wouldn't I need a template with replace markers of some kind?

When you say dump a map for every room, you mean like the display some muds have every time you look at the room and it shows you your position and a 5 room radius around you?
17 Mar, 2013, quixadhal wrote in the 14th comment:
Votes: 0
In some MUD's, some areas are special "overland" areas which pull data from a map source instead of actual rooms. As you wander around this "overland" map, it prints a larger (20x10 is common) view of the terrain as an ANSI map *instead* of any text description.

If you didn't want to special case such areas, you could simple pre-generate those maps and save them as the room descriptions in a "normal" area format. It would take extra RAM, but… RAM is cheap.
18 Mar, 2013, salindor wrote in the 15th comment:
Votes: 0
Yup, more precisely, the one this was written for generated an automap for everything except indoors and city and gave a generic description if one wasn't provided.

Quixadhal is right, if you wanted this to be more generic; you would simply write the autogenerated code in its place. The disadvantage to doing this is when you go to modify the world map to add cities and dungeons. If it is autogenerated, then when you go to link in the new dungeons/cities, then the descriptions and map generation automatically adjust.

The way we dealt with it, is we painted the world map so we would have continents and rivers with mountains and such. Basically I looked at some maps similar to the autogenerator posted earlier and manually painted my world. After the world was constructed I considered how civilization would take hold in such a world (for example placing cities near rivers) and how roads would be connected between them. I may have gone a little overboard as I have always been obsessed with realism and it wasn't until later I realized it was possible for too much realism (thank you FFXI for making me walk 30 minutes every time I logged in just to level…)

Salindor
18 Mar, 2013, quixadhal wrote in the 16th comment:
Votes: 0
LOL!

I used to hold true to the holy grail of "realism" too, until I got older and lost the patience to walk 30 minutes just to level. :)

Now, my belief is to make things realistic where it doesn't annoy people. Having a giant world to explore is great! Having to walk it on foot, all the time, is not so great. So, if you want people to have to go to town to do stuff, and you want a world big enough to spend hours wandering… you need a way to let them get back to town easily and quickly, and ideally to get back out there again.

One solution is portals. If your game is in a fantasy world, you can let the users open a portal every so often, pop back to town, do their stuff, and go back through the portal to the room they were in before. The graphical game Diablo did this quite well.

If you're sci-fi, you can always call for transport. A taxi, a helicopter, whatever…. something that lets you get back to town quickly and easily.

I'm sure other options will come to mind for other genres… the idea is to make it as easy for the player to PLAY the game, as possible. Folks these days have jobs/lives/kids and short attention spans… let them spend their 90 minutes a day adventuring, not slogging across the map.

But yes, to get back on topic, the problem of editing the world is there… however, I envision only using the generator to create your initial world (or new expansions to the terrain), not to edit stuff that's already in play. Once you have a big wilderness, you can go hand-edit rooms for cities, roads, dungeons, and all the other fun areas that should be the majority of your content. You'd only need to replace the "wilderness" if you chose to DELETE content, rather than changing it.
28 May, 2013, duwnel wrote in the 17th comment:
Votes: 0
The problem that I ran into with generating maps like those from straight clouds on their own was that they either would overflow the edge of my defined world (which beyond those points is just water, leaving a squared off corner of land), or if I wanted to wrap, they never tiled cleanly.

The solution I used was a perlin noise generator across 3 dimensions to render clouds, then a rolling particle mask to create a non-circular gradient. This meant that by the edge of the map it was all water, but I still had a large continent. The result could be compared to a volcano forming an island in the ocean. One side effect is outliers small islands or shallows that pop up far from the main continent, and these are the result of slightly smaller peaks in the perlin noise, and can be brushed out. You can do similar with photoshop with various gradient tools, and finding the edges to have some beautifully unique lands Some portions ease into the ocean by way of beach, others drop quickly like cliff sides.

Another fun little algorithm to play with for creating a wilderness is the Drunkard's Walk (great for creating mountain ranges). Give it a start position and let it wander for however many steps you like. Give it a terrain type and it'll create it where to meanders. Might be useful to have it roll a particle out from each direction as it steps to raise up the surrounding terrain in a small area, so that mountains roll to hills roll to plains, or similar. Great for rivers and lakes too…

Generating worlds can be fascinating, and provide for interesting results. Something I'm currently playing with is the value of each area as an indicator of terrain. So, below a threshold is of course water, above it is land. But land isn't smooth plains may form at a known span of altitudes, and there may be valleys that aren't low enough for water. Early (primitive) roads were made through these low areas because they're easy to travel, and roads are easier to travel upon than plains. Since everything in the wilderness is based on X and Y Coordinates, each square (representative of a certain distance) may differently affect the traveler's speed. Following a road, however, will offer no such impediment, and will (generally) be the fastest route between two nearby cities. Likely, I'll be able to modify the rolling particle algorithm to find a path through the valleys between City A and City B.

As for Realism, it's all about what you do with it. For instance, if you're in a massive and expansive world, if you travel for 30 minutes to get somewhere, you should have passed something interesting on the way. Consider games like The Elder Scrolls. You may walk for quite a time and not seem to get far from your starting point, but you have encounters and places to explore on the way. It may not be where you're headed, but it offers you something to do one the way. And traveling shouldn't be all about walking. Maybe you ride a horse when you can afford one. Or perhaps you've started to change into something else, and have wings to carry you faster. How fast can a wizard travel with a haste spell?

I'm with Quixadhal in that there's nothing worse than doing nothing in the little bit of time you have. Portals are great to get you back to a town, but there has to be more than one town; what does the base town that you were in when you started offer you after 6 months or regular play? Consider the Temple in Dikurivatives you're always recalling to the same place, around which everything else was built. Does it have to be this way in a wilderness? You have the opportunity to have different cities with new challenges and areas to explore as you grow. It doesn't mean you have to have them now, just start developing them as your player base begins to need them. Alternatively, if you have a group of players that enjoys crafting, make this a way that they can level and grow, and let them build the city they wish to see at a place that they want to see it. Let it thrive or fail based on their ability to attract other players. Watch towns combine and grow into cities. Then add an element of danger by spawning gangs into certain parts of those cities and let them grow or die out based on whether the players attempt to drive them out.

The point is, it's all what you make of it. Wilderness is only wilderness until its settled. Create the option to settle the overland, and watch it form into something useful, not just a means of getting among areas.
08 Sep, 2013, Ripley wrote in the 18th comment:
Votes: 0
I know this topic is a little old, regardless, having gone through this recently I wanted to share my experience.

I developed a wilderness system for Luminari MUD, based on perlin noise. I wanted a large map and the ability to generate, on the fly, one room at any given coordinate without generating rooms at any other coordinates. What I ended up doing is combining ridged perlin noise and regular, billowy perlin noise, then masking that with a weighted average of a radial gradient and a rectangular gradient. Theae gradients were distorted slightly with 1-d perlin noise. I then use a gradient for temperature and another noise function for moisture to determine the sector types. Here is the map I have generated using these techniques:



Each color is a sector type.

they way it is coded, we can overwrite the generated sectors on a coordinate by coordinate basis. The above map is generated by the mud every boot.
09 Sep, 2013, Runter wrote in the 19th comment:
Votes: 0
Not bad. Maybe you should release notes on the algorithm you used. :)
09 Sep, 2013, Ripley wrote in the 20th comment:
Votes: 0
Once I have finished with it all I do plan on writing something general up. Having a wilderness like this really opens up a lot of possibilities.
0.0/26