Start with game jams. When you're constrained to make a complete game in 48/72 hours, suddenly you start to understand what's important and what's not. Granted, I haven't done any doors in my jam games yet =)
What do you mean? The examples show use cases we have to think of. When designing worlds, or at least rooms players walk in freely, these questions about doors must be answered.
Ideally, of course, we could just physically model them, and then: wooden doors can be hacked away with an axe, a steel door could perhaps be forced using a crowbar but not if the frame is reinforced, etc. But, the modelling based on actual physical behavior is hard, both coding wise as well as computationally wise. So, we accept that we must do a simplified model and yet we must make it not too simple so that it still believably acts as a door in the virtual world.
I mean surely you don't require that many "specialists" to address all those concerns. It's like saying I need a chef to salads, another to make condiments, one to work the grill, etc.
Ah, so you were referring to the second section? I considered that as a bit of a tounge in cheek, but frequently AAA titles would create tasks for most of these positions. In indie development, sure some or all of these roles would be combined into a single or several persons. That does not mean that all (most) of these would not be done, though.
It's just a list of roles. On a one-man project they will all be done by the same person. But obviously as budget scales up you can also split up the roles more and more.
>Programming is chaotic magic. There are no rules. You ask a game dev “Can the player summon a giant demon that bursts from the ground in an explosion of lava?” and they’ll say “sure, that’s easy” and then you’ll ask “can the player wear a scarf?” and they’ll go “oof”
Funny, because Alexnet came out in 2012 and Inception in 2014. So the problem was already more or less solved when the comic was drawn, but the DL craze hadn't reached the masses yet.
I think we all forget how nonexistent on-device inference was back then. If you had a 500mb CNN model, there was absolutely no way you were including in a mobile app.
You could maybe host it on a server behind an API, but that would be significant costs.
We are spoiled these days. I can drag an ONNX file into a handful of services and do inference for fractions of a cent.
That was no problem, because back then you only really needed a GPU for training. People who only learned about DL through transformers and LLMs might find this hard to believe, but you could comfortably run inference on AlexNet with 250mb RAM on a CPU and Inception only used like 50mb. No fancy hardware or accelerators necessary.
Game dev is one of the most unconstrained software domains. On the one hand it's what makes it exciting and endlessly interesting, but it's also what can make it a nightmare. Perhaps most simply because computers are really not up to the task of simulating worlds, and so much hackery and smoke and mirrors are required.
All of the answers to these problems are trivially easy. I maintain my stance that "game designer" is not a real job and is just a fanciful cushy position for people who were already privileged in life to pretend like they're doing hard work. Things like "do doors lock behind the player?" is not anywhere close to as hard as the very easiest problem faced by the actual programmers who are doing the actual work on your project.
"SOMEONE has to solve The Door Problem, and that someone is a designer." -- it sounds like literally thirty minutes of work per week. Just admit that your job is easy and cushy and the programmers and artists are the only ones doing any actual work. They make fun of you when you're not in the room. They add ducks to animations just so that you can feel important by telling them to take them out. You're a parasitic drain on the project, not a "big idea man". Everyone already knew whether or not that door should lock before you were asked.
A game designer is just a type of product designer (the product, in this case, being a game).
If you don't understand the role of product design in making a successful product (and the difficulty involved in making correct product design decisions), that speaks only to your own inexperience.
"Product designers" are also made fun of by the people doing the actual work. I agree that it can be difficult, but those difficult decisions are worked through by the people with their hands and eyes on the actual thing (or on the actual code), not by the "idea people" who spout off nonsense and expect their fever dreams to magically turn into a useable product or useable software by their little minions beneath them. No, their little minions are the only ones who actually know how to do anything, and the "product designer" is just in their way.
A "product designer" is someone who got daddy to fund their "gentleman's Cs" MBA degree and then posts online saying they have a brilliant idea for a company and they just need to find some programmer to implement their grand "Facebook for Dogs" idea and they'll graciously give them 20%. Someone who idolizes Steve Jobs and whose eyes glaze over when any of the actual fractal complexity of the world is presented to them.
I'm making a game right now, and I'd kill for a good game designer.
The gap between "high level goal" and "features to implement" is just as complex and squirrelly as the gap between "features to implement" and "lines of code".
I work on a project with a decent ratio of engineers:designers. A good designer is not just "ideas people", they are fairly technical without getting into the nitty gritty.
If one side gets too much power then it can land in situations like you describe (design makes unrealistic requests, or engineering over constraints the product). When the balance is right then working becomes quite amazing, nothing better than seeing my work (engineering) used to make stuff I couldn't even think of and I can see the appreciation of helping design make their vision come true.
Often the most difficult problem to solve is figuring out which problems to solve. That difficult problem is often 'simply' a design choice with a high impact.
32 comments
[ 4.6 ms ] story [ 70.2 ms ] threadIdeally, of course, we could just physically model them, and then: wooden doors can be hacked away with an axe, a steel door could perhaps be forced using a crowbar but not if the frame is reinforced, etc. But, the modelling based on actual physical behavior is hard, both coding wise as well as computationally wise. So, we accept that we must do a simplified model and yet we must make it not too simple so that it still believably acts as a door in the virtual world.
-Alex Blechman
You could maybe host it on a server behind an API, but that would be significant costs.
We are spoiled these days. I can drag an ONNX file into a handful of services and do inference for fractions of a cent.
The Door Problem (2014) - https://news.ycombinator.com/item?id=24313607 - Aug 2020 (11 comments)
The Door Problem (2014) - https://news.ycombinator.com/item?id=16021509 - Dec 2017 (27 comments)
"SOMEONE has to solve The Door Problem, and that someone is a designer." -- it sounds like literally thirty minutes of work per week. Just admit that your job is easy and cushy and the programmers and artists are the only ones doing any actual work. They make fun of you when you're not in the room. They add ducks to animations just so that you can feel important by telling them to take them out. You're a parasitic drain on the project, not a "big idea man". Everyone already knew whether or not that door should lock before you were asked.
If you don't understand the role of product design in making a successful product (and the difficulty involved in making correct product design decisions), that speaks only to your own inexperience.
A "product designer" is someone who got daddy to fund their "gentleman's Cs" MBA degree and then posts online saying they have a brilliant idea for a company and they just need to find some programmer to implement their grand "Facebook for Dogs" idea and they'll graciously give them 20%. Someone who idolizes Steve Jobs and whose eyes glaze over when any of the actual fractal complexity of the world is presented to them.
The gap between "high level goal" and "features to implement" is just as complex and squirrelly as the gap between "features to implement" and "lines of code".
If one side gets too much power then it can land in situations like you describe (design makes unrealistic requests, or engineering over constraints the product). When the balance is right then working becomes quite amazing, nothing better than seeing my work (engineering) used to make stuff I couldn't even think of and I can see the appreciation of helping design make their vision come true.
Why video game doors are so hard to get right https://www.youtube.com/watch?v=AYEWsLdLmcc