I'm directing an indie game at the moment. I think programming and art skills can be both be valuable, depending on game and genre and so on, but I strongly agree about artists having a better perspective on game production. They understand that games are content and most of the work goes into content creation. Sometimes you discuss adding two characters and the programmer is thinking I can just share the movement code while the artist knows it's at least weeks of work to create all the art, same goes for sound, writing, and game design.

The highly automating/efficient mindset of programmers is great but even small games are big pieces of art that require a lot of diligent labor that you must expect and respect.

And of course, your point is that no one sees programming in a screenshot or trailer.

Totally fine to paint in broad strokes, and I would probably lean towards that perspective myself. However there are some games that show off the programming more than others, at least in motion. Movement based games, like technical platformers or similar, have a lot of expression through the systems that govern them. Whether or not a game feels good is fairly easy to figure out after spending some time with it, but understanding what would make it feel better and how to achieve it is a much harder skillset to develop. Obviously non-programmers can work out in high level terms what might improve game feel, but I think you can get much better results when you have deep understanding of how things work, what's possible, and what side effects may fall out of a given change.

That said, some of the most fun mechanics are born out of happy accidents involving interactions that weren't fully considered so it's definitely not a constant

I am being broad but to be more specific, if we classify games across two dimensions, one being tall (aka systems) versus wide (aka content), then I can't think of a single game that is more tall than wide. At best you get games which are squares, like tetris and pacman where a small amount of systems and a small amount of content go together.

For the vast majority of games they are very wide. Including technical platformers, which will have very finetuned movement systems, but they must be accompanied by a lot of equally finetuned levels. Another way of seeing it is that content is the "space" which your systems are expressed in, and more expressive systems require more space. A complex combat system will demand more enemy characters for its complexity to be relevant.

But I was only speaking in terms of programmers' understanding the nature of game production, rather than their actual contribution to the game. Of course there are very programming forward games, and entire genres driven first and foremost by innovative gameplay code. But even in those games and genres the programmer must understand that on top of the unique features that are being programmed, most of the important work will still be content creation. It's the nature of the beast. I'm a programmer who had to learn this the hard way. It's nothing like a software startup. It's more like a movie production with a software project inside.

I think this is why there are so many "Learn Hiragana and Katakana" apps and websites. As developers we gravitate towards the known quantity (e.g. web/app development) rather than the amorphous "learn to write Japanese" goal. I am part of this cohort.

Agreed, but I also think people just underestimate the breadth of language. I think a common exit point is after feeling like you've learned grammar well through your materials, you hit real world content or native speakers and realise you didn't know a single word or phrase. It is really disheartening, but on the flipside the first time you start to understand it will be an electric feeling. Quite addictive.

Japanese isn't that hard to write though. Especially kana. yoou can learn to prounouce those in a week with flashcards (I did so in high school) and honesly, making your own flashcards are good writing practice. Even Kanji is surprisingly structured in how you write the strokes after you do a few hundred.

Now, reading kanji... that's where the pain begins.

Kanji's a lot less daunting when you realize they're words not letters.They convey ideas instead of sounds (heck they don't even really convey a single sound considering the number of readings)

There are like 220 hiragana/katakana. You can't learn those in a week.

Reading kanji is easy, the problem is looking them up. Jisho has a terrible kanji recognition engine. The one from sljfaq.org works amazingly well, but it is not a dictionary so you have to ugh, copy every kanji by hand, making the process take forever for each word.

> There are like 220 hiragana/katakana. You can't learn those in a week.

They're less than 50 each, plus a few diacritics. I did learn hiragana in 3 days, it's that easy. One just need motivation, and practice. People failing at it just don't put the work. Heck, I can read more thai letters than a relative who lives there for years and is "learning" the language because I sat and took a few hours to practice.

You seem to have intrinsic motivation to learn languages, whereas your relative probably has extrinsic motivation - looking for a punishment or a reward (E.g. I have to learn it because people here use it. If I don't...)

> Making a game engine is a very concrete task, in that you can map out the steps and many of them are well-defined.

This doesn't sound right to me. Surely making an engine has thousands of different choices to make and thousands of rabbit holes to get lost in.

Sure there are tradeoffs but they still are concrete decisions. Do I care about X or Y more.

Making a game fun is a bit of a black art. A little more juice (screen shake/SFX/etc) can make the exact same experience otherwise a lot more fun. An interesting recent example of this for me is playing Witchfire, a 1st person single player extraction shooter that just came to steam in early access. One of the bolt action guns once you level it up makes a bell sound with every headshot that makes it feel incredibly epic, along with the benefits headshots give for that gun.

In comparison, it's a concrete task.

There's pretty much no rules when it comes to making a game. Versus with an engine, you at least have some requirements and guidelines. It's gotta render stuff, do physics, etc. With a game you could literally do anything, and 99.99% of all stuff you can do probably sucks and isn't fun. So you have to really be willing to throw ideas away.

There are just so many good examples. If you get stuck or aren’t sure you at least have safety rails.

> Making a game engine is a very concrete task

To me it means playing with tech without making anything that’s useful. You can’t make any design tradeoffs without a game in mind.

Every engine I’ve seen written in isolation gets immediately gutted as soon as it needs to make something work.

First you hack through all your abstractions to get the critical path up and then you essentially write each feature again.

The reason is quite simple. You need to be a writer, an artist, map designer and a musician if you want to make games. If all you know is writing software, then working on an engine is less asset intensive.

That is absolutely correct, and that’s why I have always, in my free time, written engines and frameworks.

I envy the creator of Stardew Valley; he programmed, designed, wrote, and composed the entire game by himself over his 5 years of development.