No difference found
이 페이지는 뭔가 ¶
- Data Driven Development라고 게임 개발쪽에서 자주 쓰이는 개발 패러다임이 있는데 국내에 어째 자료를 못찾겠어서 나름 정리해볼려고 만든 페이지
- Table Driven Development라고 불리기도 하는 것 같다.
주의! ¶
참고 자료 ¶
http://www.gamedevforever.com/12
http://samarian.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%93%9C%EB%A6%AC%EB%B8%90-%EB%B0%A9%EC%8B%9D%EC%9D%84-%ED%86%B5%ED%95%9C-%ED%95%98%EC%9D%B4%EB%B8%8C%EB%A6%AC%EB%93%9C-%EC%95%B1%EA%B0%9C%EB%B0%9C%ED%95%98%EA%B8%B0
http://www.slideshare.net/sehyeonnam9/10-38127704
http://www.gamedevforever.com/12
개요 ¶
- 간단히 말해서, 하드코딩 하지 말고, 좀 데이터로 빼라는 말
- 좀 풀어 말해서, 프로그램 안에다가 로직을 넣지 말고, 프로그램이 돌아가는 것을 외부 데이터를 통해서 관리하는 방식.
- 스크립팅 언어가 이를 위한 도구임.
장점 ¶
- 하드코딩 했을 경우, 기획자는 테스트를 하기 위해서 개발자를 거쳐야 된다. 이 비용 발생 자체가 오버헤드고, 이때문에 기획자가 테스트를 꺼릴 수도 있다. 여튼 안좋다.
- 게임 내부의 로직을 데이터로 움직일 수 있게 하면 기획자는 프로그래머를 거치지 않고 그 데이터만을 수정함으로써 자신의 기획을 테스트해 볼 수 있다.
- 기획자와 개발자의 영역이 분리된다는 점도 있을 듯?
- 다양한 플랫폼에 따라서 내부에서 분기를 해 줄 필요가 없다. 그저 다른 플랫폼 용 데이터만을 선택해서 작동시키면 되는 일이다.
- 퀘스트 로직이 잘못 되었을 때, 유저가 프로그램을 재설치하지 않고 그 로직에 관련된 파일만을 교체시키면 된다.
- 유저가 만드는 확장 프로그램. 어느정도 데이터 드리븐으로 구현되어있느냐에 따라 달라지긴 할듯.
주의해야 할 점 ¶
- LUA같은 것으로 Data를 만든다고 할 때, 프로그래머는 최소의 기능만 제공해주고 어떤 기능의 로직을 이것으로 구현하는 것은 방향이 다르다.
- 예를 들어서, 퀘스트 구현을 한다고 할 때, 기획자는 '어떤' NPC가 '이런' 텍스트의 부탁으로 '이만큼' 시간안에 '무슨 물건'을 가지고 오는지만을 정의해서 퀘스트를 만들 수 있어야 하지, 퀘스트의 실행부터 팝업창의 실행, 타이머 조작 등의 세세한 것까지 만지게 하면 안된다는 것이다. 정도의 문제이다.
- 하지만 이 프로그램이 추후 변동될수 있을지를 생각해보자. 또한 프알못이 이걸 건드릴 일이 있나 생각해보자.
예시 ¶
- 데이터 드리븐으로 하면 각 설정별 XML파일을 만드는 것으로 새로운 레이아웃을 만들 수 있음. 심지어 XML파일만 갈아끼면 되니 서버에 XML파일을 저장해놓고 상황에 맞게 바꿀 수도 있음.
- 데이터 드리븐이 아니면 사실상 프로그래머가 그 모든 텍스트 출력을 다 해야함,,, 보통은 데이터 포맷을 정의하고 이 방식대로 시나리오 라이터 또는 스크립터가 작성하면 프로그램 내부구조 몰라도 돌아가게 짬. 대부분의 노벨게임 엔진이 이런식.
- 데이터 드리븐 안하면 실제 반영되지 않을 내용도 기획자가 보려면 프로그래머가 고쳐야됨. 발 * 암