6 ms·

Such a good write up. It’s mind boggling the amount of problems you have to solve with fakes, hacks, trickery to fool the human player’s eye. What’s worse is t

Such a good write up. It’s mind boggling the amount of problems you have to solve with fakes, hacks, trickery to fool the human player’s eye. What’s worse is that all of these techniques across all of the mentioned areas are evolving and changing as hardware changes. It’s impossible for one person to keep up anymore. The art pipeline is pretty much cookie cutter from films with an added step of simplification of the mesh and baking normals. The rest is up to the engine and graphics programmers to get working as intended, the downstream of this is the design team. It’s gotten easier in the animation department. Easier in the texturing department. Easier due to painting and PBR, but it’s gotten exponentially more difficult in the core engineering, engine level department. It’s a murder pit of the mind. I’ve written a few game engines. I don’t write game engines.

deleted 6y ago
[deleted]
proc0 6y ago
I think game engines are the most complex software category to be engineered. They aim to simulate reality for a given piece of hardware. It seems as hardware gets better game engines implement something closer to the physics equations that describe the universe. With some AI as shortcuts for biological formations, we'll soon have to reinvent the wheel less and take less algorithmic shortcuts whenever we need a basic simulation with gravity, lighting, materials etc.
- hombre_fatal 6y ago
  Then there’s the other impossible half of the problem: making a game that’s fun. Such a hard nebulous problem that it’s easy to procrastinate by focusing on the technical stuff as a break.
  - gabereiser 6y ago
    This. More game companies need to focus on core fun and play than technical achievements and micro transactions.
    - wongarsu 6y ago
      In mobile games the motto seems to be "why make it fun when you can make it addicting instead".
      - paulryanrogers 6y ago
        Isn't that intentional now? Interesting enough players want to continue yet uncomfortable enough they want to pay to bypass arbitrary gating.
  - AnIdiotOnTheNet 6y ago
    Indeed. It's one of the pitfalls I see a lot of first-time game developers fall into: they don't actually have a fun game, but rather than work on that they keep adding complex systems and digging in technically in the likely vein hope that fun will somehow emerge from that.
- ReactiveJelly 6y ago
  How do you know that simulating reality is the most complex thing software can do? How do you measure "complex", anyway?
  - hutzlibu 6y ago
    Probably because reality is indefinite complex and that it would take a whole reality to correctly simulate a reality. So the hard part is to make aproximations that run in REAL TIME (unlike scientific simulations, that have some time to run). And how do you measure complex? Well, how about the number of changing variables involved? Simulating and solving chess is very easy in comparison. You have only very limited and fixed variables. Simulating a physic sandbox game with advanced chemistry and even biology that is supposed to run in real time - seems impossible at this moment on the other hand. Too many connected details.
  - proc0 6y ago
    Complexity as in software. It has many moving parts, and I think it includes most if not all of computer science areas, like networking for multiplayer, cutting edge rendering, client-server applications for managing updates and also the multiplayer, AI for NPCs but now AI for animations and environment generation, and the list is really long. The only exception I can think of is software for rockets/spaceships and rovers, which have to operate under very unique circumstances.
- yurishimo 6y ago
  And that's assuming we want to play/make games with "realistic" simulations! I'm sure we've all played those sandbox physics games where a few values were tweaked just to far in one direction. Sometimes that can be really fun! I'd e interested to know if these more advanced tools take that into account, or will there be frequent cases of needing to roll your own physics engine? I'm trying to think of an example, but I believe I remember reading about a game that purposefully used a slightly lighter gravity for some models to help the player feel more powerful (?) than other characters. I wish I could remember, but the idea is the same. Physics that are dynamic could be a fun/useful gameplay mechanic and I hope we don't see those types of games go away because everyone decides it's too complicated/not worth it to use a different physics algorithm than the one shipped in some console SDK.
  - proc0 6y ago
    Yeah, movement speed is also perceptively slower in a game for some reason and realistic speeds are boring so most FPSs have the player running at car speeds. These tweaks will always be there to "fix" our limitations in reality. Teleporting is another example where nobody is really interested in traveling distances like IRL.
    - allo37 6y ago
      Hey if I could fast-travel IRL I probably would :p
turing_complete 6y ago
Isn't it what makes game programming interesting, though? I work at a FAANG company and do game and engine development as side projects and would like to do that full-time at some point. In game programming you actually solve difficult and interesting problems and really care about the performance your code. For the majority of other software engineering positions, managing dependencies seems to be the hardest challenge.
- awild 6y ago
  With the size of game development teams it really depends on what you're working on (And I'd speculate, that less people work on engines than on game systems). Only the really big studios roll their own engines. Looking at something like Watchdogs, there are also people involved in writing Quest and Dialogue systems etc. for the game designers and these things are quite mundane.
  - ajuc 6y ago
    > Quest and Dialogue systems etc. for the game designers and these things are quite mundane. Depends what you want from them. I've written a small quest and dialog system for my indie game (never finished, as most of my side projects :( ), and it was quite involved. I used a graph programming library ( https://github.com/ajuc/pefjs https://github.com/ajuc/pefjs ) to create graphs of nodes where each edge is a blocking condition (is the $MONSTER alive? is player near $NPC?) and each node is next step in a quest (with some actions if needed). Then there was a in-memory database allowing to record arbitrary metadata that quests might require. Stuff like "have the player killed that monster", "does the player have the quest item equipped", "have the player talked with one of these 4 people about X", "has any NPC seen the player near the $PLACE during $EVENT". I briefly considered adding gossips - if $NPC1 seen player commit murder and $NPC2 meets $NPC1 - then $NPC2 remembers that too, and remember who told them. But then I calculated how much memory that would need and it's staggering. And players won't notice anyway most likely. But it would be so cool. Once you start recording data about data (does $NPC2 know about the fact that $NPC1 seen player commit murder?) it's hard to know where to stop. Anyway, even without these - there's lots of that stuff and it needs indexing and filtering. I considered using some in-memory SQL database or datalog, but eventually just rolled my own with basic hashmap indexing. Then there was dialog system and I wanted more variety than the same responses every time, so I created sets of possible greetings and goodbyes, confirmations, negations, reaction to repeatedly asking the same question, etc. Then the system chooses randomly from the list (each "kind" of NPC has separate list - one for working class characters, one for strangers, one for scholarly types, and special lists for important NPCs). You can also parametrize dialogs with data from quest database - so you can for example ask the player about his new $COLOR $BRAND vehicle when he comes to see the NPC the first time after the purchase. There's lots of interesting stuff to do there, even if it's not visual.
10x-dev 6y ago
I've been trying to learn graphics programming for 10 years now, in my spare time. The amount of complexity that was slowly introduced for the sake of better graphics makes entering the field now a daunting task. I have about a dozen books, each thousands of pages long. People who have been writing games since the 90s added this knowledge incrementally. Learning it now is such a mess. I am partially disappointed with myself, partially with the state at which the field has arrived.
- mrfox321 6y ago
  Look at the bright side, it will take less time to catch up than it took them to build the foundation!
- gabereiser 6y ago
  How I started was I got interested in 3D modeling because I wanted to make a Star Wars fan film in 1996 with my 8mm. I bought a DVD set on how to do modeling and texturing in 3D Studio Max from the Gnomon School. It was amazing. Film level quality secrets and techniques. I got pretty good. This lead me down a rabbit hole of how do I take this and apply it towards games. 3D modeling and texturing for games. Then I started working on coding and realized that OpenGL/DirectX used similar concepts to what I learned in 3D studio max. There’s a scene, a camera, a mesh, a light, materials, textures, shaders (SM1.0), and all these things combined give you your lit scene using some advanced but cookie-cutter math.
FartyMcFarter 6y ago
> The rest is up to the engine and graphics programmers Don't forget technical artists, who implement and use tools to make art content run well on game engines. This could mean optimizing shaders, tweaking content streaming, tweaking occluders, etc.
- gabereiser 6y ago
  I left out a lot of median positions between the extremes. Yes. Audio engineering is in there too. Technical artists sit between gfx programmers and the artists, also working with level designers to create the desired effects too.

deleted 6y ago

[deleted]

proc0 6y ago

I think game engines are the most complex software category to be engineered. They aim to simulate reality for a given piece of hardware. It seems as hardware gets better game engines implement something closer to the physics equations that describe the universe. With some AI as shortcuts for biological formations, we'll soon have to reinvent the wheel less and take less algorithmic shortcuts whenever we need a basic simulation with gravity, lighting, materials etc.

hombre_fatal 6y ago
Then there’s the other impossible half of the problem: making a game that’s fun. Such a hard nebulous problem that it’s easy to procrastinate by focusing on the technical stuff as a break.
- gabereiser 6y ago
  This. More game companies need to focus on core fun and play than technical achievements and micro transactions.
  - wongarsu 6y ago
    In mobile games the motto seems to be "why make it fun when you can make it addicting instead".
    - paulryanrogers 6y ago
      Isn't that intentional now? Interesting enough players want to continue yet uncomfortable enough they want to pay to bypass arbitrary gating.
- AnIdiotOnTheNet 6y ago
  Indeed. It's one of the pitfalls I see a lot of first-time game developers fall into: they don't actually have a fun game, but rather than work on that they keep adding complex systems and digging in technically in the likely vein hope that fun will somehow emerge from that.
ReactiveJelly 6y ago
How do you know that simulating reality is the most complex thing software can do? How do you measure "complex", anyway?
- hutzlibu 6y ago
  Probably because reality is indefinite complex and that it would take a whole reality to correctly simulate a reality. So the hard part is to make aproximations that run in REAL TIME (unlike scientific simulations, that have some time to run). And how do you measure complex? Well, how about the number of changing variables involved? Simulating and solving chess is very easy in comparison. You have only very limited and fixed variables. Simulating a physic sandbox game with advanced chemistry and even biology that is supposed to run in real time - seems impossible at this moment on the other hand. Too many connected details.
- proc0 6y ago
  Complexity as in software. It has many moving parts, and I think it includes most if not all of computer science areas, like networking for multiplayer, cutting edge rendering, client-server applications for managing updates and also the multiplayer, AI for NPCs but now AI for animations and environment generation, and the list is really long. The only exception I can think of is software for rockets/spaceships and rovers, which have to operate under very unique circumstances.
yurishimo 6y ago
And that's assuming we want to play/make games with "realistic" simulations! I'm sure we've all played those sandbox physics games where a few values were tweaked just to far in one direction. Sometimes that can be really fun! I'd e interested to know if these more advanced tools take that into account, or will there be frequent cases of needing to roll your own physics engine? I'm trying to think of an example, but I believe I remember reading about a game that purposefully used a slightly lighter gravity for some models to help the player feel more powerful (?) than other characters. I wish I could remember, but the idea is the same. Physics that are dynamic could be a fun/useful gameplay mechanic and I hope we don't see those types of games go away because everyone decides it's too complicated/not worth it to use a different physics algorithm than the one shipped in some console SDK.
- proc0 6y ago
  Yeah, movement speed is also perceptively slower in a game for some reason and realistic speeds are boring so most FPSs have the player running at car speeds. These tweaks will always be there to "fix" our limitations in reality. Teleporting is another example where nobody is really interested in traveling distances like IRL.
  - allo37 6y ago
    Hey if I could fast-travel IRL I probably would :p

turing_complete 6y ago

Isn't it what makes game programming interesting, though? I work at a FAANG company and do game and engine development as side projects and would like to do that full-time at some point. In game programming you actually solve difficult and interesting problems and really care about the performance your code. For the majority of other software engineering positions, managing dependencies seems to be the hardest challenge.

awild 6y ago
With the size of game development teams it really depends on what you're working on (And I'd speculate, that less people work on engines than on game systems). Only the really big studios roll their own engines. Looking at something like Watchdogs, there are also people involved in writing Quest and Dialogue systems etc. for the game designers and these things are quite mundane.
- ajuc 6y ago
  > Quest and Dialogue systems etc. for the game designers and these things are quite mundane. Depends what you want from them. I've written a small quest and dialog system for my indie game (never finished, as most of my side projects :( ), and it was quite involved. I used a graph programming library ( https://github.com/ajuc/pefjs https://github.com/ajuc/pefjs ) to create graphs of nodes where each edge is a blocking condition (is the $MONSTER alive? is player near $NPC?) and each node is next step in a quest (with some actions if needed). Then there was a in-memory database allowing to record arbitrary metadata that quests might require. Stuff like "have the player killed that monster", "does the player have the quest item equipped", "have the player talked with one of these 4 people about X", "has any NPC seen the player near the $PLACE during $EVENT". I briefly considered adding gossips - if $NPC1 seen player commit murder and $NPC2 meets $NPC1 - then $NPC2 remembers that too, and remember who told them. But then I calculated how much memory that would need and it's staggering. And players won't notice anyway most likely. But it would be so cool. Once you start recording data about data (does $NPC2 know about the fact that $NPC1 seen player commit murder?) it's hard to know where to stop. Anyway, even without these - there's lots of that stuff and it needs indexing and filtering. I considered using some in-memory SQL database or datalog, but eventually just rolled my own with basic hashmap indexing. Then there was dialog system and I wanted more variety than the same responses every time, so I created sets of possible greetings and goodbyes, confirmations, negations, reaction to repeatedly asking the same question, etc. Then the system chooses randomly from the list (each "kind" of NPC has separate list - one for working class characters, one for strangers, one for scholarly types, and special lists for important NPCs). You can also parametrize dialogs with data from quest database - so you can for example ask the player about his new $COLOR $BRAND vehicle when he comes to see the NPC the first time after the purchase. There's lots of interesting stuff to do there, even if it's not visual.

10x-dev 6y ago

I've been trying to learn graphics programming for 10 years now, in my spare time. The amount of complexity that was slowly introduced for the sake of better graphics makes entering the field now a daunting task. I have about a dozen books, each thousands of pages long. People who have been writing games since the 90s added this knowledge incrementally. Learning it now is such a mess. I am partially disappointed with myself, partially with the state at which the field has arrived.

mrfox321 6y ago
Look at the bright side, it will take less time to catch up than it took them to build the foundation!
gabereiser 6y ago
How I started was I got interested in 3D modeling because I wanted to make a Star Wars fan film in 1996 with my 8mm. I bought a DVD set on how to do modeling and texturing in 3D Studio Max from the Gnomon School. It was amazing. Film level quality secrets and techniques. I got pretty good. This lead me down a rabbit hole of how do I take this and apply it towards games. 3D modeling and texturing for games. Then I started working on coding and realized that OpenGL/DirectX used similar concepts to what I learned in 3D studio max. There’s a scene, a camera, a mesh, a light, materials, textures, shaders (SM1.0), and all these things combined give you your lit scene using some advanced but cookie-cutter math.

FartyMcFarter 6y ago

> The rest is up to the engine and graphics programmers Don't forget technical artists, who implement and use tools to make art content run well on game engines. This could mean optimizing shaders, tweaking content streaming, tweaking occluders, etc.

gabereiser 6y ago
I left out a lot of median positions between the extremes. Yes. Audio engineering is in there too. Technical artists sit between gfx programmers and the artists, also working with level designers to create the desired effects too.