Yup, I have worked on plenty of business code, and systems that seemed to have more automated testing than actual work code. I have felt the same thing a few times.

It is always a cost/benefit analysis, or should be.

Also note that automated testing is not necessarily just a suite of tests run separately. I have been on many games where the automated tests are built in to non-release builds. For example, a test of network data where encode() is called, and if testing is enabled decode() is immediately called with an asset that the result is equal. This has a small cost for the build, but the benefits are worth it. Automated tests are an enormous field covering a broad range of solutions.

I have worked on projects at EA, ABK, and Epic where libraries hit that transition point where the cost/benefit ratio changed. Part of making the library ready for corporate sharing includes getting the key features documented, and creating tests that validate their behavior. They tend to also be an opportunity to clean up some rough edges when extracting from the game code and turning them into reusable libraries, where the tests serve both as verification and a use case example.

Sometimes I have seen the demos are the comprehensive test suite. The demos showcase and comment on every feature, so every feature gets exercised. The output results also provide benchmark numbers making those easy to see and compare, too.

frob said:
Also note that automated testing is not necessarily just a suite of tests run separately. I have been on many games where the automated tests are built in to non-release builds. For example, a test of network data where encode() is called, and if testing is enabled decode() is immediately called with an asset that the result is equal. This has a small cost for the build, but the benefits are worth it. Automated tests are an enormous field covering a broad range of solutions.

Yeah, asserts in debug builds seems to be quite common. In the extreme case you could have pre- and post-conditions before all functions. There is a language for verification that does something like that, called Dafny. I guess the only issue with asserts, is that if you are calling additional code only in a debug build, as in the case you describe, timing of certain events might hide issues in debug builds that appear in release (or vice versa).

I definitely agree automated testing is a broad field. I often time think the tests themselves end up being the most complex parts software. Maybe that is a sign that the benefit/cost ratio is low but I really like writing them nonetheless and I believe they make me think through my code and edge cases in more depth.

frob said:
They tend to also be an opportunity to clean up some rough edges when extracting from the game code and turning them into reusable libraries, where the tests serve both as verification and a use case example.

That's also a benefit of them. I think a lot of clean coding practices are quite arbitrary and hard to remember. But what's certain to me is that when I start writing units for my functions I become more-or-less forced to write a clean API with clear separation, since testing it otherwise would be a PITA.

perry_blueberry said:
I often time think the tests themselves end up being the most complex parts software.

They are. To write/design tests, you need to deeply understand the code you're testing AND you have to understand the test code itself.

perry_blueberry said:

If I just reach a certain level of expertise in my craft I would no longer have to have companies “take a chance on me" or reject my application early on because it is not readily apparent that I'm more fit for the task than any other application. So the question is how I can reach this level and how I can then convince other people.

[…]

The main thing I can think of is to have a bunch of stuff on Github. [..] It seems it would have to be something visually striking [..]

Another thing I can think of is to run a blog […] But that seems like quite a bit of extra work in comparison to just pushing to a git repo.

[..] I rarely end up actually implementing the stuff I read about since it would take a lot of time

[..] create tutorials [..] again that's a ton of work for something on the side.

I'll be blunt here. You aspire to be so good that it's an “obvious” decision for companies to hire you. But you're not able or willing to put in the work that is necessary to get to that point. And that's the difference.

It's understandable to want to optimize your time. But there are no shortcuts to skill and experience. You just have to get to work. There's no magic “wow factor” you can find in a short time. It doesn't exist.

You've “been into gamedev for maybe a bit over a year” - so you're quite a few years - and a few shipped games - short of having the kind of experience that makes you a must-hire at a games company. That's okay. Just accept that and get started on acquiring the skills you need.

The best advice here is also the most obvious - make a game. Pick something small, and use an engine if you like. It doesn't have to be polished or sellable. You can (and probably should) use free assets rather than make your own. But the process will give you two things:

1. Experience of all the skills needed to make a game
2. Source code that proves the above

Beyond that, small tech demos can be useful, especially when they are of features where you couldn't realistically be expected to make the whole game, or where it's an area you are quite interested in.

You should expect to have to make more than one thing to show your skill range. Again, you can't dodge the work. To have the best chances in today's market you'd need C++ and C# competence, UE4 and Unity competence, and competence with no engine/a low level framework. If you don't have time for that, fine - set some priorities and go from there. If you can leverage your existing skills to get something done quickly, then do that first - just be aware that it's about matching your skills and experience to the role, and the key is to get more skills and more experience to match more roles and more closely - it's not about having one ‘must-hire’ skill.

perry_blueberry said:

That's also a benefit of them. I think a lot of clean coding practices are quite arbitrary and hard to remember. But what's certain to me is that when I start writing units for my functions I become more-or-less forced to write a clean API with clear separation, since testing it otherwise would be a PITA.

In practice I often find this to be a circular argument, in that dedicated fans of unit testing tend to favour testable APIs even if they make the code worse in some other ways. A common one is the debate over whether a private function should be testable. If you only test it via public functions, it's hard to guarantee good coverage. So people get tempted to expose it in some way, which now means that implementation details have leaked into the interface.

Encapsulation is one of the first victims of comprehensive testing. Often an object can't be tested adequately in isolation without being able to swap out its components. So you end up adding accessors or constructor arguments to inject replacement components, many of which never need replacing except for the case of unit testing. But again the interface has grown to accommodate this. The solution then is to outsource the now-complex construction of the object to something else, or even to use a whole dependency injection system to knit your objects together, and this isn't free. It adds complexity and overhead.

The question is - is it worth it? In a workplace of averagely-skilled engineers churning out long-lived business software, the answer is probably yes. The up-front cost is necessary to get a baseline of quality and the ongoing cost is matched by the ongoing need to remain reliable in the face of changes. But is that the case for game development? There's always a cost/benefit analysis to be made.

The easiest code to test is functional - you push an input into a function and you can verify the output.

The next easiest code to test is procedural transactions - you have a state, there's some input or an event, a procedure takes that input and mutates a small bit of the state in a predictable way, and you can verify that the state you expected to change did so - and hopefully, that nothing else did.

The hardest code to test is simulation-style code - you have a large state, time passes, and much - sometimes all - the state mutates based on a large set of rules, and on the rest of the state. It's not always clear what is expected to have changed, or to what values.

I've worked in ‘business’ software (web, telecoms, apps) and it's mostly the first two. And I've worked in games, and it's large amounts of the last one. And given that game code is much harder to test, those tests have to work doubly hard to prove their worth. You can (and should) be able to pick apart the smaller units of state change to understand them in isolation. But it's harder, and so often it makes more sense to just concentrate on writing quality code than on taking the extra time to test it, especially given the shorter shelf-life of most game code and the slightly higher level of competence (which is not universal, but on average).

I think the discussion is drifting away from the subject.

“Be so good they can't ignore you” includes knowledge in fields like automated testing, sure.

Be yourself, show what you know. As you develop your skills with experience you will be harder to ignore. And sometimes people do ignore greatness in the field. There are tons of stories online where an interviewer says “GOTCHA! You don't know ${technology}” only to find out the person invented it, maintains it, or runs the standards committee for it.

Kylotan said:

I'll be blunt here. You aspire to be so good that it's an “obvious” decision for companies to hire you. But you're not able or willing to put in the work that is necessary to get to that point. And that's the difference.

It's understandable to want to optimize your time. But there are no shortcuts to skill and experience. You just have to get to work. There's no magic “wow factor” you can find in a short time. It doesn't exist.

You've “been into gamedev for maybe a bit over a year” - so you're quite a few years - and a few shipped games - short of having the kind of experience that makes you a must-hire at a games company. That's okay. Just accept that and get started on acquiring the skills you need.

The best advice here is also the most obvious - make a game. Pick something small, and use an engine if you like. It doesn't have to be polished or sellable. You can (and probably should) use free assets rather than make your own. But the process will give you two things:

1. Experience of all the skills needed to make a game
2. Source code that proves the above

Beyond that, small tech demos can be useful, especially when they are of features where you couldn't realistically be expected to make the whole game, or where it's an area you are quite interested in.

You should expect to have to make more than one thing to show your skill range. Again, you can't dodge the work. To have the best chances in today's market you'd need C++ and C# competence, UE4 and Unity competence, and competence with no engine/a low level framework. If you don't have time for that, fine - set some priorities and go from there. If you can leverage your existing skills to get something done quickly, then do that first - just be aware that it's about matching your skills and experience to the role, and the key is to get more skills and more experience to match more roles and more closely - it's not about having one ‘must-hire’ skill.

I appreciate the bluntness. I think time will tell how much I want this and how big my interest actually is.

It's just incredible hard to guess what some company expects. I've made “complete” games just by following tutorials. I guess I could do something similar with another game idea, but it just doesn't strike me as something a hiring manager/engineer would find particularly impressive. Obviously creating a successful (and somewhat complex) game would be quite impressive but if I get to that point I might as well contine creating my own games instead of working for someone else.

I guess I'm also struggling with knowing what I want to get out of gamedev. On the one hand I really like learning about new technology for its own sake and gamedev has some of the most interesting software/technology. But what has happened for me before is that I've gotten bored once I know how things actually work. On the other hand, gamedev is so approachable (compared to, say, embedded where hardware costs a ton) and being highly involved in the the overall picture and the artistic parts is enticing as well from a long-term perspective. I guess that question boils down to being a technical expert and working for others, or using technology to achieve a goal and seeing everything else as just a vehicle/tool to get there. Of course there is some overlap, and I'm sure more senior technical people in AAA companies get to do more full-picture stuff as well.

frob said:
There are tons of stories online where an interviewer says “GOTCHA! You don't know ${technology}” only to find out the person invented it, maintains it, or runs the standards committee for it.

There is this: https://rejected.us/​​​ . Some of those are ridiculous.