어떻게든 굴리는 게임 공방

게임 아이콘 서울 2026 참여 후기

ybbro — Fri, 29 May 2026 19:19:41 +0900

https://www.gameaicon.com/

GAME AICON Seoul 게임아이콘 서울

게임아이콘 서울(GAME AiCON Seoul)은 글로벌 게임산업과 인디게임을 연결하고 AI 시대의 새로운 기회를 논하는 B2B 게임 네트워킹 컨퍼런스입니다

www.gameaicon.com

대표님께서 인디 게임 개발자님들과의 모임에서 좋은 기회를 얻어

신규 인디 게임사에 대한 지원으로

게임 아이콘 서울 2026에 우리 SpaceCowboy 사의 Inkoid 부스를 낼 수 있게 되었습니다.

해당 행사는 B2B (비즈니스 투 비즈니스) 로 온라인 / 오프라인을 통해 각각 진행되었습니다.

온라인 미팅은 업체와 시작 시간을 정해서 15~30분 정도로 진행이 되었습니다.

우리 팀은 노트북 성능이 좋지 못하여 데스크로부터 대여하여 진행할 수 있었습니다.

그리고 게임에 대해 발표하는 하는 피칭 덱 시간이 있었는데
AI 동시 번역 업체도 행사에 참여해서 기술 지원을 해주셨습니다.

덕분에 원활한 진행이 가능하여 좋았습니다.

1. 퍼블리싱

큰 기업들을 포함한 여러 업체의 바이어들이 현장에 오셔서
관심있는 게임들에 대한 설명을 듣고 연락처를 교환하고는 하였습니다.

2. 협업
사운드, 그래픽, 백앤드, 유저 테스트, 현지화, 광고 등 다양한 분야의 업체도 참석하였습니다.

해당 분야의 새로운 정보를 얻을 수 있어 시야와 견문을 넓힐 수 있었으며

다음에 협업할 업체들과 인연을 쌓을 좋은 기회도 얻을 수 있었습니다.

3. 다른 인디 개발자들과의 만남

50팀이 넘는 인디 개발팀이 자리를 빛내 주셨습니다.

퀄리티가 좋은 팀을 보며 우리 게임에 대한 반성을 하기도 하고

재치있는 아이디어에 감명을 받기도 하였습니다.

그리고 대화하며 얻을 수 있는 다양한 정보들도 많은 도움이 되었습니다.

개발자 님들이 우리 게임을 플레이하며 귀중한 피드백도 해주었습니다.

고민 중이던 게임 개선 문제에 대해 생각지도 못한 방향의 좋은 방향성의 조언을 들을 수 있기도 하고
신규 컨텐츠에 대한 아이디어도 얻는 등

게임을 발전시킬 수 있는 많은 조언을 들을 수 있었습니다.

다음에 부스로 참여하시는 인디 게임 팀이 이 글을 본다면,
1. 연락처를 주고받을 명함은 넉넉하게

2. 헤드셋 혹은 이어폰(노이즈 캔슬이 되면 더 좋을 것 같아요) 지참 추천

온라인 미팅 중 주위에 다른 팀들도 회의를 동시에 진행하여 소리가 잘 들리지 않을 수 있어요.

3. 게임에 대해 자세한 설명이 가능한 2인 이상이 부스를 운영
한명이 온라인 미팅, 화장실 등의 이유로 자리를 비워도 바이어 님들이 부스에 방문했을 때 현장 응대가 가능하면 더 좋은 인상을 줄 수 있습니다.
팀원의 여유가 된다면 2인 이상 참여를 추천합니다.

4. 오래 서있을 상황에 대한 대비
오래 서 있어야 하기에 발바닥, 발목, 종아리 등이 아플 수 있어요.
이에 대한 대비도 해가면 좋을 듯합니다.
전 가장 두꺼운 양말, 깔창 2개, 가장 편한 신발을 신었고 손님이 없을 때 스트레칭이나 부스 의자의 도움을 조금씩 받았어요.
그리고 첫날에 집에 와서 파스를 사용했네요.

5. 보조 배터리 (상황에 따라 선택)

부스는 2구 콘센트, 모니터 1대, 의자 1개 이렇게 단출한 구성으로 되어 있었습니다.

우리 게임의 경우 모바일 게임이 타겟이었기에

노트북, 모니터를 사용하여 부스 정면, 옆면에 PV를 반복 재생하였고

콘센트 수가 부족하여 보조 배터리를 이용하여 충전하며 게임 시연을 하였습니다.

우리 팀과 같은 느낌으로 운영할 팀은 보조 배터리를 지참하는 것을 추천합니다.

그 외 부스에 물, hdmi 케이블 등 현장에 비치된 것은 요청하면 받을 수 있습니다.

우리 부스에는 hdmi to hdmi 케이블이 없는 관계로
부스 운영 이틀차에 지참했는데 다른 부스에는 기본적으로 있었다더군요.
부스 운영 전날에 부스를 한번 보고 없으면 미리 요청해두시는 걸 추천합니다.

재밌고 멋진 우리의 게임을 알리거나 협업할 업체를 찾는 쉽지 않은 길

게임 아이콘 서울과 함께해 보시는 건 어떠신가요?

랑그릿사 7주년 이벤트 공유

ybbro — Fri, 29 May 2026 13:58:30 +0900

TPS 게임 내 덱 빌딩 카드 개발 - (2) 장착 카드 데이터 형식

ybbro — Mon, 4 May 2026 19:38:22 +0900

1. ScriptableObject 를 활용한 데이터 관리

using UnityEngine;


[CreateAssetMenu(fileName = "EquipCard_", menuName = "EquipCard/Card")]
// 장착 카드 데이터
public class EquipCard_Data : ScriptableObject
{
    // 아이콘
    [field: SerializeField, Header("아이콘")] public Sprite icon { get; private set; }
    // 종류
    [field: SerializeField] public EquipCard_Sort_Selector equipCard_Part { get; private set; }

    // 등급
    [field: SerializeField, Header("등급")] public EquipCard_Rank rank { get; private set; }
    // 장착 코스트
    [field: SerializeField, Header("코스트")] public int cost { get; private set; }
    // 능력치 변화들
    [field: SerializeField, Header("능력치 변화")] public StatusChange[] statusChange { get; private set; }
}

// 장착 부위
public enum EquipCard_Part
{
    InkWell,
    Body,
    Hook,
    Shooter,
    Shotgun,
    Charger,
    RPG,
    Drill,
    Chaser,
    Gatling,
}

// 인스펙터 정리 + 작업 효율을 위한 커스텀 에디터를 쓰기 위해 사용
// 장착 부위를 드롭다운으로 선택 >> 해당 부위의 장착 카드, 특수 능력만 출현
// 텍스트
[System.Serializable]
public class EquipCard_Sort_Selector
{
    public EquipCard_Part category;
    public string sort; // 실제 선택된 키 이름 (문자열로 저장)

    // sort에 따라서 특능 부여하면 안되나?
    // 같은 종류의 카드라도 이후 등급에 따라 특능이 생기거나 빠질 수 있기에 따로 두자
    public string ability;
}

// 장착 부위 별 카드 종류
// >> 장착 부위 + 종류 값을 통해 어떤 카드인지 판별
// >> 정보 가져와서 보여주기

// 잉크통
public enum EquipCards_InkWell
{
    Light,
    Big,
    Super_InkGenerator,
    Unauthorized_Nozzle,
}

// 바디
public enum EquipCards_Body
{
    Light,
    GPU_Upgrade,
    Memory_Upgrade,
    Overload_Booster,
    Ink_Burster,
    Magnet,
    Transparency,
}

// 그래플링 훅
public enum EquipCards_Hook
{
    WithPaint,
    Big,
    Absorb_HP,
    Absorb_Ink,
    Traction, // 견인
}

// 무기
// 슈터
public enum EquipCards_Shooter
{
    Shooter_Large_diameter,
    Shooter_Assult,
    Shooter_Bounce,
}

// 샷건
public enum EquipCards_Shotgun
{
    Shotgun_High_Pressure,
    Shotgun_Sprayer, // 분무기 칙칙
    Shotgun_InkEjector, // 잉크 방사기(화염방사기랑 비슷함)
}

public enum EquipCards_Charger
{
    Charger_Quick,
    Charger_Beam,
    Charger_MapHack,
}

public enum EquipCards_RPG
{
    RPG_Grenade_Launcher,
    RPG_Nuclear,
    RPG_EMP,
    RPG_Pressure,
}

public enum EquipCards_Drill
{
    Drill_Large,
    Drill_Sharp,
    Drill_Durable,
    Drill_Skyroad,
}

public enum EquipCards_Chaser
{
    Chaser_Wing,
    Chaser_Smart,
}

public enum EquipCards_Gatling
{
    현재_아이디어_없음,
}

// 부품 등급
public enum EquipCard_Rank
{
    Normal,
    Rare,
    Epic,
    Legend,
}

// 어떤 종류 + 얼마나 변화시키는지 통합 관리
[System.Serializable]
public class StatusChange
{
    public StatusToChange statusToChange;

    [Tooltip("얼마나 변화시킬지 % 그대로 쓰기 \n" +
             "예) 5% 증가 = 5 \n" +
                 "3% 하락 = -3")]
    public float percentage;
}

// 어떤 종류의 스텟을 변화시키는지
public enum StatusToChange
{
    maxHP,
    maxInk,
    moveSpeed,
    InkRecover_Natural,
    InkRecover_Boost,
    RespawnTIme,

    EquipCard_maxCost,

    // 갈고리
    Hook_Speed,
    Hook_Range,

    // 무기
    Weapon_AtkDelay,
    Weapon_inkConsume,
    // 히트스캔 타입은 사거리가 존재하기에 해당 스텟 추가
    Weapon_HitScan_Range,
    Weapon_Charger_maxChargeTime,

    // 탄환
    // 샷건, 차저와 같은 히트스캔 타입 무기는 아래 Bullet에서 바꿔주면 무기에 바로 적용되게끔
    Bullet_Speed,
    Bullet_LifeTime,
    Bullet_Damage,
    Bullet_Paint,
}

// 장비 특수 능력
// 게임 시작 시, 착용 특수능력들에 따라 착용 특수 능력들이 작용하는 곳에 값 부여
// UI 특능 작동 버튼 출현 같은 간단한 것은 해당 착용 특수 능력들이 작용하는 곳에서 분기 처리

// 무기/탄환 매커니즘 같은 복잡한 것은 기존 스크립트 상속 및 특능 착용에 따라 교체하도록 하면
// 기존 매커니즘을 건드릴 필요가 없어 문제 시 기존 부분은 정상 플레이 가능하게끔 할 수 있음

// 장착 부위별로 특수 능력을 만들어둠
// >> 이후에 다른 부위를 추가할 일이 있더라도 확장성이 좋음 + 세분화하여 관리 및 인스펙터 작업이 편함

public enum SpecialAbility_InkWell
{
    None,
}

// 몸통
public enum SpecialAbility_Body
{
    None, // 기본 = 없음

    // 1. 과부하 부스터
    // n1초간 이동 속도 증가 + 그 후 n2초간 딜레이 및 해당 시간 동안 이동 속도 감소
    // >> 짧은 시간 고출력을 내는 대신 과부하
    Body_OverloadBooster,

    // 2. 잉크 버스터
    // 잉크 30 사용(부족 시 UI 버튼 disable로 사용자에게 사용 불가 상태 알림)
    // 범위 내 플레이어 넉백(1회성 물감이 펑 터지는 느낌의 충격파로 상대 팀은 대미지를 주면서 밀어냄 + 아군은 그냥 밀어냄) + 색칠 가능한 구조물들에 색칠
    // 사용 이후 쿨타임 n초 + 그 동안 물감 자연 회복력 감소
    Body_InkBurster,

    // 3. 마그넷 잉크
    // 자성을 띤 잉크를 도포(시전 캐릭터 주위로 블랙홀 느낌의 물감 이펙트)하여 상대 플레이어를 자신의 주위로 끌어들임  
    Body_Magnet,

    // 4. 투명 잉크 도포 장치
    // >> 잉크 30 사용(부족 시 UI 버튼 disable로 사용자에게 사용 불가 상태 알림). 사용 시 2~3초간 투명화(본인 클라에서는 자신이 반투명, 투명화 사용 시 오토 에임의 타겟이 되지 않도록) + 투명 상태에서 이동속도 감소. 재사용 쿨타임 n초
    // >> 교전, 생존에 유리한 투명화 효과를 가져가는 만큼 잉크를 사용하게 하여 투명화 이후 폭발적인 화력을 내는 데 제약을 둠
    Body_Transparency,
}

// 그래플링 훅
public enum SpecialAbility_Hook
{
    None, // 기본 = 없음

    // (1) 잉크 갈고리
    // >> 그래플링 훅 사용 시 해당 위치에 물감 색칠. 단, 색칠은 크지 않게. 쿨타임 n초 + 물감 자연 회복량 감소
    // >> 모바일에서 조준 + 그래플링 훅을 사용하는 것을 줄여줄 수 있음. 대신에 훅을 보다 자주 사용해야 하게끔 자연 회복량을 줄이기
    Hook_WithPaint,

    // (2) 거대한 갈고리
    // 그래플링 훅 머리의 크기를 키움 
    // >> 머리의 크기가 커진 만큼 방사형으로 레이캐스트를 여럿 쏘아서 주변의 물감 색칠도 탐색하게끔 (물감 충전이 쉬워짐 + 다른 물체를 맞추기 쉬워짐) + 훅의 물감 고속 충전 속도 상승, 이동 속도 감소
    Hook_Big,

    // (3) 모기 갈고리
    // 상대 팀에 갈고리 부착 시, HP 뺏어오는 기능, 갈고리 발사 속도 증가, 최대 HP 감소
    Hook_Absorb_HP,

    // (4) 잉크 갈취 갈고리
    // 상대 팀에 갈고리 부착 시, 잉크를 뺏어오는 기능, 갈고리 발사 속도 증가, 최대 잉크 감소
    Hook_Absorb_Ink,

    // (5) 견인 갈고리
    // 맞은 상대를 자신에게 끌고 오는 갈고리(견인 쿨타임 N초), 이동속도 소폭 감소
    Hook_traction,
}

// 무기
public enum SpecialAbility_Shooter
{
    None, // 기본 = 없음
    Shooter_Bounce, // 튕기는 탄환 >> 이건.. Bullet을 상속하는 BouncingBullet을 하나 만드는 게 더 깔끔해보임
}

public enum SpecialAbility_Shotgun
{
    None, // 기본 = 없음
    Shotgun_flamethrower, // 화염방사기처럼 발사
}

public enum SpecialAbility_Charger
{
    None, // 기본 = 없음
    Charger_mapHack, // 조준 중에 구조물 뒤의 플레이어가 보임
}

public enum SpecialAbility_RPG
{
    None, // 기본 = 없음
    RPG_multiple, // 한번에 모든 물감을 발사하지 않음 >> 연사 가능
    RPG_EMP, // 맞은 적들에게 짧은 시간 조작 불가 부여(지직거리는 이펙트라던지.. 플레이어들에게 상태를 나타낼 것도 필요)
    RPG_Press, // 폭발 진원지로부터 반대 방향으로 날아가게끔 힘 주기 (팀원도 날려버리면?)
}

public enum SpecialAbility_Drill
{
    None, // 기본 = 없음
    Drill_skyroad, // 드릴이 지나간 자리에 길 이펙트가 남아 닿는 상대에 대미지
}

public enum SpecialAbility_Chaser
{
    None, // 기본 = 없음
    Chaser_Wing, // 한번에 6발 + 옆 방향으로 발사하는 체이서
}

public enum SpecialAbility_Gatling
{
    None, // 기본 = 없음
    //Gatling_, //게틀링.. 은 아직 아이디어가 없음
}

2. 커스텀 에디터

인스펙터에서 데이터 작업 실수를 줄이기 위한 장비 카드 장착 부위에 따른 enum 세분화

장비 장착 부위 선택 -> 해당 부위 카드 종류, 특수 능력 enum으로 변경

// 드롭다운 선택 enum에 따라 이하 항목 세분화(작업 효율성 증대 + 작업자 실수 방지)를 위한 커스텀 에디터
// >> 장비 종류별 카드

#if UNITY_EDITOR
using System;
using UnityEditor;
using UnityEngine;


[CustomPropertyDrawer(typeof(EquipCard_Sort_Selector))]
public class EquipCard_Sort_Drawer : PropertyDrawer
{
    public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
    {
        var categoryProp = property.FindPropertyRelative("category");
        var sortProp = property.FindPropertyRelative("sort");
        var abilityProp = property.FindPropertyRelative("ability");

        EditorGUI.BeginProperty(position, label, property);

        // 카테고리 선택
        Rect categoryRect = new Rect(position.x, position.y, position.width, EditorGUIUtility.singleLineHeight);
        EditorGUI.PropertyField(categoryRect, categoryProp);

        // 카테고리에 따라 enum 타입 결정
        // sort
        Type enumType_sort = null;
        // ability
        Type enumType_ability = null;
        switch ((EquipCard_Part)categoryProp.enumValueIndex)
        {
            case EquipCard_Part.InkWell: 
                enumType_sort = typeof(EquipCards_InkWell);
                enumType_ability = typeof(SpecialAbility_InkWell);
                break;
            case EquipCard_Part.Body:
                enumType_sort = typeof(EquipCards_Body);
                enumType_ability = typeof(SpecialAbility_Body);
                break;
            case EquipCard_Part.Hook:
                enumType_sort = typeof(EquipCards_Hook); 
                enumType_ability = typeof(SpecialAbility_Hook);
                break;
            case EquipCard_Part.Shooter:
                enumType_sort = typeof(EquipCards_Shooter);
                enumType_ability = typeof(SpecialAbility_Shooter);
                break;
            case EquipCard_Part.Shotgun: 
                enumType_sort = typeof(EquipCards_Shotgun); 
                enumType_ability = typeof(SpecialAbility_Shotgun);
                break;
            case EquipCard_Part.Charger:
                enumType_sort = typeof(EquipCards_Charger); 
                enumType_ability = typeof (SpecialAbility_Charger);
                break;
            case EquipCard_Part.RPG:
                enumType_sort = typeof(EquipCards_RPG); 
                enumType_ability = typeof(SpecialAbility_RPG);
                break;
            case EquipCard_Part.Drill:
                enumType_sort = typeof(EquipCards_Drill);
                enumType_ability = typeof(SpecialAbility_Drill);
                break;
            case EquipCard_Part.Chaser:
                enumType_sort = typeof(EquipCards_Chaser);
                enumType_ability = typeof(SpecialAbility_Chaser);
                break;
            case EquipCard_Part.Gatling:
                enumType_sort = typeof(EquipCards_Gatling);
                enumType_ability = typeof(SpecialAbility_Gatling);
                break;
            // 무기 추가 시 enum을 각각 만들고, EquipCard_Part에 항목을 추가한 뒤, 여기에 추가
        }

        // Sort enum : enumType에 따라 그에 해당하는 enum 항목들을 드롭다운으로 생성
        if (enumType_sort != null)
        {
            Array values = Enum.GetValues(enumType_sort);
            string[] names = Enum.GetNames(enumType_sort);
            int index = Array.IndexOf(names, sortProp.stringValue);
            if (index < 0) index = 0;

            Rect sortRect = new Rect(position.x, position.y + (EditorGUIUtility.singleLineHeight + 3), position.width, EditorGUIUtility.singleLineHeight);
            int newIndex = EditorGUI.Popup(sortRect, "Sort", index, names);
            sortProp.stringValue = names[newIndex];
        }

        // Ability Enum
        if (enumType_ability != null)
        {
            Array values = Enum.GetValues(enumType_ability);
            string[] names = Enum.GetNames(enumType_ability);
            int index = Array.IndexOf(names, abilityProp.stringValue);
            if (index < 0) index = 0;

            Rect abilityRect = new Rect(position.x, position.y + (EditorGUIUtility.singleLineHeight+3) * 2, position.width, EditorGUIUtility.singleLineHeight);
            int newIndex = EditorGUI.Popup(abilityRect, "Ability", index, names);
            abilityProp.stringValue = names[newIndex];
        }

        EditorGUI.EndProperty();
    }

    public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
    {
        return (EditorGUIUtility.singleLineHeight + 3) * 3;
    }
}
#endif

TPS 게임 내 덱 빌딩 카드 개발 - (1) 개요

ybbro — Mon, 4 May 2026 19:29:47 +0900

GAME AiCON Seoul 2026에 전시 참가자 중 하나로 Inkoid 게임이 선정되었습니다.

해당 전시는 B2B 투자 유치의 목적이 강하기에 투자사를 설득할 만한 수익 구조를 보여줄 필요가 있습니다.

하지만 현재 Inkoid의 수익 예정은

안드로이드 버전 기준 광고와 광고 제거 판매 뿐이라 설득력이 굉장히 약하기에

게임의 재미를 더하며 BM으로 활용할 만한 요소를 추가하기로 회의를 했습니다.

기존에는 플레이하여 얻는 포인트의 사용처가 코스튬 외에는 없기에 이를 활용한

장착 카드 뽑기 >> 장착 >> 능력치 변화 or 특수 능력 부여 or 기존과 다른 매커니즘의 무기

플레이 포인트 판매 상품 추가를 통해 투자할 만한 상품으로 개발하려 합니다.

0. 클라우드 저장 + 인벤토리, 장착 정보 항목을 유저 데이터 파일에 추가

자체적으로 서버를 굴릴 규모가 되지 않아 기존에는 로컬에 암호화된 데이터 파일을 저장하는 방식으로 했으나

플레이 포인트 가챠 판매를 할 예정이면 플레이어의 현금성 재화가 날아가지 않도록 적어도 클라우드 저장은 필수

현재 클라우드 저장을 죽여놓은 상태인데, 유니티 클라우드 사용 테스트하여 적용 필요

순서는 장비 매커니즘을 다 만들고 해도 괜찮으나 반드시 해야 함

1. 장비 카드: 단순한 스탯 변화

장비 장착 변경 시, 장착 카드들의 종류 별 스탯 변화 합을 계산하여 유저 데이터에 저장

게임 시작 전, 그 게임 내에서는 변하지 않기에 포톤 pun2 해당 플레이어의 커스텀 프로퍼티에서 가지고 있도록

모든 클라이언트에서 해당 플레이어 리스폰, 무기 변경, 탄환 발사 등의 상황에 스탯 변화 적용해야 동기화에 문제가 없음

2. 장비 카드: 특수능력

장비 장착 변경 시, 특수 능력의 데이터에 해당하는 것을 유저 데이터에 기입
게임 시작 전, 마찬가지로 포톤 pun2 해당 플레이어의 커스텀 프로퍼티

(1) 전투 시작 시 1회성으로 발동
예) 해당 특수능력 UI 버튼 출현 >> 해당 UI를 터치하면 특수능력 작동

(2) 전투 중 매커니즘이 바뀜
기존 스크립트를 상속하여 매커니즘을 변경하여 꼬일 일이 없도록 제작하기 (특수 능력이 많아져도 관리가 용이)

>> 특수 능력에 따라 상황에 맞게 스크립트 변경해주기
예) 무기 작동 방식 변경 >> 무기 변경 시 바꿔주기

그래플링 훅 작동 방식 변경 >> 플레이어 첫 스폰 시 바꿔주기

유니티 UI 앵커 배치 작업 시간을 줄이기 위한 자동화 코드

ybbro — Fri, 27 Feb 2026 13:22:03 +0900

이전에 해상도에 따른 UI 작업을 다룬 포스팅이 있었는데,

앵커를 통해 화면 일정 비율 위치에 UI를 배치하는 방법에 대해 소개를 드렸습니다.

https://ybbro.tistory.com/27

하지만, 그 작업을 모든 UI에 하나하나 하고 있다면 시간 소모가 매우 커집니다.

따라서 그 작업을 자동화하여 아주 빠르고 간단히 진행할 수 있는 에디터 메뉴를 만들었기에 공유드립니다.

<< 적용 전 >>

<< 적용 후 >>

<< 주의사항 >>

1. 해당 스크립트를 만들어 Assets/Editor 폴더에 넣어주시고 주석으로 된 사용법을 따라해보세요.

2. Grid / Vertical / Horizontal Layout Group, ContentSizeFitter 과 같은 자동 정렬 컴포넌트는 계산을 덮어써 비율이 깨지기에 정렬 대상에서 제외되도록 처리해 두었습니다. >> 해당 오브젝트들은 Canvas Scaler의 Match를 조절하여 최대한 맞춰봅시다.

#if UNITY_EDITOR
using UnityEditor;
using UnityEngine;
using UnityEngine.UI;

public class RectTransformAnchorSetter
{
    // 1. 목적
    // 캔버스 스케일러 - UI 스케일 모드를 쓰더라도 기준 화면 비율과 다르게 되면 깨질 수 있음 (pc에서의 창 크기 조절 or 모바일 폰 해상도 비율 다름 등)
    // UI 작업 때 시간이 오래 걸림 + 이후 수정해야 할 수 있어 앵커를 다 맞춰주지는 않는데,
    // 화면 비율이 달라지면 해당 UI들이 의도한 것과 다르게 배치되는 경우가 있기에
    // 현재 위치를 앵커로 마킹한 후 포지션을 0으로 만들어 그 화면 위치 비율에 고정시키는 작업을 하나하나 수작업 해줘야 하는 2차 수고 발생
    // 그 작업 시간을 획기적으로 줄이기 위해 자동화 메뉴를 만들었습니다.

    // 2. 사용법
    // 1) 하이어라키를 전체 선택(단축키 Ctrl + A) (UI가 아닌 요소들은 자동으로 걸러주기에 전체 선택)
    // 2) 유니티 에디터 상단 메뉴 - Tools - UI - Set Anchors To Current Rect 메뉴(단축키 Ctrl + Shift + Q)

    // 메뉴에 항목 추가
    // %#q = Ctrl + Shift + Q 단축키
    [MenuItem("Tools/UI/Set Anchors To Current Rect %#q")] 
    static void SetAnchorsToSelectedRect()
    {
        Canvas.ForceUpdateCanvases();

        // 앵커 프리셋 Middle, Center 설정용
        Vector2 anchorPreset_MiddleCenter = new Vector2(0.5f, 0.5f);

        // 선택된 모든 오브젝트 순회
        foreach (var obj in Selection.gameObjects)
        {
            // RectTransform 컴포넌트 가져오기
            RectTransform rect = obj.GetComponent<RectTransform>();
            // RectTransform이 아니거나 앵커의 기준이 될 부모가 없으면 제외
            if (rect == null || rect.parent == null)
                continue;

            // UI 요소들은 Canvas (RectTransform 포함)의 자식이며 그 안의 요소들도 RectTransform으로 위치 결정
            // 부모도 RectTransform이어야 계산 가능 >> 앵커의 기준
            RectTransform parentRect = rect.parent as RectTransform;
            if (parentRect == null)
                continue;

            // 슬라이더의 자식 오브젝트를 자동 앵커로 하면 Fill, Handle이 깨짐
            // 슬라이더 컴포넌트가 들어간 오브젝트만 앵커를 맞춰주면 그 자식들은 자동으로 부모에 맞춰짐
            Slider slider = rect.GetComponent<Slider>();
            Slider parentSlider = rect.GetComponentInParent<Slider>(true);
            if (parentSlider != null && slider != parentSlider)
            {
                Debug.LogWarning($"{obj.name} 계산 건너뜀.\n원인: 부모에 슬라이더 존재하여 계산 불필요");
                continue;
            }

            // ContentSizeFitter 컴포넌트가 있는 요소 제외 >> preferred size 기준 RectTransform.sizeDelta 강제 조절 >> 앵커 기반 계산과 충돌하여 비율 어긋남
            // >> 다른 컴포넌트나 스크립트에서 위치 계산을 다시해서 덮어쓰면 해당 변환을 수행해서는 안됨. 이하 레이아웃 그룹 제외도 같은 이유
            if (rect.GetComponent<ContentSizeFitter>() != null)
            {
                Debug.LogWarning($"{obj.name} 계산 건너뜀.\n원인: ContentSizeFitter에서 위치 자동 계산");
                continue;
            }

            // Layout 시스템에 의해 제어되는 요소 제외. 단 GetComponentInParent이 해당 탐색을 수행하는 자신도 포함인데, 레이아웃 그룹 컴포넌트가 있는 부모는 앵커 위치 고정을 해줘야 잘 맞음
            LayoutGroup layoutGroup = rect.GetComponent<LayoutGroup>();
            LayoutGroup layoutGroup_Parent = rect.GetComponentInParent<LayoutGroup>(true);
            if (layoutGroup_Parent != null && layoutGroup != layoutGroup_Parent)
            {
                Debug.LogWarning($"{obj.name} 계산 건너뜀.\n원인: LayoutGroup이 있는 오브젝트의 자식이므로 위치 자동 계산");
                continue;
            }

            // Undo 기록 (Ctrl+Z로 되돌리기 가능하게)
            Undo.RecordObject(rect, "Set Anchors");

            /*
             핵심 개념 설명
             
             offsetMin = 왼쪽 아래 기준 앵커로부터 얼마나 떨어져 있는지 (픽셀)
             offsetMax = 오른쪽 위 기준 앵커로부터 얼마나 떨어져 있는지 (픽셀)

             우리는 이 offset을 부모 크기로 나눠서
             "비율"로 변환 후 anchor에 더해줄 것이다.
            */

            // 부모의 실제 너비/높이
            float parentWidth = parentRect.rect.width;
            float parentHeight = parentRect.rect.height;

            // 0 나누기 방지: 부모 크기가 0이면 계산이 불가능하므로 로그를 남기고 스킵
            // >> 자동으로 맞춰주면 문제 발생 우려가 있기에 작업자에게 알림
            if (Mathf.Approximately(parentWidth, 0) || Mathf.Approximately(parentHeight, 0))
            {
                Debug.LogWarning($"{obj.name} 계산 건너뜀.\n원인: 부모 {parentRect.name}의 Width 혹은 Height가 0. 해당 값을 0보다 큰 값으로 바꾼 후 다시 실행");
                continue;
            }

            // 현재 offset을 부모 크기 기준 비율로 변환
            Vector2 newAnchorMin = new Vector2(
                rect.anchorMin.x + rect.offsetMin.x / parentWidth,
                rect.anchorMin.y + rect.offsetMin.y / parentHeight
            );

            Vector2 newAnchorMax = new Vector2(
                rect.anchorMax.x + rect.offsetMax.x / parentWidth,
                rect.anchorMax.y + rect.offsetMax.y / parentHeight
            );

            // 새 앵커 적용
            rect.anchorMin = newAnchorMin;
            rect.anchorMax = newAnchorMax;

            /*
             이제 offset을 anchor에 흡수했으므로
             offset은 0으로 만들어도
             화면상 위치/크기는 그대로 유지된다.
            */
            rect.offsetMin = Vector2.zero;
            rect.offsetMax = Vector2.zero;
        }
    }
}
#endif

Inkoid 튜토리얼 제작

ybbro — Sun, 11 Jan 2026 10:15:42 +0900

기존 튜토리얼 씬은 패널에 텍스트만 띄워놓고 '읽어보세요' 로 했었습니다.

하지만 이 생각이 얼마나 안일했는지는 한 유튜버의 플레이로 알 수 있었습니다.

해당 유튜버는 튜토리얼까지는 진입하였으나 전혀 읽지 않고 뭘 해야하는지 모르겠다며 리뷰를 마무리하더군요.

이를 통해 플레이어들은 줄글을 써놓은 것에 진입 장벽을 느끼기 쉽다는 것도 알 수 있었습니다.
게임을 즐기려는데 이만큼 배워야 한다는 압박도 첫 인상을 나쁘게 주기 쉽습니다.

또한 지스타 현장에서 빠른 플레이를 돕기 위해 직접 설명해줘야 했지요.

다른 부스들은 룰에 대해 크게 설명할 필요 없이 게임 내 튜토리얼만으로 충분해 보여 이에 비해 준비가 부족했었다 생각합니다.

따라서, 체험형으로 하나씩 따라하며 룰을 익힐 수 있도록 튜토리얼을 개편했습니다

모바일 빌드 시, JSON 파일을 읽어오지 못하는 문제

ybbro — Sun, 11 Jan 2026 09:28:07 +0900

에디터, PC 빌드에서는 잘 작동하던 드롭다운이 먹통이 되는 문제가 생겼습니다.

<< 문제 인식 및 분석 >>

1. 화면 중앙의 드롭다운

스크립트를 통해 언어 옵션에 따라 항목 표시를 채워넣는 초기화를 진행하고 있었으나

터치했을 때 잠시 Pressed 색상이 뜨는 것으로 보아 이벤트 시스템 쪽 문제는 아니라 판단했습니다.

2. 번역이 되지 않음

로컬라이징 매니저의 로직에 따라

첫 실행 시 시스템 언어에 따라 초기 설정이 되어 나와야 하나,

중앙의 Select Region이 한글로 번역되어 나오지 않았습니다.

안드로이드 : 언어 번역이 되지 않고 개발 중이던 그대로 출력

PC : 한글 옵션으로 제대로 실행

번역문을 집어넣어야 할 TMP_Text, TMP_DropDown 이 둘이 번역이 되지 않은 상태로 먹통이 된 상황이네요.

확인해보니,

번역문을 제대로 불러오지 못해

해당 데이터를 담을 딕셔너리가 비어있고

이로 인해 데이터 수가 0개로 나와 드롭다운 항목 초기화 실패로 이어졌습니다.

<< 조치 >>

    // 설정에 맞는 언어 파일을 읽어들여 localizedText 딕셔너리에 정리
    // >> 언제든 효율적으로 찾을 수 있도록
    public IEnumerator LoadLanguage()
    {
        //문자열 더하기 대신 쓰는 이유
        //플랫폼에 따라 경로 사이에 / or \ 가 다르게 붙기에 해당 메서드로 안전하게 파일 경로를 만들 수 있음
        string path = Path.Combine(Application.streamingAssetsPath, fileName);

        // File.ReadAllText(path)로는 안드로이드에서는 APK 내부 에셋에 접근 불가
        // 해당 Json 파일이 StreamingAssets 폴더 내에 있기에 무조건 UnityWebRequest로 읽어야 함

        // using = 자동 리소스 정리. 내부적으로 IDisposable.Dispose() 호출
        // UnityWebRequest는 네이티브 리소스, 네트워크 핸들, 메모리 버퍼를 들고 있기에 명시적 해제가 중요 >> 해주지 않으면 메모리 누수 발생
        using (var request = UnityEngine.Networking.UnityWebRequest.Get(path))
        {
            // 요청이 완료될 때까지 대기
            yield return request.SendWebRequest();

            // 파일 경로로부터 읽지 못했다면, 에러 메시지와 함께 불러오기 종료
            if (request.result != UnityEngine.Networking.UnityWebRequest.Result.Success)
            {
                Debug.LogError($"Localization load failed: {request.error}\nPath: {path}");
                yield break;
            }

            string json = request.downloadHandler.text;
            LocalizationFile file = JsonUtility.FromJson<LocalizationFile>(json);

            localizedText = new Dictionary<string, LocalizedValue>();
            foreach (var item in file.items)
            {
                localizedText[item.key] = item.value;
            }
        }
        // 여기서 자동으로 request.Dispose() 호출


        // 기존 : File.ReadAllText(path)로 읽어옴
        // string json = File.ReadAllText(path);
        //LocalizationFile file = JsonUtility.FromJson<LocalizationFile>(json);
        //localizedText = new Dictionary<string, LocalizedValue>();
        //foreach (var item in file.items)
        //{
        //    localizedText[item.key] = item.value;
        //}
    }

APK 파일로 빌드하면서 압축 과정을 거치는데,

그로 인해 직접 해당 경로에 접근할 수 없었던 게 문제의 직접적인 원인이었습니다.

따라서, 경로에 접근하는 방법을 바꾸어야 했습니다.

기존 : File.ReadAllText();

수정 : UnityWebRequest

<< 결과 >>

모바일 빌드로 제대로 번역본이 출력됨을 확인

<< 안드로이드 테스트 빠르게 하기 >>

1. Unity Remote

테스트 속도를 빠르게 하기 위해 알아보았으나,

에디터 2022 버전 이후 미지원 + 최신 모바일 기기 미지원 이슈로 인해 해당 방법은 사용하지 못했습니다.

2. 앱 플레이어

기존에는

PC에서 빌드 → 안드로이드로 APK 파일 이동 → 설치 → 테스트

옮기는 과정을 거쳐야 했지만,

PC에서 가상 모바일 환경으로 APK 파일 설치 및 구동이 가능한 앱 플레이어를 통해

PC에서 빌드 → 앱 플레이어로 설치 → 테스트

절차를 줄여 보다 빠르게 테스트하는 방법도 배웠습니다.

물론 정상 구동 후 모바일에서 테스트하는 것도 잊지 맙시다.

Inkoid 최적화 내용 정리

ybbro — Sun, 30 Nov 2025 15:55:25 +0900

주로 무기/탄환/색칠 담당자였으므로 제가 한 부분부터 최적화를 시작했습니다.

1. 유도탄

1발에서 4발씩 발사하게 하는 매커니즘 변경으로 인한 최적화 필요

(1) 기존

1) 동기화를 위한 포톤뷰 컴포넌트로 인한 네트워크 부하 증가
2) 생성/파괴를 통한 GC 발생

(2) 변경

1) 탄환을 발사할 때만 그 정보를 RPC로 전달 >> 더 가볍게 하려면 RaiseEvent로 변경해보기
각각 로컬 클라이언트에서 유도탄을 생성하고 움직임을 제어하도록 변경 >> 네트워크 부하 완화

2) 오브젝트 풀링
탄환 생성 통신을 받으면 정보에 맞게

각각 로컬클라이언트에서 탄환을 생성하고

사용이 끝난 탄은 비활성화 상태로 로컬 오브젝트 풀에 넣고

다음 탄환 생성 호출 시 풀에 남은 오브젝트가 있다면 이를 다시 쓰게끔 하는 방식을 통해

생성/파괴에서 발생하는 GC 절감

2. 드릴 무기 통신 최적화
드릴 무기 스크립트가 FixedUpdate() 주기로 RPC를 계속하고 있었음
>> 필요할 때만 1번씩 통신하게 하여 통신 최적화

3. GetComponent<>() 남용 완화

총알 발사 시, 동일한 컴포넌트를 3번이나 찾는 곳이 있었음

각각 다른 스크립트에서 다른 작업자들이 작업한 내용

GetComponent<>()도 성능을 꽤 먹는 메서드 중 하나라 런타임 중 남발하면 안됨에도 총알 발사 같이 슈팅 게임에서 매우 자주 일어나는 매커니즘마다 여러 번 쓰이고 있었음

한번은 컴포넌트를 가져오는 과정이 필요했기에 한번만 찾고 여기서 필요한 매커니즘들을 수행하게끔 통합

4. 이펙트 (파티클 이펙트)

(1) 탄환 발사/타격 이펙트의 Light, Glow, Glow Impact 제거

해당 오브젝트들을 에셋 스토어에서 구매 시 들어있어서 관성적으로 썼었는데 모바일 포팅까지 목표로 두고 있어 사소한 것도 넘길 수가 없었음

그림자, 빛 번짐 효과는 Inkoid 게임 그래픽에서 크게 중요한 것이 아니었기에 해당 컴포넌트들 비활성화 후 관찰 >> 기존과 큰 차이 없음 >> 해당 오브젝트들 삭제 >> 성능 부하 크게 완화

(2) 파티클 수 줄이기

물방울 튀는 이펙트들 중 수량이 많이 튀는 것이 있어 이룰 줄임

RPG의 경우 넓은 범위를 커버하는 느낌이 들어야 하기에 파티클 크기를 키우고 수를 줄여 최적화

(3) 파티클 라이프타임 줄이기

현재 매우 긴 라이프 타임. 눈에 보이는 것보다 더 길게 라이프가 유지됨 (2.5초 -> 1초)

게임 최적화 공부 정리

ybbro — Sun, 30 Nov 2025 15:06:14 +0900

유니티에서는 프로파일러(Ctrl+7)를 통해 런타임 중 어느 메서드에서 시간을 많이 소요하는지, 드로우콜이 많이 발생하는지 체크할 수 있음

어디서 어떤 항목에 병목이 발생하는지에 따라 해결 방법도 천차만별이므로 많이 경험할 수밖에 없음..

CPU Usage에서 주로 많은 것을 확인할 수 있음
내 PC의 경우 GPU Usage를 확인할 수 없었기에 CPU Usage에서 체크
Gfx.WaitForPresent 함수가 CPU 사용 프로파일러에서 가장 오래 걸린다면, 이는 CPU가 GPU를 기다리고 있다는 뜻. 즉, 이 시점에서 게임이 GPU 바운드가 된 상태

<< 최적화를 위해 주의할 사항 >>
1. 움직이는 오브젝트에는 리지드바디 포함할 것
리지드바디가 포함되지 않은 오브젝트는 유니티에서 정적인 가능성이 높은 객체로 간주
>> 리지드바디를 붙일 경우 언제든 움직일 수 있다고 인지한 상태이므로 움직임과 연산에 필요한 것들을 미리 할당해둔 상태여서 움직일 때 그렇지 않은 오브젝트에 비해 연산량이 적음

2. 개방된 환경에서는 오클루전이 큰 효과를 얻지 못함. 다만, 건물, 지형 등 변곡이 있다면 여전히 효과 유효

3. LOD : 랜더링 관련인데 멀리 떨어진 오브젝트 요소들에 대해 랜더링 해상도를 뭉갠다던지 랜더링하지 않는다(Cull 단계)던지 간략화하여 그래픽 성능 최적화. LOD0 는 적당히 낮추는 것이 중요 (유니티 LODGroup)

4. 그림자 : 빛의 영향을 받는 모든 객체가 버퍼에 랜더링. 빛에 맞은 객체가 여러번 랜더링 >> 탄을 발사할 때 Light가 포함되어 있으니 이에 따라 많은 드로우콜이 발생 >> light 효과가 미미하면 빼는 것이 상책
그 외 불필요한 light 조명들이 있다면 최대한 없애도록
+ 실시간 계산 대신 라이트맵을 구워두고 쓰거나
+ Quality 설정에서 pixel light count를 제한할 수 있음
>> 확인해보니 각 씬에는 Light 컴포넌트가 단 하나. 그러나 이펙트마다 존재 >> 이펙트에서 Light, Glow 관련 지우고 봐도 크게 퀄리티 차이를 느끼지 못해 비활성화부터 시작하는 중

5. 드로우콜: 최대한 줄이도록 노력해야 함 >> 단순한 매시로 사용(캡슐, 구, 육면체 등으로 비슷하게 대체), 여러 매시 결합하여 한번에 드로우

1) 정적 배칭(로드할 때)
Static 체크 시 메모리 증가 가능(배치된 메쉬 복제)
Runtime에서 위치 변경하면 Static이 깨져서 재배칭 비용 발생

2) 동적 배칭(런타임 중에 생성하는 것들에 대해 결합)
그러나 제약이 많아 실전에서 큰 효과 보기가 힘듦

대부분 GPU Instancing + Texture Atlas 조합을 사용

적은 종류의 머티리얼, Atlas 텍스쳐들을 사용(가능한 한 돌려쓰기) >> 동일한 소재의 측정값만 배칭하고 함께 랜더링 가능
텍스쳐를 하나의 텍스쳐로 결합 >> 이를 머티리얼에서 사용하는 큰 Atlas 텍스쳐 생성 (?) : 방법은 아직 모르겠으나 이렇게 설명

# 프로그래밍 기법으로 드로우콜을 줄이기 위해 어떻게 해야하나?
1) 오브젝트 풀링 >> 이미 적극 활용 중 >> 유도탄 생성 / 파괴가 성능 소모가 클 수 있기에 이를 풀링으로 바꾸면 좀 더 향상 가능성 있음
2) Update() 남용 금지 >> Update(), FixedUpdate() 등 반복하는 이벤트 함수들 중 빈 함수들 or 줄일 수 있는 것들은 다 확인하고 삭제해주기
3) GC.Alloc 0 만들기 >> 프로파일러 - CPU - GC.Alloc 꼭 확인
줄이는 방법
(1) string.Format 지양 -> StringBuilder 사용
(2) .ToString() 남발 금지 (로컬라이징에 많이 써서 반성..) >> 줄일 수 있는 방안 모색하기

(3) foreach에서 종종 GC 발생(var 타입) >> for 권장
(4) LINQ 대부분 할당 발생
(5) new 생성 반복 금지 >> 구조체 or 풀링 or 미리 생성해두고 이용

지스타 2025 출품 이후 Inkoid 무기 개편

ybbro — Tue, 25 Nov 2025 02:46:13 +0900

팀스파르타 Unity 10기 수료 후 영광스럽게도

지스타 2025 출품작으로 선정되는 기회를 얻어 다녀왔습니다.

지스타 부스 운영을 통해 처음 하는 플레이어들에게 많은 피드백을 받았으며 출시 전까지 이를 최대한 반영하여 개선할 예정입니다.

우선적으로 제가 맡아 진행한 부분은

우리 게임은 판당 2분으로 짤막하게 즐길 수 있고

오래 붙잡고 할 그런 게임은 아니기에

처음 써도 각 무기의 재미를 느끼게 하는 방향으로 개편하는 것이었습니다.

이미 성능이 뛰어나고 사용하기 편한 무기 2종을 제외한 나머지 전부 수치/매커니즘을 바꾸었습니다.

1. 차저

물감 소모량 감소, 차지 시간 대폭 감소, 색칠 성능 소폭 상승

플레이의 답답함 크게 완화, 빗나갔을 때의 부담 감소

잉크가 최대치일 때, 차지샷을 3번 쏘고도 1번 평타를 쓸 수 있어 물감 충전할 곳이 없어 플레이가 제한되는 경우를 최소화

2. RPG

한번에 보유한 모든 물감을 소모하되 물감 소모량에 따라 공격/색칠 범위가 커지는 폭탄을 발사

한방에 점령 포인트 뺏기 + 주변의 적을 처치 가능하여 큰 한방을 제대로 느끼게끔 변경

물감을 많이 충전하지 못했음에도 적이 접근할 경우 해당 물감만으로 적에 대응할 수도 있게 하여 플레이의 답답함을 완화

3. 체이서 (유도탄)

기존에 1발씩 발사 >> 4발씩 발사

1발 당 대미지는 줄임

총 대미지에는 큰 차이가 없으나, 색칠 성능 상승(추적 미사일이므로 색칠에는 크게 기여하지 않을 것이라 예상), 미사일 수가 많아졌기에 조금이라도 딜하기 쉬워지고 난전 상황에서 더욱 좋아졌다고 판단

1발씩 발사할 때에 비해 확실한 재미를 줌

이후 무기 모델링 교체 예정

4. 드릴

기존의 조작이 너무 번거롭고 어려워 거의 대다수의 손님들이 기피

기존: 마우스 왼쪽 꾹 누르면 드릴 사용. 이 때 방향키로 움직이거나 에임 방향 대시로 따라가서 공격/색칠

변경: 마우스 왼쪽을 한번 누르면 에임 방향으로 아주 빠르게 돌진. 돌진이 끝날 때, 마우스 왼쪽을 계속 누르고 있는 상태면 저속으로 드릴 돌진 지속

마우스 왼쪽 버튼 하나로만 공격+에임 방향 이동 조작, 마우스 이동으로 직관적인 방향 전환이 가능하게끔 하여 개선

이후에는 튜토리얼을 체험형으로 개편하면서 무기 튜토리얼도 추가할 예정입니다