Why I’ve avoided Shader Graph

Shader Graph has been out for a while now but for some reason, it’s something I’ve always avoided. In a way, crystallizing on why that is has helped me understand what aspects of game development I don’t actually love. There’s two main aspects of this feature that kept me away; Low-level, math-focused programming and the creativity needed in an artist. Forcing myself to use this feature helped me understand these aspects and reflect on their relationship to my career. When one makes the decision to name them self an Engineer, they naturally want to excel at all the aspects that fall under that umbrella, otherwise is to fail in some way. What I’ve learned is that acknowledging my limitations in ability and interest will result in excelling in the areas that do motivate me, which inevitably leads to more productivity and better quality work.

Personal experience aside, Shader Graph is an extremely useful feature in implementing even basic visual effects. I learned of it’s usefulness not only on Mesh Materials but also how it could be used on sprites and particle systems:

If I’m being honest, I think the real reason I wanted to get familiar with this feature is just so I could get some experience with Unity’s official implementation of visual scripting. With that said, it felt very familiar to other visual scripting solutions with the only real feature that stood out was the gradient-colored connections between nodes. I’m hoping to see some innovation in their implementation in the future, but at the very least, they have a ton of examples to learn from.

The problem of scope under tight time constraints

I had an idea, make a simple game using the ‘standard’ Unity approach then remake the same game with Bolt and again with ECS. I wanted to really see the practical differences, the strengths and weaknesses of each approach. I knew it would have to be a very small scale project to keep things simple so I went with the classic Flappy Bird. Immediately starting the first version of the project I began to run into the same conundrum that I always run into when doing small-scale projects or gamejams, how much do I invest into foundational architecture and keeping things generic versus just getting shit done.

The Game Jam dilemma

This is a problem that I’ve never really took the time to nail down. I also think deep-down sometimes I claim to make decisions that may not be perfect with the excuse of time constraints (when the reality is that I may not actually know what the perfect solution is, or just too lazy). There’s also the lingering knowledge that “if i would have done it this way, then it would have worked out better” but the reality is that you’ll never know because you typically never go back and make that change and the game’s scope is small enough that is ultimately doesn’t matter.

So I had a new idea, I’ll make the game as if I’m under gamejam conditions but keep track of all the shortcuts, crossroads and architectural decisions I’ve made that are suspect. Afterwards, I will expand the game and see what decisions were the right call and what screwed me later in development. I can also go back and perhaps do things different just to compare which way was faster.

Here’s an example of some of the notes I took:

As always, here’s the source.

 

The UI layer keeps dying..

While working on the recent Ludum Dare, a few friends asked for a quick component to show a path to a target point. Instinctively I started working on converting 3d points to 2d lines.

It was a complicated translation, but it worked. It was clear that it wasn’t going to hold up with complicated paths with varying depth.

I started ‘fixing’ it to change it’s look based on the distance from the camera and then had a moment of clarity, why not just render the path in the 3d space? It’s a solution that I seem to come about more and more lately.

A lot better, now it can have natural depth, be effected by lighting and match post-processing effects in the game.