-

스크립터블 오브젝트는 말이 너무 길어서

"SO" 정도로 줄여서 표현할게요.

목차

0. 서론

1. SO, 왜 쓰는가?

2. 활용 시 지니는 생각

3. 생각의 흐름

4. 일지에 쓴 SO 설명

5. 6줄 요약

0. 서론

며칠 전 썼던 개발 일지에 한 분이 질문 달아주셨는데,

답변이 좀 길어져서 쓰는 글이에요.

해당 글:

https://gall.dcinside.com/mgallery/board/view?id=game_dev&no=158098

질문해 주신 내용을 보고,

'SO 사용법은 봤는데,

다른 구조에 적용하려고 보니 감이 안 잡혀서

적용 예시가 필요한 상태.'

정도로 이해했어요.

그래서 제가 어떤 생각으로 사용하고 있는지 적으려고 해요.

저도 초보라, 이보다 좋은 활용 방법이 많고

아예 틀린 내용이 있을 수 있지만,

처음에 감을 잡는 데에는 도움이 될 수 있다고 생각해요.

1. SO, 왜 쓰는가?

이건 이미 아시는 내용일 수 있지만,

저는 원래 목적에서 약간은 변질된 목적을 생각하며 사용하고 있는 듯 해서

원래 목적을 먼저 짚고 가려고 해요.

만약 몬스터를 만든다고 가정할 때,

몬스터의 정보(ex: 체력, 공격력, 방어력... 등등)를

아래처럼 변수로 넣어둘 수가 있는데,

이런 스크립트 넣은 오브젝트가 많아지면...

이 정도 크기의 스크립트 정도는 괜찮지만,

변수가 아주 많아진 스크립트가 수백, 수천개로 늘어나면

컴퓨터가 메모리 관련해서 힘들어할 거예요.

이때 컴퓨터를 덜 힘들게 하기 위해

SO라는 에셋에 정보를 모아서 담아두는 거예요.

아래 그림처럼요.

*대괄호 속 내용이 메모리 차지

이렇게 SO를 추가해 '몬스터A'의 주소만 표시하면

대괄호 속 내용의 양을 줄일 수가 있는 거죠.

2. 활용 시 지니는 생각

위 예시처럼 SO를 사용하면, 스크립트와 인스펙터는 이렇게 돼요.

이걸 보고, 저는
'SO가 마치 줄임말 같다'라는 생각을 했어요.

'공격했을 때

공격력, 체력, 방어력... 등등을 가져오기 귀찮다.

그런데 이 정보들을 SO에 담아두면 monsterA만 넘겨주면 된다.'

이런 마인드예요.

위 [ 1. SO, 왜 쓰는가? ]에 적힌 이유는 오직 '메모리'인데,

막상 이용할 때는 '줄임말'로 쓰게 돼요.

줄임말로써 SO를 쓰다 보면 어느새 메모리 이득을 보고 있게 되더라고요.

3. 생각의 흐름

앞의 내용을 토대로 제가 SO를 쓸 때

하는 생각의 흐름을 간략하게 적어 볼게요.

일지에 적혀있는 직접 사용한 축복이나 장신구 데이터 설명은

아래 [ 4. 내가 쓴 SO 설명 (일지 내용) ] 에 있어요.

1) 불편함을 미리 감지

무언가 구현하기 전에 미리 불편할 상황을 상상해 보고,

불편함을 감지했다면 데이터(SO)를 만드는 거예요.

아래는 ItemData라는 SO를 만들기까지의 생각 예시예요.

ex1: "인벤토리에서 한 슬롯을 선택 중이라면,

선택 중인 아이템 정보를 툴팁에 띄워야겠어."

-> 필요한 정보가 아이템 이름, 설명, 그림... 뭐가 많네?

-> '불편하다'

-> SO "ItemData" 생성

ex2: "이 아이템을 착용한 상태라면,

아이템의 추가 능력치를 플레이어에게 적용해야겠어."

-> 필요한 정보가 아이템의 공격력, 체력, 방어력... 뭐가 많네?

-> '불편하다'

-> SO "ItemData" 생성

ex3: ...

이런 예시들 중 하나만 있어도

SO를 만들 가치는 충분하다고 생각해요.

반대로 이런 불편함이 여러 가지로 예상된다면

SO를 가능한 빨리 만들어야겠지요?

2) 데이터 생성의 선택지

한 가지 목표에도, 여러 가지 방법으로 데이터(SO)를 만들 수 있는데,

따로 정답이 있는 건 아니에요. 하지만

다양한 방법 중 본인 or 팀에게 맞는, 쓰기 편한 게 최고예요.

ex: 아이템을 강화하면,

붙어있는 능력치가 올랐으면 좋겠어.

방법 I. 강화한 버전의 아이템(ItemData)을 추가해서, 강화하면 아이템을 바꿔주기.

방법 II. 강화할 능력치가 담긴 ReinforceData(SO)를 새로 만들어서, 강화하면 아이템이 담긴 슬롯에 해당 강화 데이터(ReinforceData) 넣어주기.

+) 추가로, ItemData에 이 아이템에 붙일 수 있는 강화 목록(ReinforceData[])을 넣어줄 수도 있어요.

방법 III. ...

당연히 앞으로 개발할 방향에 따라 방법이 어느 정도 정해지겠지만,

경우에 따라 '이 방법 말고 저 방법으로 할걸 ㅠㅠ' 하고 후회할 수 있으니

나름 신중하게 고민하는 것을 추천해요.

다시 바꾸는 건 귀찮거든요.

물론 진심으로 후회가 될 때는 바꾸면 그만이긴 합니다.

+) 생각나면 바로 생성

내용을 줄일 수 있는 게 생각나면

아래처럼 ~~Data 형태로 계속 만들고 있어요.

몇 개 없다고 생각했는데, 꽤 많아졌더라고요.

4. 일지에 쓴 SO 설명

어쩌면 글의 핵심이 될 내용이네요.

이제는 일지에 보였던 축복, 장신구, 보석 데이터에서

특징적인? 요소들 몇 개만

왜 그렇게 만들었는지 간단히 설명 붙이면서, 글 마무리할게요.

- 축복 데이터 (예시)

Blessing Type: 정보 창 글자 색을 위한 변수.

보여질 축복 리스트 정보 창의 정렬을 위해 쓸 지도 몰라서,

이름을 Color 아닌 Type으로 했어요.

+) 열거형 자료형 enum 사용했어요

- type buff

- type debuff

- type epic

int[] Blessing Value: 축복 레벨에 따른 적용 값

- 장신구 데이터 (예시)

장신구 데이터는 얼핏 보면... 복잡해 보이는데요.

장신구에 끼운 보석에 따라 적용될

축복 리스트 + 장신구 그림.

이 2개를 담아둔 것이 전부입니다.

한 마디로 '이 장신구를 끼면 어떤 축복들이 적용될 것인가'

를 위한 데이터예요.

축복 리스트(Blessing Datas Amount): (축복 데이터+축복 레벨)[]

어떤 축복이 몇 레벨씩 적용되는지 체크.

Blessing List_empty Gem: 보석을 미착용한 상태의 축복 리스트

이제 착용한 보석이 뭔지 알아야 하는데,

보석은 색과 레벨로 나뉘기 때문에

Gem Color List에 있는 Gem Color로 보석의 색깔을,

Blessing Lists_by Gem Lvl의 인덱스로 레벨을 구분해요.

결국 그 안에는 해당 보석을 꼈을 때의 축복 리스트가 있어요.

Gem Color List에 있는 Sprite Accessory With Gem에는

그 색 보석을 착용한 장신구의 그림이 들어가요

- 보석 데이터 (예시)

Gem Color_index: 위의 장신구 데이터에서 Gem Color List를 통해 축복 리스트를 얻어내야 하는데,

매번 for문 같은 거 돌려 '이 리스트가 이 보석이랑 같은 색인가?'를 쓰기가 좀 거시기해서 추가했어요.

Item_gem: 보석은 장신구에 장착하는 '보석'이기도 하면서, 인벤토리에서도 존재하는 '아이템'이에요.

그래서 GemData도, ItemData도 존재해요. 타고 타고 들어가는 게 편할 거 같아서

ItemData에도 보석 데이터를, GemData에도 아이템 데이터를 양쪽 다 넣어 두었어요.

Next Level Gem: 보석을 세공해 업그레이드할 때, 건네줄 다음 레벨의 GemData예요.

5. 6줄 요약

1. SO를 쓰는 원래 목적은 메모리 때문이에요.

2. 근데 저는 그냥 줄임말이라고 생각하는 게 편하더라고요.

그렇게 쓰다 보면 어느새 원래 목적에도 맞게 되거든요.

3. 불편함을 미리 감지해 SO를 만드는데,

다양한 방법 중 본인 or 팀에게 맞는, 쓰기 편한 게 최고예요.

4. 제가 쓴 것들 풀이예요.

쓰다 보니 글이 꽤 길어졌네요...

긴 글 읽어주셔서 감사합니다.