[TIL]2024-2-16 / 38일차 - 팀 과제 마무리

프로젝트 로고

1. 오늘의 알고리즘 코드카타 - 숫자 문자열과 영단어

 

 

 

 

답안 : 

//String.Replace 메서드를 알게 되었다...
//단순 노가다 가즈아
using System;

public class Solution {
    public int solution(string s) {
        int answer = 0;
        s = s.Replace("zero", "0");
        s = s.Replace("one", "1");
        s = s.Replace("two", "2");
        s = s.Replace("three", "3");
        s = s.Replace("four", "4");
        s = s.Replace("five", "5");
        s = s.Replace("six", "6");
        s = s.Replace("seven", "7");
        s = s.Replace("eight", "8");
        s = s.Replace("nine", "9");
        
        answer = int.Parse(s);
        return answer;
    }
}

 

---

 

2. 오늘의 공부

 

오늘은 발표를 위한 마무리 준비, 리드미 작성, 발표 리허설 등을 하며 오전을 보냈다.

 

리드미 작성 부분을 쓰며 정리한 구현된 공격 로직의 흐름은 나중에도 참고해보려고 남겨두겠다.

-> 공격 인풋 발생(어택 컨트롤러)

-> 매니저에 저장된 무기 사용 명령(어택 매니저)

-> 무기 인터페이스의 공격 명령 발생(IWeapon - Attack)

-> 현재 저장된 무기의 공격 명령 발생(AttackManager.currentWeapon.Attack)

-> 각 무기 내부의 탄환 생성 로직 작동(플레이어의 발사체 증가 수, 관통 증가 수 등이 각자 상이하게 적용)

-> 오브젝트 풀링을 담당하는 매니저에서 탄환 생성(PoolManager)

-> 생성된 탄환이 개별 로직대로 작동(ex= 일반적인 직선 이동, 생성된 위치에 시간차 공격, 적을 추적)

-> 지정된 타겟과 충돌을 감지하면 대상의 HealthSystem을 불러와 대미지 적용

    + 이벤트 트리거로 충돌 애니메이션 작동과 삭제 처리
      
    + 관통이 가능하다면 처음 충돌한 대상의 HealthSystem을 저장하고 이후 충돌한 대상의 것과 비교하여 투사체 이동중 중복 충돌 방지

 

오후에는 각 팀들의 발표와 피드백을 보았다. 다른 팀들도 놀라운 퀄리티로 만들어온 팀도, 자기들의 고충을 이겨내는 팀도 있었다.

 

우리 팀의 퀄리티도 어디 내놓아도 전혀 부족할 것이 없는 것 같아 뿌듯했다.

 

이후에는 팀 내에서 자체적으로 팀장의 이번 과제에서 이용한 동적 생성에 관한 멘토링 시간이 있었다.

이런 구조는 처음 보는지라 어려우면서도 익히기만 한다면 무지 유용한 기술이었다.

 

개인 과제를 할 때도 가능하다면 이번 과제의 동적 생성과 UI는 응용해 보고 싶다.

 

저녁에는 스탠더드 반 특강을 진행하고 하루가 끝났다.

특강의 주제는 설계 패턴. 그런데 신기하게도 이번 팀플을 진행하며 배운 내용들과 쳤다.

 

• 프로젝트의 커스텀 Enum 데이터 타입들을 모아놓을 클래스 파일을 생성해서 정의
  • ex ) namespace EnumTypes 안에 enum AttackTypes, enum CardRanks ...
•  같은 맥락으로 커스텀 Struct 데이터 타입들을 모아놓을 클래스 파일 생성
• static class를 이용한 유틸리티 타입을 모아놓을 클래스 파일로 인스턴스 이용
• 글로벌 변수들을 모아놓을 클래스들 정리
• 생성될 객체들을 관리할 관리자 클래스 정의
  • ex) 가장 꼭대기에 GameManager 클래스가 하위 관리자로 CharacterManager, UIManager, CameraController, MapManager, EffectManager를 갖는 형태로 설계. 이러면 게임매니저만 역참조 하면 다른 모든 것에 접근 가능해진다.
• 씬 전환에 걸쳐서도 게임 오브젝트들을 갖을 객체를 정의하여 데이터들을 관리
• 에디터 타임에 수정되며 게임 타임 중에는 변하지 않을 데이터들을 SO로 정의하여 관리
• 데이터 덩어리 객체를 정의하여 데이터 접근
  • ScriptableObject나 GameObject와 같은 객체를 참조하고자 하는 경우 모두 [SerializeField]로 사용하기 부담된다는 점도 있다. 그러므로 무지성으로 사용하고싶은 모든 데이터들을 담아둘 덩어리 객체를 정의하여, 자주 사용되던 테스팅으로 사용되던 필요하다면 박아넣고 사용할 수 있는 공간을 확보한다.
• 리소스를 종류별로 묶어둔 데이터 덩어리 정의
• BaseMonoBehaviour 객체를 통해 MonoBehaviour를 래핑한다.
  • 유니티에서는 gameObject에 스크립팅을 위해 MonoBehaviour 객체를 이용한다. 하지만 MonoBehaviour는 부족한 점이 많다. 그래서 몇가지 기능들을 확장해서 사용할 필요가 있다.
  • MonoBehaviour의 리플렉션 이벤트들은(Awake, Start, Update, OnDestroy ..) 굉장히 느리다. 그러므로 자체적인 이벤트 호출루틴을 구축할 필요가 있다.
• OnDestroy 시에는 반드시 모든 레퍼런스를 놓아주기
  • 유니티에는 가비지 컬렉터가 있으니 메모리는 알아서 관리해줄 것이다.. 라는 착각은 버리자.

---

 

갈수록 유용하지만 어려운 개념들이 늘어난다. 점점 따라가기 벅찬 느낌이 있지만, 이런 게 취미 수준의 코딩과 점차 전문적인 기술로 나아가는 길이라고 생각이 든다.