1. Storytelling, dialogue, worldbuilding and atmosphere

What makes games, games, is that they are interactive. The game should leverage that by making heavy use of environmental storytelling. There should be very few cutscenes and small amounts of high-quality, impactful dialogue told by complete, unique characters. Etching a key part of the story into a wall in an optional dungeon in an ancient language that can only be translated with an optional book is better than a character standing next to the entrance waiting to dump exposition on the player (or worse, tell a quirky, milennial one-liner). Carefully placed books, notes, objects and creatures in certain locations should hint at what might've happened at those locations. Item descriptions should concisely describe events or characters pertaining to those items. If the player has to figure things out, pay attention, explore the environment and obtain loot, the player will feel rewarded and trusted, as well as motivated to keep playing, re-play the game or even explore and discuss the story further outside of the game.

As far as player agency goes with regards to story, a combinatorial explosion where the player can affect every little thing invariably leads to unrealistic, unsatisfactory scenarios, ludo-narrative dissonance and low-quality story. On the other hand, not being able to influence the events goes against the spirit of an RPG. I am partial to a system where the player doesn't influence much throughout the game, but is able to select some endings based on some things they did or did not complete.

2. Exploration and world design

Interconnected, non-linear, open-level design, please. The player has a clear objective and some reasonable boundaries, but is nevertheless given a high degree of freedom on how to approach that objective based on their playstyle. The player can also decide whether to rush through the level or fully explore it and be appropriately rewarded for it. This style of design should be rich in optional areas, secret areas, alternative routes, locked doors, traps, and carefully placed enemies and loot that serve as hints on where to go. Some groups of levels should be order-agnostic. This provides the player with high amounts of agency, but not so high that they are distracted and overwhelmed by unrelated, low-quality content, as is the case with fully open worlds. There should not be an in-game map, the world should be learnable by heart, and the game should facilitate that learning by creating backtracking sequences that make sense and don't feel like a waste of time. To facilitate that, the game should reward exploration with shortcuts, and should not allow fast travel until most of the map has been explored. Furthermore, the player should be intrinsically motivated to explorate. While loot can serve as a guide, and a cherry on top of the cake for finding a secret area, the player should be primarily rewarded through a beautiful view or learning something new about the story.

The atmosphere of the world is also tremendously important. The artstyle needs to be cohesive and compliment the story and gameplay. Music should be used sparsely and match the emotion of the area or state the player is in. Care should be put into the sound design and the player should be able to use sound meaningfully.

Quests should not be present in the game. To be clear, characters should send you to do meaningful things for them and offer a reward, but there should not be exclamation marks above their head or instructions in a quest log. Dilligent players that learn information by interacting with the world should be rewarded.

3. Difficulty, combat, progression

I enjoy tactical combat as much as the next guy and I think there is, and should be, a market for tactical RPGs, but strictly in the context of "my dream RPG", I have to go for action combat. I believe action combat rewards skilled players and immerses players in ways that tactical combat just can't, and since modern hardware is well capable of action combat, I think those capabilities should be utilized.

To that end, combat should not feel clunky or sticky. The game should react to the player's input immediately (aside from mechanics like stamina or stagger) and the controls should not be confusing or counterintuitive. Hitboxes should be placed and sized carefully so that the player never feels betrayed. Ambushing or overwhelming the player might be okay depending on the specifics, but the game must ultimately make the player feel like they are fighting on fair grounds. The game should feel difficult, but never rigged. The difficulty level of the game should be tuned such that players will feel accomplished after a combat encounter. The difficulty level should only be adjustable through diegetic means, like some clever strategies being overpowered. That way, the player still at least feels rewarded for finding them. A successful dodge or parry should not result in health loss, and all attacks should be dodgeable or parryable, such that the game can be beaten unharmed and at any level of progression by extremely skilled players. The world must not scale to the player level. The game should punish players for dying, but should avoid masochistic tendencies and artifically wasting time.

As for the specifics of the combat and movement, the player should be given a simple set of moves from which complex sequences can emerge. Walk, run, attack, special attack, jump, dodge, parry, use equipment. Attacking after running, dodging, jumping, or parrying may do something special. Attacking multiple times in a row with some set amounts of delays may result in a combo. If the enemies are difficult enough to force the player to learn the moveset and utilize it to it's full potential, the players will create the flashy and smooth moments themselves, and they will feel infinitely more rewarded for their skill than systems where complex, flashy abilities are hidden locked behind level-ups and subsequently available in combat automagically at the press of a single button. Spells don't need to exist in the game as an extra system. Spellcasting staves, books or talismans that can be equipped as weapons and conform to the aforementioned moveset rules are sufficient. Similarly, parkour sequences/level traversal should not be automagical. The player should learn how to make good use of their jump button.

Under this system, simple, archetypal builds like fighter, rogue or wizard should not really even exist. Building a character in this game should revolve around creating a unique experience and approach that can't be easily boxed into a DND class. To facilitate that, the progression system should be high consequence and impossible to boil down to mathematics. Regardless of whether the progression is presented through skill trees, charms, weapons, gear, something else, or any combination of these, they should always change something fundamental about the player's approach to combat. "Your quick attack cleaves" rather than "+10% to critical hit chance". In general, most of the progression should push the player sideways rather than forward, unlocking optional or alternative gameplay. The player should rely on skill and the playstyle and moveset they chose to beat more difficult enemies.

Crafting should exist but should be sparse and meaningfully integrated into the progression system. Defeating powerful bosses to obtain rare crafting materials to craft a cloak that unlocks an alternate dodge move while wearing it is good. Sitting at a campfire to craft 50 healing soups is bad.

The game shouldn't have companions. Computer controlled allies suck.

2. Indirections are most often more expensive than whatever you are trying to prevent by adding an indirection

3. Dependencies are most often more expensive than whatever you are trying to prevent by adding a dependency

4. Complexity hidden behind a procedure call is complexity nonetheless

5. Architecture emerges from code, not the other way around

6. Most things are simple to change. Data structures are not. Consider them carefully.

7. Thinking about computer programs from a very high level or in an overly abstract manner is most often unhelpful

8. All programs are, in essence, a set of instructions operating on data. Reasoning that strays too far from this definition is most often unhelpful.

9. Architectures or design patterns with a fancy name and a catchy abbreviation are most often extraordinarily unhelpful

10. If you value simplicity, then if someone is getting paid in any way for giving you programming advice, you most likely shouldn't listen to that advice

11. If you value simplicity, then you should stick to the fundamentals and avoid most trends, particularly those that promise to be revolutionary

12. Files and packages exist to split code at meaningful interfaces, not to keep things neat and aesthetically pleasing. If long files or a flat file hierarchy are causing you trouble, you need a better text editor

13. Your workflow needs to be simplicity-oriented too. If you are constantly waiting for an IDE to stop lagging or for a build to finish, it's hard to get anything done

14. Over time, most simple code degenerates into complex code. Whenever it happens, that code needs to be revisited promptly, because complexity spreads quickly

These are all my personal learnings and may or may not apply to any other person.

1. Inspiration is mostly harmful

The initial dose of inspiration that sparks a bunch of ideas that I can then take and work on is tremendously important. It could be something I've seen in nature or a game I've played recently. However, consuming similar media to the one I am creating to find solutions to design issues or ideas to implement is not very helpful at all. I find that it poisons the quality of the original ideas I have or may have had. It also triggers a comparison reflex in my head, and as we all know, comparison is the thief of joy. I think the best strategy is to distance myself from similar media as far as possible after the initial surge of inspiration.

2. Finding the right amount of consistency

As Stephen Vizinczey said, consistency is a virtue for trains. Even though he was talking about philosophy, I think it applies to design and programming work too. It's not always possible to be truly productive and solve hard problems, say, at 8:00 every day, at least for me. The solution is not so clear to me though, as working whenever the brain feels like it also doesn't feel great. Not that it would be a problem from a productivity or time-management perspective, but not being bound to a routine does unpleasant things to my brain. I suppose the right balance is somewhere in the middle, but I haven't truly found it yet.

3. Don't overdo it with innovation

I severely underestimated how tiring it is to invent completely new mechanics for a game. Not only are they tricky to design in a fun way because you are doing it without any reference, it's also a wild guess as to know whether people will enjoy them without having access to a hefty amount of playtesters. In hindsight, it's probably more optimal for a solo-developed game to have a small to medium amount of innovation grounded in other, more conventional mechanics.

4. Avoid becoming your project

There were times while working on the game when I would be feeling seriously upset if I didn't manage to implement a feature, and elated when I did. This is what I call "becoming your project" and it's tremendously unhelpful for both work and mental health. It's difficult to avoid this toxic relationship with your project if you truly care about it. As far as I can tell, the most effective way to avoid this issue is to remember to be a real person outside of the project, have hobbies you also truly care about, talk to friends, work on mindfulness, and remember to zoom out.

5. Try out a lot of different things before committing

Due to my particular situation, I didn't have as much time as I would have wished to select the project I'm going to commit to. As a result, I'm not entirely sure I made the game that I myself really love. Don't get me wrong, I enjoy playing it, and I genuinely think it's a good game (to the extent that I can rate my own game), but I probably would have made something closer to my heart given another chance to think it through.

6. Consider your playtesting prospects

This one is going to directly contradict the previous point in which I suggest making a game for yourself, but I never promised this list would make any sense. Let's face it, unless you are famous, or have a lot of money, it will be hard to do live playtesting with the correct audience. Yes, you can do playtesting with randos from Reddit, but that's hardly the same quality. Therefore, it would be a good idea to make a game such that your friends are the target audience (I didn't), which will give you easy access to quality playtesters. This may not apply if you suspect that your friends are not honest or would sugarcoat feedback.

7. Understand the type of marketing your game needs

Broadly speaking, there are games that are marketed by screenshots, and games that are marketed by gameplay. My game is decidedly in the latter category. I wasted a lot of time on a "Coming Soon" Steam page with a shiny trailer and screenshots, which, needless to say, didn't generate a lot of traction, because my game is not particularly stunning visually. In fact, within a day of releasing a demo, I accrued as many wishlists as in half a year with no demo. In retrospect, I would basically not bother with marketing at all before my demo release considering the type of my game.

8. Banish regrets

This is not so much a learning, but a word of encouragement, for myself and anyone who can relate. As you can see, I messed up quite a few things, but this post is not called "mistakes I made developing a solo game". After all, mistakes are just learnings in disguise! I have also done a lot of things correctly, but those are not worth writing about, because there is not much to learn from those. Could the game be even better had I done everything correctly and the development process had gone a lot smoother? Well, of course, but there is no point thinking about that. The only thing to be done is to learn and do better next time.

Shameless self-plug

If all this made you curious about the game in question, you can find it here. It's almost finished and the demo will come out soon^TM

I think that is a nonsensical question asking about a nonsensical concept.

Let us examine a common kneejerk reaction that almost all of us had at some point when asked that question. If the universe is deterministic, then every event that has ever happened and will happen was predetermined at the beginning, and thus we cannot have free will. If the universe is probabilistic, then everything that has happened and will happen is random, thus we cannot "have" free will. Even if we avoid pondering the nature of the universe itself, our lives are basically shaped entirely by our environment - our parents, our friends, an endless stream of ads and content. Thus we cannot have free will. The kind of person we are is a result of either design or randomness, and what kind of person we are is going to determine what decisions we make. Thus, you guessed it, we cannot have free will.

See the problem? Not only does this kind of thinking carry unfavorable implications concerning reward and punishment, but it is also entirely irrelevant to our daily lives. After all, when was the last time you felt determinism making a decision for you? In fact, what does truly having free will even imply? The ability to make decisions independent of previous events and external context? That's not something that can conceivably exist, and so it's unsurprising that thinking about it leads to convergent and frankly rather unhelpful conclusions.

We should try a different perspective. I think a much more apt phrasing is whether we experience free will. That shifts the discussion from arguments on whether free will empirically exists, to something that is actually tangible and applicable to our daily lives. Actually, we should go a step further and let go of "free will" too. There is no point in using that term if its very existence is impossible by definition. Not to mention that it's a very overloaded term anyway. I much prefer the term "volition". With all our changes, the question now becomes: do we experience volition?

Even if it may seem like pointless semantics, that is a huge difference. With a simple change in phrasing, the determinism of the universe and volition now became compatible concepts that can be reasoned about separately, which makes the discussion simpler and more relevant. Rejoice! Now, whether we experience volition is not something I can answer for other people. I know for sure that when I go to the store, I can decide whether I buy the apple juice or the orange juice. I can decide what kind of games I make, I can decide whether to spend my time doomscrolling or meditating, and I can decide whether to pick up the random trash I see on the street on Saturday morning. Even if all of my decisions were predetermined at the beginning of the universe, it has no effect on my experience of volition. Imagine a computer program in a made-up programming language that goes like this:

Of course, the program is deterministic. Every single output for every single input of this program is predetermined at the time of writing the program. I can know for sure that if I input the number "2198128", the program will output "x is even". If I input "3", the program will output "x is odd". However, the program is still making a choice. If you were that program, you would look at x, and decide, by your own volition, whether to output "x is even" or "x is odd". You wouldn't know that you were programmed to be that way. This is exactly how humans operate, except that instead of one input x, we take in trillions of past and current inputs. There may be a universal architect or some other power that created the world such that when I'm presented with a certain trillion-dimensional matrix of inputs at this exact moment I will make such and such decision. Regardless, I still experience making the choice myself.

Somehow I feel that this kind of reframing is not really more satisfying to most people than the original empirical thought process. It feels kind of dirty. Like wrapping an ugly piece of code in a function call and putting it in a separate file so we don't have to look at it anymore. Still, I think there is something beautifully humble about this experience-centered approach.

So, why can't AI replace me, specifically, and what do I even mean by that? Quite simply, AI can't experience the satisfaction that I do when I look at the 20000 lines of questionable quality code that apparently constitutes my game, and by some miracle of God does almost exactly what I imagined it would do before writing it. AI can't experience the juxtaposition that I do when I feel like a champion for finding a bug, but also realizing that I am a fucking idiot because I put that bug there in the first place. AI can't experience the somewhat cathartic state of confusion that I do after a 14-hour coding bender, nor can it experience the relief I do when I immerse myself in a deep meditation session to clear my head afterwards.

AI can't experience the bizarre sensation of thinking, speaking and dreaming code after losing yourself in a difficult problem so deep that the only conceivable way you can solve it is in the shower. AI doesn't have memories of first learning programming in Delphi at the age of 10, and it quickly becoming one of the few respites from what I thought back then was an ugly, ugly world. AI can't experience the sense of community that I do when I watch a Recreational Programming video and see so many people blissfully nerding out over the same things as me. AI will never understand that code makes me happy, sad, satisfied, bewildered, horrified, euphoric, and more. AI can create value, but it cannot possibly create art, as long as the definition of art includes some sort of intention, meaning, interpretation or experience with a journey behind it. And for me, code is art. That's just it.

• people's identities
• airplanes, cars
• warehouses, factories, offices
• medical equipment
• videogames, social media
• distribution and archival of knowledge
• distribution of books, series, movies and porn
• et cetera

Anecdotally, it is very hard for me to even imagine living without software at this point. Where I live, everything has been digitalized, and I don't even remotely know how to register an appointment with the doctor or buy bus tickets without my phone. If I would like to find out, I would have to search for it, on my phone. Through a set of circumstances I am currently living in a city alone quite far from all of my close friends and family, and I rely on software to stay in contact with them. I pay with software and the number that represents the amount of money that I "own" and can spend on food is also dependent on some highly questionable software. I watch YouTube videos instead of cassettes and I don't play with Lego, I play videogames. Software has become such an existential and fundamental part of the human experience that it really, really doesn't make sense to think of it as a separate thing from our lives anymore, and that has implications. By the way, philosophically, everything "digital" is really "physical" anyway. The silicon is tiny and arranged CPU-wise, and the LEDs are tiny and arranged screen-wise, but it's about as real as it gets. The term "real life" when used to describe everything that doesn't happen in a computer seriously rubs me the wrong way, but I digress.

The amount of abstractions (including LLMs) used by the average programmer also seems to be growing quite rapidly, or at least has been until recently. Understandably so, since abstractions are great. They ostensibly allow us to be more efficient, because we can skip solving all the difficult technical problems, and instead we can jump right to implementing the meat of our hot new business or game idea. There is however a caveat to that: if people are not forced to solve something difficult, they will generally avoid it. Logically, then, the number of programmers that learn the fundamentals and understand the computer they are programming for is decreasing proportionally to the increase of abstractions, and we collectively decreasingly understand the thing we increasingly depend on.

Whether you are in the "software is in decline" or "you're just wearing rose-tinted glasses" crowd, some simple logical deduction should at least nudge you towards the former. After all, if we understand it less and less, how can it not be in decline? This should be a little bit alarming, because as established earlier, software is pretty important. Software declining so much that it becomes unbearably slow and unreliable as we add more and more abstractions is already something most of us should strive to avoid if possible, but what's worse, we don't currently have any mechanism to prevent our understanding of software from reaching zero. That may take a very long time to happen, or it may not happen at all, but if it happens, the consequences could be anything, including things like, say, total downfall of human society. As unlikely and pessimistic as that sounds, it has happened many times before in human history, and we should not be so arrogant to think that we are now somehow impervious to it. The Wheel giveth and the Wheel taketh.

Now, don't get me wrong, I'm not pointing fingers and saying that everyone who uses a hefty amount of abstractions is stupid or evil and actively seeking apocalypse and we the good guys need to stop them. Some are evil; as a game developer that sometimes makes the deeply regrettable decision of participating in online discourse, I've been called "delusional" on multiple occasions for insinuating that I don't use a game engine. Those people have a desire to utilize every shortcut necessary to finish a project as fast as possible, minimize quality, maximize profit, and worst of all, learn nothing along the way and also bring you down with them. Thankfully there are not that many people of this kind, so let us ignore that as we cannot change it. Most people belong to a second, much more pleasant group, that we can very much do something about. They just want to program in peace, use whatever is the stack of choice at the company they work at, get paid, not worry about the consequences of their code, or whether it even has any.

So what do we do? Well, by no means do I suggest that "we all program in assembly" as the so-called "software engineers" like to remark amidst dependency injecting their javas, or something. Some amount of abstractions is absolutely necessary for human progress. Overcorrecting would be just as bad in this regard. Everyone uses abstractions, and there's not much we can, or should do about that. Luckily, all we need, as long as we are only aiming at the latter of the aforementioned groups, is a moderate dose of mindfulness. We can think about how many abstractions we use, and how responsibly we use them. We should be grateful for the work of the giants whose shoulders we stand on and spend time to understand the code we are using. We should reinvent the Wheel.

I will say though, that this kind of approach is much more realistic and enjoyable if we are writing code for something that we care about. That's why it's imperative that provided our employment opportunities, we do our absolute best to select one that we care for a lot, and have enough agency in it to make any kind of difference. Self-employment is even better, given that our financial situation allows us to weigh the fate of human civilization higher than the time-to-market of our new product. Lastly, keep in mind that writing a game from scratch in Vulkan right away is not necessary. If the next-best-possible-thing is using Raylib instead of Unity or Unreal, then do that. It's also important to realize that unless you're pressed for money, there is no shame in a long development cycle. Quite the opposite. Late is once, crap is forever.

If you think this whole ordeal is just doomsaying, or you just couldn't care less, I still have something in it just for you. Whatever it is you are working on may very well end up much better when you make it from scratch. The human brain works amazingly well under constraints. Also, if you ever have days during which you suffer from the dreaded "Microsoft employee-tis" and can't get any work done, leaning on the fact that you are contributing positively to something might help you get over that, sometimes.