An announcement for the new year

So I’ve been doing this thing pretty regularly for a year and a half now. Except for a few illness-related breaks, I’ve been putting up three posts a week since the middle of 2015. I’m not complaining; I love doing this. But now that I feel like moving towards writing more original works of fiction, I’m not sure I can keep up the pace I’ve set for myself. See, I usually write these posts in one big batch at the end of a month, or when I have no other works in the, well, works. (For example, I’m actually writing this on October 4. Last week, I finished the final part of my Otherworld novella series, and I’m mostly killing time until NaNoWriMo.)

If I’m going to make a more serious effort at writing full stories, I don’t know if I can handle also writing 10-15 posts here. These tend to run about 1000 words apiece, sometimes far more—that’s basically 25% of my average monthly output that I could dedicate to other work. And honestly, I’m starting to run out of ideas for posts. I’m not doing as much coding as before. Really, my whole life right now is in a place I’d describe as…not the best. Fiction is my escape from that. The nonfiction I put up here just doesn’t have the same beneficial qualities.

So here’s what I’ve decided, looking at the three main types of posts I do on Prose Poetry Code, and then the ongoing series I’ve been running.


Wednesdays have been my dedicated day for code-related articles. As I said, I haven’t done much in that area lately. I tried back in June to make a game, but you saw how that worked out. It’s not that I don’t like programming anymore. I still do, believe me. It’s more that I have other things on my mind, and the very analytical, very mathematical necessities of writing good code take me out of the moment.

For these, I’m going to drop back severely. I’ll probably only write 1-2 code posts per month in 2017, unless something big comes up. The field still interests me, and there’s a lot of fertile ground there, but the research and thought required to make a good post about programming each week just isn’t worth it right now. Maybe I’ll change my mind down the road.

Writing & worldbuilding

These are the meat of the site, in my opinion. The Monday posts are where I have the most fun, because they give me the chance to let my imagination roam free. Worldbuilding really is my favorite part of writing. If I lose it, then I’ve lost any reason to even have this place.

Therefore, I’ll keep Mondays mostly as they are. There might be a few more weeks off through the year, but rest assured that those will be for good reason: I’ll be writing something more important. In all, count on about 40 or so total posts about worldbuilding and general writing next year.

Languages and verse

Fridays originally started out as a way to showcase the art of conlangs. After all, language construction is one of the things that got me into worldbuilding in the first place. It’s only fair to give it the honor it deserves. Since then, I’ve been branching out a bit. Now, the last post of the week has become the time when I talk about poetry, song, verse, and music.

I’d like to keep that going, though maybe not at the same high level. I’ll probably take 1-2 Fridays off per month through 2017, meaning you’ll have around 30 total posts. Most of those will be conlang-related, but some will pick up the other topics.


I do a lot of post series. I like them. They’re like chapters in a book, each building off the last or taking something in a new direction. I like the continuity. But lately it seems like all my posts are part of a series. There aren’t that many one-offs. So, for the coming year, I’m going to take a step back. For each of the main series I’ve got going, here’s my plans:

  • “Let’s make a language”: This was practically the reason I started the whole site. It’s not stopping in the near future. I’ve got plans all the way out to Part 27; at one part per month, that takes me through June. After that, it shouldn’t be too hard to come up with more ideas.

  • “Magic and tech”: Another one of my personal favorites, but I’m starting to run low on material. I think I’ll drop this back to one post every two months, or 6 for the year. Maybe, I’ll even have enough work here to write a novella set in the magical realm the series describes.

  • “Building aliens”: This one has almost run its course. I’ll let it, and then I think I’ll let it retire. Now, I’m not going to stop posting about aliens, so don’t worry about that. This is just the hard SF alien-making series that’s going away.

  • “Software internals”: There’s only so much more I can do here without getting way too bogged down in technical details, so I’m putting this one on hiatus. If there’s any kind of desire to see it return, I’ll consider it later on.

  • “Project SL”: The whole Social Liberty thing was a response to the election year. It won’t be back in post form.

  • “Assembly”: I love assembly language, but trying to debug code in a web-based emulator is annoying, even frustrating. If v86 gets better, I’ll look into starting it back up. (Really, what I need most is clipboard support.)

Never fear / Happy New Year!

I’m not abandoning this place. I’ve made a promise to myself that I wouldn’t let that happen. The quantity of posts will go down in 2017, but I hope that will be balanced out by a corresponding increase in quality. If I don’t have to worry as much about finding the material for three posts a week, maybe I can spend more time on each post that I do write. So even though it may not seem like I’m around as much, I’ll still be here. Now, let’s make 2017 the best year ever!

Programming in 2016: game development

I tried to make a game this year. My body failed me. But I’ve been keeping up with the news in the world of game development, and 2016 has been exciting, if a bit frustrating.


Unity’s still the big kahuna for indie development. But they’ve gone to that same “rapid release” model that everyone else has, the same one that has all but ruined Firefox, Windows, and so many other projects. On top of that, they switched to a subscription model. Rather, they switched to a subscription-only model.

Yes, that’s right. You can only rent the Unity engine on a monthly basis now. It’s still free for tiny devs, but it actually costs more now for everybody else. Sure, there’s the new Plus tier (something like $40 a month, I think), but it doesn’t give you much over the Free version. By the time you need it, you can probably afford the full subscription.

On the technical side, they’re making progress towards Vulkan support, and there are rumblings about actually upgrading their version of C# to something approaching modern. That’s probably thanks to the .NET Core open-sourcing I mentioned last week, but I don’t care what the reasoning is. Any upgrade is welcome here.

The other rumor is that they might switch to C++. I…don’t know about that one. On the one hand, I have to say, “Yes, please!” Modern C++ is just as good as C# in almost every way. In many, it’s better. However, what does this do to that huge body of C# Unity code? If there’s a compatibility layer, then you’ve got inefficiencies. If they simply include the “old” engine, they’ve only made more work for themselves. And then you have JavaScript, which is still (mostly) a supported language for Unity coding. How would it fit in to a C++ future?


Godot is still my favorite 2D engine. It’s free, the source is open, and it’s very easy to use. 3D is a known problem, but that doesn’t bother me much; I’m not capable of making a 3D game anyway.

Well, Godot made their big announcement back in the summer, with the release of version 2.1. It’s not really revolutionary, but it sets the stage for greater things. Time will tell if those come to pass, but I think they will. With 2.2, we’re supposed to get a better renderer and possibly C# support. The big 3.0 might even add Vulkan to the mix, not that it helps me. And the Asset Library, well, it can only get bigger, right?

The main problem for Godot has been its documentation, and that’s much improved over this time last year. There’s a growing body of tutorials out there, too. I don’t think the engine has reached critical mass yet, but I also don’t think it has peaked.

Maybe—if I don’t get sick the day after I announce it—I’ll try another “game in a month” thing. If I do, it’ll be in Godot.

Lots of little ones

I didn’t do much in the way of development in 2016. I didn’t look at Unreal in anything other than passing, for example. But I’ve kept an eye on happenings in the game dev world, and here are some quick thoughts on other engines out there:

  • Unreal is, like the C++ it’s written in, solid and relatively unexciting. That’s what makes it exciting.
  • Superpowers might be a nice little JavaScript platform, but it’s got this horrible bug that makes all the dropdown boxes turn solid black. Makes it hard to use, you know?
  • Clickteam Fusion may or may not be getting bigger in 2017. They’re working on their version 3 release, and it might be cross-platform. Stay tuned for more on that front.
  • Amazon put out their Lumberyard (a fork of CryEngine). It’s free, as long as you’re willing to use their cloud services, but the real cost is in the machine you need to run the environment.
  • CryEngine itself is…strange. They’ve put out source code, but it’s not open. In fact, reading the license, t’s almost impossible to find a game you could even make! Maybe they’ll fix that, but I wouldn’t hold my breath.
  • The Atomic Game Engine looked like a promising release a few months ago, but it seems to be dead. The developers haven’t put out any news since May, and the forums were shut down in favor of Facebook. Sounds like they don’t want new users to me.
  • Finally, RPG Maker has a new version. It’s finally becoming something other than Windows-only, and the coding part has followed the hipster crowd from Ruby to JavaScript. In my opinion, that can only be a good thing.

I could go on, but I’m running out of year, so I’ll stop. Let’s just say this: 2016 was a good year for an independent game developer. 2017 will be even better. You’ve got a massive selection of engines at your disposal, from solid open-source offerings to AAA beasts. Maybe next year will be when we finally solve the asset problem. We’re getting there, slowly but surely.

Let’s make a language, part 21c: Occupations and work (Ardari)

For Ardari, things aren’t much different from Isian. There’s still the big difference between the agris “rich” and nydor “poor”, those who have a kroll “job” and those who don’t. Ardari speakers are a bit more worldly, however, as can be seen in the modern öskul “school” common to every town. Their larger cities also each have a bank (prèt), ready to lend (khipy-) money to anyone who might need it.

By contrast, the alz “farm” isn’t as central to Ardari culture as it is to Isian. Being more urban, Ardari speakers are more likely to work at (if not run) a chemba “shop” or pyuli “restaurant” instead. Many work at building (moll-), as their people are in a state of growth these days. Diggers (dròkön, the same term is used generically to refer to any “blue-collar” worker) are needed everywhere, as well. Most of these, however, are men, while women tend to do things like cook (lòsty-) or weave (urdè-). Most respected of all, though, is the sydonkön “teacher”, an important man (or, as is increasingly the case, woman) in every locale.

Although farming isn’t as big a deal as it once was, rural areas still rely on it heavily. The èmlokön remains a necessary and honorable profession; land is passed down from father to son as it has been for centuries. Mills (panad) are integral, even if the miller (tyokön) more often observes and pushes buttons these days. Finally, the market (virdègh) continues to act as the center of an Ardari community, no different from how our shopping malls used to be.

Next time…?

So that covers Part 21 of our series on creating conlangs. We’re nowhere near done—if you think about it, we’re never truly finished, but bear with me here. Now, I can keep going. I actually do have plans all the way out to Part 27. However, as you’ll see in the coming days, I’ve got other things on my mind. There are places I want to go with Prose Poetry Code, and that includes this series. So I might slow down a bit on these posts. Or I may continue on the current schedule, with three posts (comprising one part) a month. I’ll be good through the first half of 2017 if I do that. Stay tuned for my decision; in the meantime, keep creating, and have a happy holiday, whichever one you celebrate.

Word list

General terms
  • job: kroll
  • poor: nydor
  • rich: agris
  • to borrow: mänyt-
  • to create: grät-
  • to destroy: sògör-
  • to lend: khipy-
  • to repair: èbord-
  • to use: qas-
  • to work: nafèlo
  • work: naf
Places of work
  • bank: prèt
  • bar (pub): om
  • farm: alz
  • inn: mäsoza
  • market: virdègh
  • mill: panad
  • restaurant: pyuli
  • school: öskul (borrowing)
  • shop: chemba
Work actions
  • to bake: mej-
  • to build: moll-
  • to clean: fènt-
  • to cook: lòsty-
  • to dig: drò-
  • to drive: brech-
  • to fold: sòv-
  • to grind: tyokh-
  • to guard: chud-
  • to hunt: kwar-
  • to pour: swar
  • to press: akwèt-
  • to serve: klo-
  • to sew: wènt-
  • to shoot: käzh-
  • to sweep: nwèse-
  • to teach: sydon-
  • to tie: tölon-
  • to wash: majtas-
  • to weave: urdè-
  • baker: mejkön
  • carpenter: mollkön
  • cooking: lòstyënda
  • driver: brechkön
  • farmer: èmlokön
  • hunter: kwarkön
  • hunting: kwarönda
  • janitor: nwèsekon
  • laborer: dròkön
  • miller: tyokön
  • servant: klokön
  • tailor: wèntökön
  • teacher: sydonkön
  • teaching: sydonda (from sydon- + -önda)

Programming in 2016: languages

It’s nearing the end of another year, and that’s the cue for sites the world over to start looking back on the past twelve months. Due to a lack of creative impulse in the code sphere, I’ll be doing the same. So let’s see how the science and art of programming fared in 2016, starting with the advances and changes in programming languages.


JavaScript might not be the biggest language out there, but it’s certainly the one most people have experienced in some form, so it makes sense to start here. And JavaScript has certainly seen some improvements this year. For one thing, it’s got a new version, as the standards guys have moved to the same silly release model that gave us modern Firefox and Chrome. The only things added to ES2016 (what should have been ES7) are an exponent operator and a single new Array method, includes(). Absolutely nothing to get excited over, and the “big” changes, like async, are still in the future…if they’re ever put in at all.

On the other hand, the environment for JavaScript is getting better all the time. You can count on full ES5 support now, and you shouldn’t have too much trouble using ES6 features. Maybe you’ll need a polyfill for those, but that’s a temporary solution. And the one good thing about Windows 10 is Edge, if only because it’s the end of the “old” Internet Explorer and that browser’s awful support for, well, anything.

Outside the browser, Node keeps chugging along. They’ve had some problems there (such as the leftpad debacle), but they’ve got that whole Node/IO.js fork thing worked out. From a political standpoint, it’s not optimal, but the codebase is solid enough. The ecosystem is growing, too, as almost everybody is using some sort of Node/Webkit construction, from Visual Studio Code to Atom to Vivaldi.

As usual, JavaScript’s future looks much brighter than its past. It’s still straining at its own boundaries, but it’s growing. It’s becoming a better language. The two main platforms (browser and Node) have improved by leaps and bounds, and now they’ve become mature. In the next year, they’ll only get better.


C++ had a big year in 2016, but it was all behind the scenes. The real test will come next year, when the C++17 standard comes out, but we already know what it’s going to have in it. What might that be? More of everything, really. I’ve already written about some of the more interesting bits in a three-part series back in August. (Part 1, Part 2, Part 3)

So 2017 looks like it’ll be fun, but what about now? “Modern” C++ is finally getting widespread support, so that’s good. Even those of you stuck on five-year cycles should now be ready for that, and C++14 was an incremental upgrade. On the platform side, it’s C++. The platform is your computer, or your phone, or your refrigerator. It’s the same platform it’s always been. That’s why you would use it over any other language.


Microsoft has been doing their schizophrenic love-hate thing with open source for a while now, but 2016 saw the biggest payoff of the “love” side. The open release of .NET Core happened this summer, complete with support for platforms other than Windows. Considering how hard it can be to get MS to even acknowledge such a thing, that’s practically a miracle.

It’s also the beginning of the end for Mono—the third E stands for Extinguish, remember—but that’s not as bad as it sounds. Mono still has its uses, mostly for older .NET code and the things that the MS offering won’t support. Oh, and they also bought Xamarin, whose main reason for existing seemed to be letting you write C# code for mobile devices. But if even some of .NET is open-source, we don’t need that anymore. The community can do it.

C# remains a Microsoft language, though. The MIT license won’t change that. It’ll definitely give non-Windows developers some peace of mind, but you always have to remember who holds the cards here.


Java’s a funny thing. On the one hand, it’s not that bad a platform. On the other, it’s owned by Oracle. They’re still playing the part of Sisyphus, rolling a ball of lawsuits up the hill, only for the courts to send them right back down. But unlike in mythology, there’s the possibility that they might win.

If they do, it’s bad news for everyone, but most of all for Java developers. Who would want to use a language owned by a sue-happy corporation? (And now the C# fanboys can say, “There’s another thing Java ripped off!” Well, okay, at least MS hasn’t sued anybody using C#. Yet.)

But if you can put that out of your mind, Java’s not bad. It’s awful from a security standpoint, and the language sucks, and—well, you get the idea. I still believe it has some upside, though. Scala—or Clojure, if that’s the way you roll—makes using the JVM bearable. Android requires Java coding, even if they desperately want to call it something else.

So Java’s 2016 has been mostly dismal, but look on the bright side: Java 9 is coming soon. And one proposal on the table is “ahead-of-time compilation”. For Java. Just think about that for one second. Maybe I’m misunderstanding, but wasn’t that the exact thing Java was designed to prevent?

The rest

Other languages have had an interesting year, but it’s too much work to list them all. Besides, I haven’t used that many of them. But here’s a few of the highlights:

  • Rust is growing. It’s almost to the point of being usable! (The rewrite of Firefox into Rust will come before that point, however.)
  • Go is still bad, but at least Google isn’t trying to push it (or Dart) on Android devs anymore. I’ll call that an improvement.
  • Python really seems to be disappearing. It’s had some minor releases, but nothing amazing. That’s a good thing, but the glaring flaws of Python 3 haven’t gone away.
  • PHP remains the bad joke of the programming world, but maybe PHP 7 can fix that. Because PHP 6 did so well.
  • Perl 6…exists! Technically, that happened last Christmas, but it’s close enough. You can’t complain about a once-in-a-lifetime occurrence.

We’ll round out the year next week by looking at another area of development: games.

On colonialism

The process of colonization ran for untold millennia before it came to a halt in the past few generations, but colonialism is uniquely tied to the period beginning around 1500, with the first Spanish incursions into the Americas, and ending with the independence movements of British, French, German, and other territories around the end of World War I. That’s about 400 years worth of colonial sensibilities, a fairly large swath of “modern” history affected by the building and upkeep of colonies.

What can we use from that time to build a good story? It’s a little beyond the traditional view of fantasy, but this period has become a significant part of the post-medieval fantasy subgenre. Paul Kearney’s Monarchies of God series and Django Wexler’s The Thousand Names are two excellent works I’ve read in recent years that fit into the “colonial era”; the first is a voyage of exploration to a new world, the latter a native uprising in a faraway imperial holding. These neatly bracket the ends of the era, in fact: colonialism begins with the first attempt at a colony, and it ends when the native—or nativized—population revolts against its distant masters.

Making a colony

The colony itself, obviously, is the central focus of a colonial story. At the beginning, it’s very much a tale of people struggling to tame a hostile environment. The true stories of European settlers coming to America are riveting. They’re full of doubt and faith, strife both with the natives and with each other, desperation and perseverance. Australia, sub-Saharan Africa, and southern Asia all have equally gripping accounts of the trials and tribulations the supposedly advanced Europeans had to endure to make those places their own. Even in the realm of science fiction, one can imagine a story about the first colonists on the moon, Mars, or a planet in a distant solar system to fall along the same lines.

After the initial struggles, the colony is not out of the woods by any means. They’ll have to adapt to their new location, to the sheer distance from their homeland. In 18th-century Australia, for instance, colonists might as well have been on another world, because they about as likely to return to England. The churning waters of the Atlantic meant that the Americas were little better off. India and Indochina were surrounded by hostility, and the antagonism of the natives of Africa is the stuff of legend. Add to that the unfamiliar terrain, the entirely new set of flora and fauna, even the differences in climate—a colony today wouldn’t be a sure thing, and these people managed it as much as 500 years ago!

Eventually, the early turbulence settles, probably after a generation or two. Once the original settlers have died off, you’re left with a population that is truly “native”. That’s where the real fun of colonialism comes in. The home government (or corporation, or whatever) might want to send more colonists, and this will cause a clash between the newcomers and those who have grown up in the colony. Or the colony’s patrons back home might want something to show for their initial outlay; some colonies were established purely for profit, especially in the Far East.

It’s entirely likely for these tensions between the colony’s native inhabitants and their motherland to grow into rebellion or open revolt. It took England’s American colonies a century and a half to reach that point, longer for India and South Africa, but it did happen. Of course, that coincided with an increased liberalism in political thought, part of the Enlightenment that ran through the entire Western world. Without the philosophies of the late 18th century, the cause of American independence (and the Mexican, African, Indian, and others that followed in its wake) might have been delayed by decades.

Our land

There’s a single wild card that makes colonizing into colonialism: the natives. Whether we’re talking about Native Americans, Australian Aborigines, or any other preexisting population, they’ll have something to say about the foreigners landing on their shores, claiming their lands. In our history, we know how that turned out, but it wasn’t always a sure thing.

Australia had a relatively sparse population anyway, but its indigenous inhabitants tended to live in the same general areas that the colonists wanted to take for themselves. They’re the best lands on an otherwise marginal continent, so that’s not surprising. The Americas, on the other hand, may have been peopled to a much larger extent. Upper estimates put the total Native American population in 1491 as high as 100 million. Half that sounds more reasonable, but that’s still a lot more natives than you might think from watching westerns.

We know what happened to most of them, though: they died. Disease and what might be called an early example of ethnic cleansing did them in. The same things tended to have the same effect—devastation—on all the other native populations of the world, but the Americas get top billing, thanks to a combination of factors. One, the US has a lot more global power than Australia or South Africa. Two, the colonization started earlier, so the effects of this interchange of genes, ideas, and disease vectors weren’t understood as well as in the 1700s. And third, the violent persecution of the indigenous peoples didn’t end with colonialism; anti-Indian sentiment ran high for the first century of the United States’ existence. Yes, apartheid lasted longer as an institution, but it was more political than militant.

But enough about that. Let’s get back to colonialism. Anywhere there’s a society, even a tribal one, in place, there’s bound to be friction. The Europeans won everywhere both from the disease factor and because of their relative level of technology. Once the illnesses had run their course, and the surviving native remnants were immune or simply too remote to become infected, the guns and horses utterly outclassed anything they could bring to bear.

It wasn’t always constant warfare and subjugation, though. Many colonies wanted to work with the natives. The reasons for cooperation are obvious: here’s a culture that’s already entrenched. They know the land in a way you never will, and all they want are a few of your high-quality guns or blankets or iron pots. In exchange, they teach you how to live better. And some of the colonists badly needed such lessons. Religious dissidents and petty criminals make poor settlers in the best circumstances, and colonies were far from that. It’s not surprising, then, that so many histories of colonization start with a few years of working in concert with the natives.

The colonial populations always seem to grow faster than the indigenous ones, because they’re not susceptible to the diseases they brought and because they’re often being supplemented by a steady influx of new colonists from the homeland. Thus, it’s almost natural that the settlers start taking more and more land, squeezing out the natives. That’s when the squabbles start. Maybe it begins as a raid here or an assassination there. Eventually, it can become something far greater, as in the cases of King Philip’s War in America and the Zulu wars in Africa. (Sometimes, as with the French and Indian War, it can be helped along by outside forces.)

If all-out war happens, it’s rarely to the sole detriment of the colony. The natives can inflict some serious wounds—the Zulus certainly did—but a colonial nation necessarily has a sizable military backing. It’s often just a matter of time before the inevitable attrition takes its toll.

On the other hand, there’s another way a native population can be effectively destroyed by colonists: marriage. Intermingling between European and American began with the first voyage of Columbus, if not the Viking landings half a millennium earlier. It’s here where those cultural differences can come to the fore. Men taking native wives—even if by force—will have a moderating effect on the persecution of those natives. Some might even abandon their own societies to join those of their spouses, but far more will introduce half-native children into the larger colonial mix. This plays havoc with the casual racism of the period, creating systems of delineation like those in Mexico, but also further blurring the line between the “good” guys and the “bad”.

In the story

For a story set in the age of colonialism, you’ve got plenty of options. Your story could be the founding of a colony, from the first landfall (if not before, looking at the original cause of the migration) to the pivotal event that ensures its survival. With natives added in, that gives you ample opportunity for action, intrigue, and first-contact diplomacy. You can delve into the indigenous culture, possibly through the eyes of a hostage or envoy, or you might turn things around and give the POV of the natives defending their homes from invaders.

The second phase of colonialism, after the initial generation is dead and gone, might be considered the “boom” phase. New settlers are coming in, while existing ones are expanding their families at a high rate. Food and land are in abundance. Here, the tensions between foreign and indigenous are still in play, but then you have the growing class of born-and-raised native sons and daughters. What are their stories? Where do they stand? They may resent the “actual” natives for causing trouble, but equally despise the motherland they’ve never known, who only sees their home as a trading post, a military base, and a source of cheap labor.

If you’re following the American model, it’s not too far to go for the third phase: rebellion. If it’s successful, this is where the colony ends, but colonialism may remain for some time. Most likely, it’ll finally die out with the original rebels or their children, but animosity between “native” and “outsider” won’t go away so easily, even as those labels become less and less meaningful. It may even get worse.

In the end, though, it’s your story. Following the historical trail of cause and effect, however, is a good start towards realism. We know this outcome can happen, because it did. People, even people set in a different world, tend to have the same motivations, the same influences. Barring unforeseen circumstances—magic or aliens, for example—it’s hard to imagine colonialism turning out too differently. It’s human nature.

Let’s make a language, part 21b: Occupations and work (Isian)

Isian, as you’ll recall, is a language whose speakers live in a remote part of our world. They’ve been cut off from modern civilization for a couple of centuries, but they’ve recently been rediscovered. Because of this, they’ve got a lot of native vocabulary to describe work, but some newer concepts require compounds.

In general, work is lodunas, an abstract noun derived from lodu “to work”. But a specific job, career, or occupation goes by bor instead. Most jobs are intended to create (tinte), but some instead destroy (dika), and a select few repair (efri) what is broken.

Workers (lodumi, plural of lodum) can perform many actions, based on their jobs. Some might teach (reshone), others build (oste). Makers of food include bakers (ogami, from oga “to bake”) and simple cooks (pirimi; piri “to cook”). These aren’t the only “domestic” occupations, either. Many Isian speakers, for their jobs, must clean (nolmi), wash (hishi) clothes, sew (seshe), or simply act as servants (dulcami; dulca “to serve”). More important for the town are craftsmen such as totasami (carpenters, literally “wood men”).

Isian is the language of a society that is still very agrarian. Thus, many of its speakers work as farmers (sepami) or just as assistants on a ban “farm”. In cities, however, most working men are instead simple lodumi, day laborers. Women who work are more likely to be reshonemi “teachers” or seshemi—in this context, a better translation might be “seamstresses”.

Finally, the places where people might work can be just as interesting as what they do. Well-to-do Isian speakers might run their own seb “shop” or chedom “inn”. Cooks can work at a restaurant (hamasim, literally “eating house”), though some isimi (“bars” or “pubs”) also serve food. And it remains common for most of the town to gather one day a week at the rishan “market”.

Word List

General terms
  • job: bor
  • poor: umar
  • rich: irdes
  • to borrow: mante
  • to create: tinte
  • to destroy: dika
  • to lend: hente
  • to repair: efri
  • to use: je
  • to work: lodu
  • work: lodunas
Places of work
  • bank: mantalar (from mante + talar)
  • bar (pub): isim
  • farm: ban
  • inn: chedom
  • market: rishan
  • mill: mur
  • restaurant: hamasim (hama “eat” + isim)
  • school: teju
  • shop: seb
Work actions
  • to bake: oga
  • to build: oste
  • to clean: nolmi
  • to cook: piri
  • to dig: daco
  • to drive: foro
  • to fold: efe
  • to grind: harca
  • to guard: holte
  • to hunt: ostani
  • to pour: lu
  • to press: hapa
  • to serve: dulca
  • to sew: seshe
  • to shoot: chaco
  • to sweep: wesa
  • to teach: reshone
  • to tie: ane
  • to wash: hishi
  • to weave: sumbe
  • baker: ogam
  • carpenter: totasam (totac “wood” + sam “man”)
  • cooking: pirinas
  • driver: forom
  • farmer: sepam
  • hunter: ostanim
  • hunting: ostanas (ostani + -nas)
  • janitor: wesam or nolmim
  • laborer: lodum
  • miller: mursam (mur + sam “man”)
  • servant: dulcam
  • tailor: seshem
  • teacher: reshonem
  • teaching: reshonas (reshone + -nas)

Wrapping text by code

Very many games require displaying significant amounts of text on the screen. Whether dialogue, signs, backstory “data log” entries, or lists of quests and objectives, text is absolutely a necessity. And we’re not talking about just a word here and there. No, this is serious text, entire sentences at least. More specifically, I want to look at the long strings of text that are commonly shown in dialog boxes or other GUI/HUD elements, not something that might be baked into a texture.

With single words, it’s not hard at all: you just throw the word on the screen at the right position. What game engine doesn’t let you do that? Even my failed attempt at a simple 2D engine a few years ago could manage that much!

It’s when you need to display longer snippets that things get hairy. Your screen is only so wide, so, like any word processor, you have to know when to wrap the text. Now, many engines do this for you, but you may not be using one of those, or you may be writing your own. So this post is designed to give you an idea of what lies ahead, and to provide a starting point for your own efforts.

Ground rules

First, let’s get this out of the way: I’m using a bit of pseudocode here. Actually, it’s JavaScript, but with a lot of references left undefined. Hopefully, you can convert that into your language and platform of choice.

Next, I’m going to assume you’re working in English or another language that uses an alphabetic script. Something like Chinese or Japanese will have its own rules regarding how long text is broken up, and I don’t entirely understand all of those. The same goes for Arabic and other RTL scripts, but they’re much closer to American and European usage, so some of the concepts described here might carry over.

We’ll also ignore hyphenation in this post. It’s a hideously complex topic, first of all, and nobody can quite agree on which words should (or even can) be hyphenated at the end of a line. Besides, what was the last game you saw that used printed-style hyphenation? In the same vein, we’ll be ignoring non-breaking spaces, dashes, and the like.

The last assumption I’m going to make is that we’re working with Unicode strings. That shouldn’t matter too much, though. We won’t be delving into individual bytes—if you do that with Unicode, you’ve gone wrong somewhere, or you’re at a far lower level this post.


On the screen, our string will be divided into lines. Thus, our job is clear: take a string of text, divide it into lines so that no line is longer than the width of our dialog box. Simple, right? So let’s see how we can go about that.

English text is divided first into sentences. These sentences are then divided into words, sometimes with added punctuation. Each word is separated from its neighbors by blank space. It’s that space that lets us wrap our text.

For a first approximation, let’s take the example of fixed-width text. This was common in older games, and it’s still used for a retro feel. (And programmers demand it for editing code.) It’s “fixed” width because each letter, each bit of punctuation, and each space will have the same width. That width can be different from one font to another, but every character in a fixed-width string, even the blank ones, will be as wide as any other.

As we won’t be worrying about hyphenation, every line will have a whole number of words. Thus, our first task is to get those words out of our string:

// Split a string of text into a list of words
function splitWords(str) {
    return str.split(' ');

Basically, we’ve split our string up into words, and removed the spaces in the process. Don’t worry about that. We’ll put them back in a moment. First, we need to go on a little digression.

Building with boxes

Do you remember magnetic poetry? Those little kits you could buy at the bookstore (back when bookstores were a thing)? They came with a set of pre-printed words and a bunch of magnetic holders. Some of them even let you cut your own magnets, then slide the bits of laminated paper containing words into them. However you did it, you could then assemble the words into a short, tweet-level string that you could stick to your fridge. Longer words required longer magnets, while something like “a” or “I” took up almost no space at all. If you used one of the magnetic poetry kits that came with a little board, you had to do a bit of shuffling—and maybe some editing—to get the words to fit on a line.

That’s what we’re doing here. We’re taking the words of our text, and we’re assembling them on the screen in exactly the same way. Like the board, the screen is only so wide, so it can accommodate only so much. Any more, and we have to move to the next line. So wrapping text can be thought of like this. (It’s also the beginnings of computerized typesetting. We’re not really doing anything different from TeX; it just does the job a whole lot better.)

So we need to pack our words onto lines of no more than a given width. One way to do that is incrementally, by adding words (and spaces between them) until we run out of space, then moving on to the next line.

// Build lines of fixed-width text from a string
function buildTextLines(str, screenWidth, fontWidth) {
    let allWords = splitWords(str);
    let lines = [];

    let currentLine = "";
    let currentLineWidth = 0;
    let currentWord = "";

    while (allWords.length > 0) {
        currentWord = allWords.shift();

        let currentWordWidth = currentWord.length * fontWidth;

        if (currentLineWidth + currentWordWidth > screenWidth) {
            // Too long; wrap text here
            // Save the line we just finished, and start a new one
            currentLine = "";
            currentLineWidth = 0;

        currentLine += currentWord;
        currentLineWidth += currentWord.length * fontWidth

        // Try to insert a space, unless we're at the edge of the box
        // (width of space is the same as anything else)
        if (!(currentLineWidth + fontWidth > screenWidth)) {
            currentLine += " ";
            currentLineWidth += fontWidth;

    return lines;

For fixed width, that’s really all you have to do. You can still treat the text as a sequence of characters that you’re transforming into lines full of space-delimited words. As a bonus, punctuation carries over effortlessly.

Varying the width

The real fun begins when you add in variable width. In printed text, an “m” is bigger than an “n”, which is wider than an “i”. Spaces tend to be fairly narrow, but they can also stretch. That’s how justified text works: extra bits of space are added here and there, where you likely wouldn’t even notice them, so that the far ends of the lines don’t look “ragged”. (That, by the way, is a technical term.) Two words might have an extra pixel or two of space, just to round out the line.

Doing that with simple strings is impossible, because I don’t know of any programming language having a basic string type that accounts for proportional fonts. (Well, TeX does, because that’s its job. That’s beside the point.) So we have to leave the world of strings and move onward. To display variable-width text, we have to start looking at baking it into screen images.

Since every engine and renderer is different, it’s a lot harder to give a code example for this one. Instead, I’ll lay out the steps you’ll need to take to make this “box” model work. (Note that this phrase wasn’t chosen by accident. HTML layout using CSS, as in a browser, uses a similar box-based display technique.)

  1. Using whatever capabilities for font metrics you have, find the minimum width of a space. This will probably be the width of the space character (0x20).

  2. Using this as a guide, break the text into lines—again based on the font metrics—but keep the words for each line in a list. Don’t combine them into a string just yet. Or at all, for that matter.

  3. For each line, calculate how much “stretch” space you’ll need to fill out the width. This will be the extra space left over after adding each word and the minimum-width spaces between them.

  4. Divide the stretch space equally among the inter-word spaces. This is aesthetically pleasing, and it ensures that you’ll have fully justified text.

  5. Render each word into the sprite or object you’re using as a container, putting these stretched spaces between them. You can do this a line at a time or all at once, but the first option may work better for text that can be scrolled.

In effect, this is a programmatic version of the “magnetic poetry” concept, and it’s not too much different from how browsers and typesetting engines actually work. Of course, they are much more sophisticated. So are many game engines. Those designed and intended for displaying text will have much of this work done for you. If you like reading code, dive into something like RenPy.

I hope this brief look whets your appetite. Text-based or text-heavy games require a bit more work for both the developer and the player, but they can be rewarding on a level a fully voiced game could never reach. They are, in a sense, like reading a story, but with a bit of extra visual aid. And games are primarily a visual medium.

Magic and tech: economy

One of the biggest topics of the last decade has been the economy. We’re finally climbing out of the hole the banks dug for us in 2008, and it’s been long enough that most people have taken notice. Employment, income, wages, and benefits are important. So are less obvious subjects like inflation, debt and credit, or mortgages. Even esoteric phrases like “quantitative easing” make the news.

The economy isn’t a modern invention, however. It’s always been there, mostly in the background. From the first trade of goods, from the first hiring of another person to perform a service, the economy has never truly gone away. If anything, it’s only becoming bigger, both in terms of absolute wealth—the average American is “richer” than any medieval king, by some measures, and today’s billionaires would make even Croesus jealous—and sheer scope.

How would magic affect this integral part of our civilization? The answer depends on the boundaries we set for that magic, as we shall see.


Our economy, whether past, present, or foreseeable future, is based on the concept of scarcity. For the vast majority of human history, it was only possible to have one of something. One specific piece of gold, one individual horse, one of a particular acre of land or anything else you can think of. You could have more than one “instance” of each type—a man could own twenty horses, for example—but each individual “thing” was unique. (Today, we can easily spot the friction caused when this notion of scarcity meets the reality of lossless digital copying, the lashing out by those who depend on that scarcity and see it slipping away.)

Some of those things were rarer than others. Gold isn’t very common; gems can be rarer still. Common goods were relatively cheap, while the rare stuff tended to be expensive. And that remains true today. Look at any “limited edition”. They might have nothing more than a little gold-colored trim or an extra logo, but they’ll command double the price, if not more.

Supply and demand

All that only applies to something people want. It’s a natural tendency for rare, desirable goods to climb in value, while those things that become increasingly common tend to also become increasingly worthless. This is the basis of supply and demand. If there’s more of something than is needed, then prices go down; if there’s a shortage relative to demand, then they go up.

Although it’s a fairly modern statement, the concept is a truism throughout history. It’s not just a fundamental idea of capitalism. It’s more a natural function of a “scarcity economy”. And you can apply it to just about anything, assuming all else is equal. A shortage of laborers (say, due to a plague) pushes wages higher, because demand outstrips supply. That’s one of the ultimate killers of feudalism in the Middle Ages, in fact. Its converse—a glut of supply—is the reason why gas prices have been so low in America the past year or so.


Another thing you have to understand about the economy is that it’s all connected. Today, that’s true more than ever; it’s the reason we can talk about globalism, whether we consider it a bringer of utopia or the cause of all the world’s ills. For less advanced societies, the connectivity merely shrinks in scale. There was, for example, no economic connection between Europe and the Americas until the fifteenth century, apart from whatever the Vikings were up to circa 1000. The Black Death had no effect on the economy of the Inca, nor did the collapse of the great Mayan cities cause a recession in Rome. Similarly, Australia was mostly cut off from the “global” economy until shortly before 1800.

Everything else, though, was intertwined. The Silk Road connected Europe and Asia. Arab traders visited Africa for centuries before the Portuguese showed up. Constantinople, later Istanbul, stayed alive because of its position as an economic hub. And like the “contagious” recessions of modern times, one bad event in an important place could reverberate through the known world. A bad crop, a blizzard blocking overland passes, protracted warfare…anything happening somewhere would be felt elsewhere. This was the case despite most people living a very localized lifestyle.

Making magic

In role-playing games, whether video games or the pen-and-paper type, some players make it their mission to break the economy. They find some loophole, such as an easily creatable magic item that sells for far more than its component cost, and the exploit that to make themselves filthy rich. It happens in real life, too, but government tends to be better at regulating such matters than any GM. (The connection between these two acts might make for an interesting study, come to think of it.)

We’re trying for something more general, though, so we don’t have to worry about something as fine-grained as the price of goods. Instead, we can look at the big picture of how an economy can function in the presence of magic. As it turns out, that is very dependent on the type of magic you have at your disposal.

First, let’s assume for a moment that wizards can create things out of thin air. Also, let’s say that it’s not too difficult to do, and it doesn’t require much in the way of training or raw materials. Five minutes of chanting and meditating, and voila! A sword falls at your feet! Something more complex might take more time, and living things can’t be created at all, but crafted goods are almost as easy as a Star Trek replicator.

Well, that destroys any economy based on scarcity. It’s the same problem media companies have with computers: if something can be copied ad infinitum, with no loss in quality, then its unit value quickly drops to zero. Replicating or creating magic, if it’s reasonably widespread, would be like giving everyone a free 3D printer, a full library of shape files, and an unlimited supply of feedstock. Except it’d be even better than that. Need a new sword/axe/carriage/house? Call up the local mage. No materials needed; you’re only paying for his time, the same as what would happen to books, music, and movies without licensing fees and DRM.

So that’s definitely a “broken” economy. Even a single user of such magic breaks things, as he can simply clone the most expensive or valuable items he knows, selling them whenever he needs the cash. Sure, their value will eventually start to drop—supply and demand in action—but he’ll be set for life long before he gets to that point.

It’s the economy, stupid

For our magical kingdom, let’s look at something more low-key. It doesn’t have creation magic. Instead, we have at our disposal a large amount of “automating” magic, as we’ve seen in previous parts. What effect would that have on the economy? Probably the same effect increasing automation has in our real world.

Until very recently, most work was done by hand, occasionally with help from machines that were powered by people, animals, or natural forces. The Industrial Revolution, though, changed all that. Now, thanks to the power of steam (and, later, electricity), machines could do more and more of the work, lightening the load for the actual workers. Fast-forward to today, where some studies claim as many as 40% of jobs can be done entirely automatically. (For labor, we’re actually getting fairly close to “post-scarcity” in many fields, and you can see the strain that’s beginning to cause.)

Magical force and power can easily replace steam and electricity in the above paragraph. The end result won’t change. Thus, as magic becomes more and more important in our fictional realm, its effects stretch to more and more areas of the economy. As discussed in the post about power, this is transforming the workforce. Unskilled labor is less necessary, which means it has a lower demand. Lower demand, without a corresponding decrease in supply, results in lower wages, fewer working hours, fewer jobs overall. We know how that turns out. The whole sordid story can be found in all sorts of novels set in Victorian England or Reconstruction America—Charles Dickens is a good start. Or you can look at modern examples like Detroit or Flint, Michigan, or any steel town of the Midwest.

There is an upside, though. After this initial shock, the economy will adjust. We see that today, as those displaced in their jobs by robots have begun branching out into new careers. Thus, it’s easy to imagine a magical society embracing the “gig economy” we’re seeing in Silicon Valley and other upscale regions, except they’d do it far earlier. You could even posit a planned socialist economy, if the magic works out.

But mages are human, too. They’re subject to need and greed the same as the rest of us. So they might instead become the billionaires of the world. Imagine, for instance, wizards as robber barons, hoarding their techno-magic to use as a lever to extract concessions from their rivals. Or they could simply sell their secrets to the highest bidder, creating something not much different from modern capitalism. If magic has a distinct military bent, then they could become the equivalent of defense contractors. The possibilities are endless. All you have to do is follow the chain of cause and effect.

The economy is huge. It’s probably beyond a single author to create something entirely realistic. But making something that passes the sniff test isn’t that hard. All you have to do is think about why things are the way they are, and how they would change based on the parameters you set. Oh, and you might want to find one of those munchkin-type players who likes to find loopholes; for the economic side, they’re more useful than any editor.

Let’s make a language, part 21a: Occupations and work (Intro)

We all have a job to do, whether it’s an actual career or simply the odd jobs we do around the house. Work is as old as humanity, so it’s not surprising that it is a very important part of a language’s vocabulary. For a conlang, it should be no different.

Working on work

Work is, at its core, about action, about doing things. Thus, many of the words regarding work will be verbs, and many others will likely be derived from those verbs in some way. To be sure, there will be nouns and adjectives that aren’t, but derivation gives us a powerful tool to create new words, and work is a great example of a field where derivation really shines.

Think about “working” verbs. We can cook and clean and teach, among hundreds of others. And when we do those things, in English, we become cooks, cleaners, and teachers. Two out of the three of these use the agent derivation -er, and that pattern is repeated throughout the language: agents are nouns that perform an action, so agents of working verbs naturally represent the “workers”. (Cook is an exception, but not much of one. Ever heard of a cooker? That’s not what you call the occupation in English, but another language could do things differently.) If your conlang has an agent marker, then creating occupational nouns is probably going to be easy and regular. Of course, there can be exceptions, especially once loanwords come into play, e.g., chef.

Another easy derivation takes us to abstract nouns representing the occupation itself. In English, this comes in the gerund form: “working”, “teaching”, etc. Other languages might have their own special cases, though. Note that this is not the same as the adjective form seen in phrases like “a working man”. That one is a different, yet equally simple, derivation; a language can use the same pattern for both, or it can separate them.

If your language has a gender distinction in nouns, then things might become a little more complicated. English has a few cases like these (actor/actress), but political correctness is starting to erase some of these distinctions. Romance languages, by contrast, have a larger, more stable, set of gendered agents. Now, a conlang with gender doesn’t have to have separate occupational terms for masculine and feminine, but it’s an obvious step that many natural languages have taken.

Which work is which?

The breadth of work words is another one of those cultural things that you have to take into account. A primitive society set in Bronze Age Europe isn’t going to have words for “computer” (originally, this was “one who computers”, a word for a person) or “investor”, because such concepts won’t exist. Similarly, a lost Amazon tribe might not have native words for “ironworking” and “blacksmith”, as those would be foreign concepts.

As with plants and animals, “foreign” work will often be spoken of in foreign terms, i.e., loanwords. This isn’t always the case, however. It’s entirely plausible that a language’s speakers will invent new terms for these new jobs. If they’re smart enough, they may even try to translate the meaning of the foreign root. Even if they do borrow the root, they may not import the agent marker with it. Instead, the borrowing can create a whole new paradigm: work verb, occupational agent, abstract occupational noun, and so on.


For naturalistic conlangs, regularity is anathema. With the field of work, there’s ample opportunity to introduce irregularities. The agent derivation doesn’t always have to work, for example—we’ve already seen English cook. Old verbs might be lost, leaving nouns (like carpenter) that don’t seem to fit anymore. Different derivations can be used on different roots, too; we speak of carpentry but also woodworking. And then there’s the oddity of English employee, one of the few instances where the language has a patient derivation to go along with the agent. (The full paradigm of “employ” shows exactly what we’re talking about, in fact. You’ve got the basic agent “employer”, the not-quite-irregular patient noun “employee”, and the abstract “employment”, which doesn’t use the usual participle form. Irregularity all around.)

Next up

In the next two posts, we’ll get a look at some Isian and Ardari working words. Over 50 of them, if you can believe that. Then, the future becomes murkier. We’re nearing the end of another year, so stay tuned for a special announcement regarding upcoming parts of the series.

RPG Town: layout

I love the retro look in games, that 16-bit pixel-art style that has, thankfully, become common once again in indie titles. A Link to the Past is my favorite Zelda game, and I’ve been playing Stardew Valley far too long over the past few months. Maybe it’s the nostalgia talking, but I truly enjoy this style.

One of the main draws of retro graphics is the way an area can be laid out using a tilemap. There are far too many tilemap tutorials out there, and this won’t be one of them. Instead, I’d just like to share a little thing I started recently. I call it RPG Town.

The town

RPG Town is a little village that would be at home in any RPG, action-adventure, or roguelike game that uses a 16-bit graphical style. It’s definitely a pixel-art place, and I’m using a free sprite set I found linked on the excellent to visualize it.

The backstory, such as it is, is deliberately vague. RPG Town can be a home base for a player character, or a little stop along the way, or just anything. It’s home to a couple dozen people, and it’s got that typical over-urbanism common to video game settlements. No real farms here, but you can imagine they’re right off the map. It’s also a coastal place, situated on the mouth of a small river. Thus, fishing is likely a big deal there. There’s an offshore island not too far away; it’s claimed by RPG Town, but the people don’t really use it for much. (Maybe it holds the ruins of a lighthouse, or something more sinister.) Other than that, it’s just your average, quaint little town, set amid fertile plains and dense woodlands, ready for an adventure to come its way.

The making of

Really, RPG Town is an excuse for me to play with Tiled. I’ve never used it for much, but I want to. It’s a wonderful program, great for creating tilemaps of any kind, but especially those for retro-style games. Plus, it’s free, and it runs everywhere, so you don’t have to worry about any of that. Get it. It’s more than worth your time.

Anyway, after starting a new map and setting up the tile set I’m using. My first step was to configure the terrain. The Tiled manual talks about doing this; it’s a huge help, if your tile set is made for it.

Once I had the preliminaries out of the way, it was time to start making a map. So that’s what I did. First, I filled my whole canvas (128×64, by the way, with the tiles 16 pixels square) with a plain grass tile, then “carved out” the water areas. I had already decided RPG Town’s location, so all I had to do was draw the water. Tiled took care of the tile transitions seamlessly, and I ended up with this:


Tilemaps are best built in layers, from the base (the terrain) up to the more complex parts like houses or signs. Following that philosophy, next come the roads. RPG Town isn’t a big port, but it’s a port, so it’s only natural that it would be a stopping point for a road or two. Those I made as wide cobblestone paths, meeting in the middle in a tiny town square. There are also a few branching side streets, and some stuff that won’t quite make sense yet. Oh, and I added a spot of sandy beach, because who doesn’t like that?


Now that I know where all the roads are running to, it’s time to give the people of RPG Town some places to live and work. I’m not ready to actually plop down buildings yet, so I’ve limited myself at this early stage to simply staking them out. On this last picture, you can see the outlines of where buildings would go. Later on, I’ll build them, but this is enough for now.


To be continued?

I’ll keep playing with RPG Town in my spare time. If I do anything interesting with it, I’ll post about it. One day, there might even be a few virtual people living there.