gamedev – Page 2 – Prose Poetry Code

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:

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

Cooldowns

A lot of games these days have embraced a real-time style of fighting involving powers or other special abilities that, once activated, can’t be used again for a specific amount of time. They have to “cool down”, so to speak, leading the waiting period to be called a cooldown. FPS, RTS, MOBA…this particular style of play transcends genres. It’s not only for battles, either. Some mobile games have taken it to the extreme, putting even basic gameplay on a cooldown timer. Of course, if you don’t mind dropping a little cash, they’ll gladly let you cut out the waiting.

A bit of history

The whole idea of cooldowns in gaming probably goes back to role-playing games. In RPGs, combat typically works by rounds. Newer editions of D&D, for example, use rounds of 6 seconds. A few longer actions can be done, resulting in your “turn” being skipped in the following round, but the general ratio is one action to one round. This creates a turn-based style of play that usually isn’t time-sensitive. (It can be, though. Games such as Baldur’s Gate turn this system into one supporting real-time action.)

A more fast-paced, interactive style comes from the “Active Time” battles in some of the Final Fantasy games. This might be considered the beginning of cooldowns, at least in popular gaming. Here, a character’s turn comes around after a set period of time, which can change based on items, spells, or a speed stat. Slower characters take longer to fill up their “charge time”, and Haste spells make it fill faster.

Over the past couple of decades, developers have refined and evolved this system into the one we have today. Along the way, some of them have largely discarded the suspension of disbelief and story reasoning for cooldowns. Especially in competitive gaming, they’re nothing more than another mechanic like DPS or area of effect. But they are pretty much everywhere these days, in whatever guise, because they serve a useful purpose: forcing resource management based on time.

Using cooldowns

At the most basic level, that’s what cooldowns are all about. They’re there for game balance. Requiring you to wait between uses of your “ultimate” ability means you have to learn to use the smaller ones. Limiting healing powers to one use every X seconds gives players a reason to back off from a bigger foe; it also frees you from the need to place (and plan for) disposable items like potions. Conversely, if you use cooldowns extensively in your game, you have to make sure that the scenarios where they come into play are written for them.

On the programming side, cooldown timers are fairly easy to implement. Most game engines have some sort of timer functionality, and that’s a good base to build from. When an ability is used, set the timer to the cooldown period and start it. When it signals that it’s finished, that means that the ability is ready to go again.

But to better illustrate how they work—and because not every game engine likes having dozens or hundreds of timers running at once—here’s a different approach. We’ll start with a kind of “cooldown object”:

class CooldownAbility {
    // ...

    void activateAbility();

    void updateTimer(int timeDelta);

    int defaultCooldown;
    int cooldown;
    int coolingTime;
    bool isCoolingDown;
};

(This is C++-like pseudocode made to illustrate the point. I wouldn’t write a real game like this.)

activateAbility should be self-explanatory. It would probably have a structure like this:

void activateAbility() {
    // do flashy stuff
    // ...

    // start the cooldown period
    coolingTime = 0;
    isCoolingDown = true;
}

The updateTimer method here does just that. Each time it’s called, it adds the timeDelta value (this should be the time since the last update) to the coolingTime, and checks to see if it reached the cooldown limit:

void updateTimer(int timeDelta) {
    coolingTime += timeDelta;

    isCoolingDown = (coolingTime < coolDown);
}

Most games have a nice timer built right in: the game loop. And there’s likely already code in there for keeping track of the time since the last run of the loop. It’s simple enough to hook that in to a kind of “cooldown manager”, which runs through all of the “unusable” abilities and updates the time since last use. That might look something like this:

for (auto&& cd : allCooldowns) {
    cd.updateTimer(timeThisFrame);

    if (!cd.isCoolingDown) {
        // tell the game that the ability is ready
    }
}

(Also, the reason I gave this object both a cooldown and a defaultCooldown is so that, if we wanted, we could implement power-ups that reduce cooldown or penalties that increase it.)

Implementing this same thing in an entity-component engine can work almost the same way. Abilities could be entities with cooldown components, and you could add in a system that does the updating, cooldown reduction/increase, etc.

For a certain style of game, timed resource use makes sense. It makes gameplay better. It opens up new tactics, new strategies, especially in multiplayer gaming. And while it takes a lot of design effort to keep a cooldown-based game balanced and fun, the code isn’t that hard at all. That’s especially good news for indie devs, because they get more time to spend on the balancing part.

First glance: Superpowers

It seems like each new day brings us a new tool for game development, whether it’s an engine, a framework, a library, or any of a number of other things. Best of all, many of these up-and-coming dev tools are open source and free, so even the poorest game makers (like me!) can use them. And the quality is only going up, too. No longer must indies be content with alpha-level, code-only engines, uncompiled libraries, and NES-era assets. No, even the zero-cost level of game development is becoming packed with tools that even professionals of a few years ago wished they could have had.

The one I’m looking at today is called Superpowers, by Sparklin Labs. It’s yet another HTML5 game maker that has recently been released as open source software, under the ISC license. (ISC is functionally equivalent to MIT or “new” BSD; basically, it’s not much more than “do what you want, but give us credit”.) It’s not entirely a volunteer effort, and there are a couple of options for supporting it. Their download host, indie game publisher itch.io, gives you a donation option, but the primary way to send money is through Patreon. (There’s a link on the Superpowers main page.)

Let’s take a look

What does Superpowers bring to the table? Well, first of all, it’s an HTML5 engine. The maker itself runs as a nativized web app, and games can be compiled into standalone apps or exported in a browser-friendly format. There’s also a mobile option using the Intel XDK, but I haven’t really looked into that.

Second, and even more important, is the fact that this engine comes with a visual editor. That’s something sorely lacking in the free HTML5 arena. Granted, it’s not exactly up to the level of the editors for Unity or Unreal, but it’s much better than what we had, i.e., not much. It’s got all the usual bells and whistles: tree-based scene management, component editors (these seem a little buggy on my machine, but that’s probably just a local thing), drag-and-drop actors, and so on. For what’s technically still a beta, it’s pretty nice.

Coding works about the same way. You can attach scripts to the various parts of a scene, and they’ll know what to do. The whole thing is mostly behavior-driven, following the component style that is so popular these days. The scripts themselves are written in TypeScript, and I’m a little ambivalent about that. On the one hand, it’s an easier way of writing JavaScript (Superpowers is HTML5-based, so it’s going to end up as JavaScript eventually). On the other, TypeScript is a Microsoft project, so you never know what might happen.

One of the big features that looks interesting is the collaboration support. The Superpowers “app” has a client-server architecture, and it takes advantage of it. When you start it, it creates a server. Now, that’s pretty common in Node applications, but Superpowers actually uses it. After a little initial setup, you can have other people connect to your editor instance and work with you in real-time. I can’t tell you how well that works, since I’m just a lonely guy, but if it comes anywhere close to what’s advertised, then…wow.

There’s a lot more than this, and what I’m seeing looks very good. There’s support for prefabs (like those in Unity) in the editor, for instance, and the engine has all the usual suspects: 2D physics, multiple cameras, etc. Debugging works like in Chrome, since the whole thing runs on NW.js. (IMO, Chrome is a horrible browser, but an okay wrapper for web apps. The developer tools aren’t half bad, though.)

That’s not to say the Superpowers is perfect. Far from it. It’s early in development, and there’s bound to be a few unsquashed bugs here and there. There’s also the TypeScript dependency I mentioned above, but they’re working on that; the developers have an alpha (I think) version of the editor using Lua and the LÖVE engine. And, being on GitHub, I noticed a “Code of Conduct” file, which could be worrisome to free-speech advocates like myself. Also, there’s no online API documentation. You’re supposed to use the editor’s built-in docs. The developers’ reasoning (it boils down to “But there might be plugins!”) sounds weak to my ears. Every other HTML5 engine can do it, so why not this one?

In the end, I think the good outweighs the bad. Give it some time, and Superpowers might become one of the go-to tools for making indie games. Or it could bomb, and we’ll never hear from it again. I doubt that, though. Give me some proper online API docs, support for multiple languages (including pure JavaScript, preferably of the ES6 variety), and quite a bit more polish, and I’ll gladly put it up there with Phaser at the top of the list. For now, I’ll definitely be keeping an eye on this one.

First glance: Unreal.js

With Christmas coming up, I don’t exactly have the time to write those 2,000-word monologues that I’ve been doing. But I want to post something, if only because laziness would intervene otherwise. Inertia would take over, and I’d stop posting anything at all. I know it would happen. I’ve done it once before. So, these last few Wednesdays of 2015 will be short and sweet.

This time around, I want to talk about something I recently found on a wonderful site called Game From Scratch. It’s called Unreal.js, and it’s open-source (Apache license). What does it do? Well, that’s the interesting thing, and that’s what I’m going to ramble on about.

You’ve probably heard of UnrealEngine. It’s the latest iteration of the game engine used to power a wide array of games, from Unreal Tournament to AAA titles like the newest Street Fighter and Tekken to hundreds of up-and-coming indie games. The most recent version, UnrealEngine 4, is getting a lot of press mainly because of its remarkably open development and friendly pricing scheme. (Compared to other professional game engines, anyway.) Lately, Unreal has become a serious competitor to Unity for the middle tier of game development, and competition is an indisputably good thing.

But Unreal has a problem compared to Unity. You see, Unity runs on Microsoft’s .NET framework. (Strictly speaking, it runs on Mono, which is a Microsoft-approved knockoff of .NET that used to be fully open, to the point where most Linux distributions preinstalled it a few years ago. Now…not so much.) Anyway, Unity uses .NET, and one of the nifty things about .NET is that, like the JVM, it’s not restricted to a single language. Sure, you’re most likely to use C#, but you don’t have to. Unity explicitly supports JavaScript, and it used to have full support for a Python clone called Boo. (Supposedly, there are ways to get other languages like F# to work with it, but I don’t know why anyone would want to.)

Unreal, on the other hand, uses C++. From a performance perspective, that’s a great thing. C++ is fast, it can use far less memory than even C#, and it’s closer to the hardware, making it easier to take advantage of platform-specific optimizations. However, C++ is (in my experienced opinion) one of the hardest programming languages to learn well. It’s also fairly ugly. The recent C++11 standard helps a lot with both of these problems, but full support just isn’t there yet, even 4 years later. C++17 looks like it will go a few steps further in the “ease of use” direction, but you’ll be lucky to use it before 2020.

The makers of UnrealEngine know all of this, so they included a “visual” programming language, Blueprints. Great idea, in theory, but there are a lot of languages out there that you don’t need to invent. Why not use one of them? Well, that’s where Unreal.js comes in. Its developers (some guys called NCSoft; you may have heard of them) have made a plugin that connects the V8 JavaScript engine from Chrome/Safari/Node.js/everywhere into Unreal. The whole thing is still in a very early stage, but it’s shaping up to be something interesting.

If Unreal.js takes off, then it can put Unreal well ahead of Unity, even among hobbyists and lower-end indies. JavaScript is a lot easier on the brain than C++ (take it from someone who knows both). And it has a huge following, not just for webapps and server stuff. The Unreal.js project page claims support for “(Full) access to existing javascript libraries via npm, bower, …”

That’s huge. Sure, not all npm packages are of the highest quality, but there are plenty that are, and this would let you use all of them to help make a game. Game engines, historically, have been some of the worst about code reuse, 3rd-party libraries, and other niceties that “normal” applications get to use. Well, that can change.

And then there’s one other factor: other languages. Since Unreal.js is pretty much just the V8 engine from Node, and it can load most Node packages, that opens the possibility of using some of the many “transpiled” languages that are transformed to Node-friendly JavaScript. Think CoffeeScript, TypeScript (which recently released its new 1.7 version), or even my April Fools’ Day joke language Elan.

Maybe I’m wrong. Maybe Unreal.js will fizzle. Perhaps it’s destined to join the legions of other failed attempts at integrating game development with the rest of the programming world. I hope not. The past few years have seen a real move in the direction of democratizing the art of game-making again. I’d like to see that trend continue in 2016 and beyond.

Transparent terrain with Tiled

Tiled is a great application for game developers. One of its niftiest features is the Terrain tool, which makes it pretty easy to draw a tilemap that looks good with minimal effort.

Unfortunately, the Terrain tool does have its limitations. One of those is a big one: it doesn’t work across layers. Layers are essential for any drawing but the simplest MS Paint sketches, and it’s a shame that such a valuable development tool can’t use them to their fullest potential.

Well, here’s a quick and dirty way to work around that inability in a specific case that I ran into recently.

The problem

A lot of the “indie” tile sets out there use transparency (or a color key, which has the same effect) to make nice-looking borders. The one I’m using here, Kenney’s excellent Roguelike/RPG pack, is one such set.

The problem comes when you want to use it in Tiled. Because of the transparency, you get an effect like this:

Transparent terrain

Normally, you’d just use layers to work around this, maybe by making separate “grass” and “road” layers. If you’re using the Terrain tool, though, you can’t do this. The tool relies on “transitions” between tile types. Drawing on a new layer means you’re starting with a blank slate. And that means no transitions.

The solution

The solution is simple, and it’s pretty much what you’d expect. In a normal tilemap, you might have the following layers (from the bottom up):

The bare ground (grass, sand, water, whatever),
Roads, paths, and other terrain modifications,
Buildings, trees, and other placeable objects.

My solution to the Terrain tool’s limitation is to draw all the “terrain” effects on a single layer. Below that layer would be a “base”, which only contains the ground tiles needed to fill in the gaps. So our list would look more like this:

Base (only needs to be filled in under tiles with transparency),
Terrain, including roads and other mods,
Placeable objects, as before.

For our road on grassland above, we can use the Terrain tool just as described in the official tutorial. After we’re done, we can create a new layer underneath that one. On it, we would draw the base grass tiles where we have the transparent gaps on our road. (Of course, we can just bucket fill the whole thing, too. That’s quicker, but this way is more flexible.) The end result? Something like this:

Filling in the gaps

It’s a little more work, but it ends up being worth it. And you were going to have to do it anyway.

Phaser 2.4 released

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

First Languages for Game Development

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

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

No Language At All

Examples: Scratch, Construct2, GameMaker

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

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

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

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

JavaScript

Examples: Unity3D, Phaser

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

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

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

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

C++ (with a few words on C)

Examples: Unreal Engine 4, SFML, Urho3D

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

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

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

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

Lua

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

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

C#

Examples: Unity3D, MonoGame

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

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

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

Java

Examples: LibGDX, JMonkeyEngine, anything on Android

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

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

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

Python

Examples: Pygame, RenPy

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

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

Engine-Specific Scripting

Examples: GameMaker, Godot Engine, Torque, Inform 7

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

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

The Field

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

Swift (SpriteKit) and Objective-C (iOS): I don’t have a Mac, which is a requirement for developing iOS apps, and Swift is really only useful for that purpose. Objective-C actually does work for cross-platform programming, but I’m not aware of any engines that use it, except those that are Apple-specific.
Haxe (HaxeFlixel): Flash is dying as a platform, and Haxe (through OpenFL) is its spiritual successor. HaxeFlixel is a 2D engine that I’ve really tried to like. It’s not easy to get into, though. The language itself isn’t that bad, though it may be more useful for porting old Flash stuff than making new games.
Ruby (RPG Maker VX Ace): Ruby is one of those things I have an irrational hatred for, like broccoli and reality shows. (My hatred of cats, on the other hand, is entirely rational.) Still, I can’t deny that it’s a useful language for a lot of people. And it’s the scripting language for RPG Maker, when you have to delve into that engine’s inner workings. Really, if you’re not using RPG Maker, I don’t see any reason to bother with Ruby, but you might see things differently.
JavaScript variants (Phaser): Some people (and corporations), fed up with JavaScript’s limitations, decided to improve it. But they all went in their own directions, with the result of a bewildering array of languages: CoffeeScript, TypeScript, LiveScript, Dart, and Coco, to name a few. For a game developer, the only one directly of any use is TypeScript, because Phaser has it as a secondary language. They all compile into JS, though, so you can choose the flavor you like.

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