2012년 1월 20일 금요일

[libGDX] libGDX 시작하기

안드로이드 게임 프레임 워크는 AndEngine, Rokon, Angle, jMonkeyEngine, Android-2D-Engine등 다양한 프레임워크가 있는데요, 그중에서 libGDX라는 게임 프레임워크에 대해 말해 보려고 합니다. libGDX는 Mario Zechner라는 분이 만드는 프레임 워크입니다. Mario Zechner씨는 [

시작하세요 안드로이드 게임 프로그래밍|위키북스] 라는 책을 출판하시기도 하였습니다. 이 책은 libGDX가 만들어지는 과정을 보는듯한 책으로, 게임 프로그래밍을 이해하는데 정말 좋은 책이라고 생각합니다. 꼭 한번 보시기를 추천합니다.


그러면 이제 본론으로 들어가도록 하겠습니다. libGDX는 안드로이드 게임 엔진이라는 것은 알겠는데, 일단 프레임워크가 뭔가부터 설명해야 하지 않겠습니까? 라고 질문하시는 분이 있을것 같아서 프레임워크라는 것부터 설명하겠습니다. 프레임워크는 프로그램의 뼈대입니다. 뼈대를 만들고 여기에 살을 붙여서 여러가지 다양한 게임들을 만들 수 있습니다. 프레임워크가 유연하게 짜져 있어야지 메인 프로그램을 만드는데 있어 보다 쉽고 다양한 기능들을 간단하게 추가할 수 있는등 프레임워크는 프로그램 개발에 있어 굉장히 중요하다고 할 수 있습니다.

이번 시간에는 libGDX에 대해 자세히 이야기 하기 보다 간단한 튜토리얼 하나를 통해 libGDX의 묘미를 느껴보도록 하고, libGDX의 환상적인 세계에 빠져볼 준비를 하도록 합시다.

libGDX는 좀 독특하게 멀티플렛폼 프레임워크로, 데스크탑에서 게임을 실행할수 있고, 이 게임을 그대로 안드로이드에 적용할 수 있습니다. 먼저 데스크탑에서 이미지를 출력하는 것부터 시작하도록 하죠.

먼저 이미지를 하나 준비해 주세요. 그런데 아무 이미지나 괜찮지는 않습니다. libGDX는 2의 제곱수의 크기를 같은 이미지만 불러올 수 있습니다. 예를 들어 512 * 512, 1024*128 이런 크기를 갖는 이미지들을 말하는 거에요. 무슨 소리인지 아시겠죠? 그런데 꼭 67 * 94 크기의 이미지를 넣고 싶다고요? 그러면 128 * 128 이미지에 67 * 94 를 넣고 나머지 부분을 공백으로 하시면 됩니다. 뭔가 비효율 적이고 꺼림칙 할거라고 생각하실텐데, 이렇게 하는 자세한 이유는 나중에 설명 드리도록 하겠습니다.

저는 아래와 같은 png 이미지 파일을 준비하겠습니다. (128 * 64)
(img.png)

이제 이 사진을 뜨워보도록 하겠습니다.
먼저 자바 개발 IDE인 이클립스를 받습니다. (Eclipse IDE for Java developers라고 써진걸 받으시면 됩니다.)
(http://www.eclipse.org/downloads/)
그리고 libGDX를 다운 받습니다. (Nightly Builds 버전을 받으시기 바랍니다.)
(http://libgdx.badlogicgames.com/download.php)

이제 이클립스를 실행합니다.

새로운 자바 프로젝트를 만듭니다.


저는 이름을 EdoliGame이라고 짓겠습니다.



libs라는 폴더를 추가해 줍시다. 여기에 이제 libGDX 라이브러리 파일들을 넣어줄 것입니다.



아까 받으셨던 libGDX nightly builds에서 다음과 같은 4개의 파일을 복사해 줍니다.


libs폴더에 붙어넣기를 해주시고, 4개의 파일을 add to build path를 해줍니다.



이제부터 프레임워크는 준비되었습니다. 진짜로 게임을 만들어 보도록 합시다. 먼저 클래스를 2개 만들어 줍시다. 하나는 MainGame으로 이미지를 띄우는 클래스이고, 하나는 DesktopStarter로 응용프로그램을 시작하는 클래스로 만들어 주겠습니다.


이제 코딩의 시간입니다.

MainGame 클래스

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.graphics.g2d.TextureRegion;

public class MainGame implements ApplicationListener{
 private TextureRegion image; 
 private SpriteBatch batch;
 
 @Override
 public void create() {
  batch = new SpriteBatch();
  Texture texture = new Texture(Gdx.files.internal("data/img.png"));
  image = new TextureRegion(texture);
 }

 @Override
 public void dispose() {
  
 }

 @Override
 public void pause() {
  
 }

 @Override
 public void render() {
  Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
  batch.begin();
  batch.draw(image, 50, 50);
  batch.end();
 }

 @Override
 public void resize(int arg0, int arg1) {
  
 }

 @Override
 public void resume() {
  
 }

}

DesktopStarter 클래스

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;

public class DesktopStarter {
 public static void main(String[] args) {
  new LwjglApplication(new MainGame(), "game title", 480, 320, false);
 }
}


코딩이 끝났으면 data 폴더를 만들고 아까 준비 했던 이미지 파일(img.png) 파일을 넣어 줍시다.


ctrl + f11을 눌러 실행시킵니다. 성공적으로 그림이 출력되는 것을 볼 수 있습니다.


다음시간부터는 게임 프레임워크에 대한 기초 지식등을 알아보겠습니다. 그 후 libGDX의 구조에 대해 심층적으로 알아보고, 응용하여 실제로 제대로된 게임을 만들어 보도록 하겠습니다.

질문이 있으신 분들은 질문 환영합니다.

2012년 1월 2일 월요일

드리밍 인 코드를 읽고

정말 최근에 읽었던 책 중에서 최고의 책이었다. 처음에 읽기 시작할때는 이런 책인 줄 예상하지 못했다. 단순한 소프트웨어 개발에 관한 이야기 일 줄 알았다. 소프트웨어 개발에 관한 이야기는 맞았다. 하지만 내용은 '단순'하지 않았다. 이 책은 소프트웨어 개발 역사의 처음부터 되짚어 보면서 현재 관찰하고 있는 Chandler 개발 프로젝트를 서술하고 있다.

그동안 인간의 역사에서 수많은 IT프로젝트들이 있었다. 많은 프로젝트의 결과는 참혹했다. 프로젝트가 중도 폐기 되는 경우가 많았고, 그마나 힘들게 끝마친 프로젝트에도 처음 생각했던 기능이 들어가지 않는 경우가 많다. 우리가 현재 굉장히 많은 유용한 소프트웨어를 사용하고 있는데, 그 소프트웨어들을 수많은 프로젝트중에서 어렵에 살아남은 소프트웨어들일 뿐이다. 역사는 반복되어 왔다. 실패한 프로젝트로부터 사람들은 새로운 것을 배웠다고 생각한다. 하지만 프로젝트를 시작하면 그 실수는 되풀이 된다. 이 책은 이러한 수많은 반복되는 실수들과 그 과정에서의 사람들의 소프트웨어 개발에 대한 철학을 볼 수 있다.

소프트 웨어 개발에 관한 책은 많다. 이 책의 유별난 점이라면 굉장히 포괄적으로 소프트웨어 개발을 다루고 있다는 것이다. 인류의 역사에서 사용된 거의 모든 개발론들을 포함하고 있다. 이 책을 읽으면서 정말 놀라웠던 것은 소프트웨어 개발 방법론은 컴퓨터 역사의 초기인 1950년대와 비교해서 크게 달라진것이 없고, 오히려 그때의 개발 방법론으로 돌아가려는 사람들도 있다는 것이다. 오랜 시간동안 사람들은 어떻게 해야 소프트웨어를 빠르고 안전하게 개발할 수 있는 가에 대한 생각을 해 왔다. 많은 개발자들은 교량건설을 하는 것처럼 소프트웨어를 개발하고 싶어했다. 교량을 건설할때는 먼저 설계도를 만든다. 그리고 그 설계도대로 교량을 건설한다. 그러면 그 교량은 빠른속도로 건설될 수 있고 굉장히 안전하다. 소프트웨어 개발은 그렇지 못하다. 계획서는 수시로 변경되며 결과물도 안정되지 못하고 수많은 버그로 얼룩져 있다.

이 책에서 다루는 챈들러 프로젝트는 실패한 프로젝트로 생각된다. 애초 일정을 훨씬 뛰어넘어서 거의  5년이라는 세월이 흘러서야 1.0버전이 릴리스 됬기 때문이다. 이 책의 저자는 처음에 이 프로젝트가 길어봐야 2년이라고 생각했었다. 하지만 이렇게 프로젝트 기간이 길어지면서 저자는 수많은 생각을 하게 되게 었다. 그래서 이렇게 훌륭한 책이 나올 수 있었던것 같다. 이 책에서는 저자의 소프트웨어 개발에 되한 자신의 고찰을 찾아 볼 수 있다. 저자는 소프트웨어를 조금 다뤄본 적은 있지만 개발자는 아니다. 그래서 프로젝트회의에서 사람들이 기술적인 말을 하면 전혀 알아 듣지 못한다고 한다. 하지만 이 사람은 그 어떤 개발자 보다도 소프트웨어 개발론에 대해 전문적이라고 생각한다.

소프트웨어는 공학이 아니라 예술이라는 말이 있다. 소프트웨어는 새로운 것을 창조해 내는 것이다. 나는 소프트웨어 개발이 교량 건설같은 것과 비교할 수 없다고 생각 된다. 비교된다는 자체가 웃긴 것이다. 교량은 이미 만들어진 교량을 참고해서 거의 비슷한 모양으로 만든다. 딱히 새로운 필요가 없다. 하지만 소프트웨어는 새롭지 못하면 도태된다. 창조를 해야한다. 이것은 예술이다. 물리, 화학, 수학같은 자연과학 같이 완벽한 법칙으로 이루어져 있지 않다. 건축이나 반도체 제조같이 고정된 특정 프로세스를 통해 만들어지는 것도 아니다. 미술가나 음악가가 여러가지를 시도해 보고 여러 실패를 해보면서 새로운 것에 도전하는 것이다. 소프트웨어 개발은 멋있다. 재밋고, 창조적이며 새로운 세계를 만들어 갈 수 있다. 그들에게는 꿈이 있다. 소프트웨어를 만드는 것은 개발 방법론이 아니라 이런 꿈을 만들어 가는 의지라고 생각한다.

나는 정말 이런 최고의 책을 읽은것에 대해 굉장한 행운이라고 생각한다. 이런 책을 써준 스콧 로젠버그 씨에게도 굉장히 감사하다. 이 책은 내가 소프트웨어를 개발할때마다 나를 자극해줄 것이다.

2012년 1월 1일 일요일

넥슨 글로벌 인턴십을 다녀와서.

넥슨 글로벌 인턴십에 다녀왔습니다. 오랜만에 하는 면접이라 긴장됬는데 막상 가보니까 분위기가 자유스러운 느낌이라서 크게 긴장되지는 않았네요. 그래서 나름 말도 잘 하고 나왔다는 느낌이 들긴 하는데. 결과 어떨지.ㄷㄷ
30분 면접이긴 했는데 5명이 같이 면접을 봐서 한 사람앞에 주어지는 시간은 대충 6분 정도밖에 안되서 면접이 깊이 있게 이루어 진다는 느낌은 들지 않았어요. 대충 생각나는 면접 질문들은 다음과 같네요.

  • 넥슨 글로벌 인턴십에 지원하게된 동기는?
  • 지금까지 해본 게임 중에서 가장 인상 깊었던 게임은?
  • 자신을 신체의 일부로 비유해서 표현해 보아라.
  • 친구가 자기를 소개한다는 식으로 자기소개를 해 보아라.
  • 앞으로 취직을 하게 될텐데, 어떤 게임을 만들고 싶은가? 또 어떤 회사에 들어가고 싶은가?
대충 이런 질문들이었네요. 결과 잘 나왔으면 좋겠네요..