16 Mar, 2009, Idealiad wrote in the 1st comment:
Votes: 0
A member of the TIGSource forums put up a tutorial on procedural map generation recently, and since it looked interesting and I hadn't really tried something like this I gave it a go. However as I'm a fairly bunk coder I'd like to get some feedback on the overall way I went about it. I'd appreciate any comments. Also I'm curious what other methods you have to generate simple maps like this.

This is in Python with graphics rendering by the pyglet module, any comments on the Python itself is more than welcome as well.

Here is the code at pastebin: http://pastebin.com/m27fa5e72

Some specific questions I have:

1. I use dictionaries to store the coordinates and tile type for each resolution. Is this OK?

2. Currently if you want to change the map size and so on it does involve hand tweaking some numbers in the Map class – is there a more general way to write the class so it accepts different Map sizes more gracefully?

3. While the code for creating each resolution is very similar, it is just different enough in my method that I repeat the general idea of the code several times. Is there a better way to abstract the creation of each resolution so that I could have just one block of code for creating a resolution, that I would call with different arguments for each resolution?
16 Mar, 2009, elanthis wrote in the 2nd comment:
Votes: 0
I like the tutorial. Very well written for novices to the field – I wish more people wrote articles like that, especially for MUD developers. Heck, even I learned something from it! (The treasure-location trick mentioned at the bottom. Never thought of that.)

1) dictionaries are not particularly efficient for this purpose. A two-dimensional array (array of arrays) would be faster, or better yet just a single array with a breadth approach. (that is, the index used is y * width + x). empty grid locations would just have a None value in them. Dictionaries are only going to be more efficient when you have HUGE arrays of mostly-empty tiles.

2) why not just make them parameters to the constructor?

3) not sure what exactly you need help with here. it's just the same algorithm with different numerical constants, using the previous iteration's output. The BiggestTile stuff would just be a loop that has no previous iteration… a simple if statement could handle that for you.
19 Mar, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I'd read about the A* trick before, don't remember where. I agree that it's pretty clever.

Automatically generated dungeons etc. are a pretty cool concept. Unfortunately hard to apply the nifty grid-based cave maps to MUDs due to the difficulty of using coordinates etc.
19 Mar, 2009, Vassi wrote in the 4th comment:
Votes: 0
David Haley said:
Unfortunately hard to apply the nifty grid-based cave maps to MUDs due to the difficulty of using coordinates etc.


I'm curious as to what you mean by that sentence. I'm rebuilding my block\land system and it's very co-ord dependent.
19 Mar, 2009, David Haley wrote in the 5th comment:
Votes: 0
Oh, I didn't mean from an internal perspective, that's pretty easy. I meant from a player interface perspective. It's one thing to navigate wide-open spaces like overland and have coordinates. It's another to have a cave or dungeon with twisty passages (whee!) where coordinates actually matter in how you actually move around.

EDIT: also, I'm assuming a purely text-based interface without very-fancy cursor control like the various NetHack-y games, which you typically don't really find on MUDs.
19 Mar, 2009, elanthis wrote in the 6th comment:
Votes: 0
Yeah, but you can use the algorithm in a room-based MUD just fine with some tweaks. Either avoid making large open areas, or run a post-analyzer that finds the open grid clusters and converts them into a single room with a "large open area" description.
19 Mar, 2009, David Haley wrote in the 7th comment:
Votes: 0
Yes, the idea of collapsing large grid clusters is good, and what I would do if I were to do this. But I just find it unfortunate that you'd be losing a lot of the coolness of the 2d generation. Basically, err, maybe I'm just getting dissatisfied with the relatively limited expressive power of a pure text-paragraph-based mechanism.
19 Mar, 2009, elanthis wrote in the 8th comment:
Votes: 0
Yeah. Text sucks. Picture is worth a thousand words sort of thing. It used to be that MUDs were far more flexible than graphical games could be, but that gap as closed quite a bit. All it would take is a free repository of quality, style-consistent models and a good tile-based map tool (a la NWN) and I'd be gone from the MUD scene entirely. :p Sadly, that free repository is unlikely to ever appear. Artists seem far less inclined to releasing large amounts of freely usable "source" than programmers, for some reason I can't explain.
19 Mar, 2009, David Haley wrote in the 9th comment:
Votes: 0
Where MUDs still beat graphical games is that to create new effects, you just write out "and a massive fireball consumes the room". You don't have to actually draw new content, you just say it and it's there.

To be honest I'd be pretty happy even with 2d content – 3d would be even nicer but I don't need to go there to be happy. :wink:

It is interesting that programmers are typically more inclined to share than artists. I also wonder why that is.
19 Mar, 2009, Vassi wrote in the 10th comment:
Votes: 0
David Haley said:
Where MUDs still beat graphical games is that to create new effects, you just write out "and a massive fireball consumes the room". You don't have to actually draw new content, you just say it and it's there.

To be honest I'd be pretty happy even with 2d content – 3d would be even nicer but I don't need to go there to be happy. :wink:

It is interesting that programmers are typically more inclined to share than artists. I also wonder why that is.


Having the good fortune to be working with an artist I would say it's because it's more work. Maybe its just my experience or because I covet the art enough to not want to 'piss off' the artist, but if we have art done for a particular piece of the GUI I'm five times less likely to want to redo it because that means we'll need new art.

Art is not as malleable as code. You can find a snippet you like and just make a few changes here or there but it isn't often you can get away with finding some art and then just changing the colors, the art - more often than not - has to be customized quite a bit more.

That said, before I teamed up with my current artist I had been looking around and it really is not *that* expensive to find someone to do some work for you. The only thing is you better know exactly what you're going for, or you'll have to pay for every iteration.

In truth, though, who knows. We'd have to ask a bunch of artists that question and then write some software to average out their responses and make graphs. (using clipart)

Edit: One of the best ways to get art is to work with a new artist who is looking to shore up their portfolio coming out of college.
19 Mar, 2009, David Haley wrote in the 11th comment:
Votes: 0
I wouldn't go anywhere near saying it's "more work". The things you said later made more sense, but I can't even start agreeing with the first claim. The idea that it's easier to customize code than art is more plausible, but that doesn't explain why programmers usually share more than artists do.
19 Mar, 2009, Vassi wrote in the 12th comment:
Votes: 0
I think it's mostly psychological. Code is much more intangible than artwork, which is 'right there'. I guess its the difference between giving someone "some soda" and giving someone "a coke". Does that make any sense?

That said, there are tons of free web templates, color gradients, wallpapers, clip art, photoshop shapes, and other such out there so I wouldn't really say that artists don't share their work, they just don't really share their time. I mean, when someone comes on these boards with a problem people mostly offer some tips and occasionally a line or two of code, very seldom does someone say "just send me your code and I'll write that class for you", which I think is kind of what we're complaining about "Why won't some artist make some artwork I can use.?"

Edit: If you browse places like deviantart most artists let you use their stuff with permission and credit given. I'll revert to the argument that the kind of art we want, animations and other such, is so specific as to not really be customizable. If all you want is simple sprites, you can get those on many RPG\Game maker sites.
19 Mar, 2009, David Haley wrote in the 13th comment:
Votes: 0
Vassi said:
I guess its the difference between giving someone "some soda" and giving someone "a coke". Does that make any sense?

Uh. Not really :tongue:

Vassi said:
I'll revert to the argument that the kind of art we want, animations and other such, is so specific as to not really be customizable.

I'll happily agree with this, it's just not the question we were asking.

That said, there is a very large open source programming effort, where you really can go ask for features etc., but I don't know of any equivalent in the art world.
0.0/13