Godot: GDScript 특성 시스템을 추가합니다.

extends "res://move_right_trait.gd" 대신 어떤 이점이 있습니까?

@MrJustreborn 한 클래스에 여러 특성을 가질 수 있지만 하나의 스크립트만 상속할 수 있기 때문입니다.

내가 올바르게 이해한다면 이것은 기본적으로 C#이 " 인터페이스 "라고 부르는 것이지만 비추상 메서드를 사용하는 것입니까? 프로그래머에게 친숙한 특성 대신 기능 인터페이스를 호출하는 것이 더 나을 수 있습니다.

@aaronfranke Traits 는 기본적으로 Mixins 와 동일하며 메서드 구현이 포함되어 있기 때문에 인터페이스와 완전히 다른 사용 사례를 갖습니다. 인터페이스가 기본 구현을 제공했다면 실제로 더 이상 인터페이스가 아닐 것입니다.

Traits/Mixins는 PHP, Ruby, D, Rust, Haxe, Scala 및 기타 여러 언어 (링크된 Wiki에 자세히 설명되어 있음)에 있으므로 프로그래밍 언어에 대한 광범위한 레퍼토리를 가진 사람들에게 이미 널리 친숙해야 합니다.

우리가 인터페이스를 구현한다면(특히 선택적 정적 타이핑이 오는 경우에) 인터페이스를 구현하는 것은 사실상 함수 서명을 지정하고 관련 GDScript 스크립트가 특성을 사용하여 해당 함수 서명을 구현하도록 요구하는 방법일 것입니다. 포함됩니다(해당 시점까지 존재하는 경우).

includes 와 같은 키워드?

extends Node2D
includes TraitClass

특성, mixin, has 등과 같은 다른 이름도 확실히 괜찮습니다.

추가 메뉴에서 class_name 유형을 제외할 수 있는 옵션이 있다는 아이디어도 마음에 듭니다. 자체적으로 노드로 작동하지 않는 작은 유형으로 인해 매우 복잡해질 수 있습니다.

그 자체로 하나의 기능 주제일 수도 있습니다.

(실수로 내 댓글을 삭제했습니다, 웁스! 또한 "여러 스크립트를 허용하지 않는 이유는 단일화됩니다." )

이것이 VisualScript에서 어떻게 작동합니까?

또한 특성이 구현된 경우 특성에 대한 인스펙터 인터페이스를 포함하는 것이 도움이 될 수 있습니까? 특성에 대한 일부 사용 사례에는 특성만 있고 스크립트가 없는 사용 사례가 포함될 수 있다고 상상합니다(적어도 특성 파일을 포함하는 스크립트 외에는 스크립트가 없음). 하지만 곰곰이 생각해보면 트레이트 파일이 포함된 스크립트를 만드는 것보다 그런 인터페이스를 만드는 데 들인 노력이 그만한 가치가 있는지 궁금합니다.

@LikeLakers2

이것이 VisualScript에서 어떻게 작동합니까?

내가 제안한 방식으로 수행되면 VisualScript에서는 전혀 발생하지 않습니다. GDScript 전용. VisualScript에 대해 구현된 특성 시스템은 VisualScript가 구문 분석된 언어가 아니기 때문에 완전히 다르게 설계됩니다. 그러나 가능성을 전혀 배제하지 않습니다(다르게 구현해야 함). 또한 VisualScript 상속 지원을 먼저 고려해야 할까요? ㅋ ㅋ ㅋ

또한 특성이 구현된 경우 특성에 대한 인스펙터 인터페이스를 포함하는 것이 도움이 될 수 있습니까?

별 의미가 없을 것입니다. 특성은 특성, 상수, 신호 및 특성에 의해 정의된 메서드를 전달하여 GDScript에 세부 정보를 전달합니다.

특성에 대한 일부 사용 사례에는 특성만 있고 스크립트가 없는 사용 사례가 포함될 수 있다고 상상합니다(적어도 특성 파일을 포함하는 스크립트 외에는 스크립트가 없음).

다른 언어로 표시되는 특성은 단독으로 사용할 수 없지만 사용하려면 다른 스크립트에 포함 되어야 합니다 .

그러한 인터페이스를 만들기 위해 들인 노력이 그만한 가치가 있는지 궁금합니다.

어떤 식으로든 Inspector 인터페이스를 만드는 것은 GDScript 단독으로는 그다지 의미가 없습니다. 특성을 추가하거나 제거하려면 스크립트 리소스의 source_code 속성의 소스 코드를 직접 편집해야 합니다. 즉, 스크립트 자체의 속성이 아닙니다. 따라서 어느 쪽이든 ...

1. 편집기는 이를 수행하기 위해(오류가 발생하기 쉬운) GDScript 파일에 대한 소스 코드의 적절한 편집을 구체적으로 처리하는 방법을 가르쳐야 합니다. 또는...
2. 모든 스크립트는 GDScriptLanguage가 특성을 추가 및 제거하기 위한 자체 내부 프로세스를 제공할 수 있도록 특성을 지원해야 합니다(그러나 모든 언어가 특성을 지원하는 것은 아니므로 특성이 모든 경우에 의미가 없음).

그러한 기능이 필요한 이유는 무엇입니까? 이것이 지금 할 수 없는 것을 허용합니까? 아니면 일부 작업을 훨씬 더 빠르게 처리할 수 있습니까?

거의 사용되지 않는 복잡한 기능을 추가하는 것보다 GDscript를 단순한 언어로 유지하고 싶습니다.

그것은 이 사람이 문제를 가지고 있었던 Child-Nodes-As-Script-Dependencies 문제를 해결하지만 MultiScript가 단일 언어로 제한되어 있기 때문에 동일한 종류의 수하물 과 함께 제공되지 않습니다. GDScript 모듈은 특성이 서로 및 기본 스크립트와 어떻게 관련되는지에 대한 논리를 분리할 수 있지만 다른 언어 간의 차이점을 해결하는 것은 훨씬 더 복잡합니다.

다중 가져오기/다중 상속이 없기 때문에 스크립트 종속성을 자식 노드로 사용하는 것이 코드를 많이 반복하지 않는 유일한 방법이며 이는 확실히 문제를 좋은 방식으로 해결할 것입니다.

@groud @Zireael07 내 말은, 더 급진적인 교차 언어 접근 방식은 1) ScriptStack을 사용하여 누적된 스크립트를 단일 스크립트 표현으로 병합하도록 Object를 완전히 재설계하고, 2) MultiScript를 다시 도입하고 자동으로 변환하는 편집기 지원을 만드는 것입니다. 멀티스크립트에 스크립트 추가(또는 단순성을 위해 모든 스크립트를 멀티스크립트로 완전히 만드는 것, 이 경우 MultiScript의 구현은 본질적으로 ScriptStack이 됨), 또는 3) 병합할 수 있는 Object 유형에 대한 일종의 교차 언어 특성 시스템 구현 참조 확장 스크립트는 특성으로, 일반적인 스크립트와 마찬가지로 내용을 통합합니다. 이러한 모든 옵션은 엔진에 훨씬 더 침습적입니다. 이렇게 하면 모든 것이 더 간단해집니다.

나는 특성이 필요하다고 생각하지 않는다. 우리에게 가장 필요한 것은 빠른 엔진 릴리스 주기입니다. 내 말은 대부분의 IDE에서 플러그인 스타일과 같이 새 dll 정도 파일을 추가하고 엔진이 자동으로 통합되는 것처럼 새 기능을 추가하기 위해 엔진을 보다 유연하게 만들어야 한다는 뜻입니다. 예를 들어 websocket이 작동하는 데 정말 절실히 필요합니다. 3.1이 릴리스될 때까지 기다릴 필요가 없습니다. 3.1은 현재 너무 많은 버그로 인해 깨졌습니다. 이 기능이 있으면 좋을 것입니다. 새 클래스는 임의의 .dll 또는 일부 경로의 .so에서 GDScript에 자동 주입할 수 있습니다. 이것이 C++에서 얼마나 많은 노력을 기울였는지 모르지만 이것이 너무 어렵지 않기를 바랍니다 😁

@fian46 글쎄요, 누군가 웹 소켓을 다운로드 가능한 GDNative 플러그인으로 구현했다면 예, 당신이 설명한 것은 워크플로일 것입니다. 대신 그들은 바닐라 엔진에서 사용할 수 있는 통합 기능을 만들기로 결정했습니다. 사람들이 그런 식으로 기능을 만드는 것을 막을 수 있는 방법은 없으므로 귀하의 요점은 이 문제의 주제와 전혀 관련이 없습니다.

죄송합니다. GDNative가 존재하는지 모르겠습니다 😂😂😂. 특성은 훌륭하지만 가짜 특성 클래스를 만들고 인스턴스화하고 나중에 기본 스크립트처럼 함수를 호출하는 것이 더 쉽습니까?

Godot 스크립트가 이름 없는 클래스라면, "my_sprite.gd"에 "move_right_trait.gd"를 인스턴스화하지 않는 이유는 무엇입니까?
문제를 이해하지 못한다면 제 무지에 대해 사과드립니다.

Rust 또는 (인터페이스) C++와 같은 보다 강력한 형식의 언어에서 특성을 사용하는 것은 이해합니다. 하지만 더킹 형식의 언어에서는 약간 불필요하지 않습니까? 동일한 기능을 구현하기만 하면 유형 간에 균일한 인터페이스를 얻을 수 있습니다. GDScript가 인터페이스를 처리하는 방식이나 트레이트 시스템이 실제로 어떻게 도움이 되는지에 대한 정확한 문제가 무엇인지 확신이 서지 않습니다.

또한 preload("Some-other-behavior.gd")를 사용하고 결과를 변수에 저장하여 기본적으로 동일한 효과를 얻을 수 없습니까?

@fian46 @DriNeo 네, 그렇습니다. 스크립트를 로드하고 스크립트 클래스를 사용하면 이미 해결되지만 문제는 그 이상으로 확장됩니다.

@TheYokai

동일한 기능을 구현하면 유형 간에 균일한 인터페이스를 얻을 수 있습니다.

문제는 당신이 옳았던 균일한 인터페이스를 달성하는 것이 아니라 덕 타이핑이 잘 해결되는 것이 아니라 관련 구현의 그룹을 효율적으로 구성(결합/교체)하는 것입니다.

3.1에서는 스크립트 클래스를 사용하여 참조 스크립트(또는 실제로 모든 유형)에서 정적 함수를 정의한 다음 해당 스크립트를 네임스페이스로 사용하여 GDScript에서 해당 함수에 전역적으로 액세스할 수 있습니다.

extends Reference
class_name Game
static func print_text(p_text):
    print(p_text)
# can even add inner classes for sub-namespaces

extends Node
func _ready():
    Game.print_text("Hello World!")

그러나 비정적 콘텐츠, 특히 노드별 기능을 사용하는 콘텐츠의 경우 논리를 나누는 것이 번거롭습니다.

예를 들어, KinematicBody2D가 있고 "점프" 동작과 "실행" 동작을 갖고 싶다면 어떻게 합니까? 이러한 각 동작은 KinematicBody2D의 입력 처리 및 move_and_slide 기능에 액세스해야 합니다. 이상적으로는 각 동작의 구현을 독립적으로 교체하고 각 동작에 대한 모든 코드를 별도의 스크립트에 보관할 수 있습니다.

현재 내가 익숙한 모든 워크플로가 최적이 아닙니다.

1. 모든 구현을 동일한 스크립트에 유지하고 사용 중인 기능만 바꾸면...
   
   
   
   1. "동작"을 변경하려면 여러 기능을 세트로 교체해야 할 수 있으므로 구현 변경 사항을 효과적으로 그룹화할 수 없습니다.
   
   
   2. 모든 동작(X * Y)에 대한 모든 기능은 단일 스크립트에 있으므로 매우 빠르게 부풀려질 수 있습니다.
   
   
2. 전체 스크립트를 교체할 수 있지만 이는 모든 동작 조합 과 해당 동작을 사용하는 논리에 대해 새 스크립트를 생성해야 함을 의미합니다.
3. 자식 노드를 스크립트 종속성으로 사용하는 경우 부모를 잡고 상대적으로 말해서 일종의 부자연스러운 move_and_slide 메서드를 호출하는 이상한 "구성 요소" Node2D 노드가 있다는 의미입니다.
   
   
   
   • 부모가 해당 방법을 구현하거나 해당 방법이 있는지 확인하는 논리를 수행할 것이라고 가정해야 합니다. 확인을 하면 자동으로 실패하고 게임에 잠재적인 버그가 생길 수 있습니다. 또는 불필요하게 도구 스크립트로 전환하여 편집기에서 시각적으로 알려주도록 노드에 구성 경고를 설정할 수 있습니다. 문제가 있다는 것입니다.
   
   
   • 또한 노드는 Node2D에서 파생되고 핵심은 KinematicBody2D 부모의 동작을 구동하는 것이기 때문에 의도 한 노드 작업에 대한 적절한 코드 완성을 얻지 못합니다.
   
   

이제 옵션 3이 현재 가장 효과적인 워크플로이며 3.1에서 GDScript에 대한 편리한 정적 입력을 사용하여 문제를 대부분 해결할 수 있음을 인정합니다. 그러나 더 근본적인 문제가 있습니다.

Godot의 노드-씬 시스템은 일반적으로 사용자가 자신의 밀폐된 시스템에서 특정 작업을 수행하는 노드 또는 장면을 생성하는 형태를 가지고 있습니다. 다른 장면 내에서 해당 노드/장면을 인스턴스화하고 상위 장면에서 사용되는 데이터를 계산하도록 할 수 있습니다(예: Area2D 및 CollisionShape2D 관계의 경우).

그러나 바닐라 엔진의 사용 및 일반적인 모범 사례 권장 사항은 장면의 동작 을 루트 노드 및/또는 해당 스크립트에 고정된 상태로 유지하는 것입니다. 실제로 루트에게 무엇을 해야 하는지 알려주는 "동작 구성 요소" 노드는 거의 없습니다(있을 때 매우 투박하게 느껴집니다). AnimationPlayer/Tween 노드는 내가 생각할 수 있는 유일한 논쟁의 여지가 있는 예외이지만 해당 작업조차도 루트에 의해 지시됩니다(이는 일시적으로 제어를 효과적으로 위임합니다). (편집: 이 경우에도 애니메이션 및 트위닝 은 KinematicBody2D의 작업이 아니므 로 이러한 작업을 위임하는 것이 합리적입니다. 그러나 달리기 및 점프와 같은 움직임 은 책임입니다) 허용하는 것이 더 간단하고 자연스럽습니다. 노드 간의 관계를 엄격하게 데이터 업/동작 다운으로 유지하고 코드를 자체 스크립트 파일로 더 격리하도록 유지하므로 코드를 구성하기 위한 특성 구현.

어, 자신을 '인터페이스/특성 구현'으로 표시하는 것도 * is * 테스트를 수행해야 하는데, 이는 무언가의 기능을 테스트하는 데 편리합니다.

@OvermindDL1 제 말은 그런 테스트를 하는 예를 들었지만 상속과 특성 사용을 구분하고 싶었기 때문에 대신 in 를 사용했습니다.

여기에서 XY 문제에 빠진 것 같습니다. 저는 이 주제를 어떤 식으로든 다루었고 제안서를 제출할 것이라고 생각했던 2개의 다른 문제(#23052, #15996)에서 방금 나왔지만 모든 컨텍스트를 제공하지는 않았습니다.

@groud 이 솔루션은 #19486에 대해 제기된 문제 중 하나를 해결할 것입니다.

@willnationsdev 좋은 아이디어, 기대됩니다!

내 제한된 설명에서 이 특성 시스템이 달성하고자 하는 것은 이 비디오에 표시된 워크플로와 유사한 것을 활성화하는 것입니다. https://www.youtube.com/watch?v=raQ3iHhE_Kk
(사용된 기능이 아니라 표시된 _workflow_에 대해 이야기하고 있음을 고려하십시오.)

비디오에서는 장점과 단점이 있는 다른 종류의 워크플로와 비교합니다.

적어도 내가 아는 한 이러한 종류의 워크플로는 상속이 작동하는 방식 때문에 현재 GDScript에서는 불가능합니다.

@AfterRebelion 그가 코드베이스의 모듈성, 편집 가능성, 디버그 가능성(및 해당 속성의 관련 세부 정보)을 분리하는 비디오의 처음 몇 분 은 실제로 이 기능을 추구하는 것입니다.

적어도 내가 아는 한 이러한 종류의 워크플로는 상속이 작동하는 방식 때문에 현재 GDScript에서는 불가능합니다.

Godot는 노드 계층 구조와 디자인 씬과 관련하여 실제로 이것을 아주 잘 하기 때문에 이 부분은 사실이 아닙니다. 장면은 본질적으로 모듈식이며 코드를 처리하지 않고 편집기에서 직접 속성을 내보낼 수 있으며(심지어 애니메이션으로 만들기도 합니다) 장면이 독립적으로 실행될 수 있기 때문에 모든 것을 격리된 상태에서 테스트/디버깅할 수 있습니다.

어려움은 논리가 루트 노드의 상속된 기능에 의존하기 때문에 일반적으로 자식 노드에 아웃소싱되는 논리를 루트 노드에서 실행해야 하는 경우입니다. 이런 경우, 작문을 사용하는 유일한 방법은 부모가 사용하는 동안 자녀가 자신의 일에 신경을 쓰게 하기보다 부모에게 무엇을 해야 하는지 말하기 시작하도록 하는 것입니다.

GameObject에는 사용자가 활용할 수 있는 실제 상속이 없기 때문에 Unity에서는 문제가 되지 않습니다. Unreal에서는 Actor에 대해 유사한 노드/컴포넌트 기반 내부 계층 구조를 가지고 있기 때문에 약간(?) 문제가 될 수 있습니다.

자, 여기서 잠시 Devil 's Advocate를 플레이해 보겠습니다. Unreal에서 이러한 시스템을 작성하는 방법에 대해 생각하는 데 시간을 보냈고 이는 저에게 이에 대한 새로운 관점을 제공했습니다. 이것이 좋은 생각일 것이라고 생각한 사람들에게 죄송합니다 / 그것에 대해 흥분했습니다:

특성 시스템을 도입하면 유지 관리를 더 어렵게 만드는 언어인 GDScript에 복잡성 계층이 추가됩니다.

게다가, 특성으로서의 특성은 변수, 상수, 신호, 메서드, 심지어 하위 클래스 가 실제로 어디에서 왔는지 분리하기 어렵게 만듭니다. 노드의 스크립트에 갑자기 12개의 다른 특성이 있는 경우 모든 것이 어디에서 오는지 반드시 알 필요는 없습니다. 무언가에 대한 참조가 보이면 코드베이스에서 사물이 어디에 있는지 알기 위해 12개의 다른 파일을 살펴봐야 합니다.

주어진 문제는 코드 기반에서 평균 2~3개의 다른 위치를 선택해야 할 수 있기 때문에 이는 실제로 언어로서의 GDScript 의 디버깅 가능성을 저하시킵니다. 이러한 위치 중 하나라도 찾기 어려운 이유는 그들이 하나의 스크립트에 있다고 말하지만 실제로는 다른 곳에 있으며 코드의 가독성이 데이터/논리를 담당하는 것이 무엇인지 명확하게 나타내지 않으면 2 또는 3입니다. 단계는 임의의 크고 스트레스가 많은 단계 세트로 곱해지고 있습니다.

프로젝트의 규모와 범위가 증가하면 이러한 부정적인 영향이 더욱 확대되고 특성을 사용하기 어려운 품질이 됩니다.

그러나 문제를 해결하기 위해 무엇을 할 수 있습니까? 우리는 자식 "컴포넌트 로직" 노드가 씬 루트에 무엇을 해야 하는지 알려주는 것을 원하지 않지만, 문제를 해결하기 위해 상속이나 전체 스크립트 변경에 의존할 수도 없습니다.

이 상황 에서 비 ECS 엔진은 무엇을 할까요? 구성이 여전히 답이지만 이 경우 전체 노드는 소유권 계층 구조의 역학을 확장/복잡하게 만들 때 비합리적입니다. 대신, 구체적인 행동 구현을 추상화하는 비노드 구현 객체를 정의할 수 있지만 이 객체는 모두 여전히 루트 노드가 소유합니다. 이것은 Reference 스크립트로 수행할 수 있습니다.

# root.gd
extends KinematicBody2D

export(Script) var jump_impl_script = null setget set_jump_impl_script
var jump_impl
func set_jump_impl_script(p_script):
    jump_impl = p_script.new() if p_script else null

export(Script) var move_impl_script = null setget set_move_impl_script
var move_impl
func set_move_impl_script(p_script):
    move_impl = p_script.new() if p_script else null

func _physics_process():
    # use logic involving these...
    move_impl.move(...)
    jump_impl.jump(...)

내보내기가 새로운 Resource 인스턴스에 대해 할 수 있는 것처럼 특정 유형을 파생하는 클래스에 대한 열거형으로 Inspector에서 편집할 수 있는 방식으로 작동했다면 정말 좋았을 것입니다. 지금 할 수 있는 유일한 방법은 리소스 스크립트 내보내기를 수정한 다음 구현 스크립트가 리소스를 확장하도록 하는 것입니다(다른 이유 없이). 그러나 구현 자체에 Inspector에서 정의할 수 있는 매개변수가 필요한 경우 리소스를 확장하는 것이 좋습니다. :-)

이제 이를 더 쉽게 만들 수 있는 것은 스니펫 시스템이나 매크로 시스템을 사용하여 개발자가 재사용되는 선언적 코드 섹션을 더 쉽게 생성할 수 있도록 하는 것입니다.

어쨌든, 네, 저는 특성 시스템과 문제 해결에 대한 더 나은 접근 방식에서 눈에 띄는 문제를 식별했다고 생각합니다. XY 문제 문제만 만세! /에스

편집하다:

따라서 위 예제의 워크플로에는 구현 스크립트를 설정한 다음 런타임에 스크립트의 인스턴스를 사용하여 동작을 정의하는 작업이 포함됩니다. 그러나 구현 자체에 Inspector에서 정적으로 설정하려는 매개변수가 필요하다면 어떻게 될까요? 다음은 대신 리소스를 기반으로 하는 버전입니다.

# root.gd
extends KinematicBody2D

# if you use a Resource script AND had a way of specifying that the assigned Resource 
# must extend that script, then the editor would automatically assign an instance of 
# that resource script to the var. No separate instancing or setter necessary.

export(Resource) var jump_impl = null # set jump duration, max height, tween easing via Inspector
export(Resource) var move_impl = null # similarly customize movement from Inspector

# can then create different Resources as different implementations. Because they are resources,
# one can edit them even outside of a scene!
func _physics_process():
    move_impl.move(...)
    jump_impl.jump(...)

관련: #22660

@AfterRebelion

사용된 기능이 아니라 표시된 워크플로에 대해 이야기하고 있음을 고려하십시오.

아이러니하게도 당신이 이것을 명확히 하고 내가 최적의 워크플로에 동의한 다음 댓글의 뒷부분에 동의하지 않은 다음 기본적으로 해당 비디오에서 "사용된 기능"이 실제로 어떻게 문제를 해결하는 이상적인 방법인지 말함으로써 후속 조치를 취합니다. 어쨌든 Godot의 이 문제. ㅋ.

# root.gd
extends KinematicBody2D

export(Script) var jump_impl_script = null setget set_jump_impl_script
var jump_impl
func set_jump_impl_script(p_script):
jump_impl = p_script.new() if p_script else null
...

와, 수출이 이렇게 강력한지 몰랐습니다. 프리미티브 및 기타 데이터 구조와만 상호 작용할 수 있을 것으로 예상했습니다.

이것은 나의 이전 의견을 무효로 만듭니다.
말씀하신 대로 구현을 더 쉽게 하기 위해 어떤 종류의 매크로가 구현된다면 MultiScript 없이도 해당 워크플로를 구현하는 가장 좋은 방법이 될 것입니다. 가능한 모든 스크립트를 미리 선언해야 하기 때문에 Unity만큼 다재다능하지는 않지만 여전히 좋은 옵션입니다.

@AfterRebelion

말씀하신 대로 구현을 더 쉽게 하기 위해 어떤 종류의 매크로가 구현된다면 MultiScript 없이도 해당 워크플로를 구현하는 가장 좋은 방법이 될 것입니다.

글쎄요, 같은 댓글에서 언급한 Resource 기반 접근 방식과 #22660의 더 나은 편집기 지원을 결합하면 Unity가 할 수 있는 것과 비슷한 품질을 만들 수 있습니다.

가능한 모든 스크립트를 미리 선언해야 하기 때문에 Unity만큼 다재다능하지는 않지만 여전히 좋은 옵션입니다.

글쎄, 그들이 3.2에서 배열 유형 힌트를 수정하면 스크립트를 확장하고 자신의 것을 효과적으로 추가해야 하는 파일 경로에 대해 내보낸 배열을 정의할 수 있습니다. 이것은 EditorInspectorPlugin 클래스를 사용하여 특정 리소스 또는 노드에 대한 Inspector에 사용자 정의 콘텐츠를 추가함으로써 3.1의 플러그인을 통해 수행할 수도 있습니다.

내 말은, "Unity"와 같은 시스템을 원했다면 실제로 루트에 수행할 작업을 알려주는 하위 노드가 있고 수동으로 선언하거나 추가하지 않고 이름을 참조하여 가져오기만 하면 됩니다. 루트 노드의 스크립트에서. Resource 메서드는 일반적으로 훨씬 더 효과적이며 더 깨끗한 코드베이스를 유지합니다.

특성 시스템은 GDScript 코드의 사용성에 과도한 부담을 주기 때문에 제가 설명한 이유에 따라 이 문제를 종료하겠습니다. 추가의 함정은 그러한 시스템에서 얻을 수 있는 비교적 빈약한 이점보다 훨씬 큽니다. 이러한 동일한 이점은 더 명확하고 유용하게 다른 방식으로 구현할 수 있습니다.

글쎄요, 제가 없는 동안 이 토론을 놓쳤습니다. 아직 모든 것을 읽지는 않았지만 코드 재사용 문제를 해결하기 위해 GDScript에 특성을 추가하는 아이디어가 있었습니다. 이 문제는 파생 유형에 스크립트를 첨부하는 가짜 다중 상속보다 훨씬 더 우아하고 명확합니다. 내가 할 일은 특정 트레잇 파일을 만드는 것이지만 어떤 클래스 파일도 트레잇이 되도록 허용하지 않았습니다. 나는 그것이 너무 나쁘다고 생각하지 않는다.

그러나 여러 노드 유형에서 코드를 재사용하는 주요 문제를 해결하기 위한 제안에 열려 있습니다.

@vnen 마지막 항목인 솔루션은 재사용 가능한 섹션을 리소스 스크립트에 아웃소싱하는 것입니다.

• 노드의 멤버 변수인 것처럼 여전히 노출되고 속성이 인스펙터에서 편집될 수 있습니다.

• 그들은 데이터와 논리가 어디에서 왔는지에 대한 명확한 흔적을 유지합니다. 많은 특성이 하나의 스크립트에 포함되면 쉽게 손상될 수 있습니다.

• 그들은 언어로서의 GDScript에 과도한 복잡성을 추가하지 않습니다. 예를 들어, 존재한다면 공유 품질(속성, 상수, 신호)이 기본 스크립트에 병합되는 방식을 해결해야 합니다(또는 병합되지 않은 경우 사용자가 종속성 충돌을 처리하도록 강제).

• 리소스 스크립트는 Inspector에서 할당 및 변경할 수 있으므로 더 좋습니다. 디자이너, 작가 등은 편집기에서 직접 구현 개체를 변경할 수 있습니다.

@willnationsdev (모든 스크립트가 리소스이기 때문에 "리소스 스크립트"라는 이름이 이상하게 들릴지라도) 알겠습니다. 이 솔루션의 주요 문제는 사람들이 상속 접근 방식으로 기대하는 것을 해결하지 못한다는 것입니다. 내보낸 변수와 신호를 장면의 루트 노드에 추가합니다(특히 장면을 다른 곳에서 인스턴스화할 때). 하위 리소스에서 내보낸 변수를 계속 편집할 수 있지만 실용성이 떨어집니다(편집할 수 있는 속성을 한 눈에 알 수 없음).

또 다른 문제는 상용구 코드를 많이 반복해야 한다는 것입니다. 또한 함수를 호출하기 전에 리소스 스크립트가 실제로 설정되었는지 확인해야 합니다.

장점은 아무것도 필요하지 않으며 이미 사용할 수 있다는 것입니다. 나는 이것이 문서화되어야 하고 현재 "파생 노드에 스크립트 첨부" 방법을 사용하는 사람들이 솔루션이 얼마나 실행 가능한지 보기 위해 솔루션에 대해 언급할 수 있다고 생각합니다.

@vnen

그러나 덜 실용적이 됩니다(편집할 수 있는 속성을 한 눈에 알 수 없음).

여기서 무슨 말인지 자세히 설명해 주시겠습니까? 특히 #22660과 같은 항목이 병합된 경우 어떤 속성에 액세스할 수 있는지에 대한 명확성이 상당히 부족할 수 있습니다.

1. 장면을 인스턴스화하고 편집 방법을 알고 싶으므로 해당 장면의 루트 노드 스크립트를 확인합니다.
2. 대본을 보니...
   
   
   
   • export(MoveImpl) var move_impl = FourWayMoveImpl.new()
   
   
   • use FourWayMoveTrait
   
   
3. 스크립트를 열기 위한 식별자(실제로 3.1.1 기능이어야 함!)를 클릭 추적하는 수단이 있다고 가정하면 연결된 스크립트를 열고 해당 속성을 볼 수 있습니다.

내가 뭔가를 놓치고 있지 않는 한, 나에게 같은 수의 단계처럼 보입니다.

또한, 어떤 속성이 편집 가능한지 실제로 리소스를 사용하면 훨씬 더 명확해집니다. 구현에 고유한 속성이 있는 경우 데이터가 구현과 관련되어 있다는 사실이 구현 인스턴스, 즉 move_impl.<property> .

또 다른 문제는 상용구 코드를 많이 반복해야 한다는 것입니다. 또한 함수를 호출하기 전에 리소스 스크립트가 실제로 설정되었는지 확인해야 합니다.

이것은 사실입니다. 그러나 초기화가 포함된 내보내기의 이점이 추가된 말의 비용보다 더 크다고 생각합니다.

("고위급 팀원", HLT, 디자이너, 작가, 아티스트 등)

• 스크립트를 열지 않고 Inspector에서 직접 값을 할당하고 변경할 올바른 줄을 찾은 다음 변경할 수 있습니다(이미 언급했지만...).

• 내보낸 콘텐츠에 기본 유형 요구 사항이 있음을 지정할 수 있습니다. 그러면 Inspector는 허용 가능한 구현의 열거된 목록을 자동으로 제공할 수 있습니다. 그런 다음 HLT는 해당 유형의 파생물만 안전하게 할당할 수 있습니다. 이것은 주위에 떠돌아다니는 모든 다른 특성 스크립트의 결과를 알아야 하는 대안에서 그들을 격리하는 데 도움이 됩니다. 또한 use 키워드를 본 것에 대한 응답으로 명명된 특성 파일과 명명되지 않은 특성 파일 조회를 지원하도록 GDScript의 자동 완성을 수정해야 합니다.

• 구현 구성을 *.tres 파일로 직렬화할 수 있습니다. 그런 다음 HLT는 FileSystem 도크에서 끌어다 놓거나 Inspector에서 고유한 권한을 만들 수도 있습니다. 특성으로 동일한 작업을 수행하려면 기본 생성자를 재정의하는 사용자 정의 생성자를 제공하는 파생 특성을 만들어야 합니다. 그런 다음 명령형으로 코딩된 생성자를 통해 대신 해당 특성을 "사전 구성"으로 사용합니다.

  1. 선언적이기보다는 명령적이기 때문에 약합니다.
  2. 생성자가 스크립트에서 명시적으로 정의되어야 하기 때문에 더 약합니다.
  3. 트레이트에 이름이 지정되지 않은 경우 사용자 는 기본 기본 트레이트 대신 적절히 사용 하기 위해 트레이트의 위치를 ​​알아야 합니다. 트레이트의 이름이 지정되면 전역 네임스페이스가 불필요하게 막힙니다.
  4. $ use MoveTrait use FourWayMoveTrait 라고 스크립트를 변경하면 스크립트가 기본 MoveTrait 와도 호환된다는 지속적인 표시가 더 이상 없습니다. 그것은 FourWayMoveTrait 가 깨지지 않고 다른 MoveTrait 로 변경될 수 있는지 여부에 대한 HLT 혼동을 가능하게 합니다.
  5. HLT가 이러한 방식으로 새로운 특성 구현을 생성하는 경우 기본 특성에서 설정할 수/필요한 모든 속성을 반드시 알 필요는 없습니다. 이것은 인스펙터에서 생성된 리소스와 관련된 문제가 아닙니다.

• 같은 유형의 리소스가 여러 개 있을 수도 있습니다(이유가 있는 경우). 특성은 이를 지원하지 않지만 대신 구문 분석 충돌을 유발합니다.

• 2D/3D 뷰포트를 벗어나지 않고도 구성 및/또는 개별 값을 변경할 수 있습니다. 이것은 HLT에 훨씬 더 편안합니다(코드 를 봐야 할 때 완전히 짜증이 나는 사람을 많이 알고 있습니다).

그 모든 말과 함께, 나는 상용구가 짜증난다는 데 동의합니다. 하지만 이를 처리하기 위해 매크로 또는 스니펫 시스템을 추가하여 단순화하고 싶습니다. 스니펫 시스템은 GDScript 단독이 아니라 ScriptEditor에서 편집할 수 있는 모든 언어를 지원할 수 있기 때문에 좋은 아이디어입니다.

에 대한:

그러나 덜 실용적이 됩니다(편집할 수 있는 속성을 한 눈에 알 수 없음).

나는 인스펙터에 대해 이야기하고 있었기 때문에 여기서 "HLT"를 의미합니다. 코드를 살펴보지 않는 사람들. 특성을 사용하여 새 내보낸 속성을 스크립트에 추가할 수 있습니다. 리소스 스크립트를 사용하면 변수를 리소스 자체로만 내보낼 수 있으므로 하위 리소스를 편집하지 않는 한 인스펙터에 표시되지 않습니다.

나는 당신의 주장을 이해하지만 그것은 원래의 문제를 넘어서는 것입니다: 코드 반복을 피하십시오(상속 없이). 특성은 프로그래머를 위한 것입니다. 많은 경우 재사용하고 싶은 구현이 하나뿐이며 이를 인스펙터에 노출하고 싶지 않습니다. 물론 코드에서 직접 할당하는 것만으로 내보내기 없이 리소스 스크립트를 계속 사용할 수 있지만 여전히 공통 구현에서 내보낸 변수와 신호를 재사용하는 문제를 해결하지 못합니다. 이것이 사람들이 시도하는 주된 이유 중 하나입니다. 상속을 사용합니다.

즉, 사람들은 현재 기능뿐만 아니라 내보낸 속성(일반적으로 해당 기능과 관련됨) 및 신호(그러면 UI와 연결할 수 있음)에 대해 일반 스크립트에서 상속을 사용하려고 합니다.

이것은 해결하기 어려운 문제입니다. GDScript만으로 이를 수행할 수 있는 몇 가지 방법이 있지만 다시 한 번 상용구 코드를 복사해야 합니다.

외부 스크립트가 마치 메인 스크립트 자체에 직접 작성된 것처럼 작동하도록 하기 위해 발생해야 하는 전후 관계를 상상할 수 있을 뿐입니다.

그것을 이루기 위해 하늘과 땅이 움직여야 하는 것이 아니라면 있으면 좋을 텐데. 엑스)

@vnen 지금 무슨 말씀 하시는지 알겠습니다. 글쎄, 이번 호에는 아직 생명이 있는 것 같기 때문에 다음에 기회가 있을 때 다시 열겠습니다.

재개봉 소식은 없나요? 이제 GodotCon 2019가 발표되고 Godot Sprint가 하나의 일이므로, 아마도 이것은 이야기할 가치가 있을 것입니다.

@AfterRebelion 나는 돌아와서 그것을 다시 여는 것을 잊었습니다. 상기시켜주셔서 감사합니다. XD

@willnationsdev EditorInspectorPlugin 에 관해 읽은 내용이 마음에 들었습니다! 빠른 질문, 이것은 데이터 유형에 대한 사용자 정의 검사기를 만들 수 있다는 것을 의미합니다... 예를 들어... 검사기에 버튼을 추가합니다.
(이 작업을 수행한지 꽤 오래되었습니다. 인스펙터의 버튼을 사용하여 디버깅 목적으로 이벤트를 트리거하는 방법을 사용하려면 버튼을 눌러 스크립트를 실행하도록 할 수 있습니다.)

@xDGameStudios 네 , 그 외에도 훨씬 더 많은 것이 가능합니다. 사용자 정의 컨트롤은 상단, 하단, 속성 위 또는 범주 아래에서 Inspector에 추가할 수 있습니다.

@willnationsdev 개인적으로 연락드려도 되는지 모르겠네요!! 하지만 EditorInspectorPlugin(일부 샘플 코드와 같은)에 대해 더 알고 싶습니다. 사용자 지정 리소스 유형(예: MyResource)에 속성 내보내기 "이름"이 있고 "이름"을 인쇄하는 검사기 버튼이 있는 줄에 있는 것 변수를 누르면 (편집기에서 또는 디버깅 중)! 이 문제에서 문서화는 시간이 많이 부족합니다... 이것을 사용하는 방법을 알면 문서를 직접 작성할 것입니다! :D 감사합니다

나는 또한 그것에 대해 더 알고 싶습니다. 엑스)

그렇다면 이것은 정적 함수를 포함하는 서브클래스가 있는 자동 로드 스크립트와 동일한가요?

예를 들어 귀하의 사례는 Traits.MoveRightTrait.move_right() 가 됩니다.

또는 더 간단하게 서로 다른 특성 클래스에 대해 서로 다른 자동 로드 스크립트를 사용합니다.

Movement.move_right()

아니요, 특성은 한 스크립트의 소스 코드를 다른 스크립트에 복사하여 붙여넣는 것과 같은 언어별 기능입니다(파일 병합과 유사). 따라서 move_right() 가 있는 특성이 있고 두 번째 스크립트가 해당 특성을 사용한다고 선언하면 정적이 아니고 액세스하더라도 move_right() 를 사용할 수 있습니다. 클래스의 다른 위치에 있는 속성. 속성이 두 번째 스크립트에 없으면 구문 분석 오류가 발생합니다.

나는 다중 상속을 가질 수 없기 때문에 중복 코드(작은 기능, 예를 들어 호 만들기) 또는 불필요한 노드가 있다는 것을 발견했습니다.

이것은 굉장할 것입니다. 정확히 동일한 기능을 가진 스크립트를 다른 노드 유형에서 사용하도록 만들어야 하므로 기본적으로 한 줄의 코드에 대해 서로 다른 extend 가 발생합니다. 그런데 현재 시스템으로 만드는 방법을 아는 사람이 있으면 알려주십시오.

extends Node 가 있는 스크립트에 대한 기능이 있는 경우 소스 파일을 복제하고 적절한 extend 로 바꾸지 않고도 동일한 동작을 다른 노드 유형에 연결할 수 있습니까?

이에 대한 진전이 있습니까? 앞에서 말했듯이 계속 코드를 복제하거나 노드를 추가해야 합니다. 나는 그것이 3.1에서 끝나지 않을 것이라는 것을 알고 있지만 아마도 3.2를 목표로 할 것입니까?

오, 나는 이것에 대해 전혀 작업하지 않았습니다. 사실, 나는 이것보다 확장 메소드 구현에 더 동의합니다. 나는 그와 함께 최고의 구문/구현 세부 사항을 해결하고 싶기 때문에 둘 다에 대해 vnen과 이야기해야 합니다.

편집: 다른 누군가가 특성을 구현하는 데 균열을 일으키고 싶다면 뛰어들 수 있습니다. 개발자와 협력하기만 하면 됩니다.

"확장 방법 구현"?

@Zireael07 #15586
그것은 사람들이 엔진 클래스에 대한 새로운 "내장된" 기능을 추가할 수 있는 스크립트를 작성할 수 있도록 합니다. 구문에 대한 내 해석은 다음과 같습니다.

static Array func sum(p_self: Array):
    if not len(p_self):
        return 0
    var value = p_self[0]
    for i in range(1, len(p_self)):
        value += p_self[i]
    return value

그런 다음 다른 곳에서 다음을 수행할 수 있습니다.

var arr = [1, 2, 3]
print(arr.sum()) # prints 6

지속적으로 로드되는 확장 스크립트를 비밀리에 호출하고 Array 클래스에 바인딩된 동일한 이름의 정적 함수를 호출하여 인스턴스를 첫 번째 매개변수로 전달합니다.

이에 대해 @vnen 및 @jahd2602 와 몇 가지 이야기를 나눴습니다. 마음에 떠오르는 한 가지는 다형성에 대한 Jai의 솔루션인 속성의 네임스페이스 가져오기입니다.

이 방법으로 다음과 같은 작업을 수행할 수 있습니다.

class A:
    var a_prop: String = "Hello"
    func foo():
        print("A's a_prop: ", a_prop)
    func bar():
        print("A's bar()")

class B:
    using var a: A = A.new()
    var a_prop: String = "World" # Overriding A's a_prop

    func bar():  # Overriding A's bar()
        print("B's bar()")

func main():
    var b: B = B.new()
    b.foo() # output: "A's a_prop: World"
    b.bar() # output: "B's bar()"

요점은 using 키워드가 속성의 네임스페이스를 가져오므로 b.foo() 는 실제로 b.a.foo() 에 대한 구문적 설탕일 뿐입니다.

그런 다음 b is A == true 및 해당 B가 A를 허용하는 입력된 상황에서 사용할 수 있는지 확인합니다.

이것은 또한 특성으로 선언할 필요가 없다는 이점이 있습니다. 이는 공통 품질 이름이 없는 모든 항목에 적용됩니다.

한 가지 문제는 이것이 현재 상속 시스템과 잘 맞지 않는다는 것입니다. A와 B가 모두 Node2D이고 A: func baz(): print(self.position) 에서 함수를 만드는 경우 b.baz() 를 호출할 때 어떤 위치가 인쇄됩니까?
한 가지 해결책은 호출자가 self 를 결정하도록 하는 것입니다. b.foo()를 호출하면 b를 self로 사용하여 foo()를 호출하고 bafoo()는 foo()를 self로 호출합니다.

Python( x.f(y) 은 f(x,y) 에 대한 설탕)과 같은 독립형 메서드가 있는 경우 구현하기가 정말 쉬울 수 있습니다.

또 다른 관련 없는 아이디어:

독립형 기능, JavaScript 스타일에만 중점을 둡니다.

정적 함수에 대해 x.f(y) == f(x,y) 규칙을 채택하면 다음을 매우 쉽게 얻을 수 있습니다.

class Jumper:
    static func jump(_self: KinematicBody2D):
        # jump implementation

class Runner:
    static func run(_self: KinematicBody2D, direction: Vector2):
        # run implementation

class Character:
    extends KinematicBody2D
    func run = Runner.run       # Example syntax
    func jump = Jumper.jump

func main():
    var character = Character.new()
    character.jump()
    character.run(Vector2(1,0))

이것은 실제로 메서드에만 영향을 미치기 때문에 클래스 시스템에 최소한의 영향을 미칩니다. 그러나 이것이 정말로 유연하기를 원한다면 우리는 완전한 JavaScript로 전환하고 함수 정의가 할당 가능하고 호출 가능한 값을 허용하도록 할 수 있습니다.

@jabcross 좋은 것 같습니다. 일종의 선택적 네임스페이스 개념이 마음에 들고 기능 아이디어가 흥미롭습니다.

하나의 네임스페이스와 관련하여 단순히 using A 가 아닌 다른 선언적 사항이 관련 없는 것처럼 보이는 이유가 궁금합니다.

다중 상속으로 어떻게 해결해야 하는지도 궁금합니다. 옵션 A는 두 스크립트 모두 동일한 유형을 상속하도록 강제하는 것이므로 특별한 병합 없이 둘 다 동일한 클래스의 맨 위에서 확장됩니다.

옵션 B, 특성 클래스를 지정하기 위한 추가 GDScript 키워드 및 힌트를 원하는 클래스. 같은 생각이지만 더 명확하게 보이려면 추가 단계만 있을 뿐입니다.

A.gd 상단:

extends Trait as Node2D
is Trait as Node2D
is Trait extends B
extends B as Trait

오, 나는 네임스페이스 가져오기의 개념을 정말 좋아합니다. 특성 문제뿐만 아니라 엔진 유형에 콘텐츠를 추가하기 위한 잠재적으로 "확장 방법" 개념도 해결합니다.

class_name ArrayExt
static func sum(_self: Array) -> int:
    var sum: int = 0
    for a_value in _self:
        sum += a_value
    return sum

using ArrayExt
func _ready():
    var a = [1, 2, 3]
    print(a.sum())

@jabcross 그런 다음 람바를 추가하거나 객체가 호출 연산자를 구현하도록 허용했다면(호환 가능한 값에 대해 callable 유형을 가짐) GDScript 코드에 보다 기능 지향적인 접근 방식을 추가할 수 있습니다( 좋은 아이디어가 될 것 같아요.) 물론 그 시점에서 @vnen 의 #18698 영역에 더 많이 들어가긴 했지만...

우리는 GDScript가 여전히 동적 언어이며 이러한 제안 중 일부는 호출을 올바르게 전달하기 위해 런타임 검사가 필요하고 성능 저하가 추가된다는 점을 고려해야 합니다(기능을 사용하지 않는 사람들에게도 모든 함수 호출을 확인해야 하기 때문에 속성 조회도 가능). 이것이 확장을 추가하는 것이 좋은 생각인지 확신할 수 없는 이유이기도 합니다(특히 본질적으로 구문 설탕이기 때문에).

나는 특성이 클래스가 아니라 고유한 특성인 순수 특성 시스템을 선호합니다. 이렇게 하면 컴파일 시간에 완전히 해결될 수 있고 이름 충돌의 경우 오류 메시지를 제공할 수 있습니다. 나는 이것이 추가적인 런타임 오버헤드 없이 문제를 해결할 것이라고 믿습니다.

@vnen Ahhh, 런타임 비용에 대해 깨닫지 못했습니다. 그리고 그것이 모든 확장 메서드 구현에 적용된다면 그것도 이상적이지 않을 것입니다.

우리가 순수한 특성 시스템을 만들었다면 다른 스크립트에서 extends 와 using TraitName under extends 대신 trait TraitName 를 만들 생각이었습니까? 그리고 이것을 직접 구현하시겠습니까, 아니면 위임하시겠습니까?

우리가 순수한 특성 시스템을 만들었다면 다른 스크립트에서 extends 와 using TraitName under extends 대신 trait TraitName 를 만들 생각이었습니까?

그게 내 생각이야. 나는 그것이 충분히 간단하고 코드 재사용에 대한 거의 모든 사용 사례를 다룹니다. 나는 특성을 사용하는 클래스가 특성 메소드를 재정의하도록 허용할 것입니다(컴파일 타임에 수행할 수 있는 경우). 특성은 다른 특성을 확장할 수도 있습니다.

그리고 이것을 직접 구현하시겠습니까, 아니면 위임하시겠습니까?

나는 그 일을 할 수 있는 다른 사람에게 그 일을 맡기는 것을 꺼려하지 않을 것입니다. 어쨌든 시간이 부족합니다. 그러나 미리 디자인에 동의해야 합니다. 나는 세부 사항에 대해 상당히 유연하지만 1) 런타임 검사에서 발생하지 않아야 하고(GDScript는 컴파일에서 알아낼 수 없는 항목에 적합하다고 믿어야 함), 2) 비교적 간단해야 하며, 3) 컴파일 시간.

@vnen 이 아이디어를 좋아합니다. 트레잇이 포함된 클래스에 대해 자동 완성과 같은 작업을 수행할 수 있는지 또는 불가능한 것인지 어떻게 상상하는지 궁금하십니까?

트레잇이 포함된 클래스에 대해 자동 완성과 같은 작업을 수행할 수 있는지 또는 불가능한 것인지 어떻게 상상하는지 궁금하십니까?

내 관점에서 특성은 본질적으로 "가져오기"입니다. 구성원을 위한 완료가 작동한다고 가정하면 완료를 표시하는 것이 간단해야 합니다.

@vnen 기본적으로 trait 플래그가 설정된 ClassNode로 구문 분석할 것이라고 상상합니다. 그런 다음 using 문을 수행하면 모든 속성/메소드/신호/상수/하위 클래스를 현재 스크립트에 병합하려고 시도합니다.

1. 메서드가 충돌하면 상속된 메서드를 재정의하는 것처럼 현재 스크립트의 구현이 기본 메서드를 재정의합니다.
   
   
   
   • 그러나 기본 클래스에 이미 "병합된" 메서드가 있는 경우 어떻게 해야 합니까?
   
   
2. 속성, 시그널, 상수가 겹칠 경우 같은 타입/시그니처인지 확인하세요. 불일치가 없으면 속성/신호/상수의 "병합"으로 간주하십시오. 그렇지 않으면 사용자에게 유형/서명 충돌(분석 오류)을 알립니다.

나쁜 생각? 아니면 비메서드 충돌을 완전히 금지해야 합니까? 서브클래스는 어떻습니까? 나는 우리가 그러한 갈등을 만들어야 한다는 느낌을 가지고 있습니다.

@willnationsdev "다이아몬드 문제"(일명 "죽음의 다이아몬드"라고도 함)처럼 들리는데, 이미 여러 인기 있는 프로그래밍 언어에 적용된 다양한 솔루션과 함께 잘 문서화된 모호성입니다.

생각나는 것:
@vnen 특성이 다른 특성을 확장할 수 있습니까?

@jahd2602 그는 이미 그것을 가능성으로 제안했습니다 .

특성은 다른 특성을 확장할 수도 있습니다.

@jahd2602 Perl/Python 솔루션을 기반으로 하여 기본적으로 각 클래스의 콘텐츠를 포함하는 레이어의 "스택"을 형성하여 마지막으로 사용된 특성의 충돌이 다른 버전 위에 놓이고 덮어쓰도록 하는 것처럼 보입니다. 이 시나리오에 대한 꽤 좋은 솔루션처럼 들립니다. 당신이나 @vnen 에게 다른 생각이 없다면. 솔루션 jahd의 연결된 개요에 감사드립니다.

몇 가지 질문입니다.

첫째: using 문을 어떤 방식으로 지원해야 하나요?

using 문에는 상수 값 GDScript가 필요하다고 생각합니다.

using preload("res://my_trait.gd") # a preloaded expression
using ScriptClass.MyTrait # a const resource
using Autoload.MyTrait # a const resource
using MyTrait # a regular script class

위의 모든 것을 생각하고 있습니다.

둘째: 특성 및/또는 그 이름을 정의하는 데 허용되는 구문은 무엇이어야 합니까?

누군가는 반드시 자신의 특성에 대해 스크립트 클래스를 사용하고 싶어하지 않을 수 있으므로 trait TraitName 요구 사항을 적용해야 한다고 생각하지 않습니다. trait 가 줄에 있어야 한다고 생각합니다.

따라서 도구 스크립트라면 당연히 맨 위에 도구가 있어야 합니다. 그런 다음 특성이면 다음 줄에 특성인지 여부를 정의해야 합니다. 선택적으로 다른 사람이 같은 줄에 있는 특성 선언 다음에 스크립트 클래스 이름을 명시하도록 허용하고, 그렇게 하는 경우 class_name 도 사용하도록 허용하지 마십시오. 특성 이름을 생략하면 class_name <name> 가 좋습니다. 그런 다음 다른 유형을 확장할 때 특성 선언 뒤에 extends 를 삽입하거나 특성 선언 뒤에 자체 행에 삽입할 수 있습니다. 따라서 다음 각 항목이 유효한 것으로 간주합니다.

# Global name from trait keyword.
trait MyTrait extends BaseTrait

# Global name from class_name keyword, but is still a trait and also happens to be a tool script.
tool
trait
extends BaseTrait
class_name MyTrait

# A trait with no global name associated with it. Does not extend anything.
trait

셋째: 자동 완성 목적 및/또는 의도/요구 사항 선언을 위해 트레잇이 확장해야 하는 기본 유형을 정의하도록 허용해야 합니까?

우리는 이미 특성이 다른 특성의 상속을 지원해야 한다고 논의했습니다. 그러나 TraitA를 extend Node 로 허용하고 TraitA 스크립트가 노드 자동 완성을 얻도록 허용해야 하지만 현재 클래스가 Node를 확장하지 않을 때 using TraitA 문을 수행하면 구문 분석 오류도 발생합니다. 또는 파생 유형 중 하나?

네 번째: 트레잇이 다른 트레잇을 확장하도록 하는 대신 클래스 확장을 위해 예약된 extends 명령문을 유지하고 트레잇이 이 명령문을 전혀 필요로 하지 않게 하고 기본 트레잇을 확장하는 대신 허용할 수 있습니까? 특성을 하위 가져오기를 통해 고유 한 using 명령문을 갖도록 하시겠습니까?

# base_trait.gd
trait
func my_method():
    print("Hello")

# derived_trait.gd
trait
using preload("base_trait.gd")
func my_method():
   print("World") # overrides previous method, will only print "World".

물론 여기의 이점은 여러 개의 다른 클래스를 포함하는 C++ 포함 파일과 유사하게 여러 using 문을 사용하여 단일 특성 이름으로 여러 특성을 일괄 처리할 수 있다는 것입니다.

다섯째: 특성이 있고 메서드에 대해 using 또는 extends 가 있고 고유한 특성을 구현하는 경우 해당 함수 내에서 호출할 때 수행할 작업 .<method_name> 기본 구현을 실행하시겠습니까? 이러한 호출은 항상 클래스 상속 컨텍스트 내에서 실행되고 특성 계층 구조가 여기에 영향을 미치지 않는다고 가정합니까?

cc @vnen

첫째: using 문을 어떤 방식으로 지원해야 하나요?

using 문에는 상수 값 GDScript가 필요하다고 생각합니다.

using preload("res://my_trait.gd") # a preloaded expression
using ScriptClass.MyTrait # a const resource
using Autoload.MyTrait # a const resource
using MyTrait # a regular script class

나는 그 모든 것이 좋습니다. 그러나 경로의 경우 문자열을 직접 사용합니다. using "res://my_trait.gd"

둘째: 특성 및/또는 그 이름을 정의하는 데 허용되는 구문은 무엇이어야 합니까?

누군가는 자신의 특성에 대해 스크립트 클래스를 사용하고 싶어하지 않을 수 있으므로 trait TraitName 요구 사항을 적용해야 한다고 생각하지 않습니다. trait 가 줄에 있어야 한다고 생각합니다.

따라서 도구 스크립트라면 당연히 맨 위에 도구가 있어야 합니다. 그런 다음 특성이면 다음 줄에 특성인지 여부를 정의해야 합니다. 선택적으로 다른 사람이 같은 줄에 있는 특성 선언 다음에 스크립트 클래스 이름을 명시하도록 허용하고, 그렇게 하는 경우 class_name 도 사용하도록 허용하지 마십시오. 특성 이름을 생략하면 class_name <name> 가 좋습니다. 그런 다음 다른 유형을 확장할 때 특성 선언 뒤에 extends 를 삽입하거나 특성 선언 뒤에 자체 행에 삽입할 수 있습니다. 따라서 다음 각 항목이 유효한 것으로 간주합니다.

# Global name from trait keyword.
trait MyTrait extends BaseTrait

# Global name from class_name keyword, but is still a trait and also happens to be a tool script.
tool
trait
extends BaseTrait
class_name MyTrait

# A trait with no global name associated with it. Does not extend anything.
trait

트레이트의 tool 는 직접 실행되지 않기 때문에 아무런 차이가 없어야 합니다.

나는 특성이 반드시 글로벌 이름을 가질 필요는 없다는 데 동의합니다. trait tool 를 사용합니다. 스크립트 파일의 첫 번째 항목이어야 합니다(주석 제외). 키워드 다음에 특성 이름이 선택적으로 와야 합니다. 나는 클래스가 아니기 때문에 class_name 를 사용하지 않을 것입니다.

셋째: 자동 완성 목적 및/또는 의도/요구 사항 선언을 위해 트레잇이 확장해야 하는 기본 유형을 정의하도록 허용해야 합니까?

솔직히 편집자를 위해 언어에 기능을 추가하는 것을 좋아하지 않습니다. 바로 주석이 유용할 것입니다.

이제 특정 유형(및 파생 상품)에만 특성을 적용하려는 경우 괜찮습니다. 사실, 저는 이것이 정적 검사를 위해 더 낫다고 생각합니다: 이것은 트레잇이 클래스의 항목을 사용할 수 있게 하는 반면 컴파일은 실제로 올바른 유형 및 기타 항목과 함께 사용되는지 확인할 수 있습니다.

네 번째: 트레잇이 다른 트레잇을 확장하도록 하는 대신 클래스 확장을 위해 예약된 extends 명령문을 유지하고 트레잇이 이 명령문을 전혀 필요로 하지 않게 하고 기본 트레잇을 확장하는 대신 허용할 수 있습니까? 특성이 _그_ 특성을 하위 가져오기하는 자체 using 문을 갖도록 하려면?

글쎄요, 그것은 대부분 의미론의 문제입니다. 특성이 다른 특성을 확장할 수 있다고 언급했을 때 extends 키워드를 사용하려는 것은 아닙니다. 주요 차이점은 extends 를 사용하면 하나만 확장할 수 있고 using 를 사용하면 다른 많은 특성을 하나에 포함할 수 있다는 것입니다. 나는 using 괜찮습니다. 주기가 없다면 문제가 되지 않습니다.

다섯 번째: 특성이 있고 메서드에 대해 using 또는 extends 가 있고 고유한 특성을 구현하는 경우 해당 함수 내에서 호출할 때 수행할 작업 .<method_name> 기본 구현을 실행하시겠습니까? 이러한 호출은 항상 클래스 상속 컨텍스트 내에서 실행되고 특성 계층 구조가 여기에 영향을 미치지 않는다고 가정합니까?

어려운 질문입니다. 나는 특성이 클래스 상속을 다루는 비즈니스가 없다고 가정할 것입니다. 따라서 점 표기법은 부모 특성에 대한 메서드를 호출해야 합니다(있는 경우). 그렇지 않으면 오류가 발생합니다. 특성은 자신이 속한 클래스를 인식하지 않아야 합니다.

OTOH, 특성은 거의 "포함"과 같으므로 클래스에 그대로 적용되므로 부모 구현을 호출합니다. 그러나 솔직히 그 방법이 부모 트레잇에서 발견되지 않는다면 나는 단순히 점 표기법을 금지할 것입니다.

클래스에 하나 이상의 다른 특성이 있어야 하는 특성은 어떻습니까? 예를 들어 Jumper , Upgradable , 그리고 KinematicBody2D 를 상속하는 클래스가 모두 필요한 DoubleJumper $ 입니다.

예를 들어, Rust를 사용하면 이와 같은 유형 서명을 사용할 수 있습니다. KinematicBody2D: Jumper, Upgradable 와 같은 것입니다. 그러나 : 를 사용하여 유형에 주석을 달기 때문에 KinematicBody2D & Jumper & Upgradable 또는 기타를 사용할 수 있습니다.

다형성 문제도 있습니다. 특성 구현이 클래스마다 다르지만 동일한 인터페이스를 노출한다면 어떻게 될까요?

예를 들어, Enemy 와 Player 모두에서 사용하는 Jumper 트레잇에 kill() 메소드가 필요합니다. 동일한 Jumper 유형 시그니처와 호환되도록 유지하면서 각 경우에 대해 서로 다른 구현을 원합니다. 이 작업을 수행하는 방법?

다형성의 경우 kill() 가 있는 특성을 포함하는 별도의 특성을 만든 다음 메서드의 고유한 특정 버전을 구현하기만 하면 됩니다. 이전에 포함된 트레이트의 메서드를 재정의하는 트레이트를 사용하는 것이 이를 처리하는 방법입니다.

또한 유형 힌트에 특성 요구 사항이 포함되도록 할 계획은 (아직) 없다고 생각합니다. 그것이 우리가 하고 싶은 일입니까?

별도의 특성을 생성

일회성 특성 파일을 많이 생성하지 않습니까? 중첩된 특성 선언( class 키워드와 유사)을 수행할 수 있다면 더 편리할 수 있습니다. 특성을 사용하는 클래스에서 직접 메서드를 재정의할 수도 있습니다.

강력한 유형 서명 시스템(부울 구성 및 선택 사항/null이 아닌 경우)에 정말 감사드립니다. 특성이 딱 들어맞을 것입니다.

논의되었는지 확실하지 않지만 기능의 특성 특정 버전을 호출하는 것이 가능해야 한다고 생각합니다. 예를 들어:

trait A
func m():
  print("A")

trait B
func m():
  print("B")

class C
using A
using B

func c():
  A.m()
  B.m()
  m()

A , B , B 를 인쇄합니다.

또한 "런타임 비용 없음"에 대해 완전히 확신하지 못합니다. 내보내기 전에 정의된 특성을 사용하는 클래스와 함께 동적으로 로드된 스크립트(내보내기 중에는 사용할 수 없음)를 어떻게 처리합니까? 내가 뭔가 오해하고 있는 걸까? 아니면 그 경우가 "런타임"으로 간주되지 않습니까?

논의되었는지 확실하지 않지만 기능의 특성 특정 버전을 호출하는 것이 가능해야 한다고 생각합니다.

나는 이미 이것을 고려하고 있었지만 클래스가 충돌하는 특성(즉, 같은 이름으로 메서드를 정의하는 특성)을 사용하도록 허용하는 것에 대해 확신이 없습니다. using 문의 순서는 차이가 없습니다.

또한 "런타임 비용 없음"에 대해 완전히 확신하지 못합니다. 내보내기 전에 정의된 특성을 사용하는 클래스와 함께 동적으로 로드된 스크립트(내보내기 중에는 사용할 수 없음)를 어떻게 처리합니까? 내가 뭔가 오해하고 있는 걸까? 아니면 그 경우가 "런타임"으로 간주되지 않습니까?

수출하는 것이 아닙니다. 컴파일은 로딩 시에 일어나기 때문에 로딩 시간에 확실히 영향을 미칠 것이지만(매우 중요하지 않을 것이라고 생각하지만) 스크립트가 실행될 때는 영향을 미치지 않아야 합니다. 이상적으로는 스크립트를 내보낼 때 컴파일해야 하지만 이는 또 다른 논의입니다.

여러분, 안녕하세요.

저는 Godot를 처음 접했고 지난 며칠 동안 익숙해졌습니다. 재사용 가능한 구성 요소를 만드는 데 사용할 베스트 프랙티스를 찾으려고 노력하면서 패턴을 결정했습니다. 나는 항상 다른 장면에서 인스턴싱되도록 의도된 하위 장면의 루트 노드를 외부에서 설정하려는 모든 속성을 내보내도록 만들 것입니다. 가능한 한 나머지 장면에는 인스턴스된 분기의 내부 구조에 대한 지식이 필요하지 않게 하고 싶었습니다.

이 작업을 수행하려면 루트 노드가 속성을 "내보내기"한 다음 값을 _ready의 적절한 자식에 복사해야 합니다. 예를 들어 자식 Timer가 있는 Bomb 노드를 상상해 보십시오. 하위 장면의 루트 Bomb 노드는 "detonation_time"을 내보낸 다음 _ready에서 $Timer.wait_time = detonation_time 를 수행합니다. 이것은 우리가 그것을 인스턴스화할 때마다 아이들을 편집 가능하게 만들고 타이머로 드릴다운할 필요 없이 Godot의 UI에서 멋지게 설정할 수 있도록 합니다.

하지만
1) 그것은 매우 기계적 변형이므로 시스템에서 유사한 것을 지원할 수 있을 것 같습니다.
2) 자식 노드에서 직접 적절한 값을 설정하는 것보다 약간의 비효율성을 추가할 수 있습니다.

계속하기 전에 이것은 일종의 "비공개" 상속(C++ 용어로)을 허용하지 않기 때문에 논의 중인 내용과 관련이 없어 보일 수 있습니다. 그러나 저는 상속과 같은 엔지니어링 대신 Scene 요소를 구성하여 동작을 구축하는 Godot의 시스템을 실제로 좋아합니다. 이러한 "기재된" 관계는 변경되지 않고 정적입니다. OTOH, 장면 구조는 동적이며 런타임에 변경할 수도 있습니다. 게임 로직은 개발하는 동안 변경될 수 있기 때문에 Godot의 디자인이 사용 사례에 아주 잘 맞는다고 생각합니다.

자식 노드가 루트 노드의 동작 확장으로 사용되는 것이 사실이지만 그렇다고 해서 자급자족이 부족한 것은 아닙니다(IMO). 타이머는 시간에 익숙해지는 것과 상관없이 완벽하게 독립적이며 동작을 예측할 수 있습니다. 숟가락으로 수프를 먹든 아이스크림을 먹든 손을 뻗는 역할을 하면서도 제 기능을 제대로 발휘한다. 나는 루트 노드를 자식 노드의 동작을 조정하는 거장으로 간주하므로 서로에 대해 직접 알 필요가 없으며 따라서 독립적으로 유지될 수 있습니다. 상위/루트 노드는 책임을 위임하지만 직접적인 작업을 많이 수행하지 않는 데스크 바인딩된 관리자입니다. 얇기 때문에 약간 다른 동작을 위해 새 것을 쉽게 만들 수 있습니다.

그러나 루트 노드는 전체 인스턴스 분기의 기능에 대한 기본 인터페이스 역할도 해야 한다고 생각합니다. 인스턴스에서 조정할 수 있는 모든 속성은 속성의 최종 소유자가 일부 자식 노드인 경우에도 분기의 루트 노드에서 "설정 가능"해야 합니다. 제가 놓치고 있는 것이 없다면, 이것은 Godot의 현재 버전에서 수동으로 정렬되어야 합니다. 동적 시스템의 이점과 더 쉬운 스크립팅을 결합하기 위해 이것이 어떻게든 자동화될 수 있다면 좋을 것입니다.

내가 생각하고 있는 한 가지는 Node.js의 하위 클래스에서 사용할 수 있는 "동적 상속" 시스템입니다. 그러한 스크립트에는 속성/메서드의 두 가지 소스가 있습니다. 하나는 확장하는 스크립트의 소스이고 다른 하나는 장면 구조 내의 자식에서 "버블업된" 소스입니다. 따라서 Bomb에 대한 내 예제는 bomb.gd 스크립트의 멤버 변수 섹션 내에서 export lifted var $Timer.wait_time [= value?] as detonation_time 와 같이 됩니다. 시스템은 기본적으로 _ready 콜백에서 $Timer.wait_time = detonation_time 를 생성하고 Bomb 노드의 부모로부터 $Bomb.detonation_time = 5 를 허용하여 $Timer.wait_time = 5 가 설정되도록 하는 getter/setter를 생성합니다.

MoveRightTrait가 있는 OP의 예에서는 mysprite.gd가 연결된 노드에 MoveRightTrait가 자식 노드로 포함됩니다. 그런 다음 mysprite.gd에 lifted func $MoveRightTrait.move_right [as move_right] 와 같은 항목이 있습니다(이름이 같을 때 'as'는 선택 사항일 수 있음). 이제 mysprite.gd에서 생성된 스크립트 객체에 대해 move_right를 호출하면 자동으로 적절한 자식 노드에 위임됩니다. 아마도 신호가 버블링되어 루트에서 자식 노드에 연결될 수 있습니까? 아마도 전체 노드는 func, signal 또는 var 없이 lifted $MoveRightTrait [as MvR] 로 버블링될 수 있습니다. 이 경우 MoveRightTrait의 모든 메서드와 속성은 mysprite.move_right로 mysprite에서 직접 액세스하거나 'as MvR'이 사용되는 경우 mysprite.MvR.move_right를 통해 액세스할 수 있습니다.

이것은 인스턴스 브랜치의 루트에 있는 씬 구조에 대한 인터페이스 생성을 단순화하고, 그들의 "블랙박스" 특성을 증가시키고 Godot의 다이내믹한 씬 시스템의 힘과 함께 스크립팅 편의성을 얻는 방법에 대한 하나의 아이디어입니다. 물론 고려해야 할 측면 세부 사항이 많이 있습니다. 예를 들어 기본 클래스와 달리 자식 노드는 런타임에 제거할 수 있습니다. 해당 오류의 경우 호출/액세스하는 경우 버블링/리프트된 함수 및 속성이 어떻게 작동해야 합니까? 올바른 NodePath가 있는 노드가 다시 추가되면 해제된 속성이 다시 작동하기 시작합니까? [YES, IMO] 또한 Node에서 파생되지 않은 클래스에서 'lifted'를 사용하는 것은 오류가 됩니다. 그런 경우에는 버블/리프트할 자식이 절대 없기 때문입니다. 또한 노드에 동일한 이름의 속성/메서드가 있는 경우 중복된 "as {name}" 또는 "lifted $Timer1 lifted $Timer2"로 이름 충돌이 발생할 수 있습니다. 스크립트 인터프리터는 이러한 논리적 문제를 이상적으로 감지합니다.

나는 이것이 우리가 전달 함수와 초기화를 작성하지 않아도 되는 단지 구문상의 설탕일지라도 우리가 원하는 것을 많이 줄 것이라고 생각합니다. 또한 기본적으로 개념적으로 간단하기 때문에 구현하거나 설명하는 것이 그리 어렵지 않을 것입니다.

어쨌든 여기까지 읽으셨다면 감사합니다!

나는 모든 곳에서 "들어 올린"을 사용했지만 그것은 단지 예시일 뿐입니다.
using var $Timer.wait_time as detonation_time 또는 using $Timer 와 같은 것도 분명히 좋습니다. 어떤 경우든 자식 노드에서 편리하게 의사 상속을 받을 수 있으므로 인스턴스화할 분기의 루트에서 원하는 기능에 대한 일관된 단일 액세스 지점을 생성할 수 있습니다. 재사용 가능한 기능 부분에 대한 요구 사항은 노드 또는 해당 하위 클래스를 확장하여 더 큰 구성 요소에 자식으로 추가할 수 있다는 것입니다.

그것을 보는 또 다른 방법은 노드에서 상속된 스크립트의 "확장" 키워드가 "is-a" 관계를 제공하는 반면 스크립트에서 "사용" 또는 "리프트" 키워드를 사용하여 "버블업"한다는 것입니다. 자손 노드의 멤버는 단일 상속이지만 다중 "인터페이스"(예: Java)가 있는 언어에 존재하는 "구현"[헤이, 가능한 키워드]과 유사한 것을 제공합니다. 무제한 다중 상속(예: C++)에서 기본 클래스는 [정적 작성] 트리를 형성합니다. 비유하자면 저는 Godot의 기존 노드 트리 위에 편리한 구문과 상용구 제거를 레이어링하는 것을 제안하고 있습니다.

이것이 탐구할 가치가 있다고 판단되면 다음과 같은 디자인 공간 측면을 고려해야 합니다.
1) "사용"에서 직계 자녀만 허용해야 합니다. IOW using $Timer 는 아니지만 using $Bomb/Timer'? This would be simpler but would force us to write boilerplate in some cases. I say that a full NodePath ROOTED in the Node to which the script is attached should be legal [but NO references to parents/siblings allowed]. 2) Should there be an option that find_node의 the "using"-ed node instead of following a written in NodePath? For example using "Timer" with a string for the pattern would be slower but the forwarding architecture would continue to work if a referenced node's position in the sub-tree changes at run time. This could be used selectively for child nodes that we expect to move around beneath the root. Of course syntax would have to be worked out especially when using a particular member (eg. using var "Timer".wait_time as detonation_time is icky). 3) Should there be a way query for certain functionality [equivalent to asking if an interface is implemented or a child node is present]? Perhaps "using" entire nodes with aliases should allow testing the alias to be a query. So MoveRightTrait 사용 DirectionalMover in a script would result in node.DirectionalMover returning the child MoveRightTrait. This is logical because node.DirectionalMover.move_right() calls the method on the child MoveRightTrait. Other nodes without that statement would return null. So the statement node.DirectionalMover:`가 관례에 따라 기능 테스트가 된다면.
4) 상태 패턴은 "using"-ed 노드를 "using" 문에서 참조된 것과 동일한 인터페이스[덕 타이핑] 및 동일한 NodePath를 갖지만 변형 동작을 갖는 다른 노드로 교체하여 구현 가능해야 합니다. 장면 트리가 작동하는 방식으로 이것은 거의 무료로 작동합니다. 그러나 시스템은 상위를 통해 연결된 신호를 추적하고 교체된 하위에서 연결을 복원해야 합니다.

저는 지금 한동안 GDScript로 작업해 왔으며 어떤 종류의 특성/믹스인 및 프록시/위임 기능이 절실히 필요하다는 데 동의해야 합니다. 속성을 연결하거나 장면의 루트에 있는 자식 메서드를 노출하기 위해 이 모든 상용구를 설정해야 하는 것은 상당히 성가신 일입니다.

또는 구성 요소를 시뮬레이션하기 위해서만 트리 수준을 추가합니다(각 새 구성 요소로 모든 노드 경로를 깨뜨리기 때문에 상당히 빨리 복잡해집니다). 한 노드에서 여러 스크립트를 허용하는 메타/멀티 스크립트와 같은 더 나은 방법이 있습니까? 관용적 인 솔루션이 있으면 공유하십시오 ...

C++(GDNative)를 믹스에 넣으면 _ready 및 _init 가 서로 다르게 작동하기 때문에 상황이 더욱 악화됩니다(읽기: 기본값을 사용한 초기화가 반쯤 작동하거나 전혀 작동하지 않음).

이것이 내가 GDScript에서 해결해야 하는 주요 사항입니다. 전체 상속 구조를 구성하지 않고 노드 간에 기능을 공유해야 하는 경우가 많습니다. 예를 들어 플레이어와 상점 주인에게는 인벤토리가 있고, 플레이어+아이템+적에게는 통계가 있고, 플레이어와 적에게는 장비 아이템이 있습니다.

현재 나는 이러한 공유 '구성 요소'를 이를 필요로 하는 '엔티티'에 로드된 클래스 또는 노드로 구현하지만 지저분하고(노드에 대한 많은 검색을 추가하고 오리 타이핑을 거의 불가능하게 만드는 등) 대체 접근 방식에는 자체 단점이 있으므로 더 나은 방법을 찾지 못했습니다. 특성/믹스인은 내 생명을 절대적으로 구할 것입니다.

결론은 상속을 사용하지 않고 객체 간에 코드를 공유할 수 있다는 것입니다. 제 생각에 이것은 현재 Godot에서 깔끔하게 수행하는 것이 필요하지만 불가능합니다.

내가 Rust 특성(https://doc.rust-lang.org/1.8.0/book/traits.html)을 이해하는 방식은 그들이 Haskell 유형 클래스와 같다는 것입니다. 여기서 유형에 대해 정의해야 하는 일부 매개변수화된 함수가 필요합니다 특성을 추가하고 특성을 구현하는 모든 유형에 대해 정의된 일부 일반 함수를 사용하게 됩니다. Rust 특성이 여기에 제안된 것과 다른가요?

https://github.com/godotengine/godot-proposals/

여기에서 광범위하게 논의되었기 때문에 이 항목은 아마도 도매로 마이그레이션될 것입니다.

여기에서 광범위하게 논의되었기 때문에 이 항목은 아마도 도매로 마이그레이션될 것입니다.

_나는 제안의 "이동"이 무의미하다고 생각합니다. 사람들이 관심을 표명하면 godot-proposals를 닫고 다시 열도록 요청하고 필요한 경우 다른 제안을 실제로 구현하도록 요청하는 것이 좋습니다. 어쨌든..._

나는 1년 전에 이 문제를 우연히 만났지만 이제서야 특성 시스템의 잠재적인 유용성을 이해하기 시작했습니다.

누군가가 문제를 더 잘 이해하도록 영감을 주기 위해 현재 작업 흐름을 공유합니다(그리고 아마도 특성 시스템을 구현하는 것보다 더 나은 대안을 제안할 수 있음).

1. 프로젝트에서 사용된 각 노드 유형에 대한 구성 요소 템플릿을 생성하는 도구를 만듭니다.

@willnationsdev https://github.com/godotengine/godot/issues/23101#issuecomment -431468744

이제 이를 더 쉽게 만들 수 있는 것은 스니펫 시스템이나 매크로 시스템을 사용하여 개발자가 재사용되는 선언적 코드 섹션을 더 쉽게 생성할 수 있도록 하는 것입니다.

당신의 발자취를 따라 걷는다... 😂

tool
extends EditorScript

const TYPES = [
    'Node',
    'Node2D',
]
const TYPES_PATH = 'types'
const TYPE_BASENAME_TEMPLATE = 'component_%s.gd'

const TEMPLATE = \
"""class_name Component{TYPE} extends {TYPE}

signal host_assigned(node)

export(bool) var enabled = true

export(NodePath) var host_path
var host

func _ready():
    ComponentCommon.init(self, host_path)"""

func _run():
    _update_scripts()


func _update_scripts():

    var base_dir = get_script().resource_path.get_base_dir()
    var dest = base_dir.plus_file(TYPES_PATH)

    for type in TYPES:
        var filename = TYPE_BASENAME_TEMPLATE % [type.to_lower()]
        var code = TEMPLATE.format({"TYPE" : type})
        var path = dest.plus_file(filename)

        print_debug("Writing component code for: " + path)

        var file = File.new()
        file.open(path, File.WRITE)
        file.store_line(code)
        file.close()

2. 구성 요소를 호스트로 초기화하는 데 재사용할 정적 메서드를 만듭니다(예: 루트).

class_name ComponentCommon

static func init(p_component, p_host_path = NodePath()):

    assert(p_component is Node)

    # Try to assign
    if not p_host_path.is_empty():
        p_component.host = p_component.get_node(p_host_path)

    elif is_instance_valid(p_component.owner):
        p_component.host = p_component.owner

    elif is_instance_valid(p_component.get_parent()):
        p_component.host = p_component.get_parent()

    # Check
    if not is_instance_valid(p_component.host):
        push_warning(p_component.name.capitalize() + ": couldn't find a host, disabling.")
        p_component.enabled = false
    else:
        p_component.emit_signal('host_assigned')

첫 번째 스크립트로 생성된 구성 요소(특성)는 다음과 같습니다.

class_name ComponentNode2D extends Node2D

signal host_assigned(node)

export(bool) var enabled = true

export(NodePath) var host_path
var host

func _ready():
    ComponentCommon.init(self, host_path)

(선택 사항) 3. 구성 요소 확장(특성)

@vnen https://github.com/godotengine/godot/issues/23101#issuecomment -471816901

그게 내 생각이야. 나는 그것이 충분히 간단하고 코드 재사용에 대한 거의 모든 사용 사례를 다룹니다. 나는 특성을 사용하는 클래스가 특성 메소드를 재정의하도록 허용할 것입니다(컴파일 타임에 수행할 수 있는 경우). 특성은 다른 특성을 확장할 수도 있습니다.

당신의 발자취를 따라 걷는다... 😂

class_name ComponentMotion2D extends ComponentNode2D

const MAX_SPEED = 100.0

var linear_velocity = Vector2()
var collision

export(Script) var impl
...

실제로 내보낸 Script 는 구성 요소당 특정 호스트/루트 노드 유형의 동작을 구동하기 위해 이러한 구성 요소에서 사용됩니다. 여기서 ComponentMotion2D 에는 주로 두 개의 스크립트가 있습니다.

• motion_kinematic_body_2d.gd
• motion_rigid_body_2d.gd

그래서 아이들은 여전히 ​​여기서 host / root 행동을 합니다. host 용어는 내가 상태 머신을 사용하여 가져온 것이며, 상태가 노드 imo로 더 잘 구성되어 있기 때문에 특성이 완벽하게 적합하지 않을 수 있는 부분이 여기에 있습니다.

구성 요소 자체는 onready 멤버로 만들어 루트에 "하드와이어링"되어 상용구 코드를 효과적으로 줄입니다(실제로 이들을 object.motion 로 참조해야 하는 비용 부담).

extends KinematicBody2D

onready var motion = $motion # ComponentMotion2D

이것이 문제를 해결하는 데 도움이 될지 확실하지 않지만 C#에는 클래스 유형의 기능을 확장하는 확장 메서드 라는 것이 있습니다.

기본적으로 함수는 정적이어야 하며 첫 번째 매개변수는 필수이며 self 여야 합니다. 정의로 보면 다음과 같습니다.

확장자.gd

# any script that uses this method must be an instance of `Node2D`
static func distance(self source: Node2D, target: Node2D):
    return source.global_position.distance_to(target.global_position)

# any script that uses this method must be an instance of `Rigidbody2D`
# a `Sprite` instance cannot use this method
static func distance(self source: Rigidbody2D, target: Node2D):
    return source.global_position.distance_to(target.global_position)

그런 다음 distance 메서드를 사용하려면 다음을 수행합니다.

플레이어.gd

func _ready() -> void:
    print(self.distance($Enemy))
    print($BulletPoint.distance($Enemy))

나는 그것에 익숙하지만 문제를 해결하는 데 도움이되지 않습니다. 헤헤 그래도 감사합니다.

@TheColorRed 확장 방법은 이미 제안되었지만 동적 언어에서는 실현 가능하지 않다고 생각합니다. 나는 또한 그들이 처음에 이 토론을 시작한 근본 문제를 해결했다고 생각하지 않습니다.

또 다른 참고 사항으로, GDScript에 대한 많은 제안을 GIP로 열 것입니다( @willnationsdev 가 상관하지 않는 경우 포함됨).

나는 여전히 특성이 OO 언어에서 수평으로 코드를 공유하는 것이 가장 합리적이라고 믿습니다(다중 상속 없이, 하지만 그렇게 가고 싶지는 않습니다).

동적 언어에서는 실현 가능하지 않다고 생각합니다.

GDS는 동적입니까? 확장 메소드는 유형이 지정된 인스턴스로만 제한될 수 있으며 다른 언어에서와 정확히 동일하게 작동합니다. 컴파일 중 메소드 호출을 정적 메소드(함수) 호출로 대체하는 구문 설탕뿐입니다. 솔직히 말해서, 저는 프로토타입 ala JS 또는 메소드를 클래스 또는 심지어 인스턴스에 연결하는 다른 동적 방법보다 먼저 포주(ext. 메소드)를 선호합니다.

우리가 무엇을 하기로 결정하든지 이름을 "포주"로 지정하지 않기를 바랍니다.

GDS는 동적입니까?

이 맥락에서 "동적"에 대한 많은 정의가 있습니다. 분명히 하자면, 변수 유형은 컴파일 시간에 알려지지 않을 수 있으므로 런타임에 메서드 확장 검사를 수행해야 합니다(어떤 방식으로든 성능이 저하됨).

확장 메서드는 유형이 지정된 인스턴스로만 제한될 수 있습니다.

이 작업을 시작하면 GDScript를 유형만 지정할 수도 있습니다. 그러나 그것은 내가 여기에서 하지 말아야 할 완전히 다른 논의입니다.

요점은 사용자가 스크립트에 유형을 추가했기 때문에 작업이 시작되거나 중지되어서는 안 된다는 것입니다. 그럴 때면 거의 항상 혼란스럽습니다.

다시 말하지만, 나는 그것이 어쨌든 문제를 해결한다고 생각하지 않습니다. 우리는 동일한 코드를 여러 유형에 첨부하려고 하는 반면 확장 메서드는 한 유형에만 추가합니다.

솔직히 말해서, 저는 프로토타입 ala JS 또는 메소드를 클래스 또는 심지어 인스턴스에 연결하는 다른 동적 방법보다 먼저 포주(ext. 메소드)를 선호합니다.

아무도 (런타임에) 메서드를 동적으로 연결하는 것을 (아직) 제안하지 않았으며 나도 원하지 않습니다. 특성은 컴파일 시 정적으로 적용됩니다.

원래 Hax와 믹스인 매크로 라이브러리에 대해 언급했지만 대부분의 사용자가 타사 언어를 사용하지 않는다는 것을 깨달았습니다.

나는 최근에 이것이 필요하게 되었습니다.

사용자가 상호 작용할 수 있지만 동일한 부모를 공유할 수 없는 일부 개체가 있지만 유사한 API 그룹이 필요합니다.

예를 들어 동일한 부모로부터 상속할 수 없지만 유사한 API 세트를 사용하는 일부 클래스가 있습니다.
창고: 재정, 삭제, MouseInteraction + 기타
차량: 재정, 삭제, MouseInteraction + 기타
VehicleTerminal: 재정, 삭제, MouseInteraction + 기타

재정의 경우 get_finances_component()가 게임 개체에 대해 전혀 신경 쓰지 않기 때문에 충분한 API이므로 최소한의 상용구 코드가 필요하기 때문에 구성을 사용했습니다.

다른 사람:
MouseInteraction 및 Deection 게임 개체에 대해 알아야 하므로 복사하여 붙여넣기만 하면 됩니다. 이상한 위임을 하지 않는 한 일부 구성은 여기에서 작동하지 않습니다.

Warehouse:
  func delete():
      get_delete_component().delete(self);

그러나 그것이 상속된 클래스라면 필요할 경우 삭제 코드의 일부를 다시 작성할 수 있는 삭제 작동 방식을 재정의할 수는 없습니다.

마우스 상호 작용 및 선택 게임 개체에 대해 알아야 하므로 복사하여 붙여넣기만 하면 됩니다. 이상한 위임을 하지 않는 한 일부 구성은 여기에서 작동하지 않습니다.

현재 onready 노드를 통해 구성 요소에 액세스합니다. 비슷한 일을하고 있습니다.

# character.gd

var input = $input # input component

func _set(property, value):
    if property == "focused": # override
        input.enabled = value
    return true

그래서 이거:

character.input.enabled = true

다음과 같이 됩니다.

character.focused = true

@Calinou가 친절하게 내 문제를 지적했듯이 https://github.com/godotengine/godot-proposals/issues/758 은 이것과 밀접하게 관련되어 있습니다. 그룹에 특성을 추가할 수 있다는 제안에 대해 어떻게 생각하십니까? 이로 인해 스크립트 및 기타 오버헤드가 크게 필요할 수 있습니다.

공유 가능한 코드를 클래스에 주입하는 방법이 있으면 좋을 것입니다. 값을 내보낸 경우 이러한 값이 인스펙터에 표시되고 메서드와 속성을 사용할 수 있고 코드 완성으로 감지할 수 있습니다.

Godot 엔진에 대한 기능 및 개선 제안은 현재 전용 Godot 개선 제안(GIP) ( godotengine/godot-proposals ) 이슈 트래커에서 논의되고 검토되고 있습니다. GIP 추적기에는 제안서에 모든 관련 정보가 포함되어 생산적인 토론을 시작하고 커뮤니티가 엔진 제안서의 유효성을 평가하는 데 도움이 되도록 설계된 상세한 문제 템플릿이 있습니다.

기본( godotengine/godot ) 추적기는 이제 전적으로 버그 보고서 및 끌어오기 요청 전용이므로 기여자가 버그 수정 작업에 더 집중할 수 있습니다. 따라서 이제 주요 이슈 트래커에서 이전 기능 제안을 모두 종료합니다.

이 기능 제안에 관심이 있다면 주어진 문제 템플릿 에 따라 GIP 트래커에서 새 제안을 여십시오 (이미 존재하지 않는지 확인한 후). 관련 토론이 포함된 경우 이 닫힌 문제를 참조해야 합니다(새 제안에서 요약하는 것이 좋습니다). 미리 감사드립니다!

참고: 이것은 인기 있는 제안입니다. 누군가 이를 Godot 제안으로 옮기면 토론도 요약해 보세요.