계속 봐도 이해 안되는 거, 잡고 있어봤자 시간낭비다
하지만 이렇게 이해가 안되던 개념들이, 코드를 작성하다가 깨닫게 되는 순간들이 분명히 옴
그런 순간들이 모이고 모여서 실력이 발전하는 거임
같은 예시로, 디자인 패턴 공부한답시고 디자인 패턴 책펴고 공부하는 것도 좋지 않다
볼거면 그냥 훑어봐라. 이런 게 있네 하고
개발을 계속 하다보면 분명 다시 만나게 된다
그리고 아 이게 이런 이름이 붙어있는 패턴이었어? 하면서
본인이 무의식 중에 하고 있던 일이 이름이 있는 디자인 패턴이었다는 것도 알게 된다
결론: 그냥 만들기 시작해라
이 댓글은 게시물 작성자가 삭제하였습니다.
아직 딕셔너리 익숙하지 않아서 걍 안씀..
그거안쓰고 어케함
딕셔너리 그거 어댑터 같은 느낌이라 내가 A 자료를 넘겨주면 B데이터로 바꿔주는거임
탐색속도가 매우 빠르고, 숫자 대신 다른걸 사용 가능한 대신, 순서 보장이 안되는 리스트라고 생각하고 ㄱㄱ
순서 보장됨.
그냥 리스트를 쓰면 되는 것 아닌지..? 최적화 신경써야하는 게임이면 모르겠는데 그런 것도 아니라
@Indie1(121.169) ?? 딕셔너리가 순서 보장이 된다고?
@dryrain 자료 개수 적으면 문제 없긴함 ㅋㅋ
오 해시였구나. 내가 틀렸써
SortedDictionary 를써야 순서보장이네 기본적으론 순서 보장안함
@dryrain 내 딕셔너리 사용 예시를 들면, 플레이어나 적 스탯에서 사용함. 스탯종류가 적으면 그냥 클래스 필드로 선언해도 상관없는데, 방어력, 공격력, 피해량 증가, 치명타 확률, 치명타 피해량 증가, 공격속도, 이동속도, 최대 체력, 체력재생, 마나, 마나재생 등등 10가지 20가지 넘어가면 스탯 관련 필드로만 몇십줄 넘어감. 그리고 임시로 적용되는 스탯들도 있잖아? 버프나 디버프 받았을 때, 스킬썼을때 등등. 이런 애들 전부 일일이 필드로 선언하면 진짜 답도 없이 스탯 필드 선언만 100줄 200줄이 넘어감.
@dryrain 이럴 때 딕셔너리가 유용함. 베이스가 되는 스탯들을 담은 baseStat 딕셔너리, 아이템으로 변경된 스탯들을 담은 itemStat 딕셔너리, 버프나 디버프가 적용되는 buffStat 딕셔너리 들을 선언해놓고, 각각의 key로는 스탯타입(스크립터블 오브젝트 or Enum 값)을 넘겨주고, value로는 float형의 실수치를 넣어줌. 그리고 최종 합산된 스탯이 필요하면, GetFinalStat(StatType.Strength)라는 식으로 스탯타입만 파라미터로 넘기면 계산된 스탯을 리턴해주는 메서드를 만들면 끝임. 이거 말고도 딕셔너리 활용도는 무궁무진함.
@응악 아 동적인 겜은 확실히 그런 요소들을 고려해야겠네
@dryrain 그리고 자기 코드에 Switch 문이 많다? 그러면 걔들은 모두 딕셔너리로 대체 가능함
인덱스 접근이라 리스트가 성능상 더 빠르긴함. 딕셔너리는 편해서 쓰는거
@Indie1(121.169) 리스트랑 딕셔너리를 그냥 놓고 봤을 때 성능상 뭐가 더 빠르다고 단언하기는 힘듦. 실제 유스케이스에서 삽입, 조회, 삭제 중에 뭐가 많이 일어나나를 두고 어떤 자료구조가 더 적합한지를 따져봐야 함.
@응악 *수정도 포함
게임개발에서 딕셔너리가 빠른 경우는 거의 없다고 보면됨. 그냥 편해서 쓰는거
저도 쓰긴 쓰는데 사실상 리스트로도 다 되는 것들이긴 함
아직 제너릭 익숙하지 않아서 걍 안씀..
코딩은 자격증 시험처럼 일단 해놓고 아 이래서 그렇구나 배워야하는거군...
뉴비라면 일단 ai한테 자문구해가면서 지금 방향성이 맞는지 존나게물어보면 실력빨리늘듯
내가 그래서 그래프 안 써