Last but not least you would spread out functionality over more than one class. And if you now want an object that does only one of those things you have a problem. So if the game grows and the functionality expands having that base class may not only mean that an object reacts to shots but also that it collides with certain obstacles. You can only have one base class for all classes that want to react to shots. The first case was about combining effects, now it's about splitting them up. You would basically be using a base class as an interface, and since you can only have one base class you would make interface segregation impossible, which is kind of the opposite case of what I described before. But what if you then decide to have an item that damages the player but heals enemies? Such an item would have to inherit from two base classes, which is not allowed in GDscript (for good reasons). You would probably use the same method for that. Let's say you want to add items that heal players or enemies that touch them. The base class approach you describe has a couple of downsides.
I'd be interested to hear your doubts about the has_method-approach. Is this any different from checking has_method(.)? If I wanted to have another thing that damages the player, the only thing that I had to do is to attach an Area2D and attach a script to that new Area2D that extends from the script DamagingAreas2D If area_node_that_entered is DamagingAreas2D: Onready var DamagingAreas2D = preload("res://scripts/DamagingAreas2D.gd")įunc on_PlayerArea2D_area_entered(area_node_that_entered): Inside the function that handles the signal, I could have the following check Inside the Player script, I could connect the on_area_entered signal emmited by PlayerArea2D. An Area2D node attached to my bullet scene with a script that extends from Bullet script An Area2D node attached to my player's scene root node to detect collisions (PlayerArea2D)
The benefit is that if you want to add something later that also reacts to that collision you just have to add the method in question. That's the duck-typed version of interface segregation. Use has_method(.) to check if the object you are colliding with has the method that you intend to call.
GODOT NODE CODE
Instead of checking all objects and calling script code for all collisions let the physics engine only watch part of the objects and only call the script when it is needed. That way you store the important information in a way that allows the physics engine to use it for performance optimization. Use the physics layers and masks so that collision is only detected between the correct objects.There are two solutions that are both better in their own ways: HDRI Haven – CC0-licensed panorama skies.CC0 Textures ⋅ ⋅ Texture Haven – CC0-licensed PBR materials.Godot Shaders – Shaders specifically made for use in Godot Engine.Awesome Godot (curated list of Godot resources).Twitter Read before posting: Frequently Asked Questions Community Platforms Discord Contributors Chat Support Godot development on Patreon! Reference material.A community for discussion and support in development with the Godot game engine.
0 kommentar(er)
