Thoughts – Page 18 – Prose Poetry Code

The alternative

No form of government is perfect. If one were, every nation-state would eventually gravitate towards it. Nor will I say that I have developed the perfect form of rule. In fact, I’m not sure such a thing is possible. However, I can present an alternative to the deeply flawed systems of the present day.

Guided by the principles of good government we have previously seen, and aided by logic, reason, and the wisdom of ages, we can derive a new method, a better method. It is not a fully-formed system. Rather, it is a framework with which we can tinker and adjust. It is a doctrine, what I call the Doctrine of Social Liberty.

I cannot accept the strictures of current political movements. In my eyes, they all fail at some point. That is the reason for stating my principles. Those are the core beliefs I hold, generalized into something that can apply to any nation, any state. A government that does not follow those principles is one that fails to represent me. I am a realist; as I said above, nothing is perfect. Yet we should strive for perfection, despite it being ever unattainable. The Doctrine of Social Liberty is my step in that direction.

More than ever, we need a sensible, rational government based on sound fundamentals. The answer does not lie in slavishly following the dogmatic manifestos of radical movements. It does not lie in constant partisan bickering. It can only be found by taking a step back, by asking ourselves what it is that we want from that which governs us.

Over the coming weeks, I hope to detail what I want from a government. I don’t normally post on Tuesdays, but the coming election presents a suitable reason to do so. In four posts, I will describe my doctrine in its broadest strokes, and I will show how our current ruling class violates the principles I have laid out. Afterward, following the start of next year, I want to go into greater detail, because I think these things will become even more relevant.

On visual programming

With the recent release of Godot 2.1, the engine’s developers broke the news of a project coming to a future version: a visual scripting system. That’s nothing new, even in the world of game development. Unreal came out with Blueprints a while back, and even Godot already used something similar for its shaders. Elsewhere, “visual programming” has its proponents and detractors, and I’m going to throw in my two cents.

Seeing is believing

In theory, visual programming is the greatest revolution in coding since functions. It’s supposed to deliver all the benefits of writing programs to those who don’t want to, well, write. The practice has its origins in flowcharts, which are graphical representations of algorithms. Computer scientists got to thinking, “Okay, so we can make algorithms like this, so why not whole applications?” It’s only been fairly recently that computers have been able to fulfill this desire, but visual programming languages are now springing up everywhere.

The idea is deceptive in its simplicity. Instead of laboriously typing out function declarations and loop bodies, you drag and drop boxes (or other shapes), connecting them to show the flow of logic through your program. The output of one function can be “wired” to another’s input, for example. The benefits are obvious. Forget about syntax errors. Never worry about type mismatches again. Code can truly become art. With the name of this site, you’d think I could get behind that.

It does work, I’ll give you that. MIT’s Scratch is used by tens of thousands of programmers, young and old alike. Through its ingenious “building block” system, where the “boxes” are shaped like pieces in a jigsaw puzzle, you never have to worry about putting the wrong peg into the wrong hole. For children who barely understand how a computer works—or, in extreme cases, may not know how to read yet—it’s a great help. There’s a reason why it’s been copied and cloned to no end. It even makes coding fun.

What can’t be unseen

The downsides to visual programming, however, are not fun at all. Ask anyone who’s ever suffered through LabVIEW (I’ve read enough horror stories to keep me away from it forever). Yes, the boxes and blocks are cute, but complex logic is bad enough when it’s in linear, written form. Converted to a more visual format, you see a literal interpretation of the term “spaghetti code”. Imagine how hard it was to write. Now imagine how hard it would be to maintain.

Second, visual programming interfaces have often suffered from a lack of operations. If you wanted to do something that there isn’t a block for, you were most likely out of luck. Today, it’s not so bad. Unreal’s Blueprints, for example, gives you about 95% of the functionality of C++, and Godot’s variation purports to do the same.

But some things just don’t fit. Composition, an important part of programming, is really, really hard to get right visually. Functional styles look like tangled messes. Numerics and statistics are better served in a linear form, where they’re close to the mathematics they’re implementing.

The verdict

I’m not saying visual programming is useless. It’s not. There are cases where it’s a wonderful thing. It’s great for education, and it’s suited to illustrating the way an algorithm works, something that often gets lost in the noise of code. But it needs to be used sparingly. I wouldn’t write an operating system or device driver in Scratch, even if I could. (You can’t, by the way.)

In truth, the visual “style” doesn’t appeal to me. That’s a personal opinion. Your mileage may vary. When I’m learning something new, it’s certainly a big help, but we have to take the training wheels off eventually. Right now, that’s how I see a visual scripting system. For a new programmer, sure, give it a try. You might love it.

But you probably won’t. After a while, you’ll start bumping into the limitations. You’ll have webs of logic that make spiders jealous, or customized blocks that look like something by Escher. Stay simple, and you might keep your sanity—as much as any programmer has, anyway. But we’re not artists. Not in that way, at least. Code can be beautiful without being graphical.

Let’s end threads

Today’s computers almost all have multiple cores. I don’t even think you can buy a single-core processor anymore, at least not one meant for a desktop. More cores means more things can run at once, as we know, and there are two ways we can take advantage of that. One is easy: run more programs. In a multi-core system, you can have one core running the program you’re using right now, another running a background task, and two more ready in case you need them. And that’s great, although you do have the problem of only one set of memory, one hard drive, etc. You can’t really parallelize those.

The second option uses the additional cores to run different parts of a single application. Threads are the usual way of doing this, though they’ve been around far longer than multi-core processors. They’re more of a general concurrency framework. Put a long-running section of code in its own thread, and the OS will make sure it runs. It won’t block the rest of the program. And that’s great, too. Anything that lets us fully utilize this amazing hardware we have is a good thing, right?

Well, no. Threads are undoubtedly useful. We really couldn’t make modern software without them. But I would argue that we, as higher-level programmers, don’t need them. For an application developer, the very existence of threads should be an implementation detail in the same vein as small string optimizations or reference counting. Here’s why I think this.

Threads are low-level

The thread is a low-level construct. That cannot be denied. It’s closer to the operating system layer than the application layer. If you’re working at those lower levels, then that’s what you want, but most developers aren’t doing that. In a general desktop program or mobile app, threads aren’t abstract enough.

To put it another way: C++ bears the brunt of coders’ ire at its “manual” memory management. Unlike C# or Java, a C++ programmer does need to understand the lifecycle of data, when it is constructed and destructed, what happens when it changes hands. But few complain about keeping track of a thread’s lifecycle, which is essentially the same problem.

Manual threading is error-prone

This comes from threads being low-level because, as any programmer will tell you, the lower you are in the “stack”, the more likely you’ll unwittingly create bugs. And there might not be any bigger source of bugs in multithreaded applications than in the threading itself.

Especially in C++, but by no means unheard of in higher-level languages, threading leads to all sorts of undefined or ill-defined behavior, race conditions, and seemingly random bugginess. Because threads are scheduled by the OS, they’re out of your control. You don’t know what’s executing when. End a thread too early, for example, and your main program could try reading data that’s no longer there. And that can be awfully hard to detect with a debugger, since the very act of running something in debug mode will change the timing, the scheduling.

Sharing state sucks

In an ideal situation, one that the FP types tell us we should all strive for, one section of code won’t depend on any state from any other. If that’s the case, then you’ll never have a problem with memory accesses between threads, because there won’t be any.

We code in the real world, however, and the pure-functional approach simply does not work everywhere. But the alternative—accessing data living in one thread from another—is a minefield full of semaphores and mutexes and the like. It’s so bad that processors have implemented “atomic” memory access instructions just for this purpose, but they’re no magic bullet.

Once again, this is a function of threads being “primitive”. They’re manually operated, with all the baggage that entails. In fact, just about every problem with threads boils down to that same thing. So then the question becomes: can we fix it?

A better way

Absolutely. Some programming languages are already doing this, offering a full set of async utilities. Generally, these are higher-level functions, objects, and libraries that hide the workhorse threads behind abstractions. That is, of course, a very good thing for those of us using that higher level, those who don’t want to be bogged down in the minutiae of threading.

The details differ between languages, but the usual idea is that a program will want to run some sort of a “task” in the background, possibly providing data to it at initialization, or perhaps later, and receiving other data as a result. In other words, an async task is little more than a function that just happens to run on a different thread, but we don’t have to care about that last part. And that is the key. We don’t want to worry about how a thread is run, when it returns, and so on. All we care about is that it does what we ask it to, or else it lets us know that it can’t.

This async style can cover most of the other thread-based problems, too. Async tasks only run what they’re asked, they end when they’re done, and they give us ways (e.g., futures) to wait for their results before we try to use them. They take care of the entire lifecycle of threading, which we can then treat as a black box. Sharing memory is a bit harder, as we still need to guard against race conditions, but it can mostly be automated with atomic access controls.

A message-passing system like Scala and Erlang use can even go beyond this, effectively isolating the different tasks to an extent resembling that of the pure-FP style. But even in, say, C++, we can get rid of most direct uses of threads, just like C++11 removed most of the need for raw pointers.

On the application level, in 2016, there’s no reason a programmer should have to worry about manual memory allocation, so why should we worry about manual thread allocation? There are better ways for both. Let’s use them.

On sign languages

Conlangs are, well, constructed languages. For the vast majority of people, a language is written and spoken, so creators of conlangs naturally gravitate towards those forms. But there is another kind of language that does not involve the written word, does not require speech. I’m talking, of course, about sign language.

Signing is not limited to the deaf. We all use body language and gesture every day, from waving goodbye to blowing kisses to holding out a thumbs-up or peace sign. Some of these signs are codified as part of a culture, and a few can be quite specific to a subculture, such as the “hook ’em horns” gesture that is a common symbol of the University of Texas.

Another example of non-deaf signing is the hand signals used by, for example, military and police units. These can be so complex that they become their own little jargon. They’re not full sign languages, but they work a bit like a pidgin, taking in only the minimum amount of vocabulary required for communication.

It’s only within the community of the hearing-impaired that sign language comes into its own, because we’re talking about a large subset of the population with few other options for that communication necessary for human civilization. But what a job they have done. American Sign Language is a complex, fully-formed language, one that is taught in schools, one learned by children the same as any spoken tongue.

Conlangs come in

So speaking with ones body is not only entirely possible, but it’s also an integral part of speaking for many people. (The whole part, for some.) Where does the art of constructing languages come in? Can we make a sign conlang?

Of course we can. ASL was constructed, as are many of the other world sign languages. All of them have a relatively short history, in fact, especially when compared to the antiquity of some natural languages. But there are a few major caveats.

First, sign languages are much more difficult to comprehend, at least for those of us who have never used one. Imagine trying to develop a conlang when you can’t speak any natlang. You won’t get very far. It’s the same way for a non-signer who would want to create a sign language. Only by knowing at least one language (preferably more) can you begin to understand what’s possible, what’s likely, and what’s common.

Second, sign languages are extremely hard to describe in print. ASL has transcription schemes, but they’re…not exactly optimal. Your best bet for detailing a sign conlang might actually be videos.

Finally, a non-spoken, non-written language will necessarily have a much smaller audience. Few Americans know ASL on even the most rudimentary level. I certainly don’t, despite decades of alphabet handouts from local charities and a vain attempt by my Spanish teacher in high school to use signing as a mnemonic device. Fewer still would want to learn a sign language with even less use. (Conlangers in general, on the other hand, would probably be as intrigued as for any new project.)

Limits

If you do want to try your hand at a sign conlang, I’m not sure how helpful I can be. I’ll try to give a few pointers, but remember what I said above: I’m not the best person to ask.

One thing to keep in mind is that the human body has limits. Also, the eye might be the most important organ for signing. A sign that can’t be seen is no better than a word you don’t speak. Similarly, it’s visual perception that will determine how subtle a signing movement can be. This is broadly analogous to the difference in phonemes, but it’s not exactly the same.

Something else to think about: signing involves more than the hands. Yes, the position and orientation of the hands and fingers are a fair bit of information, but sign languages use much more than that. They also involve, among other things, facial expressions and posture. A wink or a nod could as easily be a “phoneme” of sign as an outstretched thumb.

Grammar is another area where signing can feel strange to those used to spoken language. ASL, for example, doesn’t follow normal English grammar to the letter. And there’s no real reason why it should. It’s a different language, after all. And the “3D” nature of sign opens up many possibilities that wouldn’t work in linear speech. Again, it’s really hard to give more specific advice here, but if you do learn a sign language, you’ll see what I’m saying. (Ugh. Sorry about the pun.)

Celebrating differences

Conlanging is art. Just as some artists work with paint and canvas, others sculpture or verse, not all conlangers have to be tied to the spoken and written varieties of language. It’s okay to be different, and sign languages are certainly different.

Elimination

The six basic principles of responsible government don’t, by themselves, converge on a single system. Instead, it’s best to first look at those regimes they entirely eliminate.

Necessity

Egalitarianism is, in essence, a lack of organized government. Anarchy is a repudiation of it. Neither is well-suited to the needs of a large, diverse state. Human nature is to be social, and that means forming relationships, whether romantic, platonic, friendly, or simply on the basis of mutual acquaintance. Those relationships can easily turn into alliances, recognitions of shared purpose. From there, it is a short step to self-organization, and then to government. Therefore, anarchy can never be more than merely a temporary state.

Purpose

A government that does not protect the lives of its citizens is a failure. One that does not uphold those citizens’ rights is equally lacking, though the nature and quantity of those rights can be argued. It is clear, however, that some systems of rule are entirely unsuitable. Those predicated on the absence of individuality—Leninist communism, for instance—cannot be considered acceptable for governing a free people. Likewise, those which ignore fundamental human rights—theocracies being only the most familiar example—must not be seen as viable. But even democracy is not infallible, as the tyranny of the majority can be used to strip rights from the minority. Good government, in this sense, is far more than a question of who rules. It also must take into account how those who rule protect those who do not.

Evolution

Nothing in this world is without change, and that includes society. Social mores shift over generations, but a rigid government can fail because it fails to adapt to these seismic shifts. To prevent this, a state must give some allowance to the possibility of radical changes to its structure, to its core tenets. Those that do not, those that remain fixed, are doomed to fall. Again, theocracy, with its strict insistence on dogma and received wisdom, is the perfect illustration. But a theocracy can adapt by reading and interpreting its scriptures in a new light, while a strongly segmented, highly conservative aristocracy may instead resist the natural evolution of culture, leading to failure.

Equality

Every human being is unique, but we all share many things in common. It is easy, common, and perfectly natural to separate humanity into groups based on the presence or absence of a specific factor. However, to institutionalize this separation is to create an imbalance between members of a preferred class and outsiders. Implementing this sort of segregation by intrinsic factors, those we are physically, mentally, or psychologically unable to change, sorts humanity into those who are—by definition—haves and have-nots. This leaves a segment of the population without political power, without the opportunity for redress, and that segment will only seek to find a new outlet for such. Legislative tribalism, in the form of laws motivated by race, religion, sex, or other factors, is a failure of a government to protect (as by the Principle of Purpose) a certain portion of its citizenry. Executive tribalism, as seen in caste systems, aristocracies, communism, and oligarchy, bars this same portion from using its political voice.

Cooperation

Once again, we return to egalitarianism, as it is a prime example of the nature of competition. When every man is for himself, he can accomplish only what is within his own means. A larger conglomeration, however, can achieve greater things. This is because of resource pooling, specialization, and leadership, among other factors, and it is an expected consequence of our social nature. The most striking examples are those grand projects requiring the cooperation of an entire state, but this sort of socialism is inherent in any system of government. That does not require a surrender of all free will, as in Hobbes’ Leviathan, nor is it a condemnation of capitalism. When we accept the role of government, we commit a portion of ourselves to it, hoping that we receive greater benefits in return. It is this equation, in its lack of balance, where the failure of neoliberal technocracy lies. Yet there is equal imbalance in pure objectivism and pure collectivism.

Initial Conditions

The final principle is the most culture-specific, and it is here that one government system—or the idealized notion thereof—is singled out. However, the Constitution itself does not uphold all the ideals stated above. In its original form, it embraced inequality. It made little space for grand-scale cooperation. In accordance with the Principle of Evolution, however, it has changed to reflect the times, the changing beliefs of those it represents. Other founding documents fail a different set of fundamental principles, and in differing ways. They may be suitable as a starting point for deriving a system of government, but few begin so close to the ideal. Wholly unusable, by contrast, are scriptural resources such as the Ten Commandments, as these are defined by their violation of the Principle of Equality.

None of this is to say that these forms of government are invalid. If a people chooses to create for itself a state based on a violation of the Principles, the choice is theirs alone, and it is not for us to assign fault or blame. Those regimes, however, may not endure.

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.

Conlangs as passwords

Keeping our information secure is a high priority these days. We hear a lot about “two-factor authentication”, which usually boils down to “give us your mobile number so we can sell it”, but the first line of defense for most accounts remains the humble password.

The problem, as eloquently stated by XKCD #936, is that we’ve trained ourselves to create passwords that are all but impossible to remember. And the arcane rules required by some services—banks are the worst offenders—can actually serve to make passwords less secure than they otherwise could be. There are two reasons for that. One, the rules of what’s an “acceptable” password restrict the options available to us. An eight-character password where one of those characters must be a capital letter, one must be a number, and a third must be a “special” character (but not those that might interfere with the site’s code, like the semicolon) really only gives you five characters of leeway.

The obvious solution is to make passwords even longer, but that brings into play the second problem. A password like eX24!mpR is hard to remember, and that’s only eight characters. Extend that to twelve (Ty93M@tsD14k) or sixteen (AsN3P45.tVK23hU!) and you’ve created a monster. Yes, muscle memory can help here, but the easiest way to “remember” a password like that is to write it down, which defeats the whole purpose.

The XKCD comic linked above outlines a way to solve this mess. By taking a few common English words and smashing them together, we can create passwords that are easy to remember yet hard to crack by brute force. It’s ingenious, and a few sites already claim to be “XKCD-936 compliant”.

But I had a different idea. I’ve made my own languages, and I’m still making them. What if, I thought, I could use those for passwords? So I tried it, and it works. In the last year or so, I’ve created a few of these “conlang passwords”. And here’s how I did it, and how you can use the same method.

Rather than a few unrelated words, a conlang password is a translation of a simple phrase. Usually, I try to use something closely related to the function of the site. For example, my account on GOG.com is the phrase “good old games”—the site’s original name—translated into one of my older (and unpublished) conlangs. Similarly, my start page/feed reader has a passphrase that means “first page”. My password on Voat translates as “free speech”. All very easy to guess, except for the fact that you don’t know the language. Only I do, so only I can do the necessary translation.

Going this way gives you a couple of extra benefits. Case is up to you, so you could use a phrase in title case for those sites which require a capital letter. Or you can use a language like Klingon, with capital letters already in the orthography. Special characters work about the same way; add them if you need to, but in a more natural way than the line-noise style we’re used to. And since our password is a full phrase, it’s likely going to be near the upper end of the length range, making brute-forcing an impossible task. If it’s allowed, you can even add proper spacing between words, further lengthening the password and frustrating hackers. Also, if the site requires a “security question” (a misnomer if I’ve ever heard one), and it lets you use a custom one, then you never have to worry about forgetting the password, as long as you remember the language.

There are, of course, downsides to this method. Numbers are…difficult; the best option I’ve found for places that make you put one in is a kind of checksum. At the end of the password, simply put the number of letters you used. As an example, let’s say we want to use our example conlang Isian to make a password at Amazon.com. (By the way, that’s a bad idea, as information on Isian is open to all, even if no one’s really looking.) In my opinion, a good phrase to describe Amazon is “they sell everything”. In Isian, that translates to is dule lichacal. Thus, our password could be something like IsDuleLichacal. Fourteen characters, three of them capital letters. And we can take on a 14 at the end to up the strength a little more, or satisfy overly strict systems. As long as you’re consistent, memorization is less of a problem. And you don’t need to write down the password itself; just the key phrase is enough.

Now, not every language works for this. For very good reasons, passwords using Unicode characters are not recommended, even in those rare cases where they’re supported. The ideal conlang for password use is something more like Isian: no diacritics, no funky letters like ə, just basic ASCII. Letters, numbers, and a few symbols—in other words, the same set of characters that passwords can use.

The best conlangs are probably the most English-like in style. Somewhat isolating, but not too much. Relatively short words. A reasonably uncomplicated grammar, so you don’t have to sort through all the rules. Oh, and you’ll definitely need a sizable vocabulary to cover all the concepts you might want to use in your passwords. Just a grammar sketch and the Swadesh List won’t cut it.

Not everybody will want to go through the effort needed for this scheme. But, if you’ve got an extra little conlang around, one you’re not using for anything else, you might want to give it a shot. It can hardly be less secure than the sticky note on your monitor, right?

The axioms

Let us consider the following statements as axiomatic:

Principle of Necessity: Government, in some form, is a construct necessary for the creation and function of any collection of people larger than the tribe or village.
Principle of Purpose: A government exists solely to protect the liberty, health, safety, and well-being of its constituents.
Principle of Evolution: A form of government is not cast in stone, but it must have the potential for change.
Principle of Equality: A system of rule that classifies, based on intrinsic factors, some people as greater or lesser in rights or in being is untenable.
Principle of Cooperation: A society of any size is able to achieve greater feats by working in concert rather than in competition.
Principle of Initial Conditions: The Constitution of the United States is not a perfect document, but it is the best available starting point for enumerating the rights of the people and the responsibilities of government.

This set of axioms should be considered a framework, a definition of the boundaries of a space. With logic and deductive reasoning—two qualities sadly lacking in modern politics—it is possible to derive a system of political thought and a model for governance, one which upholds the principles above while remaining rooted in the practicalities of the modern world.

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.

Fathers

Let me be frank: I don’t have a lot of good things to say about fathers. Mine left over 20 years ago, about a month after my 12th birthday. I haven’t seen him in over a decade and a half, and I’ve only spoken to him once or twice in that same period. The life-changing event of his departure colors all my earlier memories, as well. I only hope that I someday have the chance to prove to myself that I can do a better job.

That’s not to say I know nothing of the subject. I have a stepfather, and that tie that binds us has lasted essentially my entire adult life. For that reason, however, I’ve never seen him as a father in the parental sense. In my mind, the relationship between us is closer to equal.

My grandfather, who passed away in 2012, was also like a father to me, as much as he was to his seven children and the other descendants. Again, though, it’s not the same. He was far older (62 years, to be exact), so I didn’t feel the same bond that exists between parent and child.

In the media, fathers fall into a few broad categories. There’s the abusive alcoholic, the saintly sage, the blue-collar buffoon, and the vaguely man-shaped void that appears far too often in life and art. Characterizing a real, living man in such a way diminishes him, though. I understand the needs of the medium, but how hard is it to give depth to such an integral part of a family, especially in a story centered on that family?

I can’t say I’m an expert on fatherly affection. It’s something I’ve been denied for so long that I’ve all but forgotten what it’s like. But that doesn’t mean I can’t hold opinions on what it should be. Fathers should be leaders. They should be knowledgable, strong of body and spirit, yet also sympathetic. Perhaps it’s outdated to say that a father is the head of a household, but he still holds one of the top positions, no matter where you fall on the political spectrum. He should act like it. Fathers have less attachment to their children by design—they didn’t spend nine months carrying them around—but “less” doesn’t have to mean “none”.

If you’re writing a story about fathers, now’s a good time. Yesterday was a day for them. The other 364? They should share them with their sons and daughters.