Tag: Unity

Unity’s official Visual Scripting is here! Well, sort of…

substence Leave a comment

While Unity’s official Visual Scripting feature is not even slated for preview until 2020.1, Christmas came early last week when an experimental drop was posted on the beta forums.

Okay, so Unity has finally joined the fray of modern game engines, no big deal, right? In a sense, no. The first iteration is basically playing catch-up with everyone else, but there are a few notable features:

Code Generation

Every time the graph is compiled, it also spits out a generated code version of the graph. This is great way to learn what is happening under the hood, and can even give you some pointers on coding conventions. As an engineer first, this gives me great comfort and confidence in what the graphs are generating so I can focus on keeping the graph itself clean and not so worried about what’s happening behind the scenes. While the default viewer doesn’t let you edit the result, you can always find the actual file in your coding IDE and manipulate it in any way you please, granted your changes will be overridden in the next build.

D.O.T.S. Integration

Unity’s visual scripting is built from the ground-up with ECS(Entity Component System) in mind as part of their Data-Oriented Technology Stack(DOTS). In fact, there doesn’t seem to be any plans for it to work with the old Object-oriented model(monobehaviours, game objects, etc.) at all. While this is great for those of us who are excited to transition to the new paradigm, one of the biggest appeals of Visual Scripting is it’s entry-level usability and understanding.. which all goes out the window when attempting to use pure ECS. Let’s make a quick comparison to demonstrate:

  • In say, Blueprints, you would have a player object in the scene with a graph attached to it, this graph would have movement data and execute the act of moving the player.
  • In the world of Unity’s Visual Scripting you need a player object in the scene with an Authoring Component attached to it, which converts the object into an entity and adds a separate Runtime Component that stores the data needed for movement. Then you have to create a detached System Graph that executes the act of moving entities on entities that share the same components as the player.

All three of these aspects exist in separate parts of the editor (scene, code, graphs) yet they all have to work together perfectly to achieve even the simplest of tasks. I think this will be a deal-breaker for potential users looking to get into game development without an engineering background. There’s simply too many other easier/better ways to get into the game. With that said, both ECS and their Visual Scripting component are over a year out so there’s plenty of time to make the process easier.. but there’s a lot to overcome.

**Oh! Another feature worth mentioning is Live Edit, which lets you manipulate the graph while the game is running and see changes update in real-time. Unfortunately this didn’t seem to be working in this release so I didn’t get to see it hands-on.

 

Why I’ve avoided Shader Graph

substence Leave a comment

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.

Unity’s ECS isn’t quite ready for prime time.

substence Leave a comment

Per my previous post, I challenged myself to port the Flappy Bird project to Unity’s upcoming Entity Component System using both Pure and Hybrid implementations. While the Hybrid version was pretty straightforward, it became clear very quickly while working on a Pure ECS implementation that there was a lot of work left to do on it’s current state. Unity themselves have admitted to a lot of problems and potential changes to things like [Inject] and ComponentArray so I think it’s a good idea to avoid it for now. With that said, I plan to try to keep using the Hybrid version of ECS with all my future projects, at least where it’s convenient.

I did discover some interesting architecture tweaks like storing components and systems in the same file:

Also very useful was a global class for Archtypes:

As always, source is on my github.

 

The problem of scope under tight time constraints

substence Leave a comment

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.

 

2018 Unity update

substence Leave a comment

For the past year or so I’ve been working almost exclusively in Unreal but have always had one eye on Unity and have been dying to get my hands on some of the new features to come out recently.

Entity Component System

Pure ECS is a feature that has a very special place in my heart as one of the first big systems I made back in the Flash(actionscript) days was an ECS-like system. I even went on to contribute to a popular gaming package called the Push Button Engine which championed some of those same core ideas.

Nested Prefabs

Holy crap was this a feature that could have saved me so many headaches in the past. So much so that I even bought a 3rd party solution(unfortunately I wasn’t able to get my company to actually use it) . Even though I think it took too long for these problems to be addressed, I’m happy it was done holistically with a few important updates to Prefabs in general.

I made a small Asteroids-like game to test all these new features and was surprised at how fundamental different the new systems were, it’s going to take quite a bit of effort for teams to adopt the new way of development so I’m a bit skeptical of everyone immediately jumping on board.

Last on the list is a officially-ish supported Visual Scripting system called Bolt, which deserves it’s own post.