gamedev – Prose Poetry Code

Fork in the road

The past week or so has been an eventful one in the game development world. Unity is still backpedaling on their disastrous attempt at charging devs per-sale. The CCP-infested Unreal Engine has lowered its royalty fee. Ubisoft is teaching us all how best to set half a billion dollars on fire.

And then there’s Godot.

I’ve written about Godot Engine in the past. It first came out about 10 years ago, and it took the opensource world by storm. Here was a pro-level—okay, semi-pro back then—game engine that was free to use, without worrying that Unity would demand payment when you only ever opened the editor twice. (This actually happened to my brother.) Over the past decade, it grew, evolved, becoming the premier engine for budding developers on a budget.

All that changed a few days ago. "Get woke, go broke," the saying goes, and Godot’s management has chosen to go for broke. A far-left "community manager" proudly boasted on Twitter that this engine was perfectly fine being on an admittedly overzealous list of woke games. Fine. Sure. Find me a AAA studio that isn’t utterly broken to the mind virus, and I’ll gladly buy their games. Well, except I can’t actually buy their games; they won’t sell them to me. (California got one right this time, amazingly enough.)

Most people probably ignored the initial message, seeing it as just another fluorescent-haired professional victim parroting the latest narrative. And that’s probably how it was originally intended. But then came the doubling down. People who questioned the intent of the message started getting banned. Developers were kicked out. Backers were kicked out. The project head first claimed to be apolitical, then whined about being bullied off Twitter altogether, retreating to the safe space of leftist Mastodon. At every turn, those who objected to, disputed, or simply asked about Godot’s underlying political agenda were purged.

The great thing about open source is that this doesn’t mean the end. Because anyone can take the source, compile it, and release the resulting binaries, an open project can’t be shut down by progressive whim; this is most likely why so many are switching to "open core" models or demanding copyright assignments.

End result, though, is Redot Engine. Yes, the name’s derivative, but that’s to be expected. The whole thing is derivative, but in the positive sense that only free code under a permissive license allows. Redot hasn’t even released a build yet, and they’re already overwhelmed with support, so much so that Godot’s screeching gallery has started openly attacking it. They use the usual communist methods, so familiar from Antifa, BLM, and anything to do with Trump: projection, accusations of white supremacist beliefs, attempts to clog the system with garbage, and vague allusions of unseemly images stored on the "bad guys’" computers.

All this, because someone said, "No, I don’t want my game engine to have a political agenda."

Nor should it. Tools should be apolitical, because a tool, in and of itself, is amoral. It does not think or act on its own. It simply exists. The uses of a tool are in no way indicative of any inherent moral qualities of that tool. Nuclear bombs were once considered a viable means of digging canals, after all. And even if we accept the idea that a tool can espouse an ideology, why would we want one that’s communist? Why would we want to support the single most deadly ideology in all of human history? The one responsible for the Holodomor and the One Child Policy, the one that gave the world Stalin and Mao and Castro and Chavez?

Redot, as I see it, can be a chance to show that some people are still fighting against the encroachment of anti-human ideology in software. That gives me hope, because I’ve often felt I was fighting that battle alone, as I watched project after project adopt censorious codes of conduct or otherwise wall themselves off from rational discourse.

It’s not perfect yet, so my other hope is that the Redot team understands two things. One, something founded purely on a negative basis—that is, solely to be against another—cannot endure. This was the downfall of Voat and Threads, among many others

Second, if Redot wants to be inclusive in the true, non-bowdlerized meaning of the word, then it must be open. As yet, it is not. All discussion and development is currently hosted only in walled gardens: Discord, Github, Twitter, Youtube. There isn’t any way for a privacy-conscious developer/author to contribute, and I won’t compromise my own morals by supporting the very platforms which have spread the woke mind virus to software development in the first place.

So that’s where we stand right now. Godot has self-immolated, and I have no problem saying they deserve it. Redot is carrying the torch, but they need to prove that their words are not just wind. If they do, then we will have not only a great game engine for free, but a beacon of light in an otherwise dark time.

Crux Eternal

I’ve finally done it. I’ve made a game.

Okay, okay. It’s just a demo for now, but it’s complete in that regard. It’s called Crux Eternal (the name is an inside joke, I’ll admit) and it’s a simple puzzle game based on the “Kakuro” or “Cross Sums” puzzles I’ve worked since I was a kid. They’re a bit like Sudoku mixed with a crossword, and they can be surprisingly difficult.

This demo version includes 15 puzzle configurations, all in the smallest size that made sense to me. There’s a timer, and the game does track your best times for each configuration. Puzzles are randomly generated to fit the pattern, so there’s some replayability, as well.

I’d certainly love to flesh out Crux Eternal into a full-fledged game. This was the first time I’d brought a Godot project (or any gamedev project, for that matter) from inception to completion, and I’d like to keep it going. I also have a few other game ideas rattling around in my head, though, so maybe I’ll work on them instead.

Anyway, you can play Crux Eternal online in your browser, or you can download local versions for Linux and Windows. The source is available over on my Gitlab, and it’s MIT-licensed.

Window of opportunity

One of the biggest problems with the world today is propaganda. And one of the biggest sources of propaganda is media. Of course, that’s something which has happened pretty much forever, but the scale of it is so much greater today. Movies push communist and other anti-human agendas. TV shows parrot progressive talking points without a hint of irony. Video games give our virtual characters a choice not between male and female—the only two biological sexes for humans—but between "Body Type A" and "Body Type B", yet never explain why only the first is allowed to be topless.

It only goes downhill from there. Rap is essentially the only genre of music that is advertised nowadays (with the minor exception of anti-American "country" pop music), while also being the only one to have no recognizable evolution in a generation. Sports leagues spent the summer of 2020 showcasing their support for a terrorist organization, and continue to promote child predators and genital mutilation. The list goes on, but you get the idea.

There’s a growing pushback among viewers, listeners, and players. Starfield’s launch was disastrous, and the game was rightly criticized by gamers for not only its antiquated graphics, but also its unrealistic demographics. The NBA is seeing its lowest TV ratings in decades. Disney is churning out bomb after bomb at the box office. And even mediocre musicians like Jason Aldean and Oliver Anthony are hitting the top of the charts solely because they’re willing to take a stand against the narrative.

Of course, the problem lies in the gatekeepers of media. Hollywood isn’t going to stop putting out woke garbage until Blackrock goes under, which isn’t happening anytime soon. AAA studios don’t care how poor the reviews are for their newest recycled PS3 franchise, because they know the games themselves are loss leaders at this point. And major sports literally have government protection for their monopolies.

Thus, we have to turn to the indie scene in every case. That’s where the innovation is. That’s where the pro-American, pro-Enlightenment, and pro-human media can be found. Indie authors are writing stories that lift us up and let us escape, instead of the same dreary racial metaphors. Indie musicians are creating tracks in every genre that bring to life the emotion that music should make us feel. Indie video games, even when they’re based on a timeless formula, show off new tricks of gameplay while also telling compelling stories.

It’s only going to get better.

The new hotness these days is AI. And that’s also the current target for the powers that be. Big business and established interests hate AI because of the potential it has. Ignore the complaints about copyright and consent. Those are red herrings. The real fear of generative AI is that it will give us a chance to create media without having to go through them. For instance, that’s why Steam, never a fan of freedom in the first place, is banning indie games which use AI content.

If a dev can use AI to cut out the time needed to hire artists, voice actors, and so on, that means so many more indie games will get past the demo and alpha stages. If an author uses an AI tool to generate story seeds or mines an LLM for dialogue inspiration, he might just finish that novel he’s been working on for years. And the tools are only getting better with each new release. Soon, much more of the media pipeline will be accessible to those of us without the means to break into the industry. Low-budget films used to be a laughingstock. In a few years, they might be indistinguishable from a Hollywood blockbuster. (Well, not exactly. You’ll be able to spot the indie movie because it’s the one with a straight white man as the protagonist.)

It’s been over seven years since I wrote Democratization of development. In that post, I argued that game development was reaching a golden age because of the availability of high-quality tools at a price affordable to the average person. That’s even more true in 2023 than it was in 2016, even if Unity has decided it no longer wants an audience. And you know what? Almost all the games I play now are indies. (The only exceptions are Nintendo’s licensed titles, which you can’t play on PC anyway.)

Let’s get other kinds of entertainment to that same level. With the free tools available now or in the near future, it’s a no-brainer. Blender, Godot, Synfig, GIMP, Inkscape, LMMS…these are only the ones I’ve used. Not one of them costs a single dollar. So the software is there. AI will add the assets for those of us without artistic talent.

Elephant in the room

That only leaves one last thing: distribution. It’s the hardest aspect, and it’s the one that doesn’t have a good solution. Patreon is a far-left wasteland little better than OnlyFans. Steam is owned by a company that uses practices deemed illegal in at least 3 countries. Crypto just isn’t the silver bullet its proponents wish it was.

This is where we, as indie creators, need to step up and let our voices be heard. Rich conservatives talk a big game about creating alternatives to woke business, but they never follow through on their promises. Rumble, for example, calls itself a haven for free speech, yet still bans many of those who seek to exercise it. And there just aren’t any right-wing or libertarian distributors out there—whether for movies, music, books, or video games—willing to seek out the indies who are desperate for a platform that respects them.

We have a moment, however. The backlash against progressivism is growing. Hollywood is crippled by its unions, and the video game industry may follow in its footsteps. Big Media is burning through cash at an unprecedented rate, and its outright hostility to its core customer base is keeping it from replenishing its coffers. If anyone with the means would take that next step, that pivotal step of reaching out to us indies and saying, "We’ll work for you," then democratization would get the boost that might just launch us ahead of the soulless corporate entertainment empire.

We’re ready. We’re waiting.

2023 Projects

I’m constantly dreaming up new ideas for side gigs and hobby projects. Anyone who read my posts before April 2021 knows that all too well. Lately, as my current job has begun to wind down and my relationship seems to be nearing a plateau, my brain has decided to kick back into high gear on this front. So here are some of the things I’m thinking about with my spare mental cycles. Some of them I’ll get to eventually. Some I’m already planning out. A few will likely never see the light of day.

Borealic

I haven’t done much with conlangs in the past couple of years. A few months back, I had another aborted start on an "engineered" language, this one based on a ternary number system. (The idea was to make something philosophical but also easily representable without words. I’m weird.)

Now, I’m doing serious work on what is my first real attempt at an auxiliary language. There are plenty of auxlangs already out there, of course: Esperanto, Lojban, and so on. Mine is slightly different, however. Instead of drawing on Latin as the primary source of vocabulary—or being some sort of amalgam of the world’s major languages—I’m developing a conlang intended as a pan-Germanic interlingua.

The core vocabulary is derived from actual Proto-Germanic roots, most of which are shared by at least two of the six major Germanic languages spoken today. Those are English, German, Dutch, Danish, Norwegian, and Swedish, for those of you keeping score at home. Icelandic, Frisian, and the other "minor" Germanic tongues also get their due, mostly as additional confirmation of a meaning that has drifted over the past 2500 years or so. (Gothic has been extinct basically forever, so I exclude it from consideration.)

In terms of grammar, "Borealic" (the external name; it calls itself "Altidisk") mostly follows the general pattern of West Germanic and North Germanic languages. Where these differ, I look for common ground, and I try going back to a common ancestor for inspiration. The basic word order, for example, is V2: verbs always try to fill the second slot in a sentence if possible. That’s a common theme throughout the Germanic world. So is a two-way tense distinction between past and non-past, with the future tense instead being indicated by an auxiliary verb.

My goal isn’t necessarily to create a conlang for everybody to use. No, this one is explicitly intended for purposes best described as nationalistic. Borealic is for the Germanic peoples of the world. It’s a way to connect with our shared culture, a culture that is increasingly under attack these days.

Borealic is what I’m working on as I write this post, so it’s the one I’ll probably be sharing soonest.

Word games

I still want to be a game developer, and I’m still working towards that goal. I have two concepts I’ve been fleshing out in my head, and I’m getting ready to start making something more concrete out of them.

First is "Fourwords". At its core, this is going to be a simple little fill-in word puzzle. Instead of a crossword, however, you get a chain of four different words. The last letter of one word is the first letter of the next, and all the words in a chain are connected by a theme which the player will see while working the puzzle. You get points based on the length of each word (they aren’t fixed, but are variable between 4-12 letters) and the perceived difficulty of the chain: more generic categories are considered harder, as are those for very specific niches.

I envision Fourwords as a mobile-first game. In other words (no pun intended), there will be sets of puzzles that unlock as the player progresses. I’ll have plenty of gamification elements thrown in there, and—as much as I hate it—probably some kind of builtin ad or IAP support. I’ll build it using the new 4.x version of the Godot Engine, which will be my first real foray into its new features. I imagine also needing a server to store player data and all that. Lucky for me, my "real" job requires me to learn AWS.

The second word game is much simpler, yet also much more complex. This one doesn’t have a name yet, and it’s little more than a Wordle clone at heart. It’s a Mastermind-like game using words of five or six letters; I haven’t decided which would work best. You have a secret word, and you have to try to guess what it is. If you’re right, you win! If you’re wrong, you get to see which letters are correct, and which ones are in the wrong places. Scoring is based on how many guesses you make and how long it takes you to get to the right word.

Since there are only so many words in the English language, this one necessarily has a well-defined endpoint. But I figure I can add in a timed mode with randomization to keep things a little fresh. Beyond that, the format doesn’t have much else going for it.

But here’s the kicker. This one isn’t going to come out on mobile. It’s not going to be on desktop, either. No, I want to make this game for a console. And not just any console, but a retro one. I must be getting crazy in my old age, because I am seriously considering making a game for the NES. That means 6502 assembly, low-res tile graphics, music that is more code than notes, and all those arcane incantations that game devs used to do. It’ll be a monumental undertaking, but what if I can pull it off?

Adventure

I’ve started writing again in recent weeks. Time is short, but I’ve been able to find an hour here and there to get back to On the Stellar Sea. Those poor kids have had to stay on that planet too long!

Writing on Orphans of the Stars has made me want to go back to the project I had originally imagined would accompany it. This one is almost another game dev project, but of a different sort. The Anitra Incident is technically a prequel to the novel series, but it’s one I plan to write as interactive fiction. In other words, you are the protagonist. The setting is about 200 years in the future, when humanity’s lunar and Mars colonies are up and running, and we now turn our eyes outward. A strange Main Belt asteroid catches our eye, and a manned mission is sent to explore it. What they—you—find will shock everyone.

That’s the gist of it. It’s kind of a CYOA game, kind of an exercise in descriptive writing, and hopefully a lot of fun. And the books have already referenced this particular era of the setting’s history, so part of me feels I have to write it. I’ll need to relearn Sugarcube, I suppose. Graphics should be a lot easier now, thanks to Stable Diffusion. I may even be able to do character portraits, something I never imagined I would be capable of. (That’s no joke. I’ve had great success generating portraits of some of the Innocence kids, and they make good writing references.)

Never enough

There are plenty of other things my brain has decided to focus on. Pixeme, my community-based language learning web platform idea, is starting to take shape. Concerto is another one I want to play around with some more; it’s a microkernel OS written in Nim, a language I’ve found that I really enjoy. Another one I just named yesterday is Stave: the goal with this one is to create a long-term stable virtual machine. As in really long term. I want to make a VM that will stand the test of time.

But I’ll get to that later. Right now, there’s so much to do, and nowhere near enough time to do it all.

New adventures in Godot

As I’ve said many times before, I think Godot Engine is one of the best options out there for indie game devs, especially those working on a budget in their spare time. Since I don’t have all that much spare time (rather, I have more than I know what to do with), I thought I’d put my money where my mouth is and try to make a game.

I know it’s not easy. It’s not simple. That doesn’t mean I won’t give it a shot. And I’ll be sure to keep you updated as to my progress.

What I’ve got so far is an idea for a casual word-find game. Think a cross between Tetris and Boggle. You’ve got a playfield of letters, and the object is to select a series of them that spells out a word. You get points based on the length of the word and the letters you use (rarer letters like J or Z are worth more than the common E or R). Then, the letters you chose disappear, and others fill the space.

That’s where I’m at now: getting the field set up. Then, I’ll work on the rest of the basic game mechanics, from selection to scoring. UI comes after that, and games need sound effects, animations, etc. Eventually, I’d like to produce a mobile and desktop version for you to download here or elsewhere. (Still weighing my options on that.)

Don’t expect too much, but if I can get this done, I hope to move on to more ambitious projects. Although I do focus far more on writing these days, I still love coding, and game programming remains one of my favorite aspects. Godot makes that part easy, and it does it without all the cruft of Unity or Unreal. It really hits the sweet spot, at least as far as I’m concerned.

On Godot 3.0

For a couple of years now, I’ve been talking about the amazing Godot Engine. Recently, I’ve been writing so much that I haven’t had time to get back into coding, but the announcement of Godot Engine version 3.0 got my attention. Now, I’ve had some time to play with it, and here’s my verdict.

First off, Godot is free. It’s open source. It’s cross-platform, for both development and deployment. All three of those are important to me. I’m poor, so an engine that costs hundreds or thousands of dollars just to get started is, well, a non-starter. Second, my desktop runs Linux, so a Windows-only tool is probably going to be useless, and something proprietary really isn’t good when you have the very real possibility of having to delve into the bowels of the engine for customization purposes.

Yes, something like Unity is probably better for someone who’s just starting out. It’s got a bigger community, it’s more mature, and it does have a much more professional air. On the other hand, Godot’s new version really ups the bar, putting it on the same general level as other “indie-friendly” game engines.

New and improved

The biggest new feature in Godot 3.0 has to be the improved 3D renderer. 3D was always Godot’s weak point, especially on certain hardware. Namely, mine. Last year, I was running on integrated graphics (A10 Trinity, if you care), and I got maybe 5 FPS on Godot’s platformer demo. Fast-forward to January 1st, 2018, after I installed a new (to me) RX 460 running the fancy amdgpu drivers and everything. Curious, I fired up Godot 2.1 and the demo. Results? 5 FPS max. No difference.

With 3.0, though, that’s no longer a problem. From what I’ve read, that’s because the developers have completely overhauled the 3D portion of the engine. It’s faster on low-end (and medium-level) hardware, and some of the sample images are stunning. I’d have to do more tests to see just how well it works in practice, but it could hardly be worse than before.

In a way, that perfectly describes all the new features. The renderer’s been rewritten to be better. Physics now uses the Bullet engine instead of a homebrew system. Audio? Rewrite. Shaders? Rewrite. It’s not so much revolution as evolution, except that doesn’t work. No, think of it more as evolution by revolution. Now, that’s not to say there are no new features in this version. It’s just that those are overshadowed by the massive improvements in the existing parts.

I’ll gladly admit that I don’t care much about VR gaming. I’m not one of those who see it as a gimmick, but it’s not ready for primetime yet. But if you’re of a different persuasion, then you might be interested in the VR support that’s been added. I’ll leave that to you to discover, as I honestly have no idea how it all works.

More to my taste is the additional programming support. Godot uses a custom scripting language by default, a Python clone designed to interface with the engine. I’m not really a fan of that approach, as I’ve written before. Clearly, I’m not alone in that thinking, as version 3.0 now offers more options. First up is GDNative, way to extend the engine using external libraries (written in native code, hence the name) without going through the trouble of recompiling the whole thing every time you make a change. That one looks good on its face, as it opens up the possibility of integrating popular and well-tested libraries much more easily.

But that doesn’t really replace GDScript, although it does add the ability to make bindings for other scripting languages. The new Mono support, on the other hand, actually does change the way you write code. It’s not perfect (as of this writing, it’s not even complete!), but it definitely shows promise.

As you know, Unity uses C# as its language of choice; they’ve deprecated JavaScript, and they try to pretend Boo never existed. Well, now (or once it’s done) Godot will let you write your game in C#, too. Even better, it surpasses Unity by using a much newer version of Mono, so you get full C# 7.0 support, assuming you trust Microsoft enough to use it.

If that wasn’t enough, there’s also a “visual” scripting system, much like Unreal’s Blueprints. That one’s in its early stages, so it’s not much more than a flowchart where you don’t have to write the function names, but I can’t see it not getting improved in future versions.

So there you have it. I haven’t even scratched the surface here, but I hope it whets your appetite, because I still think Godot is one of the best indie game engines out there. If you don’t have the money to spend on Unity, you’d rather use a platform without a port of the Unreal editor, or you don’t want to risk getting sued by Crytek, then there’s almost no reason not to give Godot a shot. It’s only getting better, and this new version proves it.

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

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

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.

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.

Words

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
            lines.push(currentLine);
            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.)

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).
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.
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.
Divide the stretch space equally among the inter-word spaces. This is aesthetically pleasing, and it ensures that you’ll have fully justified text.
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.

Godot Engine 2.1

So a new version of one of my favorite game engines came out recently, and I’m just now taking a look at it. (Actually, I’m writing this on the 11th.) If you’ll recall from a couple of months ago, I tried making a game in Godot 2.0, but I couldn’t continue due to an illness. Now, with a new version out, I think I might try again soon. But first, let’s look at what’s in store, and let’s see if Godot is still worthy of the title of Best Free Game Engine.

Asset sharing

Unity’s absolute best feature is the Asset Store. There’s no question about that. It’s got everything you need, and it’s almost possible to make a game just by downloading graphics, sound effects, and pre-written code from there. And other engines (Unreal, etc.) are starting to jump on the same bandwagon.

With version 2.1, Godot can now say it’s joining the ranks. There’s a new Asset Library accessible within the editor, and it’ll eventually work the same as any other. Right now, it’s pretty bare, but I have no doubt it’ll grow as time goes on.

Better plugins

Godot’s editor has a lot of features, but it doesn’t do everything. Developers have always been able to add functionality with plugins (mainly through using the tool keyword in Godot scripts), but 2.1 brings a whole new EditorPlugin API, meaning that these tools can integrate better with the rest of the editor. They can also work with the Asset Library.

The API, like the Asset Library, is a work in progress, so it doesn’t have all the features yet. But give it time.

Editor improvements

If you don’t speak English, Godot 2.1 helps by supporting full internationalization of the interface. Along with that, the developers have added full support for actual fonts, instead of the whole “import TTF to textures” process we used to have to do. This also opens up the possibility of customizing the editor’s fonts, their colors and sizes. And it’s a small step from there to full-on theming, so that’s in, too.

Another nicety is custom keybindings, and that solves one of my bigger gripes. Not that I couldn’t change the bindings, mind you; I rarely do that in programming apps, if only because it makes tutorials harder to follow. No, now I can actually see what the default bindings are. Godot’s documentation was severely lacking in that area, but giving me the option to change now also brings the ability to discover, and that’s always a good thing.

They’ve also added some drag-and-drop stuff that I’ll probably never use, along with context menus, which I certainly will. And then there’s the usual improvements to the script editor, which are necessary when you’re using your own scripting language. (More on that later.)

Animation

Animation in Godot confused me. It must have confused a lot of other people, too, because one of the big new additions is a simpler way of using the AnimatedSprite node for, well, animation. You know, the thing it’s made for. No longer do you have to create an AnimationPlayer and all that, when all you really want to do is say, “Hey, play this one little animation, okay?”

The verdict

The official announcement (linked above) has a few other additions, like new features for live reloading. They’ve also got a link to the full changelog, if you like reading. But I’m content with what I’ve seen so far. Godot is still good, and it looks like it’s only getting better—maybe.

What does the future hold? Well, according to the developers, the next version is 2.2, due by the end of the year. (Yeah, right!) That one’s the first true “feature” release, and what features it’ll have. Do you hate Python? My brother does, so he’s happy to hear that Godot will soon give you not one, but two new options for scripting. One is a “visual” design system like Unreal’s Blueprints, a style that I’ll be writing about soon. The other is massive in its importance: C#. Yep, the same language Unity uses. If that takes off, then look out.

Beyond that, things get murky. They claim they’re already starting on Godot 3.0, and it’ll come out early next year. As it’s centerpiece, it’ll have an entirely new renderer, probably based on Vulkan. And that might be a problem. But I’ll wait and see. Godot is too good to abandon, but I hope it doesn’t abandon me on the road to better things.

On game jams

This post is going up in August, and that’s the month for the summer version of everyone’s favorite game jam, Ludum Dare. But I’m writing this at the end of June, when there’s still a bit of drama regarding whether the competition will even take place. If it does, then that’s great. If not, well, that’s too bad. Neither outcome affects the substance of this text.

Ludum Dare isn’t the only game jam on the market, anyway. It’s just the most popular. But all of them have a few things in common. They’re competitive programming, in the sense of writing a program that follows certain rules (such as a theme) in a certain time—two or three days, for example, or a week—with the results being judged and winners declared. In this, it’s a little more serious than something like NaNoWriMo.

And it’s not for me. Now, that’s just my opinion. I’m not saying game jams are a bad thing in general, nor am I casting aspersions at LD in particular. I simply don’t feel that something like this fits my coding style. It’s the same thing with NaNoWriMo, actually. I’ve never truly “competed” in it, though I have followed along with the “write 50,000 words in November” guideline. Again, that’s because it’s not my style.

One reason is shyness. I don’t want people to see my unfinished work. I’m afraid of what they’d say. Another reason is the schedule, and that’s far more of a factor for a three-day game jam than a month-long writing exercise. I don’t think I could stand to code for the better part of 48 or 72 hours. Call it flightiness or a poor attention span, but I can’t code (or write) for hours on end. I have to take a break and do something else for a while.

Finally, there are the rules themselves. I don’t like rules intruding on my creative expression. In my view, trying to direct art of any kind is a waste of time. I have my own ideas and themes, thank you very much. All I need from you is the gentle nudge to get me to put them into action. That’s why I do a kind of “shadow” NaNoWriMo, instead of participating in the “real thing”. It seems antisocial, but I feel it’s a better use of my time and effort. What’s important is the goal you set for yourself. Climbing into a straitjacket to achieve it just doesn’t appeal to me.

But I do see why others look at game jams differently. They are that nudge, that impetus that helps us overcome our writing (or coding) inertia. And that is a noble enough purpose. I doubt I’ll join the next Ludum Dare or whatever, but I won’t begrudge the existence of the game jam. It does what it needs to do: it gets people to express themselves. It gets them to write code when they otherwise wouldn’t dare. There’s nothing bad about that, even if it isn’t my thing.