Tag: ECS

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.

 

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.