GPKI 표준 API HTML 5 전환 삽질기

• 최근 Internet Explorer 11 기술 지원 종료 때문에 담당하던 프로젝트에서 Active X를 걷어내는 작업을 진행 중이다.
• 그 중에서도 GPKI 표준 API를 Active X → HTML 방식으로 전환하면서 겪은 삽질기를 공유해 보겠다.
• 나는 GPKI를 이용한 개발을 한 적이 없고 무수한 삽질을 하면서 전환 작업을 한 것일 뿐 GPKI에 대하여 아는 게 없기 때문에 질문에 답변할 수 없다는 점 미리 밝힌다.

개발 환경

• 참고로 내가 담당하는 프로젝트의 개발환경은 다음과 같다. 프로젝트가 오래된 만큼 사용 환경과 툴이 매우 구식이다. -_-
  • 개발 언어: Java 1.7, JSP
  • 개발 툴: 전자정부프레임워크가 세팅된 Eclipse
  • 서버: Tomcat 7.0

1. GPKI 표준 API 모듈 신청

• GPKI 표준 API 모듈이 있어야 개발이 가능한데 이 모듈 파일은 담당 공무원이 api.gpki.go.kr에 접속하여 서류 작성을 하고 신청을 해야 얻을 수 있다.
• 모듈 신청 완료 후 모듈 압축 파일을 담당 공무원으로부터 받을 수 있고 압축을 풀면 다음의 파일을 확인할 수 있다.
  • 표준API 보급관리시스템 설치가이드 V1.3(브라우저).pdf
    • 가이드 문서이다. 이걸 보면서 개발을 시작하면 된다.
  • gpkiapiJava_v1.5.1.0_Windows_x86_32bit.zip
    • 표준 API가 들어있는 압축 파일이다. 파일 이름에서 알 수 있듯이 32비트 버전이다.
  • gpkiapiJava_v1.5.1.0_Windows_x86_64bit.zip
    • 위와 동일하고 64비트 버전이다. 내가 운영 중인 서버는 64비트이므로 이 버전을 사용했다.
  • GPKISecureWeb_PACKAGE_1.2.0.0_20210917(UTF-8).zip
    • gpkisecureweb 또는 웹보안API라고 부르는 모듈이고 UTF-8 버전이다. 특별한 일이 없으면 이걸 쓰면 된다.
  • GPKISecureWeb_PACKAGE_1.2.0.0_20210917(EUC-KR).zip
    • 위와 동일한데 서버 인코딩을 EUC-KR로 사용하는 경우 이 버전을 쓰면 될 것으로 판단된다.
  • gpkiapi.lic
    • 임시 라이센스 파일이다.

2. 폴더 세팅

• api 폴더는 다음과 같이 세팅하였다.

  • D:\gpki\gpkiapi → GPKIAPI 폴더
  • D:\gpki\gpkisecureweb → gpkisecureweb 설정 폴더

• D:\gpki\gpkiapi 안에 gpkiapiJava_v1.5.1.0_Windows_x86_64bit.zip 파일의 압축을 풀어 넣었다.

• D:\gpki\gpkisecureweb 안에 GPKISecureWeb_PACKAGE_1.2.0.0_20210917(UTF-8).zip 파일의 압축을 풀어 넣어야 하는데 압축 파일 안을 보면 GPKISecureWeb_PACKAGE_1.2.0.0_20210917(UTF-8)\WEB-INF가 있고 이 안에 certs와 conf가 있다. 이것을 D:\gpki\gpkisecureweb 안에 넣어주면 된다.
• 굉장히 헷갈리게 압축 파일 안에 WEB-INF 폴더가 2개가 들어있다. -_-; conf 폴더 안에 dsjdf.properties 파일이 들어있어야 하므로 꼭 확인하자.
• 로그가 쌓일 폴더를 만들어 준다. → D:\gpki\gpkisecureweb\log
• D:\gpki\gpkisecureweb\conf 안에 gpkiapi.lic 라이센스 파일을 넣어준다.
• 전체 폴더 구조는 다음과 같다.

3. gpkisecureweb 설정 폴더의 properties 파일 세팅

• 메모장 등 에디터로 다음의 파일을 열고 수정을 한다.
  • D:\gpki\gpkisecureweb\conf\dsjdf.properties
  • D:\gpki\gpkisecureweb\conf\gpkisecureweb.properties
• 각 설정 파일에 경로가 D:/Projects/GPKI/GPKISecureWebHTML/WebContent 이런 식으로 세팅되어 있는데 자신의 환경에 맞게 경로를 변경하고 저장한다.
• 내 경우 설정 폴더의 경로는 드라이브명(C:나 D:)이 있는 경우 D:\gpki\gpkisecureweb로 수정하였고, 드라이브명이 없는 경우는 /gpkisecureweb으로 수정하였다.
• 경로에 / 기호와 \ 기호가 혼재되어 있는데 기호는 그대로 두고 경로명만 바꿔주면 된다.

4. 프로젝트에 gpkisecureweb 추가

• 이클립스를 열고 본인이 진행하는 프로젝트의 webapp 안에 gpkisecureweb을 추가하자.
• gpkisecureweb은 GPKISecureWeb_PACKAGE_1.2.0.0_20210917(UTF-8).zip 파일 안에 들어있고 가이드 문서에 의하면 gpkisecureweb\WEB-INF는 제외하라고 나와 있다.
• 프로젝트에 gpkisecureweb을 추가한 후 다음과 같이 확인할 수 있다.

5. gpkisecureweb 설정

• 다음 파일들을 열어 gpkisecureweb 폴더의 경로를 수정해준다.
• 내 경우 webapp 하위에 gpkisecureweb를 세팅해 두었으므로 절대경로인 /gpkisecureweb으로 수정해 주었다.
• 경로 외에 자신의 환경에 뭔가 세팅할 게 더 있다면 가이드 문서를 참고하여 수정한다.

  /gpkisecureweb/client/var.js → /gpkisecureweb 절대경로 수정
  /gpkisecureweb/GPKI_Config.js → 내 경우 세팅할 게 없음
  /gpkisecureweb/client/GPKIWeb/js/GPKIWeb_Config.js → /gpkisecureweb 절대경로 수정
  /gpkisecureweb/jsp/header.jsp → /gpkisecureweb 절대경로 수정
  /gpkisecureweb/client/GPKISecureWebNP2.js → /gpkisecureweb 절대경로 수정

6. 예제 파일 수정

• 예제 파일 /gpkisecureweb/jsp/createSecureSession_1_1.jsp의 내용을 보면 initSecureSession();라는 키보드 보안 관련 함수를 호출하는 부분이 있는데 실행해보면 이 부분에서 에러가 발생한다.
• 내 경우 키보드 보안을 사용하지 않기 때문에 해당 라인은 주석 처리하였다.

7. 예제 테스트

• 여기까지 세팅을 했다면 예제 웹페이지를 테스트 해 볼 수 있게 된다.
• 톰캣 서버를 기동시키고 웹브라우저를 열어 주소창에 http://localhost:포트번호/gpkisecureweb/index.html 입력을 해 본다.
• 사용자와 서버 인증서 인증 후 보안 세션 만들기 (인증서 로그인) → 선택하면 다음 화면으로 이동한다.
• Form 객체를 이용한 팝업 로그인 (Login) → 선택하면 파라미터 3개와 주민등록번호 입력폼, 공인인증서 선택창 버튼이 나타난다.
• 본인의 인증서를 하드에 설치한 후 공인인증서 로그인이 되는지 확인한다.
• 파라미터 3개는 아무거나 입력해도 된다.
• 정상적으로 로그인이 되면 다음과 같이 결과가 나타난다.

• 이제 예제를 참고하면서 본인의 프로젝트에 맞게 로그인 등 세팅 및 개발을 하면 된다.
• 참고로 공인인증서를 띄우는 함수는 Login(target, form, isEmbedded)이다. 사용법은 createSecureSession_1_1.jsp의 내용을 참고하면 된다.

참고 사항

공인인증서 선택창에서 비밀번호가 계속 틀렸다고 나오는 경우

• /gpkisecureweb/client/GPKIWeb/js/GPKIWeb_Config.js 파일을 열어보면 GPKIJS_LIC 라는 key가 보일 것이다. 이 key의 String 값이 "Ma2132AbaSdfiQxai..." 이런 식으로 긴 암호화 문자열로 되어 있는데, 라이센스 파일 gpkiapi.lic 파일을 메모장 등 에디터로 열고 내용을 복사한 후 붙여넣는다.
• [주의] 이 설정은 운영서버가 아닌 테스트 환경에서만 사용해야 한다. 개발이 끝나고 정식 라이센스를 받으면 gpkijs.lic 파일을 추가로 받는데 실제 운영 서버에는 이 파일의 내용을 붙여넣기 해야 한다.
• 가이드 문서에 라이센스에 대한 언급은 되어 있으나 이렇게 세팅해야 한다고 자세히 나와 있지 않아서 실제 세팅 방법을 알아내기 무척 어렵다. 제발 이런 건 좀 자세히 써주었으면... -_-

서버에서 인증서 검증에 실패하였습니다 → 에러가 발생하는 경우

• 인증서 선택창이 떠야 할 화면에서 다음과 같이 Server 단의 에러가 발생하는 경우 properties 파일을 수정해야 한다.

  com.gpki.secureweb.GPKISecureWEBException: CRL| 를 이용한 인증서 검증에 실패하였습니다.
    at com.gpki.servlet.GPKIHttpServletRequest.init(GPKIHttpServletRequest.java:475)
    at com.gpki.servlet.GPKIHttpServletRequest.<init>(GPKIHttpServletRequest.java:134)

• D:\gpki\gpkisecureweb\conf\gpkisecureweb.properties 파일을 열고 다음과 같이 NONE으로 수정한다.

  GPKISecureWeb.VerifyCertMethod = NONE

gpkiapi.dll 찾을 수 없다는 에러가 발생할 경우

• gpkiapiJava_v1.5.1.0_Windows_x86_64bit_20170501.zip 파일 내 lib64 폴더 안을 보면 gpkiapi.dll, LDAPSDK.DLL 2개의 파일이 있다.
• 이 파일들을 C:\Windows\System32에 복사하여 넣어주면 된다.
• 다른 OS의 경우 Path를 잡아주면 된다고 한다.

여담

• gpki 고객센터에 전화 문의하라고 되어 있는데 문의할 게 있어서 전화해도 연결이 안 된다. -_- 어쩔 수 없이 무한 삽질을 할 수 밖에 없었다.
• 관련 문의가 꽤 많을 것 같은데 공개 게시판 같은 거라도 운영하면 검색으로 확인할 수 있는 것들이 꽤 많을텐데 왜 안 하는지 모르겠다.

가운데 너는 누구냐

캡콤의 명작 바이오하자드(이하 바하) 시리즈의 신작이 내년 초 출시 예정이다. 바하 1편을 시작으로 시리즈는 무려 20년이나 이어져 왔다. 그동안 매 시리즈마다 바하는 변화와 발전을 거듭해왔는데, 이번 7편의 변화는 이전 시리즈에서의 변화 수준이 아니라 아예 장르가 바뀔 태세다. 초창기 바하 팬으로서 이번 신작에 대해서는 기대와 걱정이 모두 들고 있는데, 그 동안 공개된 내용만을 놓고 볼 때는 아쉽게도 걱정이 더 앞서고 있다.

바이오하자드 1 - 여기에서 깜놀하지 않은 게이머는 없을 것이다.

바하7의 제작진이 그동안 일관되게 알린 문구는 ‘공포로의 회귀’였다. 아마 4~6편부터 바하 시리즈를 접한 뒷세대 팬들이라면 “바하 시리즈는 대놓고 좀비 무쌍 게임 아닌가요?”라는 질문을 할지도 모르겠다. 나처럼 바하 1편부터 즐겨온 구세대 게이머들이라면 알겠지만, 바하 1편은 공포 어드벤처에 더 가까웠다. 처음으로 좀비와 마주칠 때의 카메라 연출, 갑작스레 등장하여 수많은 게이머를 놀래킨 좀비견, 그리고 좁은 공간을 날아다니던 까마귀 떼와 각종 함정까지, 바하 1편은 시대를 풍미한 몇 안 되는 명작 공포 게임이었다. 그렇지만 이런 종류의 게임들이 늘 그렇듯이 한 번 경험한 공포는 점점 익숙해지고 계속 저하될 수 밖에 없다. 강력한 무기와 탄환을 얻어갈수록, 그리고 한 회차를 끝낼수록, 점점 액션 게임으로 변모할 수 밖에 없는 한계는 분명히 있었다.
그럼에도 불구하고, 장면마다 고정된 시점과 다소 불편한 캐릭터 조작, 어둡고 으스스한 분위기와 어쩐지 B급 감성 충만한 연출로 인해 적어도 1회차에서 만큼은 충분히 긴장과 공포를 맛볼 수 있었다. 그리고 이런 분위기는 비록 퇴색되기는 했지만 3편까지는 그럭저럭 이어지다가, 4편에서 드디어 본격 액션 김레온의 좀비 무쌍으로 변화하게 된다.

바이오하자드 4 - 아, 로켓런처! 훌륭한 대화수단이지.

많은 클래식 팬들이 변화된 4편을 비판했지만 결과적으로 보면 바하의 변신은 대성공이었다. 3편까지 이어져 오던 시리즈의 공포 코드는 이미 다수의 팬들에게 더 이상 먹히지 않게 되었다. 사실 3편까지 바하는 그렇게 크게 바뀌거나 개선되지도 않았다. 바하 시리즈는 어떤 식으로든 변화가 필요했고 그렇게 결정된 변화 노선은 본격 액션 게임이었다. 어차피 공포가 먹히지 않는다면 액션이라도 화끈하게 가자는 것이 제작진의 의도였다.
그 결과는 새로운 팬층의 유입으로 증명되었다. 판매량이 늘어나고 상업적으로도 크게 성공했다. 국내 팬들도 바하 4에서부터 본격적으로 늘어났다. 바하 1~3편은 플레이스테이션 (PS1) 타이틀로 출시되었는데, 이 때 당시 국내에서는 PS1이 판매되지 않았기 때문에, 클래식 팬들은 대부분 일본 내수 기기를 어렵게 구해 즐기던 소수의 게임 매니아들이었다. 그 후 오랜 시간이 흘러 바하 4편이 닌텐도의 게임큐브로 출시되었다. 아마 큐브 독점 타이틀이었다면 실패했을지도 모르겠지만, 곧이어 PS2로도 출시가 되었고, 이 때는 국내에서 PS2도 정식으로 판매되고 있어서, 바하 4는 이전작들과 달리 쉽게 접할 수 있었다. 그리고 PC로도 출시되면서, 수많은 어둠의 능력자들에게 마개조(?)를 당하면서, 더욱 많은 팬을 얻을 수 있었다.

어쨌든 이 때부터 바하는 액션 위주로 게임이 흘러가게 되어, 아쉽지만 공포와는 거리가 멀어지게 되었다. 그 뒤로 이어지는 후속작들 역시 마찬가지였다. 그렇게 시리즈의 방향성이 바뀌어 후속작들이 나오고 세월도 흐르고 바하 시리즈도 잊혀질 때쯤 마침내 7편에 대한 소식이 하나 둘 흘러나오기 시작했다. 그리고 바하 7편의 영상과 데모가 공개되고 제작진도 7편에 대한 내용을 공개적으로 알리기 시작했는데, 제작진들은 의외로 ‘공포로의 회귀’를 들고 나타났다.

최근까지 공개된 바하 7에서, 바하의 느낌은 거의 찾아볼 수가 없었다. 데모 버전을 접했을 때 처음 든 생각은 ‘이거 정말 바하 맞나?’였다. 물론 바하7이 바하 느낌이 나지 않는 것이 치명적인 단점이라고 말할 수는 없다. 그렇지만 1인칭으로 변화된 시점, (데모 버전이라 그렇겠지만) 총기나 무기없이 도망만 다니는 무기력한 플레이어를 보면서 이전 시리즈와는 달라도 너무 다르다라는 느낌이었다. 시리즈 전반에 등장하던 좀비나 생물병기는 전혀 볼 수 없었고, 웬 ‘텍사스 전기톱 연쇄살인사건’에나 나올 법한 인물들이 출연하고 있었다. 흔한 헐리우드 영화를 보는듯한 느낌이랄까. 새로운 것을 기대하게 되는 최신 시리즈가 이전작과의 연결 고리는 거의 볼 수 없다는 사실과, 흔한 영화를 보는 느낌을 준다는 건 불안한 부분이었다.

바이오하자드 7 데모 - 극강의 그래픽

반면 제작진이 대대적으로 홍보한 새로운 게임 엔진으로 인해, 게임의 그래픽은 크게 발전했고, 디테일은 훌륭했으며, 나름 신경 쓴듯한 분위기 묘사는 상당했다. 앞서 언급한 것처럼 (흔하디 흔한 것일지라도) 영화와 같은 분위기와 연출은 1인칭 시점과 맞물려 매우 잘 어울렸다. 특히 비디오 테이프 연출은 어느 정도 기대감도 들게 했다. 게임 안에서 비디오를 시청하면 그 비디오가 녹화되던 과거로 돌아가 진행하고 그것이 현재의 시점에 영향을 준다는 아이디어는 괜찮은 시도였다.

바이오하자드 7 데모 - 철조망과 지저분한 저택... 뭐? 이건 사일런트 힐이잖아!

그러나 게임의 전반적인 느낌은 많은 이들이 말하듯 최근의 공포 게임인 암네시아, 사일런트 힐, 에일리언 아이솔레이션, 아웃라스트를 따라가는 듯 했다. 무기력한 플레이어, 적들로부터의 숨기와 탈출, 다음 장소로 이동하기 위한 퍼즐 풀기, 비밀의 발견… 이것들은 이미 다른 게임에서 익숙하게 접해왔던 것들이다. 바하 7에서 과연 이 정도의 변화가 기존 바하 팬들을 설득시킬 수 있을지, 아니면 새로운 팬층을 형성시킬 수 있을지 의문이 든다. 새롭고 혁신적인 시스템이나 게임성 같은 것을 보여주지도 못했다. 그리고 이전 시리즈의 인기 요소였던 동료 시스템이나 코옵 모드도 제외된다. 이런 상황에서 ‘공포로의 회귀’가 올바른 방향일지는 의문이 든다. 공포라는 장르의 특성상 한계는 명확하다. 1회차 이후에는 어떻게 될 것인가?

만약 바하 7이 조금 더 발전적인 모습으로 출시가 되지 않고, 겨우 데모 버전에서 보여진 수준으로 정식 출시가 된다면… 그 때도 바하 팬들은 여전히 바하의 팬이 될 수 있을까? 공포 요소를 강조하고 싶었다면 차라리 ‘1편으로의 회귀’라는 문구를 걸고 개발을 하는게 낫지 않았을까? 앞서 언급했듯이 바하 1편은 최근작들과 달리 공포 어드벤처에 가까운 게임이었고, 바하 1편의 컨셉, 배경으로부터 여러 가지 아이디어를 얻을 수 있었다고 생각한다. 만약 공포만을 강요하는 지금과 같은 상황이라면 실망이 조금 더 클 것 같다. 앞서 언급했듯이 이미 그런 게임들은 충분히 있으니까 말이다.

바이오하자드 20주년 - 바하 1편을 즐기던 때가 엊그제 같은데 벌써 20년 전이라고? 앗, 그럼 내 나이가... 'o';

그렇지만 바하 시리즈가 변화해야 한다는 제작진의 주장에 대해서는 절대적으로 공감한다. 4~6편에서 보여준 액션은 오랜 시간이 흐르며 진부해진 부분이 있고, 이제는 보다 새롭고 참신한 것이 등장해야 하는 시점이라는 것은 분명하다.
바하 시리즈를 탄생시킨 캡콤이 비록 우려먹기의 대표 주자로 악명이 높지만, 새로운 우려먹기 시리즈를 탄생시키기 위해 수많은 시도와 실험을 하는 제작사인 것을 팬들은 잘 알고 있다. 바하 시리즈가 이어져 온지 벌써 20년 째이고, 시리즈의 스토리도 시스템도 새로울 것 없이 바닥이 나 있는 상태에서 최근작들은 이전작들에 비해 판매량도 떨어지는 분위기다. 바하 7이 위기에 몰려있는 시리즈의 부활을 이끌 것인지 아니면 이대로 무덤에 끌고 들어갈 것인지는 지켜봐야 알겠지만, 지금의 내용만으로는 부족하다는 것이 내 생각이다. 어떤 식으로든 더 새롭고 혁신적인 내용이 들어가고 그에 따른 팬들의 기대치가 높아져야만 바하 시리즈가 부활할 수 있다. 시간이 많지 않지만 제작진의 고민이 더 필요한 때가 아닌가 싶다.

몇 년전까지만 해도 SendMessage는 쓰지 않는 것이 좋다라는 의견이 대세였었던 것으로 기억하는데, 최근에는 꼭 그렇지만은 않은 것 같다. 내 경우 SendMessage로 인해 심각한 성능 저하를 겪은 기억은 없었다. 사실 그렇게 쓸 일이 많지도 않지만, 간단하게 쓸 일이 있다면 써도 좋다는 생각이다.

참고:

http://unitygame.tistory.com/entry/%EC%9C%A0%EB%8B%88%ED%8B%B0-SendMessage-%EC%82%AC%EC%9A%A9

Atom

오픈소스 에디터 이 한 마디로 모든 설명이 끝난다. 조금 쓸만한 에디터라고 하면 상용 에디터일 경우가 많고, 대부분 직장인인 개발자들은 이러한 경우 회사에서 지원하지 않으면 사용하기 어려운 부분이 있다. 아톰 에디터는 오픈소스이기 때문에 어디서든 마음껏 사용할 수 있다. 게다가 오픈소스를 사랑하는 개발자들의 지원으로 수많은 플러그인을 통해 에디터 자체의 기능을 무한대로 확장해 쓸 수 있다. 예를 들어, 글쓰기를 좋아하는 블로거라면 마크다운 플러그인으로 블로그용 글을 작성하거나 이미 작성한 글을 pdf로 변환해 볼 수도 있다.

또한 멀티 플랫폼이라 macOS, Windows, Linux에서 모두 사용할 수 있다. 플러그인을 이용하면 세팅한 환경을 모든 플랫폼에서 동기화하여 사용할 수도 있다.

단 하나 아쉬운 단점이 있는데, 에디터 치고는 무겁다는 점이다. 그래도 꾸준한 업데이트를 통해 계속 보완이 되고 있는 점은 다행이다. 사실 아톰의 초기 버전은 실사용하기에는 좀 어려울 정도였다. ;)

웹사이트: Atom

Sublime Text

아톰 에디터 이전 에디터계를 평정(?)할 뻔한 툴이다. 사실 아톰 에디터가 이 에디터를 참고해서 만든 것이 아닌가 싶을 정도로, 두 에디터는 서로 닮았다. 예를 들어 아톰 에디터의 플러그인에 대응하는 것이 패키지라는 것인데, 이것으로 본체의 기능을 확장해 쓸 수 있다. 또한 아톰과 마찬가지로 다양한 플랫폼을 지원한다.

그리고 아톰과는 달리 매우 가볍고 빠르다. 내 경우 빠르게 무언가를 작성해야 할 일이 있다면 서브라임을 바로 열어 쓴다.

단점은 역시 상용 툴이라는 점이다. 그렇지만 구입하지 않아도 Unregisted 마크가 찍히는 것 외에 기능상의 제한은 없기 때문에 집에서 혼자 사용하는 것이라면 부담없이 쓸 수 있다.

웹사이트: Sublime Text

Evernote

에버노트는 마치 아이폰의 메모와 비슷하면서도 분류, 태그, 검색 등 기능적인 면에서는 더 파워풀한 툴이다. 노트 클라우드 서비스이기 때문에 멀티 플랫폼이 기본이다. 그리고 웹의 내용을 그대로 긁어오는 클리핑 기능은 이 분야에서 최고이다. 어떠한 내용도 즉각 작성하여 PC나 핸드폰을 통해 볼 수 있고, 다이어리, 작업일지, 할일 관리 등 못하는 게 없다. 이러한 특성 때문에 활용성만큼은 무궁무진하다. 내 경우, 그 동안은 블로그를 통해 정보 공유를 했었는데, 이제는 에버노트만 쓴다. 만약 공유할 내용이 있다면 '공유' 버튼을 한 번 눌러주면 끝이다.

에버노트의 단점은 무료 유저의 경우 용량 및 기기수 제한이 있다는 것이다. 그렇지만 아예 못 쓸 정도는 아니고, 텍스트 자료 위주로 쓴다면 무료 기능만으로도 충분하다.

웹사이트: Evernote

각각의 툴에 대한 보다 자세한 내용은 웹사이트나 블로그 등을 참고하면 좋을 것이다.

스크립트의 멤버 중 public으로 된 것들은 유니티의 인스펙터에 노출이 되어서, 실행 중에 그 값을 쉽게 모니터링 할 수 있다.

그런데 구조상 private으로 된 것이 있을 수 있는데 이런 것도 노출을 시킬 수 있다.

두 가지 방법이 있는데, 첫 번째는 인스펙터의 Debug 모드를 이용하는 것이고 두 번째는 스크립트에서 노출을 시키는 방법이다.

Debug 모드

인스펙터의 탭을 마우스 우클릭하면 메뉴가 나타나는데, 여기에서 Debug를 선택하면 된다.

스크린샷에서 볼 수 있듯이 public 멤버와는 다르게 비활성된 회색 색상으로 나타난다.

그 외에도, Instance ID라던가 Transform의 Debug 정보도 인스펙터에 추가된다.

스크립트에서 노출

private 멤버의 윗 라인에 [SerializeField] 코드를 추가하면 된다.

예제

[SerializeField]
private bool isSecretMode;

Debug Mode와 다른 점은, bool 타입의 경우 public 멤버처럼 체크가 가능하게 된다.

NGUI의 UIGrid 객체 밑에 자식 객체를 두었다가 삭제하려는 경우, PC에서는 정상적으로 삭제가 되지만 안드로이드에서는 삭제가 완전히 되지 않고 이상하게 동작하는 것을 발견했다.

아래의 코드를 보자.

foreach (Transform transChild in gridObj.transform)
{
    Debug.Log("delete child >>>>>>>>>>>>>" + transChild.gameObject.name);
    Destroy(transChild.gameObject);
}

루프를 돌면서 UIGrid에 붙어있는 자식을 삭제하게 되는데, 로그도 정상적으로 찍히고 PC에서는 아무 문제가 없다. 그런데 실제 안드로이드 기기에서 돌려보면 UIGrid의 자식이 완전히 삭제되지 않고 1~2개씩 남는다.

이 문제를 해결하려면 루프 밑에 다음과 같은 코드를 추가하면 된다.

gridObj.transform.DetachChildren();

출처: http://nomoreid.egloos.com/4796039

Unity3D 프로젝트를 처음 시작할 때 반드시 설정해야 하는 것

Edit - Project Settings - Editor - Version Control의 Mode를 Meta Files로 변경해야 한다. 그렇지 않으면 프로젝트의 각종 설정값이 각 팀원의 라이브러리에 저장되기 때문에 SVN이 꼬이게 된다.

추가 팁
Asset Serialization의 Mode를 Force Text로 변경하면 Scene 파일도 텍스트로 저장되기 때문에 SVN에서 Scene의 변경 사항을 추적할 수 있게 된다. 디폴트 값인 Mixed로 유지할 경우는 Scene 파일이 바이너리로 저장되기 때문에 누군가 Scene 파일을 변경했을 때 무엇이 변했는지 디테일한 정보를 얻을 수 없다.

프로젝트를 진행하다보면 NGUI의 label만으로는 표현이 뭔가 아쉬운 경우가 있다. 특히 게임 캐릭터나 유닛이 데미지를 받는다거나, 스코어를 보여준다거나 하는 상황에서 사이즈가 큰 폰트를 써야 할 경우가 많은데, 이럴 경우 기본 폰트의 크기가 작아 폰트가 지저분하게 보인다거나 게임 자체가 뭔가 허접(?)하게 보일 확률이 높다.

"0부터 9까지의 숫자 부분만 따로 떼어 특별한 이미지로 만든 후에 이것을 label로 쓸 수 있다면..?"

이런 생각으로, 데미지 폰트를 만드는 방법을 검색해 보았으나... BMFont를 이용한 폰트를 만드는 방법은 여기저기 블로그 등에 널려(...) 있는데 비해, 이미지로 구성된 숫자 폰트를 만드는 방법은 의외로 찾아보기 어려웠다. 약간의 삽질 끝에 숫자 폰트를 만드는 방법을 확실히 알게 되어 공유해 보겠다.

준비물
Unity, NGUI, BMFont, 폰트로 만들 0부터 9까지의 이미지

참고로 여기서 사용한 각 툴의 버전은 다음과 같다.
Unity3D: 4.1.5
NGUI: 2.6.3
BMFont: 1.13

1. BMFont를 띄우고 0부터 9까지 폰트로 만들 숫자를 선택한다.

일반적인 BMFont를 만드는 과정과 거의 비슷한데, 폰트 중에 숫자 부분만을 선택(클릭)한다는 점이 다르다. (보통 인터넷에 돌아다니는 KS1001.txt 파일을 import하는 과정...)
숫자를 클릭하면 어두운 회색 박스가 약간 밝은 회색 박스로 변한다. 이런 식으로 0부터 9까지 선택을 한다.

2. Image Manager를 띄운다.

일반 폰트를 만들 때는 존재조차 있는지 몰랐던, Image Manager를 띄운다.

3. Import Image

Image Manager를 띄우면 달랑 메뉴 하나에 빈 창만 보이는데, 메뉴의 Image => Import image를 클릭한다.

4. Id 입력

파일을 선택하는 창이 뜨는데, 준비해둔 숫자 폰트 중 0번 이미지를 선택하자. 그러면 위와 같은 Icon Image 창이 뜬다.
여기서 주의할 점은 Id 부분인데, 0번 이미지의 Id를 48로 변경하고 Ok를 눌러주자.
나머지 1번부터 9번까지는 0번 이미지부터 순서대로 Id값을 1씩 늘려나가면 된다. 이렇게 하면 9번 이미지는 Id가 57번이 된다.

5. 설정 확인

0번부터 9번 이미지를 모두 Import했다면 위와 같은 화면을 볼 수 있을 것이다.
0부터 9까지의 문자 박스에 하늘색 점이 표시되어 있고, 밝은 회색 박스로 변해 있다는 것을 알 수 있다. 만약 자신이 작업한 결과물이 위의 스샷과 다르다면 지금까지의 작업 과정을 다시 한 번 차근차근 확인해 보자.

6. Export Options

이제 Export Options를 설정해야 한다. BMFont의 Options => Export Options를 클릭하여 옵션 창을 띄우자.
확인할 사항은 두 가지이다. 첫 번째는 Bit depth인데 32비트로 바꾸면 된다. 만약 8비트 상태 그대로 둔다면 원래의 색상이 아니라 희멀건 폰트를 보게 될 것이다. 두 번째는 Textures인데, 유니티 프로젝트에서는 대부분 png 이미지를 사용하므로, png로 바꾸면 된다.
Save bitmap font as...를 누르면 저장할 이름을 결정하는 창이 뜬다.
여기서는 DamageFont라고 정해보았다.

[참고] 이후의 과정은 일반적인 BMFont를 만드는 과정과 같다.

7. fnt를 txt로 변경

저장하면 fnt와 png 파일이 생긴다. 이 중 fnt 파일의 확장자를 fnt에서 txt로 바꾼다.

8. txt와 png를 유니티의 프로젝트로 드래그&드롭

앞의 과정에서 만든 txt와 png를 유니티의 프로젝트에 드래그&드롭한다.
이제 NGUI의 Font Maker를 열어 폰트를 만들면 되는데, 유니티 메뉴 => NGUI => Open the Font Maker를 클릭한다.

9. Font 아틀라스 만들기

지금까지의 과정을 정상적으로 진행했다면 위와 같은 모습을 볼 수 있다. 앞의 과정에서 프로젝트에 포함시켰던 txt 파일을 Font Data로 드래그하고, png 파일은 Texture로 드래그한다.
Font Name을 입력하고 Create 버튼을 누르면 프로젝트 폴더에 아틀라스와 마테리얼이 생성된다.

10. 최종 테스트

NGUI의 Widget Tool을 띄운 후, 조금 전 만든 DamageFont 아틀라스를 Font로 선택한다. Label을 만든 후 정상적으로 폰트가 출력되는지 확인하자. 지금까지의 과정을 차근차근 따라했다면 위의 스샷처럼 Scene 화면에서 데미지 폰트로 된 Label을 확인할 수 있을 것이다.

tag: Unity3D, NGUI, BMFont, 데미지 폰트, 숫자 폰트, 이미지 폰트 만들기

Herose VS. Monsters

스크린샷이나 관련 이미지만 보면 마치 RPG인 것 같지만, 이 게임은 RPG보다는 워크래프트에 더 근접해 있는 느낌이다. 경험치, 레벨, 장비, 직업 등 RPG의 요소를 두루 갖춘 전략 게임이랄까. 영웅을 터치하여 특정 지점으로 이동시키거나 공격하는 등 액션의 느낌이 워크래프트와 많이 닮았다는 느낌이다.

게임의 진행

게임의 장면은 크게 필드, 전투, 인벤토리와 상점 등으로 구성되어 있다. 필드에는 목표 지점이 표시되어 있고, 화면을 터치하여 이동을 하게 된다. 화면에 표시는 되지 않지만 이동 중에 적들을 만나게 되면 (Final Fantasy처럼) 전투 화면으로 전환된다. 한 번의 전투가 끝나게 되면 경험치와 돈을 받아 다시 필드로 빠져나오고, 목표 지점에 도달하면 보스와의 전투가 시작된다. 보스 전에서 승리하면 가려져 있던 새로운 필드가 나타나고, 그곳으로 이동이 가능하게 된다. 새로운 지역으로 이동할수록 적들은 점점 강해진다.

영웅의 육성

영웅은 크게 근접형, 원거리형, 회복형으로 분류해 볼 수 있다. 근접형의 대표적인 직업에는 전사가 있고, 원거리형으로는 궁수나 마법사가 있다. 그리고 마지막으로 회복형으로는 사제가 있다. 각 직업마다 스킬 트리가 있어서 하나의 직업을 여러 방식으로 육성해 볼 수 있다. 전사만 하더라도 공격을 강화한 투핸드소드 타입 또는 쌍수 타입으로 키운다거나, 방어를 강화한 검방전사 등 여러 가지 방향으로 키울 수 있는 것이다. 스킬 트리를 완성해 나갈수록 사용 가능한 스킬이 늘어나지만, 각 스킬에는 재사용 대기시간이 있어서 아무 때나 사용하면 전투가 힘들어질 수 있다. 적재적소에서 각 영웅의 스킬을 사용해야 전투에서 쉽게 승리할 수 있는 것이다.

장비 아이템

각 직업별 부위별 수많은 장비가 있다. 적들이 간혹 떨어뜨리는 것도 있지만 상점 아이템이 대체적으로 성능이 좋다. 하지만 좀 쓸만한 장비다 싶으면 상당히 비싼 편이라 전투 노가다가 필요하다. 그게 싫다면 현질(?)을 해야 한다.

장비는 등급이 있는데, 디아블로 시리즈처럼 색깔로 구분이 가능하다. 예를 들면 회색은 잡템, 흰색은 보통, 녹색은 희귀, 파란색은 레어, 이런 식이다.

전투 방식

전투 화면은 사이드 뷰 시점으로 되어 있다. 영웅의 이동은 특정 지점을 터치하면 그곳으로 영웅이 이동을 하게 되고, 영웅이 이동 중에 적을 만나면 공격한다. 또는, 적을 직접 터치하여 이동과 공격을 할 수도 있다. 원거리 영웅은 공격 거리가 허용되는 거리 내에서는 이동하지 않고 공격하게 된다. 등장하는 모든 적을 전멸시키면 한 번의 전투가 종료된다.
전투에서는 마치 실시간 전략이라고 할 수 있을 정도로, 빠른 상황 판단과 적절한 스킬 사용이 필수적이다. 한 번의 전투는 몇 차례의 웨이브로 구성되어 있는데, 웨이브 한 번당 1~5명 정도의 적들이 돌격해 온다. 미약하게나마 어그로(위협 수준)의 개념이 있어서, 몸빵이 잘 안 되는 원거리형 영웅이나 죽기 직전의 영웅에게 들러붙은 적을 전사가 도발하여 떼어오는 것이 가능하다. 하지만 게임을 진행하다보면 몰려오는 적들의 직업도 점점 다양해져서 빠른 상황 판단과 대처가 필요하다. 예를 들어 전사와 궁수, 마법사가 한 조가 되어 근접+원거리 짬뽕 공격을 해 올 경우, 극딜로 적들을 차례차례 녹여 버리거나, 전사가 빨리 원거리 적에게 달려가서 도발로 떼어내거나, 궁수가 뿌리 묶기로 접근하는 적을 행동 불능 상태로 빠뜨린 후 원거리 적들을 먼저 처리할 수도 있다. 즉, 다양한 직업과 스킬 트리가 조합되어 전투에서 수 많은 경우의 수가 존재할 수 있다.

한 줄 요약

나름 깔끔한 그래픽, 심플하지만 몰입도 높은 게임

식물 대 좀비

Plants VS. Zombies

일명 식좀. 국내에 아이폰이 출시된 후 이런저런 커뮤니티마다 쩌는 중독성으로 소개가 되면서 크게 히트한 게임이다. 디펜스 장르하면 떠오르는 대표적인 게임이 되기도 했는데, 나 역시 식좀 이전에는 디펜스 장르에 대한 개념이 거의 없었다. 혹자는 이미 "스타크래프트나 워3 유즈맵으로 디펜스 장르가 확립되었다"라고도 하지만 어디까지나 그것들은 유즈맵일 뿐이고, 디펜스란 장르로 정식 타이틀이 붙은 게임은 없었다. 이 글은 어떤 게임이 디펜스 장르의 시초인지에 대해서 관심을 두는 글은 아니니 일단은 패스. 

어쨌든 식좀하면 디펜스, 디펜스하면 식좀이 떠오른다라고 말할만큼 대표적인 디펜스 계의 명작 게임이라고 할 수 있겠다. (여담이지만 이 게임이 얼마나 임팩트가 강하고 대단했는지, 월드 오브 워크래프트의 힐스브래드 구릉지 쪽 퀘스트로도 나왔다.) 게임 개발자의 관점에서도 한 번쯤은 꼭 해 봐야 하는 게임이지 않을까 싶다.

게임 내용은 캐주얼 게임답게 초간단하다.

1. 태양 에너지(돈)를 모은다.
2. 에너지로 식물을 구입(?)하여 맵에 배치한다.
3. 식물이 몰려드는 좀비를 물리치는 것을 구경한다.
4. 좀비가 방어선을 뚫게 되면 (집의 담장을 허물면) 게임 오버.

써 놓고 보니 게임 내용이 꽤나 단순하지만, 디테일은 결코 단순하지 않다. 일단 좀비의 종류도 다양하고, 집을 방어할 수 있는 식물도 한 가지가 아니라 수십 종이다.

식물은 크게 세 종류로 분류해 볼 수 있는데, 첫째는 태양 에너지를 생산하는 해바라기, 둘째는 좀비를 공격하는 콩알탄을 발사하는 공격 담당, 셋째는 감자처럼 닥돌하는 좀비를 일시적으로 방어하는 방어 담당 식물이다.

플레이어는 이 세가지 식물 중 어떤 것이 가장 효율적일지를 빠른 시간 내에 판단하여, 태양 에너지를 모으면서 식물의 구입과 배치를 해야 한다. 그렇지 않으면 좀비가 점점 증가하여 방어선을 뚫게 되고 결국 게임 오버로 이어지기 때문이다.

그런데 식물의 구입과 배치가 말로는 쉽지만 실제로 해 보면 꽤 까다롭다. 태양 에너지가 있어야 공격 담당이든 방어 담당이든 식물을 구입할 수 있는데, 에너지를 모으려면 해바라기를 구입해야 한다. 그런데 게임 시작 얼마 후에 좀비가 한 마리 달려들고… 공격을 해야 할지, 해바라기를 심을지 순간적으로 판단해야 한다. 이 타이밍을 놓치면 좀비의 초반 러쉬(?)에 당할 수 있기 때문이다.

해바라기는 공격 능력이 전혀 없고 좀비에게 몇 대 맞으면 죽어버리기 때문에 가급적 집(담장)에 가깝게 배치하는 것이 좋다. 그리고 웨이브(좀비 한 무리가 한 번 쳐들어오는 상황)가 진행될수록 좀비의 수가 더 많이 증가하는데다, 점프하거나 폭발하는 등 특수한 능력을 가진 좀비들도 생기기 때문에 각 식물의 배치에 상당히 머리를 써야 한다.

밸런스가 꽤 잡혀 있어서인지 게임 시작 전에 룰을 어느 정도 숙지했더라도, 실제로 해 보면 에너지를 모으면서 방어를 하는 것이 (스테이지를 클리어 해 나갈수록) 점점 어려워 진다. 어느 정도의 경험을 통해서 적들의 공격 간격을 예측하며 식물을 적절히 배치해야 하나의 스테이지를 클리어할 수 있는 것이다.

다양한 종류의 식물과 독특하고 우스꽝스럽게 생긴 좀비, 그리고 절묘한 밸런스가 중독성까지 부여하는 이 게임은 명작이라고 충분히 부를만 하다. 디펜스 장르를 별로 좋아하지 않는 나도 해 볼 정도면 말이다.