DodgerV2 Part 2: "Techstack"

In the last post I spoke briefly about the vision I have for the game as well as what Dodger “Classic” was. Today we are going to talk about the tech that will actually drive the gameplay.

Unity2D, one of the more well known “free” game engines.

So why am I going with Unity?

1. Unity handles 2D really well compared to Unreal Engine 4 (my usual engine of choice).
2. Dodger Classic was made in Unity and I want to see how much better I can make it now with a few more years of programming and game development knowledge.
3. Unity has had a lot of updates since I last used it for a serious project and they have added some very interesting stuff since then that I really want to use.

What interesting stuff has Unity added exactly?

What I am primarily interested is DOTS (“Data Oriented Technology Stack”) which is a more data driven way to of handling logic. I will talk about this more later on in this post.

The other thing I am interested in is their new Input System (which reminds me a lot of how Unreal Engine handles input) and from what I have seen so far it seems quite good and I want to test it out. I am not sure how much I will actually get to use it though since DodgerV2 is first and foremost a mobile game. Hopefully it will be useful for the eventual PC implementation though.

What is DOTS?

The Data Oriented Technology Stack (DOTS) is Unity’s ECS implementation. ECS (Entity Component System) is a more CPU-Cache friendly way of handling logic and data. I am in no way an expert on ECS but I will try to explain how it works and why it is faster as best I can.

Instead of GameObjects you have entities which hold Components. Components hold data. Systems hold logic. If we for example want to rotate a lot of cubes in the world the usual way of doing it in Unity is having a MonoBehaviour like this and placing it on all those objects:

The problem with this is that there is no guarantee that every object with this MonoBehaviour will update after each other so the instructions might be kicked out of the CPU’s instruction cache and then it has to get it from the RAM or slower cache. Getting it from a slower cache or RAM is terrible for performance, we just waste cycles waiting for it. What if instead we could just do all of this logic for everything that needs it at the same time? Then we wouldn’t have to wait and that is what ECS is good for.

The example I am going to show now is a hybrid ECS approach where data is in MonoBehaviours. It does the exact same thing though and will in theory perform much better at higher amounts of objects. Not to mention that ECS in Unity can be run in parallel which means we can use multiple cores to our advantage (In DodgerV2 this would allows us to process both Asteroid and Bullet movement at the same time in 2 threads).

Use in DodgerV2

For DodgerV2 I will be using the Hybrid ECS that I showed above approach because I need collision and that isn’t implemented in ECS yet. If that were to be implemented it would be perfect for this project but I am not going to work on that or wait for it.

I will have 2 Entity types:

1. Bullets
2. Asteroids

Because both of those entities only move forward we only need one system for them the ForwardMovementSystem. It will just move the entities forward based on their speed.

For the speed we need a component, we’ll just call this the MovementComponent and all it will just hold a float Speed.

And that is pretty much the whole implementation of ECS I will be using. Pretty simple.

And this was all I wanted to cover in this post. The next post will be the first more journal like one so it might be quite different but it will be talking about market research.

Click here to go to the next post: Part 3: “Market research & Journaling”.

Written 21 Nov 2019 by Grim