![]() It is registered at a global level within the project. Class_name allows you to assign a custom class identifier (that still extends one of the core Godot classes). So how do we fix this? The answer is class_name. Was it enemy, Enemy or Walking_Enemy? Not to mention typos in your code, one misplaced letter or capitalisation and suddenly your otherwise perfectly working code will mis-identify your enemy every time. It’s also quite hard to keep track of which group names you have already used and which you haven’t, leading to potential mix ups as in the point before. For example group names are case sensitive: Enemy is not the same as enemy or EneMY.īecause you can add any node to any group, you can, and might, accidentally add the enemy’s collision object to the enemy group and all of a sudden if you’re expecting all enemies to be of type KinematicBody they’re now KinematicBodies and CollisionShapes and you’ve got a confusing mess on your hands (yes I’ve done this). This can work great for simple projects and is often my preferred way to do things in Godot. ![]() You can find all objects in the SceneTree belonging to a single group, perhaps to connect signals to them by using get_tree().get_nodes_in_group(). You can then check if the colliding object is_in_group(). All enemies would belong to the “enemy” group. You can assign a node to any number of groups and therefore you could identify nodes by the group they’re in. extends Node # Autoload script exampleĬonst Player = preload("res://Player.gd")Ĭonst BaseEnemy = preload("res://Enemy.gd")Ĭonst Pickup = preload("res://Pickup.gd")Īs an alternative Godot has the group system. As such it’s better left for really small prototype projects or one off cases where other solutions might be too heavy to engineer such as a mod or achievement that needs to check something very specific. This is a fine solution but it can lead to lots of preloads around your code or moving everything up into an autoload where you have a class full of nothing but preloaded scripts to check objects against (see code below). If collider is preload(“res://Enemy.gd”): # Do the thing to the enemy Well, one option is to check the script type of the object you’ve collided with. This will work well enough if you can guarantee that you’re interacting with an enemy but what if you collide with a wall or a trap which has completely different functionality to an enemy and therefore doesn’t use the same base script? Upon player collision with the enemy you can just check the enemy_type and retrieve the relevant data. If body.has_method("take_damage"): # basic sanity checkingīut now what if you need to identify the type of this enemy from another script, such as the player script, how will you do it? You could give the enemy class a var enemy_type field and assign it values such as “walker”, “seeker” etc. Move_and_slide(vel * direction, Vector2.UP)įunc _on_Area_Body_entered(body): # Only bodies in the player collision layer can be detected, must be a player, do hurt ![]() Var direction = get_direction() # Will check for position and change direction if needed # On enemy collision layer, player collision mask extends Node2D # Enemy that just walks back and forth on a platform If you’re making a 2D platformer and one of your enemies just walks along the platform then back again you can probably leave your class as it is, its behaviour can be fairly safely self-contained, collision layers will probably be enough for any basic interaction checking, for example: was the collider in the player collision layer? Then deal damage to the player, simple. Most scripts are fine being just an extension of one of the core classes however it can be useful to have a bit more control over identifying and instancing scripts with custom behaviour. In Godot (talking mainly about GDscript) all scripts extend one of the base classes Object/Node with further extensions below that. In this quick tip I’ll explain what class_name in Godot 3.1+ does and when and why you should use it.
0 Comments
Leave a Reply. |