Deathzone on it's own layer

The tutorial instructs to put the death zone on it’s own layer with a mask of the enemy layer. Since this zone if for enemies, is there any reason why it coun’t be on the enemy layer with an enemy layer mask? Is there an idomatic or other reason for placing the deathzone in its own layer?

This could be a teaching point as we make courses based on a spiral syllabus so that we can cover aspects but there is always more than one way of doing things.
I would give a try and let us know if you come up against any issues with it.

Thanks for the reply, Marc. This is how I implemented it; all seemed to work as expected in this simple case. I understand there are many ways to do things, and I was looking to find out if there are specific reasons why it was done that way. Just because something works doesn’t mean it’s correct :wink:. For example, your other recent response on position vs global_position Global_position vs position.

Thinking on this a little longer it makes more sense to me to have the layer on the deathzone and masking the enemy. Usually when you create a game you might make multiple enemies and they would all inherit from a base class called “Enemy”, Doing it this way means that anything that is an Enemy is destroyed.
If you did it the other way around and forgot to correctly set the layer on the enemy then it would not be destroyed. This way just ensures that it only needs to be done the once and not every time you create a new enemy.
You are correct in that just because you could does not mean that you should.

Thank you for the reply. What I am trying to understand is why the death zone needs to be on it’s own layer. Perhaps it’s simply good practice, which I respect.

What are we gaining by putting the death zone on one layer and masking the enemy layer vs. putting the death zone on the enemy layer and masking the enemy layer (which is the same layer)? Where my head is on setting it up this way is that everything enemy-related is on the same layer: the enemies and the death zone.

I seem to remember this is just good practice and it is not limited just to the Godot engine.
Back when i was first learning and Godot was still in its infancy stages i was using Unity and learning to make a breakout type game and we destroyed the ball when it went passed the bat in much the same method.
It seems it is just standard practice to have a zone to destroy items that are no longer needed in any scene.

A more advance technique classes in our Godot 3D course and to reiterate my previous reply…
You create the code for the base enemy called “Enemy” and at the top of that script you create the line “class Enemy” this makes that available anywhere in the code.
This method means that you can check in the death zone “if is Enemy” then destroy it which negates the need to deal with layers.
Apologies if that wasnt very clear in my last post

What is good practice? I would like to make sure I am understanding correctly. Thank you for you time.

Good practice can cover many different aspects of game development but for this example its making it modular so things can be reused with little effort to remake.
An example would also be that games are often developed in teams and so the level designer for example wont know coding and will just use the assets available to them so often its easier for them to understand “This is the death zone” and this kills the enemy. Its also that the script can be reused for hazards like if you were making a platformer (which we do later in the course) the death zone could essentially be used like a “hazard” and be spikes for example.

Other aspects include good naming of variables so they are simple but descriptive enough that you can see at a glance what they do and the same for a block of coding without the need for lots of descriptive comments within that code.

Overall as said before in this example its the modular aspect and ease to understand that the deathzone has a deathzone layer.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms