Note: This article is intended for indie game developers or also gamers interested in the technical side of things.

I think usability and user experience is something easily overlooked in games. I want to bring up Kerbal Space Program here which I started playing again. While this game can be extremely fun, it is definitely is not ideal in terms of usability. There is a certain amount of time and energy you have to invest in order to play it at all. The biggest issue are structure and size of the control buttons on the interface and the fact it is difficult to tell what you have to do in the first place. This makes for some high entry friction and a steep learning curve. In part, this is due to the game's complexity. 

But does a game deals with a complex subject matter also have to be a pain to use?

Usability also applies to Developers

If you have a big software or game with a lot of features, complexity needs to be packed into small units. This both applies to the user interface and the code base itself. Often if an interface is muddled, it can be an indication how the underlying code base looks like - Or that the  requirements weren't formulated in a way that is clear and easy to understand for a developer and also for the end user. 

The reasons for this can vary greatly. But in either way:

Someone who does not possess clarity over a piece of software, will not be able to reproduce clarity. 

Ergo, development processes have to be designed for ease-of-use for the developer as well in order to carry on the usability torch to the end user. 

Usability of Code & Architecture

Note: Software Architecture usually refers to how multiple software systems, however in a game development context, it is more the of how the code itself is structured.

So to get the best usability out of your game, you can apply the FOIT principle (which I totally didn't just made up)

• Formulate clear requirements, split in small chunks to abide the single responsibility principles early on
• Organize: pick the best internal structure for these requirements, using the language tools your programming language of choice provides to you (modules, packages). For AstraX, I have one package per mechanic: Resources, Docking, Discovery.
• Implement in small chunks, that means a lot of classes if using OOP. Use known programming patterns that fit the requirements best (factory pattern, listener pattern, MVC).  
• Test: have as many quality assurance methods in place as possible (e.g. automated testing, code analysis, regular manual testing periods)

These measures, inspired from traditional software development, will help keep the internal code quality of a game high and technical debt low. The downside is that a considerable amount of time and effort goes into these, which slows down development - at first. 

But: after a certain time period, any software will thrive in long-term and will allow developers to work faster, compared to software that does not posses high internal quality. Legacy software in enterprise environments often has so much technical debt its development time converges to zero. 

If you encounter any game in the wild that was never finished or has slowed down development by a lot: this is typically why.

To illustrate what I mean, here is a graph from famous software engineer Martin Fowler's blog (his book "Refactoring" I recommend to anyone who's interested in coding as craft)

As senior developer only looking at the surface of software I can tell that both quality assurance and architecture is an enormous deficiency in many games. One could go so much further with a game that had adequate architecture. But a lot of games never manage to go there because of bad design, low quality, or a lack of awareness for the two.

Games that in my perspective managed to get the best out of themselves via aforementioned methods seem to be Subnautica, Don't Starve and Hades. A negative example would be ARK: Survival (don't even get me started).

Interface Usability

When designing an interface, game developers can learn a lot from web technologies. Libraries for Angular such as PrimefacesNG or ClarityUuse established usability patterns and components that come with them. Even without training in the UX/UI field, it is beneficial to try to incorporate these into games in order to make a game that is fun and easy to use.

Another way to improve usability is to test and play your own game thoroughly, particularly as a solo indie developer. Take notes as you notice anything that takes a bit of effort for you. Also take note of any player feedback you may receive! Even a small comment can hint to something bigger to improve.

Dangers of Overengineering

Another issue that plagues (game) developers is the tendency to overengineer software. If you really enjoy what you're doing and see it as some kind of intellectual challenge, you may end up solving problems that aren't even there. Or you start solving a problem that you already solved elsewhere. That way you may end up with a complex solution to a relatively simple problem. Worst case, this unnecessarily added complexity can be a death sentence in the long run, particularly if these decisions happen early on in development when the system is new and fresh.

However: a problem needs to be analyzed, your current code base evaluated if it doesn't already solve this problem, then the most simple and elegant solution needs to be chosen. What sounds really easy is actually quite difficult and takes a lot of experience and practice to master.

Looking at all my unfinished projects, I am guilty of this crime too, but it is something I grew out of.

AstraX and Usability

For AstraX I started out with a lot of classes, each with a small and well-defined scope, often just possessing one or two methods. It took a while to get used to, but this finely chopped code structure really paid out in the end, as I can just rearrange functionality as more features are added. This particularly holds true for the generator, which is driven by its data model.

Because the code base is so flexible, it allows me to improve usability for the end user and still maintain a relatively high development speed.  Development speed is majorly affected by the amount of time I invest into this game personally, which can vary strongly as hobby game developer.

Over course of development, UI-components in AstraX got entirely re-created multiple times for the sake of improving user experience. This is possible because the data model is decoupled and independent from the user interface logic itself. The connection between the two is established via event listeners that manage data synchronization. I only have to change some code in those listeners if I make large changes to the interface, the rest of the code stays the same.