I don't really have much to say on the topic of population density in fantasy worlds, but I did recently run into a number of posts on the topic that got me thinking about the relationship between civilization and wilderness in fantasy campaigns again, specifically about the attractiveness of a "Points of Light" setting.
When I think "fantasy world" my brain conjures up images of small villages where peasants work the surrounding fields. In an "established" country, those small villages are fairly numerous (never more than, say, 3-5 miles apart, see the Bavarian example above) and they tend to lie close to roads or rivers leading to bigger towns and cities. There is constant trade and commerce, tolls are collected by local rulers, monsters are generally not too close to civilization unless there's something driving them there, etc.
In a "Points of Light" setting things are vastly different. Small unfortified villages are virtually non-existent because they would be overrun too easily by the hordes of monsters roaming almost everywhere. Instead people cluster into either well-fortified "homesteads" or "castles" and come out to "work the fields" only under guard, or into bigger fortified "towns" that encompass those fields in their defensive perimeter. These settlements are fairly rare, usually 30-40 miles apart, much like the Russian example above. Trade between the settlements is a dangerous undertaking requiring lots of guards, therefore the settlements are much more self-sufficient.
There are many more things differentiating my "default" world from this "Points of Light" world, things like roads and who built them, things like countries or indeed a working feudal system. But I'll have to shelve those for another post. Suffice it to say that I find myself very much attracted to the "Points of Light" idea these days and much less to the "pastoral settled farm lands" version of a fantasy world I grew up with. I guess that means that my fantasy campaign is about to turn into a medieval version of Gamma World?
Tuesday, November 26, 2013
Thursday, November 21, 2013
Ternary Operator in Go
A long time ago someone asked how to do the ternary operator in Go. In C or Java you can write
max = a > b ? a : b;
to select the larger of the two. In Go you have to write an if instruction instead:
if a > b {
max = a
} else {
max = b
}
The following is probably my most horrible (public) programming suggestion ever, certainly not worthy of my ambitions as a teacher of clear programming style:
max = map[bool]int{true: a, false: b}[a > b]
But at least it won the "This is beautiful abuse. Simultaneously I feel respect and disgust." and the "That is awesomely disgusting." prices back then. Of course someone else pointed out that it should really be
max = map[bool]int{true: func()(int){return a}, false: func()(int){return b}}[a > b]()
instead, but I didn't think that's worth the effort since we're already evaluating both for the condition. They were, however, correct to mention it.
Why post this? No big reason, I've just been doing more Go hacking again recently and was reminded of this incident. Also my suggestion to include all of this in the FAQ was eventually turned down by the Go folks (probably a good thing in retrospect) but I wanted to leave a record of it behind on the web in any case. :-)
max = a > b ? a : b;
to select the larger of the two. In Go you have to write an if instruction instead:
if a > b {
max = a
} else {
max = b
}
The following is probably my most horrible (public) programming suggestion ever, certainly not worthy of my ambitions as a teacher of clear programming style:
max = map[bool]int{true: a, false: b}[a > b]
But at least it won the "This is beautiful abuse. Simultaneously I feel respect and disgust." and the "That is awesomely disgusting." prices back then. Of course someone else pointed out that it should really be
max = map[bool]int{true: func()(int){return a}, false: func()(int){return b}}[a > b]()
instead, but I didn't think that's worth the effort since we're already evaluating both for the condition. They were, however, correct to mention it.
Why post this? No big reason, I've just been doing more Go hacking again recently and was reminded of this incident. Also my suggestion to include all of this in the FAQ was eventually turned down by the Go folks (probably a good thing in retrospect) but I wanted to leave a record of it behind on the web in any case. :-)
Subscribe to:
Posts (Atom)