Hacker News Reader

Comment by gabereiser | Hacker News Reader

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.

View on HN

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.

I've shipped two commercial games on Steam and PS4. My advice, don't quit your job just yet. It's extremely, extremely hard to make a living off game making.

At the rate the industry is going, I give you a whopping 1 in 1000 chances of matching your current wage making games.

Also, even if you get a job at a AAA game company, you're looking at a 50-75% pay cut from what you'd be making in FAANG. Even salaried game developers are very underpaid, because there are so many people who are willing to take the jobs for the fun/love factor (which eventually goes away).

The only people making real money are: a) corporate execs, b) people who get lucky with a big indie hit on Steam/etc, c) people lucky enough to work at a company with profit sharing (very rare)

> I give you a whopping 1 in 1000 chances of matching your current wage making games.

The comment your replied to make it clear they find game programming interesting and they have a passion for it.

What on earth does making the same wage have to do with it?

If we can make a liveable wage doing what we enjoy, there are scores of people that couldn't care less about a massive wage.

>What on earth does making the same wage have to do with it?

The fact that, on Earth, passion only gets you so far. And it can easily wane off, given bad circumstances.

And of course, on Earth at least,

(a) "passion to create AAA games"

is not the same as

(b) "passion to be an employee on a AAA game company, with impossible schedules, idiotic management, unpaid overtime, and lower salary that I could get elsewhere".

In the end, whatever their passion, the AAA game developer is just a cog in a team (the head / driver of the team would be 1 in 20 or 1 in 50 devs).

Because passion is the traditional excuse to exploit workers in the industry.

I work on commercial physics solvers (mostly fluids) and engineering design optimization code. Game programming seems like the only other thing I’d ever want to do, programming wise. Maybe optimization but really even machine learning is pretty ho hum in comparison. All that data wrangling...

I guess “we” pay for the fun with lower salaries and/or poorer work life balance. At least sometimes, eh hem.

The best job I ever had was working on computer-aided engineering software. It was a difficult job that you did with a ton of really bright people, it paid quite well, and it was very low stress.

The only gotcha is you can't really transfer those skills into other jobs, and the market for computational physics is rather sparse.

Yeah, you hit the nail on the head there. the sparsity makes me nervous. Combine that with the fact that I recently changed jobs from a very low stress position where I was basically calling the technical shots for myself to one where I am micromanaged to the half day time step... (I did this to myself in order to broaden and deepen my computational resume.) I sleep a lot less this year than last.

My first job after university actually was a ML/data science job at a smaller company. The interesting / challenging part was actually understanding the problem domain and how we could actually leverage data, the technical and algorithmical challenges were, for the most part, pretty easy. It was mostly data wrangling and importing some classifier or regressor from scikit-learn.

Of course, there are also super interesting and technically challenging jobs in ML out there.

Yeah, maybe something with differential geometry and ML would be fun. I’ve also built a system for composing relations and generating gradients from a computational graph...(for CAD design generation) Maybe I should look at working on a framework project. Whatever the theano folks are doing nowadays - or the like.

Totally this. Games programming seems the only field where all my years of comp sci and eng training actually matter.

Data visualization for enterprise backends holding TB of data is also a difficult and interesting problem.

Just like having a database holding DNA data that a robot in a chemical lab needs to get hold of in less than X ms for the planning software not to go astray when locating where to get the plate from.

It is a matter to look for challenges.

Thanks to demoscene and early industry contacts I have seen the other side of the garden, and decided it wasn't that green after all.

>Isn't it what makes game programming interesting, though?

Game programming maybe.

For game playing, I'd prefer games focused on interesting gameplay and world-building, rather than the 1000th derivative game in a 3D-graphics race...

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.

> 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 ) 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.

If you want to record a ton of boolean values you should look into sparse bitsets like roaring bitmaps. You can encode a ton of information that way and serdes is trivial.

My best idea was to assign "importance" to each event, and only record when each NPCs met and for how long.

Then when I check if NPC x knows about EVENT y I check who he met between time of the event and now and look at importance (witnessed murder would be high) and if there's a path for the information to pass - then he knows.

But it's too much work to do in every "tick" of the quest process. It should only be checked when something changed (someone who knows meets someone else).

It became too complicated system for just a few usages and some background gossip. But I think for a big RPG it could be great. Would allow more reactive world and more interesting quest design.

I think the main reason AAA games don't do this is voice overs. If we had good emotional speech synthesis a lot of new possibilities would open. So indies have an advantage here because text-only is still accepted.

That kind of lookup seems like a great use case for a graph database. These kinds of queries are trivial and reasonably fast there.

I think where such a system would shine is in background banter. The player has to observe the NPCs telling each other these facts so he can appreciate it. That also opens the door for the player stepping in to prevent the spread of information. With the right setting that could be a major game mechanic

> 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.

I think we are getting here with natural language understanding.

Rather having to write statements and handle the logic on a per-agent basis. We could keep a database of events with a brief description of what occurred, and use some NLU engine to use that description to form statements and opinions on the subject at hand.

It could even incorporate sentiment by having favorably weights between groups. So let's say, elves hate dwarves, and an event occurred where "Belegost (dwarven city) was razed (terrible action) by armies of Gondolin(elven city." The event name would run though a NLP system to which would make elven characters see the event more favorable than dwarven ones.

You could even model the spread of information.

I'm not saying these are cool and impressive engineering projects. I've studied games engineering and also worked on small scale games, but there is an enormous difference between optimized graphics/game engine code and what you and I did.

Well it's a hobby project not an AAA game.

I did 3d graphics too even some shaders for commercial projects (not games - enhanced vision devices for partially blind people). I did some basic (archais by now) 3d rendering techniques (BSP trees, portals, quadtrees) in my hobby games.

I don't think one is inherently harder or more cool than the other.

You can look at Dwarf Fortress for gameplay/quest/dialogs and Cyberpunk 2077 for graphic, and it would be as cool and hard as each other IMHO.

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.

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.

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.

This. More game companies need to focus on core fun and play than technical achievements and micro transactions.

In mobile games the motto seems to be "why make it fun when you can make it addicting instead".

Isn't that intentional now? Interesting enough players want to continue yet uncomfortable enough they want to pay to bypass arbitrary gating.

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.

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.

Hey if I could fast-travel IRL I probably would :p

How do you know that simulating reality is the most complex thing software can do?

How do you measure "complex", anyway?

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.

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.

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.

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.

Look at the bright side, it will take less time to catch up than it took them to build the foundation!

> 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.

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.

Reply on news.ycombinator.com