WHY'S BlOG

따로 게시물을 작성하고 싶어서 이렇게 늦었지만 올려본다!

네이버블로그에도 똑같이 올리긴했는데,

여기서는 좀 더 내용을 추가해서, 그리고 호들갑떨지 않고 얘기해봐야지.

일단 처음 BIC페스티벌 전시장을 가자마자했던건 1전시장 바로 앞에 있는 GBTI테스트이다!

컴퓨터 여러대가 쭉 나열되어있고, 다 GBTI테스트를 할 수 있도록 하였다.

그리고 BIC페스티벌을 좀 더 즐기기 위한 컨텐츠로 스탬프 모으기가 있었고,

GBTI테스트도 스탬프 미션 중 하나였다.

​

GBTI는 우리가 아는 그 MBTI에다가 GAME합친거다.

이 결과 유형을 가지고 나의 게임성향과 맞는 게임을 팜플렛을 보고 이동할 수 있다.

근데 생각해보니 내 유형에 맞는 B존에서 내가 게임을 했던가..?

전투형은 확실히 단시간에 즐기기에 좋은거같아서

계속 사람이 많아 안한것 같다..

이 팀!

나는 참고로 'GAMEMAKERS'라는 전국연합게임동아리에 속해있었다.

그 전날 여러동아리가 함께한 대학생 게임연합동아리 발표회를 참여했었는데 

거기에서 정말 눈에 띄는 게임 하나가 바로 이 '도라셔다'였다.

게임의 컨셉이 확실하고 아트나 사운드가 너무 퀄리티가 높아서 잊을 수가 없었다.

진짜 다시봐도 사운드라던가 아트라던가 대단하다.

전날에는 다들 이 게임을 할려고 모여있어 잘 즐기지를 못했지만

다행이 BIC 에서는 충분히 즐길 시간이 되어서 호들갑떨면서 막 좋아했다. 

오구게임도 있었다. 게임이 전시되어있고 오구 그리신 작가님도 같이 있으셨는데 여기서 충격적인사실!

남자친구는 오구 이모티콘이 있는지 모르고 오구캐릭터 자체를 게임으로 알고있었다!

카톡 이모티콘으로 처음접한 나는 충격받았고, 남자친구도 충격받았다.

​

그리고 오구캐릭터가 캐릭터성이 확실한만큼 게임 아트도 깔끔하고 좋았는데..

항상 시연하던 사람들이 많아서 기다리다가 게임을 결국 못즐겼다 ㅠㅜ.,.

그래도 기다리면서 오구 엽서를 받았다. 귀엽다

이 날 BIC페스티벌을 참가하면서 진짜 뼈저리게 느낀게 고양이가 인기가 정말 많구나 였다.

진짜 고양이가 나와있는 게임의 거의 과반수를 차지했다고해도 과언이 아닐정도로 고양이게임이 정말 많았다.

귀엽긴 귀엽지!! 근데..나는 멍멍이파인데.. o(TヘTo)멍멍이 화이팅..

내가 멍멍이 게임 만들어야겠다.. 화나...

​

근데 화나는거랑 별개로 위 사진에 있던 고양이 게임 재밌었다.

고양이가 되게 쭉쭉 잘 늘어난다라는 점을 이용하여 진행한느 방식이었는데, 난이도가 악랄했다.

조작이 익숙치 못해서 그렇다고해야하나.. 결국 하는도중에 나왔다..

나 말고도 어려워하는 사람들이 꽤 있는것같았다..근데 귀여워서 봐줌

이 게임도 직접해봤는데 되게 컨셉이 신박하고 재밌었다. 게임도 나름 즐거웠고

근데 그 뒤에 남자친구에게서 들은 얘기로는.. 개발자가 좀 변태가 아닌가싶은..

그런 요소들이 있다고해서 충격받았다. 캐릭터들 귀여웠는뎅...

​

아 그리고 충격받은게 위 게임이 정말 깔끔하고 잘만들어졌길래 이건 어떤 엔진으로 만든거냐고 물었었는데 그때 담당자분께서 본인은 마케팅부라서 잘 모르겠는데.. 아마.. 자체엔진으로 알고있다고 하시길래

아~ 그렇구나 하고 옆에 다른부스를 구경하고있었는데 오셔가지고 개발팀에 연락해보니까

유니티를 베이스로 만들었다고 얘기를 전해주셨다. 친절해!

​

아니 친절한것보다 유니티라니??? 와 내가 알고있던 유니티가 맞나..싶더라..

나는 아직 배우고 가야할 길이 먼것같다.

이 게임은 펭귄들한테 일시키는 컨셉의 게임이었는데

영수증?에 적힌 요구사항에 따라 가방에다가 필요물품들을

넣어서 보내면되는 게임이다.

​

와 아트가 진짜 화려하고 색감도 감각적이고

캐릭터들도 너무너무 귀엽더라 !! 게임은 아트가 진짜진짜 중요하구나 한번 더 느꼈다.

​

아 게임은 되게 직관적이고 쉽고 재밌었다.

깔끔하고 조아조아!

이 게임은 남자친구가 엇,게임방송에서 봤던 게임이다! 라고 해서 들리게되었다.

스토리 위주로 흘러가는 게임이라 힐링게임이며 픽셀아트가 예쁘게 잘 들어갔다.

​

이 게임은 부스에 나온게 에피소드2이며 1은 2년전?에 나왔다고한다.

부스에 있던 분들의명함도 되게 게임에 맞춰서 예뻐가지고

처음에는 명함이 굿즈인줄 알았다.

여기 게임이 인상깊고 제일 재밌었다! 

여기 부스의 담당자분께서는 위의 coffeeTalk부스에 담당자분과 함께 계시길래

처음에는 그 부스의 사람인줄 알았는데 알고보니 여기 부스의 사람이셨다.

아, 물론 다들 외국인! ㅎㅎ..

​

처음 부스에 갔을때는 게임의 컨셉에따라 간단한 카드마술을 보여주셨는데

와..ㅎㅎ 영어로 얘기하시니까 영어듣기시험같아서 머리 열심히 굴리면서 들었다.

마술을 다 보여주시고 나서는 이런 기술을 여기 게임에서 알 수 있다며 게임을 해보라고 하셔서 했는데

​

정말재밌었다!! 그리고 아트가 중세풍이고 되게 서양동화?그림형제 동화에 나올것같은 아트였는데

아트가 컨셉에 잘 맞춘덕에 더 몰입해서 할 수 있었던것같다.

다들 그렇게 생각했는지 BIC어워드에서 그랑프리부문을 수상하였다. 그럴만하다!

신박하고 재밌다.

고양이를 활용한 아름다운 게임! 루시아 게임은 아트가 정말

포근하고 부드럽고 따뜻하고 예뻣다. 고양이의 귀여움을

극강으로 집어넣어 아름답게 게임으로 표현한다면 이런느낌이 아닐까? 싶을정도

​

게임을 시연하면서 7가지인가 문양을 모으면 굿즈를 더 주신다고 하셨는데

4개인가밖에 못모았다. 와 어디에 숨어있었지????진짜 감도 안오던데..

사실 얘기는 안했지만 쿠킹덤도 있었고 낙원의기록도 있었고 Wetory라는 게임도 있었고

한국 요괴? 관련 게임 등등 많았다. 쿠킹덤에서 가방주셔서 덕분에 편하게 굿즈들을 모으면서 구경을 잘했던것같다. ㅎㅎ 와 너무너무 재밌었다. 부스에 있던 게임을 만드신 사람들의 열정도 너무 좋았고 페스티벌에 구경하러온 사람들의 애정들도 너무 좋았고 게임에 대한 자극을 열심히 받고 가는것같다.

다음에 지스타할때도 꼭꼭 가야지! ㅎㅅㅎ!!

( + 지스타 후기도 곧 올리겠습니다! :D)

항목13에서 본 shared_ptr(auto_ptr은 이후에 삭제되었다고한다)은 힙이 아닌 다른 자원에는 맞지않다라는 견해가 일반적이다.

하지만 모든 자원이 힙에서 생기지는 않는다. 그래서 자원 관리 클래스를 우리가 스스로 만들어야할 필요성이 있다.

class Lock{
public:
    explicit Lock(Mutex *pm)
    :mutexPtr(pm)
    { lock(mutexPtr);}
    
    ~Lock() {unlock(mutexPtr);}
    
    private:
    Mutex *mutexPtr;
};

잠금을 관리하는 클래스를 하나 만들고 , RAII법칙을 따라한다고하자. 

Lock m11(&m);
Lock m12(m11);

하지만 여기서 복사를 하게 된다면 어떻게 될까?

복사할때 이루어지는 동작과 관련해서 선택지를 고를 수 있다.

1. 복사를 금지한다.

복사하면 안되는 RAII클래스(위와 같은 Lock)의 경우에는 복사가 아예 안되도록 막아놓아야한다.

이 경우에는 복사함수를 private 멤버로 만들면된다.

2. 관리하고 있는 자원에 대해 참조 카운팅을 수행한다.

해당 자원을 참조화는 객체의 개수에 대한 카운트를 증가시키는 식으로 RAII 객체의 복사 동작을 만들어야한다.

shared_ptr이 이러한 방식을 사용하고있다.

하지만, shared_ptr의 경우에는 참조카운트가 0이되면 삭제가 되기때문에 Lock을 해제만 하고싶지 삭제를 하고싶지않은 사람에게는 다소 목적이 안맞을 수 있다.

class Lock {
public:
    explict Lock(Mutex *pm)
    :mutexPtr(pm, unlock) //삭제자로 umlock함수 사용
    {
    lock(mutexPtr.get());
    }
private:
    std::tr1::shared_ptr<Mutex> mutexPtr; //원시포인터 대신, shared_ptr사용
};

이런경우에는 shared_ptr에 '삭제자'(deleter)라는 것이 있다. 삭제자란 shared_ptr의 참조 카운트가 0이되면 호출되는 함수 혹은 함수객체를 일컫는 말이다. 이 삭제자를 shared_ptr 생성자의 두번째 매개변수에다가 선택하여 넣어줄 수가 있다.

이러면 소멸자를 선언할 필요 없이 비정적데이터 멤버(mutexPtr)의 소멸자가 자동으로 호출되는데, mutexPtr의 소멸자는 shared_ptr의 삭제자가 자동으로 호출되어진다!

3. 관리하고 있는 자원을 진짜로 복사한다.

 자원관리 객체를 복사하면 그 객체의 자원까지 복사되어야하기때문에 깊은 복사를 수행해야한다. 

4. 관리하고 있는 자원의 소유권을 옮긴다.

현상 : 

 프로젝트를 실행시키고나서 오브젝트들이 회전을 해야하는데 하지않았습니다.

살펴보니 씬에서는 오브젝트의 콜라이더만 정상적으로 작동하고, 오브젝트는 작동하지않았습니다.

인스펙터창에 Rotation도 콜라이더와 똑같이 정상적으로 작동하였으나, 오브젝트만! 움직이지않았죠.

원인 :

원인은 Mesh때문이었습니다.

정확하게 말하면 Combined Mesh (root:scene) 2(Mesh Filter) 때문이었죠.

해결:

인스펙터창에 static 중, Batchong Static을 풀어주면됩니다.

회전이 잘됩니다.

원인분석:

Batchong Static 은 움직이지않는 동일한 재질을 공유하고있는 오브젝트들을 일괄처리함으로써

드로우콜을 줄여 최적화를 자동으로 도와줍니다.

씬을 시작할때 작동하며, 런타임중에는 따로 연산을 하지않는다고합니다.

저는 스크립트로 필요할때만 회전하게 할려다보니 이런 상황을 맞닥뜨린것같습니다.

다른 mesh를 쓰지만 같은 material을 공유하고있는것도 어느정도 작용했겠죠..

하지만, 같은 mesh를 쓰는건 아니기에 batch에서 딱히 차이는 없었고

아마 개수가 엄청나게많은게 아닌이상에는 동적인 연출을 위해서 끄고 작업할 것같습니다.

자원을 객체에 넣음으로써,  C++가 자동으로 호출해 주는 소멸자에 의해 해당 자원을 저절로 해제할 수 있다.

표준라이브러리에 auto_ptr클래스가 있는데, 이 클래스는 포인터와 비슷하게 동작하는 스마트포인터로서 가리키고있는 대상에 대해 소멸자가 자동으로 delete를 불러주도록 설계되어있다.

void f()
{
    Investment *pInv(createInvestment());
    //createInvestment() 는 Investment 클래스의 객체를 동적할당하고 포인터 반환함수
    ...
    delete pInv;
 }

void f()
{
    std::auto_ptr<Investment>pInv(createInvestment());
    ...
 }

위의 코드에서는 delete에 도달하기전에 빠져나갈 요소들이 분명 많아보이지만, 밑에 auto_ptr을 쓰는 경우에는 위의 코드에서 생길 수 있는 자원누출을 막을 수 있다.

여기서, 자원관리에 객체를 사용하는 방법의 두가지 특징을 알 수 있다.

1. 자원을 획득한 후에 자원 관리 객체에게 넘긴다.

자원획득 초기화( Resource Acquisition Is Initialization: RAII) 라는 용어가 있다. 자원획득과 자원관리 객체의 초기화가 한문장에서 이루어진다는것이다. 

2.  자원관리 객체는 자신의 소멸자를 사용해서 자원이 확실히 해제되도록 한다.

auto_ptr은 자신이 소멸될때 가리키고 있는 대상에 대해서도 자동으로 delete를 해준다. 

그렇기때문에 객체를 가리키는 auto_ptr이 둘이상이라면 자원이 두번 이상 삭제되는 결과가 나온다.

이러한 상황을 막기위해 auto_ptr객체를 복사하면 원본 객체는 null로 만든다.

하지만 auto_ptr을 쓰지 못하는 상황(STL 컨테이너)이라면 참조카운팅 방식 스마트 포인터(reference-counting smart pointer: RCSP)방식 또한 좋다.

가비지 컬렉션과 비슷하게 어떤 자원을 가리키는 외부 객체의 개수를 유지하고있다가 그 개수가 0이 되면 해당 자원을 자동으로 삭제하는 스마트포인터인데, 가비지 컬렉션과 다르게 서로가리키고 있는 상황에서도 없앨 수 있단게 특징이다.

void f()
{
    std::tr1::shared_ptr<Investment>pInv(createInvestment());
    // tr1::shared_ptr이 대표적인  RCSP이다.
    ...
 }

하지만 여기서 중요하게 봐야할건, auto_ptr, shared_ptr 둘다 동적으로 할당한 배열에 대해서는 쓰지 못한다. 

왜냐하면 동적으로 할당도니 배열은 vector나 string으로 대체할 수 있기때문이다.