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.

The world falls into two categories for me. "Must be fast" and "I don't care (much)". C/C++ is ideal for the first one, and C# is awesome for the second.

My argument isn't that C# is bad or performance is unachievable. It's that the mental overhead to write something that has consistent, high performance in C/C++ is very low. In other words, for the amount of mental effort, knowledge, and iteration it takes to write something fast + maintainable in C#, would I be better served by just writing it in C/C++?

The linked assembly is almost certainly non-optimal; compare to -O3 of the C version: https://godbolt.org/z/f5qKhrq1G - I automatically get SIMD usage and many other optimizations.

You can certainly make the argument that if X, Y, Z is done, your thing would be fast/faster. But that's exactly my argument. I don't want to do X, Y, Z to get good results if I don't have to (`return ref Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(array), (nuint)index);` and using/not using `[MethodImpl(MethodImplOptions.AggressiveOptimization)]` are non-trivial mental overhead!).

I want to write `foo.bar` and get good, alloc free, optimized results... and more importantly, results that behave the same everywhere I deploy them, not dependent on language version, JIT specifics, etc.

If I was operating in a domain where I could not ever take the C/C++ path, these features of C# are of course very welcome. And in general more power/expressiveness is very good. But circling back, I wonder if my energy is better spent doing a C version than contorting C# to do what I want.

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]; 
  }

    [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);
    }

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

Given what's there today, especially the sizzle reel, I'm pretty dubious.

If the author drops an amazing generative text-to-sim system on top of this... THAT is impressive - but effectively orthogonal to what's there - so I'm withholding excitement for now.

Take the time to read over the repo. It is not revolutionary. It is an integration of a bunch of third party packages (which are largely C/C++ libraries with Python wrappers, not "pure python"!). The stuff unique to Genesis is adequate implementations of well-known techniques, or integration code.

The backflip is awesome but plausibly explained by the third party RL library, and they include an example program which... runs a third party library to do just this.

The performance numbers are so far beyond real world numbers as to be incoherent. If you redefine what all the words mean, then the claims are not comparable to existing claims using the same words. 43 million FPS means, if my math is right, you are spending 70 clocks per frame on a 3ghz processor. On a 4080 you would have ~500k clocks in the same period, but that implies 100% utilization with zero overhead from Amdahl's law. (Also, Hi, Erwin, maybe you think these claims are 100% realistic for meaningful workloads in which case I'll gladly eat crow since I have a huge amount of respect for Bullet!)

I can only judge what's released now, not a theoretical future release, and what's here now is something a really good developer could bang out in a couple of months. The USP is the really good spin around the idea that it's uniquely suited for AI to produce beyond-SOTA results.

I have slightly longer form thoughts: https://x.com/bengarney/status/1869803238389887016

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

The code signing process has sucked and always been deeply cryptic, even on macOS - getting something usable and improvable that's cross platform is a fantastic win.

I'd label Warden an "AI maximalist" approach. Also has a lot of merit and is very interesting, but much harder to have fine control or tweakability, and much much harder to do fully hands off. "Hands off"-ability is an important metric because it's useful to not babysit every second of footage.

Writing comedy is really hard! Great concept for a show, tho. TBH a good example of something that could be interesting and viable with a tool like On Screen but never make it as a studio or even indie production.

The scope and target complexity of the series I'm making with On Screen is _dramatically_ cut down from what I started with, and it's still a bit of a stretch for the models at times. I started at DS9/Babylon 5 and ended up at Flash Gordon...

I agree, BTS is definitely very interesting.

But I had 8 kids 5-15 watch all of Ep1 _AND_ choose to watch Ep2 afterwards last night. They actually sat and watched, too, instead of having it on in the background... AND they were bummed they couldn't watch the super secret pilot episode (which has MAJOR audio issues - I couldn't bring myself to inflict it on them).

So I think something is there.

I agree, there are some great opportunities to track things somewhat more quantitatively. It takes ~15 minutes and $10 bucks to generate a script depending on how fast OpenAI is feeling. So in a real scale v2 it would be very reasonable to explore this.

Man, I sure hope I get to build this further!

Good call on the playlist. I'll do that soon. I agree, ep1 is rough.

I shot you an e-mail on a v2. (An MVP would be less; I realized I sent you the pitch for a full v2.)

There are a LOT of art packs out there for a ton of different looks and genres. Building sets is quick and easy even with kitbashing. I think you could synthesize 3d content in a lot of ways (vid2vid, Gaussian diffusion generative models, prop placement by LLM, clever use of stable diffusion/firefly for mattes, etc.) or have a small stable of fiverr types to make art for people on demand in a specific style...

Great feedback. Thank you Mike and HanClinto.

I am planning on doing some more articles/director commentary as it goes along.

I have a number of episodes in the queue and each one is better than the last. My plan is to release an entire season of 12 or so.

The "I'm a GPT that wants everyone to be friends and how" is increasingly better in those episodes.

Even incremental improvements in stuff like background music make a big big difference.

I really want to do a v2 that is more of a "copilot" than an "AI first" experience. But I need partners to help with funding; I've taken it about as far as I can on a solo basis. The next step is a team of 4-5 people levelling it up. Every piece could be 10x better, and it would be a different beast entirely if that happened. I think there are some super exciting directions this could go.

The vision of a distributed creator system is very interesting, as is letting people do more hands-on writing/rewriting.

If any VCs are reading, I'd love to talk. :)

(PS - Hi Han!)

Yeah - I think you don't necessarily (or only the best) go to a Netflix or MGM, but you could see success like a lot of smaller podcast content creators do.

10,000 screaming fans can take you a long long way.

For those interested - you can see actual episodes here: https://www.youtube.com/@OnScreenShow

It's interesting to consider "AI as its own genre" rather than "AI replacing mainstream content" - like how cheap animation enabled the anime genre or cheap filmmaking enabled the indie genre.

I wrote an autonomous AI space opera tv show generator. It takes a short topic phrase on one end and spits out a 10-15 minute 3D animated and AI voiced video suitable for upload to YouTube on the other end.

Super interesting learning exercise since it intersects with many enterprise topics, but the output is of course more fun.

In some ways it is more challenging - a summary is still useful if it misses a point or is a little scrambled, whereas when a story drops a thread it’s much more immediately problematic.

I’m working on a blog post as well as getting a dozen episodes uploaded for “season 1”.

https://bengarney.com

Most notable is an article series I wrote about making your own video conferencing app from scratch, including networking + codec.

Disclaimer: I spent five years working at GarageGames doing core Torque development (the Tribes 2 engine derivative we sold).

The core code was pretty clean but there was a LOT of cruft on top of this part which tended to obscure the really good bits. IMHO the library that handled the animation was genius - it was incredibly light, it supported a broad featureset, and it could load any old asset from v1 up to v30. It even did a bunch of crazy data layout stuff to allow extremely fast endian conversion for PPC vs Intel (back when that mattered).

Good efficient networking for that era meant you had to be miserly with your resources. Tribes 2/Torque was very much aligned with these requirements and your example is actually a good example of those strengths.

The engine had three update cycles, all in service of the networking.

First, it would process fixed timestep logic - ticks guaranteed at 32 per second (this also aligned with packet send rate). Client and server both ran this. This is physics, user input, health management, etc.

Second, it would run "time" based logic. This would be things like particle systems which don't care a lot about whether you advance them 100ms at a time or 1ms at a time, and don't need to match precisely for gameplay anyway. Only client ran this.

Third, it would interpolate tick state. This would smoothly interpolate between the last and current game state based on how far you were between the two states. It introduced a small amount of lag but since it did not predict it never caused visual glitches. This is gave a smooth appearance for any of the stuff that happened in the first step. Only client ran this.

The result of all this machinery is that you paid exactly what you needed to for each type of thing in your simulation and no more.

Later versions of the engine added lag compensation. This meant that client would snapshot game state and re-run the fixed timestep logic for compensated objects based on latency. You could configure it to only consider objects that might have interacted with the player (and thus were mispredicted) to save on CPU.

What happened in the case of authoritative skeletal animation?

1. Gameplay relevant parts of the skeleton would be simulated in the fixed ticks. For instance, the current orientation of a player's weapon which might need to take their animation pose into account. So you might see the spine and one arm updated here, while legs wouldn't be touched.

2. In the time based logic, you would run the full skeletal animation update so that the player could see smooth animation.

3. In the interpolation phase, you would interpolate the position of the player between the two states to give a smooth appearance (in conjunction with the animation work in phase 2).

I would submit the above is actually a pretty elegant solution to the above. Unfortunately the surface level code was all cut down versions of Tribes code which was written with shipping, not long term reuse, in mind.

Most of the community developers never really got their hands wrapped around this architectural stuff. A big fault of our core engine product was that it was oriented towards AAA projects and we never really made it both user friendly AND powerful. So we went with powerful but that didn't serve our indie customer base well.

It took Unity around a decade and $500M to add "really powerful" to "easy to use" so I don't feel too bad about this.

I've been in games and game middleware (including in many cases with Linux support) for fifteen years and I have never once seen this happen. Generally there is a tremendous amount of commentary like this from Linux folks and the port neither gets meaningful (or profitable) publicity nor sales that outstrip support. This comment is the stereotypical Linux game post.

When supporting a platform can mean debugging and submitting patches for a users graphics drivers in exchange for a shockingly low conversion rate, it's an easy no for me.

PS I built and maintain an Enterprise AWS GPU app on Ubuntu and the platform is great. But it was very non trivial to get working.

PPS if you spend less than $150/yr combined on all software purchases (including mobile/console) please don't make a case for Linux gaming. TuxRacer is your apotheosis.

Game Closure | Engineer | SALARY: $100k - 150k | San Francisco Bay area (SF) | Tokyo, Japan | Eugene, Oregon | VISA REMOTE

Game Closure is behind Everwing, the top game on Facebook’s Instant Games platform. In parallel, we’ve built the world’s most advanced javascript game engine for messenger games. We’ve raised more than $30M, and we have more than a million users per engineer at the company.

Our technologies and games have already been in front of many tens of millions of users, and we’re adding millions of new users monthly.

The Game Closure team is growing very rapidly. We need senior engineers for game development and game engine technology roles. These are high leverage senior positions. Remote workers are welcome. Our teams are already highly distributed because we’re looking to build the best engineering team in the world.

Outside of our games, we have projects for hosted real-time multiplayer gaming, social gaming, cross-compilation to native platforms, React integration, and many other core infrastructure tools that we would welcome your support on defining and creating.

Please email linda@gameclosure.com

Subject: Game Closure Core Engineer: YOUR NAME HERE

Please include a personal note about your background and interests so we can prioritize your application!

Best, Ben Garney VP Engineering, Core Tech

Game Closure | Engineer | SALARY: $100k - 150k | San Francisco Bay area (SF) | Tokyo, Japan | Eugene, Oregon | VISA REMOTE

Game Closure is behind Everwing, the top game on Facebook’s Instant Games platform. In parallel, we’ve built the world’s most advanced javascript game engine for messenger games. We’ve raised more than $30M, and we have more than a million users per engineer at the company.

Our technologies and games have already been in front of many tens of millions of users, and we’re adding millions of new users monthly.

The Game Closure team is growing very rapidly. We need senior engineers for game development and game engine technology roles. These are high leverage senior positions. Remote workers are welcome. Our teams are already highly distributed because we’re looking to build the best engineering team in the world.

Outside of our games, we have projects for hosted real-time multiplayer gaming, social gaming, cross-compilation to native platforms, React integration, and many other core infrastructure tools that we would welcome your support on defining and creating.

Please email linda@gameclosure.com

Subject: Game Closure Core Engineer: YOUR NAME HERE

Please include a personal note about your background and interests so we can prioritize your application!

Best, Ben Garney VP Engineering, Core Tech

Game Closure | Engineer | SALARY: $100k - 150k | San Francisco Bay area (SF) | Tokyo, Japan | Eugene, Oregon | VISA REMOTE

Game Closure is behind Everwing, the top game on Facebook’s Instant Games platform. In parallel, we’ve built the world’s most advanced javascript game engine for messenger games. We’ve raised more than $30M, and we have more than a million users per engineer at the company.

Our technologies and games have already been in front of many tens of millions of users, and we’re adding millions of new users monthly.

The Game Closure team is growing very rapidly. We need senior engineers for game development and game engine technology roles. These are high leverage senior positions. Remote workers are welcome. Our teams are already highly distributed because we’re looking to build the best engineering team in the world.

Outside of our games, we have projects for hosted real-time multiplayer gaming, social gaming, cross-compilation to native platforms, React integration, and many other core infrastructure tools that we would welcome your support on defining and creating.

Please email linda@gameclosure.com

Subject: Game Closure Core Engineer: YOUR NAME HERE

Please include a personal note about your background and interests so we can prioritize your application!

Best, Ben

Blackstorm | Engineer | SALARY: $100k - 150k | San Francisco Bay area (SF) | Tokyo, Japan | Eugene, Oregon | VISA REMOTE

Blackstorm is behind Everwing, the top game on Facebook's Instant Games platform. In parallel, we've built the world's most advanced javascript game engine for messenger games. We've raised more than $30M, and we have more than a million users per engineer at the company.

Our technologies and games have already been in front of many tens of millions of users, and we're adding millions of new users monthly.

The Blackstorm team is growing very rapidly. We need senior engineers for game development and game engine technology roles. These are high leverage senior positions. Remote workers are welcome. Our teams are already highly distributed because we're looking to build the best engineering team in the world.

Outside of our games, we have projects for hosted real-time multiplayer gaming, social gaming, cross-compilation to native platforms, React integration, and many other core infrastructure tools that we would welcome your support on defining and creating.

Please email linda@blackstormlabs.com

Subject: Blackstorm Core Engineer: YOUR NAME HERE

Please include a personal note about your background and interests so we can prioritize your application!

Best,