Why modern game developers can barely develop games? Black-box development might be the root cause…

Published October 30, 2019
Advertisement

(this post was originally posted on medium.com, you can read it there if you prefer.)

 

From time to time I get asked why I insist on the importance learning how shaders work.

I get where this question is coming from.

That’s the wrong question. The real question is “Why do you insists on learning how things work?”.

Why do you insist on learning how things work?

Unity, Unreal and the likes made it quite easy for beginners.

You can finish a game without even knowing that something like shaders exists.

Well, they probably know they’re there but never bother to learn how they work.

Year after year, I see new programmers approach development through black boxes.

Look at the JavaScript library ecosystem to see what I mean.

It’s crowded with cut and paste libraries that most developers don’t even know how they work. They just add the library and use it.

Most developers never bother to see what’s inside.

CLARIFICATION: I’m not saying using libraries is wrong. That would be nonsensical. What I’m saying is that if we don’t know how a library works internally, we’re on our path to doomsday.

This is also true on Unity’s Asset Store. It’s even promoted as a “time saver”. And in a way it is, but it’s a time saver as much as it is a time consumer.

The problem is that black-box development is quite risky in games:

Our games need to run in 60fps (if not more).

That leaves us with only ~16ms to do our rendering. Usually this is plenty of time, but sometimes it’s not. What do we do when it’s not?

Also, we’re used to work with computers with so much RAM that most games will not run out of it. Unless you’re on mobile, embedded or limited hardware.

Usually we don’t use the CPU to do graphics. But if you don’t know shaders, there are a lot of problems that you’d try to solve using the CPU.

That will lead you to a road block where the CPU is not powerful enough (or, to be fair, not designed!) for that job.

I think it’s important to every aspiring game developer to limit black-boxes as much as you can.

Use the Asset Store, use all the tools at your disposal, but learn the way things work.

If you don’t you’ll end up limited by an otherwise limitless technology.

For starters, you should know how to answer these questions:

  • How do graphics card work? Why do we need one? What’s the difference between the CPU and the GPU?
  • Why something may be allocating so much dynamic memory every frame? Why is that a bad thing?
  • What’s the meaning of the sample rate of an audio file?
  • What’s an affine transform?
  • What’s the CPU cache? How can I leverage it?

The list can go on for ages, but if you can’t answer these things, my suggestion is that is time for you to start investing time in learning. Spend time in getting better. Why?

A case for getting better

You can probably say “I’m already creating games with Unity, why do I need more than that?”

As explained by the Self-Determination Theory, human motivation (and happiness as a consequence!) is driven by three main factors:

  • Autonomy: You need to feel that you can self-determine what to do, that you have choices and you’re making decisions.
  • Relatedness: You need to feel connected to your motives.
  • Competence: You need to feel challenged. You need to feel like you’re valuable to the cause you’re working on.

By being a black-box developer, you’re effectively limiting your progress on the first and third of these factors.

Autonomy suffers from black-box development because you’re tied to the design decisions of others: Unity, the asset creator, etc.

Competence suffers because you don’t learn how things work and therefore you don’t become more valuable.

The followup question might be, why do I want to become valuable?

Career Capital Theory

In his book So Good They Can’s Ignore You, Cal Newport suggests that Carrer Capital might be the way to loving what you do.

"If your goal is to love what you do, you must first build up “career capital” by mastering rare and valuable skills, and then cash in this capital for the traits that define great work." — Cal Newport, So Good They Can't Ignore You

When I read that book many years ago, many things that I felt during my life clicked immediately.

This is why it’s so important to be good and understand how things work.

By being great at what you do, you’ll have access to work on the most interesting things out there.

You’ll become surrounded by the most interesting people out there.

You’ll never get bored and rely on empty things to kill time.

It’s important because it leads to happiness.

Why are you writing all this?

I’m going to be sincere. I have an ulterior motive. We all have.

I want as many people as possible to be aware of what I’m doing.

Currently I'm working on a 2D Shader Development book series, but my goal is to help people to open the black-box and live a better life as game developers.

I’m currently running a giveaway before launching my third book. The prize is 1-year of Unity Plus. Which gives you access to Unity Learn Premium.

If you got moved by what I said in this article, I strongly suggest you become part of my mailing list by joining the giveaway, as I will be discussing these topics and compile as much knowledge as I can in order to become great at making games.

Hope to see you there!

1 likes 1 comments

Comments

MagForceSeven
To a certain degree I get it, if you're going to be using a tool you should understand how that tool works. I just don't think it's a truly reasonable approach, especially for game teams that have very few members. It's a depth vs. breadth problem and as with anything else in CS it's a trade off between extremes.
 
As much as I'd love to know everything about everything, it's just not possible. As two cases I can learn 100% about one thing or 10% about 10 things. In the first case I would probably make an amazing member of a team making a game but I couldn't do it by myself. But that doesn't mean there's anything wrong with the second case where I could still be an awesome member of a team and maybe make a game by myself or in a much smaller team. If that 10% of 10 things gets me 80 or 90 percent of the way to a finished game, then it doesn't matter I didn't understand the fine details of the shader compiler if it never mattered. And as long as I'm not making boneheaded sorts of algorithmic mistakes (I'm looking at you n3 loop) I'm not going to worry too much about a frame rate problem before I have one.
 
Professionally, I have a lot of black boxes. I ignore a lot about the graphics stuff that goes on, including shaders. And I have that luxury because we have dedicated graphics programmers who make it there mission to know it all.  As a hobby dev using Unreal, I learn just enough to move forward in the things I want to do. This doesn't make me a bad programmer any more than it makes any of the graphics programmers bad because they don't know the first thing about how the AI library might work.
 
Black boxes are important, they reduce cognitive load and allow people to do the challenging and motivating work they care about and not, for example, learn the intricate details of the JSON parser they want to integrate into their project but don't really care how it does it's work. Even in your clarification you suggest that one should know how the libraries you use work internally, which to me defeats the purpose of them. Sure, you should be able to understand things like the time and space complexity or the thread safety-ness of the library but you should be able to get that sort of understanding without knowing details of the implementation.
 
In the end, I think that if you set the bar as "you can't use a library/engine unless you know how it all works", you're going to spend more time trying to understand your tools than using them and I'd rather be using them.
October 31, 2019 03:47 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement