Hacker News Reader

Comment by PaulHoule | Hacker News Reader

A totally different kind of creativity is involved.

Frankly, people get ahead in CS by writing papers. Many people who are successful in academic CS aren’t that interested in writing programs or even that good at it.

Video games require interdisciplinary talent. The credits for a video game look like the credits for a movie because it takes 2-d and 3-d artists, character designers, writers, musicians, sound effect specialists, voice talent, and various specialized programmers.

Sure there is the occasional legendary developer who makes something like Touhou on their own but that’s deeply unusual. If a person is dedicated to success on the CS track they might not find it helps them get a postdoc or faculty position or tenure.

View on HN

I did my bachelors on a games focused compsci degree.

There were tons of people from different backgrounds, basically all there for the wrong reasons (artists to learn to program games, programmers how to program and make games etc) it's quite the endeavour to make a good game, the programming is the least of it. On top of that you need to actually be good at game design (which in my experience is the last thing people focus).

There is a tiny silver of academic CS called "human-computer interaction" (HCI) which has a lot to do with game design.

Having been on the periphery of academic CS at times I think the whole enterprise is terribly imbalanced.

A big part of the activity in social impact is in teaching the introductory CS courses which are required for many majors. PhD programs understand that their graduates have to be able to teach these classes, but few CS academics are excited about it.

Some areas get huge amounts of funding and fill up conference proceedings for decades without significant results. Other areas are funded heavily in Europe but seem almost blacklisted in the U.S. (The "Semantic Web")

I have written quite a bit of run-of-the-mill applications software for which is there is a huge need, just like for the intro CS class. For a long time I have been the quantitatively trained person who knows about data structures, algorithms, race conditions, ontologies, etc.

Lately I have been doing art side projects and have gotten very interested in the work of people like Walt Disney and Jim Henson who created imaginary worlds that people would like to inhabit. I see that study as related to game design and leading to very real gains in application software such as customer satisfaction, more revenue, lower support costs, etc.

>> it takes 2-d and 3-d artists, character designers, writers, musicians, sound effect specialists, voice talent, and various specialized programmers.

Minecraft. AAA games need a full crew, but many/most of the truly groundbreaking games come from very small teams. KSP, Factorio and Prison Architect spring to mind. If they don't have the specialist then the game just doesn't get that aspect. Minecraft didn't use writers. KSP used open source music. In the end you discover that none of those disciplines are absolute necessities. Factorio and Prison architect proved even 3d rendering unnecessary.

The games that you list were made by people who were already making games. For years.

> Factorio and Prison architect proved even 3d rendering unnecessary.

I believe this was already proven by a huge number of games existing way before these two ;]

You can make a movie with a tiny crew too. A lot of people do it but you hardly ever hear about the results.

There are some aspects of moviemaking that I could probably do professionally, others I have enough experience with that I know I'm terrible at them (acting, directing), and others that I'm totally ignorant of (what the hell does the "Foley" person do?)

If I do make a video or a game I know I can do well in some areas and other ones are going to be weak. Right now for instance I am planning on writing three "Breakout" clones to try out three different programming models. There is really no game design other than tuning up a clone of a known design. Even though the point is to try out 'software architectures' for things that are gamelike but not games I'm going to work hard on visuals and sound effects.

I'm not expecting to make enough unique enough that anyone would pay for it.

Other examples: Two of my favorite single players games were done by relatively small teams: The Witness, and The Outer Wilds. I'm skeptical games as original and creative as those could be done by high-budget teams, due to profitability concerns.

Prison Architect is one of the most disturbing media I've experienced, way beyond Frog Blender and the torture scenes from 24. That is, you play someone who does cruel things to people while sitting comfortably at a distance.

It was meant to have the opposite impact. As the warden/architect you have to manage the prisoners. You don't create them. You don't put them in prison. They arrive at your door every morning and you have to take care of them, meet their needs and keep them happy/alive. If anything, your goal is to shorten their stay and get them released asap. The game is meant to engender empathy.

The problem with video games is that the software just has to be good enough to fool the human mind. Basically "smoke and mirrors". Real software, however, usually has much harder requirements, and most people find working on that instead more interesting and more rewarding.

How is "real software" different from video game software? I ask because it seems like most consumer applications that run on our machines or that we use on the web also just have to be good enough to be tolerated by the human using it, or "fool the human mind". Where does the line get drawn between "real software" and fake (I guess?) software for you?

I'm thinking of a mathematical physicist working on fluid simulations versus a game developer who just uses some basic finite differences scheme that looks nice but is otherwise not very realistic.

Or some CAD software developer who has to think about robustness of their geometric primitives versus a game developer who doesn't really care if computations fail every now and then.

Just yesterday I've implemented collision detection between two figures in a game by simply sampling a small number of points inside the relevant shapes - and guess what? Works well enough.

A lot of game projects are also of a "write-and-forget" kind, where ongoing maintenance either isn't a concern at all or is very limited in scope, which also influences the requirements and kinds of problems you have to solve a lot.

The "technical debt" phenomenon is that people try to "write-and-forget" even when they are working on the kind of business app where pretty obviously 90% of the work is going to be maintenance. (e.g. the business changes.)

Technical debt, however, comes back to bite your ass, so you eventually learn how to deal with it with so called "best practices" - with better or worse results. The point is that for game developers it's rare to have that pressure actually applied on them, which is reflected in what's considered "best practices" in that field and how fast they evolve compared to other fields.

Reply on news.ycombinator.com