bengarney

secret | REMOTE | Contract to full time | Any country

I need an experienced Unity graphics specialist to reboot a beloved and unique simulation game IP as part of a small dedicated team. You are comfortable writing terrain, foliage, atmospherics, volumetrics, particle system from scratch, along with more typical URP/SRP dark arts + fell workings. You are OK with an opinionated codebase that largely sidesteps standard Unity stuff.

Apply by: e-mailing me at (my first name) at theengine.co

Here is a thought experiment (for devs who buy into package managers). Take the hash of a program and all its dependency. Behavior is different for every unique hash. With package managers, that hash is different on every system, including hashes in the future that are unknowable by you (ie future "compatible" versions of libraries).

That risk/QA load can be worth it, but is not always. For an OS, it helps to be able to upgrade SSL (for instance).

In my use cases, all this is a strong net negative. npm-base projects randomly break when new "compatible" version of libraries install for new devs. C/C++ projects don't build because of include/lib path issues or lack of installation of some specific version or who knows what.

If I need you to install the SDL 2.3.whatever libraries exactly, or use react 16.8.whatever to be sure the app runs, what's the point of using a complex system that will almost certainly ensure you have the wrong version? Just check it in, either by an explicit version or by committing the library's code and building it yourself.

It is, but it isn't quite the same as C, either. That is to say, there is some semi-unknowable stack of stuff happening under the covers.

I will predict the future: you will pull up the JIT assembly output to make the case that they output similarly performant assembly on your preferred platform, and that you just have to do X to make sure that the code behaves that way.

But my problem is that we are invoking the JIT in the conversation at all. The mental model for any code like this inevitably involves a big complex set of interacting systems and assumptions. Failure to respect them results in crashes or unexpected performance roadblocks.

I increasingly wonder if writing and binding performance critical things in C/C++ would be less overall effort. Performant zero-alloc C# vs C/C++ is backdoor magic vs first class language support. Boxing gloves vs. surgical gloves.

C# _can_ do this! But I face many abstractions: special perf APIs, C#, IL, asm. Outcomes will vary with language version, runtime version, platform, IL2CPP/Burst/Mono/dotnet. But C/C++ has one layer of abstraction (the compiler), and it's locked in once I compile it.

I want to do the thing as exactly and consistently as possible in the simplest way possible!

A build environment that compiles .cpp alongside .cs (no automatic bindings, just compilation) would be so nice for this.

----

Example of what I mean regarding abstractions:

  void addBatch(int *a, int *b, int count)
  {
    for(int i=0; i<count; i++) 
      a[i] += b[i]; 
  }

versus:

    [MethodImpl(MethodImplOptions.AggressiveOptimization)]
    public static void AddBatch(int[] a, int[] b, int count)
    {
        ref int ra = ref MemoryMarshal.GetArrayDataReference(a);
        ref int rb = ref MemoryMarshal.GetArrayDataReference(b);
        for (nint i = 0, n = (nint)count; i < n; i++)
            Unsafe.Add(ref ra, i) += Unsafe.Add(ref rb, i);
    }

(This is obviously a contrived example, my point is to show the kinds of idioms at play.)

I was a developer on that version!

We got the team back together and did a spiritual successor, Marble It Up!. If you are still enjoying the original I’d recommend checking it out (on consoles and Steam).

Is there an example of this?

A skybox with depth is only marginally better than a skybox for any sort of 3d experience. Using the depth for occlusion would be kind of cool.

I would not expect much, but you'd have to measure to be sure.

If you actually have a million of something you're better off writing a custom manager thing to handle the bulk of the work anyway. For instance, if you're doing a brick building game where users might place a million bricks - maybe you want each brick to be an Actor for certain use cases, but you'd want to centralize all the collision, rendering, update logic. (This is what I did on a project with this exact use case and it worked nicely.)

Really interesting analysis of where the data lives… cutting 3-4 textures would save you more memory even in the 100k actor case, though.

As someone on the hiring side, I strongly agree with GP.

I can think of a specific example where someone with experience and strong qualifications pushed for a higher salary - which I agreed to - then struggled with the role and ended up not sticking around. In another instance, someone had lower qualifications and experience, but also negotiated hardest out of their hiring cohort - same outcome, plus they weren't a great fit personality wise.

Meanwhile, I can think of several other people who cross-trained from their initial non-technical careers at the local community college, came in with low experience, didn't negotiate aggressively (although did stand up for themselves)... They've done great work (and grown substantially and been good to work with) over the long term, and seem to enjoy working for me enough that a few who left for other jobs were interested in being hired again later on.

Negotiating employment terms is the first task you complete at a new job. It is a good predictor. If it leaves a bad taste in the mouth for either side, it's not a good sign of things to come...

I have a product that does exactly this. E-mail me at ben AT theengine DOT co, I'd love to show it to you and see if it would help.

This is stuff is such a PIA to parse. I assume it's just different teams doing different features over the years, and being alternately repulsed/seduced by each format. Probably features are implemented as libraries so there isn't a master oversight - they aren't trying to make iMessage's internal formats follow a consistent plan, just let all the libs coexist...

I wrote a tool to do automated QA on internet video (HLS/DASH, tech used for Netflix, YouTube, Twitch, etc.).

It evaluates streams against a database of 100 or so "quirks" that identify either general issues or issues that will only manifest on certain player libraries. For instance, specific "in spec" encodings which are actually non-standard in practice get flagged.

Built on TypeScript/node/Docker over the course of maybe 18 months. Used it fairly often when I was working in the space, not at all these days. Originally the plan was to license it as an enterprise vid tool.

(I've been considering open-sourcing it - would YOU use it if so?)