Career Planning & The Knapsack Problem

A few days ago, in a students meeting, the Big Question for every game developer wanna-be was raised:

Which [programming language/audio software/whatever] should I learn to work in the video-games industry?

My relationship with game development is, at best, second hand*, as, although I know people who have made it into the business, I am myself trying to open that door. So I explained which would be the answer for me and which was for those I know who are now developing video-games as a job. Afterwards, I made clear that the actual response, although dependant on many factors, is in the end always a personal choice. But I kept trying to find a better answer for the future.
As of late, I have also given some thought to the knapsack problem. In my mind both met and produced a (mostly irrelevant) revelation:

A career path towards any desired position can be represented as a variation of the knapsack, known in gaming circles as the most common and recognizable of RPG mechanics: "the Diablo inventory system".

Only that, instead of weapons, potions, robes and scrolls, you store subjects studied, software mastered and projects finished. Each takes a certain space and time, and has an associated value of "usefulness" towards reaching the goal.

What is the equivalent of a seal? Beating John Romero at Quake?

When you start your ascension on the game development ladder, you are required to fill your memory, bookshelves, hard-drive and time with all kinds of knowledge, practice and conversations. Every new thing you learn takes a certain space in each dimension of your life and has a future value. They can also be replaced with improved versions (Basic C++ can be forged into Advanced C++), or can be a requirement to obtain another latter piece of equipment (Model Rigging lvl. 1 can only be obtained after unlocking Model Animation lvl. 3 and 3D Modelling lvl. 2).

So, when trying to become a video-game developer, one must consider carefully what to put into the sack, taking into account which position one ultimately aspires to. All intermediate jobs required to reach the target are also equipment needed. On the other hand, positions not actually needed and people you know can ease your way up. Just like an Iron Scepter +4 can get you through an icy dungeon in a breeze, even if it does not exploit fire weakness.

But, despite the similarities, even RPG gamers used to almost optimally solving knapsack problems of considerable complexity (several stats, shifting circumstances, etc.), fail to put their experience to use when trying to break into the actual development business. Why is that?
First of all, nobody realizes they are facing that problem. In a game you know you need to sort your equipment because it is in front of your eyes. In real life you have to figure out there is a puzzle, to begin with. Most of us fail to see the actual nature of the problem because we usually think the Big Question has the One Answer. But no heavenly voice will ever reply "LEARN MAYA" or "REVIEW YOUR CALCULUS".
Second, in a game it is usually easy to compare two pieces of equipment. An Axe +40 +1D6 is usually preferred over a Dagger +3 +3D6, even if the dagger is twice as fast and takes 2 squares less in your inventory. But how do you decide if a course on Maya is more useful than studying algebra? Their respective values is established by those screening you for each position, and you might not get access to that information until much later in the adventure.

Thus, in the end, my first recommendation to anyone aspiring to work in the game industry (or any other thing, actually), be it as a programmer, artist, designer or whatever is, as I was once adviced:

1. Estimate the value of each possible subject you can learn by checking out what is asked for in open positions you'd like to get (take them with a grain of salt, though, for they often describe ideal candidates).
2. Draw a (mental?) graph of the positions and knowledge needed to fulfill those requests. This will be the equipment you want to get, and also when you want to own each piece. Basically, the guide to beating the game.
3. Finally, start working on getting the stuff required for the first position, while working up your chances to get what is needed for the last and all in-between. Keep your long and short term objectives clear and with a little luck and patience you might make it.

So, what is the value associated to learning a new programming language when you aspire to become a camera designer? If the languages you know allow you to work in a decent 3D engine already, probably not as much as improving your algebra and calculus, or simply creating lots and lots of camera behaviours. Most job openings for such a position request advanced knowledge of 3D algebra and experience or a port-folio. Scripting in a certain scripting language is a plus, not a selling point.

However, you cannot discard the importance of tangential knowledge. Many jobs will require working in areas not linked to your interests, even more if you are not looking for a specialist position. In a small company, a person who can decently cover two or more areas is much more valuable than an ace in just one. Remember: clerics, with their healer/warrior abilities, are invaluable in small parties.
And also keep in mind that the industry is full of great talents and possibilities. As you proceed, always consider your chances of reaching your target, and the desirability of positions you had no idea existed. Dreams may not be that beautiful once you get to live them, and being able to find another interesting job in the same environment might be even more fullfilling. Think of it as sub-classing, and then giving more use to your second class than the first.

To end, I'll give a practical example:
In my case, I'd like to be a level & mechanics designer/programmer in a small or middle sized company. Requirements I've found around, and gross importance estimations, are: experience creating games (10), ability to analyze games (10), programming & patterns (8), maths (6).
Taken those estimations, I decided that I had to write my own games (game creation and programming), write reviews (analysis), review my maths and design lots of prototypes (experience). I am also removing the dust settled over my C++ skills, and learning a couple of scripting languages, because they are very common requirements. But I still remain faithful in the possibilities of C#/Mono as a promising asset for the future, so most of my projects are in XNA and Unity.
This blog is also part of the strategy to become a game programmer and designer, as I'll use it to post the reviews and games I write, and have something to show to recruiters. It is in my inventory, taking time from other tasks, but I consider it could be valuable enough for a future quest.

So, consider this advice, compare it to other options and aim for the best.

* Unless you want to work as a localization engineer, tester, producer, etc. I know a little bit more about that.

P.S.: As I wrote this post I became aware of the similarities of this approach to the cool-concept-of-the-moment of Gamification. Just so you don't start making presentations about it, it's not the same. Mainly because the knapsack is just an analogy, not a game mechanic used to motivate students. A similar concept, Skill trees, more kin to gamification, could be used in universities and such to make career paths clearer to students. I don't think it'd be that fruitful, beyond a mere informational standpoint, but that shouldn't keep anyone from trying.

 Why didn't I pick that skateboard proficiency back in grade five?!?