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.)

  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.

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.

Indie genres

Being a game developer is hard. Going at it as an indie is that much harder. You don’t have the budget that the big guys have, which means that you can’t afford flashy, state-of-the-art graphics, A-list voice actors, or a soundtrack full of 80s hits. That doesn’t mean that indie games can’t be great. They can, as the past few years have shown. (After I finish writing this post, I’ll probably go back to Sunless Sea, one of those great indie games.)

But the lack of money, and the lack of assets, technology, and infrastructure that it creates, that does have an impact on what an indie dev can do. That’s starting to change, but we’re not quite there yet. For the time being, entire swaths of gaming’s concept space are blocked off for those of us not backed by the AAA guys.

It’s for this reason that some gaming genres are far more common for indies. Those that are the easiest to write, those using the least amount of “expensive” bits, and those that fit within the capabilities of indie-available tools are best represented. Others are rarer, because they’re so much more difficult for a small studio or lone developer.

So let’s see what we can do. I’ve taken the most popular game genres and divided them into three broad categories: those that are very indie-friendly, the ones that indies probably can’t make, and a few that are on the bubble.

The good

  • Puzzles: Puzzle games are some of the first that budding game developers learn how to make, and they’re still highly popular. They’re easy to make, they don’t require a lot of high-quality assets, and people know they won’t be very fancy. Yet puzzle games can be incredibly addictive, even for casual players. These are always a good choice for an indie project, particularly a solo one.

  • Platformers: Another popular genre that perfectly fits the indie mold. Most of the low-cost and free engines have special support baked in for platformers, almost like the creators are steering you towards the genre. And it’s good that they are, as platformers have brought success to quite a few developers over the years. People thought they were dead when the 3D revolution hit, but time has only proven them wrong.

  • Adventure: Adventure gaming is another genre left for dead in decades past. But it also found resurgence in recent years. Point-and-click adventures, survival horror, visual novels, and even interactive fiction have grown in popularity. For indies, adventure is a good genre because it rewards great writing over eye-candy. Art is hard for most programmers, but there are a lot of free assets you can use here.

  • Shooters: First-person or third-person, shooters are popular everywhere. Most of the major engines are tuned for them, and for a while it seemed like that was all the big guys knew how to make. Now, indies aren’t going to make the next blockbuster franchise, but that’s no reason to give up on the shooter genre. Plenty of niche gamers have a favorite shooter. The hardest parts are the assets (but Unity, for instance, has a lot of them available at a decent price) and the multiplayer backend. Get those straight, and you’re golden.

  • Retro: I’m using “retro” as a catchall term for a number of smaller genres that have been around for a long time and are still popular today…in their original forms. Think shoot-em-ups, for example. A lot of people seem to like the retro feel. Pixel art, 8-bit sounds, garish color schemes, and frustratingly difficult gameplay are the rule here, and a subset of gamers will eat that up. In other words, retro gaming is a perfect fit for indies: assets are easy to create, nobody expects them to be good, and you don’t have to worry much about game balance.

  • Sandbox: Ah, Minecraft. The open-world sandbox might be the defining genre of the 2010s, and it’s one that the bigger studios haven’t really tackled very much. Some of the best sandbox games, according to the gamers I’ve talked to, are the indie ones. The genre does have an allure to it. No story needed, AI is only for enemies, the world is made by code, and players will swoon over the “emergent” gameplay. What’s not to love? (Of course, it’s never that simple, but that hasn’t stopped indies from taking over the sandbox space.)

The bad

These next few genres are the ones that don’t seem indie-friendly, but a dedicated developer could make something out of them.

  • Turn-based strategy: Of the strategy variants, I prefer this one for its laid-back nature. But it’s a hard one for an indie. You’ve got two real choices. You can focus on single-player, but then you need a good handle on AI. Or you can make a multiplayer-centric game, with all the problems that entails. Still, it can be done, even as a volunteer effort. Freeciv and Battle for Wesnoth are two examples of free strategy games that have won hearts and minds.

  • Simulation: Sims are another tantalizing genre. They’re a little more complex than their sandbox cousins, often because they have restrictions and goals and such, but most of the same arguments apply. Simulation games also tend to be better focused, and focus is a powerful tool ignored by many devs on either side of the money line. But they’re a lot of work, and it’s a different kind of work. Simulations need to be researched, then written in such a way that they (mostly) reflect reality. Can indies do it? Kerbal Space Program proves they can, but it’s not going to be easy.

  • Role-playing: RPGs, in my opinion, are right on the line of what’s doable for a solo developer. They’re well within the reach of an indie studio, however. It’s not the code that’s the problem—RPG Maker takes care of most of that—but the combination of gameplay, artwork, and writing that makes an RPG hard. That shouldn’t stop you from trying. When done right, this genre is one of the best. Free or cheap assets help a lot here, although you still have to do the storyline yourself.

The ugly

Some genres are mostly beyond indie capabilities. Not that they haven’t given them a shot. Sometimes, it even pays off.

  • Sports: With one exception, sports games are very unfriendly to smaller studios. You’re competing against juggernauts who’ve been at this for decades, and they have all the licenses, endorsements, and publicity. But if you’re willing to invent a new sport, you just might be able to slip into the picture. If you have a bigger budget, that is. It worked for Rocket League.

  • MMO: Just no. MMOs combine all the problems of RPGs with all the hassle of multiplayer shooters, and the whole is much greater, in terms of trouble, than the sum of its parts. Indies have tried, but few have really succeeded. It’s a combination of content and infrastructure that tends to doom them. The general lack of dedicated tooling (MMO-specific engines, etc.) doesn’t help matters.

  • Real-time strategy: The RTS genre is almost dead unless your game is named StarCraft, all but replaced by the MOBA. Either way, it’s a tall order for indies. Strong AI, good artwork, racks of servers to host the multiplayer matches, and the list only grows from there. To top it off, the real-time genres seem to attract more cheaters than just about anything else, so you have to be watchful. But monitoring games for cheating means taking your eyes off the code or hiring moderators. Neither is a good option for a dev on a tiny budget. If you somehow manage it, the payoff can be enormous, because of one recently coined word: esports.

  • Console: This is a platform, not a genre, but it’s worth mentioning here. Thanks to the closed nature of consoles, indie development usually isn’t worth pursuing. Yes, Sony and Microsoft have become more open in the last few years (Nintendo is, if anything, becoming even worse), but there are still too many barriers in the way to make console games a good use of your valuable time. Stick to the three PC platforms (Windows, Linux, and Mac) and the two mobile ones (Android, iOS) at the start.

Godot game, part 2: Abort, retry, fail?

I don’t believe in fate. Problem is, fate doesn’t seem to care.

The week started off just fine. I got a bit of work done on the game late Wednesday night and early Thursday morning. Then, disaster struck.

For most of the next few days, I was almost totally bedridden, shivering and sweating in turns, coughing my head off, getting dizzy every time I stood up, and generally feeling awful. I figured it was nothing more than the usual allergy flareup of late spring/early summer at first, but as the days wore on, I suspected something more was afoot.

It was my mother’s idea to take me to the ER yesterday evening. I’m a poor, white man living in the rural South, so that’s effectively my only option, and it’s one I only like using as a last resort. When I go, it’s more to find out exactly what’s wrong with me than out of any hope that they can fix it. The ease of mind is just as valuable as the diagnosis and treatment.

After a 20-mile drive down there (again, rural South) and about half an hour of waiting, the doctor gave the verdict: bronchitis. Nothing worse than that, thank goodness, but that’s already bad enough, if you ask me. In the grand spirit of American doctors, he gave me a round of antibiotics (for what is probably a viral infection, naturally) and some lovely opioid-based cough syrup that is about as appealing to me as the coughing itself. Honestly, I can’t complain too much; I know from experience that there’s only so much you can do for bronchitis, apart from letting it run its course. But my mind is at ease, and that’s a far better medicine.

What does this mean for my grand “Godot Game Month” project, you ask? Well, total failure. Nothing less. Even if I felt 100% better today, I doubt I could work hard enough to catch up on the days I’ve lost. And I don’t feel much better. (Just as I wrote that sentence, I had another mild fit of coughing. Fortunately, nothing bad came of it. Correction: more bloody mucus. Yay.)

I know my limits. I know how far I can push them. I hate to admit defeat, but I am well aware when something is beyond my capability. This is one of those cases.

So, to sum up, the game is on hold, indefinitely. Once I get at least somewhat healed, I’ll start working on it again, but as a long-term project, something I do in my spare time. I tempted fate with this idea, and she slapped me down for it. I’ve learned my lesson; it won’t happen again.

As for the other posts, I have a nice queue full of them, enough to take me through the middle of July. Those will proceed as scheduled. Hopefully, by the time I need*to write again, I’ll feel like doing it.

A Godot game, part 1

So I’ve really been neglecting the “code” aspect of Prose Poetry Code lately. I’ve been far more focused on writing than writing programs, and it shows. Let’s change that. Let’s make a game.

The month of June has five Wednesdays this year. The first one is today, June 1. That’s the starting line. By June 29, four weeks from the day this is posted, I hope to have…something. I don’t know what it’ll be, but I want it to be more than my previous aborted attempts at actually creating a game.

Here’s the idea. I think Godot is a great game engine for indie developers on a budget, as I’ve said more than once on here. Now, I’m going to put my (lack of) money where my mouth is. My game will be simple enough, a little word-building game that’s a bit like a cross between Tetris and Boggle. Blocks containing letters fall from the top of the screen, and the player has to arrange them to form English words. Each word formed counts for points (based on the length of the word and possibly other factors) and it is removed from the board after it is made. If the player runs out of space on the board, it’s Game Over.

That’s what I have so far. I’ll worry about combos, difficulty levels, and things like that along the way. Think of this more like a game jam entry than a design document. Hopefully, by starting small, I’ll manage to end the month with something playable.

For those interested, here are the technicalities:

  1. Although I’m writing this post on May 4, and I’ve already created an empty Godot project, I won’t start coding until this post is up, on June 1.

  2. The goal is to have a playable game by June 29. It won’t be a finished product by any means, but I want something that could reasonably be called an alpha by that time.

  3. I’m using Godot for the engine, and the assets are coming from OpenGameArt. At the end of this, I may put all of it up for download, but I don’t know yet.

  4. Each Wednesday, I’ll post a bit of a status report. Those will make up the Code posts for this month. (Software Internals will return the first week of July.)

  5. Other posts (worldbuilding, conlang, etc.) are still on schedule. I write those beforehand, mostly when I’m bored, so I should have a month of them stored up.

You’re welcome to play along at home. This isn’t a competition, though. If I can’t do it, then I can’t. So don’t expect me to push myself like I do for NaNoWriMo. Besides, there aren’t really any metrics for development like a word count. Counting lines of code isn’t that helpful, because nobody can predict how many of them you’d need. And finally, this is meant to be fun and educational for me, but I hope you take the same time to explore for yourself.

With that, I’m out for this week. Wish me luck. I’ll need it.

Democratization of development

Ten years ago, you only had a very few options for making a game. I know. I was there. For indies, you were basically limited to a few open-source code libraries (like Allegro) or some fairly expensive professional stuff. There were a few niche options—RPG Maker has been around forever, and it’s never cost too much—but most dev tools fell into the “free but bad” or “good if you’ve got the money” categories. And, to top it off, you were essentially limited to the PC. If you wanted to go out of your way, Linux and Mac were available, but most didn’t bother, and consoles were right out.

Fast forward five years, to 2011. That’s really around the time Unity took off, and that’s why we got so many big indie games around that time. Why? Because Unity had a free version that was more than just a demo. Sure, the “pro” version cost an arm and a leg (from a hobbyist perspective), but you only had to get it once you made enough profit that you could afford it. And so the 2010s have seen a huge increase in the number—and quality—of indie titles.

Five more years bring us to the present, and it’s clear that we’re in the midst of a revolution. Now, Unity is the outlier because it costs too much. $1500 (or $75/month) is now on the high end for game engines. Unreal uses a royalty model. CryEngine V is “pay what you want”. Godot and Atomic lead a host of free engines that are steadily gaining ground on the big boys. GameMaker, RPG Maker, and the like are still out there, and even the code-only guys are only getting better.

Engines are a solved problem. Sure, there’s always room for one more, and newcomers can bring valuable insights and new methods of doing things. The basics, though, are out there for everyone. Even if you’re the most hardcore free-software zealot, you’ve got choices for game development that simply can’t be beat.

If you follow development in other media, then you know what’s happening. Game development is becoming democratized. It’s the same process that is bringing movie production out of the studio realm. It’s the same thing that gave every garage band or MIDI tinkerer a worldwide audience through sites like SoundCloud and Bandcamp. It’s why I was able to put Before I Wake into a store offering a million other e-books.

Games are no different in this respect. The production costs, the costs of the “back-end” necessities like software and distribution, are tending towards zero. Economists can tell you all about the underlying reasons, but we, as creators, need only sit back and enjoy the opportunity.

Of course, there’s still a ways to go. There’s more to a game than just the programming. Books are more than collections of words, and it takes more than cameras to make a movie. But democratization has cut down one of the barriers to entry.

Looking specifically at games, what else needs to be done? Well, we’ve got the hard part (the engine) out of the way. Simpler ways of programming are always helpful; Unreal’s Blueprints and all the other “code-less” systems have some nifty ideas. Story work doesn’t look like it can be made any easier than it already is, i.e., not at all. Similarly, game balance is probably impossible to solve in a general sense. Things like that will always have to be left to a developer.

But there is one place where there’s lots of room for improvement: assets. I’m talking about the graphics, sounds, textures, and all those other things that go into creating the audiovisual experience of a game. Those are still expensive or time-consuming, requiring their own special software and talent.

For asset creation, democratization is hard at work. From the venerable standbys of GIMP and Inkscape and Blender to the recently-freed OpenToonz, finding the tools to make game assets isn’t hard at all. Learning how to use them, on the other hand, can take weeks or months. That’s one of the reasons why it’s nearly impossible to make a one-man game these days: audiences expect the kind of polish that comes with having a dedicated artist, a dedicated musician, and so on.

So there’s another option, and that’s asset libraries. We’ve got a few of those already, like OpenGameArt.org, but we can always use more. Unity has grown so popular for indie devs not because it’s a good engine, but because it’s relatively inexpensive and because it has a huge amount of assets that you can buy from right there in the editor. When you can get everything you need for a first-person shooter for less than a hundred dollars (or that Humble Bundle CryEngine collection from a while back), that goes a long way towards cutting your development costs even further.

Sure, asset libraries won’t replace a good team of artists working on custom designs specifically for your game, but they’re perfect for hobbyists and indies in the “Early Access” stage. If you hit it big, then you can always replace the stock artwork with something better later on. Just label the asset-library version “Alpha”, and you’re all set.

Looking ahead to the beginning of the next decade, I can’t say how things will play out. The game engines that are in the wild right now won’t go away, especially those that have been released for free. And there’s nowhere to go but up for them. On the asset side of things, it’s easy to see the same trend spreading. A few big “pack” releases would do wonders for low-cost game development, while real-world photography and sound recording allow amateurs to get very close to professional quality without the “Pro” markup.

As a game developer, there’s probably no better time to be alive. The only thing that comes close is the early generation of PC games, when anyone could throw together something that rivaled the best teams around. Those days are long past, but they might be coming back. We may be seeing the beginning of the end for the “elite” mentality, the notion that only a chosen few are allowed to produce, and everyone else must be a consumer. Soon, the difference between “indie” and “AAA” won’t be because the tools used. And that’s democracy in action.