Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 트리거 시스템
Ähnlich wie 트리거 시스템 (20)
트리거 시스템
- 1. Date 2013 – 05 - 05 Make 이승형 Trigger 알아보기
- 2. 이게 무슨 게임이냐? “트리거의 협곡 에 오신걸 환영합니다.”
- 3. “트리거가 무어란 말인 가?” “구성요소를 빠뜨릴 수 없지!” “트리거의 유전자 조작”
- 4. “트리거가 무어란 말인 가?” “구성요소를 빠뜨릴 수 없지!” “트리거의 유전자 조작”
- 5. “너는 트리거에 대해 얼마나 알아?”
- 7. 트리거는 다름 아닌 방아쇠이다!
- 8. “지금 고작 그거 설명하려는 거야?”
- 9. “게임에서의 트리거는 조금은 특별하다.” 트리거는 일종 덫을 의미한다. 플레이어는 이 덫에 걸림으로서 개발자가 의도한 무언가를 발동하게 되는데 플레이어가 행한 행동이 도화선이 되어 발생하는 것, 이것을 바로 트리거라 지칭하는 것이다
- 10. 트리거에 대해서 알겠는데 Why?사용하면 뭐가 좋아?
- 11. Why? 트리거에 대해서 알겠는데 Why?사용하면 뭐가 좋아? 기획자가 원하는 것을 무엇이든 지 만들 수 있어! 프로그래머가 작업하지 않 아도 기획자들이 작업 가능 해! 다양한 연출과 게임 진행을 한방에 해결!
- 12. “오 쓸만한걸? 그럼 나한테도 알려 달라구”
- 14. “트리거가 무어란 말인 가?” “구성요소를 빠뜨릴 수 없지!” “트리거의 유전자 조작”
- 15. 우선 진행하기 전에 필요한 요소먼저…
- 17. “이런 씨, 뭐가 저리도 많아＂
- 18. 저건 트리거의 일부에 지 나지 않는다고 훗. 어렵게 생각하지 말아 어렵지 않잖아? 우리집 신발갯수가 더 많다구
- 19. 쳇, 그럼 알았다고 뭐부터 하면 되는거야?
- 20. 트리거를 사용함에 있어 우선 기획자들이 사용할 수 있는 도구가 필요하다
- 21. 그것은 여러 가지를 표현하는데 무리가 없어야 하며 기획자들이 이해할 수 있어야 하는 것이어야만 한다.
- 22. SCRIPT
- 23. SCRIPT의 장단점 일일히 나열하기 어려우니 우선은 Java Script장점을.. 장점 1. 배우기 쉽다. 2. 클라이언트와 실시간으로 대응한다 3. 브라우저의 거의모든 객체를 제어할 수 있다. 4. 간단한 게임에서 에디터나 상업용프로그램에 이르기까지 많은분야에서 활용된 다. 단점 1. 소스가 노출된다. 2. 브라우저별로 함수나 객체의 사용이 달라서 호환성에 문제가 있다. 3. 다룰수 있는 메소드가 한정되어 ActiveX나 JAVA 애플릿, 플래시등에 비해 자유 롭지 못하다. 4. 브라우저가 없으면 실행이 안된다. 지식인한테 얻음
- 24. SCRIPT의 장단점 일일히 나열하기 어려우니 우선은 Java Script장점을.. 장점 1. 배우기 쉽다. 2. 클라이언트와 실시간으로 대응한다 (중요) 3. 브라우저의 거의모든 객체를 제어할 수 있다. 4. 간단한 게임에서 에디터나 상업용프로그램에 이르기까지 많은분야에서 활용된 다. 단점 1. 소스가 노출된다. 2. 브라우저별로 함수나 객체의 사용이 달라서 호환성에 문제가 있다. 3. 다룰수 있는 메소드가 한정되어 ActiveX나 JAVA 애플릿, 플래시등에 비해 자유 롭지 못하다. 4. 브라우저가 없으면 실행이 안된다. 게임에서의 장단점
- 25. 장단점은 대충 알겠는데 도대체 어떻게 사용한다 는 거야?
- 26. Binding
- 27. 스크립트는 프로그래머가 작성한 코드를 스크립 트에 바인딩하여 기획자가 해당 스크립트를 호 출시 프로그래머가 작성한 로직을 실행할 수 있 다 Squirrel script : 예제코드 “Test.Obj.constructor를 실행하면 프로그래머가 작성한 Test.Obj.constructor를 실행한다!”
- 28. 쳇, 스크립트라는 거 참 복잡하네. 내가 만들어서 사용하면 안되는거야?
- 29. Script를 개발하는 것은 좋으나 권하지는 않는다 나도 개발 중이긴 한데..
- 30. 토큰은 어떻게 해석해?!! 이 버근 또 뭐야?!! 속도가 느리잖아!!개발 기간이 짧지가 않다고!!
- 31. 알려져 있는 Script는 많다. 이러한 Script는 안정적이며 속도도 빠르 고 비교적 버그도 적으므로 프로젝트에 알 맞은 Script을 찾아 공부하자! - 루아스크립트 - 몽키스크립트 - Squirrel 스크립트 - 파이썬 - 자바스크립트
- 32. 이제 스크립트에 대해서도 알았다. 다음은 뭐야?
- 33. 조건과 행위는 단순히 판별할 조건 그리고 조건에 해당하는 행동 을 스크립트로 작성하면 된다. “엑, 바로?”” 모두 파괴하였군! 그로므로 넌 바보가 될거야 넌 함정에 빠진거지 다음 타이밍으로 가자! “그럼 트리거야. 쉽지?”
- 34. 트리거를 통하여 발생되어진 이벤트들은 타이밍이 중요하다! 프리젠테이션의 애니메이션처럼! “타이밍이 없는데 몬스터가 1.1까지 갔다가 말풍선을 2초간 띄우고 다시 0.0까지 돌아오는 것 어떻게 구현하지??”
- 35. 트리거에서 기본적으로 필요한 것은 기본적으로 지연 시간과 재생 시기(동시에 실행, 완료의 실행)이다! “프리젠테이션의 애니메이션을 만든다고 생각하면 돼”
- 36. 트리거에서 기본적으로 필요한 것은 기본적으로 지연 시간과 재생 시기(동시에 실행, 완료의 실행)이다! “프리젠테이션의 애니메이션을 만든다고 생각하면 돼” 지연 시간을 위해선 시간을 얼마나 흘렀는지 지연 시기를 위해선 앞 행동이 완료 되었는지 알아야 한다.
- 37. 트리거에서 기본적으로 필요한 것은 기본적으로 지연 시간과 재생 시기(동시에 실행, 완료의 실행)이다! “프리젠테이션의 애니메이션을 만든다고 생각하면 돼” 지연 시간을 위해선 시간을 얼마나 흘렀는지 지연 시기를 위해선 앞 행동이 완료 되었는지 알아야 한다. 이러한 옵션은 행동에 대한 기본적인 옵션으로 스크립트로 반드시 설정하도록 규격화 해놓는다.
- 38. 트리거에서 기본적으로 필요한 것은 기본적으로 지연 시간과 재생 시기(동시에 실행, 완료의 실행)이다! “프리젠테이션의 애니메이션을 만든다고 생각하면 돼” 지연 시간을 위해선 시간을 얼마나 흘렀는지 지연 시기를 위해선 앞 행동이 완료 되었는지 알아야 한다. 이러한 옵션은 행동에 대한 기본적인 옵션으로 스크립트로 반드시 설정하도록 규격화 해놓는다. 순조로이 행동이 진행될거 같지? 진행하면서 게임환 경도 바뀐다는 점 명심해. 스케쥴러도 만드는거 잊지 마~ 말풍선 띄울 놈이 죽어버리 기라도 하면..
- 39. “이봐 만들라고 만들어 봤는데 도대체 이 트리거는 언제 실행되는거 야?”
- 40. “매 프레임 검사하면될까?” 스크립트 파싱 비용? 실행시켜 볼 트리거가 10000개?
- 41. 매 프레임마다 트리거를 실행시키기에는 불필요한 오버헤드가 너무 크다 “매 프레임 검사하면될까?” 스크립트 파싱 비용? 실행시켜 볼 트리거가 10000개? FPS가 1..?
- 42. 뭐야? 결국 사용할 수 없는 시스템이 잖아? 집이나 가자
- 43. 오버헤드를 줄이는 방법을 찾다가 발견한 스타크래프트2 트리거 해답은 바로 이벤트에 있다 이것만 있으면 트리거가 실행될 시기를 지정할 수 있다. 커스텀 맵과 유즈맵이 잘되어 있는 만큼 트리거도 무척 잘 되어 있더라
- 44. 오버헤드를 줄이는 방법을 찾다가 발견한 스타크래프트2 트리거 해답은 바로 이벤트에 있다 이것만 있으면 트리거가 실행될 시기를 지정할 수 있다. 커스텀 맵과 유즈맵이 잘되어 있는 만큼 트리거도 무척 잘 되어 있더라 클릭되어 질 때 실행! 로딩할 때 실행! 죽으면 실 행!
- 45. 이제 필요한 것은 모두 갖췄다. 하지만 총을 쏘려면 총알을 주는 제공자와 총을 쏠 작동자가 필요한 법?! “그건 누구야?”
- 47. “총은 장고가 쏜다?”
- 48. “총은 장고가 쏜다?” 누가 쏠지 모른다 또 총알은 누가 주고? 누가 쏘는 것인지 제공하는 오브젝트가 무엇인지 알 수 없기 때문에 제공자와 작동자는 반드시 정보 제공이 필요하다
- 49. 이제 좀 알 것 같아요! 다음은 뭐에요?
- 51. ?! C++에도 변수가 있고, 스크립트에도 변 수가 있는데 또 무슨 변수?
- 52. 트리거에서도 변수가 사용된 데 알고 있어? 트리거에서? 왜 트리거에도 별도 변수가 필요해?
- 53. 트리거에서 변수 사용은 트리거가 실행 시 필요로 하는 많은 데이터들은 스크립트(모듈) 에게 전해주기 위해서이다.
- 54. 트리거에서 변수 사용은 트리거가 실행 시 필요로 하는 많은 데이터들은 스크립트(모듈) 에게 전해주기 위해서이다.
- 55. “아까 봤던 스타크래프트 맵 에디터 트리거” 못봤다고 하지 말아줘…
- 56. “아까 봤던 스타크래프트 맵 에디터 트리거” 못봤다고 하지 말아줘… 여기에도 있다 지역 변수
- 57. “별거 없네?! 그냥 변수만 저장하면 된다는 이야기잖아?”
- 58. 트리거의 변수는 어떤 데이터가 저장될지 모른다. 때문에 가변형이여야 한다. “스크립트 variant만든다고 생각해”
- 59. 트리거의 변수는 어떤 데이터가 저장될지 모른다. 때문에 가변형이여야 한다. “스크립트 variant만든다고 생각해” 이 변수는 다양하게 사용되므로 속도가 빨라야 하고 편의를 위해 Operator가 정의 되어있어야 한다.
- 60. 트리거의 변수는 어떤 데이터가 저장될지 모른다. 때문에 가변형이여야 한다. “스크립트 variant만든다고 생각해” 이 변수는 다양하게 사용되므로 속도가 빨라야 하고 편의를 위해 Operator가 정의 되어있어야 한다. 대표적으로 boost::any _variant_t(comuti.h) folly::dynamic(facebook lib) 등이 있다. “boost::any는 type_info 때문에 너무 느리고 _variant_t는 오퍼레이터가 한정적이고 Dynamic은 변수타입이 적다…. 만들어야 하나????”
- 61. 트리거의 변수는 어떤 데이터가 저장될지 모른다. 때문에 가변형이여야 한다. “스크립트 variant만든다고 생각해” 이 변수는 다양하게 사용되므로 속도가 빨라야 하고 편의를 위해 Operator가 정의 되어있어야 한다. 대표적으로 boost::any _variant_t(comuti.h) folly::dynamic(facebook lib) 등이 있다. “boost::any는 type_info 때문에 너무 느리고 _variant_t는 오퍼레이터가 한정적이고 Dynamic은 변수타입이 적다…. 만들어야 하나????” 순조로이 행동이 진행될거 같지? 가변형 변수만드는 거 쉽지만은 않을걸…. 일일히 모두 만들어야 한 다고 TT 단위 테스트 수백번이야..
- 62. 또…. 트리거의 변수는 직접적으로 건들여선 안된다. 즉, 트리거는 인스턴스화가 되어지며 인스턴스화 된 데이터를 통하여 트리거를 실행! “트리거의 변수가 변경되면 네가 원하는 결과가 안나올거야”
- 63. 또…. 트리거의 변수는 직접적으로 건들여선 안된다. 즉, 트리거는 인스턴스화가 되어지며 인스턴스화 된 데이터를 통하여 트리거를 실행! “트리거의 변수가 변경되면 네가 원하는 결과가 안나올거야” 이를 위해선 트리거 자체를 Stratgy Pattern을 이용하여 제작 트리거 내부에 정의 되어 있는 변수는 건드리지 않으며 조건 및 행동! “이거 중요하다. 밑줄 땡땡이 무한@@＂
- 64. 또…. 트리거의 변수는 직접적으로 건들여선 안된다. 즉, 트리거는 인스턴스화가 되어지며 인스턴스화 된 데이터를 통하여 트리거를 실행! “트리거의 변수가 변경되면 네가 원하는 결과가 안나올거야” 이를 위해선 트리거 자체를 Stratgy Pattern을 이용하여 제작 트리거 내부에 정의 되어 있는 변수는 건드리지 않으며 조건 및 행동! “이거 중요하다. 밑줄 땡땡이 무한@@＂ 변수를 꼭 만들지 않아도 돼. 스트립트 내부 소스를 볼 수 있다면 가져와서 사용 해도 되겠지. 그럼 그건 내 꺼나 다름 없어 굳이 만들필요 있어?
- 65. “복잡하네 정말! 내가 이걸 실수 없이 잘 할 수 있을까?”
- 66. 실수란 없을 수 없다. “특히나 트리거는 더욱 예민하지.”
- 67. “복잡하네 정말! 내가 이걸 실수 없이 잘 할 수 있을까?”
- 68. “복잡하네 정말! 내가 이걸 실수 없이 잘 할 수 있을까?” 동작
- 69. “복잡하네 정말! 내가 이걸 실수 없이 잘 할 수 있을까?” “내가 사용하려했던 오브젝트가 죽어버렸어! 이 오브젝트가 죽으면 완료는 어떻게 하고 뒤에 있는 행동들은 어떻게 하지?”
- 70. 트리거는 여러 컴포넌트를 사용하며 예상치 못한 오동작이 일어날 수 있고 또, 트리거 진행 중에도 게임도 업데이트 중이므로 논리상 문제가 없더라도 사소한 문제로 인하여 진행을 하지 못할 수도 있다. “대화를 해야하는데 해당 NPC가 사라져버렸어..”
- 71. 트리거는 여러 컴포넌트를 사용하며 예상치 못한 오동작이 일어날 수 있고 또, 트리거 진행 중에도 게임도 업데이트 중이므로 논리상 문제가 없더라도 사소한 문제로 인하여 진행을 하지 못할 수도 있다. 더욱 큰 문제는 오동작이 발생하더라도 반드시 트리거가 진행해야 할 경우도 있는 것이다. “대화를 해야하는데 해당 NPC가 사라져버렸어..” “트리거가 NPC를 죽였다가 살려야 하는데 죽이고 실패해버렸어. NPC없이는 더 이상 진행을 못하는데…?”
- 72. 아.. 밑도 끝도 없는 문제들이여. 버그도 버그지만 이런 런타임 환경은 내가 어찌할 수 없잖아?
- 73. 트리거의 경우에는 2가지의 문제가 발생한다.
- 74. 트리거의 경우에는 2가지의 문제가 발생한다. 환경적인 요인으로 발생하는 실패
- 75. 트리거의 경우에는 2가지의 문제가 발생한다. 환경적인 요인으로 발생하는 실패 프로그래머의 실수나 컴포넌트들의 문 제로 더 이상 트리거가 실행되어서는 안되는 예외
- 76. 이건 실패 으악! 누가 날 공격하래? 예상치 못한 일이 발생할 것을 대비하여 트리거를 여러 개 설치하여 대비한다. “무식하게 여러 개 만드는 것보단 다른 방법이 있겠지? 그건 나중에!”
- 77. Assert? 누가 이 따위 코딩을 로직상 문제인 것은 직접 찾아 고친다. 문제가 발생했다고 프로그램을 종료시키는 것보단 안전하다. 이건 예외 “로그 남기는 게 도움된다.”
- 78. 헤… 이제 별로 안남았고마 조금만 힘내라잉~~ 마지막으로 행위 대상자를 알아보자. “이건 트리거 만들때 중요해”
- 79. 트리거가 실행되어 조건에 충족되었다고 가정하자. 그러고 여러 행동들은 타이밍에 맞춰 시작한다. 행동1 행동2 행동3 행동4 이러한 행동들은 „언제 | 어디서 | 무엇‟을 의미한다 “그런데 누가?”
- 80. 트리거가 실행되어 조건에 충족되었다고 가정하자. 그러고 여러 행동들은 타이밍에 맞춰 시작한다. 행동1 행동2 행동3 행동4 이러한 행동들은 „언제 | 어디서 | 무엇‟을 의미한다 누가 | 언제 | 어디서 | 무엇
- 81. 그것이 무엇인지도 모르고 사용한다는 것은 말도 안되는 일이오.
- 82. 트리거가 컨트롤할 오브젝트를 몰라서야 되겠 어? 트리거는 특정 몇몇 부분만 사용하는 것이 „NPC, UI, Scene, Player‟ 등 다양하게 사용될 수 있단 말이야! 그러니까 적어도 이 모두를 포함할 수 있는 공통된 인터페이스가 필요해! 트리거에 특화된 클래스를 만들어 오브젝트들 이 이를 상속받아도 좋고 말이야! 하루히님의 말씀
- 83. Object obj =ObjectContainer.find(_idx); if( !obj ) return false switch( _idx.type() ) { case index::efffect : effect efc = EffectContainer.find(_idx); … break; case index::npc : npc n = NpcContainer.find(_idx); … break; } “솔직히 이것보단…” “이게 낫잖아?” 간단한 예제 이건 시작에 불과해…
- 84. 컨트롤하려는 대상을 명시한다는 것이 어쩌면 불필요한 일일지도 모른다. 어차피 대상을 담을 가변형 변수는 무엇이든 담을 수 있도록 제작되었으니 말이다. 하지만 공통적 인터페이스를 가졌다는 것은 때로 트리거에게 큰 도움이 될 때가 있다. 모두 규격화시킬 수 있기 때문이다. “라이브러리 개발이라면 그래도 고려한번 쯤..” “각각 다른 컴포넌트 모두 예외처리를 하겠소이까..?” 벌써 까먹은거 아니지?
- 85. “수고하셨습니다.”
- 89. “트리거가 무어란 말인 가?” “구성요소를 빠뜨릴 수 없지!” “트리거의 유전자 조작”
- 90. 지금까지 배운 개념으로는 아주 간단한 트리거를 만드는데는 무리가 없다. Action( 행동 ) variant_field Bool condition(실행자,제공자) Bool excute(실행자,제공자) trigger variant_field Bool instance(trigger) trigger_context Action( 행동 ) Action( 행동 ) action_container scheduler 문제 없이 잘 돌아감!
- 91. 지금까지 배운 개념으로는 아주 간단한 트리거를 만드는데는 무리가 없다. Action( 행동 ) variant_field Bool condition(실행자,제공자) Bool excute(실행자,제공자) trigger variant_field Bool instance(trigger) trigger_context Action( 행동 ) Action( 행동 ) action_container scheduler 하지만 이것으로는 부족하다. “나는 욕심많은 남자 후후훗?!”
- 92. “저거면 되는 거 아니였어?”
- 93. 앞서 이야기한 개념들을 활용 하면 훨씬 다양한 트리거를 만들어 낼 수 있다. “이것이 진짜 배기지!” 이러한 다양한 트리거를 한번 알아보고자 한다.
- 94. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 95. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 96. 결정 트리란 질문을 점차 세분화 시킴으로 서 보다 알맞은 해답을 찾는 것을 의미한다. “이것을 트리거에 적용한다면?”
- 97. 한 트리에서 다양한 행동 패턴을 만들 수 있 으며 이러한 패턴은 다양한 방면에서 사용 될 수 있다. 조건 조건 조건 조건 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건
- 98. 한 트리에서 다양한 행동 패턴을 만들 수 있 으며 이러한 패턴은 다양한 방면에서 사용 될 수 있다. 조건 조건 조건 조건 조건 한 트리거에서 하나밖에 실행하지 못한다면 너무 비생산적이잖아? 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건
- 99. “결정 트리는 AI 설계에서도 이용된다고!!” “잘만 사용하면 정말 좋은 자료구조야!”
- 100. 트리거에서의 결정트리는 단순히 해답 찾기용 이상으로 활용되어질 수 있다.
- 101. 단순히 조건만 판별하던 노드를 모두 트리거로 변경. 이로써 좀더 다양한 패턴을 양산할 수 있다. 트리거에서 의사 판별만 하고 싶다면 행동을 넣지 않으면 돼. 별거 없지? 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건
- 102. 다양한 활용을 위해 트리거를 복사붙여 넣기하던 짓, 이제 않 해도 되는건가? 행복해 @..@
- 103. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 104. 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 지연평가 트리거 역시 결정 트리를 이용하여 제작할 수 있다. 결정 트리 트리거에 지연평가를 한다면..
- 105. 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 행동 조건 지연평가 트리거 역시 결정 트리를 이용하여 제작할 수 있다. 결정 트리 트리거에 지연평가를 한다면.. 완료 후 실행완료 후 실행 완료 후 실행 완료 후 실행 완료 후 실행 완료 후 실행 완료 후 실행 완료 후 실행 완료 후 실행 완료 후 실행완료 후 실행 어렵지 않게 제작할 수 있어. 단지 앞서 실행한 트리거가 완료되었는지 확인하면 돼.
- 106. “제길, 안그래도 머리가 복잡한데 굳이 이걸 사용할 필요가 있어?”
- 107. 지연 평가를 사용하면 다음과 같은 설정이 가능하다. Player “너 1.1까지 가” 인덱스 1 트리거 실행
- 108. 지연 평가를 사용하면 다음과 같은 설정이 가능하다. Player 다음 트리거 시행! [조건] 1.1오는데 1 초 이하면 말풍선! 아니면 하지마!
- 109. 지연 평가를 사용하면 다음과 같은 설정이 가능하다. Player 다음 트리거 시행! [조건] 1.1오는데 1 초 이하면 말풍선! 아니면 하지마! $@!$! %@! 플레이어가 „1.1‟까지 평가를 늦춰 현 상황에 보다 알맞은 트리거를 실행하는 것!
- 110. 지연 평가 트리거를 이용하면 2개 이상 필요하였던 트리거를 단 하나만 있어도 모두 표현이 가능하다! “나의 경우 실패 처리도 지연 평가를 통해 해!”
- 111. “우오오와 만두보다 더 대단한 걸?”
- 112. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 113. 아..안돼. 그러나 서버에서는 동작이 불가능하단 말이야!
- 114. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다.
- 115. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다. “정상적으로 실행이 되려면 유기적 관계여야만 하는데 클라이언트 접속상태는 보장되지 않아!”
- 116. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다. “스케쥴러를 설치해야하는데 어디에 설치해?!”
- 117. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다. “물리적 서버, 논리적 서버가 트리거 사용에 문제가 되네?!”
- 118. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다. “몇몇 컨텐츠는 별도 서버에서 관리되는데 동기화 맞추기가 쉽지 않아!!”
- 119. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다.
- 120. 지금까지 이야기한 트리거들은 사실 서버에서는 사용하기가 적절하지가 않다. 쉽지가 않을 뿐이다.
- 121. 애초에 트리거를 고려해주지 않으니 트리거가 서버에 맞춰 제작하려고 한다면 한계가 있기 마련이다.
- 122. 애초에 트리거를 고려해주지 않으니 트리거가 서버에 맞춰 제작하려고 한다면 한계가 있기 마련이다. 여기 나도 있어요!!!! 트리거 왈 “효과적인 서버구조는 많지만 트리거를 고려해주는 구조는 없어”
- 123. 클라이언트 접속 상태는 안전하지 않으므로 유동적인 자료는 트리거 변수에 저장하라! “트리거 변수 잊지 않았지? 변수는 여기서 큰 힘을 발휘해!”
- 124. 클라이언트 접속 상태는 안전하지 않으므로 유동적인 자료는 트리거 변수에 저장하라! 서버의 물리적 논리적 단위에 맞춰 스케쥴러를 작동하고 구조적으로 동기화를 맞출 방법을 강구하라! “트리거 변수 잊지 않았지? 변수는 여기서 큰 힘을 발휘해!” “병행 프로세스! 락을 최대한 줄여봐! DOD, Lock Free같은 방법론도 있어!”
- 125. 클라이언트 접속 상태는 안전하지 않으므로 유동적인 자료는 트리거 변수에 저장하라! 안녕, 오랜만이야. 나 정말정말 보고 싶었지? 미안하지만 내 취향 아니야 서버의 물리적 논리적 단위에 맞춰 스케쥴러를 작동하고 구조적으로 동기화를 맞출 방법을 강구하라! 서버에서 작동하는 트리거는 모듈화 시키자! 서버만이 알 뿐 클라이언트가 관여 혹은 영향을 주어서는 안된다! “트리거 변수 잊지 않았지? 변수는 여기서 큰 힘을 발휘해!” “클라와 서버는 상호작용하지만 적어도 트리거에서는 안돼! 절대적인 환경요소만을 트리거에서는 체크해야 돼! ” “병행 프로세스! 락을 최대한 줄여봐! DOD, Lock Free같은 방법론도 있어!”
- 126. 트리거는 항상 뒷전이야! 컴포넌트 별로 모두 분석해야한다고!
- 128. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 129. 트리거를 이용하여 어느 오브젝트에게 명령했다고 가정하자 그럼 그 오브젝트는 뭘하고 있겠는가? “하긴 뭘해, 트리거가 지정한 행동을 하겠지”
- 130. “지금 그걸 문제라고 낸거야? 엉?”
- 131. 정 말?
- 132. 스킬 발동!
- 133. 스킬 발동! ?
- 134. “도대체 뭐가 문제 인지 모르겠어” 분명 트리거는 조건 만족했는데..
- 135. 트리거가 컨트롤하는 대상 즉, 오브젝트의 특성에 대해 생각해보았는가? 트리거 이외에 오브젝트를 컨트롤하는 것 없는지 생각해봐야 한다! “AI, UI도 오브젝트를 컨트롤하지. 한마디로 간섭이 많아;;”
- 136. 트리거가 컨트롤하는 대상 즉, 오브젝트의 특성에 대해 생각해보았는가? 트리거 이외에 오브젝트를 컨트롤하는 것 없는지 생각해봐야 한다! 트리거가 하려는 행동 또 다른 명령에 의하여 무시될 수도 있다. “이때는 어떻게 해야 돼?” “AI, UI도 오브젝트를 컨트롤하지. 한마디로 간섭이 많아;;”
- 137. 하지만 게임 환경에 발생 되는 수 많은 명령들 이것을 해결할 방법을 우리는 이미 알고 있다.
- 138. 동기 실행과 비동기 실행 이것을 이용하면 말끔히 해결 끝 해피해피~&&
- 139. 동기 실행은 트리거가 명령한 커맨드를 우선적 처리! “자기가 하던 일은 멈춰야 겠지?”
- 140. 동기 실행은 트리거가 명령한 커맨드를 우선적 처리! 비동기 실행은 트리거가 명령하더라도 자신의 하던 일은 계속하는 것이다! 비동기 시에는 명령 무시에 대한 대비할 것! “자기가 하던 일은 멈춰야 겠지?”
- 141. 동기 실행은 트리거가 명령한 커맨드를 우선적 처리! 동기 실행이 반드시 안전 한 것만은 아니야. 때로는 트리거보다 우선순위가 높 아야 할때도 있어. 어려우면 포기하면 돼~ 비동기 실행은 트리거가 명령하더라도 자신의 하던 일은 계속하는 것이다! 비동기 시에는 명령 무시에 대한 대비할 것! 동기 실행과 비동기 실행을 혼용하여 사용할 경우는 반드시 문제가 없는지 확인해야 함! “자기가 하던 일은 멈춰야 겠지?” “꼭 필요 것만 동기 실행하도록~”
- 142. 정신줄 놓지마!
- 143. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 144. 트리거 라이브러리를 개발한다면 효과적으로 여러 프로젝트에 즉시 사용될 수 있지.
- 145. 트리거에겐 일정한 규칙이 있다. 이를 활용한다면 충분히 라이브러리를 개발할 수 있다. 나도 개발중이라서..
- 146. 위의 코드는 트리거 라이브러리 코드 trigger_make_namespace( “test”, …/*namespace의 옵션 설정*/ ); set_trigger_namespace( “test” ); var t1 = create_trigger(1); t.add_ConditionCB ( trig_bind(checkHP,150) ); t.add_ConditionCB( trig_bind(checkLevel,50) ); t.add_ActionCB( tirg_bind(runActor, make_pos(2,2)), true, 1.0f ); var t2 = create_trigger(2); var t3 = create_trigger(2); t1.attachChild( t2 ); t1.attachChild( t3 ); t.save( “filename.trg” ); var c = create_context(); c.insertField( make_trigvar( “time”, 0.0f ) ); c.insertField( make_trigvar( “name”, “실행확인” ) ); c.excute(t1); Callback func „Test‟ Namespace Trigger variant파일 세이브 Trigger excute 완료 후 실행 실행 시간
- 147. trigger_make_namespace( “test”, …/*namespace의 옵션 설정*/ ); set_trigger_namespace( “test” ); var t1 = create_trigger(1); t.add_ConditionCB ( trig_bind(checkHP,150) ); t.add_ConditionCB( trig_bind(checkLevel,50) ); t.add_ActionCB( tirg_bind(runActor, make_pos(2,2)), true, 1.0f ); var t2 = create_trigger(2); var t3 = create_trigger(2); t1.attachChild( t2 ); t1.attachChild( t3 ); t.save( “filename.trg” ); var c = create_context(); c.insertField( make_trigvar( “time”, 0.0f ) ); c.insertField( make_trigvar( “name”, “실행확인” ) ); c.excute(t1); 위의 코드는 트리거 라이브러리 코드 가 아닌 이상적인 트리거 스크립트이다. 나도 이렇게까진 개발하지 못한… Callback func „Test‟ Namespace Trigger variant파일 세이브 Trigger excute 완료 후 실행 실행 시간
- 148. “뭐? 트리거 스크립트라고??”
- 149. 무조건 프로그래머가 하라는 법이 어딨어?
- 150. 트리거 라이브러리를 바인딩할 스크립트를 정하여 라이브러리와 함께 개발!
- 151. 트리거 라이브러리를 바인딩할 스크립트를 정하여 라이브러리와 함께 개발! 네임스페이스를 통하여 트리거들은 독립성을 지키며 네임스페이스만의 특성을 유지 “한 종류의 트리거만 사용하진 않아!!”
- 152. 트리거 라이브러리를 바인딩할 스크립트를 정하여 라이브러리와 함께 개발! 툴 개발도 좋지만 스크립 트를 이용하면 훨씬 유용하게 사용할 수 있어. 이유는 다음 장에! 툴 개발이 싫어서 그런거야 네임스페이스를 통하여 트리거들은 독립성을 지키며 네임스페이스만의 특성을 유지 해당하는 스크립트와 트리거 DLL만 있으면 즉시 사용가능! “한 종류의 트리거만 사용하진 않아!!” “정적 템플릿 라이브러리 개발하지마TT”
- 153. 툴을 이용하는 것은 생각보다 가독성이 좋지 않다. 단일(단위실행) 하면 모를까. 기능이 많아지고 복잡할수록 혼란스러워 진다. “기본으로 트리 형식에 툴에서 변수 표현하기가 어렵다…”
- 154. 런타임 환경에서 트리거를 유연하게 컨트롤할 수 있다. 툴을 이용하는 것은 생각보다 가독성이 좋지 않다. 단일(단위실행) 하면 모를까. 기능이 많아지고 복잡할수록 혼란스러워 진다. “런타임 환경에서 트리거를 attach,detach 할 수 있는 장점! 생성,저장도 가능!” “기본으로 트리 형식에 툴에서 변수 표현하기가 어렵다…”
- 155. 런타임 환경에서 트리거를 유연하게 컨트롤할 수 있다. 스크립트를 보면서 기획자도 트리거가 돌아가 는 것을 대강이나마 알 필 요 있어. 트리거의 적은 트 리거가 아니거든…. 나도 스크립트로 개발하고파 툴을 이용하는 것은 생각보다 가독성이 좋지 않다. 단일(단위실행) 하면 모를까. 기능이 많아지고 복잡할수록 혼란스러워 진다. 단지 콜백만 등록하면 되기 때문에 모듈적 설계가 가능하며 스크립트를 활용하여 부가 기능도 가능! “런타임 환경에서 트리거를 attach,detach 할 수 있는 장점! 생성,저장도 가능!” “기본으로 트리 형식에 툴에서 변수 표현하기가 어렵다…” “스크립트를 활용하는 것이니 간단한 계산능력부터 시작해서!”
- 156. “너는 이해를 했느냐? 이 얼마나 유연한 트리거 라이브러리인지? ”
- 157. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 뉴런
- 158. “넌 나에게 똥을 줬어!” 퍼지 이론에 들어가기 앞서 위키 힘을 빌려 퍼지이론이 무엇인지 확인하자
- 159. “넌 나에게 똥을 줬어!” 퍼지 이론에 들어가기 앞서 위키 힘을 빌려 퍼지이론이 무엇인지 확인하자
- 160. “넌 나에게 똥을 줬어!” 퍼지 이론에 들어가기 앞서 위키 힘을 빌려 퍼지이론이 무엇인지 확인하자 ..?
- 161. 간단히 말해 불분명한 상태를 의미합니다. 컴퓨터는 보통 2진 데이터로서 0,1을 표현하는 데 이러한 0과 1은 참과 거짓을 의미합니다. 퍼 지 이론은 참과 거짓을 확장하여 해석하는 방법 론을 말합니다. 즉, „거짓‟ „덜 거짓„ „중간„ „거짓에 가깝„ „확실 한 참„ 등 보다 현실 세계를 반영하는 논리를 뜻 합니다.
- 162. 그런데 이걸 어디에다가 써먹을까?
- 163. 그런데 이걸 어디에다가 써먹을까? “선택”
- 164. “트리거에게 조건이 있다 하더라도 모두 정확 한 판단을 할 수 있는 것은 아니다.”
- 165. “트리거에게 조건이 있다 하더라도 모두 정확 한 판단을 할 수 있는 것은 아니다.”
- 166. “퍼지 이론은 트리거에게 능동적 사고판단을 할 수 있게 하여준다.”
- 167. “하나만 골라줄래?” (트리거)돈 없어. 네가 사먹어
- 168. 결정 트리 트리거 지연평가 트리거 서버 수준 트리거 동기/비동기 실행 트리거 라이브러리 퍼지이론 신경망 알고리즘
- 169. “넌 나에게 똥을 줬어!” 이번에도 역시 용어 설명을 위해 구글링해서 관련 자료를 찾아보았다.
- 170. “넌 나에게 똥을 줬어!” 이번에도 역시 용어 설명을 위해 구글링해서 관련 자료를 찾아보았다.
- 171. “넌 나에게 똥을 줬어!” 이번에도 역시 용어 설명을 위해 구글링해서 관련 자료를 찾아보았다. ……
- 172. 한마디로 패턴 혹은 행동을 분석하여 좀 더 빠르고 올바른 답을 찾는 알고리즘이다.
- 173. 한마디로 패턴 혹은 행동을 분석하여 좀 더 빠르고 올바른 답을 찾는 알고리즘이다. 트리거는 신경망 알고리즘을 이용하여 여러 패턴을 분석하고 확장할 수 있다. “트리거 개별 하나하나가 뉴런이 되는 것!”
- 174. 어디에 이용할 수 있을까? 서버 관리, 동적인 환경 표현, AI,능동적인 컨텐츠 확장, 이벤트 등
- 175. 아직 생각뿐이라지만 충분히 가능성은 있다. 학습하고 능동적인 어플리케이션을 만드는 것
- 176. 개별적인 트리거는 각 뉴런이 되며 신호를 주고 받으며 최적의 결론을 도출하는 것. 이것이 트리거의 최종 진화체가 아닐까라는 생각을 한다.
- 177. 나는 이제 트리거 마스터이다!!
- 178. “여기까지 오느라 수고 많았어.”
- 179. 트리거에 대하여 보다 쉽고 재미있게 설명할 수 있도록 PT를 제작하였다. 슬라이드가 좀 많긴 했지만 최대한 많은 내용을 전달하기 노력했던 것 같다. 사실 트리거와 관련하여서만 이야기 하였지만 능동적인 트리거를 개발하면 트리거 개발 자체보다는 더욱 심각한 문제를 많이 겪곤 한다. 코드는 프로그래머가 작성하지만 사용하 는 것은 기획자로서 예상 못한 로직을 구현하기도 한다. 뿐만 아니라 일관되지 않은 컴포 넌트들과 메모리 관리 문제, 속도 문제, 동기화 문제, 데이터 호환 문제, 컨텐츠 추가 문제 도 다수 겪기도 한다. 고작 경력 갓 1년이 된 새내기인 내가 자신하며 남들 앞에 당당히 이야기하기는 어려우나 지난 1년간 트리거를 위해 정말 많은 생각을 하였다. 마지막 부분의 „트리거 라이브러리 „라는 목차의 경우 무려 10시간 이상을 할애하여 작성한 것으로 “어떻게 하면 효과적인 라 이브러리를 개발할 수 있을까”라는 생각을 최대한 짜내어 만든 것이다. 회사 내에서는 스 크립트로 작성하는 것이 아닌 정적 라이브로서 프로그래머인 내가 일일이 설정하여주고 설명해주고 있어 평소에도 트리거 자체를 스크립트로 개발하면 내가 할 일을 덜어 없앨 수 있지 않을까하며 했던 생각을 이번 PT를 통하여 문서화 한 것이다. 국내에는 트리거 자료가 많이 없다. 스타크래프트의 맵 에디터를 보면서 어떻게하면 효과 적으로 만들 수 있지 않을까 하며 만들었던 것이 지연평가 트리거까지 만든 것이다. 이 사 실(구조 구성)은 후에 AI 파트 담당자분과 이야기하며 알게 된 것으로 여기에 담당자분께 얼핏 들은 퍼지이론과 신경망 알고리즘까지 덧붙여 트리거의 확장가능성을 엿 보았다. 후에는 정말 고성능의 트리거를 만들 수 있을지 확신할 수 없지만 앞으로도 계속 프로그래밍은 할 것이니..^^ 마지막으로..
- 180. The End.. 이제 없으니까 공부나 하자