Difference between r1.1 and the current
@@ -1,3 +1,114 @@
[[Tableofcontents]]
== 연사자 소개 ==
* 권준혁
* CAUCSE 14학번
* ZeroPage 24
* Steamers 7기 회장
== 기획을 편하게 하는 프로그래밍 ? ==
* 코드 깔끔? , 에러처리 ?
* 삽질!
== 발표 내용 ==
* ProjectAI 개발과정에서의 난관 / 극복 사례
* 기획이 놀게 해주는 프로그래밍 방법
* 프로그래머가 기획을 하게 되면
== ProjectAI란? ==
* 어드벤처 + 액션||퍼즐
== 지금 다시 개발하라면 이렇게 한다. ==
* '''성급하게 개발에 들어가지 말자'''
* 기획을 하면서 프로그래머와 이야기를 하며 게임의 구조를 대충 그려본다.
* 전체적으로 어떻게 해야될 지에 대한 가이드 라인을 잡는다.
* 그렇지만 이 단계에서 모든 것이 결정되는 것은 아니다.
* 게임 제작은 도중에 많이 바뀐다!
* 어느 부분에서 확장성을 둘 것인지를 , 어느 부분은 안 바뀔 것인지를 잘 정해야한다.
* 간간한 게임이라도 중간에 변경은 생긴다.
* 프로그래머가 나중에 대응하기 쉽게 잘 고려해야 한다.
* 어떤게 추가될 수 있고 없고도 말해두는 게 좋음
* 프로그래머측도 이 과정에서 일반화할 것과 안 할 것을 생각할 수 있다. -> 비용 감축
* ProjectAI는 스토리 라인이 2개, 친밀도에 따른 스토리 변화 등등 하고 싶은 게 많았지만 처음에 제대로 생각을 못해서 지금 그런 것을 못합니다.
* 근데 사실 그게 말처럼 쉽게 되는 건 아님
* '''주기적인 스파이럴'''
* 게임은 결국 재밌으려고 하는 것이다.
* 직접 해보면서 어떻게 바뀌어 가는지 확인해봐야한다.
* 기획서만으로는 확인 못하는 것이 많다.
* 사이클을 돌려가면서 게임이 잘 되어가고 있는지 확인한다.
* 다른 사람의 코드를 보는 일이 최대한 없이, 게임의 컨텐츠를 바꿀 수 있어야 함.(이해하는 데 시간이 듬)
* 코드에서 데이터를 직접 가지는 것은 좋지 않음.
* 데이터의 변경으로 간단히 게임의 컨텐츠를 바꿀 수 있어야 함.
ex) 퍼즐의 구조, 맵의 구조, 스토리의 진행도, 엔딩의 조건
* '''컴퓨터가 할 수 있는 건 컴퓨터에게'''
* 퍼즐이 정상적인가 검사하는 것 등은 컴퓨터가 할 수 있다.
* 퍼즐을 자동 생성 할 수도 있다.
* 근데 데이터의 양이 방대해지면 바꾸기도 힘듬
* 어떤걸 바꿔야 내가 원하는대로 가는지도 모름
* '''데이터와 툴의 중요성'''
* 툴의 퀄리티가 제작 속도를 결정한다.
* 툴은 잘 만들자
* 그리고 나중에 데이터 구조 바꿀 수 있으니 그것도 신경쓰자.
* 그리고 제발 xml이나 json쓰자
* 좋은거 있으면 그거 쓰자.
* '''의도 전달'''
* 기획을 전할 때는 그 의도를 전달한다.
* 조금만 바꿔서 의도 그대로 간단하게 구현할 수 있을 수도 있다.
* '''리소스, 데이터 관리 갓-클래스'''
* UI만들 때 편함
* 가져다 쓰기 편함
* 세이브 로드 하기 편함
* 무거워져봤자임
* 통로만 잘 만들어 놓으면 됨
* '''프로그래머가 기획하면 생기는 일'''
* 기획을 하는데 왠지 코딩 귀찮다 싶으면 안하려고 함
* 제일 피해야 되는 자세
* 아무래도 가성비를 따지게 되는 듯
* 특히 나는 내가 직접 해야해서 더 그랬음
* 왠지 문제가 있으면 내가 바꾸면 될 것 같음
* 구조를 알고 있으니 왠지 그럴 수 있을 것 같음
* 그렇다고 해서 모든 구조를 꿰고 있는건 아니었다.
* 이런 안이한 마음가짐으로 하다가 데이터가 많아지니 감당이 안 됨
* 프로그래머 아니여도 건드릴 수 있게 해둬야 하는 게 중요한 듯.
* 컴공틱하게 됨.
* 제발 다른 사람 대상으로도 테스트합시다.
== 실제 게임 기획 데이터 (이렇게 하지 마세요) ==
* XML 분리
* 조건을 변경하려면?
* 폴더 구조
* 이미지명 prefix로 하자
* 스테이지별 txt
5. 지금 다시 개발하라면 이렇게 한다. ¶
- 성급하게 개발에 들어가지 말자
- 기획을 하면서 프로그래머와 이야기를 하며 게임의 구조를 대충 그려본다.
- 전체적으로 어떻게 해야될 지에 대한 가이드 라인을 잡는다.
- 그렇지만 이 단계에서 모든 것이 결정되는 것은 아니다.
- 게임 제작은 도중에 많이 바뀐다!
- 어느 부분에서 확장성을 둘 것인지를 , 어느 부분은 안 바뀔 것인지를 잘 정해야한다.
- 간간한 게임이라도 중간에 변경은 생긴다.
- 프로그래머가 나중에 대응하기 쉽게 잘 고려해야 한다.
- 어떤게 추가될 수 있고 없고도 말해두는 게 좋음
- 프로그래머측도 이 과정에서 일반화할 것과 안 할 것을 생각할 수 있다. -> 비용 감축
- ProjectAI는 스토리 라인이 2개, 친밀도에 따른 스토리 변화 등등 하고 싶은 게 많았지만 처음에 제대로 생각을 못해서 지금 그런 것을 못합니다.
- 근데 사실 그게 말처럼 쉽게 되는 건 아님
- 기획을 하면서 프로그래머와 이야기를 하며 게임의 구조를 대충 그려본다.
- 주기적인 스파이럴
- 게임은 결국 재밌으려고 하는 것이다.
- 직접 해보면서 어떻게 바뀌어 가는지 확인해봐야한다.
- 기획서만으로는 확인 못하는 것이 많다.
- 사이클을 돌려가면서 게임이 잘 되어가고 있는지 확인한다.
- 다른 사람의 코드를 보는 일이 최대한 없이, 게임의 컨텐츠를 바꿀 수 있어야 함.(이해하는 데 시간이 듬)
- 코드에서 데이터를 직접 가지는 것은 좋지 않음.
- 데이터의 변경으로 간단히 게임의 컨텐츠를 바꿀 수 있어야 함.
ex) 퍼즐의 구조, 맵의 구조, 스토리의 진행도, 엔딩의 조건
- 게임은 결국 재밌으려고 하는 것이다.
- 컴퓨터가 할 수 있는 건 컴퓨터에게
- 퍼즐이 정상적인가 검사하는 것 등은 컴퓨터가 할 수 있다.
- 퍼즐을 자동 생성 할 수도 있다.
- 근데 데이터의 양이 방대해지면 바꾸기도 힘듬
- 어떤걸 바꿔야 내가 원하는대로 가는지도 모름
- 퍼즐이 정상적인가 검사하는 것 등은 컴퓨터가 할 수 있다.
- 데이터와 툴의 중요성
- 툴의 퀄리티가 제작 속도를 결정한다.
- 툴은 잘 만들자
- 그리고 나중에 데이터 구조 바꿀 수 있으니 그것도 신경쓰자.
- 그리고 제발 xml이나 json쓰자
- 좋은거 있으면 그거 쓰자.
- 툴의 퀄리티가 제작 속도를 결정한다.
- 의도 전달
- 기획을 전할 때는 그 의도를 전달한다.
- 조금만 바꿔서 의도 그대로 간단하게 구현할 수 있을 수도 있다.
- 기획을 전할 때는 그 의도를 전달한다.
- 리소스, 데이터 관리 갓-클래스
- UI만들 때 편함
- 가져다 쓰기 편함
- 세이브 로드 하기 편함
- 무거워져봤자임
- 통로만 잘 만들어 놓으면 됨
- UI만들 때 편함
- 프로그래머가 기획하면 생기는 일
- 기획을 하는데 왠지 코딩 귀찮다 싶으면 안하려고 함
- 제일 피해야 되는 자세
- 아무래도 가성비를 따지게 되는 듯
- 특히 나는 내가 직접 해야해서 더 그랬음
- 왠지 문제가 있으면 내가 바꾸면 될 것 같음
- 구조를 알고 있으니 왠지 그럴 수 있을 것 같음
- 그렇다고 해서 모든 구조를 꿰고 있는건 아니었다.
- 이런 안이한 마음가짐으로 하다가 데이터가 많아지니 감당이 안 됨
- 프로그래머 아니여도 건드릴 수 있게 해둬야 하는 게 중요한 듯.
- 컴공틱하게 됨.
- 제발 다른 사람 대상으로도 테스트합시다.
- 기획을 하는데 왠지 코딩 귀찮다 싶으면 안하려고 함
