귀하의 게시물을 정말 좋아합니다.

편집하다:
젠장, 이 단락을 간과했어

소스 수준에서 수정이 필요한 경우 실제로 파일을 프로젝트에 복사할 수 있는 방법이 있습니다. 그런 다음에만 파일을 프로젝트 폴더 자체로 가져와야 합니다. "복제된" 자산은 .custom과 같은 숨겨진 폴더에 있을 수 있습니다.

그래서 당신은 기본적으로 내가 가진 우려를 다뤘습니다. (죄송합니다)
워크플로 + 동작을 상상하는 방식에 대해 더 자세히 설명합니다.

게시하다:
하나의 워크플로는 IMO에서 간과됩니다.
자산을 자원으로 사용하거나 첫 번째 빌딩 돌로 사용합니다.
현재의 정말 투명하고 간단한 접근 방식을 사용하면 몇 가지 자산을 다운로드할 수도 있습니다. 일부 파일을 삭제합니다. 일부 png와 원하는 기능이 있는 스크립트를 유지하는 것보다. 현재는 작업하고 수정할 수 있습니다.

자산이 .local/godot/assets 폴더에 숨겨져 있으면 이 기능이 손실됩니다.

제안

자산은 여전히 ​​표시되고 편집기 파일 브라우저에 나열되어야 합니다. .local/godot/assets 폴더 또는 프로젝트 폴더 자체에 있는 경우 독립적입니다. 따라서 적절한 문서가 없거나 해당 문서에서 배우고 싶은 경우 파일을 탐색하고 작동 방식을 이해할 수 있습니다.
'자산'인 모든 폴더는 어떤 종류의 아이콘이 있는 폴더로 표시되어 자산이 무엇이고 실제 파일이 저장되는 위치에 대한 개요를 볼 수 있도록 해야 합니다.
또한 모든 자산을 나열하는 편집기 창이 있어야 합니다. (테이블에서)

• 다운로드 됨은 다운로드된 모든 자산을 나열합니다. 버튼 클릭으로 프로젝트에 추가할 수 있습니다. 그러나 그 외에는 자산 라이브러리의 자산과 동일합니다. 이 목록은 모든 프로젝트에서 동일하며 프로젝트 자체에는 영향을 미치지 않습니다. (개요를 쉽게 볼 수 있습니다. 프로젝트를 열 때 이 목록을 지우고 모든 자산을 다시 다운로드하는 것도 쉽습니다.)
• 항상 활성 (기본적으로 모든 프로젝트에 대해 "이 프로젝트에서 사용됨(활성/비활성)"으로 전환) 해당 자산은 컴퓨터의 모든 프로젝트에 추가됩니다(새로 생성된 자산도 포함). (애셋 자체에서 이를 허용해야 할 수도 있습니다.) 이는 실제로 편집자 지향적입니다. 구석에 있는 시계처럼 git 지원, 할 일 목록 또는 더 많은 기본 리소스를 갖기 위해:(사용자 지정 환경에서 각 프로젝트 시작 시 작업할 더 많은 테마와 많은 스프라이트)...
  프로젝트별로 수동으로 비활성화할 수 있습니다.
  그들은 여전히 ​​​​프로젝트 파일 시스템에 나열되어 있으며 다른 지원/플러그인처럼 작동합니다. 그래서 당신은 그들의 파일을 찾아보고 그들이 어떻게 작동하는지/무엇을 하는지 볼 수 있습니다.
• 이 프로젝트(활성/비활성)에서 사용되는 이것은 실제로 프로젝트 파일 시스템의 링크된 폴더를 표시합니다. 및 "추가"(여전히 .local/godot/assets 폴더 안에 있지만 프로젝트 로컬 파일처럼 작동합니다.) 파일을 프로젝트에 추가합니다.
  여기에서 활성화하려는 자산 버전을 선택할 수도 있습니다. 그리고 버전을 바꾸세요.

자산에서 파일을 편집/저장/업데이트 하려는 즉시 두 가지 옵션이 표시됩니다.

.local/godot/assets 에 저장

.local/godot/assets 에서 자산을 업데이트하여 사용자 정의 사용자 버전에 넣습니다.
패키지 관리자가 git 기반이면 사용자 지정 사용자 버전이 하나의 추가 커밋이 될 수 있습니다. 저장할 때마다 commit --amend 를 받습니다.
(예 3.2.5/user ) 및 다른 모든 프로젝트에서도 사용할 수 있습니다. (다른 프로젝트의 버전을 사용자 버전으로 업데이트할 때)
이것이 왜 유용한가요?
에셋 스토어의 테마는 거의 완벽하지만 글꼴 유형이 싫어...
글꼴 유형을 변경하고 새 자산 버전으로 저장합니다. 다른 모든 프로젝트를 다시 방문하고 자산 버전을 /user 로 변경합니다. 이제 당신은 행복합니다.
자산의 사용자 버전을 게시하는 버튼이 하나 있을 수도 있습니다.
따라서 자산 저장소에서 다른 ppl은 약간의 조정으로 사용자 버전을 선택할 수도 있습니다.
자산 git repo에 대한 홍보를 만들기 위한 중간 역할을 합니다. (또는 자산 작성자가 /user 버전에서 마스터의 새 버전으로 변경 사항을 체리 선택하기 위해 제거합니다.)

프로젝트에 로컬로 만들기

.local/godot/assets 폴더의 파일을 현재 프로젝트로 복사합니다... 특별한 자산 동작(예: 버전...)을 제거하고 이제 원하는 대로 이를 엉망으로 만들 수 있습니다. (또한 폴더는 자산으로서의 사용자 정의 모양을 잃습니다.)

이를 통해 자산 저장소는 템플릿의 사용 사례도 다룰 수 있습니다. 거의 모든 예술 관련 자산을 위한 완벽한 선택입니다. 자산에 대해 작업하여 필요한 만큼 만들 수 있기 때문입니다.
이미 다운로드한 많은 애셋(일부 기본 프로토타입 스프라이트를 예로 들 수 있음)을 항상 활성화하여 로컬로 만들고 가져올 수 있습니다.

무작위 생각

이것은 로컬 자산/리소스 라이브러리/컬렉션을 위한 훌륭한 솔루션일 수도 있습니다. .local/godot/assets 에 있는 폴더를 사용하면 OS 파일 관리자에서 검색하지 않고도 멋진 편집기 UI를 사용하여 Godot 프로젝트에 콘텐츠를 추가할 수 있습니다.

저는 AssetLib와 asset lib 통합(에디터와 GDScript 모두에서) 모두가 핵심 엔진에 포함하는 것의 대안으로 계속 추진한다면 사랑이 필요하다는 데 동의합니다.

그러나 나는 개인적 으로 이것이 플러그인이 얼마나 많이 푸시되어야 하는지에 동의하지 않습니다.

새로운 PR에서 우리가 스스로에게 묻는 첫 번째 질문 은 이것이 플러그인이 될 수 있습니까? 그러나 이것이 핵심에 충분히 사용될 것입니까? .

플러그인에 다음과 같은 문제가 있습니다.

• 사람들은 우선 자신이 무엇을 찾고 있는지 알아야 합니다. Godot는 초보자를 대상으로 합니다. 초보자 친화적인 소프트웨어는 일반적으로 누군가가 (합리적으로) 필요로 하는 모든 것을 갖기 위해 노력하고 있습니다. 그렇지 않으면 먼저 자신이 무엇을 놓치고 어떻게 얻을 것인지 알아야 하기 때문입니다.
  초보자가 Gentoo가 아닌 Ubuntu를 사용하는 이유가 있습니다. 당신이 그 의존성 시스템을 얼마나 훌륭하게 만들었는지에 상관없이.
• 결정 마비 가 존재합니다. Godot에 기능이 있으면 사용하는 데 잠시 시간이 걸립니다. 플러그인이 5개 있는 경우 어떤 플러그인을 사용할까요? 예를 들어 5개 이상의 콘솔 플러그인이 있습니다. 초보자는 어떤 것을 선택해야 하며, 그 이유는 무엇이며 이 결정에 합리적으로 얼마나 많은 시간을 소비해야 합니까?
• 플러그인은 버려지고 품질이 떨어지며 업데이트 시 뒤쳐집니다. 무작위 플러그인이 폭발하지 않을 것이라고 믿는 이유는 그 뒤에 충분한 사람들이 있는 Godot를 신뢰하는 것보다 훨씬 적습니다.
• Unity 를 참조하십시오. 그들의 자산은 대부분 유료 이며, 플러그인이 먼저 필요한 경우가 많은데, 결국 플러그인이 제대로 통합되지 않거나 업데이트로 인해 중단되거나 유료이고 일반적으로 최소한 의 지원을 감당할 수 있음에도 불구하고 중단됩니다.
• 문서 : 어쨌든 이것으로는 충분하지 않습니다. 핵심이 아닌 모든 기능은 공식 자습서/문서에서 사용할 수 없습니다. 플러그인에 대한 무작위 독신 사람들은 문서를 제공하지 않거나 짧은 예만 제공할 가능성이 높으며 프로젝트에서 해당 기능을 다른 사용자와 원활하게 통합하는 방법에 대한 데모 또는 본격적인 자습서를 제공하는 더 가치 있는 비트를 제공하지 않을 것입니다.

예:

• 스프링 암 노드. (https://github.com/godotengine/godot/pull/18822) 적절하게 작은 추가 기능은 자체 클래스로 분리되어 문제가 발생하지 않으며 모든 3인칭 게임은 아니지만 많은 3D 게임에서 사용될 것 입니다. 응답: 플러그인이어야 합니다.
• RNG의 경우에도 플러그인으로 사용하는 것이 논의되었습니다. 게임의 90%는 아닌 것처럼 어딘가에 RNG가 필요합니다.

편집: 분명히 말해서, 나는 팽창을 피하기 위한 것입니다. 그러나 이것은 균형이며 플러그인에 모든 것이 포함되지 않은 것에 대한 음성 지원을 원합니다. 매우 게임 전용이거나 널리 사용되지 않는 항목, 독점 플러그인, 큰 종속성, 예, Asset Lib에 넣어주세요 !

@karroffel 이것은 훌륭한 게시물이며 귀하가 말한 모든 것에 대부분 동의합니다. 그러나 나는 이 점에 대해 다음과 같이 논평하고 싶다.

자산은 연결된 버전으로 저장되며 모두 .local/godot/assets 또는 이와 유사한 곳에 저장됩니다. 더 이상 프로젝트 자체의 일부가 아니라 시스템 전체에서 사용 가능한 것입니다.

이것은 Python pip 시스템이 작동하는 방식과 유사합니다. 사람들은 최신 버전의 패키지가 시스템에 있는 다른 프로젝트를 망쳤다는 것을 깨달았습니다. virtualenv는 그 문제를 해결합니다. Javascript의 npm 에코시스템에서 모듈은 기본적으로 프로젝트에 로컬로 설치되며 시스템 전체는 선택 기능입니다( npm install --global ). 그런 다음 package-lock.json 를 소스 제어에 체크인하여 팀의 모든 사람이 모든 npm 모듈의 동일한 버전을 사용하고 충돌을 피하도록 합니다.

시스템 전체 패키지는 사람들 시스템의 팽창을 줄이기 때문에 좋습니다. 버전 고정은 팀이 일관된 버전 집합을 유지하는 데 도움이 되고 함께 잘 작동하는 전체 버전 모음을 식별하는 데 도움이 되기 때문에 좋습니다.

시스템 전체 경로로 이동하는 경우 버전 고정을 유지하는 것이 좋습니다. 예를 들어:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

프로젝트 A는 fsm-1.0을 사용하고 프로젝트 B는 fsm-1.1을 사용할 수 있습니다. 프로젝트 C가 제공되며 둘 중 하나를 다시 사용할 수 있습니다. 사용자는 dependencies.json 파일 또는 최소 패치, 마이너 또는 메이저 버전에서 특정 버전의 플러그인을 지정할 수 있어야 합니다.

종속성이 다운로드되면 dependencies-lock.json 파일이 생성되어 소스 제어에 체크인될 수 있습니다.

@mhilbrunner 확실히 동의합니다. "플러그인이어야 한다"는 사고방식이 너무 강하게 밀어붙여진 것 같아요. 바로 그 상황이 그런 생각을 촉발시켰습니다. SpringArm과 같은 더 일반적인 것들은 엔진에 포함될 가치가 있고 Juan이 제거되기를 원하는 InterpolatedCamera 는 매우 유용하고 멋지다고 생각합니다! 그것들이 몇 줄의 코드에 불과하다고 생각하더라도 올바르게 이해하는 데 시간이 걸리므로 "이것이 너무 작다"는 것도 AssetLibrary로 밀어붙이는 잘못된 정당화입니다.

내 생각은 대부분 "글쎄, 프로젝트 리더가 그렇게 말했는데 새로운 상황을 개선하기 위해 무엇을 할 수 있습니까?"에 집중되었습니다.

플러그인과 같은 기능에 대한 무거운 푸시가 조금 낮아지면 좋겠지만 어느 쪽이든 제시된 변경 사항이 많은 도움이 될 것이라고 생각합니다!

@saltares 네, 제 생각이었습니다. 저는 Rust에 대한 카고 의 열렬한 팬입니다. 그것은 거의 동일하게 작동합니다. 라이브러리는 로컬에서 필요했던 모든 버전의 시스템 전체 폴더에 설치됩니다. 설명은 하나의 파일에 있고 특정 구성은 .lock 파일에 있습니다. 꽤 잘 작동합니다!

나는 이것이 이미 토론을 촉발한 것을 기쁘게 생각합니다.

위의 사항에 대한 제 견해는 다음과 같습니다.

엔진에서 물건 밀어내기

엔진 외부로 물건을 밀어내는 것은 IMO 방식입니다. 배포 크기가 중요한 플랫폼(모바일, html5)이 너무 많고 팽창이 Godot 크기의 프로젝트에서 큰 관심사이므로 모든 것을 포함하는 것으로 만족할 수는 없습니다.

나에게 철학은 아래의 모든 기준이 충족되는 경우에만 엔진의 일부가 되어야 한다는 것입니다.

1. 비교적 자주 사용한다
2. 스스로 하기 어렵다
3. 이 기능을 수행하는 방법은 하나뿐입니다.

이것은 스프링 암, 지형을 배제하고 향후 InterpolatedCamera, Vehicle 등과 같이 엔진 외부에 있어야 한다고 생각하는 기능을 제거하는 데 도움이 되기를 바랍니다.

이것에 대한 주요 관심사는 무언가가 공식적이지 않으면 유지되지 않을 것이라는 점입니다. 이것은 여러분이 잘못 알고 있는 부분입니다.

아무도 이것들이 공식적이어서는 안 된다고 말하지 않았습니다. 우리는 공식 저장소를 가질 수 있고 퍼스트 파티 확장이 될 수 있습니다. 데모는 이런 식으로 유지되고 최신 상태이므로 공식 확장 저장소에서 작동하지 않는 이유를 모르겠습니다.

확장은 엔진의 일부처럼 느껴져야 합니다.

이 점에 관하여:

• 사용자 정의 노드를 더 쉽게 확장하고 언어 간 스크립트 상속을 허용합니다.

저는 이에 대해 매우 강력하게 반대합니다. 이렇게 하면 실질적인 이점이 전혀 없으며 구현 비용이 매우 비쌉니다. 죄송합니다. 좋은 기능처럼 느껴지지만 비용/이점/위험에 대한 가중치는 매우 부정적인 측면에 있습니다.

또한 사용자 지정 노드 또는 리소스가 마치 핵심이 아닌 것처럼 나타나야 하는 것이 최종 사용자에게 좋은 일이라고 생각합니다. 사용자는 바보가 아니며 이 정보를 숨겨서는 안 됩니다.

확장에서 새 노드가 추가되고 스크립트로 완료되면 생성 대화 상자에도 표시되어야 합니다.

• 스크립트를 첨부할 때 스크립트 상속은 제안되지 않습니다. 이러한 경우 재정의가 기본값입니다.

이것은 확실히 수행되어야 하며 매우 환영할만한 추가 사항이 될 것입니다.

• 자산의 시스템 전체 설치로 적절한 종속성 관리를 추가합니다. 수정을 위해 다시 가져올 수 있는 방법으로 애드온을 프로젝트 자체 밖으로 이동

이것에 대한 나의 느낌은 그것이 환상적으로 작동하거나 명백한 이유 없이 중단되는 완전한 혼란과 추가 기능을 초래할 수 있다는 것입니다. 다른 엔진이 이것으로 어떻게 작동하는지 살펴보면 나에게 의존성 관리가 그렇게 중요하지 않은 것 같습니다.

• 자산의 경우 매우 긴 경로를 피하기 위해 클래스 이름과 네임스페이스로 스크립트를 참조할 수 있습니다.

이것은 우리가 이전에 논의한 것이지만 우리가 도달한 결론은 대부분 스크립트 언어에 의존해야 한다는 것입니다(엔진 자체에서 핵심 ScriptDB로 제공하지 않음). 전역 클래스를 사용합니다.

이것에 대한 나의 느낌은 그것이 환상적으로 작동하거나 명백한 이유 없이 중단되는 완전한 혼란과 추가 기능을 초래할 수 있다는 것입니다.

우리의 경우 애드온이 자동으로 업데이트되어서는 안 된다고 생각하지만, 대신 설치된 버전 목록과 수동 업데이트가 있어야 사용자가 업데이트를 요청하고 문제가 있는 경우 즉시 확인할 수 있습니다.

이 댓글은 길이가 길기 때문에 축소된 섹션으로 구분됩니다.

카메라를 원하십니까? Godot에는 플레이어를 추적할 수 있는 카메라가 있습니다. 코드가 거의 또는 전혀 필요하지 않습니다. Godot에서 애니메이션을 만들고 싶으세요? 캐릭터 애니메이션을 만들 수 있을 뿐만 아니라, 그 동일한 시스템이 (거의) 당신이 열심히 작업한 컷씬 시스템을 대체할 수 있으며, 단지 5줄 정도의 코드만 있으면 됩니다. 이 편집기는 RPG in the Box와 같은 다른 편집기 를 만드는 데에도 사용되었습니다. Godot에서 얼마나 많은 것을 만들 수 있는지는 정말 환상적입니다.

이제 그것을 제쳐두고, 이 글을 읽는 누군가가 내가 엔진에서 물건을 밀어내는 것과 관련된 reduz의 요점에 응답하려고 할 때 내가 생각하고 있는 것을 이해할 수 있기를 바랍니다. (현재로서는 이에 대한 생각이 없기 때문에 "확장은 엔진의 일부처럼 느껴져야 합니다" 섹션에 대한 답변은 아닙니다.)

엔진 외부로 물건을 밀어내는 것은 IMO 방식입니다. 배포 크기가 중요한 플랫폼(모바일, html5)이 너무 많고 팽창이 Godot 크기의 프로젝트에서 큰 관심사이므로 모든 것을 포함하는 것으로 만족할 수는 없습니다.

나는 팽창이 우려된다는 데 동의할 수 있지만, 당신이 지금까지 제거하고 싶어하는 것을 볼 때, 나는 그 물건을 제거하는 것이 정말로 가치가 있는지 자문합니다. Vehicle, InterpolatedCamera 등과 같은 노드를 제거하더라도... 실제로 파일 크기 차이가 얼마나 될까요? 아마 반 메가바이트? 몇 메가 바이트? 몇 메가 바이트의 가치를 저장하더라도 어쨌든 35MB 다운로드와 45MB 다운로드의 차이점은 무엇입니까? 게임 자산은 관계없이 10MB의 공백을 빠르게 채울 것입니다! 엔진의 절반을 제거할 계획이 아니라면 요점을 모르겠습니다.

가능한 한 많은 공간을 절약하는 것이 정말로 염려된다면 최종 사용자가 대신 엔진에서 필요하지 않은 노드를 더 쉽게 제거하도록 제안할 수 있습니까? 엔진을 사용할 사람들이 팽만감이 괜찮은지 여부를 결정하게 하십시오. 그들을 위해 결정하지 마십시오.

이제 물론 우리는 우리에게 주어진 모든 단일 제안을 포함할 수 없습니다...

1. 비교적 자주 사용한다
2. 스스로 하기 어렵다
3. 이 기능을 수행하는 방법은 하나뿐입니다.

...이 지침은 엔진에 허용되어야 하는 항목을 조사하기 위한 훌륭한 출발점입니다. 문제 추적기를 통해 오는 모든 단일 기능 요청에 대해 세 가지 포인트가 모두 이미 고려되고 있다는 것은 의심의 여지가 없습니다.

아래의 모든 기준이 충족되는 경우에만 무언가가 엔진의 일부여야 합니다.

하지만 자. 기능이나 노드의 운명은 핵심 기능에 크게 의존해서는 안 됩니다. 귀하가 제안한 지침은 훌륭합니다. 오해하지는 마십시오. 하지만 우리는 이를 체크리스트로 사용해서는 안 됩니다. 이것이 YoYo Games가 포럼에서 기능을 제안할 때 하는 일이며 내가 그들의 엔진에서 밀려난 이유의 또 다른 부분입니다. 확장을 사용하여 만들 수 있습니까? 네? 그런 다음 우리의 응답은 확장입니다. 얼마나 많은 기능 요청이 엔진에 있는 것이 합리적인지, 구현하기가 얼마나 쉬울지, 커뮤니티가 어떻게 느끼는지에 관계없이 확장 기능으로 만들어질 수 있기 때문에 거부된 기능 요청 수를 맞춰보세요. 그 기능.

제가 말하고자 하는 바는 이러한 지침을 염두에 둘 수 있다는 것입니다. 기능이 제안될 때마다 고려할 수 있습니다. 그러나 그것들이 모두 적용되는지 여부가 기능이 들어갈지 여부를 결정하는 요소가 되어서는 안 됩니다. 이러한 지침과 아이디어를 비교하고, 각 지침이 얼마나 중요한지 고려하고, 해당 요소에 가중치를 적용합니다... 아이디어가 적용되지 않기 때문에 너무 자주 사용되는 것처럼 보인다고 해서 자동으로 나쁜 생각이 되는 것은 아닙니다(몇 년의 경험에도 불구하고 사용 방법의 실제 규모를 모를 수 있음을 명심하십시오). 아이디어가 스스로 구현하기 쉽다고 해서 자동으로 나쁜 아이디어가 되는 것은 아닙니다. 그리고 한 가지 이상의 방법으로 아이디어를 구현할 수 있다고 해서 그것이 나쁜 아이디어라는 의미는 아닙니다! 다른 사람들이 혜택을 받을 것이라고 생각하기 때문에 누군가가 아이디어 X를 제안하는 것은 말할 것도 없습니다.

이것은 자체적으로 초보자 친화적이라고 광고하는 엔진이며, 초보자가 엔진의 일부가 아닌 게임에 고유하지 않은 무언가를 코딩해야 할 때마다 또는 일부 자산 라이브러리를 찾아 필요한 코드를 얻을 수 있다는 점을 기억하십시오. , 또는 엔진에서 원하는 것을 얻기 위해 먼 길을 간다면, 다른 엔진을 향해 조금 더 멀리 밀어낼 수도 있고, 때로는 게임 개발 전체에서 멀어질 수도 있습니다.

tl;dr : 가이드라인은 체크리스트가 아니라 가이드라인으로 사용될 때 좋습니다.

이것에 대한 주요 관심사는 무언가가 공식적이지 않으면 유지되지 않을 것이라는 점입니다. 이것은 여러분이 잘못 알고 있는 부분입니다.

아무도 이것들이 공식적이어서는 안 된다고 말하지 않았습니다. 우리는 공식 저장소를 가질 수 있고 퍼스트 파티 확장이 될 수 있습니다. 데모는 이런 식으로 유지되고 최신 상태이므로 공식 확장 저장소에서 작동하지 않는 이유를 모르겠습니다.

나는 개인적으로 이 생각에 동의하지 않습니다. 위에서 말한 것과 함께(바닐라 엔진에서 제거해도 공간이 많이 절약되지는 않음), 모두 GDscript로 변환할지 아니면 해당 노드를 얻기 위해 엔진을 다시 컴파일합니다.

• 우리가 그것들을 C++로 유지하고 재컴파일이 필요하다면... 왜? 핵심 부분을 변경하거나 자체 기능을 추가하지 않는 한 엔진을 다시 컴파일해야 할 이유가 없습니다. 일반 사용자가 자사 노드를 얻기 위해 다시는 사용하지 않을 수 있는 다른 도구를 설치해야 하는 것과 함께 컴파일 프로세스가 완료되기를 기다리고 있기 때문에 개발에 추가 시간이 소요될 뿐입니다. 이제 그것은 팽만감처럼 들립니다!

• GDscript로 변환하면 GDscript의 모든 제한이 따릅니다. 추가 자식 노드의 잠재적인 오버헤드와 같은 제한 사항(특히 사용자에게 이 자사 노드를 장면으로 가져오도록 요청하는 경우), 클래스를 참조하기 위해 클래스 이름 대신 경로를 사용해야 하는 경우(이 문제를 해결했지만 처럼 보이지만 언급해야 할 필요가 있다고 생각합니다.), 낮은 성능(차이가 얼마나 작은지에 관계없이 여전히 낮습니다) 등. 재컴파일에서 다음으로 이동했기 때문에 C++보다 조금 더 이상적입니다. 드래그 앤 드롭, 하지만...

두 옵션 모두 이 노드의 파일을 모든 새 사용자(C++의 경우)가 있는 엔진으로 가져오거나 해당 파일을 사용하려는 모든 새 프로젝트(GDscript의 경우)가 있는 프로젝트 폴더로 가져와야 함을 의미합니다. 다른 모든 사람에 대해서는 모르지만 그것이 나에게 번거롭게 들릴 뿐 아니라 첫 번째 지침("상대적으로 자주 사용됨")을 매우 논쟁의 여지가 있게 만드는 것처럼 들립니다. 내가 왜 그렇게 생각하는지 설명하려고 노력할 것입니다.

이러한 노드를 사용하려면 추가 노력이 필요하므로 이 자사 솔루션의 사용 횟수가 줄어들 것이며 이 자사 솔루션은 이전에 있었던 위치에서 더 이상 "상대적으로 자주" 사용되지 않을 것이라고 확신합니다. 결과적으로 사람들이 자사 솔루션이 있다는 것을 배우지 않을 때 동일한 기능을 다시 만드는 대안의 수를 천천히 증가시킬 것입니다. X 기능이 추가된 새 제품, Y 기능이 있는 새 제품, 두 기능을 모두 포함하지만 최적화되지 않은 새 제품 등을 만드는 것보다 개선되어야 합니다. 자사 솔루션이 있는지 모릅니다. 난장판 을 만들고 있습니다.

또한, 당신은 그들이 유지 될 것이라고 말합니다. 대단해! 그러나 누가 그들을 유지하겠습니까? 이 저장소에 새로운 것을 추가하기 위한 지침은 무엇입니까? 그리고 이 퍼스트 파티 확장 저장소가 안정적인 릴리스이든 마스터이든 상관없이 항상 작동하도록 하기 위해 노력할 것입니까? 기본적으로 별도의 프로젝트를 효과적으로 수행할 가치가 있습니까?

그건 그렇고, 나는 노드 지원 당 여러 스크립트를 구현하는 것을 훨씬 선호합니다
교차 언어 상속보다. 전자는 몇 줄에 불과합니다.
코드의..

2018년 6월 10일 일요일 13:51 Plyczkowski [email protected] 에서 다음과 같이 썼습니다.

이것에 대한 나의 느낌은 그것이 환상적으로 작동하거나 결과를 초래할 수 있다는 것입니다.
명백한 이유없이 중단되는 완전한 혼란 및 추가 기능.

우리의 경우 애드온이 자동으로 업데이트되어서는 안 된다고 생각하지만,
대신 버전이 나열된 설치된 목록이 있을 수 있습니다.
및 수동 업데이트를 통해 사용자가 업데이트를 요청하고 업데이트 여부를 즉시 확인할 수 있습니다.
무엇이든 고장났습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

노드당 여러 스크립트가 두 번 시도되었지만 항상 실패했습니다.

시도한 것은 멀티스크립트 노드이지만 번거로웠습니다.

2018년 6월 10일 일요일 15:01 Zireael07 [email protected] 에서 다음과 같이 썼습니다.

노드당 여러 스크립트가 두 번 시도되었으며 항상
실패.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

자산이 기본 제공 항목과 동일하게 보이지 않아야 함을 이해합니다. 그러나 나는 그것들이 사용자가 만든 스크립트보다 상위 클래스에 있어야한다고 생각합니다. 프로젝트에서 자산을 채굴하지 않고도 자산을 쉽게 교체/업그레이드할 수 있도록 명확한 구분이 있어야 합니다.

또한 자산에 대한 레이어를 추가하고 엔진과 더 잘 통합되도록 하여 확장하는 것은 자산 라이브러리를 통해 새로운 기능을 쉽게 제공하면서 코어를 작고 깨끗하게 유지하는 좋은 방법입니다. 자산이 노드/리소스뿐만 아니라 확장할 클래스에 대해서도 새로운 유형을 등록할 수 있다면 전역적으로 액세스할 수 있는 방식(예: 경로 종속적이지 않음)으로 엔진을 기반으로 프레임워크를 구축하는 데 큰 이점이 될 것입니다.

Escoria와 같은 프레임워크는 많은 이점을 얻을 수 있으며 RPG, 플랫포머, 비주얼 노벨 등과 같은 다른 프레임워크가 있을 수 있습니다.

내가 여기서 말하는 것은 매우 추상적이지만 내장된 것, 제3자 자산 및 사용자 코드가 무엇인지(그러나 이 분리가 제시됨)를 명확하게 구분하면 "핵심을 작게 유지하고 확장 기능을 제공합니다. " 훨씬 쉽게 전진하십시오.

언어 간 상속은 나에게 끔찍한 생각처럼 들립니다.

EditorData에서 TypeDB로 수행한 작업에서 수정 시 ProjectSettings에서 사전으로 변환되는 파일 경로 HashMap에 대한 네임스페이스 유형 이름을 유지했습니다. 내 지점에서 GDScript 파서 및 컴파일러는 이 데이터를 사용하여 유형에 대한 전역 이름을 생성합니다. 현재 사용자 정의 유형 스크립트가 표시됩니다. 스크립트는 이름으로 액세스하고 상속할 수 있습니다. 또한 이 데이터는 ProjectSettings를 볼 수 있는 모든 항목에 액세스할 수 있습니다. 따라서 에디터에 표시되는 CSharpScript는 ProjectSettings 사전에 입력되는 매핑을 생성할 수 있으므로 C#에서 선언된 유형이 GDScript에 액세스할 수 있습니다. 액세스할 때 Script 개체를 반환하는 C# 개체에서 ProjectSettings 사전 데이터를 래핑하는 방법도 있을 수 있습니다. 이렇게 하면 C#이 이름으로 GDScript 유형에도 액세스할 수 있습니다.

이 기술은 공유 네임스페이스를 핵심에서 벗어나 순수하게 Editor 컨텍스트 내에서 유지하므로 옵트인한 언어가 데이터에 액세스하는 자체 수단을 준비할 수 있습니다.

나는 언어 간 스크립트 상속을 가질 수 있다는 @karroffel 의 제안을 좋아합니다(그것이 가능한지조차 모릅니다). 어떻게 든 기본 스크립트에 대한 호출을 위임하고 동일한 모든 속성/신호/상수 등을 정의하는 메서드를 자동으로 복제합니다.

저 역시 에디터 전체에 대한 일부 플러그인과 단일 프로젝트에 대한 다른 플러그인을 유지하는 기능을 통해 AssetLibrary의 콘텐츠에 대한 보다 간소화된 액세스를 원합니다.

내가 만들고 있는 TypeDB 시스템은 또한 편집기 지원을 제공할 것입니다...

1. 모든 사용자 정의 스크립트가 CreateDialog에 표시되도록 하기
2. 사용자 정의 유형 스크립트를 확장하면 노드에 스크립트를 추가할 때 해당 스크립트를 자동으로 확장할 수 있습니다.
3. 사용자 정의 유형 스크립트를 확장하는 스크립트를 제거하면 제거 후 사용자 정의 유형 스크립트가 복원됩니다(따라서 사용자 정의 스크립트를 제거할 수 없습니다. 대신 편집기에서 "유형 변경" 명령을 사용해야 함).

또한 내가 만들고 있는 모든 인터페이스 변경은 사용자 정의 유형 스크립트를 스크립트로 명확하게 이해하고 문제의 스크립트에 액세스할 수 있도록 유지합니다. 사용자는 항상 스크립트가 무엇인지 알고 스크립트에 접근할 수 있도록 허용하지만 여전히 어느 정도는 엔진 내 객체처럼 느껴지게 합니다. GDScript 내에서도 이름은 마치 핵심 유형인 것처럼 전역적으로 액세스되지 않고 Scripts 라는 전역 사전에서 추출됩니다. 지금까지는 사용자 정의 유형 스크립트로 작업했지만 결국 사전이 사용자 정의 유형 장면과 프로젝트에서 사용할 수 있는 모든 일반 스크립트 또는 장면을 등록하도록 확장하고 싶습니다. 스크립트 언어가 그렇지 않은 경우 가져오기 시스템을 통해 가능합니다 네임스페이스 유형 이름을 획득하는 간단한 수단이 있습니다.

나는 이 제안의 사고 과정의 일부였기 때문에 몇 가지를 지적하고 싶습니다.

Godot에 대한 나의 비전

TLDR: Godot는 매우 쉽고 모듈식이며 초보자 친화적인 방식으로 자산과 플러그인으로 고도로 확장될 수 있는 도구라고 생각합니다.

내 SpringArm 홍보물을 거부한 동기는 합리적 이상이며, 이것이 @karroffel 과 내가 엔진이 경량화와 동시에 사용자 친화성을 유지하기 위해 취할 수 있는 방향에 대해 논의한 이유입니다.

내가 보고 싶은 것은 핵심 엔진이 깨끗하고 작고 빠르며 애드온과 플러그인이 잘 통합된 생태계입니다.
ArchLinux에는 하나 이상의 패키지 저장소가 있으므로 Godot에 핵심 기능(및 현재 핵심인 노드)에 대한 "공식"(Godot에서 관리) 저장소와 커뮤니티를 위한 또 다른 저장소가 있으면 좋을 것 같습니다. Godot 코어 "확장 저장소"에는 코딩하기 어렵지만 엔진의 바닐라 버전과 함께 제공되기에는 충분하지 않은 모든 노드를 넣을 것입니다.
참고로, 일부 기능은 코딩하기 쉽지만 이러한 몇 줄을 작성하기 전에 많은 연구가 필요할 수 있다는 점에서 종종 고려되지 않습니다.

사용자가 엔진 자체를 "확장"하는 것처럼 느끼는 플러그인 및 자산을 다운로드할 수 있다고 상상합니다. 다운로드하는 항목에 따라 Godot-fps 또는 Godot-platformer 또는 Godot-racing이 있습니다.

Godot는 에디터 확장으로 Unity를 능가하는 진정한 Unix와 모듈식 느낌을 주는 최초의 엔진이 될 수 있습니다. 여러분 중 많은 사람들이 여러분의 Linux 시스템이 "그 배포판"이 아니라 여러분만의 고유한 기능을 갖춘 맞춤형 시스템일 때 얼마나 기분이 좋은지 알고 있습니다.

장점

TLDR: 이 접근 방식은 Godot 관리가 엔진 팽창에 대해 너무 많이 걱정하지 않고 하드 코어 기술 핵심 기능과 사용자 친화적인 플러그인을 별도로 관리할 수 있도록 합니다.

이 제안의 좋은 점은 또한 관심사의 분리와 기여자의 처리입니다. 현재로서는 무엇이 핵심이고 무엇이 옳지 않은지 명확하지 않다고 생각합니다. 말할 수 있는 명확한 규칙이나 통계 데이터가 없습니다. 어떤 사람은 특정 기능이 널리 사용된다고 말하고 다른 사람은 그렇지 않다고 생각할 수도 있습니다.

Godot를 다른 "링"으로 나누면 PR과 기능을 보다 세밀하게 관리할 수 있는 기회가 주어 지며 @reduz 및 기타 매우 기술적인 개발자가 하드 코어 기술에 집중할 시간을 더 많이 줄 수 있고 다른 팀 은 확장 링을 관리할 수 있습니다. "확장 링"이 필요에 따라 팽창할 것이기 때문에 엔진 팽창에 직면하는 것보다 사용자 피드백과 유용성 을 더 고려합니다.

다국어 상속 정보

Godot가 성장함에 따라 자산 저장소는 쉽게 불타오르는 엉망이 될 수 있습니다. 스크립팅 언어 간의 엄격한 구분은 사람들이 자산을 판매하고 자산 저장소에서 생태계를 성장시키려는 모든 시도를 말 그대로 파괴할 수 있으며, 프리랜스 도구 제작자가 Godot용 도구를 만들고 판매할 수 있는 많은 기회를 죽입니다.
활기찬 생태계를 개발하기 위해 어떤 chanche라도 원한다면 언어 다리가 더 완벽해야 합니다.
현재로서는 언어 간 상속이 훌륭하게 들리지만 이 문제에 대해 말할 만큼 기술적인 사람은 아닙니다. 특히 C# 주변에 거대한 커뮤니티가 있기 때문에 곧 나타날 가능성이 있는 문제를 지적하고 싶습니다.

사용성에 대한 참고 사항

저는 거의 1년 동안 Godot를 사용해 왔으며, 최근에는 기능을 결정하는 사람들이 작은 데모보다 더 큰 것에는 엔진을 사용하지 않는 것 같습니다. @LikeLakers2 는 개발 중인 핵심 팀에 깊이 관여하지 않는 일부 사용자가 공유하는 문제를 지적했습니다.

나는 팽창으로 간주되는 것이 더 큰 계획에서 사소한 주제라고 생각합니다. 우리가 지금 내리는 결정이 Godot의 전체 생애 동안 준수해야 하는 것과는 다릅니다. 오픈 소스이기 때문에 우리가 원할 때마다 변경할 수 있는 유일한 문제는 기다릴수록 변경에 대한 결정이 더 무거워진다는 것입니다.

이제 그것은 다른 날의 토론이기도 합니다. 지금 현재의 사실은,

1. Godot는 작고 빠른 휴대용 게임 엔진입니다. 그리고 많이 좋아하지만....
2. Godot의 실행 파일은 다양한 요인에 따라 약 45-60MB입니다. 그러나 내보내기 템플릿은 최대 300MB입니다. 이제 첫 번째 요점에 큰 타격을 입혔습니다.
3. Godot에는 Camera Follow, Parallax BG 및 Vehicles와 같은 초보자를 위한 놀라운 기능이 많이 있습니다. 이는 다른 유사한 게임 엔진에 비해 큰 장점입니다. Godot에서 게임을 훨씬 간단하게 만들 수 있기 때문입니다. 그리고 Godot는 그러한 도구에 대한 자체 구현을 작성할 기술이 없는 많은 초보자 개발자를 위한 집입니다.

이제 일부 사람들이 부풀려 졌다고 생각하는 기능을 제거하면 어떻게 될까요? 글쎄, 엔진은 확실히 더 컴팩트하지만 그것이 필요합니까? 100MB 엔진이 내 요구 사항을 더 잘 충족한다면 다운로드하는 데 문제가 없다고 생각합니다. 그러나 수출은 어떻습니까? 100MB 엔진이 더 큰 게임을 수출하지 않습니까?

아마도 그렇습니다. 그러나 데스크탑이 256BG SSD + 1TB HDD 미만을 사용하지 않는 것 같고 심지어 전화도 최소 16GB에서 시작하는 공간이 있는 세상에서 이 공간은 모두 증가 할 가능성이 큽니다. 나쁜?
아직 제거할 필요가 없으며 몇 가지만 더 잘 관리하기 시작하면 됩니다.
기능은 핵심에 있어야 하는지 여부를 결정해야 하는 일종의 중요도 목록이 있어야 하지만 그것이 법이 되는 것이 아니라 경험의 법칙이 된다는 의미입니다.

그리고 nit-pickers의 경우 매우 사용하지 않는 도구를 제거할 수 있지만 그게 전부입니다. 우리가 부주의하지 않는 한 기능은 엔진을 부풀리지 않습니다. 그리고 Unity의 모든 부풀려진 상황에서도 사람들이 Unity를 사용하는 것을 막지는 못했습니다.
그리고 내 말은 우리가 팽만감에 대해 신경 쓰지 말아야 한다는 뜻이 아니라 조심하는 것과 편집증이 되는 것은 완전히 다른 문제라는 뜻입니다.

다중 언어 상속에 관해서는 여기에서 실제로 사용하지 않습니다. 물론 우리는 상속이 아닌 여러 언어의 스크립트와 상호 작용할 수 있어야 합니다! 그만한 가치가 없어 보이는 혜택으로 상상할 수 있는 것보다 더 많은 작업이 필요할 것입니다.
반면에 멀티 스크립트는 애드온 생성에서 더 나은 모듈화에 이르기까지 많은 문제에 대한 솔루션일 수 있습니다. 그것이 내 관점이지만.

상자에 들어 있는 노드 및 리소스 유형의 수를 제한하는 것과 관련하여 할 말이 있습니다. 덜 사용되는 자산을 외부 다운로드로 흩뿌리면 1. 새로운 사람들이 기능의 폭에 압도되지 않고 "혼돈"함으로써 시스템을 훨씬 더 쉽게 파악할 수 있습니다(결정 마비). 2. 더 좁은 사용 사례 시나리오 자산 중 일부가 나중에 다른 API와 함께 제공되는 것만큼 좋지 않은 워크플로를 갖게 되더라도 레거시 수하물을 많이 만들지 마십시오.

후자가 내장형으로 발생하면 내장형으로 고정됩니다. 다운로드 가능한 자산에서 발생하는 경우 가장 인기 있는 자산은 시간이 지나면서 사실상의 표준이 되는 경향이 있지만 그들의 운명이 Godot의 운명과 영구적으로 얽혀 있지는 않습니다. 즉, 예상되는 코어 호환성을 깨는 것만큼 걱정할 필요 없이 모호하게 사라질 수 있습니다.

교차 언어 상속 지점에 대한 설명이 필요합니다. 나는 그것을 나쁜 생각이라고 생각할 뿐만 아니라 그것이 원격으로 어떻게 가능한지조차 알지 못합니다.

1. Godot의 실행 파일은 다양한 요인에 따라 약 45-60MB입니다. 그러나 내보내기 템플릿은 최대 300MB입니다. 이제 첫 번째 요점에 큰 타격을 입혔습니다.

300MB 내보내기 템플릿? 자산을 의미합니까?

@neikeq 문제는 전체 프로젝트가 C#에 있지만 AssetLibrary에서 다운로드한 사용자 지정 노드를 사용하는 경우 해당 노드는 GDScript가 연결된 일반 노드일 가능성이 큽니다.

노드를 "확장"하고 싶다면 할 수 없습니다! 새 기능을 추가하기 위해 자식 노드를 추가할 수 있다고 생각하지만 그렇게 하면 항목을 재정의 할 수 없습니다.

구현

현재 스크립팅 언어는 일반화할 수 있는 상속된 호출에 대해 매우 유사한 패턴을 사용합니다.

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

여기의 패턴은

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

따라서 스크립트 상속 트리의 맨 아래에서 시작한 다음 그러한 메소드가 없으면 상위 레벨을 호출하려고 시도합니다.

각 스크립트에 언어별 상속 구조 대신 Ref<Script> parent_script 가 있는 경우 다음과 같이 일반화할 수 있습니다.

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

이것은 결국 좋은 생각이 아닐 수도 있지만 AssetLib를 더 많이 푸시하면 언어 간 항목을 재정의할 수 있는 옵션이 없는 것이 시간이 지남에 따라 문제가 될 수 있습니다.

@neikeq 이거 봐,

@swarnimarun 그것은 모든 플랫폼, 지원되는 모든 아치, 디버그 및 릴리스에 대한 내보내기 템플릿이며 크기는 엔진의 "팽창"과 완전히 관련이 없습니다. Linux X11 64비트 릴리스만 지원하도록 결정할 수 있으며 이 파일은 20MB가 됩니다...

@akien-mga 나는 그것을 부풀려 부를 의도가 없었습니다.
그러나 새로운 사용자는 개별적으로 빌드하거나 특정 플랫폼용으로 다운로드할 수 있다는 것을 알 만큼 경험이 충분하지 않은 전체 크기로 다운로드합니다.

이것이 우리가 초보자 사용자에게 제공하는 것과 어떻게 관련이 없습니까?

@akien-mga: 노드 제거에 대한 귀하의 주장이 옳았기 때문에 내보내기 템플릿 크기가 중요합니다.

배포 크기 중요(모바일, html5)

@swarnimarun @Zireael07 예 내보내기 템플릿 크기는 개별적 으로 중요하지만 제 요점은 템플릿 묶음의 크기를 측정해도 아무런 표시가 없다는 것입니다. 하나 의 템플릿(예: wasm 릴리스 템플릿, 3.4MB 압축 또는 Android 릴리스 APK, armv7 및 x86 libs로 압축 23MB)의 크기는 "개발에 필요한 모든 것을 다운로드하는 데 350MB가 걸립니다"(+ 아마도 10MB)보다 훨씬 더 관련성이 있습니다. 빌드해야 하는 경우 Visual Studio용 GB...). 크기가 중요한 플랫폼(웹, 모바일)에서 최소 게임의 크기가 어느 정도인지는 중요합니다.

배포 크기가 정말 중요하다고 생각하지만 고려해야 할 것은 개발자 시간이기도 합니다. 예를 들어, Unreal은 말 그대로 당신이 찾고 있는 모든 기능을 가지고 있지만, 너무 많다는 사실로 인해 무언가를 해야 할 때마다 먼저 어떤 내장 기능을 파악해야 하기 때문에 개발 프로세스가 매우 비효율적입니다. 사용하고 올바르게 사용하는 방법을 배워야 합니다.

이것은 내가 Godot에 대해 정말 사랑하는 것입니다. 기능을 즉시 코딩할 수 있습니다. 그러면 누군가 와서 "요, 우리가 사용할 수 있는 내장 기능이 있다는 것을 알고 계셨나요?"라고 말할 것입니다.

엔진에 너무 많은 기능이 있을 때의 문제는 해당 엔진으로 개발하는 것이 엄청난 피로감을 주는 경험이 된다는 것입니다. 예, 필요한 모든 기능이 있는 것은 좋지만 실제로 필요한 기능을 파악하기 위해 모든 기능을 살펴보는 것은 엄청난 고통입니다. 그것은 팽만감입니다. 이것이 바로 우리가 온디맨드로 잘 통합된 기능을 제안하는 이유입니다.

자산의 시스템 전체 설치로 적절한 종속성 관리를 추가합니다. 수정을 위해 다시 가져올 수 있는 방법으로 애드온을 프로젝트 자체 밖으로 이동합니다.

이것은 휴대성을 잃는 것과 동일합니다. 내 플러그인은 내 프로젝트의 일부입니다. 내가 작업하는 컴퓨터에 상관없이 모든 프로젝트에 대한 모든 플러그인의 구체적인 수정이 필요합니다... 내 플러그인을 .local/whatever에 저장하는 데 아무런 이점이 없습니다. . 이것은 내 프로젝트를 난독화하는 종류입니다.

res://addons 의 실제 시스템은 훌륭합니다... 사용자에게 무료이며 컴퓨터 주변에 휴대할 수 있습니다. 이 시스템에 대한 불만이 없다면 변경이 필요한가요? 유저들이 정말 불평하는 것들도 많은데...

@Ranoller 언제든지 플러그인을 게임 폴더에 복사할 수 있습니다.
어쨌든, 이 경우 project.godot은 플러그인을 종속성으로 나열하고 올바른 버전으로 새 컴퓨터에 다운로드됩니다.

다운로드? 내 플러그인은 pendrive 내부에 있는 프로젝트 안에 있고 git 저장소의 일부입니다... 제안을 이해하지 못합니다... 플러그인은 다른 코드와 동일하게 변경합니다... 나는 게임코드가 있는 플러그인에서 더 많은 코드를 변경합니다. 나는 버전별로 플러그인에 번호를 매기고 프로젝트 외부에서 작업하고 싶지 않습니다... 모든 한 줄의 코드 변경은 모든 컴퓨터의 모든 플러그인을 수동으로 변경해야 합니까?... 정말 플러그인은 프로젝트의 일부처럼 느껴집니다. .git 저장소에서 플러그인을 제공하는 것은 나에게 말도 안되는 일이지만, 나는 그것에 대해 뭔가를 이해하지 못한다고 생각합니다...

@Ranoller 아이디어는 수정할 필요가 없는 프로젝트 외부로 해당 플러그인을 이동하는 것입니다. 예를 들어 InterpolatedCamera 는 코드를 변경하지 않고 그대로 사용하려는 노드입니다.

TODO 목록이나 git 통합 등과 같은 편집기 전용 플러그인의 경우에도 마찬가지입니다. 사용하고 싶지만 변경되지 않는 것들입니다.

이것은 패키지 관리자와 매우 유사하며 라이브러리는 C 및 C++가 아닌 모든 언어에서 작동합니다. 모든 종속성을 지정하는 파일이 있으면 패키지 관리자가 해당 종속성을 가져옵니다. 이것은 PC를 변경한 경우에도 발생합니다. 패키지 관리자는 아직 존재하지 않는 패키지를 다운로드합니다.

무언가 를 수정하고 싶을 때 코드를 프로젝트로 가져옵니다. 그런 다음 git과 모든 소스 코드 등이 포함된 프로젝트에 있습니다. 그러나 항상 그런 것은 아닙니다.

내 제안은 실제로 수정해야 할 때까지 기본적으로 프로젝트 외부에 있는 것입니다.

현재 많은 자산은 대부분 수정해야 하는 템플릿입니다. 이러한 시스템을 갖추면 소스 수정이 아닌 API를 통해 보다 일반적인 용도로 변경될 수 있습니다.

@karroffel 그러나 언어 간 상속은 각 언어에서 어떻게 작동합니까? 엔진과 긴밀하게 결합된 GDScript에서는 쉬울 수 있지만 C#과 같은 범용 언어나 GDNative 위에 추가된 다른 언어의 경우 완전히 다른 이야기입니다.
나는 이것이 어떻게 성취될 수 있는지, 심지어 그것이 좋은 것보다 더 나쁜 것을 할 수 없다는 것을 진지하게 볼 수 없습니다.

IMO 프로젝트가 의존하는 애드온의 내용을 수정하는 것은 좋은 생각이 아닙니다. 수정이 필요한 경우 애드온 폴더 외부에 있는 콘텐츠를 복사하고 그곳에서 변경하면 됩니다.

편집: 또는 애드온 "포크" 😜

@neikeq 수정한 내용은 프로젝트 내부에 있습니다. 애드온을 수정하려는 경우 프로젝트 내부에 복사되고 로컬에서만 수정됩니다.

@karroffel 혼동을 피하기 위해 프로젝트 플러그인과 편집기 플러그인에 대한 아이디어가 필요할 수 있으며 둘을 명확하게 구분해야 합니다.

@QbieShay 수정한 파일을 수정하는 업데이트가 있으면 어떻게 되나요?

@neikeq 스크립트 상속은 이 문제에 대한 해결책 이 아니며 단지 하나일 것입니다. 현재 다른 프로그래밍 언어를 사용하려는 경우 연결된 스크립트로 노드의 기능을 재정의하는 좋은 방법은 없습니다.

Script API에서 메소드를 재정의하는 옵션이 있다면 그것도 좋을 것입니다! (기본적으로 새로운 방법을 외부적으로 정의하고 기존 방법을 재정의).

@PLyczkowski 그것도 유용할 제안이지만 제가 제안하는 것은 이에 국한되지 않고 이유가 있습니다.

InterpolatedCamera 의 예를 다시 살펴보겠습니다. 나는 그것에 대한 소스 코드를 만지지 않을 것이며, 단지 그것을 사용할 것입니다. 내 프로젝트에 소스가 있는 것은 낭비입니다. 또한 내가 만드는 대부분의 프로젝트는 모두 3D이므로 모든 프로젝트에 해당 코드를 복사해야 할 것입니다.

반면에 git 통합은 git hook으로 표현하기 어려운 사용자 지정 동작을 추가하는 데 매우 유용할 수 있으므로 사용자 지정이 필요합니다.

프로젝트 내부에 무언가가 있어야 할 때와 외부에 있을 때 편집자 여부에 관계없이 검은색/흰색 선이 없습니다.

@neikeq

수정한 파일을 수정하는 업데이트가 있으면 어떻게 합니까?

이 경우 버전 정보가 손실되어 더 이상 쉽게 업데이트할 수 없습니다. 그런 경우에는 git과 같은 도구를 사용해야 합니다.

아이디어는

• 프로젝트 외부: 더 쉽게 업데이트하고 프로젝트 간을 더 쉽게 가질 수 있습니다.
• 프로젝트 내부: 사용자 지정 가능, 자산 상태 손실, 자동 업데이트 없음

기본적으로 프로젝트에 복사하면 일반 파일이 됩니다.

이것을 읽으면 게임의 팽창을 피하고 파일 크기를 최소화하는 것이 유효한 것이라고 말할 수 있습니다. 그래도 여기에 몇 가지 아이디어를 던질 수 있습니다.

• Godot는 사용하지 않는 노드(즉, 많은 3D 게임이 있는 대부분의 2D 노드와 많은 2D 게임이 있는 대부분의 3D 노드)에서 사용하는 코드 게임을 제거하는 시스템을 사용할 수 있습니다. 이렇게 하면 게임 파일 크기를 줄이기 위해 새 노드 유형을 허용하지 않아야 하는 부담이 줄어듭니다. 예를 들어 Unity 사용자는 이미 훌륭한 결과와 유사한 것을 사용하고 있습니다.
• Godot는 아마도 Godot 사이트의 플러그인 페이지에 연결하는 내장 자산 브라우저를 가질 수 있습니다. 원하는 사용자 지정 노드를 선택하면 자동으로 올바른 위치에 설치됩니다. 사용하지 않는 플러그인은 게임 패키징 시 제거됩니다.
• 아마도 인기 있는 사용자 정의 노드가 Godot 빌드와 함께 번들로 제공될 수도 있습니다(블렌더가 애드온으로 하는 것처럼). 사용자 지정 노드는 일반적으로 더 높은 수준일 수 있고 어느 정도 일반 노드보다 블랙박스에 가깝기 때문에 표시해야 합니다.

어쨌든 내 2 센트.

@에이스드래곤

1. 귀하의 첫 번째 요점은 엔진 전반에 걸친 기능으로 있으면 정말 멋질 것입니다. 내보낸 게임이 노드를 사용하지 않거나 프로젝트에서 사용 중인 노드에서 노드를 사용하지 않는 경우 최종 바이너리에서 자동으로 제외할 수 있다면 멋질 것입니다. 그 외에는 현재 스위치에 의존하고 엔진을 다시 컴파일하기만 하면 됩니다. :-/

2. 이것은 기본적으로 자산 라이브러리가 이미 있는 것입니다. 문제는 종속성에 대한 개념이 없고 프로젝트 디렉토리에 직접 드롭하며 만드는 모든 프로젝트에 대해 시스템 전체에 주어진 플러그인 세트를 유지 관리할 수단이 없다는 것입니다.

3. 사용자 정의 노드는 항상 명시적으로 표시되므로 이에 대해 걱정할 필요가 없습니다(확장하기 위해 스크립트를 사용하여 사용자 정의 노드를 만들기 때문에 옆에 스크립트 아이콘이 있습니다). 스크립트이기 때문에 엔진과 함께 제공되지 않습니다. 그것들은 일종의 플러그인의 일부가 될 것이므로, 무언가를 수집하기 위한 "노드 확장" 리포지토리인 my godot-next 리포지토리와 같은 것이 있을 수 있습니다. 그것은 무엇보다 더 "공식적인"용량이 될 것입니다 (그 repo는 많은 작업을 사용할 수도 있습니다, lol).

좋아, 천천히 하지만 잡았다... 프로젝트 내부에 애드온을 유지한다면 현재 프로젝트와의 git 통합을 잃지 않고 이식성을 잃지 않고 다른 스크립트에서처럼 플러그인 코드에서 작업할 수 있습니다... 하지만 내가 변환하려는 경우 다른 개발자를 위한 도구 또는 내 모든 프로젝트를 위한 일반 도구의 플러그인 도구의 외부 git 리포지토리로 구현하고 자산 라이브러리를 사용하여 다른 사람들에게 변경할 수 있는 외부 패키지 형태로 공유합니다... 만약 저에게는 괜찮습니다... 다른 개발자가 도구를 사용하고 개인 버전이 필요한 경우 프로젝트 내부에 저장해야 하며 이 경우 플러그인이 실행되지 않습니다(자신의 작업을 잃지 마십시오 )... 그것은?

@Ranoller 예, 당신이 그의 제안의 요지를 파악했다고 생각합니다.

토론 중인 내용에 대한 몇 가지 피드백

1) 이것이 해결이 필요한 실제 문제라면 교차 언어 상속(미친 짓)보다 노드당 여러 스크립트(단 몇 줄의 코드)를 지원하는 것을 훨씬 선호합니다. 나는 이것이 여전히 해결해야 할 문제라고 생각하지 않는다.

2) 패키지 관리자와 시스템 전체에 걸친 애드온 설치 아이디어가 마음에 들지 않습니다. 나는 그것이 끔찍한 생각이고 이것으로부터 전혀 의미 있는 것을 얻지 못한다고 생각합니다. Unity 개발자가 대규모 프로젝트에서 에셋 버전을 업데이트하고 모든 것이 중단되고 수정하는 데 며칠을 보내는 것이 얼마나 충격적인 일인지 보았습니다.

3) 패키지 관리 자체에 대한 아이디어가 마음에 들지 않습니다. 저는 Unity 사용자가 대부분의 시간 동안 에셋 스토어에서 얻은 것을 끝없이 해킹하는 것을 보았습니다. 너무 자주 그들은 그것을 기반으로 사용한 다음 작업하고 자신의 용도에 맞게 사용자 정의합니다. 왜냐하면 얻는 자산은 원하는 방식의 60/70%에 불과하기 때문입니다. 그것이 어떻게 이루어지고 나중에 그들 자신의 일을 할 것입니다.

논의 중인 제안에서 실제로 얻을 수 있는 것은 아무것도 없다고 생각하므로 이 논의에 직접 추가할 계획은 없습니다.

사람들이 3D 항목 없이 간단한 방법으로 내보낼 수 있도록 허용하면 엔진 크기를 얼마나 줄일 수 있습니까? 많은 게임(절반? 절반 이상?)은 3D 기능을 필요로 하지 않지만 여전히 동일한 바이너리에 있습니다. 이론적으로 약간의 투자와 함께 모든 플랫폼에서 매크로를 사용하여 자신을 다시 컴파일할 수 있다는 것을 알고 있습니다.
또한 이 아이디어에 따라 모듈이 공식 엔진 배포판의 일부인 "내부" 동적 라이브러리인 경우 엔진에 더 많은 기능을 추가하는 것이 정말 쉽게 옵트아웃할 수 있다는 점에서 문제가 덜할 것입니다(그냥 ) 그러나 이와 같은 동적 라이브러리를 사용하면 일부 플랫폼(주로 모바일 및 HTML5)에서 약간의 제약이 있을 수 있습니다. 따라서 모듈의 경우 GDNative가 선호된다는 것을 이해할 것입니다(오 잠깐만... 동일한 문제가 있습니다^^).

@reduz 여러 스크립트가 어떻게 작동합니까? 그리고 엔진 확장에 어떤 기여를 합니까? 기존 문제에서 아이디어를 설명했습니까? (이 스레드에서 설명하기에는 너무 많을 것 같아서 질문합니다.)

자산의 시스템 전체 설치로 적절한 종속성 관리를 추가합니다. 수정을 위해 다시 가져올 수 있는 방법으로 애드온을 프로젝트 자체 밖으로 이동

아니요. 견고성을 위해 프로젝트 디렉토리에 저장하고 싶습니다. 그러나 패키지 관리자를 사용하여 수동으로 선택한 항목을 업데이트하는 방법과 시스템 전체에 캐싱을 사용하는 방법이 있을 수 있습니다.

팽창 문제에 관해서는 대신 _modules_에 대한 통제력을 높이면 감사하겠습니다. 이것은 이미 2018년 1월 Patreon 투표에서 투표되었습니다.

로드맵 우선 순위: 더 작은 바이너리 크기를 생성하기 위해 엔진의 컴파일 부분을 선택 해제하는 더 많은 옵션 [ 3.1에서 예상됨]

이 제안은 다양한 내용을 다루고 있고 사람들이 다양한 측면에서 다양한 문제를 제기하고 있기 때문에 언급하기 어렵습니다.

전반적으로 "종속성 관리자"에 대한 제안이 문서상으로는 좋아 보이지만 구현에서는 프로젝트 폴더에 애드온을 공급하는 것만으로는 얻을 수 없는 이점이 없다고 생각합니다. "설치가 더 쉬운" 경우 1가지를 해결하려면 종속성 관리를 위한 복잡한 메커니즘을 통합해야 합니다. 이 프로젝트에는 이미 3000개 이상의 이슈가 소규모 기여 ​​팀과 함께 열려 있습니다. 내 생각에는 종속성 관리와 같은 복잡한 것을 도입하는 것이 발판입니다.

나는 핵심이 미니멀해야 한다는 @reduz 의 말에 동의합니다. 제 생각에는 "핵심"으로 분류될 수 없는 모든 것이 독립적으로 통합되어야 합니다. 사용자로서 저는 Godot가 멀티 플랫폼 게임 _engine_이기를 기대합니다. 내가 Godot _게임 프레임워크_(차량, 보간된 카메라, 지형, 플레이어 컨트롤러 등)를 원하면 코어와 무관한 일류 애드온(또는 모듈?)으로 사용할 수 있어야 합니다. 애드온 스토리를 개선하면 이에 도움이 된다고 생각하지만 완전한 종속성 관리자와 자동화된 애드온 관리자는 낮은 순 이익을 위해 밀어붙이는 것 같습니다.

내 마지막 의견은 "초보자"를 대상으로 하고 "파워" 사용자를 포기하는 것에 대해 주의해야 한다는 것입니다. Godot는 강력한 기능(모듈, gdnative, gdscript, 편집기 등)과 유연성으로 인해 고급 사용자의 주목을 받고 있습니다. Godot를 테스트하고, 경계를 넓히고, API를 탐색하고, 종종 프로젝트에 다시 기여하는 것은 이런 종류의 사용자입니다. 이들은 여러 프로젝트에서 애드온을 재사용하기 위해 파일 시스템의 디렉토리에 대한 심볼릭 링크를 생성할 수 있는 동일한 사용자입니다.

코어에서 더 높은 수준의 노드를 제거하는 것이 아이디어라면 해당 노드를 쉽게 사용할 수 있어야 하고 다운로드를 위해 쉽게 찾을 수 있어야 합니다. 이상적으로는 "공식"으로 유지할 수 있으므로 가시성이 향상됩니다(엔진 내 노드와 마찬가지로). 그러면 공식 자산을 큰 문제 없이 데모 및 자습서에서 사용할 수 있습니다.

아웃소싱의 장점은 새 엔진 버전을 기다릴 필요 없이 개선하여 출시할 수 있다는 것입니다. 따라서 확장의 경우 새 릴리스를 포장하는 것이 훨씬 더 간단하기 때문에 버그를 즉시 수정할 수 있습니다.

나는 결국 패키지 관리가 대부분의 시간에 꽤 번거로울 것이라고 생각합니다. 프로젝트에 추가한 사용자 지정 노드의 새 버전의 경우에도 업데이트하면 다른 많은 문제가 발생할 수 있습니다(semver를 사용하더라도 현재 수정된 버그를 해결했을 수 있으므로).

일부 편집기 플러그인의 경우 OTOH에서는 프로젝트를 종료하고 자주 업데이트하는 것이 합리적일 수 있습니다. My Tiled 가져오기 플러그인이 한 예입니다. 게임과 함께 제공되는 것을 원하지 않고 더 많은 기능을 지원하고 버그 수정이 있는 최신 버전을 원할 가능성이 큽니다.

이것은 git 관리자 및 시간 추적기와 같은 다른 편집기 확장에 더 많이 적용됩니다. 팀 동료가 시간 추적기 플러그인을 가지고 있는지 여부는 신경 쓰지 않을 수도 있습니다. 프로젝트와 관련이 없습니다. 그러나 addons 폴더에 넣고 프로젝트 설정에서 활성화한 다음 나머지 게임과 함께 커밋하지 않도록 주의해야 합니다. 그것들은 아마도 플러그인의 소수이지만, 여전히 프로젝트에 연결되지 않은 시스템 전체 플러그인이 있는 경우에는 실제 사용 사례가 있습니다.

저는 중간 지점이 패키지 관리자를 Godot에 통합하지 않고 외부 도구로 만드는 것이라고 믿습니다. 공식적일 필요도 없습니다("승인"될 수 있음). 이를 지원하기 위해 기본 엔진에서 일부 변경이 필요한 경우(예: 전역 플러그인 사용) 추가하는 것은 큰 문제가 되지 않습니다. 특히 편집기 전용인 경우에는 더욱 그렇습니다.

그러면 유익하다고 생각하는 사람들이 사용할 수 있습니다. 그것이 널리 보급되고 모든 사람들이 그것을 사용한다면 우리는 기본 엔진에 완전히 통합할지 여부와 방법을 결정하기 위해 사용 통계와 사용성에 대한 피드백을 모두 갖게 될 것입니다.

이제 저에게 크로스 스크립트 상속은 불가능합니다(가능하다면). 멀티스크립트는 좀 이상하지만 더 깔끔한 방식으로 스크립트 간 상속을 효과적으로 대체합니다. 다음과 같은 몇 가지 문제가 발생하지만 동일한 개체에서 다른 스크립트의 기능을 호출하는 방법은 무엇입니까? 그것은 또 다른 토론이라고 생각합니다.

OTOH라는 이름으로 스크립트를 참조하는 것은 정말 좋은 것 같습니다. 이상적으로는 모든 리소스를 이름으로 참조할 수 있으므로 이동하기로 결정한 경우 경로를 해결하는 데 문제가 없습니다.

@vnen 내가 여전히 볼 수 있는 유일한 문제는 애드온과 프로젝트 간의 비호환성입니다. 그 문제를 어떻게 해결하시겠습니까?
왜냐하면 Godot에서 유지 관리하는 공식 확장 라이브러리가 있다면 모든 노드가 가능한 모든 언어로 제공되거나 사용자 친화성을 유지할 수 있는 유일한 방법은 교차 언어 상속을 볼 수 있기 때문입니다.

@vnen 모든 자산을 이름으로 참조하면 충돌이 발생합니다. 프로그래머만 클래스에 고유한 이름을 입력하고 사용할 수 있기 때문에 스크립트에 더 적합합니다(또는 드물게 리소스). 다른 것들의 경우, 경로를 제거하면 아티스트, 디자이너 등이 모든 자산의 이름을 고유하게 지정해야 하는 경우가 아니면 https://github.com/godotengine/godot/issues/15673 이 필요합니다. 여전히 이름 바꾸기 문제가 있습니다).

@Zylann @vnen 내가 쓰고 있는 TypeDB는 이론적으로 사람들이 모든 자산의 이름을 선택적으로 등록할 수 있도록 해야 합니다. 저는 현재 스크립트용으로만 사용하고 있으며 사용자 지정 유형 장면에도 사용할 계획이지만 리소스와 함께 작동하도록 수정할 수도 있습니다. 로직은 현재 스크립트와 장면에 대해 각각 HashMap을 가지고 있지만, 범주화된 HashMap에서 모든 종류의 자산을 처리하도록 로직을 일반화할 수 있습니다.

나는 시스템 전체에 대한 reduz의 우려를 존중할 수 있으며, 이는 확실히 엔진의 제품을 수정하는 플러그인에 대한 우려입니다. 그러나 vnen이 설명하는 것과 같이 특히 Editor의 기능에 관해서는 비교적 안전한 방법. 사람들이 편집기에 더 많은 기능을 부여하기 위해 플러그인을 추가하는 경우 일반적으로 열어보고 수정하는 것이 아닙니다. 그들은 그것을 있는 그대로 사용하거나 수정하는 경우 도구를 개선하기 위해 해당 변경 사항을 홍보하기 위한 것입니다. 당신은 결국 게임에 적응하지 않습니다. 그렇기 때문에 이런 플러그인을 위한 것이라면 (어떻게든) 새 프로젝트를 시작할 때 엔진에 이러한 기능을 쉽게 부여할 수 있는 수단이 있어야 한다고 생각합니다.

종속성 관리자 없이 작업을 더 쉽게 만들 수 있는 한 가지 가능한 방법은 플러그인 간에 종속성을 공유하지 않고 대신 프로젝트 내에서 중복되도록 하는 것입니다. 그런 식으로 버전 관리는 문제가 되지 않습니다. 개별 프로젝트를 잠재적으로 더 크게 만들 수 있지만 reduz가 말했듯이 게임 관련 콘텐츠이고 사람들이 어쨌든 모든 것을 만지작거릴 경우 종속성을 이동할 수 있습니다. 이 경우 우리가 필요로 하는 것은 플러그인이 자신이 가지고 있는 외부 플러그인 종속성을 선언하고 사용자에게 해당 종속 플러그인을 찾는 위치를 사용자 정의할 수 있는 옵션을 제공하는 방법입니다. 그렇게 하면 플러그인을 이동하고 다른 플러그인이 같은 위치에서 찾도록 선택하면 사용자 지정할 수 있습니다. 그러나 기본적으로 모든 것이 자체 종속성을 관리하여 즉시 작동합니다. 이 경우는 전체 plugins-as-sub-projects 제안(#19178)으로 처리하는 것이 더 쉬울 것입니다.

이것은 의존성 관리자를 필요로 하는 전역 의존성을 갖지 않도록 할 것입니다(reduz의 문제 번호 3). 또한 사용자가 애셋 라이브러리에서 애셋의 즐겨찾기 목록을 생성할 수 있는 기능과 결합하여 새 프로젝트가 생성될 때 프로젝트에 자동으로 설치하도록 선택할 수 있습니다. 수동으로 나가서 선호하는 모든 플러그인을 찾아 수동으로 다운로드하여 설치할 필요가 없습니다. 이것은 @karroffel 이 새로운 프로젝트를 생성할 때 동일한 자산으로 엔진을 쉽게 확장하는 것과 관련하여 처리하고자 하는 사용성 문제를 수정합니다.

복제할 필요가 없는 더 많은 편집기별 플러그인의 경우 사람들이 "즐겨찾는" 플러그인에 플래그를 지정하면 자동으로 심볼릭 링크를 만들어 일종의 사용자 폴더에 플러그인을 저장할 수 있습니다. 따라서 "모든 프로젝트에 이것을 원하고 공유 위치에 저장하고 심볼릭 링크를 만듭니다" 및 "모든 프로젝트에 이것을 원하고 복제합니다"에 대해 "에디터 즐겨찾기" 및 "프로젝트 즐겨찾기"가 각각 있을 수 있습니다.

이것을 TypeDB 항목과 결합하여 스크립트 이름 지정/사용자 정의 유형을 사용자 정의하면 완전히 다른 언어 간 스크립트 상속/다중 스크립트 문제를 제외하고 언급된 모든 문제를 적절하게 해결할 수 있다고 믿습니다.

따라서 "모든 프로젝트에 이것을 원하고 공유 위치에 저장하고 심볼릭 링크를 만듭니다" 및 "모든 프로젝트에 이것을 원하고 복제합니다"에 대해 "에디터 즐겨찾기" 및 "프로젝트 즐겨찾기"가 각각 있을 수 있습니다.

그러면 플러그인의 "번들"(사용자 생성 공식 승인 + 사용자 생성 로컬)이 더 편리할 수 있습니다. 따라서 "Editor Favorites" 및 "Project Favorites" 대신 "First Person Shooter", "Voxel Block Game" 또는 "My stuff"가 있습니다. 예를 들어 Unity 스타터 에셋과 거의 비슷하지만 텍스처 등으로 부풀릴 필요가 없습니다. 다양한 유형의 Godot 마스코트 얼굴이면 충분합니다.:D

이것은 또한 패키지 관리자로 작동하며, 여기서 패키지 관리자는 이제 인간 큐레이팅 플러그인 번들입니다.

@starry-abyss 사람들이 만드는 플러그인은 이미 다른 플러그인의 "번들"이 될 가능성이 있습니다(사용자 또는 플러그인 개발자는 자체적으로 이동하여 함께 병합할 수 있습니다). 여기의 목표는 사용자가 수동으로 작업을 수행할 필요가 없도록 편집기가 실제로 사용자를 대신하여 사용성 개선 작업을 수행하는 범주 간에 기능적 차이를 갖는 것입니다.

이 정도까지는 이미 "인간 큐레이팅 플러그인 번들" 기능이 있습니다. 문제는 지루한 작업을 자동화하는 동시에 모든 사용 사례에서 효율적인 생산성으로 맞춤형으로 유지하는 것입니다.

@Zylann

모든 자산을 이름으로 참조하면 충돌이 발생합니다. 프로그래머만 클래스에 고유한 이름을 입력하고 사용할 수 있기 때문에 스크립트에 더 적합합니다(또는 드물게 리소스).

네임스페이스 항목을 올바르게 지정하는 것이 그렇게 큰 문제입니까? 그러나 그것은 UID일 수 있으며, 경로에 의존하지 않는 한 나에게 별로 중요하지 않습니다. 리소스가 가져온 상대에 다시 매핑되기 때문에 경로조차 이름과 같습니다.

@QbieShay

내가 여전히 보는 유일한 문제는 애드온과 프로젝트 간의 비호환성입니다. 그 문제를 어떻게 해결하시겠습니까?

이것이 정말 문제라면 멀티스크립트가 가장 간단한 솔루션일 것입니다. 대부분 #8546의 논의로 인해 제거되었지만, 이것은 많은 노력 없이 해결할 수 있다고 생각합니다.

동일한 작업을 수행하는 여러 플러그인의 문제는 가상이라고 생각합니다. assetlib에 이미 스타 시스템이 있습니다. 이 시스템은 일반적으로 사용되며 선호되는 항목의 지표일 뿐입니다.

간과되지만 제 생각에는 사람들이 코어 엔진에 추가를 요구하는 이유 중 하나는 다음과 같습니다. 모든 플랫폼에 대해 이 것을 컴파일할 사람은 누구입니까?

물론 gdscript 플러그인의 경우 이것은 문제가 되지 않지만 Cpp 플러그인의 경우 이것은 큰 문제입니다.

우리가 이 문제를 해결하지 않으면 핵심 엔진 내부에 무엇이 들어갈 것인지에 대한 논의가 변형될 것입니다. 어떤 플러그인이 공식으로 표시될 것이며 플러그인을 공식으로 표시하면 스타 시스템이 망가질 것입니다. 플러그인에 별표를 표시하려면 공식 플러그인일 뿐입니다.

그래서 제 생각에는 이 문제를 먼저 해결해야 하는데 어떻게 해야 할지 모르겠습니다. 예를 들어 Linux를 통해 모든 플랫폼에 대해 컴파일할 수 있습니까? 그렇다면 Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ 와 같은 것을 사용하여 플러그인 제작자와 GDNative 사용자를 위해 이미 설정된 Linux 환경을 만들 수 있습니다.

예를 들어 Linux를 통해 모든 플랫폼에 대해 컴파일할 수 있습니까? 그렇다면 Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ 와 같은 것을 사용하여 플러그인 제작자와 GDNative 사용자를 위해 이미 설정된 Linux 환경을 만들 수 있습니다.

아니요(macOS 및 iOS 빌드는 실제로 macOS에서만 컴파일할 수 있음). 사람들이 GDNative 라이브러리를 자산 라이브러리에 업로드할 수 있도록 라이브 Linux OS를 부팅하도록 강요하는 것은 좋은 생각이 아니라고 생각합니다.

그러나 Travis CI 및 AppVeyor를 사용하여 모든 플랫폼에 대해 컴파일할 수 있으며 공용 GitHub 리포지토리에서 무료로 설정할 수 있습니다.

우리가 이 문제를 해결하지 않으면 핵심 엔진 내부에 무엇이 들어갈 것인지에 대한 논의가 변형될 것입니다. 어떤 플러그인이 공식으로 표시될 것이며 플러그인을 공식으로 표시하면 스타 시스템이 망가질 것입니다. 플러그인에 별표를 표시하려면 공식 플러그인일 뿐입니다.

음, 스타 시스템은 구현된 적이 없으므로 아무 것도 평가할 수 없습니다. 공식 플러그인의 경우 하나를 선택하여 공식으로 표시하는 것이 아니라 우리가 만들고 유지 관리하는 것입니다.

기본 사항을 위한 내장 노드는 편집기의 가장 좋은 점 중 하나입니다. 중요한 노드 또는 리소스가 제거될 경우 프로젝트 관리자는 공통 노드를 자동으로 다운로드하기 위한 템플릿이 필요합니다.

이 제안은 또한 엔진을 다른 "항상 온라인" 및 "정크 스토어" 엔진으로 전환할 위험이 있습니다. 완료되면 공식 지원(버그 수정) 및 가용성(버전 업데이트)을 얻기 위해 다른 많은 것들이 필요합니다.

그리고 상점은 오프라인 사용을 위한 공식 번들을 제공해야 합니다(편집기에서 오프라인 상점 지원 포함).

완료되면 공식 지원(버그 수정) 및 가용성(버전 업데이트)을 얻기 위해 다른 많은 작업이 필요합니다.

TBH, 엔진이나 상점에서 물건을 유지하는 것은 거의 동일합니다. 예를 들어 차량 노드는 거의 아무도 사용하지 않기 때문에 버그 보고서가 거의 없으며 보고된 버그조차도 수정되지 않았습니다. 나는 사람들이 엔진 소스를 엉망으로 만들지 않고도 문제를 해결하려고 하는 것이 더 쉽기 때문에 그런 종류의 노드를 아웃소싱하는 것이 훨씬 더 낫다는 것을 알게 되었고, 따라서 더 많은 잠재적 기여자가 있게 되었습니다.

엔진 노드에 문제가 있으면 사람들이 버그 보고서를 엽니다. 그러나 GDScript 코드가 포함된 플러그인인 경우 해당 사용자가 코드를 변경하고 테스트하기가 매우 쉽기 때문에 수정 사항을 커뮤니티에 다시 기여할 가능성이 높습니다. 나는 이것을 정말로 이득으로 본다. 그러나 이러한 외부 노드가 쉽게 통합될 수 있는 경우에만 가능하며 현재는 그렇지 않습니다. 여기에는 우수한 가시성과 통합 문서가 포함됩니다.

그리고 상점은 오프라인 사용을 위한 공식 번들을 제공해야 합니다(편집기에서 오프라인 상점 지원 포함).

예, 오프라인 패키지도 쉽게 설치할 수 있어야 합니다.

@reduz

패키지 관리자와 시스템 전체에 걸친 애드온 설치 아이디어가 마음에 들지 않습니다. 나는 그것이 끔찍한 생각이고 이것으로부터 전혀 의미 있는 것을 얻지 못한다고 생각합니다. Unity 개발자가 대규모 프로젝트에서 에셋 버전을 업데이트하고 모든 것이 중단되고 수정하는 데 며칠을 보내는 것이 얼마나 충격적인 일인지 보았습니다.

좋아, 하지만 왜 ? 실제적인 한계와 문제점은 무엇입니까? "나는 그것을 좋아하지 않는다"라고 말하는 것은 왜 그것이 좋은 생각이 아니라는 것을 사람들에게 확신시키지 못할 것입니다. 언급된 막연한 이유 외에 최소한 몇 가지 설명을 제공해야 합니다.

좋아, 하지만 왜? 실제적인 한계와 문제점은 무엇입니까? "나는 그것을 좋아하지 않는다"라고 말하는 것은 왜 그것이 좋은 생각이 아니라는 것을 사람들에게 확신시키지 못할 것입니다. 언급된 막연한 이유 외에 최소한 몇 가지 설명을 제공해야 합니다.

시스템에 전역 "애드온" 레지스트리가 있다고 가정:

• 온라인 애드온 시스템에서 애드온 v1.3을 다운로드합니다. 애드온이 ~/.godot 에 설치되었거나 설치되지 않은 항목
• 버전은 일종의 로컬 저장소(파일, sqlite 등)의 ~/my-project 에 있는 내 프로젝트와 연결됩니다.
• v1.4로 업그레이드합니다. 이제 내 애드온 관리자는 1.3이 어떤 프로젝트에서도 사용되지 않는다는 것을 알고 정리해야 합니다. 따라서 관리자는 종속성을 추적하고 어떤 프로젝트에 어떤 종속성이 있는지 추적하는 추가 기능이 있습니다. 또는 아무도 이 기능을 추가하지 않으므로 내 로컬 컴퓨터가 동일한 애드온의 여러 버전으로 오염됩니다.
• 프로젝트를 ~/big-project/game 로 옮기기로 결정했습니다. 이제 애드온 레지스트리에서 내 프로젝트에 대한 참조를 업데이트하는 방법이 필요합니다. 어떻게 해야 하나요? 애드온 매니저를 따로 실행해야 하나요? Manager register new_proj_location ?
• 이제 requirements.txt Python 스타일로 종속성을 로컬에 저장하기로 결정했습니다. 좋습니다. 문제가 해결되었습니다. 어떤 프로젝트가 어떤 글로벌 패키지에 의존하는지 알지 못하는 것을 제외하고는 시스템에서 Godot 프로젝트를 스캔하거나 버전이 쌓이지 않도록 각 프로젝트를 등록해야 합니다.
• 알겠습니다. 문제를 해결하기만 하면 됩니다. 때때로 죽은 패키지를 수동으로 정리합니다. 그래서 저는 v1.5를 사용하는 프로젝트를 위해 VehicleBodyAddon 작업을 하고 있습니다. 어, 가속 계산을 위해 F * M을 수행하지만 F * M * 5를 수행하고 싶습니다. 코드를 빠르게 수정하겠습니다...이런, 그 애드온을 실행하는 다른 모든 프로젝트가 있습니다.
• 다른 애드온에 의존하는 새 애드온을 만들어 보겠습니다. 흠 이제 내 새 사용자 지정 애드온이 기존 애드온에 종속된다는 것을 등록해야 합니다. 이제 관리자를 확장하여 원격 위치에서 애드온을 다운로드할 뿐만 아니라 로컬 경로나 git 리포지토리 등으로 작업해야 합니다.

"공급업체" 애드온 가정:

• 애드온 디렉토리에 애드온 다운로드
• 디렉토리의 오버라이드 애드온 업데이트

따라서 관리자는 종속성을 추적하고 어떤 프로젝트에 어떤 종속성이 있는지 추적하는 추가 기능이 있습니다. 또는 아무도 이 기능을 추가하지 않으므로 내 로컬 컴퓨터가 동일한 애드온의 여러 버전으로 오염됩니다.

이것은 정확히 다른 루비의 gem 명령이 하는 일이며, 그들에게 의존하는 다른 gem이 없는 이전 버전의 gem(루비의 애드온)을 정리하는 명령이 있기 때문에 아무도 거기에 불평하지 않습니다. 또한 업데이트하는 경우 새 버전이 어쨌든 대부분 호환될 것인데 이전 버전을 유지해야 하는 이유는 무엇입니까? 프로그램이 절대적으로 이전 버전에 의존하는 경우 사용자는 이전 버전을 다시 얻을 수 있지만 대부분은 그렇지 않을 것입니다.

프로젝트를 ~/big-project/game 로 옮기기로 결정했습니다. 이제 애드온 레지스트리에서 내 프로젝트에 대한 참조를 업데이트하는 방법이 필요합니다.

당신은하지 않습니다, 정말. 추가 기능 관리자가 프로젝트 관리자의 프로젝트 목록을 사용하고 존재하지 않는 경로를 무시할 수 있을 때 너무 깊이 생각하고 있는 것입니다. 물론 그것은 프로젝트와 요구 사항을 절대적으로 추적해야 하는 경우에만 가능하며, 말 그대로 다른 모든 추가 기능처럼 다운로드한 모든 추가 기능의 최신 버전을 유지할 수 있을 때 필요하지 않습니다.

이제 requirements.txt Python 스타일로 종속성을 로컬에 저장하기로 결정했습니다. 좋습니다. 문제가 해결되었습니다. 어떤 프로젝트가 어떤 글로벌 패키지에 의존하는지 알지 못하는 것을 제외하고는 시스템에서 Godot 프로젝트를 스캔하거나 버전이 쌓이지 않도록 각 프로젝트를 등록해야 합니다.

Python 스타일의 requirements.txt는 이러한 종류의 추가 기능 시스템에 대한 훌륭한 옵션입니다. 그렇게 하면 프로젝트에 이전 버전이 절대적으로 필요한 경우(하지만 어쨌든 최신 버전이 필요한 경우가 종종 있음) 이를 지정할 수 있으며 추가 기능 관리자가 이전 버전을 삭제하면 알 수 있습니다. 나중에 다시 다운로드하려면.

그래서 저는 v1.5를 사용하는 프로젝트를 위해 VehicleBodyAddon 작업을 하고 있습니다. 어, 가속 계산을 위해 F * M을 수행하지만 F * M * 5를 수행하고 싶습니다. 코드를 빠르게 수정하겠습니다...이런, 그 애드온을 실행하는 다른 모든 프로젝트가 있습니다.

또는 해당 프로젝트에 로컬 추가 기능의 복사본을 사용하시겠습니까? 실제로 하나의 프로젝트에만 적용되는 변경이 필요하고 프로젝트에 로컬 복사본을 만들고 싶지 않다면 확장하고 변경을 수행하는 .gd 파일을 만든 다음 다음을 사용하십시오. 애드온의 파일 대신 새 GD 파일이 필요합니다.

다른 애드온에 의존하는 새 애드온을 만들어 보겠습니다. 흠 이제 내 새 사용자 지정 애드온이 기존 애드온에 종속된다는 것을 등록해야 합니다. 이제 관리자를 확장하여 원격 위치에서 애드온을 다운로드할 뿐만 아니라 로컬 경로나 git 리포지토리 등으로 작업해야 합니다.

Git 하위 모듈. 또 다른 requirements.txt(파이썬이 하는 것과 같은). 또는 Add-on X가 필요하다고 사용자에게 알립니다. 생각보다 어렵지 않습니다. Godot의 사용자 대부분은 바보가 아닙니다. 그들은 "이 추가 기능에 필요한 것: 추가 기능 X 코어, 추가 기능 Y, 추가 기능 Z"가 무엇을 의미하는지 알고 있습니다.

@rminderhoud 필요에 따라 프로젝트의 애드온 복사본을 각 프로젝트에 저장하는 것이 좋습니다(따라서 필요한 버전만 있고 문제를 일으키지 않고 자유롭게 수정할 수 있음). 그러면 아마도 이전 제안이 핵심을 다룰 수 있을 것입니다 이 문제를 둘러싼 문제? 즉, 사용자가 새 프로젝트를 만들 때 자동으로 설치할 애드온을 지정할 수 있도록 EditorSettings 내 유틸리티를 만듭니다.

우리는 사람들이 특정 항목을 저장하기 위해 user:// 위치에 대한 하드 링크를 형성할 수 있도록 하는 유사한 유틸리티를 만들 수도 있습니다(특히 편집기 기능을 추가하는 애드온의 경우). 사용자가 무책임하게 이를 선택하고 프로젝트를 망친다면 그것은 자신의 결정일 것입니다. 프로젝트 생성 중에 모든 자산을 복사하는 기본 방법은 매우 유용할 수 있습니다.

새로운 플러그인 시스템 추가는 res://addons 와 지금처럼 호환되지 않아야 합니다. 그리고 그 이유는 다음과 같습니다.

실제 시스템은 훌륭합니다 ...

다시 한번 말한다:

실제 시스템은 훌륭합니다 ...

이전에는 그 점에 대해 불평하지 않았습니다.

이 토론에 늦었습니다. 제안에 대한 몇 가지 생각은 다음과 같습니다.

• 저는 개인적으로 아직 '자산'을 많이 사용하지 않으며 애드온 폴더를 있는 그대로 사용하는 것이 쉽다고 생각합니다.
• 교차 언어 스크립트 상속이 수행할 작업과 해결할 문제(C# 개발자가 GDScript 스크립트에서 확장하여 C#를 사용하여 사용자 지정 기능을 추가할 수 있음)(사용할 의사가 없음)를 이해하지만 확실하지 않습니다. 노드당 여러 스크립트가 수행하는 작업. 아, 그래서 GDScript 스크립트에서 확장된 C# 스크립트 대신에 그것을 호출할 수 있을까요? 어떤 스크립트가 주요 스크립트가 될까요? C# 코드는 GDScript 스크립트가 수행하는 작업을 어떻게 변경합니까?
• 스크립트가 클래스 이름/이름 공간(TypeDB)으로 참조되도록 허용하는 것이 유용할 수 있습니다. res://paths 는 괜찮지만 애드온의 무언가를 상속하면 경로 이름이 매우 길어지는 것이 사실입니다. 주요 문제는 아니지만 있으면 좋은 것 - 언어 간 상속을 위해서는 아마도 필수(또는 선호)일 것입니다.

내가 제안하고 싶은 자산 관리를 위한 더 간단한 디자인은

• 종속성.json을 갖는 것(또는 프로젝트 설정에 데이터를 저장하는 것)은 내가 다운로드한 자산의 버전과 업데이트된 버전이 있는지 알 수 있도록 하는 데 유용합니다. 필요한 정보라고 생각합니다.
• 아니요, 자산이 종속성을 정의할 수 없도록 합니다. 나는 Godot 자산이 npm 모듈처럼 서로에 대한 의존도가 높을 것이라고 생각하지 않습니다. 실제로 다른 자산에 의존하는 경우 자산 개발자가 문서에 명시하도록 하고 사용자가 수동으로 설치하도록 합니다. 이것은 일을 단순화할 것이고 우리는 코드 팽창/유지해야 할 더 많은 코드인 또 다른 종속성 검증을 생성할 필요가 없을 것입니다.
• 아니요, 자산을 '글로벌' 위치에 저장하지 마십시오. 프로젝트 addons 폴더에 보관하는 것은 이미 좋습니다. 이를 통해 프로젝트와 함께 소스 제어로 커밋할 수 있고 쉽게 관리할 수 있습니다. npm node_modules조차도 프로젝트 내부에 프로젝트의 모듈을 저장합니다.
• 이제 자산 브라우저를 개선하여 설치된 자산 중 업데이트된 자산을 나열하고 원하는 경우 업데이트할 수 있도록 합니다.
• 이제 편집기 개선 사항인 애드온에 대해 '글로벌' 애드온을 사용할 수 있다는 것이 합리적입니다. 따라서 일반 애드온은 여전히 ​​프로젝트 애드온 폴더로 이동하지만 편집기 관련 애드온의 경우 전역적으로 설치할 수 있는 옵션이 있습니다. 이것은 또한 해당 코드를 프로젝트의 addons 폴더 외부로 이동하여 릴리스 패키지로 이동하지 않습니다. (개발 도구용 npm install -g와 유사)

따라서 업데이트된 자산을 추적하고 전 세계적으로 편집기 애드온을 설치할 수 있는 몇 가지 개선 사항이 있습니다.

종속성을 처리하지 않는다고 가정하면 사용자의 검색 가능성/사용 용이성 문제가 있을 수 있다고 생각합니다. 새 사용자가 종속성이 있는 플러그인 또는 "자산 패키지"를 사용하려고 한다고 가정해 보겠습니다. 패키지는 자산 라이브러리에 표시되어 다운로드한 다음 "내부 스크립트를 로드하지 못했습니다" 또는 이와 유사한 것으로 인해 작동하지 않습니다. 그것은 비밀스럽습니다.

• 적어도 하나의 종속성을 갖는 모든 개발자는 종속성을 설치해야 하는 사용자를 보여주기 위해 상용구 코드를 설정해야 합니다(패키지가 해당 플러그인의 데모일지라도!)
• 아니면 assetlib가 최소한 그것을 나타내도록 합니까?

또한 자산을 쉽게 업데이트할 수 있도록 +1을 제공하므로 라이브러리에서 자산을 다시 탐색할 필요가 없습니다.

사실이지만 사용자가 작동하지 않는 것을 확인하면 즉시 문서를 찾아보고 다른 자산을 설치해야 하는지 알 수 있습니다.

이 시점에서 그것은 단지 상상의 문제입니다. 그리고 내가 본 프로젝트 관리자의 사고 방식으로 볼 때 실제로 문제가 있음을 알 때까지 구현하지 않는 것이 합리적입니다. 즉. 다른 자산에 의존하는 많은 자산이 있으며 사용자는 이에 대해 많은 어려움을 겪고 있습니다.

하지만 잘 설계된 솔루션으로서 다른 자산을 기반으로/에 의존하는 자산 생태계를 보유하는 것이 좋고 이를 장려할 수 있다는 데 동의합니다.

업데이트로 인한 자산 간의 상위 중단 종속성을 추가하면(타사 자산 종속 엔진에서 일반적임) 동일한 플러그인의 여러 버전이 라이브러리에 유지되어야 합니다.

@eon-s 그래서, @bojidar-bg의 제안 과 같은 것입니까?

여기서 논의되는 더 중요한 문제는 핵심 엔진에 포함하는 것과 확장 또는 공식 확장으로 갖는 것의 주제에 관한 것입니다.

저는 개인적으로 엔진을 사용자 정의하고 실제로 사용하지 않는 모든 것을 제거할 수 있다는 아이디어를 정말 좋아합니다. [예를 들어 모든 3D 항목을 제거하는 방법을 알려주실 수 있습니까? 사용하지 않는 모듈의 컴파일을 비활성화할 수 있습니까? 어떻게?]

문제는 누군가가 새로운 노드 유형을 제안할 때입니다. 언급된 Spring Arm 또는 새 클래스 예. 더 나은 RNG 클래스 또는 일부 기존 코어 노드가 제거되어야 하는 경우 차량 컨트롤러 ... C++ 코드입니다. 코어에 포함되지 않은 경우 확장으로 어떻게 추가됩니까? GDNative 자산? 그것은 관리/구축할 많은 dll과 공유 라이브러리가 될 것입니다.

저만의 Godot 빌드를 빌드하는 사람으로서 저는 실제로 Godot 빌드 폴더에 설치하는 방법을 선호합니다. 예를 들어 그것들이 모듈이라면 나는 그것을 내 모듈 폴더에 git clone하거나 어떻게든 그것을 자동화하는 도구가 있을 것입니다. 공식 모듈, 공식 확장 모듈 및 사용자가 제출한 모듈 목록에서 사용하려는 모든 모듈을 선택할 수 있습니다. 그런 다음 다운로드(git clone)하면 사용자 정의 Godot를 빌드할 수 있습니다. 또한 어떤 것이 업데이트되었는지 확인하고 업데이트하고 나중에 새 것을 설치할 수 있습니다. (C++ 코드를 참조하는 것입니다.)

따라서 엔진에서 기능을 제거하기 전에 먼저 더 우수하고 유연한 자산 라이브러리(자산 설치, 종속성, 버전 관리 등)와 더 쉬운 플러그인 통합/확장(편집기 도구, 스크립팅 가능한 사용자 정의 노드 등)이 필요하다고 생각합니다. .

여기에서 @chanon 에 응답합니다.

아니요, 자산이 종속성을 정의할 수 없도록 합니다. 나는 Godot 자산이 npm 모듈처럼 서로에 대한 의존도가 높을 것이라고 생각하지 않습니다.

하지만 왜? 그 시점에서, 아무 것도 해치지 않을 것이기 때문에 어째든 애셋이 이 종속성 파일을 갖도록 하지 않는 이유는 무엇입니까? 많은 npm 모듈에 종속성이 있는 이유는 모든 사람이 번거로움을 덜어주고 사용자가 이미 설치했을 수도 있는 다른 모듈의 코드를 재사용하기 때문입니다. Ruby gem, Python via pip 도 마찬가지이며 Linux 배포판의 패키지 관리자도 허용합니다. 자산이 자주 사용되지 않을 수 있다는 이유로 자산에 대한 종속성을 허용해서는 안 되는 이유를 모르겠습니다.

사실이지만 사용자가 작동하지 않는 것을 확인하면 즉시 문서를 찾아보고 다른 자산을 설치해야 하는지 알 수 있습니다.

나는 이 감정에 동의하지 않는다. 많은 사람들이 문서를 먼저 찾아보겠지만, 자산 라이브러리에서 매번 필요한 모든 자산을 검색해야 하는 데 짜증이 날 것이라고 확신합니다. 그러나 사전에 문제를 Google에 표시하지 않고 자산 작성자에게 자산이 작동하지 않는다고 불평하는 사람들이 항상 있다는 점도 언급할 가치가 있다고 생각합니다.

GDScript에서 수행할 수 있기 때문에 기능을 제거한다는 아이디어에도 동의하지 않습니다. 간단히 말해서, 많은 사용자가 필요한 도구/기능 등을 다운로드하거나 구현하도록 하려는 경우 Godot의 " 필요한 모든 노드를 위한 노드 " 목표와 상반됩니다.

사실, "직접 하기 어렵다"는 것이 완전히 임의적이기 때문에, 엄청난 양의 노드가 @reduz 의 엔진에 포함되기 위한 두 번째 요구 사항에 해당합니다. 누군가에게는 단순할 수 있는 것이 누군가에게는 어렵습니다.

확장을 위한 공식 리포지토리를 갖는 것이 "모든 요구 사항을 위한 노드"에 어긋난다고 생각하지 않습니다. 실행 가능한 다운로드에 통합되어 있지 않다고 해서 제공되지 않는 것은 아닙니다. 또한 기본 요구 사항이 충족되고 이를 확장할 수 있는 권한이 게임별 요구 사항에 대해 사용할 수 있다는 아이디어가 있습니다.

FPS 캐릭터 컨트롤러가 기본 제공되는 것은 좋지만 FPS 게임을 하지 않는 모든 사람에게는 쓸모가 없습니다. 그리고 그런 것들을 추가함으로써 당신은 본질적으로 그들이 필요하지 않은 많은 기능을 포함하는 모든 게임을 만들고 최종 바이너리를 증가시킵니다(모바일 및 웹 타겟에서 많이 중요합니다). 최종 내보내기에서 사용하지 않는 것을 제거하는 방법이 있어야 하며 필요에 따라 외부에서 제공하는 것이 한 가지 방법(적어도 부분적으로)입니다.

난이도가 주관적이라는 점에 동의합니다. 스프링 암 노드를 만드는 것은 구현에 대한 기본 사항을 이미 알고 있는 경우 에만 쉽습니다. 그렇지 않으면 연구에 상당한 시간을 할애하게 되어 완전한 기능을 갖춘 엔진을 사용하려는 목적을 달성하지 못합니다. 더 나은 메트릭(여전히 다소 주관적이지만)은 기능이 "얼마나 낮은 수준인지" 입니다. 물리 또는 비주얼 서버에 기능을 추가해야 하는 경우 엔진에서 제공해야 합니다. 기존 노드의 확장일 뿐이라면 아웃소싱할 수 있습니다.

나는 여전히 다운로드를 위한 공식 노드를 제공하고 코어를 다듬는 것이 더 유익하다고 믿습니다. 이를 통해 다음을 수행할 수 있습니다.

• 편집기 및 내보내기를 위한 작은 실행 파일이 있습니다.
• 더 많은 게임별 도우미와 함께 공식적으로 더 많은 기능을 제공합니다.
• 새 엔진 버전을 출시하지 않고 확장 프로그램의 버그를 업데이트하고 수정합니다. 이는 아웃소싱된 노드가 훨씬 더 빠른 릴리스 주기를 갖고 버그가 수정되는 즉시 패치를 릴리스할 수 있음을 의미합니다.

그러나 이를 위해서는 여전히 애드온을 사용자 영역 스크립트보다 더 높은 수준의 시민으로 만들어야 합니다. 확장 노드를 사용하는 것은 핵심 노드를 사용하는 것처럼 느껴야 하며 그렇지 않다는 점을 분명히 해야 합니다.

흥미로운 토론. 좋은 제안도 많다.

먼저 최종 바이너리의 간결함을 높이 평가하고 그 목표를 염두에 두고 만들어진 엔진이 있다는 사실에 감사한다는 것을 먼저 말해야 합니다. 나는 여기서 중심적인 비전이 팽만감을 적극적으로 퇴치하는 것이라는 점을 기쁘게 생각합니다. 적어도 저에게는 작업에 필요한 도구만 손이 닿는 곳에 있는 것을 선호합니다.

이 흥미로운 아이디어 중 일부에 대해 고개를 끄덕이고 싶었습니다.

특히 점점 더 많은 기능이 공식 모듈이나 플러그인과 같은 형태를 취하는 것으로 내보내집니다.

그것으로부터 나는 이것이 핵심과 같으며 필수 모듈이 기본적으로 설치된 모듈 라이브러리와 같다고 상상합니다. 아마도 많은 사람들이 편집기 설정을 통해 선택 해제될 수 있습니다. (나는 Zylann이 2D 게임에서 3D를 제외한다고 언급했다고 생각합니다.) 기본값을 넘어서 다른 모듈을 쉽게 찾고 포함할 수 있습니다.

구현의 어려움에 대해 궁금하지만 프로젝트에서 활발하게 활동하는 모듈을 제거하려는 경우 어떤 일이 발생하는지 고려해야 하기 때문입니다. 비활성화되기 전에 해당 장면/스크립트에서 제거하도록 사용자에게 경고해야 할 수도 있습니다. 아니면 프로젝트에 삭제 표시 항목으로 남아 모듈이 다시 추가될 때 되살릴 수 있습니까?

구현하는 것은 작은 일이 아니지만, 가능한 한 제공되는 기능을 선택하고 선택할 수 있어 게임 내보내기가 필요한 것만 포함하는 것을 좋아합니다. 그것에 대한 더 많은 통제는 나에게 가치있게 들립니다.

빌트인과 스크립트 사이에 특별한 분류가 있는 모듈을 갖는 것에 대한 Vnen의 다른 생각도 좋은 것이었습니다. 기존 디자인의 좋은 점을 방해하지 않으면서 일부 다른 유형의 파티셔닝 및 편집기 동작 및 옵션을 허용합니다.

애드온을 Godot 자체처럼 보이게 만드는 아이디어에 대해 찬성하는 사람도 있고 반대하는 사람도 있지만 상황에 따라 달라질 수 있습니다. 컨셉을 조금 나눠서 하는 것도 상상할 수 있었다. 둘 다 제공합니다.

또한 최종 빌드에서 편집기 도구를 유지하는 것과 관련하여 무엇을 할 수 있는지 알고 싶습니다. 도구를 위한 버그와 동작이 게임 자체에 침투할 수 있기 때문에 이러한 것들을 분리하기 위해 많은 노력을 기울였습니다. 저장될 데이터를 수정하는 작업을 하는 경우 때때로 파괴적입니다.

동시에 도구 스크립트를 사용하여 편집기 내부의 기능을 쉽게 수정하는 것이 매우 환상적이므로 더 많은 관심을 기울이는 것도 환상적입니다.

아무튼 모두들 힘내세요.

또 다른 미친 아이디어:

어떻게든 GDNative C++를 모듈로 자동 변환하는 것이 가능할까요? (이상적으로는 GDNative에 의해 생성된 간접 계층 제거)? 그런 다음 "하나의 정적 실행 파일에 있는 모든 것" 접근 방식과 "컴파일러를 설치하지 않고 기능 제거" 접근 방식의 옹호자들 모두를 기쁘게 할 수 있습니다.

노드 제거를 반대하는 분들에게 제거된 노드를 GDScript에서 공식 플러그인으로 구현하면 현재보다 낫지 않을까요? 그러면 초보자는 실제로 스크립트 내부에서 작동 방식을 확인하기 위해 정점을 찍을 수 있기 때문입니다.

GDScript가 그다지 빠르지 않기 때문에 성능이 저하될까 두렵습니다.

2018년 6월 22일 금요일 오후 11시 10분, Alan North 알림 @github.com
썼다:

노드 제거에 반대하는 사람들의 경우 제거되는 노드가
GDScript에서 공식 플러그인으로 구현하는 것보다 낫지 않을까요?
우리는 현재 무엇을 가지고 있습니까? 초보자는 실제로 내부에서 정점을 찍을 수 있기 때문에
스크립트가 어떻게 작동하는지 확인합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
.

@AlansCodeLog 절대적 으로 제거하고 외부 확장으로 만들어야 하는 경우 사용자가 엔진(원본 C++ 파일인 경우)을 다시 컴파일하거나 Mono( GDNative로 변환된 경우). 그러나 내 원래 응답 의 일부(공식 확장 저장소에 대한 섹션 참조)에는 사용자가 확장 저장소가 있다는 것을 기억하지 않으면 확장으로 가져오면 이 이상한 종류의 시장(더 나은 단어가 없음)이 생성될 것이라는 우려가 포함되었습니다. 공식 버전이나 최신 버전에 관계없이 필요한 내용이 포함되어 있습니다. 새로운 애드온은 "기능 X가 있는 노드 X", "기능 Y가 있는 노드 X" 등(확장으로 만들어진 노드를 나타내는 "노드 X")이 있는 자산 라이브러리에 제공되어 엉망이 됩니다. 모든 애드온이 차량에 도움이 된다고 주장하지만 더 많은 공식 노드가 얻을 수 있는 수준이나 조사가 없습니다.

@LikeLakers2

하지만 왜? 그 시점에서, 아무 것도 해치지 않을 것이기 때문에 어째든 애셋이 이 종속성 파일을 갖도록 하지 않는 이유는 무엇입니까?

나는 그것에 반대하지 않습니다. 그러나 reduz는 그것을 좋아하지 않는 것 같아서 먼저 제안한 것처럼 간단한 개선을 제안합니다. 어떻게 진행되는지 확인한 다음 나중에 종속성이 있는 자산에 대한 기능을 추가할 수 있습니다. 한 번에 한 단계만 제안합니다.

하지만 프로젝트 애드온을 프로젝트 폴더 외부에 설치하면 관리가 더 어려워지기 때문에 반대합니다. '글로벌' 편집기 애드온만 프로젝트 폴더 외부에 있어야 합니다.

좀 더 생각해 본 결과, 실제로 핵심 기능이 제거되고 사람들이 모든 프로젝트에서 이러한 핵심 기능[이후 확장이 될]에 액세스하려는 경우 해당 확장을 다음 위치에 설치할 수 있는 것이 합리적입니다. 그들을 위한 버전 관리가 있는 전역 위치. 그러나 확장 프로그램을 프로젝트 폴더에 직접 다운로드하여 설치하는 옵션도 이 경우에 유지되어야 합니다. (다시 말하지만 -g를 사용하여 로컬 또는 전역적으로 설치하는 npm 옵션과 같습니다)

eon-s가 위에서 말했듯이 코어 엔진에서 제거하고 자산으로 전환하려면 더 나은 자산 관리 시스템을 갖는 것이 합리적입니다. 그렇지 않으면 사용자가 제거된 기능을 쉽게 찾을 수 없기 때문에 엔진에서 기능이 손실되는 것과 같습니다.

나는 그 이상적인 시나리오를 생각하고 있었다.

• 엔진을 컴파일하지 않는 신규 사용자 및 사용자: 엔진 다운로드 페이지에서 핵심 엔진을 다운로드하고 엔진 다운로드에 포함할 공식 또는 권장 확장을 선택할 수 있는 옵션이 있습니다. ( 확장을 전역 폴더에 저장할 수 없는 경우에는 불가능합니다. 사용자는 대신 프로젝트를 생성한 후 확장을 찾아야 하므로 검색 가능성이 떨어집니다. ... 이상적인 [불가능한] 세상에서 웹사이트는 즉석에서 선택한 확장/구성 요소에서 사용자 지정 C++ 빌드를 빌드합니다.)
• 엔진을 컴파일하는 사람: 확장 C++ 코드 다운로드 및 버전을 관리하고 빌드 폴더의 올바른 위치에 저장하여 엔진 빌드에 포함되도록 하는 도구입니다.

엔진을 컴파일하는 사람으로서 나는 내 확장을 GDNative(또는 느린 GDScript)가 아닌 모듈로 사용하고 싶습니다. 내 빌드에 포함하거나 포함하지 않을 특정 노드 유형을 선택하거나 모든 3D 항목을 삭제할 수 있는 모듈성 수준을 상상하고 있습니다.

C++ 확장이 모두 GDNative가 된다면 확장 작성자가 모든 플랫폼을 위해 빌드해야 하는 부담을 갖게 됩니다. 게시하는 데 필요한 모든 작업을 수행하고 기능을 여러 개의 작은 모듈로 분리하는 것도 권장하지 않습니다. 또한 출력 프로젝트에 너무 많은 dll/공유 라이브러리 파일이 추가된다는 사실도 마음에 들지 않습니다.

반면에 엔진을 컴파일하지 않는 사람들을 위해 GDNative는 C++ 확장을 추가하기 위한 유일한 솔루션입니다.

따라서 starry-abyss가 제안한 것처럼 GDNative가 일반 모듈에 자동으로 적용될 수 있다면 좋을 것입니다.

좋아, 그래서 나는 입장을 바꿨다. 업계의 강국과 같은 수준의 기능을 가진 팽창 없는 엔진이라는 아이디어가 마음에 든다.

모든 추가 노드를 분리하면 특히 원하는 것과 원하지 않는 것을 선택할 수 있는 많은 이점이 있습니다.

여기에 접근하는 방법에 대한 몇 가지 제안이 있습니다.

1. 먼저 자산 라이브러리에 자산을 부품에 설치할 수 있는 기능을 추가할 수 있습니다. git에서는 태그 또는 분기로 분리할 수 있습니다.
   따라서 이제 2D 기능 노드만 원하면 해당 항목만 다운로드할 수 있지만 업데이트를 확인하기 위해 볼 수 있는 곳은 한 곳뿐입니다.
2. 두 번째로 자산 업데이트에 레이블을 추가하는 기능을 추가할 수 있습니다. 예를 들어 일부는 핵심 업데이트가 될 수 있고 일부는 하위 호환성이 깨질 수 있습니다.
   그러면 Asset Manager에서 자동으로 애드온을 업데이트하고 문제에 대한 업데이트를 요청할 수 있습니다. 핵심 업데이트가 기다리고 있거나 다음 업데이트가 이전 버전과의 호환성이 깨질 것이라고 알려줄 것입니다. 업데이트하시겠습니까?
3. 세 번째로 여러 버전의 자산을 허용하고 버전이 너무 오래되면 애드온/자산의 개발자는 이를 오래된 것으로 표시할 수 있으며 이는 Godot를 열 때 반영되며 이전 버전을 제거할지 여부를 묻습니다. .
4. 그리고 마지막으로 애드온이 다른 애드온을 요청하는 기능은 종속성과 비슷하지만 이 애드온을 실행하려면 이 애드온이 필요하고 설치하지 않은 경우에는 이 애드온이 필요하다고 알려줍니다.
   그리고 애드온 자체가 애드온을 더 이상 찾을 수 없다는 것을 알게 되면 다시 추가하거나 오류 메시지를 표시하도록 요청하십시오.

이 방법을 사용하면 종속성 관리자가 필요하지 않지만 개발자가 작업을 담당하게 됩니다. 애드온이 오래되고 오래된 자산/애드온을 사용하는 경우 두 개발자 모두 이야기할 수 있고 개발자는 무엇을 할지 결정할 수 있습니다.
그는 자신의 애드온을 빨리 이식할 수도 있습니다. 필요하거나 경우에 따라 다른 애드온에서 오래된 태그를 제거할 수도 있습니다.

그리고 @chanon 이 말했듯이 Unity가 한 것처럼 에셋을 전역으로 다운로드한 다음 프로젝트로 가져올 수 있어야 합니다.
그리고 애드온 프로세스 설치에 유연성이 많이 있는 현재 구현보다 더 나은 자산 관리자가 허용되어야 합니다.
애드온을 GDNative 및 모듈로 추가할 수 있는 기능을 갖는 것이 좋습니다. 이 기능은 애드온 개발자에게 약간의 부담을 줄 것이지만 여기서 근본적으로 변경되지 않는 한 이것이 유일하게 수용 가능한 솔루션이라고 생각합니다.
그러나 애드온 생성을 쉽게 하기 위해 GDNative에 몇 가지 기능을 추가할 수 있습니다. 한 번에 모든 플랫폼을 구축할 수 있다면 훨씬 좋을 것입니다.

플러그인 업데이트로 인한 종속성 및 자산 중단 문제에 대해,
왜 안되지 (그리고 이미 이것을 제안하는 누군가를 놓친 경우 사과합니다)

1. 서버가 모든 버전을 업로드하도록 유지

2. 플러그인이 특정 플러그인의 특정 버전을 지정하도록 허용

3. 플러그인에 대해 정상적인 버전 관리 시스템을 사용해 보십시오(Godot은
   내가 좋아하는 Major.Feature.BugFix 버전 번호 지정)

4. 그리고 가장 중요한 것은 플러그인을 자동 업데이트하지 않습니까? (또는 최소한 허용
   사용자가 어떤 유형의 업데이트(예: 버그 수정 및
   기능 업데이트는 있지만 주요 업데이트는 없음).

@Two-Tone 그렇다면 왜 모든 것을 무료로 만들 수 있습니까?

우리는 엔진과 전체 시스템이 불필요한 버전이 날아다니지 않도록 최대한 부풀리지 않도록 하기 위해 이 토론을 했습니다.

사용자가 업데이트를 결정하도록 허용하는 것은 옳지만 버그 수정은 기본적으로 자동이어야 합니다. 수백 개의 애드온이 있는 경우 버그 수정 업데이트를 하나씩 확인하지 않을 것이기 때문입니다.
나머지는 필요한 경우 비활성화하도록 설정할 수 있는 사용자에게 달려 있습니다.

그리고 상점은 오프라인 사용을 위한 공식 번들을 제공해야 합니다(편집기에서 오프라인 상점 지원 포함).

가장 중요한 데모와 매우 쉽게 검색할 수 있어야 하는 가장 중요한 추가 기능이 포함된 몇 10MB의 오프라인 팩 하나를 제안합니다. 이전 Godot 버전과 같이 공식 다운로드 페이지의 더 작은 글꼴 링크가 좋을 것입니다.

아마도 그렇습니다. 그러나 데스크탑이 256BG SSD + 1TB HDD 미만을 사용하지 않는 것 같고 심지어 전화도 최소 16GB에서 시작하는 공간이 있는 세상에서 이 모두가 증가할 가능성이 더 높으면 그렇게 될까요? 나쁜?

휴대용 및 저렴한 랩톱 부문에서 eMMC는 잘 작동하며 32GB 크기(10GB 미만의 여유 공간 포함)는 그리 드문 일이 아닙니다.

그건 그렇고, 그 클래스의 랩톱에서는 현재 Android 내보내기 시스템을 사용할 수 있지만 계획된 것(https://github.com/godotengine/godot/issues/18865)은 사용할 수 없다고 생각합니다. 나는 새로운 시스템의 장점을 이해하고 있으며 균형을 유지한다면 나는 아마도 그것에 투표했을 것입니다(내가 문제를 보았을 때 이미 경연 대회가 없었음). 그러나 우리는 변경으로 인해 중요한 사용 사례를 잃는다는 것을 알고 있어야 합니다.

@swarnimarun 오해가 있을 수 있습니다. 내가 그 댓글에서 "시스템"이라고 말할 때, 나는 엔진이 아니라 플러그인을 제공하는 서버를 의미했습니다. 그것이 당신을 걸었다면 죄송합니다.

그렇지 않은 경우 플러그인에 대한 종속성 시스템으로 사람들의 문제를 해결하려는 시도가 엔진 팽창을 유지하려는 것과 반대되는 방법을 알 수 없습니다. 누군가가 필요할 때를 대비하여 서버에 보관하는 플러그인은 팽창이나 유지 관리 오버헤드에 기여하지 않으며 대부분은 너무 작아서 저장 비용이 그렇게 높지 않아야 합니다.

@Two-Tone 그래, 나는 당신이 컴퓨터에 의미하는 줄 알았는데. 하지만 서버에서는 괜찮고 Github에서는 변경 후에도 저장할 수 있는 해시를 허용하므로 이미 수행할 수 있습니다. 따라서 현재 시스템에서는 repo를 업데이트한 후에도 자산 페이지에서 해시를 업데이트해야 합니다.

github뿐만 아니라 gitlab 및 다른 사람들도 허용합니다. 다른 사람이 있는 경우. Git은 커밋 ID로 저장되는 해시를 지원하므로 작업이 완료되는 방식으로 수행됩니다.

내 몇 센트, 이것의 대부분은 이전에 말한 것이 확실하므로 내가 새로운 것을 가져오고 있는지 의심스럽습니다.

나는 플러그인으로 일을 하기 위해 플러그인으로 일을 하는 것을 믿지 않습니다. 크기 문제는 이해하지만 우리는 더 이상 80년대에 살고 있지 않습니다. 우리는 엔진이 50Mb 또는 55Mb인 것에 대해 이야기하고 있습니다. 엔진이 50Mb 또는 500Mb가 아니라 플러그인으로 이동할 기능의 추가 크기 증가는 심각한 게임의 자산 크기에 비해 무시할 수 있습니다. 우리가 지불하는 가격이 더 번거로운 통합이라면 그만한 가치가 없습니다.

플러그인이 더 의미가 있는 곳이 많이 있으며 GDNative와 같은 아키텍처가 성숙함에 따라 "이것이 플러그인이 되는 것이 더 낫습니까?"라는 질문을 확실히 해야 하며 많은 경우에 나는 대답이 예라고 주장할 것입니다. 플러그인에 대해 내가 좋아하는 한 가지는 개발자로서 여러 측면에서 더 많은 자유를 허용한다는 것입니다. 그러나 한계도 있습니다.

내 VR 경험은 이들 중 몇 가지를 벗어났습니다. 시간이 더 오래 걸리는 이유가 있습니다. 모바일에서 시작하고 실행하고 싶습니다. 특히 모바일에서 다양한 방식으로 디스플레이를 설정해야 하는 요구 때문에 코어 작동 방식을 변경해야 하고 플러그인에서 캡처하기가 어렵다는 것이 증명되었습니다.
OpenVR과 OpenHMD는 지금까지 쉬운 것이었습니다. Oculus 무시당하는 해결 방법을 거쳤지만 만족합니다.
ARKit은 코어에 있어야 하며 모듈로 해결할 수 없으며 최소한 현재 구조에서는 불가능합니다(Apple은 iOS에서 동적 라이브러리를 허용하지 않으므로 그것도 있습니다).
GearVR과 Daydream은 핵심에 있어야 합니다. GearVR은 독점 라이브러리를 사용하기 때문에 불가능합니다.
Hololens/Microsoft MR 이 플랫폼을 선택할 수 있는지 확인하는 과정을 진행 중입니다. 앱은 둘 사이에서 실행되어야 하고 홀로그램 전용 앱으로 Hololens에 설치되기 때문에 Microsoft는 이를 그렇게 봅니다.

이제 AR과 VR은 소수의 사람들이 사용하는 틈새 기능이므로 가능한 한 핵심에서 벗어나야 하는 유형이며 저는 그 관점에 매우 동의합니다. 그러나 나는 다른 것들에 대해서도 같은 말을 할 수 없다.

어디선가 언급된 차체를 본 적이 있는데, 진지하게? 플러그인에 넣는 킬로바이트의 코드를 저장합니까? 물리학은 핵심 IMHO에서 완전히 지원되어야 한다고 생각하는 유형의 것입니다. 오히려 코어 내부에 완전히 통합된 물리학 개체의 전체 제품군을 보고 플러그인에서 해당 개체를 찾아야 합니다. 우리가 GDNative에서 작성한 ARVRInterface와 유사한 인터페이스 접근 방식은 아마도 견고한 통합을 만들 수 있지만 여전히 우리가 삶을 불필요하게 어렵게 만들고 있다고 느낍니다.

지형 편집기 구성 요소와 대조적으로 이제 플러그인 기반에 이상적으로 적합한 것으로 보이는 것이 있습니다. 만들고자 하는 게임 유형에 따라 지형을 처리하는 다양한 방법이 있으므로 다른 애드온 중에서 선택하는 것이 합리적이며 코어 개발과 독립적으로 이러한 애드온을 개발할 수 있다는 것이 더 큰 이유입니다.

플러그인이 의미가 있는 긴 이야기를 짧게 하자면, 플러그인을 지원하지만 너무 지나치면 안 됩니다.

플러그인으로 전환할 가치가 있는 노드는 Control 노드(복합 노드)에서 만든 Control 노드로, 다른 노드를 구성하기 위한 간단한 노드만 남깁니다.

Vehicle과 같은 복잡한 논리를 가진 노드 또는 Position과 같이 단순하지만 유용한 노드가 핵심입니다.

IMO, 이들 중 어느 것도 엔진에서 제거해서는 안됩니다. 제어 노드, 물리 노드(예: 차량) 및 현재 존재하지 않는 지형 지원:

나는 Godot가 상당히 독립적이고 통합된 애플리케이션이기 때문에 사용합니다.
미래에 Godot를 다운로드해야 하고 차량, 제어 노드, 지형 지원, 셰이더 편집기, 괜찮은 Navmesh 플러그인 및 계속해서 - 현재 플러그인과 AssetLib 시스템을 사용하여 - 아니요.

이대로 가면 플러그인 인프라와 AssetLib 모두 사용성 점검이 필요합니다.

그건 그렇고, 저는 UE4의 큰 설치 크기가 비히클, 지형 또는 UI에 대한 내장 지원이 제공 되지 않는 것보다 훨씬 덜 귀찮습니다.

이 중 얼마나 많은 내용이 이미 언급되었는지 확실하지 않습니다. 이와 같은 큰 스레드는 따라가기가 어려울 수 있지만 어쨌든:

나는 우리가 최고의 경험 에 집중해야 한다고 생각합니다. "공식적으로 승인된" 플러그인의 경우에도 자산 라이브러리로 이동해야 하는 것은 다소 다루기 어렵습니다.

내보내기 크기가 엔진의 사용성을 악화시켜서는 안 됩니다, IMO. 내보내기 크기를 줄여야 하는 경우 내보낼 때 3D와 같은 엔진 섹션을 비활성화하는 기능을 만드십시오. 특히 저는 개인적으로 모바일, 특히 웹과 같은 플랫폼을 높이 평가하지 않기 때문에 이러한 토론에서 엔진이 뒤로 물러나는 것을 보는 것이 마음이 아픕니다. (나는 그들에 대한 수요를 볼 수 있습니다, 나사 웹이지만 나를 오해하지 마십시오)

젠장, 편집기 의 다운로드 크기가 걱정된다면 "배터리 포함" 및 "최소" 편집기 다운로드가 별도로 있어야 합니다. 분리를 구현하는 방법은 논쟁의 여지가 있지만 어떤 일이 있어도 잘 통합되어야 합니다.

나는 전체 토론을 완전히 읽지 않았지만 약간 재조정하고 싶습니다. 우리는 크기에 대해 걱정하지 않습니다. 물론 일부 플랫폼에서는 내보내기 크기를 작게 유지하는 것이 중요하지만 엔진에서 기능을 구현할 때 결정적인 요소는 아닙니다. 언급했듯이 일부 기능을 작은 내보내기 크기를 허용하기 위해 조건부로 만들어야 하는 경우에는 간단합니다. 엔진 자체의 다운로드 크기는 중요하지 않습니다.

이제 해결되었습니다. 엔진에서 일부 항목("일부")을 유지하는 것을 고려하도록 권장하는 주요 요소는 다음과 같습니다.

• 기술 부채. 모든 코드를 유지 관리해야 합니다. 우리가 2014년부터 가지고 있는 것과 같은 고장난 VehicleBody는 실제 게임에 충분하지 않기 때문에 특별히 유용하지 않습니다. 최근에 Bullet을 사용하여 개선되어 점점 좋아지고 있지만 지난 4년 동안은 사실상 데드코드와 불필요한 유지보수 부담이었습니다.
• 보편성: Godot는 모든 종류의 게임을 할 수 있게 해주는 엔진이며, 제공하는 기능은 모든 종류의 게임을 할 수 있게 해줍니다. 이것이 독점적이어야 함을 의미하지는 않지만(대부분의 게임에서 2D와 3D가 동시에 필요하지 않음) 기능은 대부분의 사용자의 공통 요구 사항을 충족해야 합니다. 이는 우리가 제공하는 기능은 낮은 수준이어야 하고 게임별 높은 수준의 기능은 대부분 외부에서 가장 잘 제공된다는 것을 의미합니다.
• 유연성: 코어 외부에서 높은 수준의 기능을 유지하면 훨씬 빠른 반복 프로세스를 통해 개선하고 필요한 경우 분기하는 등의 작업을 수행할 수 있습니다.

이대로 가면 플러그인 인프라와 AssetLib 모두 사용성 점검이 필요합니다.

이것이 이 문제의 이유입니다. 그렇죠? :) 요점은 핵심 엔진의 모든 모서리 케이스를 번들로 묶는 대신 더 나은 워크플로를 허용하기 위해 사용성 점검이 필요하다는 것입니다.

음... 누군가가 VehicleBody라는 이름의 외부 기능을 시작하기 위한 아이디어가 필요한 경우 Godot 2에서 3으로 손실된 일부 노드와 클래스를 기억하고 싶습니다: ParticlesAttractor2D(노드) 및 EventStreamChibi(이 클래스는 외부 자산에 적합합니다 ), particleattractor는 실제 입자 시스템과 호환되지 않는 것으로 알고 있습니다. 하지만... Godot의 손실된 기능을 외부 자산의 형태로 복구하는 것은 어떻습니까(Ej, 새 것과 공존하는 이전 입자 시스템....). 누군가가 해당 코드를 별도의 저장소에 유지하기를 원할 수도 있습니다.

@Ranoller 새 시스템은 항상 오래된 것을 제거하므로 불가피합니다.
CPU 입자는 GLES2와 함께 돌아올 것으로 예상되지만(CPU를 지원하지 않기 때문에) CPU에는 어트랙터가 있지만 GPU에는 없는 어트랙터는 좋지 않습니다.
EventStreamChibi는 모듈이었습니다. 새로운 오디오 시스템이 더 유연해지면 트래커 파일을 더 잘 지원할 수 있을 것 같습니다.

우리가 유지 관리에 신경을 쓴다고 해도 아직 물건을 분리해야 한다고는 생각하지 않습니다.
우리는 사람들에게 특별한 스레드에 게시함으로써 노후화에 대한 도움을 요청할 수 있으며 사람들은 기능을 업데이트할 수 있습니다.
Godot 사용자 기반의 엄청난 성장과 함께 나는 많은 사람들이 기꺼이 업데이트하고 오래되거나 엔진 부품에서 누락된 필수 기능(예: 더 많은 관절)에 대해 작업할 것이라고 확신합니다.

사람들이 별도의 코드 파일에서 작업하도록 하는 것이 더 쉽다고 생각한다면 대부분의 사람들은 동일한 노출을 얻지 못할 것이기 때문에 해당 파일에 대해 알지 못하는 것이 잘못된 것입니다. 자산 관리자가 작동해야 하지만 플러그인으로 기능을 갖는 것은 잘 작동하지 않습니다 .
Unity가 매우 잘 통합되어 있고 플러그인과 같은 필수 기능을 제공하지 않기 때문에 Unity에서 Godot로 전환하는 사람들을 몇 명 보았습니다.
그리고 Unity는 이를 더욱 통합하기 위한 작업을 시작하고 Unity 개발 팀에 애드온 개발자를 추가했음을 깨달았습니다.

30MB 엔진을 다운로드해야 하고 프로젝트에 추가하는 것을 잊어버릴 수 있는 별도의 기능을 플러그인으로 다운로드하는 데 시간을 허비한다면 처음에는 해당 기능을 사용하지 않을 수 있습니다. 초보자에게 문제입니다.

기술 부채와 관련하여 이것은 모든 프로젝트(FOSS 또는 상업)가 결국 처리해야 하는 문제입니다. 진실은 일부 개발자가 결국 떠나고 지역에 많은 관심을 끌지 않는다는 것입니다(따라서 누군가가 관심을 가질 때까지 "유지 관리" 모드에 배치되어야 함). 내가 언급했듯이 이것은 대규모 상용 앱에서도 발생합니다. 그래서 엔진 트리밍을 아무리 많이 해도 Godot에서는 필연적으로 일어날 것입니다.

그 분야에서 가장 좋은 해결책은 단순히 사람들이 소스에 기여하기 시작하도록 격려하는 개발 장면을 육성하는 것입니다(그리고 Godot 장면은 모든 자원 봉사 개발을 볼 때 훌륭한 일을 하고 있지만 지속적으로 유지되어야 합니다. 패치 기고자가 리뷰를 보기 위해 오래 기다리지 않도록 하는 것과 같은 것). 그러나 개발자가 떠났기 때문에 기능을 제거하는 것은 가능한 한 피해야 합니다(지속적으로 변동하는 기능 목록은 사람들이 Godot를 _사용하지 않도록_ 설득하는 좋은 방법이기 때문입니다). 오히려 기능 제거는 더 나은 것으로 대체되기 때문에 주로 발생해야 합니다.

그러나 개발자가 떠났기 때문에 기능을 제거하는 것은 가능한 한 피해야 합니다 (지속적으로 변동하는 기능 목록은 사람들이 Godot를 전혀 사용하지 않도록 설득하는 좋은 방법이기 때문입니다). 오히려 기능 제거는 더 나은 것으로 대체되기 때문에 주로 발생해야 합니다.

다시 말하지만, 토론은 잘못된 방향으로 가고 있으므로 올바른 방향으로 돌아가도록 노력하겠습니다. 주제는 항목을 제거하는 것이 아니라 제거하고 싶어할 수 있는 새 항목이 추가되는 것을 방지하는 것입니다. 항목을 추가하는 것은 매우 쉽지만 호환성을 깨뜨리지 않고는 제거할 수 없기 때문입니다.

Godot가 성장함에 따라, 우리가 엔진이 따르기를 원하는 아키텍처나 디자인에 맞지 않을 수 있는 추가 기능이 점점 더 많은 새로운 기여자들에게 제공됩니다. 이러한 모든 변경 사항을 검토하는 데는 많은 시간이 소요되며, 원하는 사항에 맞는지 여부를 결정하는 데는 훨씬 더 많은 시간이 걸립니다. 새로운 기여자가 이러한 새로운 기능을 병합하면 엔진 유지 관리자가 잘 알지 못하거나 결국 완전히 승인하지 않는 코드가 생성될 수 있으며 원래 기여자는 종종 이를 리팩토링하고 우리가 원하는 것과 일치하는지 확인하지 않을 수 있습니다(참조 예를 들어 Tween 노드는 훌륭한 기능이지만 하위 수준의 디자인을 가지고 있고 원래 작성자가 더 이상 주위에 없으므로 다시 생각하고 다시 작성하여 호환성을 깨뜨리는 것은 우리에게 달려 있습니다.

따라서 @reduz 제안의 요점은 새로운 기여자가 코어 엔진에 넣고 싶어하는 기능의 수가 계속 증가하면 대부분의 경우 자산 라이브러리의 자산으로 더 적합하다는 것입니다. 여기서 이 문제의 요점은 이 워크플로가 가능한 한 원활할 수 있도록 하는 방법입니다.

우리는 Godot의 코드베이스를 축소하려는 것이 아니라 폭발하고 통제 불능 상태가 되지 않도록 보호하는 방법에 대해 생각하고 있습니다. (큰 PR을 한 일회성 기여자는 전체 코드베이스와 엔진의 미래에 대한 비전을 철저히 이해하는 엔진 유지 관리자보다 훨씬 더 빈번하기 때문입니다.)

따라서 @reduz 제안의 요점은 새로운 기여자가 코어 엔진에 넣고 싶어하는 기능의 수가 계속 증가하면 대부분의 경우 자산 라이브러리의 자산으로 더 적합하다는 것입니다. 여기서 이 문제의 요점은 이 워크플로가 가능한 한 원활할 수 있도록 하는 방법입니다.

문제를 한 단계 뒤로 옮기는 것 외에는 자산 라이브러리의 자산으로 만드는 것이 무엇을 할 수 있는지 묻고 싶습니다. 더 이상 유지 관리되지 않는 Godot와 번들로 제공되는 코드에서 더 이상 유지 관리되지 않는 Godot 자산의 코드로 이동하고 있습니다. 어느 쪽이든, 원래 기여자는 아마도 어느 시점에서 유지 관리를 중단할 것이고 결국 다시 망가질 것입니다.

@LikeLakers2 글쎄, 그것의 목적은 엔진에 새로운 기여를 추가할 수 있는 부드러운 길을 만드는 것입니다(자산과 관련된 대부분은 지금은 거부되기 때문에). 엔진의 일부 측면이 유지 관리되지 않는 경우 해당 지점에서 순수한 팽창으로 처음부터 엔진과 함께 번들로 제공되어서는 안 됩니다. 이러한 특성은 특히 외부에 포함/업데이트된 플러그인에 적합합니다.

미래에 Godot를 다운로드해야 하고 차량, 제어 노드, 지형 지원, 셰이더 편집기, 괜찮은 Navmesh 플러그인 및 계속해서 - 현재 플러그인과 AssetLib 시스템을 사용하여 - 아니요.

정확히. 일반적으로 AssetLib/애드온은 이에 대해 잘 작동하지 않습니다. 따라서 대화 가 이러한 방식으로 벗어나는 경향이 있습니다. 나는 아무도 지금 당장 물건을 꺼내고 싶어하지 않는다고 생각하지만, 언급했듯이 요점은 너무 많은 새로운 물건을 추가하지 않는 것입니다.

문제를 한 단계 뒤로 옮기는 것 외에는 자산 라이브러리의 자산으로 만드는 것이 무엇을 할 수 있는지 묻고 싶습니다. 더 이상 유지 관리되지 않는 Godot와 번들로 제공되는 코드에서 더 이상 유지 관리되지 않는 Godot 자산의 코드로 이동하고 있습니다. 어느 쪽이든, 원래 기여자는 아마도 어느 시점에서 유지 관리를 중단할 것이고 결국 다시 망가질 것입니다.

글쎄, 나는 그들이 엔진과 더 분리되어 관리 될 수 있다면 더 쉬울 것이라고 가정합니다. 블렌더는 이와 같은 작업을 수행합니다. 그들은 "공식적인"(실제로 공식적이지 않고 사전에 포함된) 추가 기능을 가지고 있지만, 그들의 코드는 별도의 git 하위 모듈에 보관되며, 그것들을 제출한 사람들에 의해 유지 관리되지 않을 때(당신이 다시 제출해야 한다고 생각합니다. 모든 큰 릴리스와 함께), 그들은 삭제됩니다. 솔직히 이 접근 방식이 마음에 들지는 않지만 90%의 자산 브라우저를 내장하고 나머지(수출업체와 같은)를 완전히 통합했으면 합니다.

내 생각에는 엔진에 기본 빌딩 블록만 포함되어 있고 차량 노드 와 같은 항목이 공식 애드온이 될 수 있고 다른 크고 다른 방식으로 구현될 수 있는 모든 것은 일반 애드온이어야 한다는 생각입니다. , 오른쪽?

내가 얻지 못하는 것은 공식 추가 기능이 구현되는 방법입니다. 저는 현재 내장된 것처럼 보이는 사용자 정의 노드를 작성할 수 없다고 생각했습니다. 맞습니까? 스크립트가 있어야 합니까? 또는 C++ 모듈이나 다른 것으로 가능합니다(여기서는 C++ 멍청한 놈입니다).

그리고 결국 우리는 분리된 공식 노드에 의존하는 추가 기능을 갖는 방법의 문제에 빠지게 됩니다. 일종의 종속성 시스템이 없으면 지옥처럼 들립니다.

파티에 늦었지만 현재 프로젝트의 규모를 감안할 때 Godot 3용 _많은_ 플러그인을 개발하고 있으며 프로젝트가 완료되기 전에 더 많은 플러그인을 개발하고 있는 제 자신을 발견했습니다. 각 플러그인을 사용하여 게임에 구애받지 않는 방식으로 최대한 많은 것을 개발하고 다른 사람들이 사용할 수 있도록 MIT 라이선스에 따라 오픈 소스로 만들려고 노력합니다. 나는 거짓말을 하지 않을 것이다. 현재 애드온 시스템은 큰 틀에서 보면 그렇게 나쁘지 않습니다 ... 그러나 많은 경우에 쓸모없게 만드는 몇 가지 누락된 부분이 있습니다. 그러나 그것들을 다루기 전에 @karroffel 아이디어에 대해 몇 가지 말하고 싶습니다.

먼저 이 문제를 해결해 주셔서 감사합니다. 특히 가까운 시일 내에 이러한 논의가 중요하다고 생각합니다. 즉, OP에서 제시한 각 논의 지점은 접선 중첩만 있는 대부분 직교라고 생각합니다. 한 번에 모든 문제를 해결할 필요 없이 여기에서 솔루션을 매우 많이 반복할 수 있다고 생각합니다.

이것은 현재 애드온 시스템에 대한 나의 _개인적인_ 불만으로 이끕니다. 그리고 정기적으로 플러그인을 실제로 개발하는 누군가로부터 더 나은 세상으로 가는 두 가지 아주 좋은 출발점이 될 것이라고 생각합니다.

현재 애드온 시스템의 가장 큰 문제는 종속성 관리의 부족입니다.

이것은 이미 많이 논의되었지만 대부분의 제안은 다소 무겁고 현재 시스템과 매우 호환되지 않습니다. 이제 나는 아직 assetlib 모듈의 코드 베이스에 익숙해지지 않았지만 이 부서에서 쉽게 _해야 _할_ 것입니다. 현재 Github의 3rd part addon 리포지토리는 다음 폴더 구조를 따릅니다.

addons/
    addon_name/
        plugin.cfg
        ...other files

내가 제안하는 것은 plugin.cfg 스키마를 확장하고 사용할 커밋 해시(또는 분기/태그 이름) 옵션이 있는 종속성 버전 목록을 간단하게 가질 수 있는 기능을 추가하는 것입니다. 다음과 같은 것이 작동합니다.

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

그런 다음 자산 라이브러리가 자산을 설치하려고 할 때 현재와 같이 먼저 프로젝트를 addons 디렉토리에 다운로드한 다음, 이후에 각 종속성을 다운로드하고(정의된 올바른 해시 또는 분기 사용) 이를 addons 디렉토리에도 넣습니다. . 첫 번째 단계로 종속성 충돌을 무시하거나 사용자가 사용할 항목을 선택하도록 할 수 있습니다. 이것은 _이상적인_ 솔루션은 아니지만 대부분의 경우 에 효과가 있을 것이며 적어도 assetlib의 보다 복잡한 정밀 검사가 수행될 때까지 우리를 보류할 것이라고 생각합니다. (누군가가 머리 꼭대기에서 의존성 충돌을 처리하는 간단한 방법을 생각해 낼 수 없다면).

실제 사례로,
나는 Godot 행동 나무에 대한 자산을 가지고 있습니다. 이 시스템의 일부는 노드 간에 공유될 임의의 전역 또는 노드 로컬 데이터를 저장하기 위한 UE4와 유사한 Blackboard 노드입니다. 이것은 행동 노드 간의 상태 공유를 위해 BT 시스템에서 사용됩니다. 그것은 모두 훌륭하고 멋지지만 현재 대화 시스템과 함께 제공되는 도구를 개발 중이며 이 시스템의 일부는 조건에 사용할 일종의 varibales 데이터베이스가 필요합니다. 대화 시스템에서도 BT 시스템의 칠판 구성 요소를 재사용하고 싶습니다. 사실, Blackboard 구성 요소는 얻을 수 있는 만큼 일반적이고 전역 데이터는 gamedev에서 상당히 일반적인 관용구입니다. 따라서 기본적으로 어쨌든 모든 프로젝트에서 다시 구현되는 것이기 때문에 자체적으로도 상당히 유용한 애드온이 될 수 있습니다. .

적절한 종속성 시스템을 사용하면 Blackboard 구성 요소를 자체 애드온으로 분리한 다음 이 구성 요소를 모든 BT 애드온, 대화 시스템 애드온 및 기타 게임별 용도에서 재사용할 수 있습니다. 무슨 말인지 알 것 같습니까?

다중 스크립트 노드의 필요성

이것은 이미 이 호의 또 다른 뜨거운 주제입니다. 솔직히, 저는 Godot가 어떻게 사용되도록 의도되었는지에 대한 근본적인 이데올로기를 바꾸지 않고는 이것에 접근할 수 있는 좋은 방법이 없습니다. 이것은 괜찮을 수도 있고 아닐 수도 있지만 네... 어쨌든, 이것은 플러그인 _users_에 대한 것만큼 플러그인 _authors_에 대한 문제가 아닙니다(종종 같은 사람이지만 ;).

결국 이 두 가지만 풀면 90%는 될 것 같아요. 나머지 10%는 내 생각에 그렇게 큰 거래가 아니며 아마도 자산의 기본 아키텍처를 정밀 검사하는 관점에서 접근해야 합니다.

이의가 없다면 앞으로 며칠 내에 assetlib 코드에서 종속성 관리에 관한 제 제안을 구현하려고 할 것입니다.

의존성 관리는 나에게 멋있게 들린다. : 스마일 :

내가 동의하지 않는 유일한 것은 종속성 버전이 있다는 것입니다.
선택적 목록이어야 합니다. 그것은 reduz가 언급한 문제를 일으킬 것입니다.
다른 엔진의 플러그인 시스템에서 발생합니다.

누군가가 머리 꼭대기에서 의존성 갈등을 다루는 간단한 방법을 생각해 낼 수 없다면

플러그인이 코드를 호출하는 방식에 따라 솔루션이 달라질 것이라고 생각합니다.
다른 플러그인. 플러그인의 스크립트가 수행하도록 설정하면
extends "dep2/folder/script.gd" , 설치 시 dep2 를 변경할 수 있습니다.
dep2-v3.1.2 . 해시의 경우 처음 5자리만 사용할 수 있습니다.
이름이 42자 이상인 폴더가 필요함). 5시에
충돌의 가능성은 엄청나게 적습니다.

지금은 조금 피곤해서 뭔가를 놓치고 있을지도 모르지만 나는 보이지 않습니다
어떤 문제.

@jonbonazza 그렇다면 Git 사용법을 하드코딩하지 마십시오. 여기에서는 당연한 것처럼 들리지만 일부 사람들은 다른 VCS 시스템을 선호할 수도 있습니다(또는 VCS를 전혀 사용하지 않음). 따라서 이는 아마도 asset-lib 측에서 처리해야 할 세부 사항이어야 합니다.
또한 프로젝트에서 플러그인을 VCS 하위 리포지토리로 사용하기 쉽게 만드는 작업을 고려하고 있는지 궁금합니다. 어느 시점에서 언급되었지만 합의가 있었는지 기억이 나지 않습니다.

네, 에셋의 id와 버전만 있으면 충분하다고 생각합니다.

Git 저장소/분기/태그/해시를 지정하는 것은 종속성을 지정하는 선택적 방법일 수 있지만 기본 방법은 자산 ID를 사용하는 것이어야 합니다.

자산 라이브러리에 사람이 읽을 수 있는 고유한 ID(슬러그)가 있는지 확실하지 않습니다. 그렇지 않은 경우해야합니다. 예를 들어 npm 모듈에는 설치할 때 사용하는 텍스트 모듈 이름/ID가 있습니다.

종속성 사양은 다음과 같습니다.

[dependency]
asset_id="some_asset"
version="1.0.0"

@Two-Tone 이것에 너무 열광하지 않으려고 노력했습니다. 더 나은 접근 방식이 결정될 때까지 우리를 붙잡아 둘 간단한 것을 원했습니다.

@Zylann 아마도 현재 lib 자산에서 사용되는 것과 동일한 접근 방식을 사용할 것입니다. github에서 zip 파일을 다운로드하고 추출하는 것입니다.

@chanon 자산 라이브러리는 github과 직접 연결되므로 버전에 대한 유일한 식별은 커밋 해시, 분기 및 태그입니다.

어떤 부분이 너무 미쳤습니까? 종속성 버전이 필수 또는 내 솔루션
종속성 충돌을 위해? 하나는 다음이 있는 대부분의 장소에서 표준입니다.
종속성 관리 및 다른 하나는 텍스트 및 폴더에 대한 간단한 편집입니다.
명명 된. 나는 그 둘 중 하나가 미쳤다고 생각하지 않습니다.

2018년 7월 3일 화요일 오전 11시 23분에 Jon Bonazza [email protected] 이 다음과 같이 썼습니다.

@Two-Tone https://github.com/Two-Tone 너무 화내지 않으려고 했어요
이것으로. 더 나은 날이 올 때까지 우리를 지켜줄 단순한 무언가를 원했습니다.
접근 방식이 결정됩니다.

@Zylann https://github.com/Zylann 아마 같은 접근 방식을 사용할 것입니다
현재 자산 lib에서 사용되는 파일 -- zip 다운로드 및 압축 풀기
github의 파일.

@chanon https://github.com/chanon 자산 라이브러리는 github와 함께 작동합니다.
버전에 대한 유일한 식별 정보는 커밋 해시뿐입니다.
분기 및 태그.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/19486#issuecomment-402214905 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
.

@Two-Tone 죄송하지만 "너무 미쳤습니다"는 "너무 복잡함"을 의미했습니다. 이것은 우리를 붙잡아 두는 빠른 수정일 뿐이기 때문입니다. 장기적으로 적절한 갈등 해결이 필요하다는 점에는 동의하지만 그 사이에 갈등을 해결하지 않고 그냥 지나갈 수 있기를 바랐습니다.

또 다른 옵션은 assetlib를 모두 함께 사용하지 않고 deps를 프로젝트에 직접 git clone하는 것입니다. 그러나 현재 사실상 플러그인 프로젝트 구조가 addons 디렉토리에 뿌리를 두고 있기 때문에 이것은 실제로 작동하지 않습니다. 프로젝트 루트가 한 수준 더 깊어야 합니다(예: addons 디렉토리를 제외하고 플러그인 이름에 루트됨). 솔직히 말해서 이것은 의존성에 git 하위 모듈을 사용할 수 있기 때문에 상관없이 환영할 만한 변화라고 생각합니다.

@jonbonazza 알겠습니다 . 귀하의 솔루션은 자산 라이브러리를 수정할 필요 없이 즉시 구현하고 작동할 수 있는 것입니다. 그렇다면 좋은 첫 단계라는 데 동의합니다. (제가 어떤 권한이 있는 코어 메인테이너가 아니라.. 좋은 첫걸음이라고 생각합니다.)

애셋 라이브러리 데이터베이스에 텍스트 식별자(슬러그)와 버전 정보가 추가되면 위의 예와 같이 추가될 수 있다고 생각합니다.

종속성을 위해 git 하위 모듈을 사용할 수 있습니다.

@jonbonazza 그리고 그것이 내 후자의 질문이 다시 제기되는 곳입니다. 왜냐하면 해당 repo는 다운로드에 적합하도록 전체 파일 계층을 포함해야 하기 때문에 플러그인 repo와 함께 하위 모듈을 사용하는 것이 불가능하기 때문에 .git 를 강제 실행합니다.

@chanon 맞습니다 . 몇 개의 파일에 약간의 추가 코드만 있으면 됩니다. 솔직히, assetlib에 빌드하는 대신 이 작업을 수행할 수 있는 애드온이 개발될 수 있습니다.

@Zylann 네, 그게 제가 하위 모듈에 대한 내 의견에서 얻은 것입니다. 현재 프로젝트 구조에 대한 현재 제한으로 인해 불가능하지만 이와 관련하여 자산 라이브러리를 더 유연하게 변경하는 것은 간단합니다.

편집: 이전 버전과 호환되는 방식으로도 수행할 수 있습니다.

사실 얼마 전에 프로젝트 구조에 대한 제안을 한 적이 있습니다. 그것이 실제로 플러그인이 어떻게 작동하는지에 대한 나의 주된 불만입니다. 그것들을 포장하는 좋은 방법은 없습니다. #18131을 참조하십시오. 무엇보다 먼저 변경해야 하고 더 빨리 변경해야 합니다. 따라서 플러그인을 전환해야 하는 사람이 줄어듭니다.

뭐가 복잡해? 하나는 다음과 같이 시행할 수 있는 요구 사항입니다.
단순 확인 및 다른 하나는 단순 일치 및 교체 또는
추가/앞에 추가합니다. 이것은 실제로 종속성 지원을 추가하는 것보다 간단합니다.

2018년 7월 3일 화요일 오후 12시 11분에 Jon Bonazza [email protected] 이 작성했습니다.

@Two-Tone https://github.com/Two-Tone 죄송하지만 "너무 미쳤습니다"
"너무 복잡합니다". 왜냐하면 이것은 우리를 붙잡아 두는 빠른 수정일 뿐입니다.
장기적으로 적절한 갈등 해결이 필요하다는 데 동의하지만,
나는 우리가 그 사이에 그것 없이 그냥 도망칠 수 있기를 바랐다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/19486#issuecomment-402229111 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
.

@Two-Tone 플러그인 코드의 스크립트는 종종 애드온의 경로를 직접 사용하기 때문에 폴더 이름을 바꿀 수 없습니다. 예

extends "res://addons/foo/bar.gd"

@jonbonazza 덧붙이자면 스크립트만이 아니라 다른 리소스를 참조하는 모든 리소스입니다.

그런 다음 내가 말했듯이 추가 기능 폴더 구조가 있지만 필수 항목입니다.
설치 시간은 String 클래스의 찾기 및 바꾸기 기능을 사용하기만 하면 됩니다.
찾을 모든 스크립트에 있습니다

'확장' res://addonname/ '

그리고 그것을 대체

'확장' res://addonname-versionnumber/ '

이것은 코드에서 어려운 문제가 아닙니다. C++ 덕분에 정말 간단합니다.
이러한 문제가 해결되었는지 확인하기 위한 대부분의 사용자 문제입니다.
우리는 몇 가지를 위임해야합니다. 플러그인을 업로드하고 사용자가 이를 발견하면
개발자가 이것을 믿을 수 없을 정도로 따르지 않았기 때문에 완전히 망가졌습니다.
간단한 규칙은 플러그인 개발자에게 있습니다.

그리고 우리는 처음부터 규칙을 의무화해야 할 것입니다.
우리가 이 일을 제대로 하고 있는지 확인하기 위해 이것들 또는 이것의 어떤 형태를 포함하십시오.
처음부터.

2018년 7월 4일 수요일 오후 12시 48분 Marc [email protected] 이 다음과 같이 작성했습니다.

@jonbonazza https://github.com/jonbonazza 추가하겠습니다.
그렇게 하는 스크립트이지만 다른 자산을 참조하는 모든 자산.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/19486#issuecomment-402533781 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXclrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
.

플러그인이 업데이트 후 호환성을 깨면 지원 중단 폴백을 제공하거나 @Two-Tone이 말한 대로 플러그인 또는 플러그인의 하위 폴더 이름을 변경하여 의도적으로 경로를 깨야 합니다. 좋은 상황은 아닙니다.) 그것이 엔진 자체가 하는 방식이고 다른 사람들도 하는 방식입니다. 플러그인을 작성하는 것은 당신이 모르는 다른 사람들/플러그인이 그것에 의존할 것이라는 완전히 다른 사고방식과 함께 옵니다.

이것이 해결하는 것은 종속성 문제가 아니라 종속성 충돌에 대한 솔루션입니다. 하나의 플러그인은 다른 애드온의 버전 1에 의존하고 다른 플러그인은 버전 2에 의존할 수 있습니다. 이것 또는 이와 유사한 것이 없으면 충돌이 발생하거나 사용자가 다음과 같은 플러그인을 사용할 수 없도록 제한해야 합니다. 충돌하는 종속성이 있습니다.

업데이트가 호환성을 손상시키지 않도록 하는 솔루션은 각 업데이트에 고유한 버전 번호가 있어야 하도록 강제하는 것입니다. 그러나 plugin.cfg 를 구문 분석한 다음 해당 이름과 버전 번호를 가진 플러그인이 이미 있는지 자산 서버에 물어봐야 하므로 "너무 복잡한" 범주에 빠지기 시작할 수 있습니다. 있으면 오류를 던집니다. 그렇지 않다면 모든 것이 정상이어야 합니다.

그리고 당신이 플러그인의 스크립트를 말하는 것인지 아니면 사용자가 작성하는 스크립트를 말하는 것인지는 모르겠지만, 어느 쪽이든 다루기 힘들긴 하지만 그렇게 어려운 문제는 아니라는 점에는 동의합니다.

내가 생각할 수 있는 유일한 해결책은 gdscript를 확장하여 사용자가 스크립트에서 사용 중인 플러그인 버전을 지정할 수 있도록 하는 것입니다. 그런 다음 그 시점부터 extends "res://addonname/etc 를 수행하고 엔진 자체에서 올바른 경로. 그러나 이는 @jonbonazza 가 언급한 "너무 복잡한" 문제에 속합니다. 그러나 단기적으로는 건너뛸 수 있습니다.

결국 해결해야 할 다른 문제가 있습니다. EG 사용자는 어떤 종속성이 설치되는지, 종속성 충돌 문제를 해결하기 위해 내부 파일 시스템 브라우저에서 여러 폴더를 처리하는 방법, 종속성이지만 업데이트가 있는 플러그인을 어떻게 처리해야 하는지 알아야 합니다. 수동으로 설치된 플러그인에 사용되는 것과 동일한 설정을 적용하십시오(예: 자동 설치 버그 수정 또는 기본 플러그인이 종속성 목록을 업데이트할 때만 업데이트 설치), 그리고 더 많은 것을 확신합니다.

@reduz 가 종속성 관리가 중요하지 않다고 느끼는 이유를 절대적으로 알 수 있습니다. 이것이 Godot에 포함될 가치가 있기 위해 고려되고 해결되어야 하는 _ 필요한 _ 많은 변수가 있습니다. 그렇지 않으면 다른 엔진이 사용하는 것보다 더 나은 시스템이 없게 됩니다.

솔직히 말해서, 단기 솔루션을 위한 최선의 조치는 자산 라이브러리를 변경하여 addons 디렉토리 아래에 있는 하나의 레이어에 있는 프로젝트를 제공하는 기능을 지원하도록 자산 라이브러리를 변경하는 것입니다(이전 버전과의 호환성 때문에 _require_는 아님). 예

godot-tools.level-streamer/
    project.cfg

대신에

addons/
    godot-tools.level-streamer/
        project.cfg

이런 식으로 애드온 설명에 다른 애드온이 필요하다고 지정할 수 있습니다.

또한 원하는 경우 애드온을 위해 프로젝트에서 gitsubmodules를 쉽게 사용할 수 있습니다.

deps(예: dep/ )에 대해 그렇게 한 다음 루트 디렉토리나 사용자 정의 폴더에 수동으로 플러그인을 설치하는 것은 어떻습니까? 그런 식으로 종속성이 루트를 어지럽히지 않고 애드온이 또는 중 하나에 있을 수 있습니다.

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@Two-Tone 하지만 의존성에 의존성이 있다면? 대신 deps 폴더가 플러그인 자체의 하위 폴더가 되어야 하지 않습니까? 그렇게 하면 필요에 따라 임의로 깊이 들어갈 수 있습니까?

이 전체 종속성 문제가 지나치게 생각되고 있는 것 같습니다. 몇 가지 간단한 시스템을 생각해내고 각각에 대해 토론하거나 투표를 해야 할까요? 나는 이 대화가 현재 진행되고 있는 방식으로 끝날 것이라고 예상하지 않습니다.

그말이...

@willnationsdev 작동할 수 있지만 많은 플러그인이 동일한 종속성에 의존하는 경우 해당 종속성의 복사본이 여러 개 있을 수 있습니다.

예, 종속성 관리는 간단한 일이 아닙니다. 그렇지 않으면 npm 가 그렇게 복잡할 필요가 없고 yarn 가 생성될 필요도 없습니다.

종속성을 자산의 하위 폴더로 두는 것은 매우 복잡한 경로로 이어지기 때문에 좋은 생각이 아니라고 생각합니다. 2개 이상의 자산에 동일한 종속성이 있고 일종의 중복 제거가 필요한 경우가 있습니다. 또한 게임 개발자는 공통 종속성이므로 하위 폴더의 하위 폴더를 통해 어떤 종속성이 사용 및/또는 n번 중복되는지 확인하는 것보다 프로젝트에 어떤 종속성이 있는지 정확히 확인하는 것이 더 낫다고 생각합니다.

예를 들어 node.js 웹 개발에서 node_modules가 서버에만 배포되기 때문에 작동하는 한 node_modules 내부에 있는 내용을 무시해도 됩니다. 게임의 경우 모든 코드/자산을 최종 앱 패키지로 패키징하고 동일한 종속성을 n번 복제하는 것은 매우 나쁩니다.

이러한 문제가 내 초기 제안에서 자산이 아직 종속성을 정의하도록 하지 않고 프로젝트의 종속성을 나열하고 사용자가 자산의 종속성을 수동으로 설치하도록 하는 방법이 있다고 말한 이유입니다.
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

종속성을 정의하는 자산이 있는 경우 모두 동일한 수준( res://addons 폴더)에 설치되어야 한다고 생각합니다. 종속성 버전 충돌(두 개의 자산은 동일한 자산에 의존하지만 버전은 다름)의 경우 항상 최신 버전으로 가는 것과 같이 간단한 해결이 가장 좋을 것이라고 생각합니다.

반면에 동일한 자산의 여러 버전을 설치하도록 허용하여 중복 제거 및 버전 충돌 해결을 통해 종속성 관리를 구현하려는 경우에도 괜찮습니다! 정말 튼튼하게 만들어진 것처럼 장기적으로 자산 생태계의 확장을 지원할 수 있을 것입니다. 어쨌든 내 게임 프로젝트에 동일한 자산의 여러 버전이 있다는 생각이 마음에 들지 않습니다. 그리고 제대로 될 때까지 npm 많은 버전이 필요했습니다(저는 여전히 yarn 를 선호하지만). 그래서 저는 이 작업을 과소평가해서는 안 된다고 생각합니다.

종속성을 자산의 하위 폴더로 두는 것은 매우 복잡한 경로로 이어지기 때문에 좋은 생각이 아니라고 생각합니다.
자산이 종속성을 정의하는 경우 모두 동일한 수준( res://addons 폴더)에 설치되어야 한다고 생각합니다.

나는 그것에 동의합니다. 나는 또한 애드온이 다양한 다른 소스와 다양한 폴더에 필요한 버전만큼 많지 않은 표준 위치의 프로젝트에 한 번 존재하는 것을 선호합니다. 종속성은 문제이지만 최대한 세분화하지 않고 비교적 단순하게 유지하기 위해 중간 지점을 찾을 수도 있습니다.

이러한 문제는 내 초기 제안에서 자산이 아직 종속성을 정의하도록 하지 않고 프로젝트의 종속성을 나열하고 사용자가 자산의 종속성을 수동으로 설치할 수 있는 방법이 있다고 말한 이유입니다.

저에게 자산이 종속성을 정의하는 경우 설치하기 전에 문서를 보거나 모든 플러그인을 검토해야 하는 것보다 사용자가 더 빨리 정보를 얻는 것이 기본적으로 중요합니다. 그리고 결국에는 종속성을 동시에 다운로드할 수 있는 옵션이 있지만 편의를 위해서입니다(특히 처음부터 설치할 때 어쨌든 설치해야 함). 종속성 충돌을 해결할 필요도 없을 것입니다. 적어도 설치 도구는 사용자에게 이를 감지할 수 있는지 알려줄 수 있습니다.

이 전체 종속성 문제가 지나치게 생각되고 있다고 생각합니다.

@LikeLakers2 적절한 종속성 관리 및 충돌 방지는 중요하고 어려운 문제입니다. 그것 때문에 많이 논의되고 있다.

나는 이 대화가 현재 진행되고 있는 방식으로 끝날 것이라고 예상하지 않습니다.

의존성이 가져오는 모든 문제를 파악하지 않고 이것을 밀어붙이려고 하는 것은 매우 나쁜 생각이 될 것이고 더 많은 문제를 일으킬 것입니다. 이것은 어려운 문제이며 시간이 걸릴 것입니다.

종속성 버전 충돌의 경우(두 개의 자산은 동일한 자산에 종속되지만 다른 버전의 자산) 간단한 해결이 가장 좋습니다.

@chanon 제 생각 은 단순합니다. 폴더 이름을 지정하고 텍스트 문서에서 관련 파일 경로를 변경하는 것이 복잡한가요? 사용자에게는 일회성 비용이며, 설치한 버전을 명확하게 하고 쓰기가 상당히 쉽습니다.

항상 최신 버전으로 가는 것처럼

그러면 종속성이 업데이트되고 작동 방식이 변경됨에 따라 플러그인이 경고 없이 중단됩니다. EG 플러그인 1과 2는 모두 Dep 1에 의존하지만 버전은 다릅니다. 플러그인 2는 현재 최신 버전에 종속되지만 플러그인 1은 최신 버전과 다르게 동작하는 이전 버전에 종속됩니다. 플러그인 1이 더 이상 의도한 대로 작동하지 않거나 함께 제공되지 않은 버그가 있습니다.

종속성 충돌을 해결할 필요도 없을 것입니다. 적어도 설치 도구는 사용자에게 이를 감지할 수 있는지 알려줄 수 있습니다.

@Zylann 그러면 y가 동일한 종속성의 다른 버전을 사용하기 때문에 사용자가 x 플러그인을 설치할 수 없는 문제가 있습니다. 그것은 사용자들에게 좋은 것으로 간주되지 않을 것입니다.

@willnationsdev 및 @LikeLakers2 에 동의합니다.

이 전체 종속성 문제가 지나치게 생각되고 있는 것 같습니다. 몇 가지 간단한 시스템을 생각해내고 각각에 대해 토론하거나 투표를 해야 할까요? 나는 이 대화가 현재 진행되고 있는 방식으로 끝날 것이라고 예상하지 않습니다.

너무 많은 자전거 흘림. 이것은 게임 엔진 애드온 전달 플랫폼이 아닌 게임 엔진입니다. 각 애드온의 디렉토리에 있는 공급업체 종속성만 보고 하루라고 합니다. 버전 충돌이나 관리에 대한 스트레스가 없거나 일부 비효율성을 희생해야 합니다. 애드온 사용자가 성능에 대해 우려하는 경우 GDNative 또는 모듈과 같은 REAL 성능 최적화를 고려할 위치에 있어야 합니다. 나는 또한 모든 애드온에 깊은 종속성 그래프가 있는 이유를 상상할 수 없습니다. 내가 다른 애드온에 의존하는 애드온을 볼 수 있는 유일한 이유는 그것이 어떤 식으로든 확장하는 경우입니다: SweetFpsController -> SweetFpsController w/ flying . 이 경우 엔진에 책임을 전가하기 보다는 두 프로젝트 또는 해당 사용자가 연결을 조정해야 한다고 말하고 싶습니다.

@Two-Tone 플러그인 A가 X의 버전 1을 필요로 하고 플러그인 B가 X의 버전 2를 필요로 한다면, Godot는 그것을 마술처럼 고치려고 해서는 안 된다고 말하고 싶습니다. 이에 대한 간단한 해결책은 다음과 같습니다.

• 일반적으로 X 버전 2는 버전 1과 이전 버전과 호환되어야 하며 간단하게 유지해야 합니다.
• 최신 버전의 X를 사용할 수 없는 경우 플러그인 A가 이를 지원하고 이전 버전을 다운로드할 때까지 기다리십시오(최신 버전뿐만 아니라 다른 버전을 가져오는 것을 처리하기 위해 assetlib API가 필요하므로 어려운 일이 아닙니다). 마치 모드처럼 완벽할 필요는 없습니다.
• X의 플러그인 제작자는 Godot 3가 나왔을 때 했던 것처럼 (API가 호환성을 깨기 때문에) 다른 플러그인으로 업로드합니다. 그러면 동일한 플러그인이 두 번 생성되지만 실제로 동일한 플러그인이 되기에는 너무 다르기 때문에 괜찮습니다. 두 개의 자산 라이브러리 항목이 필요하지 않아도 플러그인 개발자가 폴더 이름을 변경할 수도 있습니다.

최악의 시나리오에서는 수동으로 이 작업을 수행해야 합니다(그리고 결국 플러그인 제조업체에 대한 PR 호환성).

이것이 아니라면 매번 다른 경로가 설치되는 두 가지 버전(각 업데이트마다 모든 참조 나사 고정) 또는 경로 작동 방식을 변경하기 위해 엔진에 핵심 변경 사항이 추가되는 것(복잡함)이 포함됩니다.
나는 우리가 간단한 의존성 관리를 얻을 수 있다면 이미 Godot가 이미 가지고 있는 기능과 구조를 기본적으로 사용하고(구현하기도 매우 간단할 것이기 때문에) 이미 사용자가 현재 가지고 있는 것을 자동으로 수행할 수 있다고 생각합니다. 어쨌든 수동으로 할.

나는 의존성 관리를 항상 작동해야 하고 엔진(예: npm)의 전적인 책임이 되어야 하는 것으로 생각하지 않습니다. 왜냐하면 그것은 많은 일이 될 것이기 때문입니다. 기존 기능으로 현재 손으로 해야 하는 작업에 대한 편의를 우선적으로 고려하고 플러그인 제작자는 이러한 간단한 시스템을 염두에 두고 작업을 릴리스할 수 있습니다.
누군가가 이보다 더 나아가 시스템을 훌륭하게 구현한다면 나중에 수행할 수 있습니다. 위에서 설명한 것은 이전에 실행 가능하고 대부분 assetlib 및 편집기에 대한 간단한 개선 사항이기 때문입니다.

@Zylann 내가 제안한 것보다 더 나은 옵션이 있습니까? 그리고 특정 문자열에 텍스트를 검색하고 추가하는 것과 관련하여 마법 같은 것은 없습니다.

옵션 1은 개발자가 버전 업데이트가 그것에 의존하는 다른 플러그인을 중단시키지 않도록 하여 많은 추가 작업을 추가하도록 합니다. 누가 그런 플러그인을 개발하고 싶습니까?

옵션 2는 사용자가 플러그인이 업데이트될 때까지 기다려야 하므로 사용자가 원하는 플러그인을 사용하지 않도록 합니다.

옵션 3은 다시 한 번 플러그인 개발자를 더 어렵게 만듭니다.

경로가 다른 두 가지 버전은 어려운 문제가 아닙니다. 업데이트가 완료되면 어떤 설치 패키지가 종속성인지 확인하고 해당 패키지의 모든 스크립트에서 검색 및 교체(이전 버전 번호 고려)를 다시 실행한 다음 마지막으로 새 버전의 압축을 풉니다.

사람들이 이것을 필요 이상으로 복잡하게 만들려고 하는 것 같습니다.

적절한 종속성 관리 및 충돌 방지는 중요하고 어려운 문제입니다. 그것 때문에 많이 논의되고 있다.

@Two-Tone 내 말은 당신이 그 문제가 어려운 문제임에도 불구하고 너무 열심히 생각하고 있다는 것입니다. 많은 대화(내 답장을 포함하여 위선적으로 들릴 수 있으므로 실례합니다)는 제시된 아이디어의 문제점 에 대한 것이지, 아이디어를 변경하고 개선하기 위해 무엇을 할 수 있는지에 대한 것이 아닙니다. 계획. 제안된 아이디어에는 단점 만 있을 수 없습니다. 그렇지 않나요? 모든 사람이 자신의 방식과 방식만을 원하는 것 같으며, 이는 중요하지 않습니다.

의존성이 가져오는 모든 문제를 파악하지 않고 이것을 밀어붙이려고 하는 것은 매우 나쁜 생각이 될 것이고 더 많은 문제를 일으킬 것입니다. 이것은 어려운 문제이며 시간이 걸릴 것입니다.

나는 우리가 그것들을 다듬고 좋은 시스템을 갖추었다고 느낄 때 결정한다는 의미와 함께 몇 가지 간단한 아이디어를 제안했습니다. 나는 그것을 명시 적으로 지적해야한다고 생각하지 않았지만 거기에 있습니다.

나는 이 대화가 아무런 진전도 없이 얼마나 오래 지속되었는지에 대해 다소 짜증이 난다. 진지하게.

경로가 다른 두 가지 버전은 어려운 문제가 아닙니다.

그것만으로는 아마 아닐 것입니다. 그러나 Godot에서 주어진 시간에 동일한 플러그인의 두 가지 버전을 갖는 것은 해결하기 위해 혼란스러워지는 다른 것들을 의미합니다.

• 당신의 경로는 더 이상 당신이 생각하는 것과 같지 않습니다/코어에 변경이 필요합니다.
• 플러그인이 사용자 정의 유형을 노출하는 경우 편집기에 표시되는 유형은 무엇입니까?
• 플러그인이 C#인 경우 다른 복사본과 충돌하지 않고 어떻게 컴파일합니까?
• 플러그인이 자동 로드를 등록하는 경우 어떻게 구분합니까?
• 사용자가 플러그인을 사용하는 데이터를 생성한다면 어떤 것을 사용하게 될까요?
• 어느 것이 에디터에 UI를 보여줄까요?

엔진에 맞는 간단한 솔루션을 찾기도 전에(내가 생각하지 못한 것이 더 있을 수 있음), 호환성을 깨거나 핵심 변경 사항을 도입하지 않고 편집기와 자산 라이브러리의 기존 항목을 이미 개선할 수 있다고 생각합니다.

이 스레드의 모든 항목에 +1 - 플러그인 모듈을 확장하고 자산 라이브러리 사용을 늘리는 것이 좋습니다.

Unity를 사용해 보고 배운 후, 이제 이것이 어떤 모습이어야 하는지 더 명확해졌습니다.

첫 번째는 Unity에 이제 '패키지 관리자'가 있어 사용자가 설치/제거할 엔진 구성 요소를 선택할 수 있도록 하는 것입니다. 향후 에셋 스토어에서도 사용할 수 있을 것 같습니다.

이와 같은 것은 Godot가 "공식 애드온"을 가지고 있는 동안 "팽창을 줄이는" 수 있도록 정말 도움이 될 것입니다. Unity는 패키지 관리자를 사용해도 여전히 엄청나게 부풀려 있지만 Godot에 패키지 관리자가 있다면 더 작아질 수 있습니다. "하나의 exe" 배포 방법을 사용해야 할 수도 있습니다.

또한 일반 "모듈"은 패키지 관리자에서 설치/제거를 위해 선택할 수 있도록 공유 라이브러리(dll/.so 파일)로 빌드되어야 합니다.

프로젝트와 패키지에는 의존하는 패키지를 나열하는 매니페스트 파일이 있어야 하며 Godot/패키지 관리자는 필수 패키지가 설치되었는지 확인합니다.

패키지의 공개 레지스트리가 필요합니다.

이를 통해 커뮤니티는 Godot의 기능을 쉽게 확장하고 서로의 작업을 쉽게 구축할 수 있습니다. 지역사회 발전에 많은 도움이 될 것이라고 생각합니다.

패키지 관리자 접근 방식으로 전환하는 것의 전반적인 장점에 동의하지 않고 아직 결정하지 않았지만 약점도 있다는 점을 지적하고 싶습니다. 단일 실행 파일이 훨씬 더 통합되고 잘 될 수 있다는 점입니다. 적어도 더 쉽게 테스트되었습니다.

패키지 관리자를 사용하면 테스트 표면이 각 플러그인 및 버전에 대해 기하급수적으로 커집니다. 플러그인이 엔진 코어에 너무 깊숙이 연결되지 않은(현재 AssetLib에 있는 것처럼) 대부분 작은 추가인 경우에는 그렇게 나쁘지 않지만 엔진의 핵심 부분을 분할하면 빠르게 그렇게 됩니다.

Unity는 이미 여러 버전의 패키지, 편집기 또는 특정 패키지 조합을 설치(또는 설치하지 않음)하거나 설치된 순서에 따라 문제, 충돌 및 호환성 문제를 겪고 있습니다.

이것은 우리가 종속성 지옥에 빠지지 않도록 잘 관리해야 하는 많은 추가 복잡성입니다. :)

종속성 지옥과 관련하여 AppImage와 같은 페이지를 가져와서 플러그인 배포자가 자산/파일 종속성을 관리하도록 하여 종속성 문제를 피하는 것이 어떻습니까? 이 문제를 보는 방법은 다음과 같습니다.

플러그인은 (이상적으로는) 로직(사용자 정의 편집기, 사용자 정의 노드, 동적으로 연결된 라이브러리) 또는 자산(모델, 재료, 글꼴, 텍스처 등) 중 하나의 자체 포함 요소여야 하며 고유한 종속성 세트가 있어야 합니다. 공유 종속성을 파악하는 것은 사람들이 좋아할 수도 있지만 유지 관리를 위해 훨씬 더 많은 노력을 요한다는 수수께끼입니다. 실제로 공유 종속성을 허용하려면 Steam 런타임과 유사한 이 문제에 접근하고 다양한 라이브러리, 플러그인 및 자산을 고유한 패키지로 유지해야 합니다. 또한 여러 버전의 서버에 여러 개의 동일한 패키지를 저장해야 합니다. 유지 관리의 악몽이 될 것이며 최신 Linux 배포판이 패키지 관리자에서 어느 정도 멀어지는 것은 놀라운 일이 아닙니다.

플러그인은 기본적으로 해당 플러그인이 독립적으로 작동하는 데 필요한 모든 요소의 단일 tar 아카이브일 수 있습니다. 내부에 보관된 모든 종속성과 함께 기본적으로 자체적으로 작동해야 합니다. Godot는 이 파일을 볼 때 아카이브된 폴더의 루트 내부에 매니페스트 파일을 확인합니다. 이 매니페스트는 기본 정보(이름, 설명, godot-버전, 아이콘, 작성자)를 포함할 수 있지만 다음과 같은 것도 포함해야 합니다. 플러그인(사용자 권한 있음), project_website(사용자가 패키지 소스를 빠르게 찾을 수 있도록 하는 저장소 또는 웹사이트 링크) 및 class_names(확장할 수 있는 이 애드온 내의 클래스 목록, 스크립팅에 사용됨) 또한 다음을 가리킬 수 있습니다. 내부 플러그인 파일에 대한 상대 경로를 사용하여 종속성으로 사용하는 애드온.

플러그인 내에서 플러그인을 허용하면 종속성 문제가 (다소) 해결됩니다. 동일한 라이브러리의 다른 버전은 다른 디렉토리 경로에 있으며 주어진 포크에서 다른 '경로'로 취급될 수 있습니다. 물론 이 시스템의 문제는 주어진 디스크에 많은 중복 정보가 있다는 것입니다. 그러나 게임을 패키징할 때, Godot는 이상적으로 모든 플러그인 디렉토리를 살펴보고 체크섬을 통해 일치하는 파일 참조를 병합할 수 있습니다(여기에 tar로 표시된 파일 구조가 포함될 수 있습니까?). 이렇게 하면 두 파일이 동일할 경우 Godot는 단일 파일에 대한 참조를 병합하여 최종 출력 바이너리를 최적화합니다.

나는 이것이 이 복잡한 문제에 대한 솔루션에 대해 너무 순진하다고 확신하지만, 최근에 내 사용자 정의 글꼴 패치로 인해 플러그인 시스템에 대해 생각하고 있었습니다. 최고의 사용자 경험은 종속성에 대해 걱정할 필요가 없는 환경이고 개발자는 자신의 종속성을 관리해야 하는 사람입니다. 이렇게 하면 사용자가 더 쉽게 관리할 수 있습니다. 프로젝트는 파일 시스템 독에서 단일 파일로 표시되는 애드온을 가질 수 있으며, 마우스 오른쪽 버튼을 클릭하고 추가 옵션을 얻을 수 있습니다( extract files (개발용), update plugin (쉬운 업데이트용), 웹사이트( for easy community organization )로 이동) 및 지정된 '컨테이너'( extends "[path-to-addon-tar]://ClassName" ) 내의 클래스 참조

이 문제에 대해 2센트만 투자하면 생각하는 방식에도 약간의 결함이 있다고 확신하지만 흥미로운 솔루션이 될 수 있으며 또한 유지 관리 필요성을 줄이는 적절한 방법이 될 수 있습니다 고도팀.

이전 2센트를 기반으로 한 2센트(4마일이 되나요?):
.tar 아카이브는 대부분의 사용자(아헴, Windows 사용자)에게 다소 생소할 수 있으므로 .zip 아카이브를 사용하는 것이 더 나을 수 있습니다.

즉, Godot 자체 .pck 형식으로 플러그인을 배포하는 것은 어떻습니까? 나는 몇 가지 단점(대부분의 응용 프로그램에서 인식되지 않는 것과 같은)이 있지만 더 표준적이고 사용하게 만들 기회가 될 수 있습니다.

.tar 아카이브는 대부분의 사용자(ahem, Windows 사용자)에게 다소 생소할 수 있으므로 .zip 아카이브가 지원 범위가 더 넓기 때문에 .zip 아카이브를 사용하는 것이 더 나을 수 있습니다.

즉, Godot의 자체 .pck 형식으로 플러그인을 배포하는 것은 어떻습니까? 나는 몇 가지 단점(대부분의 응용 프로그램에서 인식되지 않는 것과 같은)이 있지만 더 표준적이고 사용하게 만들 기회가 될 수 있습니다.

물론, 나는 주로 .tar 를 일반 압축 아카이브 유형의 예로 의미했습니다. Godot의 .pck 형식을 사용할 수 있고 사용해야 합니다.

압축을 제공하고 표준 형식이기 때문에 ZIP을 사용하지 않는 이유는 무엇입니까?

@Calinou 동의합니다. .pck 파일을 사용해야 하는 경우, 사람들은 선호하는 패킹 도구를 사용하여 플러그인을 번들로 묶는 것보다 물건을 패킹하기 위해 Godot 엔진을 사용해야 합니다. GitHub는 또한 리포지토리를 .zip 파일로 다운로드하며 지금까지 가장 큰 Godot 플러그인 컬렉션을 보유하고 있습니다.

여기에 동의합니다. 다른 파일 형식을 만들 필요가 없다고 생각합니다. Zip 파일은 매우 잘 작동하는 것 같으며 사람들은 자산 라이브러리를 통해 Godot 인터페이스를 사용하여 설치하거나 수동으로 다운로드할 수 있습니다. .pck 파일은 해당 선택을 허용하지 않습니다.

내 이상적인 세계에서 https://godotengine.org/download 에 두 개의 다운로드 버튼을 갖고 싶습니다.

• reduz 세 가지 요구 사항을 충족하는 세련된 베어 최소 다운로드 및
• 일부 품질 관리를 능가하는 승인되고 정기적으로 유지 관리되는 모든 플러그인이 포함된 한 번의 부풀려진 다운로드, 그래서 나는 그들의 API가 최소 버전의 API만큼 적어도 핵심과 잘 작동한다는 것을 알고 있습니다.

훨씬 더 이상적입니다.
선택하여 혼합합니다. 최소 다운로드 시 최소 버전 + 플러그인 "테마"를 선택할 수 있습니다. 일반적인 사용 사례에 필요한 일반적인 플러그인 모음입니다. (예: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, 2.5D 게임, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackage 등). 따라서 엔진을 시작할 때 필수 플러그인이 이미 설치되어 있고 사용할 준비가 되어 있으며 승인을 받았기 때문에 작동한다는 것을 알고 있습니다.
고급 사용자는 필요하지 않다는 것을 알고 있는 경우 해당 테마 컬렉션 내의 개별 플러그인을 선택 해제하거나, 둘 이상의 플러그인 테마를 결합하거나, 승인된 플러그인 풀에서 테마에 단일 플러그인을 추가하여 사용자 정의 패키지를 만들 수 있습니다.

이상적으로 결과는 https://godotengine.org/download 가 이러한 선택에서 _즉석에서 다운로드 링크 1개를 생성하는 것입니다.

왜요? 이것은 팀이나 그룹으로 일하는 사람들, 여러 대의 컴퓨터에 배포해야 하는 학교의 교사 및 교사, 자습서를 따르고 개인 교사와 동일한 구성을 원하는 사람들을 위한 막대한 시간 절약 및 품질 보증이 될 것이기 때문입니다. 일반적으로 사용되지만 모든 사람이 사용하는 것은 아니므로 개발 팀에서 공식적으로 승인한 플러그인이 하나 있다는 것에 만족합니다. 따라서 가장 지원되는 플러그인을 모른 채 필요한 것을 찾기 위해 며칠 동안 Github와 Reddit을 뒤질 필요가 없습니다. 그들이 찾은 6개 중 옵션.

작은 크기를 필요로 하는 사람들을 위해 한 번의 클릭으로 최소 다운로드가 여전히 존재해야 하며, 크기에 신경 쓰지 않지만 엔진이 할 수 있는 것을 최대 기능으로 보기를 원하는 최대 기능 다운로드가 있어야 합니다.

더 간단한 해결책은 편집기를 처음 실행할 때 추가 [공식 전용?] 플러그인을 설치하도록 요청하는 것입니다. 현재 프로젝트 목록이 비어 있는 경우 AssetLib를 열 수 있는 옵션이 있습니다. Godot를 처음 실행하는 경우 공식 플러그인을 설치하기 위한 대화 팝업이 없는 이유는 무엇입니까?

https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 및 https://github.com/godotengine/ 에 찬성하여 종료

aaronfranke에서 편집: https://github.com/godotengine/godot-proposals/issues/554 도 참조하세요.