[Tutorial] Making a video series on a 2D platformer if anyone wants to watch!

Hey guys, i started a series on making a 2D platformer with Unity Tiny.

Currently i just have the first 2 videos out, one shows an overview of what we will be doing in the first couple videos and the second one is how to use Tilemaps with Unity TIny! We also set up a ruletile and i go over how to use them and set them up

Any feedback is appreciated

 

The next part in my Unity Tiny series is out if anyones following along! This video is also useful as a standalone because it shows the correct workflow for setting up your Unity Tiny workflow

 

Thanks alot! Im trying to get my video quality up so i can make quality C# videos when its released!

 

Made another video showing how to use facebook instants leaderboards with Unity Tiny

I also made a written version of the tutorial which can be found here:
https://docs.google.com/document/d/1FrZsvq64sYzquHkVPcLTGZOXRMoMPUi3MAC6L-K7XsU/edit?usp=sharing

 

Hey, good presentation of tiny here. Ive been struggling with it for a week now and Ive just discovered your videos.

I like the fact that you manage to do what you want to achieve however Ive noticed you're using a lot of "singleton like" patterns like your Systems with static functions etc, finding object by a hard string reference. I think for now I'm gonna stick with what you're doing because I can't manage to do otherwise but is that really how ECS is supposed to be used, even though I know thats what Mike Geig does in his tutorial series ?

For now I am really struggling with how to make my different systems communicate with each other, I simply can't manage to do something as simple as incrementing a score and displaying it on screen on a UI text.
Also, I have some UI for the game state and some UI for the endgame state, and I can't just instantiate things the way I want (because canvases requires cameras inside of the entity group, so if I have two separate UI groups I need 2 cameras).
For now, ECS feels a lot complicated especially even for doing things that would take not more than 1 min to achieve on classic oop style.

 

@Neriad
There's definitely some "getting-used-to" for ECS, but when you have some experience and feel comfortable with it, it doesn't take as long to do normal stuff... take that from me (I've been working with Tiny for the past few months now).

As for the "singleton like" patterns: there's no need to do any of that.

Finding objects (or rather entities) can be achieved by having an "EntityReference" field in your component. You can then assign an entity to that field in the editor inspector by dragging an entity (from the same EntityGroup!) into the slot on the component on an entity.

I do use some static functions myself for convenience and to avoid code duplication (also generic static functions are useful here). However I never put those functions in my Systems, I have some static utility classes for that (e.g. EntityUtils, MathUtils, TimeUtils, ColourUtils, etc.).

 

Hi, this has been really helpful (like a lot I don't know how to say how much). I'm so new to ECS

 

Alot of the things in the video i try to make more simple to understand and static references make things easier a good bit of times. (also im not a professional at ECS im new too it too, so if at anytime someone sees a better way to do something feel free to let me know! Criticism is important)

It probably would be best to have a ScoreSystem that listens for when a component called ScoreCounter gains a value, and that ScoreSystem could be used for determining highscores and what not. Then you could also have your UI system listen to the ScoreCounter component for updating the UI. Then i suppose you should use a forEach to search for the ScoreCounter to adjust the score instead of accessing it with a static function. But then i feel like youd be mucking up another class by searching for the scoreCounter to adjust it

Honestly not 100% on the best method for it, would love to hear some input!


Here soon im going to stop this series im doing and make one off videos on how to do things instead of a series on how to make a specific game. I think it will allow me to better think out the correct way to do stuff so im not considering a full project and instead can focus on just the system that needs being made for the video topic


Also

 

Your videos are really great!

Looking forward to your future content, whatever the format will be.

I would realy love some videos on how to write clean ECS too.

 

thanks alot, if you have any suggestions or anything feel free to let me know!

 

This already seems better. However, there's no need to "search" for the scoreCounter if you add an EntityReference field to a component of the entities that add score.

You also mention listening for updates of a value, which isn't really the ECS way as far as I know. Although I indeed find patterns like the regular Unity's

UnityEvent

to generically make stuff happen at an event quite beautiful, here in Tiny I tend to set everything up in a way that the entity firing an event pretty much knows what other entities will do something with that.
One way to keep it slightly generic still, is that I try to communicate only a small amount of data from one component to another, and then let the system of the other component handle as much of the logic itself. For example when I have a ScoreManager component, a HitDetection system of enemies and the player will access the ScoreManager (via EntityReference from the Player Component) and increase a value of "EnemiesHit" by 1 when the player collides with an enemy. The system for the ScoreManager then picks this value and does its things with it, like multiplying "EnemiesHit" value with "ScorePerEnemy" value and setting the text in a TextReference component, which will then update the UI.
This way, the responsibilities per component/system still stay mostly separate while preserving the ECS kind of way.

To me this seemed like a pretty good way of doing things, but I'd love to hear thoughts on it.

 

Wouldn't it be a bit cleaner if instead of modifying the "EnemiesHit" property of the ScoreManager component on the referenced entity, you just add a component to that entity? This could just be an empty tag component in this case, or with some data if needed. So instead of the HitDetection system having knowledge about incrementing "EnemiesHit", the Score system handles all that logic.

I'm also trying to get my head around thinking the ECS way, so these kind of discussions are great.

 

It would indeed further separate responsibility of the components, which is indeed cleaner. I am, however, worried that it will mean having an extra forEach loop (with the ScoreManager and the new EnemiesHit components) and that being more performance-costly than a single check to see if the "EnemiesHit" value in the ScoreManager is greater than zero.

This is why I chose to put it in the ScoreManager. I chose to mostly focus my "single responsibility" on the systems, and not so much on the components.

But it's definitely a clean way, I think. Great input

 

I was thinking that the existing system handling the ScoreManager would also query for the "EnemiesHit" component in the same forEach loop. But I'm also just assuming things without knowing the code so I could be missing something

 

with the adding a reference to the UI for displaying the score, wouldnt you normally store the UI in a deferent EntityGroup, so its not really feasable to store it in an enttity reference. Or do you search and store it when instantiating in your UI?

I guess it make more sense to store the entity reference on the ScoreDisplay component and when you instantiate the UI in, populate the EntityReference field with the score that your pulling the value from instead of storing a static reference too it like this. Would you agree?

 

I definitely think it's better to populate the EntityReference field instead of storing a static reference in a system (in fact, I try to never store any data of any kind in a system... at most I have a few Global variables in a separate class), since that is the ECS kind of way.

As for the UI, I don't have my UI in a different EntityGroup so I don't have the problem of not being able to set the EntityReference. However I can fully understand a use case for having the UI in a different EntityGroup and then I think the best way to get the reference is indeed looking it up by name once and then setting it to an EntityReference field.
The only thing I would change in such a situation is that I'd set the hardcoded string of the entity name as a field in the component instead of having a "magic string" in the code (which is still sort of storing data in your system instead of the component).

 

Yeah that makes sense! I agree for sure.

Thanks for the reply!