Author: momikey

Fractal rivers with Inkscape

I’m not good with graphics. I’m awful at drawing. Maps, however, are one of the many areas where a non-artist like myself can make up for a lack of skill by using computers. Inkscape is one of those tools that can really help with map-making (along with about a thousand other graphical tasks). It’s free, it works on just about any computer you can imagine, and it’s very much becoming a standard for vector graphics for the 99% of people that can’t afford Adobe products or an art team.

For a map of a nation or world, rivers are an important yet difficult part of the construction process. They weave, meander, and never follow a straight line. They’re annoying, to put it mildly. But Inkscape has a tool that can give us decent-looking rivers with only a small amount of effort. To use it, we must harness the power of fractals.

Fractals in nature

Fractals, as you may know (and if you don’t, a quick search should net you more information than you ever wanted to know), are a mathematical construct, but they’re also incredibly good at modeling nature. Trees follow a fractal pattern, as do coastlines. Rivers aren’t exactly fractal, but they can look like it from a great enough distance, with their networks of tributaries.

The key idea is self-similarity; basically, a fractal is an object that looks pretty much the same no matter how much you zoom in. Trees have large branches, and those have smaller branches, and then those have the little twigs that sometimes branch themselves. Rivers are fed by smaller rivers, which are fed by streams and creeks and springs. The only difference is the scale.

Inkscape fractals

Inkscape’s fractals are a lot simpler than most mathematical versions. The built-in extension, from what I can tell, uses an algorithm called midpoint displacement. Roughly speaking, it does the following:

  • Find the midpoint of a line segment,
  • Move that point in a direction perpendicular to the line segment by a random amount,
  • Create two new segments that run from either endpoint to the new, displaced midpoint,
  • Start over with each of the new line segments.

The algorithm subdivides the segment a number of times. Each new stage has segments that are half the length of the old ones, meaning that, after n subdivisions, you end up with 2^n^ segments. How much the midpoint can be moved is another parameter, called smoothness. The higher the smoothness, the less the algorithm can move the midpoint, resulting in a smoother subdivision. (In most implementations of this algorithm, the amount of displacement is scaled, so each further stage can move a smaller absolute distance, though still the same relative to the size of the segment.)

The method

  1. First things first, we need to start drawing an outline of the shape of our river. It doesn’t have to be perfect. Besides, this sketch is going to be completely modified. Here, you can see what I’ve started; this was all done with the Line tool (Shift+F6):

    Designing the path

  2. Once you’ve got a rough outline, press Enter to end the path:

    Finishing the outline

  3. If you want to have curved segments, that’s okay, too. The fractal extension works just fine with them. Here, I’ve dragged some nodes and handles around using the path editor (F2):

    Adding some curves

  4. Now it’s time to really shake things up. Make sure your path is selected, and go to Extensions -> Modify Path -> Fractalize:

    Fractalize in the menus

  5. This displays a dialog box with two text inputs and a checkbox. This is the interface to the Fractalize extension. You have the option of changing the number of subdivisions (more subdivisions gives a more detailed path, at the expense of more memory) and the smoothness (as above, a higher smoothness means that each displacement has less room to maneuver, which makes the final result look smoother). “Live preview” shows you the result of the Fractalize algorithm before you commit to it, changing it as you change the parameters. Unless your computer seems to be struggling, there’s no reason not to have it on.

    The Fractalize extension

  6. When you’re happy with the settings, click Apply. Your outlined path will now be replaced by the fractalized result. I set mine to be blue. (Shift+click on the color swatch to set the stroke color.)

    The finished product

And that’s all there is to it! Now, you can go on from here if you like. A proper, natural river is a system, so you’ll want to add the smaller rivers that feed into this one. Inkscape has the option to snap to nodes, which lets you start a path from any point in your river. Since Fractalize keeps the endpoints the same, you can build your river outwards as much as you need.

Exoplanets: an introduction for worldbuilders

With the recent discovery of Kepler-452b, planets beyond our solar system—called extrasolar planets or exoplanets—have come into the news again. This has already happened a few times: the Gliese 581 system in 2007 (and again a couple of years ago); the early discoveries of 51 Pegasi b and 70 Virginis b in the mid 1990s; and Alpha Centauri, our nearest known celestial neighbor, in 2012.

For an author of science fiction, it’s a great time to be alive, reminiscent of the forties and fifties, when the whole solar system was all but unknown and writers were only limited by their imaginations. Planets, we now know, are just about everywhere you look. We haven’t found an identical match to Earth (yet), and there’s still no conclusive evidence of habitation on any of these newfound worlds, but we can say for certain that other planets are out there. So, as we continue the interminable wait for the new planet-hunters like TESS, the James Webb Space Telescope, Gaia, and all those that have yet to leave the drawing board, let’s take a quick look at what we know, and how we got here.

Before it all began: the 1980s

I was born in 1983, so I’ve lived in four different decades now, and I’ve been able to witness the birth and maturity of the study of exoplanets. But younger people, those who have lived their whole lives knowing that other solar systems exist beyond our own, don’t realize how little we actually knew not that long ago.

Thirty years ago, there were nine known planets. (I’ll completely sidestep the Pluto argument in this post.) Obviously, we know Earth quite well. Mars was a frontier, and there was still talk about near-term manned missions to go there. Venus had been uncovered as the pressure cooker that it is. Jupiter was on the radar, but largely unknown. Mercury was the target of flybys, but no orbiter—it was just too hard, too expensive. The Voyager mission gave us our first up-close looks at Saturn and Uranus, and Neptune would join them by the end of the decade.

Every star besides the Sun, though, was a blank slate. Peter van de Kamp claimed he had detected planets around Barnard’s Star in the 1960s, but his results weren’t repeatable. In any case, the instruments of three decades past simply weren’t precise enough or powerful enough to give us data we could trust.

What this meant, though, was that the field was fertile ground for science fiction. Want to put an Earthlike planet around Vega or Arcturus? Nobody could prove it didn’t exist, so nobody could say you were wrong. Solar systems were assumed to be there, if below our detection threshold, and they were assumed to be like ours: terrestrial planets on the inside, gas giant in the outer reaches, with one or more asteroid belts here or there.

The discoveries: the 1990s

As the 80s gave way to the 90s, technology progressed. Computers got faster, instruments better. Telescopes got bigger or got put into space. And this opened the door for a new find: the extrasolar planet. The first one, a huge gas giant (or small brown dwarf, in which case it doesn’t count), was detected in 1989 around the star HD 114762, but it took two years to be confirmed.

And then it gets weird. In 1992, Aleksander Wolszczan and Dale Frail discovered irregularities in the emissions of a pulsar designated PSR B1257+12. There’s not much out there that can mess up a pulsar’s, well, pulsing, but planets could do it, and that is indeed what they found. Two of them, in fact, with a third following a couple of years later, and the innermost is still the smallest exoplanet known. (I hope that will be changed in the not-too-distant future.) Of course, the creation of a pulsar is a wild, crazy, and deadly event, and the pulsar planets brought about a ton of questions, but that need not concern us here. The important point is that they were found, and this was concrete proof that other planets existed beyond our solar system.

Then, in the middle of the decade, the floodgates opened a crack. Planets began to be discovered around stars on the main sequence, stars like our sun. These were all gas giants, most of them far larger than Jupiter, and many of them were in odd orbits, either highly eccentric or much too close to their star. Either way, our solar system clearly wasn’t a model for those.

As these “hot Jupiters” became more and more numerous, the old model had to be updated. Sure, our solar system’s progression of terrestrial, gaseous, and icy (with occasional asteroids thrown in) could still work. Maybe other stars had familiar systems. After all, the hot Jupiters were an artifact of selection bias: the best method we had to detect planets—radial velocity, which relies on the Doppler effect—was most sensitive to large planets orbiting close to a star. But the fact that we had so many of them, with almost no evidence of anything resembling our own, meant that they had to be accounted for in fiction. Thus, the idea of a gas giant having habitable moons begins to grow in popularity. Again, there’s no way to disprove it.

Acceptance: the 2000s

With the turn of the millennium, extrasolar planets—soon to be shortened to the “exoplanet” moniker in popular use today—continued to come in. Advances in technology, along with the longer observation times, brought the “floor” of size further and further down. Jupiter analogues became fairly common, then Saturn-alikes. Soon, Uranus and Neptune had their clones in distant systems.

And Earth 2 was in sight, as the major space agencies had a plan. NASA had a series of three instruments, all space-based, each increasingly larger, that would usher in a new era of planetary research. Kepler would be launched around 2005-2007, and it would give us hard statistics on the population of planets in our galaxy. The Space Interferometry Mission (SIM) would follow a few years later, and it would find the first true Earthlike planets. Later, in the early to mid 2010s, the Terrestrial Planet Finder (TPF) would locate and characterize planets like Earth, showing us their atmospheres and maybe even ocean coverage. In Europe, ESA had a similar path, with CoRoT, Gaia, and Darwin.

And we know how that turned out. Kepler was delayed until 2009, and it stopped working a couple of years ago. SIM was defunded, then canceled. TPF never got out of the planning stages. Across the ocean, CoRoT launched, but it was nowhere near as precise as they thought; it’s given us a steady stream of gas giants, but not much else. Gaia is currently working, but also at a reduced capacity. Darwin met the same sad fate as TPF.

But after all that doom and gloom had passed, something incredible happened. The smallest of the new discoveries were smaller than Neptune, but still larger than Earth. That gap in mass (a factor of about 17) is an area with no known representatives in our solar system. Logically, this new category of planet quickly got the name “super-Earth”. And some of these super-Earths turned up in interesting places: Gliese 581 c was possibly within its star’s habitable zone, as was its sister planet, Gliese 581 d. Sure, Gliese 581 itself was a red dwarf, and “c” has a year that lasts less than one of our months, but it was a rocky planet in an orbit where liquid water was possible. And that’s huge.

By the end of 2009, super-Earths were starting to come into their own, and Kepler finally launched, promising to give us even more of them. Hot Jupiters suddenly became oddballs again. And science fiction has adapted. Now there were inhabited red dwarf planets, some five to ten times Earth’s mass, with double the gravity. New theories gave rise to imagined “carbon planets”— bigger, warmer versions of Titan, with lakes of oil and mountains of diamond—or “ocean worlds” of superheated water, atmospheric hydrogen and helium, and the occasional bit of rocky land.

Worldbuilding became an art of imagining something as different from the known as possible, as all evidence now pointed to Earth, and indeed the whole solar system, as being an outlier. For starters, it’s a yellow dwarf, a curious part of the main sequence. Just long-lived enough for planets to form and life to evolve, yet rare enough that they probably shouldn’t. Red dwarfs, by contrast, are everywhere, they live effectively forever, and we know a lot of them have planets.

Here and now: the 2010s

Through the first half of this decade, that’s pretty much the status quo. Super-Earths seem to be ubiquitous, “gas dwarfs” like Neptune numerous, and hot Jupiters comparatively rare. There’s still a lot of Kepler data to sift through, however.

But now we’ve almost come full circle. At the start of my lifetime, planets could be anything. They could be anywhere. And planetary systems probably looked a lot like ours.

Then, we started finding them, and that began to constrain our vision. The solar system was now rare, statistically improbable or even impossible. Super-Earths, though, were ascendant, and they offered a new inspiration.

And, finally, we come to Kepler-452b. It’s still a super-Earth. There’s no doubt about that, as even the smallest estimate puts it at 1.6 Earth masses. But it’s orbiting a star like ours, in a spot like ours, and it joins a very select group by doing that. In the coming years, that group should expand, hopefully by leaps and bounds. But it’s what 452b states that’s important: Earthlike planets are out there, in Earthlike orbits around Sunlike stars.

For worldbuilders, that means we can go back to the good old days. We can make our fictional worlds match our own, and nobody can tell us that they’re unlikely to occur. Thirty years ago, we could write whatever we wanted because there was no way to disprove it. Now, we can write what we want because it just might be proven.

What a time to build a world.

Let’s make a language – Part 4b: Nouns (Isian)

Keeping in our pattern of making Isian a fairly simple language, there’s not going to be a lot here about the conlang’s simple nouns. Of course, when we start constructing longer phrases (with adjectives and the like), things will get a little hairier.

Noun roots

Isian nouns can look like just about anything. They don’t have a set form, much like their English counterparts. But we can divide them into two broad classes based on the last letter of their root morphemes: vowel-stems and consonant-stems. There’s no difference in meaning between the two, and they really only differ in how plural forms are constructed, as we shall see.

Cases

For all intents and purposes, Isian nouns don’t mark case. We’ll get to pronouns in a later post, and they will have different case forms (again, similar to English), but the basic nouns themselves don’t change when they take different roles in a sentence.

The plural (with added gender)

The plural is where most of Isian’s noun morphology comes in. For consonant-stems, it’s pretty simple: the plural is always -i. From last week, we have the nouns sam “man” and talar “house”. The plurals, then, are sami “men” and talari “houses”. Not much else to it.

For vowel-stems, I’ve added a little complexity and “naturalism”. We have three different choices for a plural suffix. (This shouldn’t be too strange for English speakers, as we’ve got “-s”, “-es”, and oddities like “-en” in “oxen”.) So the possibilities are:

  • -t: This will be the most common marker. If all else fails, we’ll use it. An example might be seca “sword”; plural secat.

  • -s: For vowel-stems whose last consonant is a t or d, the plural becomes -s. (We’ll say it’s from some historical sound change.) Example: deta “cup”; plural detas.

  • -r: This one is almost totally irregular. Mostly, it’ll be on “feminine” nouns; we’ll justify this by saying it’s the remnant of a proper gender distinction in Ancient Isian. An example: mati “mother”; matir “mothers”.

As we go along, I’ll point out any nouns that deviate from the usual -i or -t.

Articles

Like English, Isian has an indefinite article, similar to “a/an”, that appears before a noun. Unlike the one in English, Isian’s is always the same: ta. It’s never stressed, so the vowel isn’t really distinct; it would sound more like “tuh”.

We can use the indefinite when we’re talking about one or more of a noun, but not any specific instances: ta sam “a man”; ta hut “some dogs”. (Note that we can also use it with plurals, which is something “a/an” can’t do.)

The counterpart is the definite article, like English the. Isian has not one but two of these, a singular and a plural. The singular form is e, and the plural is es; both are always stressed.

These are used when we’re talking about specific, identifiable nouns: e sam “the man”; es sami “the men”.

More words

That’s all there really is to it, at least as far as the basic noun structure. Sure, it’ll get a lot more complicated once we through in adjectives and relative clauses and such, but we’ve got a good start here. So, here’s a few more nouns, all of which follow the rules set out in this post:

  • madi “mother” (pl. madir)
  • pado “father” (pl. pados)
  • shes “woman”
  • tay “child” (pl. tays)
  • chaley “friend”
  • gol “head”
  • bis “eye”
  • ula “mouth”
  • fesh “hand”
  • pusca “foot”
  • her “cat”
  • atul “flower”
  • seca “sword”
  • deta “cup” (pl. detas)
  • jeda “shirt” (pl. jedas)

ES6 iterators and generators

With ES6, JavaScript now has much better support for iteration. Before, all we had to work with was the usual for loop, either as a C-style loop or the property-based for...in. Then we got the functional programming tools for arrays: forEach, map, reduce, and so on. Now we have even more options that can save us from needing an error-prone C-style loop or the cumbersome for...in.

The new loop

ES6 adds a new subtype of for loop: for...of. At first glance, it looks almost exactly the same as for...in, but it has one very important difference: for...in works on property names, while for...of loops over property values. Prettified JavaScript variants (like CoffeeScript) have had this for years, but now it comes to the base language, and we get to do things like this:

var vowels = ['a','e','i','o','u','y'];

for (var v of vowels) {
    if (v != 'y') {
        console.log(v);
    } else {
        if (Math.random() < 0.5) {
            console.log("and sometimes " + v);
        }
    }
}

Most developers will, at first, use for...of to iterate through arrays, and it excels at that. Just giving the value in each iteration, instead of the index, will save the sanity of thousands of JavaScript programmers. And it’s a good substitute for Array.forEach() for those of you that don’t like the FP style of coding.

But for...of isn’t just for arrays. It works on other objects, too. For strings, it gives you each character (properly supporting Unicode, thanks to other ES6 updates), and the new Map and Set objects work in the way you’d expect (i.e., each entry, but in no particular order). Even better, you can write your own classes to support the new loop, because it can work with anything that uses the new iterable protocol.

Iterables

Protocols are technically a new addition to ES6. They lurked behind the scenes in ES5, but they were out of sight of programmers. Now, though, they’re front and center, and the iterable protocol is one such example.

If you’ve ever written code in Java, C#, C++, Python, or even TypeScript, then you already have a good idea of what a protocol entails. It’s an interface. An object conforms to a protocol if it (or some other object up its prototype chain) properly implements the protocol’s methods. That’s all there is to it.

The iterable protocol is almost too easy. For a custom iterable object, all you need to do is implement a method called @@iterator that returns an object that meets the iterator protocol.

Okay, I know you’re thinking, “How do I make a @@iterator method? I can’t use at-signs in names!” And you’re right. You can’t, and they don’t even want you to try. @@iterator is a special method name that basically means “a symbol with the name of iterator“.

So now we need to know what a symbol is. In ES6, it’s a new data type that we can use as a property identifier. There’s a lot of info about creating your own symbols out there, but we don’t actually need that for the iterable protocol. Instead, we can use a special symbol that comes built-in: Symbol.iterator. We can use it like this:

var myIterable = {
    [Symbol.iterator]: function() {
        // return an iterator object
    }
}

The square brackets mean we’re using a symbol as the name of the property, and Symbol.iterator internally converts to @@iterator, which is exactly what we need.

Iterators

That gets us halfway to a proper iterable, but now we need to create an object that conforms to the iterator protocol. That’s not that hard. The protocol only requires one method, next(), which must be callable without arguments. It returns another object that has two properties:

  • value: Whatever value the iterator wants to return. This can be a string, number, object, or anything you like. Internally, String returns each character, Array each successive value, and so on.

  • done: A boolean that states whether the iterator has reached the end of its sequence. If it’s true, then value becomes the return value of the whole iterator. Setting it to false is saying that you can keep getting more out of the iterator.

So, by implementing a single method, we can make any kind of sequence, like this:

var evens = function(limit) {
    return {
        [Symbol.iterator]: function() {
            var nextValue = 0;
            return {
                next: function() {
                    nextValue += 2;
                    return { done: nextValue > limit, value: nextValue };
                }
            }
        }
    }
}

for (var e of evens(20)) {
    console.log(e);
} // prints 2, 4, 6..., each on its own line

This is a toy example, but it shows the general layout of an iterable. It’s a great idea, and it’s very reminiscent of Python’s iteration support, but it’s not without its flaws. Mainly, just look at it. We have to go three objects deep to actually get to a return value. With ES6’s shorthand object literals, that’s a bit simplified, but it’s still unnecessary clutter.

Generators

Enter the generator. Another new addition to ES6, generators are special functions that give us most of the power of iterators with much cleaner syntax. To make a function that’s a generator, in fact, we only need to make two changes.

First, generators are defined as function*, not the usual function. The added star indicates a generator definition, and it can be used for function statements and expressions.

Second, generators don’t return like normal functions. Instead, they yield a value. The new yield keyword works just like its Python equivalent, immediately returning a value but “saving” their position. The next time the generator is called, it picks up right where it left off, immediately after the yield that ended it. You can have multiple yield statements, and they will be executed in order, one for each time you call the function:

function* threeYields() {
    yield "foo";
    yield "bar";
    yield "The End";
}

var gen = threeYields();

gen.next().value; // returns "foo"
gen.next().value; // returns "bar"
gen.next().value; // returns "The End"
gen.next().value; // undefined

You can also use a loop in your generators, giving us an easier way of writing our evens function above:

var evens = function(limit) {
    return {
        [Symbol.iterator]: function*() {
            var nextValue = 0;
            while (nextValue < limit) {
                nextValue += 2;
                yield nextValue;
            }
        }
    }
}

It’s still a little too deep, but it’s better than writing it all yourself.

Conclusion

Generators, iterators, and the for...of loop all have a common goal: to make it easier to work with sequences. With these new tools, we can now use a sequence as the sequence itself, getting its values as we need them instead of loading the whole thing into memory at once. This lazy loading is common in FP languages like Haskell, and it’s found its way into others like Python, but it’s new to JavaScript, and it will take some getting used to. But it allows a new way of programming. We can even have infinite sequences, which would have been impossible before now.

Iterators encapsulate state, meaning that generators can replace the old pattern of defining state variables and returning an IIFE that closes over them. (For a game-specific example, think of random number generators. These can now actually be generators.) Coroutines and async programming are two other areas where generators come into play, and a lot of people are already working on this kind of stuff. Looking ahead, there’s a very early ES7 proposal to add comprehensions, and these would be able to use generators, too.

Like most other ES6 features, these aren’t usable by everyone, at least not yet. Firefox and Chrome currently have most of the spec, while the others pretty much have nothing at all. For now, you’ll need to use something like Babel if you need to support all browsers, but it’s almost worth it.

Faith and fantasy

Religion is one of those things that, as an author or game designer, you have to treat very carefully. The risk of offense is too great, especially in the politically-correct, offense-first world of today. It’s easy to fall into a trap of pigeonholing real-world religions. “Evil, Arabian-looking bad guys that act like Muslims” is practically a genre trope at this point; two examples that I’ve read include the Fanim of R. Scott Bakker’s Prince of Nothing trilogy and the Krasians of Peter V. Brett’s Demon Cycle. “Evil, hierarchical church that looks Roman Catholic” isn’t exactly uncommon, either.

But that’s not really the subject of this post. Sure, the popular religions in the world are the way they are, and they’re easy to relate to, easy to understand, because we see them every day. But different cultures, especially in different worlds than our own, are going to have different ways of looking at religion, faith, philosophy, and the supernatural. And their beliefs will shape their society, just as ours, historically, have shaped our own.

Of God and gods

In the West, there are three major religions: Christianity, Judaism, and Islam. In addition, there are a number of others that have significantly less popular appeal. The East, conversely, gives us the trio of Hinduism, Buddhism, and Shinto, along with a host of minor faiths. (And by “minor”, I mean they have fewer followers, not that they’re less important or less valuable.) And, of course, we also have the “non-religions” of atheism and agnosticism, as well as a number of systems of belief that might better be grouped under “philosophy”.

Even the largest of religions is not monolithic, however. Christianity has a whole spectrum of sects (“denominations”), and many Americans have become familiar with the major divisions of Islam (Sunni and Shia). Some can even spot the difference between some of the different sects of modern Judaism (Orthodox, Reform, etc.). We know comparatively far less about the other side of the world, though; most people in the US probably think of all Buddhists as Zen, for example.

In fantasy literature, religion—when it is mentioned at all—usually only gets a passing nod. There might be the occasional oath, prayer, or swear, but a story where the beliefs of the people are not the focus often ignores those beliefs. And that’s fine. If it’s not an important worldbuilding detail, then there’s probably not much reason to put it in.

Conversely, games, especially tabletop role-playing games, make religion an integral part of the story. D&D (and its offshoots, like Pathfinder) has lists of deities, each with their own domain, and these almost always function like the pantheons of old, except with added benefits for certain believers. (In D&D, for example, clerics and paladins usually must follow a deity, and they receive divine blessings and spells in return.) In a way, despite there being a very detailed summary of religion, it’s abstracted away into a game mechanic.

And again, there’s nothing wrong with that. Players shouldn’t be forced to study theology just to play a game. But fantasy, both literature and gaming, has a problem understanding the link between religion and society, and that link was a very real, very important part of the period of history favored by fantasy.

One to many

We all know the “origin stories” of the major Western religions, whether creation, crucifixion, or revelation. But all of these, as well as those less-familiar faiths of the world, had a major impact on the development of society. The Middle Ages, that favorite era of fantasy literature and games alike, was shaped by religion. In many ways, you could even say it was defined by religion.

When fantasy posits a pantheon (like D&D), that actually breaks the world for their other main assumption: the feudal monarchy. Feudalism, serfdom, the divine right of kings, knighthood, and all those other conceits of medieval Europe are based on a thousand years of Christianity.

“The end is coming soon, so get ready,” goes the common Christian refrain, and that’s largely been true since the 30s. No, not the 1930s, but the 30s, as in 30 AD. Christianity has always had a strain of the apocalyptic—the last book of the Bible is, after all, supposed to be a vision of the End of Days—though it has waxed and waned through the ages. In the medieval period, it was mostly waxing. Plague, famine, pestilence, and war were facts of life, especially for the lower classes, and there wasn’t much they could do about it. “The meek shall inherit the earth” was the closest thing to hope for the future that many people had.

If you replace the strict belief in God (whose eternal good was countered by the increasing influence of the Devil) with a nebulous—if effectual—pantheon, then things change dramatically. Get rid of the Church, the Pope, and all the other trappings of medieval Christianity, and all of society will develop differently.

Changing the game

In medieval Europe, the Church had supreme power, and all of it was centered on the Pope. He could make kings (or break them), crown emperors, canonize martyrs, or call crusades. His announcements of doctrine, the papal bulls, were regarded as nothing less than official interpretations of scripture. And he had one ultimate, terrifying weapon: excommunication.

All that it did was ban a person or group of people from Communion, effectively ostracizing them from the Church. But in a world where the eternal soul was seen as infinitely more important than its mortal frame, this was enough to turn even the most hardened of hearts. Rebels, heretics, willful kings, and political enemies all faced the threat of excommunication, and almost every one of them quailed in the face of such a punishment. Rebellions could end entirely once word came from Rome that their leaders had been cast out of the Church, no longer able to receive the blessings of Christ and thus condemned to Hell for all eternity. Even whole cities (such as Florence) were put under that threat simply to scare their rulers into complying with the Church’s wishes or dogma.

Besides the Church’s chief weapon (I’ll spare you the Monty Python jokes) and its total control of doctrine, it also changed Europe by bringing in its own social structure. Monasteries, hermitages, nunneries, convents, and abbeys all had their roles to play, and they were all part of the Church. And these weren’t always what you’d think from movies. Monks could be rich, nuns literate, and hermits not always loners living in caves. One of them even got elected as pope: Celestine V, who quit after a few months. (Every other pope from 1294 onwards ruled until he died or was cast out, until Benedict XVI not long ago.)

The Christian church and faith was the single largest influence on the development of the Middle Ages. Because of it, the Black Death was asserted as a sign of coming Armageddon, as was the famine that preceded it, and the Mongol horde that may have brought it. Without the church, the culture of monasticism wouldn’t have been so prevalent, nor would the orders of crusading knighthood, such as the Templars, Hospitallers, and the Teutonic Order exist.

Indeed, even the period’s systems of economy and government are indebted to Christianity. Feudalism lasted as long as it did mostly because people were taught that it was the natural order of things. Serfs were born to be serfs, and nobles to be nobles, and there were shelves full of books explaining all the ways you could see how that was true. Nobles, for instance, were taller, heavier, and healthier. Nobody bothered to note that this was because of nutrition and the often harsh working conditions of the peasantry. Rather, it was taken as part of the divine plan.

The realm of fiction

Fantasy likes to take the feudal society of Europe (especially the later, post-plague society where feudalism began to falter) and make it its own, without taking along the religious aspect that made it possible. In essence, you could say that medieval, feudal Europe came about because of Constantine, the emperor of Rome who converted himself and then his empire to Christianity.

Without a strong, central Church, you lose most of the foundations of the setting. If every city or nation can make its own doctrine, then you have very little world unity and shared culture. With more than one deity to worship, with no fixed scripture proclaiming the end of the world and the promise of a utopic afterlife, then there is no motivation for serfdom, for the glory of crusade.

Even technology is affected by the change in faith. Cathedrals, the defining monument of the Middle Ages, were built because of religion. Sure, a polytheistic culture might build great temples, and they would likely come to many of the same discoveries about building, but would they have the same styles? Likely not. They certainly wouldn’t be laid out in the shape of a cross, like the European cathedrals.

Some areas might become more advanced if you lift the strictures of Christianity. Machinery that could aid in work was often overlooked, simply because there were always more laborers to throw at a problem. The science of astronomy was held back by the belief that the stars were the realm of God, thus unknowable to man. And how would banking develop if the Christian constraints on usury didn’t exist to create a niche (and a stereotype) filled by Jews?

Magic, of course, is an obvious addition to any fantasy world, but it also existed (not really, but in people’s minds) in the Middle Ages. It’s something that was well-known, but totally forbidden. Fireball-wielding mages would have to be fit into the religious world-view, and where would they go? The sorcerers of the aforementioned Prince of Nothing series are excommunicated by default, but it’s easy to imagine a setting where the wizards are seen as messengers or even avatars of God or the gods.

Like so many other topics in worldbuilding, a few decisions change the outcome completely. Monotheism, logically speaking, probably leads to one of the same outcomes as it did in our world. Polytheism is reflected in ancient Rome and even modern India, as well as most fantasy. A lot of other ideas require more thought. If God is everywhere, in everything, then who needs temples or churches? If the world is full of spirits that inhabit every living thing, how can you eat and still live with yourself? (Yes, that means an animist world could have even stricter dietary laws than Islam. Think of Hinduism’s sacred cows.)

The length of time that a religion has existed will also play a role in a society’s development. The older something is, the more likely it is to change. Faiths fracture, sectarianism grows, especially if there is no central authority. A polytheistic culture is prone to develop “local” gods; Athena, patron of Athens, is a good example. New religions exist in a state of flux, as everyone vies for the right to be considered orthodox, often with disastrous consequences for those that lose. (How many Gnostics do you know?)

Rituals, prayers, and even the calendar can also be affected. The word “holiday” literally means “holy day”, and that’s where the oldest of them come from. Christmas and Easter are the ones everybody knows, although few know that they’re replacements for “pagan” holidays celebrating the winter solstice and the vernal equinox. But Lent and Ash Wednesday were far more important in the Middle Ages. All Saints’ Day, another pagan substitution, has become so marginalized that we celebrate the night before it instead: Halloween. Different religions, though, will have their own holy times: Ramadan, Hanukkah, and so on. As for prayers, who do you pray to when you have a hundred gods to choose from? Who is the one to memorize all the appropriate rituals?

End of this day

As always, there’s a lot to think about, and your choice is one of how deep to go. Obviously, if religion isn’t a major part of your world, then there’s not too much you have to do. But religion might be a significant part of your characters’ world, and it might show in the way they act, think, talk.

Faith and logic don’t always have a lot in common, it’s true. This is one place where the latter makes the former possible. It’s not your faith you’re worried about. Presumably, you’ve already decided that, and it shouldn’t have any bearing on your created world. Logically working out the beliefs of your world and their effects, though, can make for a deeper immersion into your story. It might even make some people think.

Let’s make a language – Part 4a: Nouns (Intro)

A noun, as we learned in school, is a person, place, or thing. Of course, there’s more to it than that. Later in our education, ideas and abstract concepts get added in, but the general notion of “noun” remains the same. All natural languages have nouns, and they almost always use them for the same thing. How they use them is where things get interesting.

The Noun Itself

Nouns are going to be words. In fact, they’re probably going to be the biggest set of words in a language, owing to the vast array of people and objects and ideas in the world. The most basic nouns (i.e., the ones we’re discussing today) are represented by a single morpheme, like “dog” or “car”. Later on, we’ll get into more complicated nouns that are built up (derived) from other words, but we’ll keep it simple this time.

So we have a morpheme, which we’ll call the root. This root is the core bit of meaning; if we change it completely, we change the whole noun. We can modify the root a little, however, and some languages require us to do this. In English, for example, a noun like dog refers to a single dog. If we want to talk about four of them, we have to write dogs. Similarly, the Latin word aqua, meaning “water”, becomes aquam if it’s used as the object of a sentence.

Most languages that mark these shades of meaning (subject vs. object, one vs. many) do so via suffixes, like the English plural -s. A few work more with prefixes; these are mostly lesser-known languages in Africa, Asia, and the Americas. English is a little weird in having yet another way of marking the distinction of number: sound change, as in words like goose and geese. (It inherits this from its Germanic roots.) Semitic languages, particularly Arabic, take this a step further, but Semitic morphology is a vastly overused element of conlangs, so I won’t discuss it much here.

Isolating languages, on the other hand, don’t really go in for this kind of thing. Their nouns mostly stay in the same form, but they can still represent the same ideas in different ways. If you’re working with a language like this, then the grammatical categories we’ll see in the rest of this post will likely be formed by additional words rather than suffixes or prefixes.

Number

Probably the most basic (and most common) distinction made for nouns is that of number. Not every language has it—aficionados of Japanese know that the correct plural of “manga” is still “manga”—and that’s certainly a valid possibility for a conlang.

Besides an absence of number, what possibilities are there? First, there’s a division between one and many, singular and plural, with the singular taken as the default. That’s very common, and it’s familiar from English and most other European languages. But it’s not the only way. Some other number markings include:

  • A dual number, representing two of something. Arabic and Sanskrit have this, and there are remnants of it in English, with words like “both” and “either”.

  • Marking both singular and plural, each differently, as in Swahili mtoto “child” vs. watoto “children”. In this case, the singular prefix isn’t part of the root.

  • A distinction between “mass” and “count” (or “uncountable” and “countable”) nouns. Mass nouns like English “water”, logically enough, don’t appear in the plural.

  • A category of number specifically referring to “a few” or “some”. This is called the paucal, and it pops up here and there. Usually, it means anywhere from two to ten or so, probably because people have ten fingers.

Some languages mark for two of a noun, and some mark for a few. Three is an obvious next choice, and there are indeed a handful of languages with a “trial” number, but they only use it in pronouns (which are the subject of a later post), not the nouns themselves. Four is right out.

Gender

Gender in language has almost nothing to do with gender in anything else. For many languages, it’s almost completely arbitrary. Sure, the word for “man” might be in the masculine gender, and “woman” in the feminine, but just about anything else is possible. German Mädchen “girl” is neuter, as is Old English wīf “woman, wife”. Irish has cailín “girl” as a masculine noun, while Spanish gente “people” is feminine, no matter what kind of people it’s talking about. Of course, things don’t have to be this confused. A lot of the gender oddities are caused by historical sound changes. Conlangs don’t generally have this problem, although some authors like to add the semblance of such things.

For those languages that have gender, having two of them is common. Usually, that’s masculine and feminine. Some languages instead distinguish between animate and inanimate nouns, though there aren’t too many of these left around. Swedish managed to merge masculine and feminine at some point, resulting in the dichotomy of “common” and “neuter”.

Neuter is a popular third gender; it might be analyzed as an absence of gender, except that some nouns that do have a sex are classified under it, like those examples above. With a neuter gender, sexless items such as inanimate objects often end up there, but they can also fit into one of the others.

Languages can also make more than two or three distinctions of gender. You could have, for example, a language that has four, where every noun is either masculine or feminine, and either animate or inanimate. Some languages (notably the Bantu languages, including Swahili) have a wide variety of categories that might be called gender, though they’re more of a noun “class”.

Case

Anybody who ever took Latin in school knows about case. And they probably hate it. Case is a way of marking the role a noun has in a sentence, such as subject or object. It can also be used to show finer points of meaning, such as those marked in English by prepositions like “in” or “with”.

A lot of languages don’t have case, or only use it in certain places. English doesn’t for its nouns, but does for pronouns (“he”, “him”, “his”), and that’s actually not that rare. Other languages seem to love cases; Finnish has a dozen or so, depending on who’s counting. Generally speaking, it seems that inflectional languages are especially fond of large case systems. Isolating languages make do with something like prepositions. Conlangs can be absolutely anywhere on the spectrum, from caseless languages to the monstrosity of Ithkuil, which has 96. (Granted, Ithkuil is intended to be unrealistic.)

Closing Thoughts

There’s more to nouns than meets the eye, and I’ve only covered about half of it. Wikipedia’s page on grammatical category has a wealth of knowledge about everything above, plus all the stuff I didn’t cover.

What it can’t tell you, though, is which of these categories nouns in your conlang should have. The answer to that depends on a number of factors. For an auxiliary language, you’ll want to be pretty simple. Alien conlangs can (should, even) break the Western mold.

Number is a fairly easy choice, but there’s a hidden complexity in there. (Just look at all the plural exceptions in English!) Gender has its problems, some of them even political, but it also has the potential to make things truly interesting. A matriarchal culture, for instance, might take offense at the idea that “masculine” is the default gender in a language. Cases make a language harder to learn, I would say, but they do feel like they add a “precision” to meaning. It’s possible to go overboard, though. (Actually, studying Finnish grammar isn’t the worst idea for a budding conlanger. It worked for Tolkien.)

The next two posts are going to cover basic nouns in Isian and Ardari, along with a bunch of added vocabulary. Those, combined with the pointers in this post, should be enough to stimulate your own imagination. After that, we’ll move on to verbs, so that we can make our nouns do things.

More fun with constexpr

Continuing from my earlier post, here’s another look at how we can abuse the compiler and C++11’s compile-time abilities. This one might even be useful!

The Problem

Trigonometry functions are common in a lot of programming. On modern hardware, they’re usually highly optimized, too. But C++ developers are taught to use the compiler as much as possible. That’s why we have templates and constexpr, after all. So, can we do trig calculations this way?

The answer, of course, is “yes”. (If it wasn’t, then this post wouldn’t exist.) We’ll start with the cosine function, since it’s probably the easiest to implement. One way to define the cosine function is as an infinite series that I don’t really want to try to recreate in math notation here. As it turns out, that definition is fairly easily convertible to a recursive function that can be evaluated at compile-time.

The Code

template <int Iterations = 10>
constexpr double cosine (double theta)
{
    return (power(-1, Iterations) * power(theta, 2 * Iterations)) /
            static_cast<double>(factorial(2ull * Iterations))
        + cosine<Iterations-1>(theta);
}

template <>
constexpr double cosine<0> (double theta)
{
    return 1.0;
}

Since the Taylor series is an infinite one, we obviously can’t run the whole thing. So we approximate. I’ve decided on a default of 10 iterations, but the function, you should note, actually calculates the series “in reverse”. The base (i.e., last) case, when Iterations == 0, is the first term in the series expansion. It’s okay, though. The algorithm still works this way, although it might look a little weird.

Also, note that this cosine function uses two other constexpr functions. The first, power(), is our creation from last time, slightly renamed. The second is a typical factorial function. (It’s a good thing every single constexpr tutorial uses this one, otherwise I’d have to write it myself!) factorial takes an integer and returns another one, so I used an explicit cast to double. You could just change the definition of factorial, though, if you don’t mind the possible loss of precision. You’d probably want to template the whole thing on the type, too, instead of only using doubles.

The other trig functions can, for the most part, work off this base. The sine series raises the angle to the power of 2n+1 instead of 2n (and takes the factorial of 2n+1, as well), but it’s otherwise the same. Tangent, as you know, is sine divided by cosine. The reciprocals (secant, cosecant, cotangent) are trivial. You’d also need conversions between degrees and radians (this function uses radians), but that’s so easy you can do it in your sleep.

In a real application, you might want to combine this with lookup tables or something, especially because of rounding errors and the limited precision of floating-point numbers.

Now What?

If I can find any more constexpr contortions, I’ll definitely be making more posts. There’s still so much of the standard math library left, you know.

On magic as technology

I’ve previously written about the idea of magic and technology coexisting, and I touched briefly on some of the ways that a world would be different from our own, if magic truly did exist the way it’s often described in fantasy literature. This week, I’m taking it to 11. We’re going to look at what happens when magic doesn’t just live alongside technology, but either replaces or supplements it.

A world with magical technology shows up in the occasional mainstream setting. Many Final Fantasy games, FFVII and FFXII for example, have a heavy emphasis on magic working as or with technology. D&D’s Eberron setting has a high-magic world where magical implements take the place of technological devices. And, most familiar of all, the Harry Potter series has a number of “industrial magic” instances: messenger owls, phantom quills, etc.

The core conceit

The first thing we have to ask about a magic-as-technology setting is this: how common is the magic? If only a certain few can wield magic at all, it won’t form a major function of the technological progression. But if objects that use magic can be made and then used by those without magical talent, then you have the basis for a “technomancer” guild, where mages can create enchanted objects for the general public. Give everybody the capability for techno-magic, and many people will use it to make things. Some won’t, though, and magic-based “factories” could spring up, offering production lines and volume discounts. It might be a bit like today’s PC market, where most people buy a computer from a big name like Dell, but a select few learn how to build their own. They might pay a little more, but they get a level of customization not possible for the “big boys”.

Knowing how many magically-aware people we have, we can move on to the second question: how does magic work? I don’t mean in general, but only in comparison to science. If magic and technology work in basically the same way, and they can affect one another, then you have a “magitech” setting where the two almost merge (e.g., Final Fantasy). “Technomancy” is more of a situation where magic replaces tech (e.g., Harry Potter). Both of these have their ups and downs, but we’re not here to debate them today. They both have one thing in common: the notion that magic works in a predictable, testable, repeatable fashion. In other words, magic is scientific.

Branching off

When, in the course of history, was “scientific” magic discovered? The farther back you put this defining event, the less the final result will look like our world. Humans have an amazing capability to adapt new things to their use, and magic would be no different.

Take our own world, for instance. If magic had come into being, say, on December 21, 2012, the world as we know it would be largely the same. (I actually had an idea for a story based on this very topic, years ago, but I never got around to making it.) Three years isn’t that much time, after all. We’d probably just be seeing the first stirrings of a magical revolution right now.

Move the magical zero-hour back, though, and things begin to happen. Anywhere within an average lifetime, and the world doesn’t change enough to be unrecognizable, but you get lots of fun what-if questions. What if Osama bin Laden had access to magic in 2001? What if NASA had magical air-recycling in the 70s? What if the nuclear bombs dropped on Hiroshima and Nagasaki were magically-enhanced? Or, for that matter, what if the Japanese had magical defenses against them?

Beyond a lifetime, the possibilities start to get too much. World War I is just now at the edge of living memory, but imagine if it was the first magical war. The body counts might have been even higher, the damage to the land far worse. Or things could have been changed for the better. Who knows? Wars are the easiest to speculate about, but any historical event could have gone differently if magic had been involved. And then everything would change.

Once you go back far enough, and once magic gets powerful enough, civilization itself turns out differently. If you have magical means of sending messages across miles, who needs radio? Magical copying can eliminate the need not just for electronic copiers, but for the printing press, too. If running water can be provided by a spirit of a river that anyone can tame, then why would you ever invent the aqueduct?

Not just invention, but every facet of life can be changed through the proper application of magic. Travelers could move about at night with magical illumination sources. A “ray of frost” spell is going to be a big boost to the study of heat transfer. “Flesh to stone” can take the place of mausoleum statues. The list goes on ad infinitum, because there’s nothing that wouldn’t be different in a world full of verifiable, technical magic. Even literature wouldn’t be immune. Sword-and-sorcery fantasy in such a world would probably be more of a satirical, comedic genre, or maybe a stylized look at the real world. The true literary heroes might become those who did great deeds without magical help.

How much do you need?

This is a rabbit hole that goes on forever, and it’s easy to get lost in it. For somebody trying to create the illusion of a techno-magic world, I can only offer a little advice.

First, decide on answers to the two questions above. Figure out where magic changes the “natural” order of history (even if you’re making a fantasy world). Work out what kind of magic the people would have access to, and how many of them can use it. The decisions you make here affect everything else, so they’re the most important.

Second, you can “cheat” by saying that just about everything that happened before magic matches up with our world. The precise details won’t be the same, but a world where magic was discovered in Roman times would probably have something resembling a Stone Age and a Bronze Age before that. Basically, any invention from before your branching point gets in for free, and you can work from there.

Third, think about what you need. Sure, it’s fun to explore the different possibilities, the different paths of the butterfly effect, but you do need to remember the needs of your story. Magical, oceangoing ships without sails might be interesting, but people living in a landlocked city-state probably won’t care about them, so a story set there might only mention them in passing, such as a brief phrase dropped in a traveler’s tale.

Fourth, use logic. That’s the whole point of technological magic, that it works the same as science. Wands of magic missile can replace guns, sure, but if they’re easy (and cheap) enough to make, then they would replace guns just about everywhere. Probably bows, too. Hunters would use them, and so would assassins. If that changeover is far enough in the past, society might completely forget how to make guns. (And that could make an interesting story hook, if I do say so myself.)

Finally, resist the urge to stagnate. If magic replaces technology, that doesn’t mean that progress stops. No, it just starts going in a different direction. It’s humanity’s unspoken desire to evolve, and the history of civilization is that of people coming together to change their environment to better suit them. That won’t stop simply because magic becomes involved. In many cases, industrial magic might cause things to speed up. If we can make things fly using magic in the High Middle Ages, then Da Vinci, the Montgolfiers, and the Wrights never need to design or build gliders, hot-air balloons, and airplanes. Magical airships, ornithopters, or the like would be a common sight to them, so why bother making something less powerful, less efficient, and more dangerous?

Going deeper

In case you couldn’t tell, I really like these thought experiments. I want to do more of them. I want to follow the rabbit hole deeper. Maybe it’s not everybody’s cup of tea. Maybe you’re satisfied with Generic Medieval Europe With Wizards. That’s fine. I understand that, and sometimes it’s just what I need, too. But I definitely want to keep exploring the intersection of magic and science. I can’t promise it will be a regular, weekly thing, but I’ll put them in every now and then.

Let’s make a language – Part 3b: Language Types (Conlangs)

On the 2D “grid” of languages we saw last week, where do our two conlangs fall? We’ll take each of them in turn.

Isian

Since Isian is intended to be simple and familiar, I’ve decided to make it similar to English in this respect. Isian will have a lot of isolating features, but compound words can be made through agglutination. However, there will be a few fusional bits here and there. We might consider these “legacy” aspects of the language, something like how English still distinguishes subject and object, but only in pronouns.

Most of the morphemes in Isian will be free. Bound morphemes will be a fairly restricted set of affixes, mostly grammatical in nature, but with a few “learned” compounding affixes, analogous to English’s Latin borrowings: pre-, inter-, etc. Owing to Isian’s smaller phonology, a lot of morphemes will be two or even three syllables, but the most common are the most likely to be short.

Ardari

With Ardari, we can be more ambitious. We’ll make it a more polysynthetic language, leaning agglutinative, but with some fusional aspects, too. In other words, Ardari will have a lot of word-making suffixes and prefixes, and plenty of grammatical attachments. Some of those will have a single meaning, while others will come in a fusional set.

Like Isian, though, those bits will tend to be older, even antiquated. It’s a common theme in natural languages: fusional aspects tend to disappear over time. Look at Latin and its daughter languages. Sure, Spanish (and Italian, and French, and…) kept the verbal conjugations. But noun case is all but gone, and French shows us that spoken verbs aren’t exactly untouchable. The same thing happened with English, but long ago. (If you don’t believe me, look up some Old English. We lost our cases, too, but our cousin, German, still has them.)

Since we have more sounds to work with, Ardari will have quite a few more morphemes of a single syllable, but two will still be common, and three won’t be entirely unheard of. On the whole, though, an Ardari text will tend to be shorter than its Isian equivalent, if harder to pronounce and translate.

The Words

Now for the moment you’ve all been waiting for. Here’s the first basic vocabulary list for both of our conlangs, including an even dozen words. Obviously, these are going to be loose translations, but we’ll say that they cover the same ground as their English glosses. Also, these are simple nouns and verbs. No pronouns or adjectives yet, because we don’t really know what form they’ll take. (If you’re wondering, the Ardari verbs end in dashes because those are only the roots. We haven’t yet seen how to make the inflected forms.)

English Isian Ardari
man sam kona
house talar tyèk
dog hu rhasa
sun sida chi
water shos obla
fire cay aghli
food tema fès
walk coto brin-
see chere ivit-
eat hama tum-
live liga derva-
build oste moll-

Next Time

In the next post, we’ll take a break from our methodical, studious approach and digress into the wonderful world of nouns. We’ve already got seven of them up there, but we’ll come out with plenty more. After that, we’ll do the same for verbs, and then we’ll start to look at how we can take both of them and combine them into sentences.

Phaser 2.4 released

A while back I mentioned that I thought Phaser was a good choice for beginners of game development. It’s well-supported, it’s popular on browsers and mobile devices, and it uses the current most popular language: JavaScript.

Now, the guys behind Phaser have released version 2.4, and it has quite a few changes and updates. Most people will be gushing over the support for boned animation and video, but there are a few nuggets hidden in the changelog that might be just as useful. Let’s see what we can find, eh?

  • Phaser.Text no longer extends PIXI.Text but replaces it entirely. Phaser.Text now natively extends a Phaser Sprite, meaning it can be enabled for physics, damaged, etc.

On the surface, not a huge change, mostly just back-end stuff. But look at the second half of the entry: text objects are now sprites in their own right. That actually makes the code for a lot of games much easier, simply because we can use all the sprite methods on text. Think of, say, a word puzzle, where every word (or letter) can be made into its own sprite.

  • Mouse.button and MSPointer.button have been deprecated and are no longer set (they remain at -1). They never supported complex button events such as holding down 2 buttons and releasing just one, or any buttons other than left and right. They have been replaced with the far more robust and accurate Pointer DeviceButton properties such as Pointer.leftButton, Pointer.rightButton and so on.

This (and a handful of entries following it) is another step towards “unifying” control schemes. It’s annoying to have to write separate code to handle the mouse and a touchscreen. Now we don’t have to. Of course, you still need to compensate for the fact that a mouse can have nearly pixel-perfect accuracy, whereas fingers are lucky to get within about a centimeter of their target.

  • Added support for the Creature Automated Animation Tool. You can now create a Phaser.Creature object which uses json data and a texture atlas for the animations. Creature is a powerful animation tool, similar to Spriter or Spine. It is currently limited to WebGL games only, but the new libs should prove a solid starting point for anyone wanting to incorporate Creature animations into their games.

This is the one everybody’s talking about. To be honest, it doesn’t intrigue me as much. Creature is just one commercial, proprietary tool among many. Show me an open standard for 2D bones, and then I’ll get excited.

  • Loader.video allows you to load a video file into Phaser. It works in the same way as Loader.audio, allowing you to pass an array of video files – and it will load the first one the device is capable of playing back. You can optionally load the video via xhr where the video data is converted to a Blob upon successful load.

Video is cool, no doubt about it. But the whole field of in-browser video is a disaster area. Format support, patents, DRM, it’s all enough to make somebody swear off the whole thing forever. Still, if you can figure out a way to use it safely and easily, more power to you. Maybe it’ll lead to a revival of FMV games.

  • Text.setTextBounds is a rectangular region that allows you to align your text within it, regardless of the number of lines of text or position within the world. [ed: I removed the example, shout-out, and issue number]

More text rendering goodness. I can’t complain. This and other additions simplify the task of making a text-heavy game, something most game engines (not only HTML5, and not only free) make absurdly difficult.

  • Keyboard.addKeys is a practical way to create an object containing user selected hotkeys. [ed: Same removals here.]

Better keyboard support is a good thing in any engine, especially as so many are trying to forget that a physical keyboard even exists. And an easier way to support hotkeys can never be bad, because they’re one of the most annoying parts of a control scheme.

  • All Game Objects and Groups have a new boolean property called pendingDestroy. If you set this to true then the object will automatically destroy itself in the next logic update, rather than immediately. [ed: Removed use case and call-out.]

Godot has this same thing (as queue_free()), and it’s very helpful there. In a language full of callbacks (like JS), it’s even more necessary. Again, this isn’t something you want to scream out from the rooftop, but it’s a subtle change that eliminates a whole class of coding errors. Who could ever argue with that?

  • All Signals now have the ability to carry extra custom arguments with them, which are passed on to the callback you define after any internal arguments. [ed: Same removals here.]

A good customization point that’s never going to be important enough to mention in a press release. But it’s nice to have, and it simplifies some common tasks.

  • Phaser.Create is a new class that allows you to dynamically generate sprite textures from an array of pixel data, without needing any external files. We’ll continue to improve this over the coming releases, but for now please see the new examples showing how to use it.

Depending on how this plays out, it could be a great addition to an already excellent engine. A lot of designers absolutely hate generated textures, but I like them. Get some good noise algorithms in there, and you could do some wonderful things.

There’s a lot more in there, and I do mean a lot. And Phaser 3 should be coming within the next year or so, although release dates always have a tendency to…slip. But this 2.4 release does help cement Phaser as the forerunner for HTML5 game development. For coders rather than designers, there’s really not a better option, and I’ll continue to recommend Phaser for anybody that wants to get started with game coding. Unity’s great and all, but it’s a lot more complicated than popping open a text editor and a browser, you know?