As a hobbyist game dev one thing I've (recently) learned is that optimizing performance is paramount in video games. Running at 60 FPS you have a budget of 16 ms per frame (VR requires 90 FPS minimum else risk VR sickness; ~11ms per frame). Any scripts and anything you want on screen needs to fit in that amount of time. It's a big exercise in smoke and mirrors.
I'd love to know what optimization techniques are used so that those precious CPU/GPU cycles can go to those good looking things.
Side note: being absolutely forced to optimize the heck out of games as an essential practice gives me a much greater sense of performance characteristics in my "real" job and also in leetcode.
Use the GPU to decide what to render, and in a growing number of cases, will cull triangles in compute (software) instead of letting the fixed pipeline do it. The vertex shader feeds parameters to the fragment shader even if the triangle is culled (depth or backfacing), so with vertex counts climbing, there is a lot of dead time spent feeding fragment shaders that are never ran.
Render at a lower resolution and temporally upsample to a higher resolution.
Using low overhead apis that optimize command recording performance (DX12, Vulkan) and transfer / memory access.
Culling triangles seems to be going away though, especially with the rise of ray tracing. The expectation is that even aspects of the scene we can’t see influence lighting. How are they managing that?
IANAGD, most graphically intense games are using a hybrid approach where RT will inform lighting/shadows and reflections but still rely on traditional rasterization heavily. That gives you a good bit of room to fudge the raytracing since the rasterization gives you a baseline.
That said, it seems like the culling advice for RT is "expanded camera frustrum" culling, distance culling dependent on size, and choosing the right geometry LOD. Beyond that they want you to aggressively mark geometry as opaque and carefully arrange objects into groups (BLASes) according to a couple rules so the GPU can skip as much work as possible.
What makes you think culling triangles is going away? Ray tracing is usually done with a highly approximated volume or planar representation of the scene, which is then applied to surface triangles.
Rendering objects that 'we can't see' has been done for as long as shadow caster light sources have been around. Even though we cannot see the mesh directly, the light can, and the viewer can see the shadow. These indirections all play their role in the greater "rendering equation", and the specific solution depends on the constraints of the application and resources of the development team.
Some renderers have abandoned triangles altogether for signed distance fields, but this involves re-creating from scratch the entire art pipeline.
Sorry, I just assumed that you’d need to construct the geometry in order to produce an accurate scene (with any complex lighting, be it shadows or ray tracing). I’ll be reading up more on the techniques you’ve mentioned. Im not a graphics developer so my suppositions are entirely naive.
That's good; you get more of a frame budget that way. I saw 90 and even 144 as target frames to avoid VR sickness. It's good to know 72 frames can work too.
Frame rate plays a role - especially when it drops down below targets and stutters, which does happen irl, but designing the experience to avoid motion sickness from the ground up is what makes the difference. Keeping something stable in the view that moves along with head pose like a HUD element while everything else around you is moving makes a huge difference. Seeing the world around you in motion from inside a car with the stable windscreen will be much easier than zooming around through freespace even at 120hz for most people until they get comfortable with the sensory mismatch. I have heard several interesting approaches to acclimatization and can recommend this [1] if you are affected & am told positioning a real fan blowing air on you while in the headset will orient your proprioception in a way that helps.
The unnerving thing about this post is just how I could very realistically find myself in similar shoes. I do many things and bet on my ability to learn as I go. Sometimes it does take some extra hours. Time is finite.
Why bravery to say "I don't know; I could probably find out but I cannot."
Writing automated tests for video games. Why is it interesting to me?
I started to teach myself unity in December 2021. I've personally experienced benefits to writing automated tests and using CICD; therefore, I thought it would be fun to learn about writing tests for a 3D based software. It will be different from the web/CLI based stuff I usually write.
So, it turns out that the video game community (or at least the online circles I frequent) are extremely against the idea of writing automated testing for various reasons. This translates into there effectively being a non-existent pedagogy around teaching how to write tests for 3D based software. Content is scarce, and the content you do find is produced by people who obviously don't write automated tests. So, for me I've hit the books to arbitrage & translate techniques and philosophies into this "untapped" domain.
It's interesting because I've figured out tips & tricks that I'd consider low hanging fruit... For example, if you place a "test" camera in the test case, you can actually see what's going on in the test when it's executed. Or how important it is to clean up every created game object in your test after each test; if done right, you can keep your SUT at origin (0,0,0). Or the importance of "test prefabs" who are effectively mocks of other "real" prefabs...
One innovation that I would like to use/build that I truly consider (((revolutionary))) is this: I want the test cases I write to also automatically (or when tagged with a certain C# attribute) generate the same game objects in a "exploratory(manual) test scene." I think this innovation is the "killer app" that will completely and totally sell the value proposition of automated tests to those opposed. If you decide to build this, please also publish it on openupm and reach out to me.
I have plenty of other thoughts and ideas on this space. I love talking about automated testing; it feels like a very futuristic programmer practice. I hope this post demonstrates why this work and space is so interesting.
I worked at an MMO game company and the only testing we had was manual QA for functional testing and bot clients for server stress testing. Not a great environment for building quality software. (Our max server uptime was about 24 hours.)
The client had a secret level with all game objects for testing and debugging. But reading your post makes me see that we didn’t think ahead far enough: the secret level could have been the foundation for automated unit testing game objects and battling characters.
I haven’t watched them yet, but I added these relevant videos to my YouTube backlog just this week:
Would like tro hear more of what you're thinking! I agree it's important, but it's also secondary to building. Facebook has no tests, for example. Would tests make them more profitable?
But I'm not dismissing testing in unity. I think there are some simple approaches to testing automation that could be done. It would be nice if unit testing made more sense but in reflection i've often found it's the integration of components that breaks or changes, less than the behavior itself.
My therapist says it's important to accept my personal story of how I came to be here. Sometimes that means grieving all the missed opportunities from the past. It's important to integrate the past into the present so you can confidently move into the future. Just make sure that you are a friend to yourself as you take stock of your past. YMMV.
Assuming you successfully did the hard work above, or have opted to skip it... Let's think about the future. Try to imagine where you want to be in 5 or 10 years. What does that look like? Is it an accomplishment? A style of living? A feeling? Freedom? Think however makes sense to you as we all have different sense of what we want. That's your end point that you'll try to target. Try to think of what would have to happen each year, each month, each week to get there. How can you do that sustainably? This is a type of thinking that may be helpful to you.
In my opinion it's good that you're auditing yourself like this. Maybe you don't really want to be doomscrolling your life away. But the hard question to answer is where do you want to turn your attention? What is important to you?
I think the author is good with naming symptoms and I think they miss the true culprit. It's not typescript that is causing this pain, no it's the pain of getting correct abstractions laid down in code. It's truly the pain of code design activity. Typescript and library programming is just forcing that pain to the surface instead of hiding it away.
I know this because I struggle against these "pain during code design" & "get abstractions right" forces when I program.
Declaring types is really declaring what domain objects your program cares about and function signatures are really just describing interactions that can happen. So what 'domain objects' should meaningfully exist in my program and how do they interact? A bad abstraction can burn up a lot of time, so make sure you check your abstraction. I typically check mine describing stories to my friends (or rubber duck) and ensuring I'm using plain English and the other person doesn't get lost. YMMV
When you're doing web client programming you're typically using a library to accomplish work, and much of that work is reacting to user input and rendering data. I would argue that because so much of the linguistic heavy lifting has been done for web client programming, practicing the abstraction exercise is done less than in other programming domains. Doesn't mean it couldn't, just trying to highlight a difference in programmer domains. This is why the pain is more apparent in library programming than web client programming.
I imagine that advanced individuals in code design understand more of the connection between math and programming and are capable of describing systems of interesting work in few simple statements. I hope to reach those heights someday.
There are extremely competent programmers (10x) like there are outstanding players in sports and music. They do have an outsized impact on the projects they work on. However, they are also extremely rare. The problem, IMHO, comes from cult-startups where they think they can (a) identify these people in an interview (b) build a team of only 10x programmers.
This results in (c) calling a whole lot of average programmers they hired as 10x programmers because of (a). After all, they are smart and their interview process is infallible.
So, if you meet one of those rare folks, enjoy the intellectual banter :).
Then good luck hiring a well sized team when you’ve set the expectation that everyone needs to be a genius to contribute. A successful startup needs to either attract only the best engineers or build itself so that most of the work can be done by merely good engineers following the company’s engineering culture.
10x engineers are a myth when it comes to productivity working within a team. There are absolutely 10x engineers when they're working on a project more or less completely solo.
Yeah, but that's also different from how people, especially management, tend to conceptualize 10x engineers. You don't spot the 10x engineer by looking for the one who accomplishes 10x what other engineers do. You spot them by looking for the team that's accomplishing 5x what other teams are, and then finding the "glue" person on that team.
When I look at 10x engineers who look like 10x engineers what I typically find instead is a 3x engineer leaving a path of destruction behind them. If you give everyone else impostor syndrome and difficult processes they slow down, and you look better than you are. Than you deserve.
The real heroes are the ones who make everyone else look better. But some managers only figure out who that is when they quit or when the business lays off the wrong guy because Steve produces less than Sarah, but that’s because Steve is helping people all the time, including Sarah.
I have met 10x engineers. They solve a problem in an hour that takes me all day and which someone else might never be able to solve. They identify and solve problems I couldn't even begin to tackle. In that sense, they're not really 10x but qualitatively superior.
A+ comment. I've been hearing this idea that "there is no such thing as a 10x engineer" for almost a decade now and from the very first moment I heard it I considered it one of the most definitively untrue ideas circulating in the tech industry. In fact, there are 100x engineers.
Most the criticisms of the "10x engineer" thing I've seen were more about this expectation that everyone can be 10x, when they're more the exception than the rule. Your average programmer is just that: average.
The reason people say it's a myth is because the study that purported to identify this concept was found to have an extremely small population and confounding factors. In addition if I remember correctly it tried to do this identification by using a contrived programming problem.
There are obviously software devs who are more productive than the average. This is true of every skill. The myth is thinking that (a) companies can somehow identify these people in advance, and (b) it is better to prioritize building a team with these supposed rock stars than it is to build a team of potentially average developers who know how to work together, and then properly manage, support & motivate them. A team of ten properly supported 1.5x programmers will beat out one 10x programmer every time. And in many cases the "I'm a 10x dev" personality type does not play well with others.
I'm a firm believer that any genuinely interested, motivated and at least mildly intelligent dev can be made highly productive by finding the right fit. It's far more important for companies to focus on fit and on ensuring that their own managers actually know how to manage than on trying to tap into a hidden stream of 10x devs.
I guess it boils down to the fact that I think many companies absolve themselves and their mgmt team of blame for poor performance by saying "well we just haven't been able to identify 10x devs yet." They expect to be able to hire a single employee who will save the day for them, rather than hiring and training good mgmt.
First, the "I'm a 10x dev" personality type is not a 10x dev. Arrogance is a sign of insecurity.
Second, I don't think a team of ten 1.5x programmers will beat out a 10x programmer. You either have the depth of understanding and imagination or you don't. Take Linus Torvalds, for instance -- I would say he is a 100x programmer, or perhaps a 10,000x programmer, since he is the author of both Git and Linux -- good luck trying to replicate that contribution with a "well managed team". It is similar in many areas -- 10 guys with Math PhDs do not make one Einstein.
In the context of hiring for a business that is developing a CRUD app, you're usually trying to differentiate between 1x programmers and 0.1x programmers, however -- 10x programmers aren't often looking for work.
Pretty much, it's not about grinding out assembly line CRUD work but vision. Domas is another good example if you ever watch his Black Hat presentations on x86 backdoors he's able to approach topics that are not just technically challenging but in a manner that simply would not be attainable for many.
The irony is most companies doing routine CRUD/simple business apps probably shouldn't hire such people as it's a waste and likely causes bad outcomes and perpetuates the stereotype.
I’ve met people other people called 10x engineers. Once you looked soberly at the development process that illusion has faded every time.
Part of the problem with the myth is that as originally formulated it’s meant to be between your worst and best engineer, and whoever came up with that idea is an idiot, inattentive, sheltered, or all three.
Why? Because the worst engineers help the team by calling in sick. They have negative outcomes all the time, which means everyone else in the team is infinity times as productive.
What the rest of us think is 10x versus an adequate developer, and there are almost none of those. Are there people who can work solo and produce as much as a team of 10? Sure, but that’s because of the communication overhead. Can that person join a team of ten and double their output? Only if they are a unicorn among unicorns. The easiest way to double the output of a team is to double the output of the team members. And that doesn’t make you look more productive than them. If you’re not very careful it makes you look less productive.
I've long felt that there's a relatively simple formula for productivity:
Productivity = (Time * Effort)^Talent
People like Buckminster Fuller come to mind. Especially because of this quote of his:
>“We should do away with the absolutely specious notion that everybody has to earn a living. It is a fact today that one in ten thousand of us can make a technological breakthrough capable of supporting all the rest. The youth of today are absolutely right in recognizing this nonsense of earning a living. We keep inventing jobs because of this false idea that everybody has to be employed at some kind of drudgery because, according to Malthusian Darwinian theory he must justify his right to exist. So we have inspectors of inspectors and people making instruments for inspectors to inspect inspectors. The true business of people should be to go back to school and think about whatever it was they were thinking about before somebody came along and told them they had to earn a living.”
That also depends on the X, from my experience working at FAANGs, startups, etc... I have never seen a 10x engineer in good teams, I have only seen "10x engineers" on teams without great engineers. The comparison with sports and music is pretty silly, as those are environment where the winner(s) take all (there can only be one Billie Eillish (lol) even tho there are many singers who are better), engineering is often a team effort. In the other hand, the best engineers I have seen, just spend more time than anybody else working on a problem, and often are the ones who like to show off more, and very often lack the skills in other areas of life.
I’ve seen too many prolific engineers who destroy the confidence and productivity of people around them. These are not people you want to aspire to be.
Yeah, I also think is way more common in smaller companies. Also extreme toxicity around tools, editors, .... stuff like "10x engineers" only use Vim (the classic "i dont need a mouse, thats for normies"), the command line, Arch Linux, etc... In bigger companies, with talented engineer, no single engineer can claim to be the best/10x-er or any nonsense like that, because whatever he does, can also be done(and often improved) by the team. That's why I said that depends on the X. You can certainly have a 10Y engineer where Y = 1/10*X;
If we get to expand the definition from a software engineer on a team to a business founder, do we also get to call the fiber optics 10X engineers? Is a truck driver delivering laptops a 10X engineer?
It's a coping mechanism like lying on the couch watching the Olympics and getting angry that some people are able to push themselves to incredible feats instead of being happy for them.
Never understood that mindset, when I see 100x engineering feats like TempleOS or αcτµαlly pδrταblε εxεcµταblεs it inspires me to learn more and think outside the box.
This is a real shame. I met many interesting people on VR chat. Some were exploring identities that only a virtual world would allow them to. Mods enabled these people to lose themselves in the fantasy of their identity. I heard sad stories about how VRchat was where they could be themselves.
They're going to lose that opportunity now. For what? Tighter control so VRchat can engineer their own knock off mods? Greedy. Sad.
As a journeyman programmer, I have found a few tools to help me reduce complexity.
Abstract interfacing techniques like base classes, abstract classes, and (my favorite) interfaces allow me to model interesting things.
Thinking about relationships between things in my systems versus categorizing things helps me avoid the "if you want to do something in OOP you must first define the universe" type problems.
DDD and conceptualizing how 'infrastructure' components interact with my main system is a nice guide for me.
Trying to write good tests is how I'm able to bounce around a few projects without having to read source code to reload context.
These are things that work for me. As I continue my practice I may find that I'm wrong or misinformed about some things. I should hope that I'll be able to incorporate a higher understanding as I gain more experience.
I'd love to know what optimization techniques are used so that those precious CPU/GPU cycles can go to those good looking things.
Side note: being absolutely forced to optimize the heck out of games as an essential practice gives me a much greater sense of performance characteristics in my "real" job and also in leetcode.