Godot: 비 프로그래머를 위한 사용하기 쉬운 게임 디자이너

비주얼 스크립팅은 어느 시점에서 계획됩니다

2015년 1월 14일 수요일 오전 6시 20분에 RyanBram [email protected] 에서 다음과 같이 썼습니다.

안녕하세요 Godot 개발자입니다.

먼저 훌륭한 게임 엔진을 만들어주신 모든 분들께 감사드립니다.
매우 관대한 라이센스로. 당신의 노력은 많은 개발자와
꿈을 이루기 위해 예산이 부족한 학생.

현재 Godot의 위상으로 오픈 소스 게임의 미래는 더 밝습니다.
불행히도 게임 엔진의 대부분의 오픈 소스는 고급
프로그래밍에 대한 지식이 거의 없는 사용자를 염두에 두고 있습니다. 아직 닿을 수 없다
초보 게임 제작자.

제 제안은 사용하기 쉬운 게임 디자이너/편집기를 제공하는 것입니다.
직관적인 GUI와 미리 정의된 클래스를 제공하여 초보 프로그래머의 작업을 용이하게 합니다. 더
프로그래머는 더 많은 사용자를 의미합니다(Godot 사용자는 게임 프로그래머이기 때문에).

나는 이 일을 잘하는 한 게임 엔진을 알고 있다. Ruby에서 작성되었습니다.
원래 일본에서 왔으며 전 세계적으로 영어로 번역되었습니다. RPG라고 합니다
메이커 VX 에이스
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. 에도 불구하고
이름 앞에 RPG라는 단어가 붙은 만큼 non-RPG도 충분히 만들 수 있다.
Ruby Game Scripting System(RGSS)이 내장된 게임.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

다음 목록은 RPG Maker 엔진으로 만든 게임의 예입니다.

1. 알레프(RPG 어드벤처) http://www.pioneervalleygames.com/
2. 약속된 해우 없음(아케이드) http://rpgmaker.net/games/5102/
3. 라가로크 - 베스티아리움 (카드게임) http://rpgmaker.net/games/5808/
4. 공격받는 지구! (슈터) http://rpgmaker.net/games/6561/
5. 테라 (VisualNovel) http://rpgmaker.net/games/3956/
6. 추억의 마나 (액션 RPG)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. 마이호스 - 더 비기닝(호러) http://rpgmaker.net/games/6493/

Godot 엔진이 RPG Maker만큼 인기를 얻었으면 좋겠습니다.
RPG Maker보다 더 많은 기능. 초보자 프로그래머는 사용하기 쉬우면 됩니다.
상호 작용. 성공하면 Okam 스튜디오는 다음 GOG 또는 Steam이 될 수 있습니다.
인디 개발자들이 만든 수천 개의 게임을 퍼블리싱합니다.

안부,라이언

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - 여기에서 아이디어를 평가하지 않으려고 합니다. 아마도 미래에 유용할 수 있지만 시각적 스크립팅이 스크립팅의 효과적인 수단인지 확신할 수 없습니다. 확실하게 말할 수는 없지만 게시한 더 복잡한 게임은 시각적으로가 아니라 텍스트로 작성되었을 가능성이 큽니다. 시각적 스크립팅은 확실히 새로운 사용자가 사용하는 것처럼 보이지만 프로젝트를 올바르게 완료하는 데 필요한 실제 도구를 배우는 데 지연이 있습니다. 그러나 그것은 엔진을 더 접근하기 쉽게 만들 수 있으므로 잘 모르겠습니다.

또한 사용자가 엔진에 내장되어야 하는 것과는 대조적으로 GDScript를 사용하여 Godot에서 시각적 프로그래밍 시스템을 모두 생성할 수 있어야 합니다. 그렇죠? 하지만 확실하지 않습니다.

RPG 제작자는 "모딩" 접근 방식을 더 많이 취하는 것 같고 Godot가 더 RPG 제작자처럼 보이면 다른 종류의 게임을 만들 의도가 있는 사람들이 외면할 것입니다. 그래서 당신이 기본적으로 제안하는 것은 godot를 GameMaker처럼 보이게 만드는 것입니다(이해할 수 있는, 많은 사람들이 게임을 만들고 싶지만 프로그래밍을 모릅니다) 하지만 한계가 있습니다 :)
아마도 Godot는 Leadwerks 및 BGE가 가지고 있는 것과 유사한 Nodal Behavior Graph 편집기를 갖게 될 것입니다. 이것은 GUI 요소와 매우 잘 작동하며 나머지는 가능한 한 쉽고 강력하게 만들기 위해 약간의 연구와 수많은 커뮤니티 피드백이 필요합니다.

@SolarLune , Godot에서 게임을 만들고 맨 위에 편집기를 추가하여 게임을 모든 작은 세부 사항까지 수정할 수 있으며(GraphNode와 나머지 UI를 사용하여 매우 재미있게 플레이할 수 있음) 일부를 작성할 수도 있습니다. 맨 위에 추가 GDscript 코드를 추가하고, 이것이 완전한 게임 게임(RPG, FPS, RTS)을 별도로 제공하고 모든 측면을 조정할 수 있도록 하는 최선의 접근 방식이라고 생각합니다. Godot에서 만든 생성자.

@SolarLune : 비주얼 스크립팅은 다음과 같이 작업할 때 유용합니다.
프로그래머, 그것은 당신이 함께 놀기 위해 블록을 만들 수 있습니다. 이것
Unreal의 접근 방식이 유용합니다. 교체가 불가능할 것 같아요
완전히 프로그래밍하지만(당신이 마조히스트가 아닌 한)
프로그래머가 아닌 사람도 템플릿 블록을 만드는 사람들이 있습니다.

2015년 1월 14일 수요일 오후 4시 23분에 TheoXD [email protected] 에서 다음과 같이 썼습니다.

RPG 제작자는 "Modding" 접근 방식을 더 많이 취하는 것 같습니다.
좀 더 RPG 메이커처럼 보입니다 - 다른 것을 만들고자 하는 의도가 있는 사람들
그런 종류의 게임은 외면할 것입니다. 그래서 당신이 기본적으로 제안하는 것은
Godot를 GameMaker처럼 보이게 하십시오(이해할 수 있는 많은 사람들이
게임을 만들고 싶지만 프로그래밍을 모른다) 하지만 한계가 있습니다 :)
아마도 일어날 일은 Godot가 노드 행동 그래프를 얻게 될 것입니다
Leadwerks 및 BGE가 가지고 있는 것과 유사한 편집기입니다. 이것은 매우 잘 작동합니다.
GUI 요소, 나머지는 약간의 연구와 수많은 커뮤니티가 필요합니다.
피드백을 제공하여 가능한 한 쉽고 강력하게 만듭니다.

@SolarLune https://github.com/SolarLune , 게임 빌드 가능
Godot에서 게임을 모딩할 수 있는 편집기를 맨 위에 추가하세요.
약간의 세부 사항(GraphNode 및 나머지 UI 사용),
맨 위에 추가 GDscript 코드를 작성하는 것이 가장 좋은 방법이라고 생각합니다.
완전한 게임 게임(RPG, FPS, RTS)을 별도로 배송하고 조정을 허용합니다.
그것의 모든 측면.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

글쎄, 내가 아는 바로는, Godot는 이미 노드 기반 UI 코드를 가지고 있습니다.

그러나 최대의 유연성을 원하고 논리 노드를 유용하게 만들려면 GDscript 실행을 위한 스크립트 노드가 필요하다면 GDscript가 계속 갈 길이라는 점에 유의해야 합니다(더 복잡하고 고급스러운 작업의 경우).

현재 UE4는 복잡한 복잡성 없이 블루프린트에서 모든 것을 할 수 없습니다. GameMaker는 최대 유연성을 위해 GML을 사용하기를 기대하고(코드 블록 사용을 통해), BGE는 최대 성능을 위해 Python에서 스크립팅을 요구합니다(코드 브릭 사용을 통해). 빠른 프로토타이핑과 덜 복잡한 논리 상황에 대한 시각적 편집의 유용성을 무시할 수는 없지만 코드에서 할 수 있는 모든 작업을 수행할 수는 없는 경우가 많습니다.

비주얼 스크립팅은 어느 시점에서 계획됩니다

간단하고 긍정적인 답변 감사합니다.

여러분, 이 제안에 댓글을 달아주셔서 감사합니다. 저는 손으로 코딩을 대체할 만큼 쉽고 시각적인 편집기는 결코 충분하지 않다고 믿습니다. 이 기능은 위치를 대체하기 위한 것이 아니라 일반 코딩을 보완하는 기능으로 제안합니다.

RPG Maker VX Ace에서는 대부분의 고급 기능을 손으로 코딩합니다. 고급 프로그래머는 일반적으로 일반 사용자(캐릭터 이름, 스킬, 초상화, 스프라이트 등)가 GUI 편집기에서 값을 편집할 수 있는 고급 모딩 스크립트를 제공합니다. Ruby 게임 스크립팅 시스템은 원숭이 패치를 가능하게 합니다. 이것이 고급 사용자가 제공하는 대부분의 스크립트가 호환성 문제를 피하기 위해 RPG Maker 개발자가 미리 정의한 원래 클래스를 대체하지 않는 이유입니다.

비교하려고:
KDE 및 GNOME 프로젝트는 Linux의 강력한 Shell 명령을 대체할 의도가 없으며 대신 사용 편의성과 Linux의 성능 사이의 격차를 메우려는 프로젝트입니다.

Okam 스튜디오가 Steam과 같다는 생각에 미소가 지어졌습니다... :))

2015년 1월 14일 오후 5시 20분에 RyanBram은 다음과 같이 썼습니다.

안녕하세요 Godot 개발자입니다.

먼저 좋은 게임을 만들어주신 모든 분들께 감사드립니다.
매우 관대한 라이센스를 가진 엔진. 당신의 노력은 많은 사람들에게 도움이 될 것입니다
꿈을 이루기 위해 예산이 부족한 개발자와 학생.

현재 Godot의 위상으로 오픈 소스 게임은 더욱 밝아질 것입니다.
미래. 불행히도 게임 엔진의 대부분의 오픈 소스는 설계되었습니다
프로그래밍에 대한 지식이 거의 없는 고급 사용자를 염두에 두고 있습니다. 그것
아직 초보자 게임 제작자에게 도달 할 수 없습니다.

제 제안은 사용하기 쉬운 게임 디자이너/편집기를 제공하는 것입니다.
직관적인 GUI와 미리 정의된 클래스를 제공하여 초보 프로그래머의 작업을 용이하게 합니다.
더 많은 프로그래머는 더 많은 사용자를 의미합니다(Godot 사용자는 게임 프로그래머이기 때문에).

나는 이 일을 잘하는 한 게임 엔진을 알고 있다. Ruby에서 작성되었습니다.
원래 일본에서 왔으며 전 세계적으로 영어로 번역되었습니다. 그것은
RPG 메이커 VX 에이스
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
이름 앞에 RPG라는 단어가 있음에도 불구하고
RGSS(Ruby Game Scripting System)가 내장되어 RPG가 아닌 게임을 만들 수 있습니다.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

다음 목록은 RPG Maker 엔진으로 만든 게임의 예입니다.

1. 알레프(RPG 어드벤처) http://www.pioneervalleygames.com/
2. 약속된 해우 없음(아케이드) http://rpgmaker.net/games/5102/
3. 라가로크 - 베스티아리움 (카드게임) http://rpgmaker.net/games/5808/
4. 공격받는 지구! (슈터) http://rpgmaker.net/games/6561/
5. 테라 (VisualNovel) http://rpgmaker.net/games/3956/
6. 추억의 마나 (액션 RPG)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. 마이호스 - 더 비기닝(호러) http://rpgmaker.net/games/6493/

Godot 엔진이 RPG Maker만큼 대중화되기를 바랍니다.
RPG Maker보다 훨씬 더 많은 기능. 초보자 프로그래머는
사용하기 쉬운 인터페이스. 성공하면 오캄스튜디오가 차기작이 될지도
인디 개발자들이 만든 수천 개의 게임을 퍼블리싱하는 GOG 또는 Steam.

안부,라이언

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220.

언리얼은 실제로 여러분이 원하든지 간에 프로젝트를 위한 템플릿을 가지고 있습니다.
시각적 스크립팅 또는 전체 스크립팅 유형의 워크플로... 심지어
시각적 편집을 위한 코드 블록은 Visual Studio를 통해 액세스할 수 있으며
맞춤형... :)

2015년 1월 15일 오전 3시 44분에 Juan Linietsky는 다음과 같이 썼습니다.

@SolarLune : 비주얼 스크립팅은 다음과 같이 작업할 때 유용합니다.
프로그래머, 그것은 당신이 함께 놀기 위해 블록을 만들 수 있습니다.
이것
Unreal의 접근 방식이 유용합니다. 교체가 불가능할 것 같아요
완전히 프로그래밍하지만 (마조히스트가 아닌 경우)
프로그래머가 아닌 사람도 템플릿 블록을 만드는 사람들이 있습니다.

2015년 1월 14일 수요일 오후 4시 23분에 TheoXD [email protected] 에서 다음과 같이 썼습니다.

RPG 제작자는 "Modding" 접근 방식을 더 많이 취하는 것 같습니다.
좀 더 RPG 메이커처럼 보입니다 - 다른 것을 만들고자 하는 의도가 있는 사람들
그런 종류의 게임은 외면할 것입니다. 그래서 당신이 기본적으로 제안하는 것은
Godot를 GameMaker처럼 보이게 만듭니다(이해할 수 있는, 많은
사람들
게임을 만들고 싶지만 프로그래밍을 모른다) 하지만 한계가 있습니다 :)
아마도 일어날 일은 Godot가 노드 행동 그래프를 얻게 될 것입니다
Leadwerks 및 BGE가 가지고 있는 것과 유사한 편집기입니다. 이것은 아주 잘 작동합니다
~와 함께
GUI 요소, 나머지는 약간의 연구와 수많은
커뮤니티
피드백을 제공하여 가능한 한 쉽고 강력하게 만듭니다.

@SolarLune https://github.com/SolarLune , 게임 빌드 가능
Godot에서 게임을 모딩할 수 있는 편집기를 맨 위에 추가하세요.
약간의 세부 사항(GraphNode 및 나머지 UI 사용),
허용하다
맨 위에 추가 GDscript 코드를 작성하십시오. 이것이 최고라고 생각합니다.
접근하다,
완전한 게임 게임(RPG, FPS, RTS)을 별도로 배송하고
조정
그것의 모든 측면.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224.

Okam 스튜디오가 Steam과 같다는 생각에 미소가 지어졌습니다... :))

나도 긍정적으로 웃었다.
수천 명의 훌륭한 게임 개발자가 만든 수많은 게임 카탈로그, 공개 및 DRM 무료를 제공하는 Steam과 같은 큰 회사가 있다면 게이머로서 저에게 큰 도움이 될 것이기 때문입니다.

Unreal에는 실제로 여러분이 원하든지 간에 프로젝트용 템플릿이 있습니다.
시각적 스크립팅 또는 전체 스크립팅 유형의 워크플로... 심지어
시각적 편집을 위한 코드 블록은 Visual Studio를 통해 액세스할 수 있으며
맞춤형... :)

Godot에서 사용할 수 있다면 좋습니다.

문안 인사,
라이언

안녕 라이언

Construct 2를 확인 했습니까? 내가 가장 좋아하는 비주얼 게임 디자이너 중 하나이며 사용이 매우 간단합니다.

Godot의 비주얼 프로그래밍은 다소 어려울 것 같습니다. (Godot는 2d와 3d를 모두 수행하므로 범위가 훨씬 더 큽니다.)
또한 엔진의 기본 블록이 모두 제자리에 있을 때 훨씬 나중에 빌드될 가능성이 높습니다.

나는 reduz가 이에 대한 자신의 로드맵을 가지고 있다는 것을 알고 있지만 그가 다른 에디터/엔진 업데이트보다 이것을 우선시하지 않기를 바랍니다. 나는 프로그래머가 아닌 것보다 초보자나 반숙련 프로그래머가 Godot를 사용하기를 원합니다. 하지만 그건 나뿐이야.

안녕 라이언

Construct 2를 확인 했습니까? 내가 가장 좋아하는 비주얼 게임 디자이너 중 하나이며 사용이 매우 간단합니다.

나는 Construct 2를 시도했다. 멋지고 굉장하다. 결과 게임도 크로스 플랫폼이므로 큰 장점입니다. 불행히도 나는 여전히 RPG 게임을 쉽게 만드는 튜토리얼을 찾을 수 없습니다. 지금은 RPG Maker VX Ace를 계속 사용하고 MKXP Project 의 도움으로 내 게임을 많은 플랫폼(Android 포함)으로 이식하려고 할 수 있습니다.

공유해 주셔서 감사합니다. Godot의 비주얼 프로그래밍을 기대합니다.

친애하는,
라이언

시각적 스크립팅 접근 방식의 경우 gdevelop, 멀티미디어 융합 및 구성 2에서 메모를 작성할 수 있습니다. 이러한 엔진은 시각적 스크립팅에 100% 의존합니다. 표현식이 필요한 일부 구문을 배워야 하지만 표현식 편집기를 사용하면 올바른 명령을 매우 쉽게 찾을 수 있습니다. 이 세 가지 엔진을 사용하면 게임 제작자 및 RPG 제작자와 달리 시각적 스크립팅으로 모든 유형의 게임을 자유롭게 만들 수 있습니다.

롤플레잉 메이커는 매우 제한적이기 때문에 좋은 예가 아닙니다.
노드 기반 스크립팅은 공간 사용 측면에서 매우 비효율적입니다. 거대한 노드 그래프를 통해 이동하고 확대 및 축소할 수 있습니다. 그것을 구성 2와 비교하십시오. 모든 것이 명확한 방식으로 배치되어 있고 간결하고 읽기 쉽습니다. 그리고 당신은 승자를 얻었습니다.

BGE는 노드 기반 접근 방식을 논리 블록과 결합하려고 시도하기 때문에 여기에서 아마도 최악의 예일 것입니다. 나는 이것이 왜 나쁜지에 대해 썼습니다.
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

비주얼 스크립팅을 하는 경우 일반 노드 기반 편집기로 절반만 처리하지 마십시오. 더 많은 프로그래머가 아닌 사람들이 엔진을 사용하기를 원하면 구성2 또는 멀티미디어 융합과 같은 더 나은 디자인으로 무언가를 하십시오.

프로그래밍의 보조 방법으로 _only_ 구현된 이와 같은 것을 보고 싶습니다. 코드와 달리 시각적 스크립팅은 생산성을 상당히 저하시킵니다. 또한 디버깅과 리팩토링을 훨씬 더 어렵게 만드는 경향이 있습니다. 내가 생각할 수 있는 한 가지 주요 장점은(프로그래머가 아닌 사람들에게 어필한다는 점을 제외하고) 시각적 스크립팅이 실제 GDScript 코드(IE. 조직). 나는 그것이 다른 방향으로 갈 필요가 있다고 생각하지 않습니다 (IE. GDScript에서 Visual로). 저는 이것이 학교에서 Godot를 수업에 채택할 수 있는 좋은 방법이 될 것이라고 생각합니다.

다음은 접근성 측면에서 가장 중요하다고 생각하는 코드와 시각적 스크립팅의 두 가지 주요 차이점입니다. 이것은 10피트 기둥으로 시각적 스크립팅을 만지지 않을 사람의 말이지만 일부 사람들에게는 그것이 호소력이 있다는 것을 이해합니다. :)

코드: 코드에는 따라야 하는 특정 구문 규칙이 있는 경향이 있습니다. 내 생각에 이것이 비 프로그래머를 끄는 주요 경향이 있다고 생각합니다. 즉. GDScript에서는 if, for, while 루프 등의 함수 선언 끝에 콜론이 있어야 합니다. 제대로 들여쓰기해야 합니다. "var myInteger = 1"과 같은 변수를 선언할 때는 var 키워드를 사용해야 합니다. 대부분의 언어에는 따라야 하는 경향이 있는 3~4개의 기본 구문 규칙이 있는 경향이 있으며 제 생각에는 배우기가 그렇게 어렵지 않습니다. 소수의 작은 스크립트를 작성하면 예술가도 배울 수 있습니다. Ensemble Studios와 함께 Age of Empires의 세 가지 게임을 모두 작업한 두 명의 매우 재능 있는 아티스트와 함께 작업하기 때문에 이렇게 말합니다. 한 사람은 UnityScript로 상당한 양의 코드를 작성했으며 다른 한 사람은 이제 C#으로 수많은 코드를 작성했습니다.

시각: 메서드, 변수, 명령문 등에 대한 드롭다운 메뉴가 표시되는 경향이 있습니다. 그러나 찾고 있는 기능, 속성 등이 무엇인지, 어떤 기능을 하는지, 때로는 어떻게 작동하는지 알아야 합니다. 여전히 문제를 해결해야 합니다. 여전히 변수를 사용하고 스크립트 전체에서 변수가 수행하는 작업을 추적해야 합니다. 코드를 작성하는 것만큼 쉽게 논리적 오류가 발생할 수 있습니다.

실제로 코드를 작성할 수 있다는 것은 궁극적으로 생산성 관점에서 훨씬 더 나은 방법이라고 생각합니다. 그러나 어느 쪽도 당신을 더 나은/나쁜 프로그래머로 만들지 않습니다. 저는 비주얼 스크립팅이 정말 좋은 교육 도구라고 생각하지만, 제대로 구성하는 방법, 특히 문제 해결 방법을 모르거나 배우고 싶다면 비주얼 스크립팅은 조금도 도움이 되지 않습니다.

나는 약간 다른 접근 방식을 취할 것입니다. Godot 편집기는 자체적으로 구동되기 때문에 - 순수한 GDscript에서 유사한 편집기 인터페이스를 쉽게 다시 생성할 수 있습니다.

그래서 제 제안은 생성자를 완전히 godot에서 스크립트로 만들어서 별도로 배송하는 것입니다. 이것은 프로그래머와 비 프로그래머가 다른 도구를 사용하면서 동일한 프로젝트에서 작업할 수 있도록 합니다. 유일한 문제는 프로그래머가 아닌 사람이 두 도구를 동시에 처리해야 하는 경우가 있다는 것입니다. 하지만 이보다 더 나쁜 xD Gridmap 편집기, 셰이더 편집기, 애니메이션 편집기, 코드 편집기는 다시 만들 수 있지만 collada importer, convex 발전기, 수출업자 - 쉽지 않습니다. 여전히 바퀴를 재발명하는 것처럼 느껴지지만 많은 것을 단순화할 수 있습니다.

생성자 코어는 다운로드 가능한 콘텐츠와 물건이 있는 모든 게임 장르(FPS, RTS, GPS....)에 채택될 수 있으며 커뮤니티가 유지 관리된다면 모든 것이 GDscript이기 때문에 기여하기가 더 쉬울 것입니다.
곧 Godot에 비주얼 스크립팅이 있을 것 같지는 않지만, 다른 사람들이 그 위에 생성자를 만드는 것을 막지는 못합니다. 누군가 블렌더 2.5를 가져와 인테리어 디자인 도구를 만드는 것을 보았습니다.

여러 편집자가 있으면 Godot의 개발이 파편화될 수 있다고 생각합니다. gdscript 위에 구축되는 시각적 스크립팅 도구를 위해 잘 설계된 중앙 프로젝트가 하나 있어야 합니다.

게으르지 말고 연구하십시오. 다른 순수 시각적 스크립팅 엔진을 살펴보십시오. 사용자 기반(인기 있는 정도)을 비교하고, 킥스타터, 스팀 또는 기타 플랫폼에서 그들이 얼마나 유연한지 비교하십시오.
그들의 디자인 접근 방식을 살펴보십시오.

그런 다음 종이에 디자인하십시오. 노드 접근 방식을 복사하지 마십시오. 셰이더에 노드를 사용하는 것은 괜찮지만 논리에 도달하면 스크롤하고 알아내려고 하는 지옥 같은 혼란에 빠지게 됩니다.

날 믿어, 나는 모든 것을 시도했다. 유니티의 플레이메이커, 언리얼의 키즈멧, 롤플레잉 메이커, 스텐실 등
Construct2는 멀티미디어 퓨전과 함께 맨 위에 있습니다. 이들은 가장 유연한 접근 방식으로 가장 인기 있는 것입니다. 그리고 둘 다 자산 시장 상점이 있습니다.
그것들은 매우 유연하며 그것들로 만든 게임을 살펴보면 엄청나게 다양한 장르가 있습니다.

이에 대해 더 똑똑해지면 html5 게임을 만드는 시각적 스크립팅 편집기가 이미 있는 또 다른 오픈 소스 프로젝트인 Gdevelop과 팀을 이룰 수 있습니다.
그것의 디자인과 소스 코드를 살펴보십시오.

우리가 이 스레드에 대해 투표를 하게 된다면, 주로 프로그래머들이 투표에 참여할 것이기 때문에 완전히 잘못된 장소가 될 것이라고 확신합니다.

비주얼 스크립팅 시스템은 프로그래머가 아닌 아티스트를 위해 설계되어야 합니다. Unity의 PlayMaker와 같은 기능을 완전히 싫어한다고 불평할 수 있지만 사실은 아티스트가 PlayMaker를 좋아한다는 것입니다. 그래서 리뷰가 거의 2000개에 달하고 별 5개입니다. 투표가 Construct 2의 스크립팅과 더 유사한 것을 가지려면 A) 프로그래머가 GDScript에서 직접 프로그래밍할 수 있고 B) 많은 아티스트가 실제로 도움이 되지 않을 것이라고 믿기 때문에 시각적 스크립팅을 전혀 사용하지 않는 것이 투표입니다. 그것에 의해 즉시 꺼지고 다른 곳으로 이동합니다. 둘 다 코딩을 할 수 있는 두 명의 아티스트 친구가 Construct 2를 보고 있었고 코드를 작성하는 것과 거의 같기 때문에 이 프로그래밍 인터페이스에 재미를 붙였습니다.

시각적 스크립팅 언어는 많은 단어가 아니라 매우 시각적이어야 합니다. 언뜻보기에 코드처럼 보이지 않아야합니다. 그것은 "시각적인 사람들"에 맞춰져야 합니다. 그렇지 않으면 처음부터 만들 의미가 없습니다. 아티스트는 프로그램이 수행하는 작업에 대한 시각적 감각을 제공하기 때문에 노드 그래프에 익숙하고 좋아하는 경향이 있습니다. 다시 말하지만, 나는 노드 그래프를 참을 수 없어 나 자신을 좋아하지 않지만, 나는 프로그래머이고 내 투표는 이 영역에서 계산되어서는 안 됩니다.

나는 그것이 예술가/디자이너를 위해 디자인되어야 한다는 것에 동의합니다.
그러나 단어=복잡성이라는 논리에는 동의하지 않습니다.

누군가를 앉혀서 둘 중 하나를 사용하도록 가르친다면 구성2가 둘 중 더 쉬운 것으로 올 것입니다. 왜요?
노드보다 명확하기 때문입니다. 훨씬 더 명확합니다. 당신은 조건과 행동이 있습니다. 첫 번째는 왼쪽에, 다른 하나는 오른쪽에 놓습니다.
둘 중 하나를 추가하려면 명령을 알 필요가 없습니다. 그것들은 모두 당신이 그것들을 추가할 수 있도록 거기에 나열되어 있습니다. 각각은 시각적 힌트인 아이콘과 함께 제공됩니다.

Playmaker 및 기타 노드 기반 시스템은 훨씬 더 많은 학습이 필요합니다. 노드를 다른 노드에 연결하려면 먼저 두 노드를 연결할 수 있는지 이해해야 하기 때문입니다. 단순히 조건--> 행동이 아닙니다. 노드는 훨씬 더 복잡하고 시각적 힌트가 부족합니다. 플레이메이커에서 아이콘 어디서 보셨나요??
실수를 하기가 훨씬 쉽습니다. 그 안에 있는 논리를 읽는 것은 훨씬 더 어렵습니다.
https://www.scirra.com/tutorials/top
나는 또한 C2가 더 잘 설계된 시각적 프로그래밍 도구이기 때문에 플레이메이커보다 훨씬 더 많은 활성 사용자 커뮤니티를 가지고 있다고 주장하고 싶습니다. 비록 현재로서는 2D 게임으로 제한되어 있지만 말입니다. 웹상의 훨씬 더 많은 수의 비디오 튜토리얼(플레이메이커보다 더 많은 사람들이 사용법을 이해함), 훨씬 더 완성된 프로젝트, 건전한 시장 및 포럼, 그리고 무엇보다도 개발자와 사용자 간의 활발한 커뮤니케이션. 따라서 개발자는 아티스트 사용자가 원하는 것을 알고 있습니다.

Construct 사용자는 이벤트 시트의 스크린샷을 간단히 찍을 수 있으며 어떻게 했는지 하루처럼 명확하게 알 수 있습니다. 포럼으로 이동하여 직접 확인하십시오. 나는 그것이 플레이 메이커보다 훨씬 더 많은 사용자를 가지고 있다고 주장합니다.

나는 노드 기반 시스템에서보다 로직을 설정하는 데 더 적은 작업이 필요하다고 주장합니다.

나는 당신이 그것들을 좋아한다는 것을 알 수 있지만 그것이 프로그래머의 엔진이라고 선언하기 전에 적어도 구조2를 시도하십시오.
그들의 포럼과 사용자 기반을 살펴보십시오. 플레이메이커보다 더 좋은 평판은 아니더라도 그만큼 많이 가지고 있습니다. 이미 성공한 엔진의 플러그인이 아니라 자체적으로 잘 설계되어 좋은 평판을 얻을 수 있었습니다. 모든 아티스트가 사용할 수 있는 순수한 시각적 프로그래밍 도구입니다. 저는 아티스트이고 플레이메이커를 시도했습니다. 구성2보다 어렵습니다. C2의 포럼으로 이동하여 플레이메이커가 사용하기 더 쉽다는 것을 설득시키십시오. 그저 웃기만 하면 됩니다. :디
자신이 프로그래머가 아니십니까? 당신은 나보다 github 프로젝트에 더 많이 기여했습니다. 그것은 당신이 배우기 쉬운 진술을 해서는 안된다는 것을 의미하지 않습니까?

프로그래머의 관점에서 당신의 요점을 이해합니다. 둘 중 하나를 선택해야 한다면 Construct 모델도 선택하겠습니다. 그러나 내가 말했듯이 GitHub 메일링 리스트를 읽는 모든 사람들은 아닐지라도 대부분의 사람들이 프로그래머이기 때문에 이것은 이러한 결정을 내리기에 최악의 장소입니다.

내 경력의 대부분을 프로그래머 주변에서 보낸 것보다 아티스트와 함께 보냈습니다. 지난 18년 동안 두 가지를 모두 정기적으로 해왔지만(두 가지 모두에 열정적이었습니다) 저는 전문적으로 프로그래머가 되기 전에 전문적으로 예술가였습니다. 학위가 있어도 상관 없습니다. 학위는 디지털 애니메이션 및 시각 효과입니다. 내가 아는 한, 내가 작업한 광고는 캔자스시티에서 몇 년이 지난 후에도 여전히 재생됩니다. 나는 Hallmark, Sprint, Radio Shack, Honda 및 내가 잊어버릴 가능성이 있는 몇 가지 다른 사람들을 위한 장면을 작업했습니다. 나는 또한 Bruce Branit와 함께 "World Builder"에서 꽤 많은 장면을 작업하는 데 많은 재미를 느꼈습니다.

https://www.youtube.com/watch?v=QP3YywgRx5A
크레딧의 Nathan Warden은 나입니다.

자랑하려고 이 말을 하는 것이 아니라 요점을 알리기 위해 이 말을 하는 것입니다. 틀릴 수도 있지만, 많은 시간을 아티스트들과 함께 해온 아티스트로서 아티스트들이 무엇을 좋아하는지 알 것 같아요. 그들은 생성자와 같은 것을 별로 좋아하지 않는 경향이 있습니다. 그들은 겁을 먹고 완전히 다른 앱을 선택하는 경향이 있습니다. 아티스트는 일반적으로 프로그래머와 매우 다른 마음가짐을 가지고 있습니다. 마치 내가 친구 Erik에게 가르치려고 하는 기술적인 것에 대해 이야기할 때 그의 입에서 이런 말이 꽤 자주 나오는 것과 같습니다. 시각적으로 벽에 대고 말하는 것이 좋습니다."

아티스트가 선형 셰이더 시스템과 달리 노드 기반 셰이더 그래프와 같은 것을 즐기는 데는 이유가 있습니다. 그들은 무슨 일이 일어나고 있는지 시각화할 수 있습니다. 아티스트가 자신이 좋아하는 3D 응용 프로그램에 선형 셰이더 시스템이 없다고 불평하는 것을 본 적이 없지만 노드 기반 셰이더 시스템이 없을 때 정기적으로 불평합니다.

아티스트가 After Effects보다 Fusion과 같은 앱을 선호하는 데에는 이유가 있습니다. 거의 모든 경우에 더 시각적이기 때문에 선형을 기반으로 하는 노드를 선택합니다.

따라서 노드 기반 시스템이 아티스트에게 어필하는 2가지 이유:

1) 시각적으로 훨씬 더 매력적으로 보입니다.
2) 이미 익숙한 디자인 패러다임에 맞습니다. IE 셰이딩 및 합성

그것은 정말로 그것이 오는 것입니다. 아티스트가 한 번 살펴보고 다른 게임 엔진이 노드 기반 프로그래밍을 가지고 있기 때문에 다음 게임 엔진으로 넘어가려고 한다면 Godot는 시각적 스크립팅이 전혀 없어야 합니다. 왜냐하면 아마도 소수의 사람들 이상이 없을 것이기 때문입니다 누가 그것을 사용할 것이며 그것은 그 시점부터 더 많은 코드 유지 관리를 의미합니다.

Construct2가 무엇인지 확실히 알고 있습니까? 당신은 그 이름의 철자조차 정확하지 않습니다.
"생성자"라고 하지 않습니다.

"언뜻 보기에 코드처럼 보이지 않아야 합니다."

어떻게 보이는가보다 얼마나 명확한가가 더 중요합니다. 로직이 하는 일의 명확성은 에디터가 언뜻 보기에 어떻게 보이는지보다 더 중요합니다. Construct2는 코드처럼 보이지 않습니다. 텍스트는 일반 영어로 작성되었으며 Action 또는 Condition이 하는 일을 명확하게 알 수 있습니다. C2를 사용하는 사람들은 대부분 시각적인 사람들이기도 합니다.

이벤트 시트는 항상 노드에 대해 승리합니다. 더 적은 패닝으로 화면에 더 많은 정보를 담을 수 있습니다. 로직이 하는 일을 더 명확하게 알 수 있습니다. 그리고 시각적 단서(아이콘)는 아티스트의 눈으로 훨씬 쉽게 찾을 수 있습니다.
노드에는 아이콘이 없고 텍스트의 거대한 제한이 있습니다.
따라서 많은 경우에 노드는 크기가 얼마나 제한되어 있는지 명확하게 설명하지도 않습니다. 디자인이 일반 영어 대신 모호한 용어를 사용하도록 강요합니다.

또 다른 점:
이벤트 시트는 위에서 아래로 읽고 실행됩니다. 이것은 명백하고 예측 가능합니다.
노드 네트워크를 사용하면 눈이 모든 곳을 여행하고 분기로 나뉩니다. 점점 복잡해집니다.

실제 사용자 경험이 아닌 첫눈에 대한 3인칭 의견 이야기가 여기에 무게를 실어서는 안 됩니다. 나도 시각적인 사람이지만 이미 많은 시각적 스크립팅 엔진을 사용해 본 사람입니다. 사람들이 한동안 실제 엔진을 사용하지 않고 논쟁을 벌이는 것을 보는 것은 목이 절대적으로 아픈 일입니다. 예를 들어 작은 프로젝트에서 말입니다.

나는 Godot의 디자이너/개발자/비주얼 사람들에게 이러한 엔진을 소규모 프로젝트에서 실제로 시도해보고 결론을 내리길 촉구합니다. 이러한 제3자 이야기로 충분합니다. 우리는 연구에 대한 실습과 하나가 다른 것보다 나은 이유에 대한 논리적으로 진술된 사례가 필요합니다. 믿거 나 말거나 시각적 인 사람들에게도 상식이 있습니다.

주제를 벗어:
Fusion vs Aftereffects의 예에서 사람들은 합성에 노드 기반 접근 방식을 선호합니다. 레이어를 사용하면 동일한 효과가 여러 레이어에 복제될 수 있는 복잡한 장면에서 매우 번거로울 수 있기 때문입니다. 노드를 사용하면 합성 측면에서 더 많은 유연성을 가질 수 있으며 하나의 효과를 여러 레이어에 연결할 수 있습니다. 그러나 노드는 레이어보다 복잡합니다.

나는 거의 모든 점에서 당신의 의견에 동의하지만, 그 점은 여전히 ​​프로그래머의 관점에서 나온 것입니다. 하루 종일 비주얼 스크립팅 시스템을 사용해야 한다면 일반 코드와 가장 유사한 시스템을 선택하겠습니다. 그래서 저는 code.org를 사용하여 프로그래밍하는 방법을 배우고 싶어하는 아이들을 가르치는 것을 좋아합니다. 나는 정말 스타일의 열렬한 팬입니다. 프로그래밍 방법을 "원하는" 사람들을 가르치는 데 좋습니다.

그리고 예, 나는 Construct가 틀렸다고 말했습니다. 죄송합니다. 아니요, 개인적으로 사용하지 않았습니다. 그러나 그것이 사용하는 스크립팅 패러다임은 상상의 여지없이 새로운 개념이 아니기 때문에 중요하지 않습니다. 따라서 내 주장은 Construct 자체에 대한 것도 아닙니다. 프로그래머가 아닌 아티스트와 관련된 스크립팅 스타일에 관한 것입니다.

노드 기반 시스템에서는 각 노드에 포함된 여러 조건과 이벤트 및 기능을 가질 수 있습니다. 그런 다음 노드 이름을 입력과 같이 지정할 수 있습니다. 그 안에는 모든 조이스틱 입력이 포함되며 사용자는 사용할 이벤트를 알려줍니다. 즉. "화재"와 같은 이벤트를 지정합니다. 해당 이벤트는 연결한 노드로 전환을 일으킬 것입니다.

다음은 단순히 발사를 처리할 수 있는 무기에 대한 간단한 예입니다. 단순하지만 강력하며 코드처럼 보이지 않습니다.

마지막으로, 블록 기반 스크립팅이나 노드 기반 스크립팅 모두 인터페이스 관점에서 꽤 좋아 보이도록 만들 수 있으므로 그 점을 논하는 데 시간을 낭비하지 않을 것입니다.

그러나 "언뜻보기에 코드처럼 보이지 않아야합니다."라고 말했을 때. 많은 예술가들은 무기한의 시간 동안 매일 하루 종일 무엇을 볼 것인지에 대해 관심을 갖습니다. 매력적이지 않거나 위협적으로 보이면 전체 앱을 거부합니다. 블록 기반의 룩은 전형적인 아티스트에게 위협적이고 혼란스러워 보입니다. 프로그래머를 위한 것 같고 그렇습니다.

@blurymind ,

그래프 노드는 실제로 개념적 UML에서 나왔습니다. 프로그래밍하지 않는 청중(프로젝트 관리자, 소비자, 아티스트)이 이해할 수 있는 방식으로 코드를 그래픽으로 표현합니다. 이것이 UE4/Unity가 사용하는 것입니다. 업계의 모든 사람들이 알고 있는 사실입니다. 생성자는 일반적으로 다른 접근 방식을 취하며 이 접근 방식이 얼마나 좋은지는 이를 사용하는 사용자 수로 정의되지 않습니다.

항상 학습 곡선이 어디에나 있으며 Construct2도 예외는 아닙니다. 그러나 주장을 뒷받침하지 않고 C2 항목을 Godot에 강제로 넣지 맙시다. 이벤트 시트는 게임이 복잡할수록 길어지고 결국 그래프 노드보다 더 많은 공간을 낭비하게 됩니다. "작업 추가" 버튼에만 자체 행이 있습니다. 기본적으로 프로그래머가 코드 블록을 해석하는 방법입니다. 그래서 나쁘지 않습니다.

나는 개인적으로 왜 우리가 둘 다 가질 수 없는지 이해하지 못하지만 개발자들은 이미 충분히 할 수 있으므로 조만간 일어나지 않을 것입니다. 이것이 내가 프로그래머와 협력하여 프로그래머가 아닌 사람들이 주도하는 더 빠르게 발전할 다른 접근 방식을 제안한 이유입니다.

다음은 노드당 둘 이상의 이벤트를 가질 수 있음을 보여주는 더 나은 예입니다. 또한 각 노드(또는 상태)는 차단되지 않으므로 다른 노드 그래프를 동시에 실행할 수 있습니다.

하지만 여러분의 스크린샷을 보면 그 논리가 무엇을 하는지 전혀 모릅니다. "firePrimary"와 "fireSecondary"가 도대체 ​​뭔가요??
이제 내가 건설2에 대해 게시한 스크린샷으로 스크롤합니다.
구성 2에서 왼쪽의 조건은 ""R"을 눌렀을 때" 또는 짧은 일반 영어로 표시됩니다. 옆에 키보드 아이콘이 있습니다!

예술가에게 둘 다 보여주고 어느 것이 더 명확한지 물어보십시오.

좀 더 정교한 노드 설정도 보여주세요 :) C2 스크린샷은 전체 게임 로직을 보여줍니다. 당신의 이벤트는 단 하나입니다. 노드가 있는 하나의 스크린샷에 동일한 논리를 맞출 수 있습니까? 나는 그렇게 생각하지 않는다.

노드 예제가 정보를 가리고 있음을 참조하십시오.
노드 내부에 무엇이 설정되어 있는지 보려면 노드를 선택해야 합니다.
그것은 인간의 언어가 아닌 모호한 프로그래머 용어를 사용하고 있습니다("이벤트 보내기", "결과 저장"이 도대체 무엇입니까?).
Construct2는 모든 것을 한 곳에서 보여주며 프로그래머가 아닌 사람들도 이해할 수 있습니다. 비주얼 프로그래밍의 요점은 용어를 배울 필요를 없애는 것입니다.

저는 프로그래머가 아닙니다. 실제 코드를 작성한 경험이 없습니다. 그러나 나는 construct2로 게임을 쉽게 만들 수 있고 노드를 사용하는 것은 완전한 게임에 관해서는 훨씬 더 어렵습니다.

나는 모든 사람들이 이미 잘하는 방법을 알고 있는 것에 항상 투표할 것이라는 점을 이해합니다. 그러나 당신이 인정한 것처럼 당신은 프로그래머이고 실제로 C2를 사용한 적이 없습니다. 그리고 나는 노드와 C2 접근 방식을 모두 사용한 코딩 경험이 없는 아티스트라는 진술을 유지합니다.

나는 왜 하나를 다른 것보다 사용해야 하는지에 대한 좋은 논리적 논거를 제공하고 있습니다.
"노드가 더 시각적입니다" 및 "언리얼이 노드를 사용합니다"와 같은 진술을 제공하고 있습니다. 의견이 분분한 발언들입니다. 그리고 둘 다 프로그래머임을 인정합니다.

내가 내 주장을 지지하지 않는다는 것은 당신이 구성2를 조사하거나 노드에 대한 대안으로 디자인을 고려하고 싶지 않다는 확인에 불과합니다. 당신을 다른 방식으로 설득하는 것은 슬프게도 내 시간 낭비입니다.

@TheoXD
내가 당신을 올바르게 읽고 있다면 나는 당신의 말에 전적으로 동의합니다. 별도의 플러그인/모듈로 둘 다 있으면 좋을 것입니다. 따라서 아래에는 실제 GDScript가 있지만 원하는 것을 사용하여 시각화할 수 있습니다. 나는 이것이 가능하다고 생각한다. 노드 기반 접근 방식은 노드를 분리하기 위해 특수 주석과 같은 플래그가 필요할 수 있지만(IE. #node name="Input" 및 #endnode), 노드 그래프로 시작하면 자동이 되기 때문에 그렇게 큰 문제는 아닙니다. 나는 블록 접근 방식이 직선적일 것이라고 생각한다.

그런 의미였나요?

위에서 말했듯이 프로그래밍 교육에 정말 잘 작동하는 block/Construct/code.org 방법이 정말 마음에 듭니다. 프로그래밍을 필요악으로 보는 사람들에게 적합하지 않다고 생각합니다.

@blurymind
이해가 안되는 이유는 익숙하지 않기 때문입니다. 내가 위의 Construct 이미지를 볼 때 나는 그것이 나쁘기 때문이 아니라 내가 그것에 익숙하지 않기 때문에 무슨 일이 일어나고 있는지 전혀 단서가 없습니다.

노드를 클릭할 때까지 노드 아래에 있는 것을 볼 수 없는 한, 노드를 설정하고 나면 이미 알고 있는 것을 샅샅이 뒤져봐야 진정한 의미가 없습니다. 나는 이미 왼쪽 및 오른쪽 클릭이 있고 기본 및 보조 탄약을 발사한다는 것을 알고 있습니다. 나는 이미 1차 및 2차 화재 노드가 하는 일을 알고 있습니다. 만든 이후로 변한게 없는데 왜 볼때마다 디테일을 봐야 하지? 따라서 이제 기본 논리는 어수선합니다. 이것이 노드가 아티스트와 비프로그래머에게 더 친숙한 또 다른 이유입니다. 특정 논리를 보다 일반적인 덩어리로 나눌 수 있습니다. 그래야 큰 그림을 볼 수 있고 절대적으로 필요한 경우에만 세부 사항에 대해 걱정할 수 있습니다.

지금 실제 퍼블리싱된 모바일 게임을 위한 실제 프로젝트를 보고 있는데 거의 모든 노드 그래프가 기껏해야 2~4노드여서 평소에 정교한 설정이 필요 없을 때 더 정교한 설정을 보여드리기가 어렵습니다.

자세히 알고 싶다면 프로그래머가 아닌 사람이 작성한 동일한 앱에서 가져온 것입니다. 이것은 게임에서 가장 복잡한 그래프 중 하나입니다. 메인 플레이어의 움직임을 제어합니다.

(블록으로 할 수 없는 또 다른 것은 Samus의 배처럼 보이게 만드는 것입니다. 하하)

아무런 안내도 없이 Construct2 이미지를 한 화면에 올리고 위의 노드 그래프를 다른 화면에 놓고 아내(프로그래머는 아님)에게 "꼭 사용해야 한다면 어느 것을 사용하시겠습니까? 맨날?"이라고 말하며 노드 그래프를 가리키며 "이거"라고 말했다. 그것이 결정적인 것은 아니지만 덜 위협적이라는 사실은 그녀가 그것을 배우게 할 기회가 훨씬 더 많다는 것을 의미합니다. 그것이 위협적으로 보이면 내가 그녀에게 기본 사항을 배우도록 앉히기도 전에 그녀의 두뇌를 차단할 수도 있습니다.

그를 어느 쪽으로 밀어붙이지 않고 어제 거의 20년 동안 게임 업계에 종사하고 있는 (그리고 Construct2를 사용한) 내 아티스트 친구(3개의 Age of Empires 게임을 모두 작업한 동일한 사람)에게도 물어봤습니다. 그는 다른 아티스트들이 선호할 것이라고 생각하는 것과 노드 그래프에 대해서도 말했습니다.

그나저나 토론은 정말 재밌게 하고 있는데 죽은 말을 때리는 건 의미가 없잖아요, 하하 :)

네 저도 즐깁니다. 나쁜 감정은 없습니다 :)

굉장한 Samus Ship btw. 더 많은 사진을 게시할수록 노드가 분기되어 미친 방향으로 갈 수 있기 때문에 시각적으로 따라가기가 더 어렵다는 제 주장을 더 많이 지지하게 됩니다.
나에게 블록 사이에 선과 화살표를 따라야 하는 추가 복잡성은 항상 추가 작업처럼 느껴졌습니다. 요즘 노드들에게 또 다른 시도를 해봐야 할 것 같습니다. 그것이 Godot가 향할 곳이라면.

다시 한 번 당신은 증거로 뒷받침되지 않는 3인칭 이야기를 우리에게 제공하고 있습니다. 친구를 여기로 데려와 그가 다른 사람보다 선호하는 이유를 알려주십시오. :)
그러면 더 강력한 경우가 있을 것입니다. 나는 지금까지 노드가 더 간단하다는 논제를 뒷받침하는 논리적으로 제정신이 아닌 점을 얻지 못했습니다.

네, 많은 정보를 숨기고 있기 때문에 언뜻 보기에는 덜 위협적으로 보입니다. 귀하의 예는 내가 게시한 스크린샷에 표시된 것보다 훨씬 간단합니다. 이것은 오해의 소지가 있습니다.
다음은 C2에서 플랫포머용 로직을 설정하는 방법을 보여주는 비디오입니다.
https://www.youtube.com/watch?v=5RlSmkSbleI
처음 1분 ​​건너뛰기 :P

사과를 오렌지와 비교하지 말자.
Code.org는 Construct2와 근본적으로 다른 접근 방식입니다. Stencil과 더 비슷하게 생겼고 노드의 단점 중 하나가 있습니다. 조건과 작업이 명확하게 구분되지 않아 무엇에 연결할 수 있는지 파악하기가 더 어렵습니다. 잘 설계된 시각적 프로그래밍 도구(멀티미디어 퓨전, 구성2, 게임 개발)는 모두 사용자를 위해 작업과 조건을 명확하게 구분합니다. 이것은 당신이 필요로 하는 것을 추측하고 적시에 그것을 보여주는 소프트웨어에 의해 당신을 위해 조직되기 때문에 로직을 훨씬 쉽게 구축할 수 있게 합니다. 또한 어리석은 실수를 저지르는 것을 방지합니다.

nodes/stenyl/code.org를 사용하면 어떤 부분이 조건이고 어떤 부분이 작업인지 파악해야 합니다. 조건을 올바르게 설정하려면 더 많은 노력이 필요합니다. 노드에서 어떤 유형의 정보가 나오나요? 조건을 설정하는 데 더 많은 노드가 필요합니다. 노드를 연결하는 방법을 더 많이 학습해야 합니다.
자, 당신의 연구를하고 실제로 조금 다른 도구를 사용합니다. 노드가 아닌 모든 항목을 더 많이 보는 것은 도움이 되지 않습니다.

@blurymind , 귀하의 사례는 지금까지 Construct2를 사용하는 사용자의 수로 뒷받침됩니다. 이는 일반적으로 소프트웨어의 비즈니스 모델과 마케팅에 얼마나 능숙한가의 결과입니다. 개인적인 선호도(당신의 논리적인 주장)는 C2 워크플로를 Godot로 강제하기에는 충분하지 않습니다. 하지만 좋은 참고 자료입니다.

종이나 칠판에 게임(객체-객체 관계)을 구축하는 방법을 누군가에게 보여 준다면 어떻게 보여줄 것입니까? 이벤트 트리를 작성하여? 아니요. 노드와 선이 있는 개념적 보기를 그린 다음 이를 클래스로 생각하고 함수, 멤버를 추가합니다.
나는 이벤트 테이블이 프로그래머에 의해서만 해석되는 코드처럼 보이고 사용자가 발전하면서 실제 프로그래밍을 배우고 싶게 만들 수 있다는 데 동의합니다. 나는 그것이 약간의 용어와 학습 곡선을 가지고 있다는 것을 알아차렸고, 당신은 그것을 부정할 수 없습니다. 그러나 모양 인식 및 개체 그룹화는 실제로 실제입니다. 나는 데이터 시각화에 대한 과정을 공부하고 그것이 얼마나 지루할 수 있는지를 제외하고는 실제로 좋은 포인트가 됩니다.

이 문제에 대한 100개 이상의 댓글 점수를 보고 싶은 만큼 개발자는 모든 내용을 읽지 않을 것입니다. 우리 각자가 할 수 있는 최선은 제안서가 포함된 PDF를 만들고 메일링 리스트에서 공유하는 것입니다. 왜 우리는 이벤트 트리의 형태로 표현될 수 있는 서로 다른 추상화 수준, 그래프 노드를 최상위 수준으로 가질 수 없는지 모르겠습니다. 이것이 효과가 있다면 타협할 필요가 없을 것입니다.

" @blurymind -- || -- 그리고 당신 둘 다 프로그래머임을 인정합니다." - 나는 스스로를 프로그래머라고 생각하지 않고 예술도 하고 있습니다. 나는 객관적인 관점에서 사물을 보기 위해 내 경험을 사용합니다.

놓쳤는지 모르겠지만 저는 프로그래머일 뿐만 아니라 전문 아티스트이기도 합니다. 나는 대부분의 프로그래머가 잠시 동안 예술에 뛰어들면 정말 도움이 될 것이라고 생각합니다. 그것은 특정 프로그래밍을 훨씬 더 의미있게 만들고 프로그래머/아티스트 경쟁을 연결하는 데 도움이 됩니다. 하하 :) 이것이 더 이상적이며 대부분의 사람들에게 그다지 실용적이지 않다는 것을 압니다.

다음은 내 작업 중 일부에 대한 링크입니다(크레딧에서 Nathan Warden 검색).

World Builder(샷의 절반 정도 참여)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (대부분의 장면에 참여)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (산타와 함께한 세 번째 샷)
https://www.youtube.com/watch?v=biqBq3_Whqk

여기 내 Louie 건물의 렌더링이 있습니다. World Builder를 보시면 제가 그 작품에서 발췌하여 영화에 삽입한 일부 작품을 볼 수 있을 것입니다.

그리고 여기에 Stephen King의 Christine을 스매싱하는 Terminator 1 스타일 HK Tank의 미완성 렌더링이 있습니다. 두 모델 모두 제가 작업한 것이지만 다른 것은 촬영에 포함되지 않은 것 같습니다.

그리고 내가 이름을 댈 수 있는 것이 더 많지만 요점이 만들어졌다고 생각합니다. :)

글쎄, 그것들은 놀라운 스틸입니다. 그러나 다시 당신은 자신에게 더 많은 권위를 주기 위해 이것을 하고 있습니다. 이것은 노드가 이벤트 시트보다 낫다는 생각을 논리적으로 지원하는 데 도움이 되지 않습니다. :)

노드를 사용하면 시각적 프로그래밍을 사용하는 다른 빌어먹을 3D 게임 엔진과 같을 것입니다.

나는 이것이 여러 가지 이유로 좋은 아이디어가 아니라고 생각합니다.

-최근 Unreal은 엔진을 무료로 만들었습니다. 또한 멀티플랫폼이기도 합니다. BGE/Godot보다 훨씬 더 성숙한 엔진입니다. 따라서 시각적 프로그래밍에 대한 접근 방식을 복사할 때 그들과 직접 경쟁하게 됩니다.

-노드는 로직 시트보다 화면 효율성이 훨씬 떨어집니다. 읽기/따르기가 더 어렵습니다.

-Scirra는 구성3이 다중 플랫폼이 될 것이라고 발표했습니다. 편집기는 Windows, Linux 및 Mac에서 작동합니다.
그러나 그들은 오픈 소스가 아닙니다.
https://www.construct3.com/

이것은 scirra 커뮤니티에서 댓글의 물결을 만들었습니다. 많은 사용자들은 시각적 프로그래밍 없이도 Godot가 제공할 수 있는 많은 것들을 원합니다:
- html5 컨테이너 대신 기본 exe 파일 - 더 나은 성능을 위해
- 3D 게임 개발 지원, 구성에서 이벤트 시트 스타일을 사용하여 프로그래밍:
https://www.scirra.com/forum/construct-3_t90881

그들이 C2 내부의 2D 도구와 같이 간단하고 이해하기 쉬운 3D 편집기를 만든다면 나는 그것을 완전히 사용할 것입니다

나는 Unity, Blender, Torque 3D, UDK를 시도했습니다. 왜냐하면 그것들은 더 많이 광고되고 소위 유명한 개발자들이 사용하는 것이기 때문입니다... 그리고 그들은 같은 문제를 공유합니다: 그것들은 사용자 친화적이지 않고(전혀) 당신이 전에 3D 게임 생성 API를 사용한 적이 없습니다... 글쎄, 당신은 3Doomed입니다 (나쁜 농담 ikno)

문제는 기본을 다루고 복잡한 2D 게임을 만들 수 있는 자유를 제공하면 구성이 매우 직관적이라는 것입니다. 동일한 결과를 얻을 수 있는 다양한 경로를 제공합니다(이벤트 시스템이 의미가 있다는 것은 말할 것도 없습니다). 이것은 대부분의 다른 도구가 다루지 못하거나 제대로 다루지 못하는 세부 사항입니다.

그들이 C2를 사용하는 것과 같은 흐름과 느낌으로 3D 엔진을 만든다면; 그럼 시도해보지 않으시겠습니까?

그들은 현재 엄청난 사용자 기반을 가지고 있으며(시각적 프로그래밍을 위한 이벤트 시트 스타일을 좋아하지만 이러한 기능을 원함) 그 중 일부는 다른 엔진으로 이동할 준비가 되어 있습니다. 여기에 Godot가 많은 새로운 인디 개발자를 영입할 수 있는 큰 잠재력이 있습니다. 노드보다 이것을 선호하는 개발자(Unreal 엔진을 사용하지 않는 개발자)는 현재 무료이고 Godot보다 훨씬 더 성숙합니다.

노드 대신 사용한다면 해당 vis 프로그래밍 디자인으로 완전한 3D 게임 개발을 지원하는 최초의 엔진이 될 것입니다. Unreal(무료), Unity(무료 버전 사용 가능)와 경쟁하는 대신 새로운 사용자 기반을 활용하게 됩니다.

글쎄, 그것들은 놀라운 스틸입니다. 그러나 다시 당신은 자신에게 더 많은 권위를 주기 위해 이것을 하고 있습니다.

스틸과 링크는 내 권위의 증거가 아니라 내가 함께 일한 사람들의 증거이며 내가 꾸며낸 것이 아니라는 것입니다. 아바타, 킹콩, 세레니티, 그리고 로스트, 레볼루션 등과 같은 쇼들... 그리고 게임 업계에서 15년 이상 일한 다른 친구들도 있습니다. 모두 선형 시트 기반 워크플로보다 노드 기반 워크플로를 선호합니다. 원하는 경우 논리 시트보다 노드 그래프를 선호한다고 말하는 3-4명의 인용문을 얻을 수 있습니까?

최근 Unreal은 엔진을 무료로 만들었습니다. 또한 멀티플랫폼이기도 합니다. BGE/Godot보다 훨씬 더 성숙한 엔진입니다. 따라서 시각적 프로그래밍에 대한 접근 방식을 복사할 때 그들과 직접 경쟁하게 됩니다.

비주얼 스크립팅 워크플로는 사람들이 Godot를 해당 엔진과 비교할 때 마지막으로 보게 될 것입니다. 그들이 가장 먼저 알아차릴 것은 Unreal이 DirectX 12 및 OpenGL 4를 지원하고 그들의 데모와 예제가 훌륭해 보인다는 것입니다. 그리고 나서 그들은 다른 것들을 보기 시작할 것입니다. Godot가 그 회사들에 대해 가지고 있는 중요한 것은 그것이 FLOSS 소프트웨어이고 그것을 사용하는 모든 사람이 동등하게 소프트웨어의 완전한 소유자라는 것입니다.

노드는 로직 시트보다 화면 효율성이 훨씬 떨어집니다. 읽기/따르기가 더 어렵습니다.

귀하의 진술에 따르면 좋은 노드 기반 설정을 사용하지 않았다는 것이 분명하지만 화면 효율성과 같은 것이 걱정된다면 어쨌든 시각적 스크립팅을 사용해서는 안되며 이미 사용 가능한 실제 스크립팅을 사용해야 합니다. :) 화면 공간 측면에서 시각적 스크립팅이 제공할 수 있는 모든 것이 코드 영역 축소와 같이 일반 스크립팅에서도 수행할 수 있음을 보증합니다.

노드 대신 사용한다면 해당 vis 프로그래밍 디자인으로 완전한 3D 게임 개발을 지원하는 최초의 엔진이 될 것입니다.

고객의 요구에 많은 시간, 돈, 연구를 투자하는 Unreal과 같은 엔진이 그러한 형태의 시각적 스크립팅을 사용하지 않고 대신 노드를 선택하는 데는 이유가 있습니다.

이것에 대한 나의 견해는 모든 것이 의도하는 접근 방식에 달려 있다는 것입니다.
해결.

Game Maker와 같은 액션 블록은 흥미롭지만 더 많은
프로그래밍을 대체하도록 설계되었습니다.

Unreal의 접근 방식은 프로그래밍을 보완하는 것과 비슷하므로
디자이너는 게임에서 스스로 작업할 수 있고 게임에서 작업을 가져갈 수 있습니다.
프로그램 제작자. 이것은 팀(아티스트 및 게임 디자이너)에서 훨씬 더 유용합니다.
잘 사용할 수 있음) 확실히 내가 추가하고 싶은 접근 방식입니다
이 때문에 Godot.

Godot 아키텍처로 인해 추가하기가 매우 쉬울 것이므로
그것은 1.2에서 촬영

2015년 3월 3일 화요일 오후 4시 37분에 Nathan [email protected] 이 다음과 같이 썼습니다.

글쎄요, 멋진 스틸컷입니다. 하지만 다시 한 번 당신은
자신에게 더 많은 권한이 있습니다.

스틸과 링크는 내 권위의 증거가 아니라 내가 가진 사람들의 증거입니다.
와 함께 일했고 나는 단지 그것을 만드는 것이 아닙니다 :) 여기에는 내 일부가 포함됩니다.
당신이 들어봤을 법한 몇몇 영화에서 일한 좋은 친구들
아바타, 킹콩, 세레니티, 로스트, 레볼루션 등의 쇼... 그리고
게임 업계에서 15년 이상 일한 다른 친구들 중
연령. 모두 선형 시트 기반보다 노드 기반 워크플로를 선호합니다.
워크플로. 아마 3~4군데에서 인용문을 들을 수 있을 것입니다.
원하는 경우 논리 시트보다 노드 그래프를 선호합니까?

최근 Unreal은 엔진을 무료로 만들었습니다. 또한 멀티플랫폼이기도 합니다. 이것은
BGE/Godot보다 훨씬 더 성숙한 엔진입니다. 그래서 당신은 그들과 경쟁합니다.
비주얼 프로그래밍에 대한 접근 방식을 복사할 때 직접.

비주얼 스크립팅 워크플로는 사람들이 하게 될 마지막 작업입니다.
Godot를 그 엔진들과 비교할 때 보세요. 그들이 할 첫 번째 일은
Unreal은 DirectX 12 및 OpenGL 4를 지원하며 해당 데모는
그리고 예제가 멋지게 보이면 다른 것들을 살펴보기 시작할 것입니다.
Godot가 그 회사들에 대해 가지고 있는 가장 중요한 것은 그것이 FLOSS라는 것입니다.
소프트웨어를 사용하는 사람은 누구나 동등하게 소프트웨어의 완전한 소유자입니다.
소프트웨어.

노드는 논리 시트보다 화면 효율성이 훨씬 떨어집니다. 그들은 더 어렵습니다
읽기/팔로우.

귀하의 진술에 따르면 좋은 노드를 사용하지 않은 것이 분명하지만
기반 설정, 화면 효율성과 같은 것이 걱정된다면
어쨌든 비주얼 스크립팅을 사용해서는 안 됩니다.
이미 사용 가능한 스크립팅 :)
시각적 스크립팅은 화면 공간 측면에서 일반 스크립팅을 제공할 수 있습니다.
코드 영역 축소와 같은 작업도 수행할 수 있습니다.

노드 대신에 그것을 위해 간다면, 당신은 최초의 엔진이 될 것입니다.
비스 프로그래밍 디자인으로 풀 3D 게임 개발을 지원합니다.

Unreal과 같은 엔진이 많은 시간과 돈을 투자하는 데에는 이유가 있습니다.
고객의 요구 사항에 대한 연구는 이러한 형태로 진행되지 않습니다.
시각적 스크립팅 및 대신 노드를 선택했습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857.

Playmaker에 좋은 시도를 했고 언리얼의 키즈멧/청사진보다 더 마음에 든다고 말해야 합니다.

플레이메이커에서 노드는 작업을 배치하는 일종의 컨테이너와 같습니다. 일부 작업은 다른 노드로 이어질 수 있는 조건 확인입니다.

노드 컨테이너를 직접 만들고 이름을 지정할 수 있기 때문에 그 안의 작업은 예측 가능한 방식으로(위에서 아래로) 실행됩니다. :)

또한 노드 내부에 배치하는 작업은 실제로 시각적 입력이 있는 표준 Unity 스크립트입니다. 따라서 사람들은 자신의 스크립트를 작성하고 사용자 지정 작업으로 추가할 수 있습니다.

플레이메이커를 살펴보고 언리얼보다는 그에 가까운 노드 기반 시스템을 구현해 보세요.
물론 더 적은 수의 노드로 더 많은 작업을 수행할 수 있고 읽기 및 디버그하기 쉽고 예측 가능하다는 이점이 있습니다.

작동 방식에 대한 소개는 다음과 같습니다.
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

매우 유연하며 사용자가 쉽게 게임 기능을 추가하고 공유할 수 있습니다.

흥미로운 토론. 노드와 C2의 이벤트 시트가 아닌 다른 유형/형태의 시각적 스크립팅이지만 퍼즐 조각처럼 서로 맞는 스크립트 블록을 지적하고 싶습니다. 2D 엔진 Stencil에서 사용 http://www.stenyl.com/

MIT 스크래치 기반 http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

Unity에서 개인적으로 사용하는 Blox http://www.plyoung.com/blox/

저는 개인적으로 스크래치 같은 "시각적" 프로그래밍에 확신이 없습니다. 나
프로그래밍과 거의 비슷하다고 생각하십시오.
Unreal이 이 작업을 수행하는 방식은 게임/레벨 디자이너에게 친숙하다고 생각합니다.

2015년 3월 21일 토요일 오후 11시 57분에 todheil [email protected] 에 다음과 같이 썼습니다.

흥미로운 토론. 다른 유형/형태의 시각적 개체를 지적하고 싶을 뿐입니다.
노드 이외의 스크립팅이지만 다음과 같이 서로 맞는 스크립트 블록
퍼즐 조각. 2D 엔진 Stencil에서 사용 http://www.stenyl.com/
[이미지: stencil_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
MIT 스크래치 기반
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(차단)
[이미지: scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
Unity에서 개인적으로 사용하는 Blox http://www.plyoung.com/blox/
[이미지: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001.

_오캄스튜디오_

좋은 지적. 나에게 블록은 코드 라인과 순서도 사이의 중간입니다.

나는 시각적 프로그래밍의 스크래치/스텐실 방식을 좋아하지 않습니다. 그 레이아웃은
건설2 블록과 노드보다 시각적으로 따라가기가 더 어렵습니다. 그것은
말 그대로 퍼즐 조각을 조립하고 문제로 고통받습니다.
어떤 조각이 어디에 맞는지 알아내는 것. 그들은 간단하지 않습니다
함께

2015년 3월 22일 일요일 오전 5시 46분에 todheil [email protected] 에서 다음과 같이 썼습니다.

좋은 지적. 나에게 블록은 코드 라인과 흐름 사이의 중간입니다.
차트.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

좋아, 나는 지금 모든 것을 읽지 않을 것이지만, 이 주제에 대한 나의 2센트만 읽겠습니다.

이벤트 기반 엔진은 프로토타입 및 소규모 게임 프로젝트를 만들기 위해 만들어집니다.
Godot와 같은 엔진은 모든 종류의 프로젝트를 만들기 위해 만들어졌습니다.

그래서 그들은 두 개의 다른 에이프치를 가진 두 개의 다른 것입니다.
다른 통행료

솔직히 말해서 잘 사용하지 못합니다. (이벤트 기반 통행료)

나에게 더 나은 접근 방식은 두 개의 병렬 통행료입니다.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

나는 시각적 프로그래밍의 스크래치/스텐실 방식을 좋아하지 않습니다. 그 레이아웃은
건설2 블록과 노드보다 시각적으로 따라가기가 더 어렵습니다. 그것은
말 그대로 퍼즐 조각을 조립하고 문제로 고통받습니다.
어떤 조각이 어디에 맞는지 알아내는 것. 그들은 간단하지 않습니다
함께

2015년 3월 22일 일요일 오전 5시 46분에 todheil [email protected] 에서 다음과 같이 썼습니다.

좋은 지적. 나에게 블록은 코드 라인과 흐름 사이의 중간입니다.
차트.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

다비드 아기아르 데 아키노 파이바

유용할 수 있는 유일한 것은 통합의 "행동" 시스템입니다.
기본적으로 이것은 무언가를 만드는 스크립트이므로 Godot에서 이것은
노드당 하나 이상의 스크립트를 추가할 수 있는 가능성으로 번역합니다.
물론 복제하기만 하면 노드를 생성할 수 있지만 스크립트는
리소스를 선택한 다음 노드에 로드하고 동작을 추가하면 됩니다(
예: 점프 스크립트)
편집기에서 스크립트 이름 아래 분류된 내보내기를 볼 수 있습니다.

2015-03-26 13:15 GMT-03:00 David Paiva [email protected] :

좋아, 나는 지금 모든 것을 읽지 않을 것이지만, 이 주제에 대한 나의 2센트만 읽겠습니다.

이벤트 기반 엔진은 프로토타입 및 소규모 게임 프로젝트를 만들기 위해 만들어집니다.
Godot와 같은 엔진은 모든 종류의 프로젝트를 만들기 위해 만들어졌습니다.

그래서 그들은 두 개의 다른 에이프치를 가진 두 개의 다른 것입니다.
다른 통행료

솔직히 말해서 잘 사용하지 못합니다.

나에게 더 나은 접근 방식은 두 개의 병렬 통행료입니다.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

나는 시각적 프로그래밍의 스크래치/스텐실 방식을 좋아하지 않습니다. 그 레이아웃은

건설2 블록과 노드보다 시각적으로 따라가기가 더 어렵습니다. 그것은
말 그대로 퍼즐 조각을 조립하고 문제로 고통받습니다.
어떤 조각이 어디에 맞는지 알아내는 것. 그들은 간단하지 않습니다
함께

2015년 3월 22일 일요일 오전 5:46 todheil [email protected]
썼다:

좋은 지적. 나에게 블록은 코드 라인과 흐름 사이의 중간입니다.
차트.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

다비드 아기아르 데 아키노 파이바

다비드 아기아르 데 아키노 파이바

얘들 아! 좋은 토론이 여기에 있습니다 :) 뭔가를 추가하고 싶습니다.

우선 저는 미술 학생이지만 프로그래밍이 취미입니다. 저는 Java, Python 및 (제가 가장 좋아하는) Golang을 압니다. 그러나 내가 코딩하는 방법을 배우기 전에(약 3년 전) "프로그래밍 없이 게임을 만들 수 있다"고 주장하는 거의 모든 단일 프로그램을 시도했습니다. 이러한 주장은 모두 넌센스입니다.

특정 순서 없이 클릭 앤 플레이, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stenyl, BGE 및 기억조차 나지 않는 기타 몇 가지를 시도했습니다. 제 의견은 다음과 같습니다. 코드를 _작성_하지 않고도 게임을 만들 수 있지만 _프로그래밍_ 없이는 게임을 만들 수 없습니다. 이벤트 시트나 노드를 사용하더라도 _프로그래밍의 논리_를 이해해야 합니다. 조건, 이벤트, 변수, 문자열 등이 무엇인지 알아야 합니다. 그래서 프로그래밍 없이 게임을 만드는 것은 불가능합니다. 모든 시각적 코딩 방법은 기존 프로그래밍 언어의 논리를 표현하는 다른 방법일 뿐입니다. 이 모든 주장이 뻔한 것처럼 보일 수도 있지만, 프로그래밍에 대한 모험을 시작할 때 저는 명확하지 않았습니다.

이것으로부터 다음 고려 사항을 따릅니다.

내가 코딩하는 방법을 배우기 전에 찾은 최고의 직관적인 시각적 프로그래밍 언어는 스크래치/스텐실 퍼즐/블록 방식입니다. 이유는 다음과 같습니다.

• 이 솔루션은 기존 프로그래밍에 가장 가깝습니다. 사실 그것은 기본 코드에 대한 구문 설탕과 같은 것입니다(기본적으로 Stencil이 작동하는 방식입니다). 저에게는 더 명확하고 따르거나 넣을 수 없는 복잡한 이벤트 시트나 노드의 그래프보다 다채로운 멋진 코드처럼 보이는 것을 만드는 것이 더 쉽습니다. 함수와 같은 좋은 구조로. 나에게 _이것은_ 엉망이다
  이것은 단지 내 의견임을 기억하십시오

*스크래치/스텐실 블록이 가장 시각적이고 따라하기 쉬운 방법이라고 생각합니다. 그들은 색상을 광범위하게 사용합니다(시각적인 사람들은 색상을 좋아합니다). 노란색 = 조건문 및 루프, 녹색 = 수학, 파란색 = 변수 등을 기억하기 쉽습니다. 또한 실제 코드처럼 보이지만(노드와 대조적으로) 더 친숙합니다.

마지막으로 저는 시각적 프로그래밍이 조만간 우선순위가 되어야 한다고 생각하지 않습니다. 해야 할 중요한 일(전체 로드맵 + 문서)이 많이 있으며 이러한 시스템을 구현하는 것은 빠르고 쉽지 않을 것이라고 생각합니다. Godot는 지금처럼 IMHO가 작동하기 정말 쉽습니다. 아티스트가 게임 개발자와 협력하여 사용할 수 있는 많은 도구(비주얼 셰이더 편집기, 애니메이션 편집기, 타일맵 노드)가 포함되어 있습니다.

쩝. 이 기회를 빌어 모든 Godot 제작자와 기여자에게 감사드립니다. 수고하셨습니다 :+1:

BTW2. 내 영어에 대해 유감입니다. 최선을 다하고 있지만 여전히 어리석은 실수를 저지르고 있습니다.cry:

그것이 construct2이든 blox이든 - 그 노드 그래프보다 나에게 더 좋습니다.

시스템이 노드를 작업(상태로)의 컨테이너로만 사용하는 경우 - Playmaker의 방식대로라면 괜찮을 것입니다.

blox와 construct2의 좋은 점은 편집기가 사용 가능한 모든 조건과 작업을 표시한다는 것입니다. 그것은 당신을 위해 그들을 분리하고 범주에 넣습니다. 이는 비코더가 작업을 수행하는 명령의 이름을 알 필요 없이 즉시 엔진으로 많은 작업을 수행할 수 있도록 하는 프레젠테이션의 극적인 변화입니다.

시각적 프로그래밍에 노드를 사용하는 경우 가장 큰 문제는 이벤트가 실행되는 순서대로 사용자와 통신하는 것입니다. Unity에서 - playmaker와 blox는 모두 이를 매우 깔끔하게 수행합니다.

플레이메이커에서 노드 컨테이너(상태 - 작업 포함) 내부에 작업을 스택합니다. blox에서 - 기능을 포함하는 상태가 있는 곳.

대부분의 Unity 기능에 대한 완전한 액세스를 제공합니다. 이것은 프로그래머가 아닌 사람들에게 정말 좋습니다.
blox는 "plygame"으로 추가 개발되었습니다. 이 애드온에는 blox가 포함된 또 다른 통합 애드온으로, blox가 전체 롤 플레잉 핵 앤 슬래시 스타일 게임을 만들기 위해 액세스할 수 있는 몇 가지 사용자 정의 스크립트가 있습니다.

Blox는 Skrach/Stencil 블록과 동일합니다. 이런 스타일의 프로그래밍을 좋아하는 사람들이 많이 있는 것 같습니다. :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdDIAA7_yjFNcLXM5YOf3WE9k

Godot 개발자들이 시도해 보시기 바랍니다.
Btw Skratch(https://scratch.mit.edu/) 기술은 오픈 소스입니다! 스텐실뿐만 아니라 다른 사람들도 이를 채택하고 있습니다. Google도 이에 대해 많은 관심을 갖고 있습니다.
https://developers.google.com/blockly/

제안 - 두 가지 장점을 모두 경험해 보십시오! 상태 머신용 노드 - 표현식용 blox/skratch/stencil.
이상적인 세계에서는 Playmaker에서와 같이 노드가 상태 컨테이너로 사용됩니다. 그러나 상태 컨테이너에는 사용자가 쉽게 논리를 설정할 수 있도록 하는 레고 시스템과 같은 blox/stenyl/skratch가 있습니다. 그런 식으로 표현식을 작성하는 방법을 배울 필요는 없습니다. 끌어서 놓기만 하면 됩니다.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

iCanScript의 개발자 중 한 명이 VS 자산에 대해 다음과 같이 말했습니다.

iCS2의 기술 발전은 Unity만의 제품이 아닌 것과 분리되어 시장 기회를 크게 증가시킵니다. 최종 비전은 iCS2가 표준 Windows/OSX/iOS/Android 응용 프로그램뿐만 아니라 다른 게임 엔진용 스크립트를 만드는 데 사용할 수 있는 개발 보조 장치가 되는 것입니다.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

노드 엉망 iCanScript가 무엇입니까!

어쨌든 내가 그것을 판단하기 전에 시도해 볼 가치가 있습니다. 누군가 들어갈 수 있을지도 몰라
그것의 개발자와 터치?
Godot에 이익 기회가 있는 시장이 있다면 - 예를 들면
Unity는 - 아마도 Unity 개발자가 자산을 만들도록 끌어들일 것입니다.
역시 갓.

2015년 5월 23일 토요일 오후 4시 24분에 todheil [email protected] 에서 다음과 같이 썼습니다.

iCanScript 개발자 중 한 명이 VS 자산에 대해 다음과 같이 말했습니다.

iCS2의 기술 발전은 Unity 전용에서 분리됩니다.
제품이 크게 >시장 기회를 증가시킵니다. 최종 비전
iCS2는 >스크립트를 만드는 데 사용할 수 있는 개발 보조 도구가 될 것입니다.
다른 게임 엔진 및 표준 >Windows/OSX/iOS/Android용
응용 프로그램.

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104895405.

나는 구성 2의 이벤트 시트를 이해하고 프로그램하기가 정말 쉽다고 생각합니다.

생계를 위해 그래픽을 만드는 데 대부분의 시간을 보내는 아티스트로서 새로운 언어를 배우는 것은 매우 어렵고 시간이 많이 걸립니다. 사람들은 몇 달 만에 배울 수 있다고 말하지만 하루에 2시간만 있으면 처음부터 배우거나 간단한 언어를 사용하여 만들 수 있습니다. 또한 시각적인 사람이 되는 것은 시각적 스크립팅이 더 의미가 있습니다.

학교에서 프로그래밍을 했고 코드를 쉽게 읽고 이해할 수 있지만 작성하는 데 시간이 걸립니다. 나는 또한 더 쉬운 python을 배우려고 노력하고 있지만 그것으로 무언가를 만드는 데 여전히 몇 달이 걸릴 것입니다.

Construct 2의 접근 방식은 간단해 보입니다. 나를 위해 그것은 다음과 같이 보입니다.

1 이벤트: 액션;

2 이벤트: 액션;
: 동작;

기본적으로 프로그래밍되지만 매우 쉽게 이해할 수 있습니다. 그들이 차단 대신 언어만 사용했다면 나는 신경 쓰지 않았을 것입니다. 이 패턴을 사용하면 논리를 만들기 쉽습니다.

노드를 사용하는 것은 일이 퍼지기 시작하고 실제로 코드를 작성하는 데 더 많은 시간을 할애하는 데 더 많은 시간을 할애함에 따라 매우 빠르게 손이 갈 수 있습니다.

따라서 비주얼 스크립팅을 구현하려는 경우 이벤트 시스템을 구축하는 데 매우 진지하게 생각하십시오.

또한 프로그래밍을 선호하는 사람들이 추가 페이로드를 다운로드할 필요가 없도록 비주얼 스크립팅 시스템을 우리 같은 사람들을 위한 다운로드 가능한 확장으로 만들 수 있습니다.

Godot는 훌륭한 게임을 만들기 위해 노력하고 있습니다.

Construct의 접근 방식에 대한 내 문제는 프로그래밍처럼 느껴진다는 것입니다.
그다지 다르지 않은 것 같다
팀 관점에서 저는 Unreal의 청사진 접근 방식을 더 좋아합니다.
프로그래밍에 대해 전혀 모르는 디자이너에게 더 친숙합니다.

2015년 5월 24일 일요일 오전 3시 58분에 whoisda [email protected] 에서 다음과 같이 썼습니다.

컨스트럭트 2의 이벤트 시트는 정말 이해하기 쉽고
프로그램 인.

대부분의 시간을 내 생활을 위한 그래픽을 만드는 데 보내는 아티스트로서,
새로운 언어를 배우는 것은 매우 어렵고 시간이 많이 걸립니다. 사람들은 당신이 할 수 있다고 말합니다
몇 달 만에 배우지만 하루에 단 2시간만
처음부터 배우거나 사용하여 만들 수 있습니다.
간단한 언어. 또한 시각적인 사람이 되면 시각적 스크립팅이
감각.

나는 학교에서 프로그래밍을 했고 코드를 쉽게 읽고 이해할 수 있습니다.
하지만 쓰기에는 시간이 걸립니다. 나는 또한 더 쉬운 python을 배우려고 노력하고있다.
그러나 그것으로 무언가를 만드는 데는 여전히 몇 달이 걸릴 것입니다.

Construct 2의 접근 방식은 간단해 보입니다. 나를 위해 그것은 다음과 같이 보입니다.

1 이벤트: 액션;

2 이벤트: 액션;
: 동작;

기본적으로 프로그래밍되지만 매우 쉽게 이해할 수 있습니다. 만약 그들이
블록 대신 언어만 사용했다면 신경 쓰지 않았을 것입니다. 이것을 사용하여
패턴은 나를 위한 논리를 만들기 쉽습니다.

노드를 사용하면 사물이 퍼지기 시작하고
노드를 찾는 데 더 많은 시간을 보낸 다음 실제로 코딩하는 데 더 많은 시간을 할애합니다.
unity와 playmaker에서 이해).

따라서 시각적 스크립팅을 구현하려는 경우 매우
이벤트 시스템 구축에 대한 진지한 생각.

다운로드 가능한 비주얼 스크립팅 시스템을 생성할 수도 있습니다.
프로그래밍을 선호하는 사람들은 우리와 같은 사람들을 위한 확장 프로그램입니다.
추가 페이로드를 다운로드합니다.

Godot는 훌륭한 게임을 만들기 위해 노력하고 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159.

그러나 당신은 프로그래머의 관점입니다.
코딩.
이 경우 통계를 보는 것이 좋습니다.
구성2가 다른 시각적 프로그래밍보다 가지고 있는 비 프로그래머 사용자
편집자는 스스로 말해야 합니다.

또한 한 스타일의 비주얼 프로그래밍으로 제작된 다양한 게임을 다른 스타일보다 살펴볼 가치가 있습니다.

Unreal은 실제로 kismet에서 수행된 엄청난 수의 프로젝트를 가지고 있습니다 - 그러나 그것은 construct2보다 훨씬 오래된 엔진이고 그 중 많은 부분이 1인칭 슈팅 게임입니다.

2015년 5월 24일 일요일 오전 10시 15분, Juan Linietsky [email protected]
썼다:

Construct의 접근 방식에 대한 내 문제는 프로그래밍처럼 느껴진다는 것입니다.
그다지 다르지 않은 것 같다
팀 관점에서 저는 Unreal의 청사진 접근 방식을 더 좋아합니다.
프로그래밍에 대해 전혀 모르는 디자이너에게 더 친숙합니다.

2015년 5월 24일 일요일 오전 3시 58분에 whoisda [email protected] 에서 다음과 같이 썼습니다.

컨스트럭트 2의 이벤트 시트는 정말 이해하기 쉽고
프로그램 인.

대부분의 시간을 내 생활을 위한 그래픽을 만드는 데 보내는 아티스트로서,
새로운 언어를 배우는 것은 매우 어렵고 시간이 많이 걸립니다. 사람들은 당신을 말한다
~ 할 수있다
몇 달 만에 배우지만 하루에 단 2시간만
처음부터 배우거나 사용하여 만들 수 있습니다.
간단한 언어. 또한 시각적인 사람이 되면 시각적 스크립팅이
감각.

나는 학교에서 프로그래밍을 했고 코드를 쉽게 읽고 이해할 수 있습니다.
하지만 쓰기에는 시간이 걸립니다. 나는 또한 파이썬을 배우려고 노력하고 있습니다.
더 쉽게
그러나 그것으로 무언가를 만드는 데는 여전히 몇 달이 걸릴 것입니다.

Construct 2의 접근 방식은 간단해 보입니다. 나를 위해 그것은 다음과 같이 보입니다.

1 이벤트: 액션;

2 이벤트: 액션;
: 동작;

기본적으로 프로그래밍되지만 매우 쉽게 이해할 수 있습니다. 만약에
그들
블록 대신 언어만 사용했다면 신경 쓰지 않았을 것입니다. 사용
이것
패턴은 나를 위한 논리를 만들기 쉽습니다.

노드를 사용하면 사물이 퍼지기 시작하고
노드를 찾는 데 더 많은 시간을 보낸 다음 실제로 코딩하는 데 더 많은 시간을 할애합니다.
unity와 playmaker에서 이해).

따라서 시각적 스크립팅을 구현하려는 경우 매우
이벤트 시스템 구축에 대한 진지한 생각.

다운로드 가능한 비주얼 스크립팅 시스템을 생성할 수도 있습니다.
프로그래밍을 선호하는 사람들은 우리와 같은 사람들을 위한 확장 프로그램이 없습니다.
에게
추가 페이로드를 다운로드합니다.

Godot는 훌륭한 게임을 만들기 위해 노력하고 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Construct2의 프로그래밍 접근 방식은 다음과 매우 유사합니다.
또한 많은 사용자가 있는 Clickteam 퓨전. 그것의 용이함은
프로그래밍과 비슷하지만 여러 가지:

• 가능한 모든 CONDITIONS가 나열되고 사용자가 선택할 수 있음
  일반 영어로 클릭/드래그하여 추가하는 것은 매우 중요합니다.
  마법의 단어를 배울 필요가 없기 때문입니다. 그들은 단지 드래그 할 수 있습니다
  그들을 드롭.
• 가능한 모든 작업을 나열하고 사용자가 선택할 수 있도록 합니다.
  일반 영어로 클릭/드래그하여 추가 - 이것은 매우 중요합니다.
  마법의 단어를 배울 필요가 없기 때문입니다. 그들은 단지 드래그 할 수 있습니다
  그들을 드롭.
• 설정 및
  행동이나 조건. 당신이 표현을 쓸 때, 에디터가 당신을 도와줍니다
  기존 개체에서 얻을 수 있는 항목의 쉬운 드롭다운 목록을 사용하여
  장면. 이러한 속성에 접근하는 방법을 배울 필요는 없습니다.
  몇 번의 클릭으로 이미 사용할 수 있습니다.

아마도 가장 좋은 점은 프로그래머가 아닌 사람들에게
새로운 프로그래밍을 배우는 학습 곡선이 없는 프로그래밍 이론
언어.

2015년 5월 24일 일요일 오전 10시 17분, Todor Imreorov [email protected]
썼다:

그러나 당신은 프로그래머의 관점입니다. 이미 알고 있는 사람입니다.
코딩하는 방법.
이 경우 통계를 보는 것이 좋습니다.
구성2가 다른 시각적 프로그래밍에 비해 프로그래머가 아닌 사용자
편집자는 스스로 말해야 합니다.

2015년 5월 24일 일요일 오전 10시 15분, Juan Linietsky < [email protected]

썼다:

Construct의 접근 방식에 대한 내 문제는 프로그래밍처럼 느껴진다는 것입니다.
그다지 다르지 않은 것 같다
팀 관점에서 저는 Unreal의 청사진 접근 방식을 더 좋아합니다.
프로그래밍에 대해 전혀 모르는 디자이너에게 더 친숙합니다.

2015년 5월 24일 일요일 오전 3시 58분, whoisda [email protected]
썼다:

컨스트럭트 2의 이벤트 시트는 정말 이해하기 쉽고
프로그램 인.

대부분의 시간을 내 생활을 위한 그래픽을 만드는 데 보내는 아티스트로서,
새로운 언어를 배우는 것은 매우 어렵고 시간이 많이 걸립니다. 사람들은 당신을 말한다
~ 할 수있다
몇 달 만에 배우지만 하루에 단 2시간만
처음부터 배우거나 사용하여 만들 수 있습니다.
간단한 언어. 또한 시각적인 사람이 되면 시각적 스크립팅이
감각.

나는 학교에서 프로그래밍을 했고 코드를 읽고 이해할 수 있습니다.
용이하게
하지만 쓰기에는 시간이 걸립니다. 나는 또한 파이썬을 배우려고 노력하고 있습니다.
더 쉽게
그러나 그것으로 무언가를 만드는 데는 여전히 몇 달이 걸릴 것입니다.

Construct 2의 접근 방식은 간단해 보입니다. 나를 위해 그것은 다음과 같습니다 :

1 이벤트: 액션;

2 이벤트: 액션;
: 동작;

기본적으로 프로그래밍되어 있지만 매우 쉽게 이해할 수 있습니다. 만약에
그들
블록 대신 언어만 사용했다면 신경 쓰지 않았을 것입니다. 사용
이것
패턴은 나를 위한 논리를 만들기 쉽습니다.

노드를 사용하면 사물이 퍼지기 시작하면 매우 빠르게 손이 갈 수 있습니다.
그리고
노드를 찾는 데 더 많은 시간을 보낸 다음 실제로 코딩하는 데 더 많은 시간을 할애합니다.
unity와 playmaker에서 이해).

따라서 시각적 스크립팅을 구현하려는 경우 매우
이벤트 시스템 구축에 대한 진지한 생각.

다운로드 가능한 비주얼 스크립팅 시스템을 생성할 수도 있습니다.
프로그래밍을 선호하는 사람들은 우리와 같은 사람들을 위한 확장 프로그램이 없습니다.
에게
추가 페이로드를 다운로드합니다.

Godot는 훌륭한 게임을 만들기 위해 노력하고 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

또한 복잡한 논리를 코딩하는 방법을 배우고 궁극적으로 코딩을 배울 수 있을 만큼 자신감을 얻고자 하는 디자이너의 관점에서 살펴보십시오. 시스템이 디자이너와 프로그래머 팀에 의해 사용되는 것을 볼 때 어디에서 왔는지 알 수 있습니다. 저는 개인적으로 Godot를 많은 인디 게임 개발자와 같은 프로그래머와 팀이 아닌 단일 사용자로 사용하고 싶습니다. 이벤트 시스템은 관대하고 1000개 이상의 이벤트가 있을 때 그룹을 사용하여 더 체계적으로 느껴집니다.

이것 외에는 노드 시스템에 문제가 없으며 Godot가 현재보다 더 나은 시스템을 만들 수 있다면 나는 그것을 사용할 것입니다.

또한 가능하면 코드 블록/노드를 쉽게 찾을 수 있는 검색 기능을 만드십시오.

configure2/clickteam의 이벤트 시트는 학습할 필요가 없습니다.
구문 - 따라서 사용자는 물건을 어디에 둘지 알 필요가 없습니다.
매우 분명합니다. 왼쪽은 조건, 오른쪽은 작업입니다. 의 순서
이벤트 실행도 매우 분명합니다.
스크래치/스텐실/유니티 블록스의 레고 조각은 그다지 명확하지 않지만 여전히
"iCanScript"에 제시된 노드 악몽보다 훨씬 낫습니다. 봤어?
그들의 비디오 튜토리얼에서. 매우 복잡한 시각적 프로그래밍 디자인입니다.
꽤 가파른 학습 곡선으로. 에게 줘도 그렇게 생각한다.
프로그래머는 그것을 알아내는 데 어려움을 겪을 것입니다

2015년 5월 24일 일요일 오전 10시 33분에 whoisda [email protected] 에서 다음과 같이 썼습니다.

또한 배우고자 하는 디자이너의 입장에서 살펴보세요.
복잡한 논리를 코딩하고 결국 코딩을 배울 수 있을 만큼 자신감을 얻습니다.
나는 당신이 시스템을 사용하는 것을 볼 때 당신이 어디에서 왔는지 알 수 있습니다.
디자이너와 프로그래머 팀. 저는 개인적으로 Godot를 다음과 같이 사용하고 싶습니다.
많은 인디 게임처럼 프로그래머와 팀이 아닌 단일 사용자
개발자. 이벤트 시스템은 관대하고 다음을 사용하여 더 조직적으로 느껴집니다.
1000개 이상의 이벤트가 있을 때 그룹화합니다.

이 외에는 노드 시스템에 문제가 없으며 Godot가 관리한다면
현재보다 더 나은 시스템을 만들겠습니다.
그것.

또한 가능하면 코드 블록/노드를 찾기 위한 검색 기능을 만드십시오.
용이하게.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

그들은 더 이상 Unity 에셋 스토어에서 "icanscript"를 판매하지도 않습니다.
사용 가능한 시각적 프로그래밍 중 하나인 판매 수치를 보십시오.
시스템이 가장 많이 사용되고 있으며 프로젝트가 완료되었습니다.

이 비디오로 당신을 떠날 것입니다:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
클릭팀 퓨전으로 만든 167개의 게임이 있습니다.
프로그래밍 경험.

또한 퓨전으로 만든 성공적인 킥스타터 게임을 살펴보십시오.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

또한 Freddy's의 Five Nights(clickteam fusion에서 제작)도 언급해야 합니다.
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
그 게임은 베스트 셀러입니다. 다음은 몇 가지 수치입니다.
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

비주얼 프로그래밍 프레임워크의 아이디어는 아티스트가 프로그래머 없이도 게임을 만들 수 있도록 하는 것이어야 합니다. 그 과정에서 프로그래밍에 대해 조금 배우게 됩니다.

프로그래머가 여전히 필요한 곳에 하나를 만든다면 - 실제로 시각적 프로그래밍 프레임워크를 만든 것이 아닙니다. - 프로그래머가 디자이너가 사용할 수 있도록 설정할 수 있는 상태 머신을 만든 것입니다. 게임의 핵심 논리. 따라서 여기에 언급된 다른 시각적 프로그래밍 도구만큼 훌륭하고 완전한 것을 만들지는 않을 것입니다. 아티스트가 논리를 설정하고 프로그래밍의 기본 개념을 배우도록 초대하는 것이 아닙니다. 당신은 그것들을 프로그래머에 의존하고 그 개념의 어둠 속에서 유지하고 있습니다.

2015년 5월 24일 일요일 오전 10시 42분, Todor Imreorov [email protected]
썼다:

configure2/clickteam의 이벤트 시트는 학습할 필요가 없습니다.
구문 - 따라서 사용자는 물건을 어디에 둘지 알 필요가 없습니다.
매우 분명합니다. 왼쪽은 조건, 오른쪽은 작업입니다. 의 순서
이벤트 실행도 매우 분명합니다.
스크래치/스텐실/유니티 블록스의 레고 조각은 그다지 명확하지 않지만
"iCanScript"에서 제시된 노드 악몽보다 여전히 훨씬 낫습니다. 했다
당신은 그들의 비디오 자습서를 봅니다. 엄청나게 복잡한 비주얼이다
꽤 가파른 학습 곡선을 가진 프로그래밍 디자인. 라고 생각해도
프로그래머에게 주면 그들은 그것을 알아내는 데 어려움을 겪을 것입니다.

2015년 5월 24일 일요일 오전 10시 33분, whoisda [email protected]
썼다:

하고 싶은 디자이너의 입장에서도 살펴보세요.
복잡한 논리를 코딩하는 법을 배우고 결국에는
암호. 나는 당신이 시스템을 사용할 때 당신이 어디에서 왔는지 알 수 있습니다.
디자이너와 프로그래머 팀. 저는 개인적으로 Godot를 사용하고 싶습니다
많은 인디와 같은 프로그래머와 팀이 아닌 단일 사용자로
게임 개발자. 이벤트 시스템은 관대하고 조직적입니다.
1000개 이상의 이벤트가 있을 때 그룹을 사용합니다.

이 외에는 노드 시스템에 문제가 없으며 Godot가 관리한다면
현재보다 더 나은 시스템을 만들겠습니다.
그것.

또한 가능하면 코드 블록/노드를 찾기 위한 검색 기능을 만드십시오.
용이하게.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

당신이 원하는 방향이 아니라면 다른 게임 엔진에서 훌륭하게 작동하는 시스템을 사용하도록 강요하는 것은 현명하지 않다고 생각합니다.

같은 메모에서 시각적 스크립팅이 구현되는 좀 더 직관적인 방법을 보고 싶습니다. 지저분한 노드를 사용하지 않거나 시간이 걸리는 블록(Android 앱 작성자)을 사용하지 않거나 너무 프로그래밍처럼 보이는 이벤트 시스템(다른 모든 것보다 선호함)을 사용하지 않습니다. 그들 모두의 최고를 취하는 것.

일부 경로를 지우고 일부 숫자를 보기 위해 사용성 디자이너에게 문의할 수 있습니다.

결국 Godot 고유의 방법이 Godot를 한 사람의 초보자가 일주일 만에 첫 번째 게임을 디자인할 수 있게 하고 개발 팀이 AAA 게임을 만들기 위해 함께 협력할 수 있도록 하는 훌륭한 엔진을 만드는 것을 보는 것은 좋을 것입니다.

엔진을 바꾸거나 언어를 배우지 않고도 멋진 게임을 만드는 데 도움이 되는 시스템을 이렇게 자주 보게 되어 기쁩니다.

건배.

노드가 플레이메이커의 노드처럼 수행된다면 신경쓰지 않습니다.
작업 컨테이너(상태).
거기에 있는 노드는 실제로 작업이나 조건을 설정하는 데 사용되지 않습니다.

그러나 "iCanScript"처럼 만들면 완전히 엉망이 됩니다.

1. 이벤트가 어떤 순서로 실행되는지 말하기 어렵습니다.
2. 어떤 노드가 어떤 노드에 연결될 수 있는지 파악하기 어렵습니다.
3. 단일 작업을 설정하는 것보다 많은 노드와 단계가 필요합니다.
   끌어다 놓고 그 안에 표현식을 설정합니다(construct2/clickteam 스타일
4. 구문에 대한 도움을 받는 곳 - 이는 다음을 소개하는 좋은 방법입니다.
   많은 사람이 읽을 필요 없이 프로그래밍을 할 수 있습니다.
   문서 - 드롭다운 메뉴에 모든 것이 있습니다.
   물체).

2015년 5월 24일 일요일 오전 11시 20분에 whoisda [email protected] 에서 다음과 같이 썼습니다.

작동하는 시스템을 사용하도록 강요하는 것은 현명하지 않다고 생각합니다.
그것이 당신이 원하는 방향이 아니라면 다른 게임 엔진에 탁월합니다.
취하고 싶다.

같은 메모에서 시각적으로 더 직관적인 방법을 보고 싶습니다.
스크립팅이 구현됩니다. 지저분한 노드를 사용하거나 시간이 걸리지 않음
블록(Android 앱 작성자) 또는 너무 프로그래밍된 이벤트 시스템(내가
다른 모든 것보다 선호). 그들 모두의 최고를 취하는 것.

일부 경로를 지우고 일부를 살펴보기 위해 사용성 디자이너에게 문의할 수 있습니다.
번호.

결국 Godot만의 고유한 방법으로
1인 초심자 모두 자신의 설계를 가능하게 하는 Godot의 위대한 엔진
일주일 만에 첫 게임과 함께 개발 팀이 협력하여
AAA 게임을 만듭니다.

멋진 게임을 만드는 데 도움이 되는 시스템을 보게 되어 기쁩니다.
엔진을 바꾸지 않고 언어를 배우지 않고 '이렇게 자주.

건배.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083.

나는 Godot를 위한/innovated되는 것과 관련하여 @whoisda 에게 투표합니다. 그러나 1) 노드, 2) 이벤트 시트, 3) 블록의 세 가지 Visual Scripting 학교가 있는 것 같습니다. 이 3개의 노드 중 3D 환경에서 이 분야를 선도하는 것으로 보입니다. 말하자면 나는 스크립팅/프로그래밍이 선형(텍스트, 블록, 이벤트 시트) 또는 수평(노드) 형식에서 벗어나 구조를 사용하여 3D로 프로그램할 것을 제안하는 아이디어를 읽었습니다. 그것이 어떻게 작동할지 확실하지 않지만 매력적으로 들립니다.

언급된 비주얼 스크립팅 학교는 실제로 테스트되었으며
이미 사용자가 있습니다. Playmaker의 디자인과
블럭스 인 유니티.

상태 머신을 생성하기 위한 노드입니다.
각 노드(상태) 내에서 작업을 생성하기 위한 블록 또는 이벤트 시트.

2015년 5월 24일 일요일 오후 1시 56분에 todheil [email protected] 에서 다음과 같이 썼습니다.

나는 @whoisda https://github.com/whoisda에 투표합니다.
Godot를 위해/혁신되고 있습니다. 그러나 세 가지 Visual이 있는 것 같습니다.
스크립팅 학교: 1) 노드, 2) 이벤트 시트, 3) 블록. 이 세 가지 중
노드는 3D 환경에서 이 분야를 선도하는 것 같습니다. 말하자면
스크립팅/프로그래밍 중단을 제안하는 아이디어를 어디선가 읽었습니다.
선형(텍스트, 블록, 이벤트 시트) 또는 수평(노드) 형식 및
구조를 사용하여 3D로 프로그램합니다. 어떻게 작동하는지 확실하지 않지만 소리가 들립니다.
매력적인.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411.

노드와 이벤트를 함께 사용할 수 있다면 좋을 것입니다. 노드는 간단한 논리를 따르면 다른 노드에 연결될 수 있거나 스크립트/블록/이벤트 시트의 컨테이너가 될 수 있는 상태일 수 있습니다. 이렇게 하면 노드가 매우 크지 않고 팀으로 협업할 수도 있습니다. 그러나 이것은 개발자에게 너무 많은 것일 수 있습니다. 그래도 아이디어는 아주 깔끔한 것 같습니다.

Playmaker에서는 그런 식입니다. 사람들이 많이 좋아하는 것 같습니다.
여기 많은 사람들이 스텐실도 좋아하는 것 같습니다. 기술은
오픈 소스이며 스크래치 github 웹 사이트에서 사용할 수 있습니다. 에서 공유했습니다
이전 게시물.

저는 개인적으로 비주얼 프로그래밍의 모든 첫 단계를 보고 싶습니다.
방향. 개발자가 gd와 작동하는 상태 머신을 만들더라도
스크립트 - 고급 프로그래머라도
감사하겠습니다.

그런 다음 stencil 또는
구성2 - 코드와 비슷하지만 코드보다 훨씬 쉽습니다.
상태.

실제로 이것은 두 가지 기능 요청입니다!

• 상태 머신(노드)용
• 학습 gdscript를 대체하는 시각적 스크립팅 프레임워크에 대한 또 다른
  드래그 앤 드롭 코딩으로 그러나 또한 학습을 ​​향한 좋은 단계입니다.
  지디스크립트.

결국 메인 개발자는 Godot의 디자인에 가장 적합한 것이 무엇인지 압니다.

2015년 5월 26일 화요일 오전 11시 43분에 whoisda [email protected] 에서 다음과 같이 썼습니다.

노드와 이벤트를 함께 사용할 수 있다면 좋을 것입니다. 노드는 다음을 수행할 수 있습니다.
간단한 논리를 따르는 경우 다른 노드에 연결할 수 있는 상태 또는
이런 식으로 스크립트/블록/이벤트 시트의 컨테이너가 될 수 있습니다.
매우 큰 노드이며 팀으로 협업할 수도 있습니다. 하지만 이것도 어쩌면
개발자를 위해 많이. 그래도 아이디어는 아주 깔끔한 것 같습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984.

나는 styencyl에 익숙하지 않기 때문에 곧 확인하겠습니다.
이 시점에서 내가 보거나 읽은 모든 것에서 다음을 수집할 수 있습니다.

1) Blueprint: 게임/레벨 디자이너에게는 좋지만
비주얼 프로그래밍
2) 스텐실: 시각적 프로그래밍에는 훨씬 더 좋지만 다음에는 사용할 수 없습니다.
게임/레벨 디자이너

게임을 만드는 경험은 항상 팀에 있었기 때문에 1) 다음과 같이 볼 수 있습니다.
매우 유용하지만 그것은 또한 저를 편향되게 만듭니다. 사람이 그렇게 많은가요
Stencil과 같은 시각적 프로그래밍에 관심이 있으십니까?

2015년 5월 26일 화요일 오전 6시 10분, Todor Imreorov [email protected]
썼다:

Playmaker에서는 그런 식입니다. 사람들이 많이 좋아하는 것 같습니다.
여기에 있는 많은 사람들도 스텐실을 좋아하는 것 같습니다.
오픈 소스이며 스크래치 github 웹 사이트에서 사용할 수 있습니다. 에서 공유했습니다
이전 게시물.

저는 개인적으로 비주얼 프로그래밍의 모든 첫 단계를 보고 싶습니다.
방향. 개발자가 gd와 작동하는 상태 머신을 만들더라도
스크립트 - 고급 프로그래머라도
감사하겠습니다.

그런 다음 stencil 또는
구성2 - 코드와 비슷하지만 코드보다 훨씬 쉽습니다.
상태.

실제로 이것은 두 가지 기능 요청입니다!

• 상태 머신(노드)용
• 학습 gdscript를 대체하는 시각적 스크립팅 프레임워크에 대한 또 다른
  드래그 앤 드롭 코딩으로 그러나 또한 학습을 ​​향한 좋은 단계입니다.
  지디스크립트.

결국 메인 개발자는 Godot의 디자인에 가장 적합한 것이 무엇인지 압니다.

2015년 5월 26일 화요일 오전 11시 43분, whoisda [email protected]
썼다:

노드와 이벤트를 함께 사용할 수 있다면 좋을 것입니다. 노드는 다음을 수행할 수 있습니다.
간단한 논리를 따르는 경우 다른 노드에 연결할 수 있는 상태
또는
이런 식으로 스크립트/블록/이벤트 시트의 컨테이너가 될 수 있습니다.
가지다
매우 큰 노드이며 팀으로 협업할 수도 있습니다. 하지만 이것은 아마도
~도
개발자를 위해 많이. 그래도 아이디어는 아주 깔끔한 것 같습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142.

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

이것은 스텐실 "코드"가 어떻게 보이는지에 대한 표준 예입니까? 그렇다면 그것은 끔찍한 생각처럼 보입니다. 유치원용 시각적 래퍼의 표준 코딩처럼 보입니다. 자, 파이썬은 이미 아내가 읽을 만큼 쉽기 때문에 기초를 배우기 위해 노력하지 않겠습니까?

비주얼 프로그래밍에 대해 이야기한다면 Godot가 이미 가지고 있는 것이 훨씬 더 좋습니다 - 셰이더 그래프 또는 애니메이션 그래프: 코드는 비주얼 노드에 싸여 있습니다.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - 시각적 노드 기반 프로그래밍의 또 다른 예(Sidefx Houdini 또는 XSI). 성숙하고 어린이 장난감처럼 보이지 않으며 Godot 노드를 생각나게합니다.

나는 construct2 접근 방식을 좋아했지만 처음부터 더 많이 살펴본 결과 여러 가지 이유로 더 나은 선택인 것 같습니다.

• 프로그래밍 디자인은 구성2보다 더 인기 있는 것 같습니다.
• 사람들에게 프로그래밍 언어를 가르치는 데 도움이 되는 도구로 이미 확립되었습니다.
• 그것은 오픈 소스이며 다른 사람들은 과거에 엔진을 위해 용도를 변경했습니다.

Stencil 개발자는 오픈 소스 "스크래치" 기술을 채택했습니다. 그것은 그들의 디자인이 아닙니다.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (프로그래밍_언어)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

비 프로그래머를 대상으로 하는 다른 게임 엔진에서 스크래치를 사용하는 예:

• 스텐실(가장 인기 있는 것) http://www.stencil.com/
  
• 크래프트스튜디오 ( http://craftstud.io/ )
  
• 구글 블록리( https://developers.google.com/blockly/ )
• Godot에 가장 가까운 것은 Unity의 "Blox" 비주얼 프로그래밍 자산입니다:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdDIAA7_yjFNcLXM5YOf3WE9k
  Lua 대신 C#을 생성합니다.
  전체 문서는 다음과 같습니다.
  http://www.plyoung.com/blox/
  여기에서 판매됩니다: https://www.assetstore.unity3d.com/en/#!/content/12859

숙련된 프로그래머에게는 끔찍한 생각처럼 보일 수 있지만 비 프로그래머에게 코드 작성 방법을 가르치거나 마법의 단어나 구문을 몰라도 프로그래밍할 수 있는 권한을 부여하는 가장 좋은 방법입니다. 스크래치는 그것들을 모두 끌어서 놓을 수 있도록 하여 시각적 단서가 있는 올바른 구조를 강요합니다. 내가 게시한 "Unity Blox" 동영상 재생 목록을 시청하여 작동하는 모습을 확인하세요. 무엇보다 실천을 거듭해서 입증되었습니다. 가장 안전한 방법인 것 같습니다.

하나는 레벨 디자인에, 다른 하나는 비주얼 스크립팅에 능숙하며 더 이상 둘 중 하나를 사용하는 것에 대해 논쟁하지 않는다는 그의 요점에서 @reduz 의 의견에 동의합니다.

둘 다 사용하는 것이 가장 좋은 방법인 것 같습니다. Unity blox가 아닌 경우 Playmaker를 살펴봐도 노드가 stencil과 매우 유사하게 작업을 쌓을 수 있는 컨테이너라는 사실을 알 수 있습니다. 목록에서 드래그 앤 드롭합니다!

"하지만 비프로그래머에게 코드 작성 방법을 가르치거나 마법의 단어를 몰라도 프로그래밍할 수 있도록 권한을 부여하는 것이 가장 좋은 방법입니다."

그렇다면 이 대상이 어떤 청중인지 이해가 되지 않습니다. Godot는 시장의 거물들(Unreal Engine, Unity 등)과 경쟁하거나 Scratch와 같은 프로그래밍/제작 게임을 가르치는 것(https://scratch.mit.edu/)을 목표로 하고 있습니까?

나는 노드가 무엇인지 알고(입력 -> 매개변수가 있는 기능 -> 출력) 프레젠테이션에 동의하지 않습니다.

Stenyl과 Playmaker는 아이들에게 코딩하는 방법을 가르치는 데 탁월할 수 있지만 프로그래머가 아닌 사람들(스튜디오와 인디 모두)이 성공적인 게임을 만드는 데 성공적으로 사용하여 다양한 플랫폼에서 판매되었습니다.
Unity를 큰 소년으로 분류한다면 큰 소년도 비주얼 프로그래밍을 한다는 것을 알아야 합니다.
http://www.hutonggames.com/showcase.html

나는 Godot에 큰 소년들이 사용할 수 있는 기능이 많이 있다고 생각합니다. 더 작은/인디를 가능하게 하는 몇 가지 기능은 엔진의 더 빠른 채택에 도움이 될 수 있습니다. 그리고 오픈 소스 특성과 린넨 라이선스는 초보자에게 매우 유리합니다.

@blurymind
저는 비주얼 프로그래밍에 반대하지 _않습니다_. Godot는 이미 필요한 것을 가지고 있다고 말하고 싶습니다(ShaderGraphs): 동일한 시각적 접근 방식이 상태 기계 논리 프로그래밍 또는 일반 프로그래밍으로 확장될 수 있습니다. 내가 반대하는 것은 아이들을 겁내지 않는 또 다른 시각적 패러다임(~scratch)을 채택하는 것에 반대합니다.

앞서 언급했듯이 아이들만을 위한 것이 아닙니다. 하지만 아이들도 이해하고 사용할 수 있다면 좋은 일이라고 생각합니다. 부끄러워 할 일이 아닙니다.

제가 여기서 말하고 싶은 가장 큰 요점은 다음과 같습니다.

• 작업 실행 순서가 명확해야 합니다! 노드로 모든 논리를 수행하는 것은 매우 빠르게 매우 복잡해질 수 있습니다. 따라서 노드는 상태 imo에 사용해야 합니다.
• Playmaker 개발자는 문제를 매우 영리하게 예상했으며 이것이 바로 Stencil과 매우 유사하게 목록에서 사용 가능한 작업을 끌어다 놓는 작업 컨테이너를 노드로 만든 이유입니다.
  
  그런 식으로 이벤트를 스택

당신이 끝내는 것은 매우 깨끗하고 효율적인 노드 설정입니다!

Godot 개발자들도 플레이메이커를 시도해 볼 것을 제안합니다.
이벤트 스택을 Stencil 로직으로 교체하면 이에 대한 Godot의 접근 방식이 훨씬 더 유연하고 강력해집니다!.

스텐실 접근 방식을 통해서만 가능한 것은 아닙니다. 숙련된 프로그래머가 노드에 gd 스크립트를 첨부할 수 있도록 할 수 있다고 생각합니다. gdscript를 생성하기 위해 stencil 접근 방식을 사용할 수 있는 옵션이 있다는 것은 매우 중요합니다. 그것은 많은 새로운 사용자들을 Godot 커뮤니티에 초대할 것입니다.

@blurymind
좋아, 하지만 그건 다른거야. 사용하기 쉽다고 해서 어린이용처럼 보여야 하는 것은 아닙니다.
주어진 노드에 대한 적절한 입력/출력의 실행 순서 및 지원 필터링은 노드 기반 워크플로의 일반적인 문제입니다. 다른 소프트웨어는 다르게 해결합니다.

스스로에게 물어봐야 합니다. 프로그래머가 아닌 사람들이 Godot를 사용하기를 원하는가? gdscript에 대한 경험이 없는 사람들도 재미있는 것을 만들 수 있도록 하시겠습니까?

대답이 예인 경우 가장 좋은 방법은 시각적 스크립팅 접근 방식을 제공하는 것입니다.
노드를 어린이용으로 만든 것처럼 보이게 하려는 것이 아닙니다.
내가 제안하는 것은 이것을 두 개의 프로젝트로 나누는 것입니다!

• Playmaker에서와 같이 상태 머신으로 사용되는 노드! 프로그래머는 각 노드의 이름을 지정하고 설정한 입력 및 출력과 함께 해당 노드에 gdscript를 첨부할 수 있습니다. 따라서 이것은 어린이를 위한 것이 아닙니다. 사실, 이것은 훨씬 덜 지저분한 프로그래머를 위한 훨씬 더 유연한 접근 방식입니다.
• 드래그 앤 드롭 이벤트 시트 또는 블록 인터페이스는 GDscript를 생성하는 대체 방법입니다. 따라서 노드에 연결하기 위해 GdScript를 작성하는 대신 프로그래머가 아닌 사용자는 Playmaker와 마찬가지로 godot에서 사용 가능한 모든 이벤트 목록에서 작업을 쌓을 수 있습니다. 한 단계 더 나아가 혁신을 하려면 - 단순히 액션을 쌓는 것보다 블록과 같은 Stencil을 사용하는 것이 더 나을 것입니다.

이렇게 하면 프로그래머와 비프로그래머 모두에게 유용한 것을 갖게 됩니다. 그들은 상태 머신(노드)을 사용할 수 있으며 프로그래머가 아닌 사람들은 gdscript를 즉시 배울 필요가 없으며 대신 노드에 대한 gdscript를 생성하기 위해 gdBlocks를 사용할 필요가 없습니다(다시 - Playmaker에서와 같이).

@blurymind
난 그게 더 좋아. 또한 이미 Godot에 있는 셰이더 노드 그래프 대 셰이더 텍스트와도 일치합니다.

SideFX Houdini에는 VEX(https://goo.gl/TMWNKk)("벡터 표현"은 벡터 대수학을 의미하는 c와 유사한 언어)라는 것이 있습니다. gdScript와 다소 동의어입니다. 또한 "VOP"(http://goo.gl/Qpn2OE)(Vex Operators)라는 것이 있습니다. 본질적으로 VEX 하위 집합의 시각적 래퍼이며 위에서 참조한 LeadWerks 노드 그래프 이미지와 매우 유사합니다. 사실, VOP는 필요한 경우 텍스트 스크립트로 전환될 수 있습니다(그러나 그 반대는 아님).

2의 공존은 매우 자연스럽고 프로그래머가 아니더라도 매우 지저분하고 비효율적인 코드를 만들 수 있습니다.)

저는 개인적으로 Blueprint 접근 방식이 매우 게임 디자이너이기 때문에 좋아합니다.
하지만 내가 편견을 가질 수 있다고 주장합니다.

2시간 전에 스텐실을 다운로드해서 가지고 놀았습니다. 나는 아마도
틀렸지만 Stencil은 학습하기에 좋은 도구라고 생각합니다.
프로그래밍 부분은 간단하지만 엔진 부분도 간단합니다. 조합은
단순한 게임 엔진을 위한 간단한 프로그래밍 접근 방식이기 때문에 좋습니다.

하지만 Godot는 단순한 게임 엔진이 아니기 때문에 (적어도 Stencil에 비하면)
단순화된 프로그래밍이 그렇게 유용할 것이라고 생각하지 마십시오. 스텐실에 의존
단순히 사용할 수없는 많은 하드 코딩 된 게임 논리 항목
Godot를 사용 가능하게 하려는 시도는 Godot의 목표와 모순됩니다.
매우 범용적인 게임 엔진입니다.

노드 및 그래프 접근 방식은 제 생각에 더 흥미롭습니다.
일을 하는 더 낮은 수준과 더 유연한 방법.

2015년 5월 26일 화요일 오전 11:29, Vladimir Lopatin < [email protected]

썼다:

@blurymind https://github.com/blurymind
난 그게 더 좋아. 또한 셰이더 노드 그래프와 일치합니다.
이미 Godot에 있는 셰이더 텍스트.

SideFX Houdini에는 차가운 VEX가 있습니다(https://goo.gl/TMWNKk)("vector
벡터 대수학을 의미하는 "C와 같은 언어"입니다.
gdScript와 다소 동의어입니다. 또한 "VOP"(
http://goo.gl/Qpn2OE) (Vex Operators) - 본질적으로 시각적 래퍼
LeadWerks 노드 그래프와 매우 유사해 보이는 VEX의 하위 집합
위에서 참조. 실제로 필요한 경우 VOP를 스크립트로 변환할 수 있습니다.
(그러나 그 반대는 아님).

2의 공존은 매우 자연스럽고 허용합니다.
프로그래머가 아닌 경우, 매우 지저분하고 비효율적인 코드를 생성하기 위해 ;)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845.

Playmaker의 액션 스태킹과 Unity의 blox는 어떻습니까? Unity는 아주 단순한 엔진이 아닙니다.

스텐실은 좋은 예가 아니라고 생각합니다. Unity 에셋 스토어에서 예제를 찾는 것이 좋습니다.

플레이메이커를 이해하려고 했으나 실패했습니다. 어떻게 작동하나요?

2015년 5월 26일 화요일 오후 12시 16분, Todor Imreorov [email protected]
썼다:

Playmaker의 액션 스태킹과 Unity의 blox는 어떻습니까? 통일은 아니다
아주 간단한 엔진.

스텐실은 좋은 예가 아니라고 생각합니다. 찾는 것이 좋다
Unity 에셋 스토어의 예.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760.

플레이메이커 튜토리얼을 확인했지만 스텐실과 비슷한 것 같습니다.
수많은 사전 정의된 행동과 함께 제공된다는 느낌

2015년 5월 26일 화요일 오후 12시 19분, Juan Linietsky [email protected]
썼다:

플레이메이커를 이해하려고 했으나 실패했습니다. 어떻게 작동하나요?

2015년 5월 26일 화요일 오후 12:16 Todor Imreorov < 알림 @github.com

썼다:

Playmaker의 액션 스태킹과 Unity의 blox는 어떻습니까? 통일은 아니다
아주 간단한 엔진.

스텐실은 좋은 예가 아니라고 생각합니다. 찾는 것이 좋다
Unity 에셋 스토어의 예.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777.

_오캄스튜디오_

Unity에서 U4 청사진에 가장 가까운 것은 uScript입니다.
https://www.assetstore.unity3d.com/en/#!/content/1808

설정된 로직을 이해하기 쉽기 때문에 사람들은 uscript보다 Playmaker를 선호하는 것 같습니다. 스크린샷에서 볼 수 있듯이 간단한 논리에도 매우 지저분해집니다.

@reduz @okamstudio 플레이메이커의 재생 목록은 다음과 같습니다.
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
실제로 조금 사용하시면 될 것 같아요. 미리 정의된 동작과 스크립트를 수행할 수 있지만 플레이메이커를 사용하면 엔진의 핵심 기능에 액세스하고 이러한 동작을 처음부터 직접 만들 수도 있습니다.

예, 플레이메이커는 상태 머신이며 통합에는 미리 정의된 많은 동작이 있습니다.
Godot는 또한 그것들을 가지고 있습니다 - 그것들은 엔진에 내장되어 있습니다.
나는 여전히 unity의 stencil clone blox를 사용하여 처음부터 스크립트/동작을 실제로 생성할 수 있다고 믿습니다.

적절한 게임과 이 아이디어를 만들기 위해서는 마침내 프로그래머가 필요하다고 생각합니다.
게임디자이너가 직접 게임을 만든다는 것은 대단한 일이지만 많은 것 같아요
많은 경우에 유용하지 않은 작업. 하지만 더 많은 것이 있다면
다른 사람이 만든 플랫포머 디자이너처럼 편집기 자체를 위한 기능
UI를 쉽게 만들기 위해 다른 문제 또는 기타 유용한 것들에서 언급
더 친절한 .
2015년 5월 26일 오후 7시 52분에 "Okam Studio" [email protected] 이 작성했습니다.

플레이메이커 튜토리얼을 확인했지만 스텐실과 비슷한 것 같습니다.
수많은 사전 정의된 행동과 함께 제공된다는 느낌

2015년 5월 26일 화요일 오후 12:19 Juan Linietsky < 알림 @github.com

썼다:

플레이메이커를 이해하려고 했으나 실패했습니다. 어떻게 작동하나요?

2015년 5월 26일 화요일 오후 12:16 Todor Imreorov <
알림@github.com

썼다:

Playmaker의 액션 스태킹과 Unity의 blox는 어떻습니까? 통일은
아니다
아주 간단한 엔진.

스텐실은 좋은 예가 아니라고 생각합니다. 찾는 것이 좋다
Unity 에셋 스토어의 예.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_오캄스튜디오_

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084.

다음은 uScript에 대한 Unity 에셋 스토어의 리뷰입니다.

좋은 도구지만 프로그래머가 아닌 경우 배우기가 어렵습니다... 포럼의 도움 요청에 대한 응답이 매우 느리거나 전혀 존재하지 않습니다..

Godot에 있는 것이 무엇이든, 가능하면 GDScript로의 단방향 변환을 허용하는 것이 좋습니다. 이를 통해 디자이너와 아티스트 등이 시각적으로 빠르게 설정할 수 있으며 팀의 코더는 클릭을 사용하지 않고도 이를 추가로 조정하고 재작업할 수 있습니다.

@adolson 정말 원하던 기능이겠죠 :)

이것은 수행할 수 있으며 시각적 셰이더 편집기로도 수행할 수 있습니다.
(사실 셰이더 코드를 생성함)
하지만 생성된 셰이더 코드는 당신만큼 읽을 수 없을 것이라고 생각합니다
기대하다 :P

2015년 5월 26일 화요일 오후 6시 33분에 Nathan [email protected] 이 다음과 같이 썼습니다.

@adolson https://github.com/adolson 그게 많이 바라는 거겠지
특징 :)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945.

@reduz 일부 메타데이터가 필요합니다.
다음은 위에 표시된 대로 VOP에서 변환 -> VEX 변환의 예입니다.
:
다음은 코드의 전체 목록입니다. 그렇지 않으면 순수한 VEX에서 다음과 같이 보입니다.
@P += 벡터({0,1,0}); // 위치를 취하고 벡터(0,1,0)를 추가합니다.

보시다시피 메타데이터의 양은 상당하지만 2를 분리하는 것은 어렵지 않으며 반자동 또는 완전 자동으로 구문 분석할 수 있습니다.

@reduz 맞습니다 . 나는 그것에 대해 정말로 생각하고 있지 않았다. 아마도 대부분의 프로그래머가 시간을 보내고 싶어하는 종류의 코드가 아닐 것입니다. 레이블이 변수 이름 등이 되는 것을 볼 수 있지만 문제를 완화하기 위해 너무 많은 것을 볼 수는 없습니다.

모든 사람을 대변할 수는 없지만 코드가 엉망인 경우 코드에서 몇 가지를 빼낼 수 있지만 일반적으로 그냥 다시 작성하고 싶은 마음이 듭니다. 그래서 만약 그렇다면 이것은 나에게 개인적으로 가치가 없을 것입니다.

여러분은 정말 다양한 옵션을 거쳤습니다. 나는 Construct 2를 사용했고 깔끔하긴 하지만 코드를 수정하기 위해 절대 건드릴 수 없고 옵션이 다소 제한적이었습니다. 타일맵 업데이트는 기본적으로 프리팹을 제거하여 인스턴싱도 제거했습니다. 내가 정말 좋아했던 것은 Unity용 PlayMaker였습니다.

범위와 수행해야 할 작업을 파악하기가 매우 쉬웠습니다. 이것은 정말 매력적인 요소입니다. 내가 비주얼 스크립터를 사용하는 모든 이유는 바로 이것 때문입니다. 텍스트 코드에서 내가 무엇을 하고 있었는지 또는 무엇을 해야 하는지 잊어버렸지만 모든 것이 어떻게 '연결'되는지 보는 것이 가장 큰 이점입니다. NateWarddog은 훨씬 이전에 스크린샷에 예시를 게시했고 훨씬 더 최근에 blurrymind를 게시했습니다.

나는 reduz라고 말하고, 당신은 그것을 위해 가십시오. 지금은 귀찮게 하려고 하면 1.3 이상으로 촬영하고 그 후에도 대부분 프론트엔드 측면에 초점을 맞춥니다. 그런 다음 나중에 준비가 되면 Blueprint와 같이 읽을 수 있는 코드를 출력하는 데 집중해야 합니다. 이는 매우 어려울 것이라고 생각합니다. 이것을 과소 평가하지 마십시오!

구독 중. 저도 이것에 관심이 많아요! 나는 일부 스크립팅을 알고 있고 그것을 사용하는 데 별로 신경 쓰지 않습니다... 하지만 가능하면 노드를 연결하는 것을 선호합니다! Godot 스크립트의 시각적 단축키 역할을 하는 블렌더 게임 엔진의 로직 브릭과 같은 것은 손으로 작성하는 대신 사용할 수 있는 기능입니다... 멋진 기능이 될 것이며 제가 적극적으로 기다리고 있습니다.

비주얼 스크립팅은 많은 창의적인 사람들이나 gd 스크립트와 같은 새로운 스크립팅 언어를 배우고 싶지 않은 사람들을 끌어들입니다. 나는 게임 메이커가 너무나 유명하고 가장 큰 이유는 비주얼 스크립팅 메커니즘을 보고 있었습니다.

비주얼 스크립팅은 지루하고 어리석고 사용하기 어렵습니다.
나는 좋은 구현을 본 적이 없습니다. 시각적인 사람은 그래픽을 그려야 합니다. 나
많은 사람들이 글을 쓸 수 없다는 것을 알고,
그러나 이것은 그들에게 아무런 도움이 되지 않을 것입니다. 프로그래밍하지 않는 사람은 다음을 의미하지 않습니다.
문맹자.

주요 시스템이었던 시각적 논리 구축 도구에 대해 알지 못합니다.
모든 엔진의 게임 로직.
시각적인 방법은 여러면에서 짜증납니다. 시각적인 사람들이 일반적으로 고려하는
"기술 자료"로 프로그래밍
배관 및 열심히 일하고 위에 있고 싶은 것을 의미합니다.
그것. 이 태도
일반적으로 일부 지적 문제 때문입니다. 나는 이 사람들이 아니라고 생각한다.
타겟 고객이 될 수 있습니다
기본적으로 그들은 창의성을 제한합니다.

2016년 4월 14일 목요일 오전 8시 33분, Rémi Verschelde [email protected]
썼다:

편집: "Game Maker"에 대해 "RPG Maker"를 변경한 것을 보니 이제 더 많이 만듭니다.
센스 :p 내 게시물을 삭제합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

하고 싶지는 않지만 말해야 합니다. 하지만 그것은 시각적 스크립팅 도구인 Sergey에 대한 매우 좁은 관점입니다. 완전히 만들어진 게임의 경우 Construct와 같은 일부 엔진은 완전히 선택 해제되어 있으므로 일반 스크립팅으로 만든 해당 엔진에서 게임을 볼 수 없습니다. 다른 (좀 더 제정신, imo) 엔진에는 Unity 및 UE4와 같은 플러그인이 있습니다. 저는 개인적으로 Unity에서 일반 코드와 함께 uscript와 PlayMaker를 모두 사용하는 것을 정말 좋아했습니다. 왜냐하면 어떤 것들은 코딩하기 더 쉽지만 많은 것들이 시각적으로 스크립팅하기 더 쉽기 때문입니다. 특히 PM과 같은 시각적 스크립터를 사용하면 breakpointsw를 사용하면 더 범위가 넓은 보기에서 프로젝트를 보는 것이 훨씬 쉽습니다.

일반적으로 비주얼 스크립팅의 진정한 의미는
프로그래머가 아닌 사람이 프로그래밍에 접근할 수 있도록 하는 것은 완전히 잘못된 것입니다.
접근하다.
비주얼 프로그래밍은 일반 텍스트 프로그래밍보다 어렵습니다. 만들다
더 쉽게 전통적인 방식으로 삶의 각 경우에 대해 많은 블록을 작성해야 합니다.
방법과
이 사람들이 사용하게하십시오. 이것들은 묻는 것보다 덜 효과적임이 입증되었습니다.
코드를 작성하는 좋은 프로그래머. "프로그래밍은 직업이 아니다.
누구나 할 수 있습니다"는 잘못된 것입니다.
프로그래밍은 낭비입니다.

상태 머신에 관해서 - 나는 이것을 언젠가 구현하는 것에 대해 생각하고있었습니다.
이전이지만 높은 비주얼 프로그램에는 도움이 되지 않습니다.
이것은 도구 스크립트와 노드 편집기를 사용하여 게임에서 쉽게 수행할 수 있습니다.
강력한 도구이므로 많은 사람들이 다음과 같은 게임 도구에 사용합니다.
게임 대화 편집자.

2016년 4월 14일 목요일 오전 9시 9분에 Aaron M [email protected] 은 다음과 같이 썼습니다.

굳이 말하고 싶지 않은데 그건 시각적인 관점이 너무 좁아서
스크립팅 도구, Sergey. 그들로 완벽하게 만들어진 게임의 경우,
Construct와 같은 일부 엔진은 완전히 선택 해제되어 있으므로
일반 스크립팅으로 만든 엔진에서 게임을 볼 수 없습니다. 다른
(더 정상적, imo) 엔진에는 Unity 및 UE4와 같은 플러그인이 있습니다. 나는 개인적으로
정기적으로 Unity에서 uscript와 PlayMaker를 모두 사용하는 것을 정말 좋아했습니다.
어떤 것들은 코딩하기 더 쉽지만 많은 것들은 코딩하기 더 쉽기 때문입니다.
시각적으로, 특히 상태 머신을 시각적으로 스크립팅합니다.
PM과 같은 스크립터는 breakpointsw로 많은 피드백을 제공합니다.
보다 범위가 넓은 보기에서 프로젝트를 보는 것이 훨씬 쉽습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

Slapin, 당신이 맞습니다. 그러나 시각적 프로그래밍 또는 프로그래밍 블록의 실패율이 매우 낮다는 사실을 잊었습니다. 한계 때문입니다.
매우 제한된 스크립팅 언어를 사용할 때도 기본적으로 동일합니다. 당신은 많은 실수를 할 수 없습니다.

비주얼 스크립팅인지 텍스트 스크립팅인지에 대한 질문이 아니라 이것이 달성해야 할 목표라고 생각합니다!

프로그래밍을 더 좋게 만들고 싶다면 도구를 더 좋게 만드십시오. Codehighlighting, Codecompletion, Codevalidation, Codetemplates, asso. 디버거를 개선하고 Liveprogramming을 만드십시오.
항상 안정적인 라이브프로그래밍 환경을 찾아다녔지만 지금까지는 찾지 못했습니다!

Visual Scripting을 정말 만들고 싶다면 Stingray Engine처럼 만드세요. Visual에서 CodeBlocks를 만들고 나중에 수정할 수 있는 TextCode를 생성하거나 나중에 Visual Blocks로 사용할 수 있는 TextCode를 작성할 수 있습니다.

나는 그것이 무의미하다고 말하지는 않겠지만 우리가 2에 대해 이야기하고 있다고 말할 것입니다.
완전히 다른 제품.

스튜디오를 운영하고 있고 20-80명과 함께 게임을 만들고 있다면
매월 생산 비용으로 6자리를 지출하고 있으며
게임을 만드는 엔진, 특정 제품을 원합니다. 그 경우, 당신은
시각적 스크립팅 도구에 대해서는 전혀 신경 쓰지 않고 다른
팀이 엔진 도구를 사용하여 얼마나 생산성을 높일 수 있는지 등
(그들이 한 달 동안 일정을 초과하면 ~$100k가 나가기 때문에). 저것들
팀에는 프로그래머가 있고 훨씬 더 생산적인 코드 작성이 가능합니다.
일부 시각적 도구를 사용하는 것보다(예를 들어 Vicious Engine 검색)

반면에 멋진 아이디어가 있는데 어떻게 해야 할지 모르겠다면
코드를 작성하고 다른 제품을 원하고 빠른 프로토타입을 만들기 위해
당신은 주변을 보여줄 수 있고 결국 프로그래머에게 실제를 만들 수 있습니다.
게임.

2개의 다른 제품이고 어느 것이 더 가치가 있는지 논쟁하면
있다는 사실을 인정해야 합니다. 비주얼 스크립팅이라고 하면
이 도구는 실제로 프로토타입을 만드는 1명 이상으로 확장되지 않습니다. 처럼
정식 게임을 만들고 싶거나 팀이 2-3으로 성장하자마자
여러분, 이미 실제 프로그래밍 언어가 필요합니다. 그래서 나는 첫 번째를 좋아한다.
전체 목표로 더 많은 예를 들 수 있습니다(세 번째 제품을 원하지 않는 한,
"수백만 달러를 버는 완전한 인디 게임을 만드는 데 사용할 수 있는 엔진
코드를 작성하지 않고 ". 존재하지 않음).

그러나 우리는 둘 다 가질 수 있으며 어느 쪽도 낙담시키지 않을 것입니다. 비주얼
스크립팅 도구는 초보자 사용자를 생성하여 장기적으로 우리를 도울 것입니다.
이는 결국 업계에서 작동하고 다음을 결정할 위치에 있습니다.
실제 게임에 Godot를 사용하면 좋습니다. 또한 Square Enix의 CTO는
엔진에 시각적 프로토타이핑 언어가 있는지 물었습니다.
대기업에는 그런 유형의 틈새 시장도 있습니다.
R&D를 가치 있게 여기고 오랜 기간 동안
프리프로덕션/프로토타이핑/새로운 아이디어 실험 등(그는 또한
우리 게임이 콘솔 게임 같다고 (두 번) 어느 나라가
만드는 방법을 배우러 갔습니까 :p ).

2016년 4월 14일 03:26에 Sergey Lapin [email protected] 은 다음과 같이 썼습니다.

일반적으로 비주얼 스크립팅의 진정한 의미는
프로그래머가 아닌 사람이 프로그래밍에 접근할 수 있도록 하는 것은 완전히 잘못된 것입니다.
접근하다.
비주얼 프로그래밍은 일반 텍스트 프로그래밍보다 어렵습니다. 만들다
더 쉽게 전통적인 방식으로 삶의 각 경우에 대해 많은 블록을 작성해야 합니다.
방법과
이 사람들이 사용하게하십시오. 이것들은 묻는 것보다 덜 효과적임이 입증되었습니다.
코드를 작성하는 좋은 프로그래머. "프로그래밍은 직업이 아니다.
누구나 할 수 있습니다"는 잘못된 것입니다.
프로그래밍은 낭비입니다.

상태 머신에 관해서 - 나는 이것을 언젠가 구현하는 것에 대해 생각하고있었습니다.
이전이지만 높은 비주얼 프로그램에는 도움이 되지 않습니다.
이것은 도구 스크립트와 노드 편집기를 사용하여 게임에서 쉽게 수행할 수 있습니다.
강력한 도구이므로 많은 사람들이 다음과 같은 게임 도구에 사용합니다.
게임 대화 편집자.

2016년 4월 14일 목요일 오전 9시 9분에 Aaron M [email protected] 은 다음과 같이 썼습니다.

굳이 말하고 싶지 않은데 그건 시각적인 관점이 너무 좁아서
스크립팅 도구, Sergey. 완벽하게 만들어진 게임의 경우
그들을,
Construct와 같은 일부 엔진은 완전히 선택 해제되어 있으므로
일반 스크립팅으로 만든 엔진에서 게임을 볼 수 없습니다. 다른
(더 정상적, imo) 엔진에는 Unity 및 UE4와 같은 플러그인이 있습니다. 나는 개인적으로
정기적으로 Unity에서 uscript와 PlayMaker를 모두 사용하는 것을 정말 좋아했습니다.
어떤 것들은 코딩하기 더 쉽지만 많은 것들은 코딩하기 더 쉽기 때문입니다.
시각적으로, 특히 상태 머신을 시각적으로 스크립팅합니다.
PM과 같은 스크립터는 breakpointsw로 많은 피드백을 제공합니다.
단지
보다 범위가 넓은 보기에서 프로젝트를 보는 것이 훨씬 쉽습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

당신은 단지 나에게 punto slapin을 말하는 것뿐입니다. 내 말은, 나는 디자이너나 단순화에 대해 아무 말도 하지 않았지만, 프로그래머에게도 사용 용이성에 대해 말한 적이 있습니다. 내가 정확히 반대를 보여주는 일화적인 경험을 했을 때 시간 낭비라고 말할 수는 없습니다. 나는 스크립팅과 함께 사용 가능한 옵션을 훨씬 더 선호합니다. 당신은 내가 둘 중 하나를 선택할 수 있는 것처럼 행동하고 있고 나는 그것을 내 아티스트에게 넘겨야 합니다. 전혀 그렇지 않습니다.

멋진 스레드, 많은 의견 😁

내 것은 간단합니다. 당신은 괜찮아!

이러한 아이디어는 gdscript에 큰 도움이 될 것입니다 😁

나는 그들이 나타날 때 그것을 시도하기를 고대합니다.

나는 gdscript가 더 사용자 친화적인 사랑을 할 수도 있다고 생각합니다.

일부 노드는 완전히 문서화되지 않았습니다. 설명이 없는 경우가 많습니다.
Godot는 개발을 단순화하기 위해 몇 가지 도우미 기능을 사용할 수 있습니다. Gamemaker gml이 좋은 예입니다.
https://twitter.com/uhearteast/status/724326557108461568

문서화 내용은 여기에서 주요 PITA라고 생각합니다. 그게 전부입니다.
개발 자체는 충분히 간단합니다. 문서 및 자습서
정말 필요합니다. 따라서 YouTube 계정을 유용하게 만드십시오(또는 블로그, 또는
포럼에 게시),
많은 도움이 될 것입니다.

2016년 4월 25일 월요일 오전 9:35 Todor Imreorov [email protected]
썼다:

나는 gdscript가 더 사용자 친화적인 사랑을 할 수도 있다고 생각합니다.

일부 노드는 완전히 문서화되지 않았습니다. 설명이 없는 경우가 많습니다.
Godot는 개발을 단순화하기 위해 몇 가지 도우미 기능을 사용할 수 있습니다.
Gamemaker gml이 좋은 예입니다.
https://twitter.com/uhearteast/status/724326557108461568

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

글쎄, 나는 이것에 대해 몇 가지 생각이 있습니다.
시각적 스크립팅과 같은 것을 포함하여 엔진에 더 쉽게 접근할 수 있습니다. 이는 게임을 만들고 싶지만 프로그래밍 경험은 없지만 완전히 다른 사람들을 초대하는 모든 아티스트에게 좋습니다. , 아무 기술도 없는 사람들. 텍스트 편집기에서 프로그래밍으로 전환하는 것이 최종 게임에 어려움을 겪을지라도 결코 그들의 의제에 없을 것입니다. 게임을 만들 때 어려운 것은 프로그래밍뿐이라고 생각하는 사람들이 비주얼 스크립팅으로 갑자기 이 제한이 풀립니다. 이것도 드문 일이 아닙니다. 수많은 셔블웨어와 같이 프로그래머가 아닌 사람들을 위해 특정 작업을 더 쉽게 만들어주는 모든 인기 있는 엔진을 살펴보십시오. 시각적 스크립팅을 포함하면 안 된다는 말은 삽질웨어를 얻을 위험이 있다는 의미이기 때문이 아니라 이러한 종류의 사람들이 셔블웨어를 만들기 위해 Godotengine을 사용할 수 있다고 생각하지 않도록 하는 방식으로 구현되어야 한다는 것입니다.
제 또 다른 문제는 Godotengine이 잘하는 것 중 하나이고 많은 사람들이 이 기능을 좋아한다는 것입니다. 이 기능은 git과 매우 잘 작동한다는 것입니다. 비주얼 스크립팅의 문제는 바이너리 형식으로 저장되는 경우가 많고 소스 코드 개정을 사용하는 경우 관리하기가 매우 어렵다는 것입니다. 시각적 스크립팅을 구현해야 하는 경우 텍스트 친화적인 방식으로 저장해야 합니다. 그리고 그것이 불가능하다면 아주 어렵습니다. 나는 git에서 잘 작동하지 않는 시각적 스크립팅을 갖는 것보다 git과 친숙한 형식으로 Godotengine에 프로젝트 파일을 갖고 싶습니다.
그리고 비주얼 스크립팅 시스템을 구현하는 데 필요한 모든 작업과 기능, 효율성 또는 성능의 손실 없이 비주얼 스크립팅 없이 Godotengine에서 특정 유형의 게임을 만들 수 있다는 사실로 판단하면 그냥 다음과 같이 구현하는 것이 무슨 문제입니까? 플러그인? 왜 그것이 엔진의 핵심 부품이어야 하는지 이유를 전혀 알 수 없습니다.

시각적 스크립팅에 대한 2센트를 추가하고 그 아이디어가 마음에 들지 않는 이유는 다음과 같습니다.

어떤 gdscript 파일에서든 노드를 연결하는 기능이 코드 관리 및 숙련도 면에서 훨씬 낫다고 생각합니다.

예를 들어, 시각적 스크립팅(또는 C2와 유사한 이벤트 시트 사용)을 사용하는 경우 1000개 이상의 기능이 있는 경우 어떻게 됩니까? 모든 것을 탐색하는 것이 훨씬 더 나빠질 것입니다. 저는 지금 HTML 5 액션 RPG 게임을 Godot로 이식하고 있습니다(10k + Lines of code와 500개 이상의 기능). _(애니메이션을 제외하고 기본적으로 Path of Exile이 가지고 있는 모든 단일 기능을 가지고 있으며 멀티플레이어입니다)_

비주얼 스크립팅으로는 이것이 가능하지 않을 것입니다. 저는 우리와 여기의 Godot 개발자들이 시각적 코드 이벤트 시트보다 기능/버그 스퀴싱에 더 집중해야 한다고 생각합니다. 하지만 그건 저뿐이에요 :)

편집 : 다른 사람들이 말했듯이 아마도 작은 프로젝트의 경우 ... 그러나 큰 것은 유용하다고 볼 수 없습니다.

구성2의 이벤트 시트는 기능을 지원하며 Godot와 동일하게 작동합니다. 간단한 필터/검색 상자가 나열한 모든 문제를 해결합니다.

그러나 Godot 개발자는 인기 있는 ATM이 있더라도 이벤트 시트 접근 방식을 원하지 않습니다. 나는 그것이 청사진 언리얼 접근 방식과 비슷한 것을 얻을 가능성이 더 높다는 인상을 받았습니다. 그렇게 하면 프로그래머는 무기고에 추가된 상태 머신 편집기의 이점을 누릴 수 있습니다.

vonstruct2 에서 시각적 스크립팅 코드를 구성하려면 축소할 수 있는 그룹에 넣습니다. 이것은 gdscript조차도 할 수 없는 일입니다. 코드 블록을 축소할 수 없습니다. 그래서 어떤 면에서 이벤트 시트는 Godots gdscript 편집기보다 장점이 있습니다.

@reduz 저는 Pure Data를 보고 있었는데 그들이 하는 방식은 매우 간단합니다. 자, 이것을 확인하십시오

보시다시피 "Bang"을 입력하면 일반 개체가 Bang 개체로 바뀝니다.

비주얼 스크립팅이 단순히 GD Script의 확장이 될 수 있다면 어떨까요? 단순히 일반 노드를 배치하고 예를 들어 Vector2를 입력하면 Vector2 개체가 됩니다. 따라서 본질적으로 각 클래스/객체는 노드이기도 합니다.

기능을 실행하려면 객체가 아니라 프로세스 노드인 다른 노드를 얻을 수 있다고 생각하고 Vector2.dot와 같은 것을 입력하면 노드가 2개의 입력과 1개의 출력을 갖는 점 노드로 바뀝니다.

비주얼 스크립팅은 어느 시점에서 계획됩니다

당신은 실망하지 않았습니다 :) <3

이미 VisualScripting이 있으므로 이 문제를 닫아야 합니까?

예.

"나도 긍정적으로 웃었다.
수천 명의 훌륭한 게임 개발자가 만든 수많은 게임 카탈로그, 공개 및 DRM 무료를 제공하는 Steam과 같은 큰 회사가 있다면 게이머로서 저에게 큰 도움이 될 것이기 때문입니다."
drm 무료 게임을 판매하는 gog 스토어를 살펴보세요.

2015년 성명서에서 주제와 다른 대답을 하세요. :)