
일단 젤 왼쪽에 붙어있는 전체적으로 관리의 기능을 하는 관리자윈도우에 필요한기능은
파일을 불러왔을때 파일의 정보를 알려주거나 애니메이션추가,이름변경,프레임추가,컬러키설정
과 같은일을 담당하면될것같습니다.
그러면 한번 이제 윈도우에 컨트롤들을 만들어 배치해보겠습니다.
자 저번에 파일의 구조를 모델링해봤습니다...(누구랑말하니....)
이번엔 기본적인 윈도우의 화면을 구성해보려합니다.
그렇다면 다시 다른분의 스프라이트툴을 분석해봅시다...
자 그러면 이제 대충 우리가 만들어줘야하는 윈도우의 모습이 보이는데요
이젠 어떤식으로 코드를 작성할지 고민해봐야겠는데요
하나의 윈도우클래스를 제작하고 그것으로 여러개의 윈도우를 다른속성으로 만들지
아니면 윈도우마다 제각기 다른윈도우를 만들어 줄지말이죠.
나중에 만약 추가윈도우를 구성할때를 생각해보면 위의 두방법 말고
한개의 컴포넌트윈도우를 만들고 윈도우마다 그것을 상속받아 각자의 특성에 맞게
작동하게 구성하면 될것같다.
스프라이트툴이라 함은 곧 게임툴!! 게임에서 쓰이게 될 리소스들을 수정하고 편집하는데 쓰이게될껍니다.!!
리소스들을 수정하고 저장하게 되면 무엇이 생성되죠? 예 그렇습니다. 파일이죠~_~ (혼자묻고 혼자답하기)
예전에 스프라이트툴을 만들기전에 2D그래픽 기초를 하고있었을때는 그림파일따로 프레임값을 저장해둔 텍
스트파일 따로 따로 저장하거나 아예 프로그램상에 넣어놨었는데 이게 게임개발하다보면 귀찮은일이란걸
깨닫게 되어서 이젠 우리가 만들 파일의 구조를 모델링 해보도록해요.~_~
Kell 2009/02/03 14:03 Modify/Delete Reply Address
예전에 이와 비슷한 방식으로 스프라이트 데이타를 구성한적이 있었는데요. 뭐 나쁘진 않았으나 비트맵을 사용하다보니 아무래도 리소스 크기가 커지고,
비트맵 데이타가 직접 데이타 포맷에 포함되다 보니 리소스 변경만으로 노려볼 수 있는 효과(같은 크기의 비트맵의 다른 캐릭터), 리소스는 냅두고 여러가지 프레임을 생성하는 효과 등등을 효율적으로 관리하지 못했던게 생각이 납니다..;
또 중간에 데이타를 교체해야 하는 경우도 관리하기가 힘들었던 생각이 나네요. (툴에 그 기능을 추가하긴 했지만..;)
Kell's SpriteTool
저번에 만들었던 Kyma스프라이트툴의 소스가 날라가버리고 실행프로그램만 남았기에
이번에 스프라이트툴을 새로만들어볼까합니다. -_-
사실 저번에 만들었던 스프라이트툴이 개막장이라 유지/보수가 힘든 이유도 있었고
포맷할때 고의적으로 남겨두었달까... 젠장 ㅠㅠ
고로 이번엔 쓸만하면서도 나중에 유지/보수가 어렵지않은 스프라이트 툴을 제작해보기로 하겠습니다.
자 그럼 일단 무작정 코드를 짜던 습관을 버리려고 이런 글을 쓰면서 제작하기로 한거니
일단 개발하려는 프로그램의 목적부터 생각해봅시다.
개발목적
- 앞으로 제작하게될 2D스프라이트툴의 컴포넌트가 될 프로그램을 제작한다.
개발시 유의점
- 차후에 개발될 게임에 쓰이게될 스프라이트툴이 컴포넌트가 되는 만큼 확장성에 유의한다.
- 고로 이 스프라이트툴로 제작된 파일을 아류 스프라이트툴들도 로드할수있게 제작하여야한다.
- 최적화에 신경을 쓰되 설계시 최대한 모듈화에 힘쓴다.
정도가 프로젝트의 개요가 되겠다... 뭐 프로젝트라 하기엔 너무 작은 프로그램이라..
이런식으로 대충 목표와 개요가 정해졌고 그다음엔 설계 작업을 해야할꺼같은데
설계라는 구조적인 디자인을 해보기전에 다른 사람들이 만든 몇가지 스프라이트툴을 참고해보자
Kell's Sprite Tool
켜켜's Sprite Tool
Leave your greetings here.
Kell 2009/02/03 14:10 Modify/Delete Reply Address
아참, 그리고 스프라이트툴을 만드신다니 생각나는게 있는데요.
각 프레임 별로 애니메이션 갱신속도를 따로 설정할 수 있는 인터페이스를 마련하시는게 좋습니다.
그래야 스프라이트를 효율적으로 아끼면서 리얼한 스프라이트를 만드는데 조금은 더 도움이 됩니다. 부드럽게 움직이다가 살짝 끊긴 느낌의 스프라이트도 출력을 해주고 ( 격투 게임의 경우 Hit 했을 때의 경직 느낌 정도.. )