학교서 배울땐 메모리 어떻게 하고, 값 어떻게 저장하고 이런거 배우는데
실제 프로젝트 시작해보면
일단 기초되는 프레임워크(게임이면 게임엔진) 정하고 그 엔진 생리에서 엔진 문법을 사용함
그래서 기본적으로 엔진 차원에서 대부분 구현되어있는거 실제로 만듬. 물론 문법이야 어느정도 언어와 일맥상통하지만
가령 유니티 엔진은 모노비헤이비어 라이프 사이클 위에서 프로그래밍하고, Awake(), Update() 유니티 라이프 사이클 생각하면서 코딩하듯이
실제로 학교서 배우는 프로그래밍은 클래스-구조체 이런 구조로 하나하나 생각하는데, 실제로는 프레임워크가 권장하는 사이클과 컨벤션에 따라서 조립하게됨
그리고 여기서 유니티의 경우 에셋, 언리얼의 경우 플러그인 현업에서 주로 쓰는거 가져와서 코딩함
오히려 자기가 직접 짜는 경우 실제 버그 테스트 하는 경우가 많아서 더 오래걸림
실제로 유니티 쓰면 A* 알고리즘 자기가 직접 쓰는것보다 일반적으로 A* PRO 더 많이 쓰고, 비헤이비어 도 비헤이비어 디자이너 주로씀(최근엔 Unity6에 내장된 비헤이비어 트리로 바꾸는 추세지만)
나는 직접 다 짰긴한데, 생각해보면 실제 배우는 프로그래밍은 조금 저수준 레이어라면
웹도 그렇고 게임 엔진도 그렇고 실제로는 저수준 레이어에서 래핑된 상대적 고수준 레이어에서 코딩하는 경우가 대부분이고, 이게 더 생산성이 더 좋음
가령 UniTask, Rx,R3 이런 유니티에서 유명한 비동기 프로그래밍도 일반적으론 직접 구현 안하고 빌려와서 쓰듯이
그런의미에서 실제 현업 프로그래밍과 학교 프로그래밍의 괴리가 좀 있음.
물론 저 일반적 프레임워크를 벗어나는 범위를 코딩하기위해서는 고통이 필요한데, 사실 대부분의 경우 소비자는 그런 것을 잘몰라주긴함.
그런의미에서 적절한 균형이 필요한거고
아 코테도 마찬가지인게 알고리즘강의 들을때 코테에서도 bisect같은거 내가 직접 구현해야하는걸줄 알았는데 그딴거없고 걍 라이브러리 갖다쓰면됨 물론 이해는 해야 쓸수있지만
맞긴함. 기본적으로 딕셔너리를 짜진 않지. 뭐 딕셔너리 쓰면 박싱 문제가 있을 수 있다정도만 기억하고 그냥 쓰지만
실제로 코테 환경 자체가 기본적으로 가상환경 세팅이라 어지간하면 실제랑 많이 다르긴함. 구현도 그렇고
맞음 괴리가 심함 근데 에이스타 같은 건 깡으로 구현해봐도 괜찮을 거 같긴 함 ㅇㅅㅇㅋ
ㄹㅇ..
없뎃이라고?
a* 개오랜만에 들어보노.. 길찾기 알고리즘 아니냐 - dc App
맞음
학교는 기초위한곳이니 어쩔수없지
비전공 국비의 한계
ㅋㅋ
알고리즘 자료구조 c언어로 하나하나 다 구현한게 뻘짓이었다고? 하...