Let’s make a language – Part 2b: Syllables and Stress (Conlangs)

Okay, last time we ran a bit long. This one should be fairly short. Today, we’ll look at the syllable structure and stress patterns of our two conlangs, Isian and Ardari. There’s no sense wasting time; let’s get right to it!


Isian, remember, is going to be the simpler of the two, so we’ll start with it. Isian syllables, for the sake of simplicity, will be of the form CVC. In other words, we can have a consonant on either side of a vowel. We don’t have to, of course. Syllables like an or de are just fine. CVC is the “maximum” complexity we can have.

Obviously, the V can stand for any vowel. (It’d be kind of silly to have a vowel you couldn’t use, wouldn’t it?) Similarly, the first C stands for any consonant. For the second C, the coda, that’s where things get a little more complicated. Two rules come into effect here. First, h isn’t allowed as a final consonant. That makes a lot of sense for English speakers, who find it hard to pronounce a final /h/, although it might upset speakers of other languages. Again, simple is the name of the game.

The second rule concerns diphthongs. If you’ll recall from Part 1, Isian has six of them. Here, we’ll say that /w/ and /j/ (written w and y) can only be the final consonant if they follow a, e, or o. This matches our phonology, where /ij/, /iw/, /uj/, and /uw/ aren’t allowed. Thus, diphthongs can be neatly analyzed as nothing more than a combination of vowel and consonant.

Moving on, we’ll give Isian a fixed stress: always on the penultimate syllable. So a word like baro will always be pronounced /ˈbaro/, never /baˈro/. Words with three syllables follow the same pattern: lamani is /laˈmani/. Since a diphthong is just a vowel plus a consonant, they don’t affect stress at all: paylow will be /ˈpajlow/.

In longer words, we’ll extend this stress in the same way. Or, to put it another way, every other syllable will get some sort of stress. A hypothetical word like solantafayan would have a secondary stress: /soˌlantaˈfajan/.

There won’t be any vowel reduction in Isian. Like Spanish, every vowel will be sounded in full, and each syllable will take up about the same time. This, combined with the regular stress, will probably give the conlang a distinct rhythm. (The dominant form of poetic meter, for example, will definitely be trochaic, and Isian musicians would probably find Western 4/4 rhythms very appealing.)


As usual, Ardari is a bit more complicated. For this language, syllables will have the structure CCVCC, and each of the four C’s will have a different set of possibilities:

  1. The first C can be any stop consonant, /m/, or /n/.
  2. The second C can be any fricative or liquid except /ɫ/, except a fricative can’t follow a nasal.
  3. V, of course, stands for any of the ten Ardari vowels.
  4. The third C is restricted to four liquid sounds: /w j ɫ ɾ/
  5. Finally, the fourth C can be any consonant except those four liquids.

Now, in addition to these definitions, Ardari syllables have a few rules about which clusters of consonants are available. In the onset, there are three broad categories: stop + fricative, stop + liquid, and nasal + liquid. The last is the smallest, so we’ll deal with it first. For that combination, there are eight possibilities: /mw mj ml mɾ nw nj nl nɾ/. Of these, we’ll say that Ardari doesn’t allow a nasal followed by /l/. Also, /nj/ isn’t that much different from /ɲ/, so we’ll say that those two sounds merge, allowing a syllable that starts with /ɲ/, but nothing else. The remaining five clusters can go in as they are.

For the combination of stop and fricative, things get trickier, because of Ardari’s rules about voicing and palatalization. Rather than a system, it might be best to show precisely which clusters are allowed:

  • Bilabial + fricative: /pɸ bβ pʁ bʁ/
  • Alveolar + fricative: /ts dz tɬ tʲs dʲz tʁ dʁ/
  • Velar + fricative: /kʁ gʁ kʲɕ gʲʑ/

For stops and liquids, we’ll do the same thing:

  • Bilabial + liquid: /pl pɾ pʲʎ pw bl bɾ bʲʎ bw/
  • Alveolar + liquid: /tw tɾ tʲɾ dw dr dʲr/
  • Velar + liquid: /kw kl kɾ kʲɾ kʲʎ gw gl gʲɾ gʲʎ/

At the end of a syllable, the clusters /ɫʁ ɾʁ ɫl ɫʎ wʎ ɾʎ ɫɲ ɾɲ/ aren’t allowed, but any others that fit the syllable structure are. (This is mainly because I find them too hard to pronounce.)

Ardari stress is free, but predictable. Syllables that have coda consonants other than just /w/ or /j/ are considered heavy, while all others are light. For most words, the stress will be on the last heavy syllable. (Secondary stress will fall on any heavy syllable not adjacent to another one.) Words with only light syllables are stressed on the penultimate, as are all words with exactly two syllables. For all of these rules, there is an overriding exception: /ɨ/ and /ə/ can never be stressed. If they would be, then the stress is moved to the next syllable. So, examples of all of these, using hypothetical words:

  • Basic stress pattern: sembina /ˈsembina/, karosti /kaˈɾosti/, dyëfar /dʲəˈfaɾ/.
  • Secondary stress in long words: andanyeskaro /ˌandaˈɲeskaɾo/.
  • Two syllables: meto /ˈmeto/, kyasayn /ˈkʲasajn/.
  • All light syllables: taralèko /taɾaˈlɛko/.
  • Stress moved because of vowel: lysmo /lɨsˈmo/, mönchado /mənˈɕado/.

Because of the vowel reduction, Ardari will likely be a more free-form language than Isian, poetically speaking. Indeed, it will probably sound a lot more like English.

Next Time

With this post, we now have enough information to start making words in both our conlangs. That may even be enough for some people. If all you need is a “naming” language, you don’t have to worry too much about grammar. That said, stick around, because there’s plenty more to see. Next up is a theory post where we begin to give our words meaning, and we find out just how many words the Eskimos have for snow. See you then!

Introduction to ES6 Modules for Game Programmers

As an application (be it a game or anything else) grows, so does the need for some sort of organization. Also, all but the simplest programs will require the use of some sort of additional libraries. For both of these reasons, just about every programming language meant for serious use has a way to separate code into logical, self-contained blocks. Even lowly C has its header files, but more modern languages can do more.

JavaScript, however, used to be sorely lacking in this department. Sure, you can load additional scripts in a web page, and jQuery (to name one example) managed an entire plugin architecture using DOM onload events. But everyone recognized that this wasn’t enough, and thus modules were born.

The problem is, they weren’t a part of the JavaScript “core”, so there was no standard way of making or using a module. Node made its own module system based off the CommonJS spec (later used by Browserify), while Require.js championed a slightly different style called AMD. In general, server-side and other “app”-style JS used Node’s modules, since they were already using Node itself, while purely browser-based libraries went with AMD. As with any case where there are two competing standards, developers are left having to learn both of them.

Now, with ES6, all that can change. Modules are now a core part of the language. Once browsers fully support them, you can use them anywhere. (Babel can convert ES6 modules into AMD or CommonJS, though, if you want to use modules right now.) And this is a case where you’ll definitely want to, no matter what you’re writing.

Using Modules

Most of the discussions out there focus on writing modules, rather than using them. But game developers, in particular, are going to be more likely to use somebody else’s module first, so I’m starting there.

The import keyword is your gateway to modularity. If you’ve ever used require() in Node, you’re halfway there, but you’ve still got more to learn. The idea is pretty simple, though. Let’s say that we’re using some made-up game library that’s fully modularized, so that all its classes (because it’s all ES6, see?) are in their own module files. Well, we can do this:

import Vec2d from "lib/vector2d";

Now Vec2d is available for us to use in the rest of that script, and it will be whatever the vector2d module exported. Presumably, that would be a class or a function that created a 2D vector.

That’s the most basic import. For modules that export a single value (class, function, or even a constant), it’s all you have to do. In fact, the way the standard was made, it’s actually the preferred way of doing things. But it’s not the only way. What if we have a module that gives us multiple exports?

import {normalize, dotProduct} from "lib/vector2d";

That gives us names for two functions that might be defined (and exported) in our hypothetical vector2d module. Of course, we can combine these two:

import Vec2d, {normalize, dotProduct} from "lib/vector2d";

Here, the default export (see below) is assigned to the name Vec2d, while the braces indicate exports that we’re “picking” from the module. If we don’t like the names the module gives us, no problem:

import Vec2d, {normalize, dotProduct as dotP} from "lib/vector2d";

Finally, if we have a module that has a lot of exports (maybe something like jQuery), we can use a “wildcard” import that brings in the whole module as an object:

import * as $ from "lib/jquery";

We do have to name the object we’re importing into. (I used the traditional $ for jQuery.) After we use this import, anything the module exported with a name will be available as a property on the $ object.

Note that all importing is done statically, so you can’t “conditionally” import like this. (This is one downside to ES6 modules compared to earlier attempts like Node’s.) For that, you need to use the new Module Loader API, which would look something like AMD:

    .then(function($) {
        // Use jquery module as $, just like always

Creating Modules

Eventually, you’ll want to make your own modules. For a game, you might be using a classical OO approach, where all your game entities (enemies, powerups, etc.) are ES6 classes, each in their own file. Like we did above, we’ll start with the simplest case, where your module only has one value, particularly a class.

/* enemy.js */
export default class {
    // Class definition...

That’s all there is to it. export default is the magic phrase that tells your JS interpreter that you’re defining a module and that you want it to export a single value. That value could be anything: class, function, constant, or even another module. And, when you want to use your enemy, all you have to do is import it like we did earlier.

If you want a module with more than one export (maybe a library of independent functions), then you can use a syntax that’s almost the reverse of that for importing multiple values:

/* utils.js */
export function log(msg) {

export function foo(bar) {
    // Some other function

export const MAX_FPS = 60;  // TODO: Lower to 30 for console builds

All of these will be exported, and they can be imported using the “braces” or “wildcard” versions of import. (Since there’s no default export, these are, in fact, the only two ways to use the module. A simple import utils from "utils"; wouldn’t help us here.)

If you don’t like writing export everywhere in a module like this, you have an alternative. Instead, you can write the module as you normally would, then add an export declaration at the end. This declaration consists of export followed by the name of each expression you’re exporting, all of them put in braces, like an object literal. In other words, like this:

/* utils2.js */
function log(msg) {

function foo(bar) {
    // Some other function

const MAX_FPS = 60; // TODO: Lower to 30 for console builds

export {log, foo, MAX_FPS};

The main advantage of this style is that you can export a function (or whatever) under a different name, using as like we can when importing. So, for example, we could instead write the last line as export {log as debug, foo, MAX_FPS};.

In Closing

So modules are good, and ES6 modules make JavaScript even better. Combined with classes, we now have a language that makes writing programs (including games) much easier. Once support for modules becomes widespread in browsers, all JS game developers will reap the benefits that “native” devs already enjoy.

Let’s make a language – Part 2a: Syllables and Stress (Intro)

The syllable is the next logical unit of speech after the phoneme. It’s one or more sounds that follow a pattern, usually (but not always) centered around a vowel. These syllables can then be strung together into words, which we’ll cover in the next part. For now, we’ll see what we can do with these intermediate building blocks.

The Syllable

Most linguistic discussions divide a syllable into two parts: the onset and the rhyme. That’s as good a place as any to start, so that’s what we’ll do. The rhyme part is further subdivided into a nucleus and a coda, again a useful distinction for us to work with. As the rhyme is often the more important, we’ll look at it first.

The nucleus is the center of the syllable, and it’s usually a vowel sound. Some languages, however, permit consonants here, too, and these are known as syllabic consonants. In English, these are the sounds at the ends of words like better, bottle, bottom, and button. A few languages (e.g., Bella Coola, some Berber languages) go even farther, to the point where the dividing line between syllables becomes so blurred as to be useless. By and large, though, vowels and the occasional syllabic consonant are the rule for the nucleus.

The coda is everything that follows the nucleus, and it’s a part that is, strictly speaking, optional. Languages like Hawaiian don’t have syllable codas at all, while Japanese only allows its “n” sound, as in onsen. A slightly more complex scheme allows most (if not all) of the consonants in the language to appear in the coda. Beyond that are languages that allow clusters of two, three, or even four consonants, with English a primary example of the last category, as in the words texts and strengths. (We’ll come back to that one later.) An important distinction we can draw is between open syllables without a coda and closed syllables with one. That will come into play later on, when we discuss stress.

Moving to the onset, we see another opportunity for consonants. This can range from nothing at all (though languages such as Arabic do require an onset) to a single consonant to a cluster of two or three. Again, English is ridiculously complex in this regard, at the far end of the scale in allowing three: split and (once again) strengths. Of course, this complexity is tempered by the fact that the first of those three must be /s/, which brings us to the topic of phonotactics.

Loosely speaking, phonotactics is a set of constraints on which sounds can appear in a syllable. It’s a different system for each language. They all have a few things in common, though. First, there’s a distinction between consonant and vowel. The simplest systems allow only syllables of CV, where C stands for any consonant, V for any vowel. An alternative is (C)V, where the parentheses around C mean that it’s optional.

The next step up in complexity comes with a coda or an onset cluster: CVC or CCV. (We’ll assume the parentheses indicated an optional consonant are implied.) These two are the most common, according to WALS Chapter 12, but they’re also where phonotactics becomes important. Which consonants can end a syllable? Which clusters are allowed? Although the first question has no universal answer, the second does have a trend that we can (or should) use.

Most languages that allow consonant clusters follow what’s called the sonority hierarchy. For consonants, it’s kind of a ranking of how “vowel-like” a sound is. Semivowels such as /w/ or /j/ are high on the list, usually followed by approximants like /l/ or /r/, then nasals, then fricatives, then stops. The rule, then, is that the allowed syllables have sonority that falls outward from the nucleus. In other words, it’s incredibly common for a language to allow a syllable onset like /kɾ/, but rare for /ɾk/ to be permitted. In the coda, that’s reversed, as the sounds with higher sonority come first. English bears this out: trust is the sequence stop – approximant – vowel – fricative – stop. /s/ (and /z/, for that matter) is special, though. Many languages allow either sound to appear in a place where the hierarchy says it shouldn’t go, like in stop or tops. That’s also how English gets three consonants in an onset: /s/ is always the first.

And, of course, there are the combinations that aren’t allowed by a language despite the sonority hierarchy saying they’re fine. In English, these are mostly combinations of stops and nasals. We don’t pronounce the k in knight or the p in pneumonia, but other languages do. Conversely, those other languages have their own rules about what’s forbidden.

For a conlang, there’s really no best option for syllable structure. CV is simple, true, but it’s also limiting, and it creates its own problems. Generally, less complex syllables mean longer words, since there aren’t that many permutations that fit the rules. On the other hand, something too complicated can devolve into a mess of rules about which phoneme is allowed where.

Auxiliary languages, then, should probably stick with something in the middle of the spectrum, like CVC or a very restricted form of CCVC. Conlang artisans can go with something a bit more bizarre, especially if they’re never intending their languages to be spoken by mere mortals. And, of course, an alien race might have a different sonority hierarchy altogether, and the idea of “syllable” might make as little sense as it does for the Nuxalk of British Columbia.

Stress and Accent

However we chose to make syllables, whether CV or CVC or CCCVCCCC, we can now put them together to form words. Some words need just one. (Like every word in that sentence!) Many will need more, though, and some people find joy in hunting down the longest possible words in different languages.

Once we have more than one syllable in a word, there can be a battle for supremacy. Stress is a way of marking a syllable so that it stands out from those around it. Stressed syllables are typically spoken louder or with more emphasis. (An alternative is pitch accent, where the emphasized syllable is spoken with a different tone. This can happen even in languages that don’t actually have phonemic tone, including Japanese and Swedish.)

There doesn’t have to be any special meaning attached to stress. Many languages fix the position of the stressed syllable, so it’s always the last, the next to last (penultimate), or the third to last (antepenultimate). Others go in the opposite direction, stressing the first (initial), second, or third syllable from the beginning. In any of these languages, the stress falls in a specified place that doesn’t change, no matter what the word is. Examples (according to [WALS Chapter 14])(http://wals.info/chapter/14) include:

  • Final stress: Persian, Modern Hebrew
  • Penultimate: Swahili, Tagalog
  • Antepenultimate: Modern Greek, Georgian
  • Initial: Finnish, Czech
  • Second syllable: mostly smaller languages such as Dakota and Paiute
  • Third syllable: almost no languages (the only example in WALS is Winnebago)

Conversely, a language can also have stress that doesn’t seem to follow any rules at all. This free stress occurs in languages like English, where (as usual) it is weirder than it looks. In fact, English stress is phonemic, as it can be used to tell words apart. The canonical example is permit, which is a noun if you stress the first syllable, but a verb when you stress the second. In languages with free stress, it must often be learned, and it can be indicated in the orthography by diacritics, as in Spanish or Italian. Free stress can even vary by dialect, as in English laboratory.

It’s rare that a language has completely unpredictable stress. Usually, it’s determined by the kind of syllables in a word. This is where the distinction between open and closed syllables comes into play. Closed syllables tend to be more likely to take stress (i.e., they’re “heavy”), while open (“light”) syllables are stressed only when they are the only option. (Some languages consider long vowels and diphthongs to be heavy, too, but this isn’t universal.) It’s entirely possible, for example, for a language to normally have penultimate stress, but force the stress to move “back” to the antepenultimate if the final two syllables are light.

Stress in conlangs might be entirely unpredictable. All types are represented, in similar proportions to the real world, although pitch accent is one of those things that conlangers find fascinating. Auxiliary languages tend to have stress that’s either fixed or easily predictable; Esperanto’s fixed penultimate is a good example. Artistic languages are more likely to have free stress, though some of this might be due to laziness on the part of their creators. Fixed is easier, of course, since it’s mechanical, but free stress has its advantages. (An interesting experiment would be to create a language with free, unmarked stress, then come back to it a few years later and try to read it.)

Rhythm and Timing

Rhythm is kind of a forgotten part of conlanging. (I’m guilty of it, too.) It’s most closely tied to poetry, obviously, but the same concept creeps into spoken language, as well. For this post, the main point of rhythm is secondary stress. This kind of stress is lighter than the main, primary stress we discussed above, and it mostly occurs in long words of at least four syllables. Now, some languages don’t need (or have) a rhythmic pattern, but it can make a conlang feel more natural.

Generally, a heavy syllable is going to be more likely to get secondary stress, especially if there is a single, light syllable between it and the main stress. (In which direction? Whichever one you use to find the primary stress.) Languages without heavy syllables (such as pure CV languages) will probably have a pattern of stressing alternate syllables; in a penultimate-stress language, this would be the second to last, fourth to last, and so on.

Somewhat related to rhythm is timing, another under-appreciated aspect of a language. In languages such as Spanish or Italian, unstressed syllables are treated essentially the same as those that are stressed, and each syllable sounds like it takes the same amount of time. In others, including English, an unstressed syllable is spoken more quickly, and its vowel is reduced; here, it seems to be the amount of time between stressed syllables that stays constant.

For the most part, conlangers don’t need to worry much about rhythm and timing. However, if you’re writing poetry (or song) in your language, it will certainly come into play. Any post I do about that is a long way off.

The Mora

Some languages don’t use the syllable as the basis for stress and rhythm. Instead, these languages (including Japanese and Ancient Greek, to name but two) use the mora (plural morae). This is, in essence, another way of looking at light and heavy syllables. Basically, a short vowel in a syllable nucleus counts for one mora, while long vowels or diphthongs are two. A coda consonant then adds another mora, giving a range of one to three. Thus, a syllable that has one mora is light, and two morae make a heavy syllable. Three morae can make a “superheavy” syllable, though some languages don’t have these, and four seems to be impossible.

In a moraic system, stress (or pitch, if using pitch accent) can then be assigned to heavier syllables. Rhythm, too, would be based on the mora, not the syllable. The distinction can even be shown in writing, as in the Japanese kana. The end result, though, can be explained in the same terms either way. It’s just another option you can look into.


That was a lot to cover, and I only scratched the surface of syllables. But we can now make words, and that was worth a long post. Next up is a combination post for both Isian and Ardari. Since the theory’s out of the way, the implementation won’t take much explanation, so I’ve decided to cover both languages at the same time. After that, we’ll actually start diving into grammar. See you next week!

Thoughts on ES6

ES6 is out, and the world will never be the same. Or something like that. JavaScript won’t be the same, at least once the browsers finish implementing the new standard. Of course, by that time, ES7 will be completed. It’s just like every other standardized language. Almost no compilers fully support C++14, even in 2015, and there will certainly be holes in their coverage two years from now, when C++17 (hopefully) arrives. C# and Java programmers are lucky, since their releases are dictated by the languages’ owners, who don’t have to worry about compatibility. The price of a standard, huh?

Anyway, ES6 does bring a lot to the table. It’s almost a total overhaul of JavaScript, in my opinion, and most of it looks to be for the better. New idioms and patterns will arise over the coming years. Eventually, we may even start talking about “Modern JavaScript” the way we do “Modern C++” or “Modern Perl”, indicating that the “old” way of thinking is antiquated, deprecated. The new JS coder in 2020 might wonder why we ever did half the things we did, the same way kids today wonder how anyone got by with only 4 MB of memory or a 250 MB hard drive (like my first PC).

Babel has an overview of the new features of ES6, so I won’t repeat them here. I will offer my opinions on them, though.

Classes and Object Literals

I already did a post on classes, with a focus on using them in games. But they’re useful everywhere, especially as so many JavaScript programmers come in from languages with a more “traditional” approach to objects. Even for veterans, they come in handy. We no longer have to reinvent the wheel or use an external library for simple inheritance. That’s a good thing.

The enhancements to object literals are nice, too. Mostly, I like the support for prototype objects, methods, and super. Those will give a big boost to the places where we don’t use classes. The shorthand assignments are pure sugar, but that’s really par for the course in ES6: lots of syntactic conveniences to help us do the things we were already doing.


I will do a post on modules for game development, I promise. For now, I’d like to say that I like the idea of modules, though I’m not totally sold on their implementation and syntax. I get why the standards people did it the way they did, but it feels odd, especially as someone who has been using CommonJS and AMD modules for a couple of years.

No matter what you think of them, modules will be one of the defining points of ES6. Once modules become widespread, Browserify becomes almost obsolete, RequireJS entirely so. The old pattern of adding a property to the global window goes…out the window. (Sorry.) ES6 modules are a little more restrictive than those of Node, but I’d start looking into them as soon as the browsers start supporting them.


Async programming is the hot thing right now, and promises are ES6’s answer. It’s not full on threading, and it’s distinct from Web Workers, but this could be another area to watch. Having a language-supplied async system will mean that everybody can use it, just like C++11’s threads and futures. Once people can use something, they will use it.

Promises, I think, will definitely come into their own for AJAX-type uses. If JavaScript ever gets truly big for desktop apps, then event-driven programming will become even more necessary, and that’s another place I see promises becoming important. Games will probably make use of them, too, if they don’t cause to much of a hit to speed.

Generators and Iterators

Both of these really help a lot of programming styles. (Comprehensions do, too, but they were pushed back to ES7.) Iterators finally give us an easy way of looping over an array’s values, something I’ve longed for. They also work for custom objects, so we can make our own collections and other nifty things.

You might recognize generators from Python. (That’s where I know them from.) When you use them, it will most likely be for making your own iterable objects. They’ll also be handy for async programming and coroutines, if they’re anything like their Python counterparts.

Syntactic Sugar

A lot of additions to ES6 are purely for aesthetic purposes, so I’ll lump them all together here, in the same order as Babel’s “Learn ES2015” page that I linked above.

  • Arrows: Every JavaScript clone (CoffeeScript, et al.) has a shortcut for function literals, so there’s no reason not to put one in the core language. ES6 uses the “fat” arrow =>, which stands out. I like that, and I’ll be using it as soon as possible, especially for lambda-like functions. The only gotcha here? Arrow functions don’t get their own this, so watch out for that.

  • Template Strings: String interpolation using ${}. Took long enough. This will save pinkies everywhere from over-stretching. Anyway, there’s nothing much to complain about here. It’s pretty much the same thing as PHP, and everybody likes that. Oh, wait…

  • Destructuring: One of those ideas where you go, “Why didn’t they think of it sooner?”

  • Function Parameters: All these seem to be meant to get rid of any use for arguments, which is probably a good thing. Default parameters were sorely needed, and “rest” parameters will mean one more way to prevent off-by-one errors. My advice? Start using these ASAP.

  • let & const: Everybody complains about JavaScript’s scoping rules. let is the answer to those complaints. It gives you block-scoped variables, just like you know from C, C++, Java, and C#. var is still there, though, as it should be. For newer JS coders coming from other languages, I’d use let everywhere to start. const gives you, well, constants. Those are nice, but module exports remove one reason for constants, so I don’t see const getting quite as much use.

  • Binary & Octal Literals: Uh, yeah, sure. I honestly don’t know how much use these are in any higher-level language nowadays. But they don’t hurt me just by being there, so I’m not complaining.

Library Additions

This is kind of an “everything else” category. ES6 adds quite a bit to the standard library. Everything that I don’t feel is big enough to warrant its own section goes here, again in the order shown on “Learn ES2015”.

  • Unicode: It’s about time. Not just the Unicode literal strings, but the String and RegExp support for higher characters. For anyone working with Unicode, ES6 is a godsend. Especially if you’re doing anything with emoji, like, say, making a language that uses them.

  • Maps and Sets: If these turn out to be more efficient than plain objects, then they’ll be perfect; otherwise, I don’t think they are terribly important. In fact, they’re not that hard to make yourself, and it’s a good programming exercise. WeakMap and WeakSet are more specialized; if you need them, then you know you need them, and you probably won’t care about raw performance.

  • Proxies: These are going to be bigger on the server side, I think. Testing will get a big boost, too, but I don’t see proxies being a must-have feature in the browser. I’d love to be proven wrong, though.

  • Symbols: Library makers might like symbols. With the exception of the builtins, though, some of us might not even notice they’re there. Still, they could be a performance boost if they’re faster than strings as property keys.

  • Subclassing: Builtin objects like Array and Date can be subclassed in ES6. I’m not sure how I feel on that. On the plus side, it’s good for consistency and for the times when you really do need a custom array that acts like the real thing. However, I can see this being overused at first.

  • New APIs: The new builtin methods are all welcome additions. The Array stuff, particularly, is going to be helpful. Math.imul() and friends will speed up low-level tasks, too. And the new methods for String (like startsWith()) should have already been there years ago. (Of all the ES6 features, these are the most widely implemented, so you might be able to use them now.)

  • Reflection: Reflection is always a cool feature, but it almost cries out to be overused and misused. Time will tell.


ES6 has a lot of new, exciting features, but it’ll take a while before we can use them everywhere. Still, I think there’s enough in there to get started learning right now. But there are going to be a lot of projects that will soon become needless. Well, that’s the future for you, and what a bright future it is. One thing’s for sure: JavaScript will never be the same.

Let’s make a language – Part 1c: Ardari Phonology

Okay, the last time wasn’t so bad. But Isian is supposed to be simple. Ardari, on the other hand, will be a little bit different. Again, I’m going to try to explain some of the reasoning behind my choices as we go.

Ardari Consonants

Bilabial Alveolar Palatal Velar Uvular
Nasal m n ɲ ŋ
Stop p pʲ b bʲ t tʲ d dʲ k kʲ g gʲ q
Fricative ɸ β s z ɬ ɕ ʑ x ɣ ʁ
Approximant w l j ʎ ɫ
Tap ɾ

Instead of the relatively few 19 consonants of Isian, Ardari has a total of 33, slightly above the world average. And some of them are…well, you can see the table. The main features of Ardari’s consonant system are as follows:

  • A set of palatalized stops (all the ones with a ʲ). Note that there aren’t any actual palatal stops or affricates. Maybe they merged with the alveolar or velar stops at some point in the language’s history.

  • The uvular stop /q/ and fricative /ʁ/. These don’t quite fit in, but we can say they developed from earlier glottal stops or something. /q/ doesn’t have a voiced counterpart (nor does /ʁ/ have a voiceless one), but allophonic alteration will likely fill in the gaps. (By the way, WALS Chapter 6 has info on uvular consonants.)

  • A full set of fricatives, including bilabials (instead of the labiodentals of English), alveolars (the familiar /s/ and /z/), palatals (technically alveolo-palatals as found in e.g., Polish), and velars (voiceless and voiced).

  • More lateral consonants. We have the basic /l/, the “dark” velar /ɫ/, the palatal /ʎ/ (like ll in some Spanish dialects), and the voiceless fricative /ɬ/. The last is rare in Europe, with the exception of Welsh, where it is written ll. (WALS Chapter 8 is all about laterals.)

  • Two different kinds of “r” sound: the /ɾ/ from Spanish pero and /ʁ/, which is more like the French sound.

To add to this, some of the consonants will change at times. The most important point here is that palatalization and voicing change consonants in clusters. In pairs of consonants, the first takes on the voice quality of the second, while the second takes on the palatalization of the first. As an example, the cluster /sgʲ/ (assuming it’s possible) would be pronounced as if it were [zg], while /dʲs/ would come out as [tʲsʲ]. This only happens for stops and fricatives, though, since they’re the only ones where voicing and palatalization really matter.

As you can see, Ardari’s consonants are quite different from Isian’s. Still, even though some of them might be hard for you to pronounce, they still aren’t quite as outrageous as some of the real world’s languages. Be glad I didn’t add in implosives or clicks or something else completely weird.

Ardari Vowels

Front Central Back
High i ɨ u
Mid-High e o
Mid ə
Mid-Low ɛ ɔ
Low æ ɑ

The vowel system is more complex, but it’s still a system. Ardari has 10 vowel phonemes, and we can divide them into three groups: front (/i e ɛ æ/), middle (/ɨ ə/), and back (/u o ɔ ɑ/). The two middle vowels are most likely reduction vowels that gained full phonemic status at some point. /ɛ/ and /ɔ/, on the other hand, probably represent a lost length distinction.

The Ardari vowels, since there are so many of them, don’t show too much variation. In unstressed syllables, some vowels might be pronounced as [ɨ] or [ə]. There is one rule that will stick out, though: /i/ and /e/ are never found after a non-palatal stop. /ɨ/, conversely, can’t follow any palatal or palatalized consonant. (A similar constraint can be found in Russian, for example.)

There will still be diphthongs in Ardari, though we’ll postulate that most of them have been converted into pure vowels over time. The four that remain visible are /aj æw ej ou/ (phonetic [aɪ æʊ ɛi ɔu]), corresponding to English lie, how, say, and low. Most other combinations of vowels followed by glide consonants (/j/ and /w/) will end up being pronounced as one of these. For instance, the sequence /eu/ would become [æʊ], and /oj/ would turn into [aɪ].

Although the table looks ripe for it, Ardari doesn’t have vowel harmony. Sure it’d be easy to add it in, and I’ve done just that with a conlang that has these exact phonemes. But not this time. We’ll keep it simple for now, saving the complications for the grammar, which will come soon.


With a total of 43 phonemes (not counting diphthongs), it’s clear that fitting Ardari into the English alphabet is going to be a challenge. We have two options. We can opt for digraphs, which are strings of multiple letters standing for one phoneme (like English and Isian sh), or we can use diacritics, those funny little squiggles above letters in foreign languages. For Ardari, a combination of both might be our best bet.

Some of the phonemes can take their letter values, just like we did with Isian. Here, we’ll let the consonant phonemes /m p b w n t d s z l k g q/ and the cardinal vowels /e i o u/ all be written as they are in the IPA (/ɑ/ is close enough to a that we can say they’re the same). But that doesn’t even get us halfway!

If you look at the chart above, you can see that the palatalized stops are a big component. Let’s write them as the regular stops followed by y. That’ll take care of six more. Then, we can do the same for the palatal nasal and lateral: ny and ly. Now we’re getting somewhere. We’ll write /j/ itself as j, though, and you’ll see why in a moment. For the palatal fricatives, we’ll use the digraphs ch and zh. (We could also use Slavic diacritics and type them as š and ž. We can call that an alternate standard.)

The bilabial fricatives are pretty close in sound to their labiodental counterparts, so we’ll use f and v for them. The velar nasal is almost everywhere written as ng, so we’ll do that, except when it comes before another velar sound, when it will be n. Since nasals will assimilate, that’s okay.

We have two “rhotic” sounds /ɾ/ and /ʁ/. Either one could lay claim to r, but I’m going with /ɾ/ for that. For /ʁ/, we’ll use rh. That helps signify its “rougher” quality, don’t you think?

That leaves two laterals, two velar fricatives, and five vowels. For the velars, we can use the digraphs kh for /x/ and gh for /ɣ/. The laterals are a little tougher to figure out, but I’ll choose lh for /ɬ/ and ll for /ɫ/. It’s an arbitrary choice, to be sure, but I’m open to suggestions.

For the vowels, the best bet is usually diacritics, because the English alphabet simply doesn’t have enough vowel letters. Sure, you can use clever digraphs and trigraphs, but that way lies madness and Irish orthography, which are pretty much the same thing. Squiggles it is, then. We’ll use familiar European standards where we can, like a German-style ä for /æ/. French gives us è for /ɛ/, and we can extend this by analogy to ò for /ɔ/. That takes care of all but the two central vowels, which turn out to be surprisingly difficult. For /ɨ/, we can use y, since we already said it can’t appear after palatal consonants. (In other words, there’s no way to get yy.) For the schwa, we’ll go with ë or ö. Which to use depends on the previous consonant: ë after palatals, ö otherwise.

Whew. There we go. Let’s look at all this in a format that’s easier to read.

Written Phoneme Description
a /ɑ/ a as in father
ä /æ/ a as in cat
b /b/ b as in bad
by /bʲ/ palatalized b
ch /ɕ/ something like sh in show; more like Polish ś
d /d/ d as in dig
dy /dʲ/ palatalized d
e /e/ e as in Spanish queso
è /ɛ/ e as in bet
ë /ə/ a as in about; only after palatals
f /ɸ/ f as in Japanese fugu
g /g/ g as in got
gh /ɣ/ g as in Spanish amigo or Swedish jag
gy /gʲ/ palatalized g
i /i/ i as in German Sie
j /j/ y as in yet
k /k/ k as in key
kh /x/ ch like in German acht
ky /kʲ/ palatalized k
l /l/ l as in let
lh /ɬ/ ll as in Welsh llan
ll /ɫ/ l as in feel
ly /ʎ/ ll as in million (American English)
m /m/ m as in may
n /n/ n as in no
ng /ŋ/ ng as in sing
ny /ɲ/ ñ as in Spanish año
o /o/ au as in French haut
ò /ɔ/ o as in hot
ö /ə/ a as in about; only after non-palatals
p /p/ p as in pack
py /pʲ/ palatalized p
q /q/ q as in Arabic Qatar
r /ɾ/ r as in Spanish toro
rh /ʁ/ r as in French rue
s /s/ s as in sit
t /t/ t as in tent
ty /tʲ/ palatalized t
u /u/ ou as in French sous
v /β/ b as in Spanish bebe
w /w/ w as in wet
y /ɨ/ like i in bit; closer to Polish or Russian y
z /z/ z as in zebra
zh /ʑ/ like z in azure; closer to Polish ź

Wow, that’s a lot of letters! Next time, it’s back to the theory, where we’ll discuss all the things that we can use to make these sounds into words.

Introduction to ES6 Classes for Game Programmers

If you’ve used JavaScript for game programming, you probably already know some of its shortcomings. One of those is its object system. Where most languages that have objects are class-based (think C++, Java, etc.), JavaScript is unusual in that it’s prototype-based. If you have experience with the language, you know this already, of course. And you know that the syntax can leave a lot to be desired, especially if you come from a background in, say, any other language. (Well, any class-based language, at least. If you’re used to something like Lisp or Haskell, then nothing will surprise you.)

With the newest standard, ES6, that’s going to change. It’s supposed to come out by the end of this month, and maybe that’s true. I’m writing this on June 15th, so it might even be released before this post goes up. If that’s the case, great! (I still remember when C++11 was codenamed C++0x, so I remain skeptical.) Anyway, some of the new features of ES6 are incredibly useful for all developers, but we’ll start with classes, because they’re simple yet powerful, and game development has always been one of the main uses of object-oriented programming. (EDIT 6/18: ES6 is now out! I’m amazed, and I’m happy to admit that I was wrong. Even though the release happened between writing this and posting it, I won’t remove what I already said.)

(By the way, most browsers don’t support much of ES6 yet, and even Node.js support is spotty. You’ll likely need to use a transformer like Babel to turn your ES6 code into something usable under the current standard, ES5.)

Basic Syntax

Let’s take a look at a little class that we can use to represent an enemy in a game. In ES6, it might look something like this:

class Enemy {
    constructor(id, name) {
        // Some properties that are passed into the constructor
        this.id = id;
        this.name = name;

        // A property we can define ourselves
        this.health = 100;

    doAI() {
        /* Do some AI work here */

    kill() {
        /* Play a death animation or something */

    hit(damage) {
        this.health -= damage;
        if (this.health <= 0) {

If you’ve ever worked with Java, C++, C#, ActionScript, or any other language like that, then the syntax will be familiar. Inside the class definition, you can define methods, both instance methods (like all of those here) and static methods. Instance methods are basically the same as the prototype methods already in JavaScript. You call them on an instance of an object, and they can use that object as this. Static methods don’t require an instance of the class; they’re called on the class itself, like the functions of the Math object.

Using this class is as easy as any object constructor. var myEnemy = new Enemy(0, 'myEnemy'); is exactly the same as what you’d use if we defined Enemy in the traditional JS way, defining methods on the prototype and so on. That’s the beauty (if you want to call it that) of ES6 classes: deep down, they’re the same thing as before, but prettier, like CoffeeScript and Typescript claim to be.

constructor is a special method. (I wonder what it does…), but you can define any other method you like. You can also use get and set before method names, just like with the object literal syntax. Static methods are prefixed with static. And that’s pretty much it.


If ES6 classes could just do that, they’d be a pretty good bit of syntactic sugar, but they’d definitely be missing something. Subclassing (AKA inheritance) is that something. Like their counterparts in other languages, ES6 classes can derive from another class, adding or redefining methods and properties. Taking our Enemy class from above, we can make a couple of different enemies using subclasses:

class ToughEnemy extends Enemy {
    constructor(id, name) {
        super(id, name);

        this.health = 200;

class BossEnemy extends ToughEnemy {
    constructor(id, name) {
        super(id, name);

        this.lives = 3;

    kill() {
        if (this.lives > 0) {
            this.health = 200;

            /* say something cheesy
            e.g., "Ha! You thought I would go down that easy?"
            and play a regeneration animation */
        } else {
            // All lives are gone, so he's really dead

Now we have two new classes. ToughEnemy is a generic bad guy with double health. There’s not much to change for him, but it shows the super keyword that we can use to call methods of the superclass. In the constructor, you can use it by itself to call the superclass constructor. Actually, you have to. Otherwise, you can’t use this anywhere in the derived class’ constructor. Since we want to change the this.health property, we do call super, forwarding the constructor parameters to it, which also means we don’t have to deal with them.

For BossEnemy, we further subclass ToughEnemy, but with a little added logic. First, we give him a property this.lives, set to 3. Then, we change his kill() method as you can see above. If he goes down to 0 health, he loses a life, but he goes back to full health. That continues until he’s out of lives, when we call the superclass kill() method. Since we didn’t define one for ToughEnemy, the call goes up another level, to Enemy, which does have kill().

So, to make a subclass, define a class as usual, but add extends and the name of the base class after your derived class’ name. Everything else is the same, except for the caveat about super in the constructor. You can change methods to your heart’s content, and any that you leave out will stay the same as they were in the base class. Just like any other OO language. Like it should be.

The only downside (and a lot of people wouldn’t see it as such) is that you only get single inheritance, meaning you can only derive from one base class. That’s okay for JS, since we didn’t have anything else to begin with. And Java doesn’t have multiple inheritance, nor does C#. C++ and Python do, but it takes a lot of extra work on the programmer’s part to use it well. Basically, once you truly need multiple inheritance, you’ll know how to fake it, no matter what language you’re using.

For Games

Since ES6 classes are just a fancier way of writing JS prototypes, you can use them wherever you’d use those: pretty much anywhere. And, due to the way they’re defined, you can subclass “traditional” JS objects by extending a constructor. This includes builtins like Array (but not Math, as it’s not a constructor). If you’re using a game library like Phaser, you can extend its objects with classes, too. Basically, wherever you’d already use objects and prototypes, classes fit right in.


ES6 is new, and not everything supports it. According to this compatibility table, nothing actually has full support for classes yet. Firefox 39 will have just about everything, and Chrome 42 allows classes, but not completely. Internet Explorer, as usual, is hopeless, but Edge has quite a bit of support if you enable “experimental” JavaScript. Safari and iOS are out of the question right now. Realistically, if you want to use ES6 classes at the moment, you’ll need a transformer. But that will change, and the next generation of programmers might wonder why we ever bothered with prototype at all.

Let’s make a language – Part 1b: Isian Phonology

This will be a much shorter post than the one last week, since we have all the theory bits out of the way. This time, we’re solely focusing on the sound system of our “simpler” conlang, Isian. Rather than just give a list of sounds, though, I’ll try to justify some of my choices as we go.

Isian Consonants

Labial Alveolar Palatal Velar Glottal
Nasal m n
Stop p b t d k g
Affricate tʃ dʒ
Fricative f s ʃ x h
Approximant w l r j

Isian has a total of 19 consonant phonemes. None of them are too exotic, though monolingual American speakers might have a little trouble with /x/, the “ch” sound in German acht or Scottish loch. Everything else should be familiar. If you don’t know the IPA symbols for the palatal consonants, that’s okay. In order, /tʃ dʒ ʃ j/ are the initial sounds of church, judge, shut, and yet. Also, the /r/ phoneme can be either a tap [ɾ] like Spanish or an approximant [ɹ] like English, though the first pronunciation will be the “official” one.

So why these particular 19 sounds? Well, Isian is supposed to be easy to pronounce, but I still want it to look and sound a little “foreign”. /x/ accomplishes this feat (for Americans, anyway).

English speakers might notice what’s been left out. There’s no /v/ (as in view), /z/ (as in zip) or /ŋ/ (as in *sing). That’s all right, because of allophones. Between vowels, /f s ʃ/ can sound like [v z ʒ] (the last as in French jour or English azure), and /x/ can disappear altogether, instead making the vowel before it sound a little longer. Or it could sound like [h], if the two vowels it’s between are the same. So we might have /taxa/ pronounced more like [taha], but /tixa/ as [tiːa]. Some of our fictitious speakers might instead substitute the voiced velar fricative [ɣ]; we’ll say that this is an older and more formal pronunciation.

In the same way, /m/ and /n/ will assimilate to a following consonant, except approximants and /h/. Before a labial, /n/ becomes [m]. Likewise, /m/ comes out as [n] before an alveolar. Both of them will subtly change to [ɲ] before palatals and [ŋ] before velars.

There are no TH sounds, since those are relatively rare, and Isian is meant to be fairly average. For the same reason, we don’t have any phonemic alterations like palatalization or aspiration going on. Voiceless stops might sound aspirated at the beginning of a word, like English, or not, but this can be explained away as a dialect feature.

Isian Vowels

Front Central Back
High i u
Central e o
Low a

Isian’s vowel system is an average one, with the five cardinal vowels. But we’ll embellish it a little with some allophonic alteration.

First, these aren’t the only vowel sounds possible. We’ll say that any of the three “lower” vowels /a e o/, when followed by a /j/ or /w/ consonant, creates a diphthong, a kind of combination of two vowels in the same syllable. It doesn’t take much math to see that this creates six diphthongs: /aj ej oj aw ew ow/.

  • /aj/ is about the same as the English long-I sound in lie,
  • /ej/ is close to the English long-A sound in lay,
  • /oj/ is pronounced like in English toy,
  • /aw/ can be the sound in English law or loud (we can write this off as dialect differences),
  • /ow/ is the English long-O in low,
  • /ew/ isn’t in English, but it’s the first vowel sound in Spanish or Italian neutro. We’ll say that some dialects pronounce it as [iʊ], like English few.

So, even though we have only five vowel phonemes, thanks to diphthongs, it seems like we have 11.

Second, we’ll say that a few vowels change a little before certain consonants. /a/ becomes [æ] (English ash) before the palatal consonants /tʃ dʒ ʃ/. And we saw above how vowels before /x/ might become lengthened. Finally, although we haven’t discussed syllables and stress, we’ll say that unstressed vowels tend to be “reduced” in fast or colloquial speech. For example, an unstressed /a/ might sound like a schwa ([ə]), like in English about.


Orthography is, basically, how a language is written. Isian certainly isn’t going to have its own writing system; we’ll just use the alphabet. But we need a way to convert the phonemes into letters. English, of course, is notorious for being hard to spell, but Isian has far fewer phonemes, so it should be easier to fit into 26 letters.

Most of the phonemes can just be written as the appropriate letters. That works just fine for all the vowels, as well as the consonants /p b m f w n t d s l r g h/. The remaining six sounds need a little more thought. Here’s what we’ll do:

  • /k/ will usually be written as c, but k when it comes before /i/ or /e/. (This is mostly an aesthetic change. There’s nothing stopping us from writing k everywhere.)
  • /tʃ/ will be written ch, like it is in English. The same for /dʒ/ as j, /ʃ/ as sh, and /j/ as y.
  • /x/ can be written as kh. We can’t use ch, like German, since it’s already taken, and x would give English readers the wrong impression. Sometimes, you have to compromise.

So our full orthography for Isian looks like this:

Written Phoneme Description
a /a/ a in father; a in cash before ch, sh, and j
b /b/ b in boy
c /k/ c in cat; only used before a, o, or u
ch /tʃ/ ch in church
d /d/ d in dog
e /e/ e in Spanish peso
f /f/ f in fish
g /g/ g in go (always a “hard” G)
h /h/ h in hard
i /i/ i in French fini
j /j/ j in jet
k /k/ k in key; only used before i and e
kh /x/ ch in German nacht
l /l/ l in list
m /m/ m in man
n /n/ n in note
o /o/ au in French haut
p /p/ p in pit or top
r /r/ r in run or Spanish cero
s /s/ s in sat
sh /ʃ/ sh in sharp
t /t/ t in top or hot
u /u/ ou in French sous
w /w/ w in wet; creates diphthongs after a, e, or o
y /j/ y in yes; creates diphthongs after a, e, or o

The next post will switch over to Ardari. When we come back to Isian, we’ll make these sounds into syllables, then into words.

Repeatable Random Numbers with xorshift+ (JS)

Like most languages, JavaScript has a random number generator: Math.random(). It’s not the best, but it’s good enough for many purposes, including some we’ve seen before. Like the RNGs of most languages, though, Math.random() has its drawbacks. Of these drawbacks, one is very important for game developers: there’s no way to seed! Why is this bad? That cuts to the very heart of random number generation on computers.

True randomness is hard to come by. On a computer, you have a few ways of creating it, such as noise circuits or measurements of user input. This randomness (entropy) is then converted by code into something usable, such as numbers or bits. On Linux and similar systems, there is a special file, /dev/random, that provides access to the random data. Some programming languages then allow developers to use the data through mechanisms like C++’s std::random_device.

All well and good, right? As long as your source has enough randomness, you can generate all the numbers you need. But, contrary to thermodynamics, a computer’s entropy can run out. When that happens, /dev/random stops working, waiting until it can conjure up enough random bits to meet your needs. Other systems fare no better.

Fortunately for us, games don’t often need true random numbers for gameplay. (Authentication and encryption are a different story.) So we can get away with something that only looks random. That’s good for us, because there are plenty of algorithms out there that can make a convincing string of numbers, including Math.random(). Technically, they aren’t “true” random numbers, and they all have a weakness that can allow someone with enough data to guess the next numbers in the sequence. But that very predictability comes in handy for game development. Starting from a little bit of data (from one number to a few, depending on the algorithm used), we get a whole set of numbers, billions of them or more. That starting data is the seed.

Most languages that I’ve used allow you to set the seed on the RNG. C, for example, has the srand() function, while Python provides random.seed(). But JavaScript doesn’t have this. Instead, the RNG is seeded for you when your program/app/page loads, and it will be different every time. Usually, that’s not a problem.

Sometimes, though, you need the predictable sequence that comes from using a seed. Procedural generation is one notable example. Look at Minecraft: a whole world can be created from a simple string of text. Obviously, there’s randomness injected in the process, but it’s made on-demand. Think how hard it would be to store the whole world after creating it. But, if you only had JavaScript’s RNG, you wouldn’t have much of a choice.

There are better RNG implementations out there. Indeed, many have written JS versions of them. Here’s my attempt at the popular algorithm known as xorshift+.

module.exports = (function() {
    // xorshift128+ requires 128 bits of state (we'll seed later)
    var state = new Uint32Array(4);

    // Scaling factor (2^32) to convert Math.random floats into integers
    var MAXINT_PLUS_1 = Math.pow(2,32)

    // Pre-fill the state array (can later be seeded)
    // This is required because xorshift can't have state of all zero
    for (var i = 0; i < state.length; i++) {
        state[i] = Math.random() * MAXINT_PLUS_1;

    // A saved random number, since we're returning 32-bit numbers
    var saved;

    return {
        // Seeds the internal RNG.
        seed: function(s) {
            if (s === 0 || s == null) {
                // Can't use a zero seed (maybe throw an exception?)

            // TODO Handle various types of arguments (just numbers/arrays for now)
            if (typeof s === 'number') {
                // Use only the lowest 32 bits right now
                state[0] = s >>> 0;
            } else if (s.constructor && s.constructor.name === 'Uint32Array') {
                for (var i = 0; i < state.length; i++) {
                    if (s[i] !== undefined) {
                        state[i] = s[i];
                    } else {
                        state[i] = 0;

        // Returns a random float between 0 and 1 (exclusive),
        // with 32 bits of precision.
        random: function() {
            // If we already have a saved number, return it,
            // also clearing it for later use.
            if (saved != null) {
                var temp = saved;
                saved = null;
                return temp / MAXINT_PLUS_1;

            // x = s[0]
            var x = new Uint32Array(2);
            x[0] = state[0];
            x[1] = state[1];

            // y = s[1]
            var y = new Uint32Array(2);
            y[0] = state[2];
            y[1] = state[3];

            // s[0] = y
            state[0] = y[0];
            state[1] = y[1];

            // (a): x ^= x << 23
            var xl23 = new Uint32Array(2);
            xl23[0] = x[0] << 23;
            xl23[1] = (x[1] << 23) & (x[0] >> 11);
            x[0] ^= xl23[0];
            x[1] ^= xl23[1];

            // (b): x ^= x >> 17
            var xr17 = new Uint32Array(2);
            xr17[1] = x[1] >>> 17;
            xr17[0] = (x[0] >>> 17) & (x[1] << 19);
            x[0] ^= xr17[0];
            x[1] ^= xr17[1];

            // (c): x ^= y ^ (y >> 26)
            var yr26 = new Uint32Array(2);
            yr26[1] = y[1] >>> 26;
            yr26[0] = (y[0] >>> 26) & (y[1] << 6);
            x[0] ^= y[0] ^ yr26[0];
            x[1] ^= y[1] ^ yr26[1];

            // s[1] = x
            state[2] = x[0];
            state[3] = x[1];

            // return x + y
            var retval = new Uint32Array(2);
            retval[0] = x[0] + y[0];
            retval[1] = x[1] + y[1] + (retval[0] < x[0]);
            saved = retval[1];
            return retval[0] / MAXINT_PLUS_1;

I’ve written it as a Node.js module, but you can easily adapt it to a browser environment by changing module.exports on line 1 to window.xorshift or whatever you like. Whether it’s attached to the global window (browser) or loaded with require() (Node), the function creates an object with two methods: random() and seed(), both of which are explained below.

This isn’t a perfect implementation, and it does have a limitation that the original doesn’t have. This is because of JavaScript’s number handling, which might best be termed as “special”. JS only really has 64-bit floats for numbers, unless you do even more TypedArray contortions than I did here. So I had to compromise by making the random() function output numbers between 0 and 1 with 32 bits of resolution. Each run of the algorithm creates 64 bits of randomness, so I split that into two numbers, saving the second for the next call to the RNG. Changing the function to return integers instead of floats is easy enough: remove the two divisions by MAXINT_PLUS_1.

The whole reason for making this thing was to have a predictable RNG for JavaScript. That’s what the seed() function does. Pass in a single 32-bit integer or a typed array of them, and it will seed the algorithm using that. (One good way to extend this would be to use a hash such as MD5 to allow strings and other objects. That’s why the “TODO” comment is there.) If you don’t, it will use a few numbers generated from Math.random().

Another benefit of this (or any similar RNG) over the stock implementation is that you can create more than one, each tied to its own seed. This means that, for example, you can have your world generator running off a different sequence than your AI. You would then only have to save the seed for the world RNG, while the AI RNG gets reseeded when you reload the game. This would prevent players from, say, repeatedly reloading to get a good outcome of a battle in a strategy game.

As usual, I didn’t make the algorithm; I only wrote the code in this post. You can use it for whatever purpose you like, but I’m sure there are better implementations out there. I didn’t check, mostly because I wanted to try my hand at writing it first. It’s good practice.

Until next time, have fun!

Let’s make a language – Part 1a: Phonology (Intro)

The sound of a language is, in a sense, it’s first impression. And first impressions matter. How a language sounds, the spoken noises that it uses, can certainly influence the opinion of a listener (or reader). In the real world, for example, Westerners often perceive Arabic as a “harsh” language because of its series of “guttural” sounds. We might also talk about Chinese as a “musical” language, since it makes use of tone, a quality we’ll come to later. For conlangs, things are no different. The Elvish languages of Lord of the Rings are praised as melodious, while the Klingons of Star Trek speak a tongue that, like them, comes across as abrasive, violent. (Of course, in the case of conlangs, we have to look at things from the other direction sometimes. Elves have “enchanting” words because they’re supposed to. Klingons are a warrior race, and their language reflects this.)

All this is to say that the sound of your language is important. Even if you’re making a purely written language (like for a book), you might need to pronounce it at some point, and many readers will certainly try. After all, Dothraki began as a few words and phrases scattered almost haphazardly throughout the books of A Song of Ice and Fire. Once those books were turned into the Game of Thrones TV series, Dothraki (and Valyrian, which is barely found in the books at all, apart from a couple of fixed phrases like valar morghulis) had to become something more “real”.

To make a language, we need to understand a little about how languages work, and this is one of those posts. Specifically, we’re looking at what’s called phonology, i.e., the sounds that make up a language. Obviously, if your language isn’t spoken, like a sign language, then this post won’t be of much use. Honestly, though, I have no idea of how to even begin to make a sign language, so that’s the last I’ll say about them. (I can’t think of too many signed conlangs, unless you consider ASL a conlang. The closest thing I can come up with is the elaborate gesturing or “posing” of Daniel Abraham’s Long Price Quartet series, which is more of an addition to speech than a language of its own.) Also, if you’re making a language for aliens that don’t speak the way we do, then you’ve probably got bigger problems than I can solve.

(Digression: Okay, I had this whole thing planned out where I’d go over all the phonology stuff. But I scrapped it. Why? A few reasons. First, it was about 2,000 words just for the section on consonants. That was way too long for a post. Second, plenty of other people have already done the same thing. So, instead, I’ll leave you with a link to Wikipedia’s page on the International Phonetic Alphabet, which has clickable links for just about every possible sound found in human languages, and I’ll turn this post into something more general and useful for a beginning conlanger.)

The Sounds We Make

Every language in the world has a number of phonemes, which are basic units of sound. Think of them as letters, except we’re not necessarily talking about the ones in the alphabet. English, for instance, has 26 letters, but 40 or so phonemes, depending on dialect. Many of these phonemes, however, can surface as slightly different sounds, or allophones. The P sounds in pot and top are good examples of this. They don’t sound exactly the same, but they’re close enough that English speakers call them the same thing. A language like Hindi, on the other hand, does say they are different sounds: /p/ and /pʰ/.

Which (and how many) sounds you use in your language is largely a matter of style, and that directly relates to what kind of conlang you’re making. For languages intended to be for communication (auxlangs), you definitely want to use the most common sounds, most of which have IPA values of basic English letters: /p/, /t/, /k/, and so on. Adding in fancy things like retroflex consonants (despite being common in the very populous Indian subcontinent) or palatalization (found in Slavic languages and Irish, but not many other places) will only make things harder for the speakers that have to learn not only a new language, but new sounds to go with it.

For every other type of conlang, you might think you can just go wild with phonemes. Obviously, you can. I’m not stopping you. But something intended to sound natural should fit the patterns of natural languages. Otherwise, you end up with what I’ve heard called “shotgun phonology”. You may as well throw darts at an IPA chart. So, instead, let’s take a look at what linguistic evolution has come up with, and see if we can make something to match it.


We’ll start with consonants, both because there’s more of them and because that’s where some of the most interesting possibilities lie. English has about two dozen, which is pretty much average in the world, according to Chapter 1 of the World Atlas of Language Structures. (By the way, bookmark that site; we’ll be going back to it a lot. I’ll usually refer to it as WALS from here on out.) The minimum is about 6 or so, found in a few Pacific and Amazon languages like Rotokas and Pirahã. The high end goes up to around 80 in the Caucasian language Ubykh, and the click languages of Africa can have even more if you count the combination of click and stop as a single phoneme.

So, anywhere from 6 to 80. That’s quite a range, but we can narrow it down once we start looking for patterns. That’s the key to making a conlang seem natural in its phonemic inventory. Take English as an example, since we’re already using it. English has a set of labial consonants (/p b m f v/), a set of dentals (/t d n s z θ ð l r/), some post-alveolar or palatals (/ʃ ʒ tʃ dʒ j/), and a few velars (/k g ŋ w/). /h/ is the odd one out, but it’s like that in a lot of languages, so that’s okay. Looking at it from the other dimension, English has stops (/p b t d k g/), nasals (/m n ŋ/), fricatives (/f v θ ð s z ʃ ʒ h/), affricates (/tʃ dʒ/), and approximants (/r l j w/). Any way you look at it, essentially every consonant is related to another. There’s not, say, a uvular stop out by itself.

Any language you can think of works the same way. Spanish has a palatal series (/tʃ ɲ ʎ j/), Hindi has a set of retroflex consonants. The languages with smaller consonant inventories have broader distinctions. Rotokas, with its half a dozen consonants, divides them up in two dimensions: voiced or voiceless, and labial, alveolar, or velar. The enormous systems of the Caucasus come about similarly, but making finer distinctions. The 58 consonants of Abkhaz illustrate this. Labialized and non-labialized consonants are different in that language, and there is a set of ejective stops. Both of these combine to increase the inventory while avoiding outliers.

That’s not to say you can’t have outliers. You just need a good reason for them. If you’ve got /p/, /b/, and /t/ already, you’ll probably have /d/, too, but that doesn’t always have to be the case. Especially as you go “down” the phonetic chart, from stops to fricatives to approximants, there are a lot more opportunities to add wrinkles to the system. You can have /s/ and /k/ without having /x/, like English. Or /r/ without /l/, like in Japanese.

The same is true for “rare” sounds. Conlangers tend to over-represent two of these in particular: the English “th” sounds /θ ð/. (I’m guilty of it myself, with my language Suvile.) These sounds are comparatively rare (about 1 in 10 languages have them), but they’re far more common in conlangs. The same is true for some of the more outlandish distinctions, and the reason why is simple. A conlanger sees a sound he likes, and he builds the language specifically to have it, whether it fits or not. Again, if that’s what you like, go for it, but the result might feel “fake”.


Vowels have a bit less in the way of possibilities, and vowel systems tend to fall into a few basic categories. Here, English is on the large end of the scale, with up to 20 or more vowel sounds, depending on dialect. A few languages have only two vowel phonemes (Ubykh, mentioned above, is one of these), though these may take on different qualities at different points in a word. Five is the most common, though, according to WALS Chapter 2, and those five are usually the cardinal vowels /a e i o u/. Six is also common, with the addition usually being a schwa (/ə/) or a high central vowel like /ɨ/, though something like /æ/ isn’t out of the question. Systems with four vowels drop one of the cardinal quintet, usually /o/ or /u/. Three-vowel systems are almost always /a i u/, as these are maximally distinct.

Like with consonants, the key here is regularity, at least at the start. The common five vowels can be split into high (/i u/), middle (/e o/), and low. Or you could divide them into front (/i e/), central (/a/), and back (/o u/). Larger vowel systems become that way because they add dimensions. If you have the front vowels /i/ and /e/ and the rounded vowels /o/ and /u/, it’s not that much of a stretch to add in the front and rounded /y/ and /ø/. Similarly, a quality like length or nasalization tends to “spread” through the vowel system, multiplying the number of phonemes.

Vowel harmony is another of those ideas that conlangers get carried away with. The canonical example is Turkish, with its eight vowels /i y ɯ u e ø o a/. This makes a kind of 3D grid, where each vowel is either front or back, either high or low, and either rounded or unrounded. Turkish grammatical suffixes come in different forms, depending on which type of vowel they need, and a word must have its vowels all front or all back. This has an appealing symmetry of the kind that conlangers tend to love. Like the consonantal rarities above, though, there needs to be a reason, even if that reason boils down to “because it sounds cool”.

In my opinion, if you have no other pressing needs (like fitting in with names you’ve already made, for instance) then you should probably start with the basic five vowels. If you’re making an auxiliary language, then I’d strongly suggest stopping there. (Volapük used front vowels, because its creator was German. Esperanto went with the basic set instead. Which one’s more popular?)

Everybody else probably needs more, though. Still, start with the basics. If you add vowels, make sure they fit. More than consonants, vowels have a tendency to shift around in speech, almost like they’re floating. They like to be as distinct as possible. Sure, it might sound fun to have a language whose vowels are /i y e ø ɨ ʉ ɛ ɔ ɜ ɑ/, but it wouldn’t stay that way for long. A couple of generations of real language evolution would turn it into something like /i ɪ e ə æ u ʊ o/.


Besides consonants and vowels, we have one more thing to add to our study of phonology. Tone is probably the most popular in conlangs, simply because it isn’t found in many languages Westerners would be familiar with, making it seem exotic. (And the one major tonal language group is Chinese, further reinforcing that stereotype.) But tone is actually quite common in the world’s languages, especially in places of high linguistic concentration like Africa and the Amazon.

Tone itself can be divided into two varieties. Mandarin Chinese is an example of the first, which uses relative changes in pitch: level (called “high” in studies of the language), rising, dipping (falling from a low pitch to an even lower one, then sometimes rising again), falling, and a fifth, neutral tone found in weak syllables. Other languages have more or less complicated systems, but the idea remains the same: it’s the change in pitch that is important.

The alternative is a system where the tones themselves are steady, but at different levels. This is found, e.g., in Bantu languages of Africa. These are usually languages with two tones, a high and a low, or three, adding a middle tone. Four or more tones of this kind are rare, and it’s easy to see why. I mean, you could make a language with seven tones, each corresponding to a note on the major scale, and such a thing has indeed been done, but it would be awfully hard to speak. For speakers of such a language, singing lessons might be an integral part of grammar classes!

Obviously, an international auxlang likely won’t have tone, although one intended solely for communication in places where most languages are already tonal wouldn’t be out of the ordinary. For the more artistic conlangs, do whatever you want! In terms of numbers of languages, about half are tonal, though this is skewed by the large concentrations of tonality I mentioned above. (On a personal note, I’ve made one serious attempt at a tonal language, Lyssai. It’s for a race of elf-like forest dwellers in a story I’ll eventually write.)


Note: If you’re making an auxiliary language, you can probably skip this section.

A lot of the flavor of a language comes from its sound, and that sound comes largely from the phonemes used in the language. (Some of it comes from the syllable structure and stress patterns, which we’ll get into next time.) Guttural sounds from the back of the throat grate on American ears, while the liquid sounds of approximants and trills feel soft. Palatalized sounds have a “slurring” quality, while dentals make us think of a lisp.

For fictitious cultures, this stereotyping becomes useful. Tolkien puts into the mouths of his elves words full of fricatives and approximants and voiceless stops, all phonemes perceived as soft. In sharp contrast, orc speech is full of aspirated or voiced stops, both “uglier” types of sounds, a subtle way of confirming their status as the enemy.

Of course, if you’re making a language meant to be spoken by actors, you need to take that into account, too. That’s why Dothraki, for example, has such a relatively simple phonology. (The exception is the lone uvular stop [q], which goes against what I said earlier about phoneme sets, but he’s getting paid, and I’m not. Oh well.)

So, the lessons we can learn here are many:

  1. If you’re making an auxiliary language, choose sounds and sound distinctions that are fairly common. Esperanto arguably screwed up by including a palatal series. Volapük did the same with front rounded vowels. Of course, French was once the lingua franca (it’s right there in the name), and it has a pretty complex phonology, so there are always exceptions.

  2. Artistic languages can have whatever sounds you can pronounce. But remember your audience. Americans probably aren’t going to be able to pronounce pharyngeals. Japanese speakers might not be able to manage [θ] and [ð].

  3. Phonemes, especially stops, tend to be connected. A distinction made on only one phoneme feels unnatural. It’s not impossible, mind you, just less likely.

  4. Vowels are like a gas. They expand to fill their space, and they spread out. The fewer you have, the more guises they can take. A language with only /a i u/, for example, can still have [e o] as allophones.

  5. Tone is nice, and it can be interesting, but you need to study up on how it’s used. (Actually, this can go for anything else in this gigantic post.)

  6. There are more things on heaven and earth than are dreamt of in your language. The conlang community has a saying known as ANADEW: a natlang (natural language) already did, except worse. Almost every concept that a conlanger thought he came up with, some real language spoken somewhere has it.

That’s it for now. (Finally!) Next time, we’ll get into the sound systems of our two languages, Isian and Ardari.

First Languages for Game Development

If you’re going to make a game, you’ll need to do some programming. Even the best drag-and-drop or building-block environment won’t always be enough. At some point, you’ll have to make something new, something customized for your on game. But there are a lot of options out there. Some of them are easier, some more complex. Which one to choose?

In this post, I’ll offer my opinion on that tough decision. I’ll try to keep my own personal feelings about a language out of it, but I can’t promise anything. Also, I’m admittedly biased against software that costs a lot of money, but I know that not everyone feels the same way, so I’ll bite my tongue. I’ll try to give examples (and links!) of engines or other environments that use each language, too.

No Language At All

Examples: Scratch, Construct2, GameMaker

For a very few cases, especially the situation of kids wanting to make games, the best choice of programming language might be “None”. There are a few engines out there that don’t really require programming. Most of these use a “Lego” approach, where you build logic out of primitive “blocks” that you can drag and connect.

This option is certainly appealing, especially for those that think they can’t “do” programming. And successful games have been made with no-code engines. Retro City Rampage, for example, is a game created in GameMaker, and a number of HTML5 mobile games are being made in Construct2. Some other engines have now started creating their own “no programming required” add-ons, like the Blueprints system of Unreal Engine 4.

The problem comes when you inevitable exceed the limitations of the engine, when you need to do something its designers didn’t include a block for. For children and younger teens, this may never happen, but anyone wanting to go out of the box might need more than they can get from, say, Scratch’s colorful jigsaw pieces. When that happens, some of these engines have a fallback: Construct2 lets you write plugins in JavaScript, while GameMaker has its own language, GML, and the newest version of RPG Maker uses Ruby.

Programming, especially game programming, is hard, there’s no doubt about it. I can understand wanting to avoid it as much as possible. Some people can, and they can make amazing things. If you can work within the limitations of your chosen system, that’s great! If you need more, though, then read on.


Examples: Unity3D, Phaser

JavaScript is everywhere. It’s in your browser, on your phone, and in quite a few desktop games. The main reason for its popularity is almost tautological: JavaScript is everywhere because it’s everywhere. For game programming, it started coming into its own a few years ago, as mobile gaming exploded and browsers became optimized enough to run it at a decent speed. With HTML5, it’s only going to get bigger, and not just for games.

As a language, JavaScript is on the easy side, except for a few gotchas that trip up even experienced programmers. (There’s a reason why it has a book subtitled “The Good Parts”.) For the beginner, it certainly offers the easiest entry: just fire up your browser, open the console, and start typing. Unity uses JS as its secondary language, and about a million HTML5 game engines use it exclusively. If you want to learn, there are worse places to start.

Of course, the sheer number of engines might be the language’s downfall. Phaser might be one of the biggest pure JS engines right now, but next year it could be all but forgotten. (Outside of games, this is the case with web app frameworks, which come and go with surprising alacrity.) On top of that, HTML5 engines often require installation of NodeJS, a web server, and possibly more. All that can be pretty daunting when all you want to do is make a simple game.

Personally, I think JavaScript is a good starting language if you’re careful. Would-be game developers might be better off starting with Unity or Construct2 (see above) rather than something like Phaser, though.

C++ (with a few words on C)

Examples: Unreal Engine 4, SFML, Urho3D

C++ is the beast of the programming world. It’s big, complex, hard to learn, but it is fast. Most of today’s big AAA games use C++, especially for the most critical sections of code. Even many of the high-level engines are themselves written in C++. For pure performance, there’s not really any other option.

Unfortunately, that performance comes at a price. Speaking as someone who learned C++ as his second programming language, I have to say that it’s a horrible choice for your first. There’s just too much going on. The language itself is huge, and it can get pretty cryptic at times.

C is basically C++’s older brother. It’s nowhere near as massive as C++, and it can sometimes be faster. Most of your operating system is likely written in C, but that doesn’t make it any better of a choice for a budding game programmer. In a way, C is too old. Sure, SDL is a C library, but it’s going to be the lowest level of your game engine. When you’re first starting out, you won’t even notice it.

As much as I love C++ (it’s probably my personal favorite language right now), I simply can’t recommend starting with it. Just know that it’s there, but treat it as a goal, an ideal, not a starting point.


Examples: LÖVE, many others as a scripting or modding language

Lua is pretty popular as a scripting language. Lots of games use it for modding purposes, with World of Warcraft by far the biggest. For that reason alone, it might be a good start. After all, making mods for games can be a rewarding start to game development. Plus, it’s a fairly simple language that doesn’t have many traps for the unwary. Although I’ll admit I don’t know Lua as well as most of the other languages in this list, I can say that it can’t be too bad if so many people are using it. I do get a kind of sense that people don’t take it seriously enough for creating games, though, so take from that what you will.


Examples: Unity3D, MonoGame

C# has to be considered a good candidate for a first language simply because it’s the primary language of Unity. Sure you can write Unity games in JavaScript, but there are a few features that require C#, and most of the documentation assumes that’s what you’ll be using.

As for the language itself, C# is good. Personally, I don’t think it’s all that pretty, but others might have different aesthetic sensibilities. It used to be that C# was essentially Microsoft-only, but Mono has made some pretty good strides in recent years, and some developments in 2015 (including the open-sourcing of .NET Core) show positive signs. Not only that, but my brother finds it interesting (again, thanks to Unity), so I almost have to recommend at least giving it a shot.

The downside of C# for game programming? Yeah, learning it means you get to use Unity. But, that’s about all you get to use. Besides MonoGame and the defunct XNA, C# doesn’t see a lot of use in the game world. For the wider world of programming, though, it’s one of the standard languages, the Microsoft-approved alternative to…


Examples: LibGDX, JMonkeyEngine, anything on Android

Java is the old standard for cross-platform coding. The Java Virtual Machine runs just about anywhere you can think of, even places it shouldn’t (like a web browser). It’s the language of Minecraft and your average Android app. And it was meant to be so simple, anybody could learn it. Sounds perfect, don’t it?

Indeed, Java is simple to learn. And it has some of the best tools in the world. But it also has some of the slowest, buggiest, most bloated and annoying tools you have ever had the misfortune of using. (These sets do overlap, by the way.) The language itself is, in my opinion, the very definition of boring. I don’t know why I feel that way, but I do. Maybe because it’s so simple, a child could use it.

Obviously, if you’re working on Android, you’re going to use Java at some point. If you have an engine that runs on other platforms, you might not have to worry about it, since “native” code on Android only needs a thin Java wrapper that Unity and others provide for you. If you’re not targeting Android, Java might not be on your radar. I can’t blame you. Sure, it’s a good first language, but it’s not a good language. The me from five years ago would never believe I’m saying this, but I’d pick C# over Java for a beginning game developer.


Examples: Pygame, RenPy

I’ll gladly admit that I think Python is one of the best beginner languages out there. It’s clean and simple, and it does a lot of things right. I’ll also gladly admit that I don’t think it can cut it for game programming. I can say this with experience as I have tried to write a 2D game engine in Python. (It’s called Pyrge, and you can find the remnants of it on my Github profile that I won’t link here out of embarrassment.). It’s hard, mostly because the tools available aren’t good enough. Python is a programmer’s language, and Pygame is a wonderful library, but there’s not enough there for serious game development.

There’s always a “but”. For the very specific field of “visual novels”, Python does work. RenPy is a nice little tool for that genre, and it’s been used for quite a few successful games. They’re mostly of the…adult variety, but who’s counting? If that’s what you want to make, then Python might be the language for you, just because of RenPy. Otherwise, as much as I love it, I can’t really recommend it. It’s a great language to learn the art of programming, but games have different requirements, and those are better met by other options.

Engine-Specific Scripting

Examples: GameMaker, Godot Engine, Torque, Inform 7

Some engine developers make their own languages. The reasons why are as varied as the engines themselves, but they aren’t all that important. What is important is that these engine-specific languages are often the only way to interact with those environments. That can be good and bad. The bad, obviously, is that what you learn in GML or GDScript or TorqueScript doesn’t carry over to other languages. Sometimes, that’s a fair trade, as the custom language can better interact with the guts of the engine, giving a performance boost or just a better match to the engine’s quirks. (The counter to this is that some engines use custom scripting languages to lock you into their product.)

I can’t evaluate each and every engine-specific programming language. Some of them are good, some are bad, and almost all of them are based on some other language. Godot’s GDScript, for example, is based on Python, while TorqueScript is very much a derivative of JavaScript. Also, I can’t recommend any of these languages. The engines, on the other hand, all have their advantages and disadvantages. I already discussed GameMaker above, and I think Godot has a lot of promise (I’m using it right now), but I wouldn’t say you should use it because of its scripting language. Instead, learn the scripting language if you like the engine.

The Field

There are plenty of other options that I didn’t list here. Whether it’s because I’m not that familiar with the language, or it doesn’t see much use in game development, or because it doesn’t really work as a first language, it wasn’t up there. So here are some of the “best of the rest” options, along with some of the places they’re used:

  • Swift (SpriteKit) and Objective-C (iOS): I don’t have a Mac, which is a requirement for developing iOS apps, and Swift is really only useful for that purpose. Objective-C actually does work for cross-platform programming, but I’m not aware of any engines that use it, except those that are Apple-specific.

  • Haxe (HaxeFlixel): Flash is dying as a platform, and Haxe (through OpenFL) is its spiritual successor. HaxeFlixel is a 2D engine that I’ve really tried to like. It’s not easy to get into, though. The language itself isn’t that bad, though it may be more useful for porting old Flash stuff than making new games.

  • Ruby (RPG Maker VX Ace): Ruby is one of those things I have an irrational hatred for, like broccoli and reality shows. (My hatred of cats, on the other hand, is entirely rational.) Still, I can’t deny that it’s a useful language for a lot of people. And it’s the scripting language for RPG Maker, when you have to delve into that engine’s inner workings. Really, if you’re not using RPG Maker, I don’t see any reason to bother with Ruby, but you might see things differently.

  • JavaScript variants (Phaser): Some people (and corporations), fed up with JavaScript’s limitations, decided to improve it. But they all went in their own directions, with the result of a bewildering array of languages: CoffeeScript, TypeScript, LiveScript, Dart, and Coco, to name a few. For a game developer, the only one directly of any use is TypeScript, because Phaser has it as a secondary language. They all compile into JS, though, so you can choose the flavor you like.

If there’s anything I missed, let me know. If you disagree with my opinions (and you probably do), tell me why. Any other suggestion, criticism, or whatever can go in the comments, too. The most important thing is to find something you like. I mean, why let somebody else make your decisions for you?