김환의 프로그래밍 블로그

머드게임형식의 TextRPG 팀프로젝트 단위로 제출하기. 어제의 문제 기능적으로 발생한 문제는 없었음. 오늘의 작업 팀원들이 맡은 각 기능의 작업이 막바지에 이르렀기에 각 기능 간 연결을 본격적으로 시작했다.  - 전투 중 "아이템 사용" 구현  : 우선적으로 해결해야 했던 문제는, 인벤토리 담당의 마지막 작업을 끝마쳐주기 위해 "전투 중 아이템 사용" 을 구현하는 것이었다. 해당 과정에서 팀원의 이질적인 코딩스타일이나 타 기능과의 연동을 미처 생각하지 못한 듯한 디자인(소모품 사용 함수가 전투 중에 그대로 넣기에는 그 상황을 상정되지 않은 듯한 내용이 들어감)이었기에 개인적인 변형을 가했다. 코드를 새로 짜거나 수정할 때에는 SOLID 다형성 을 어느 정도 지키거나 주석을 통해 타인에 대한 가독성을 높이는  것이 좋다고 느껴졌다.  - 보스 몬스터의 "특수 패턴 추가" 및 UI표시  : 팀원들의 기능을 연결했다면 내 작업을 마무리할 차례다. 최종보스의 '특수 패턴'은 이미 다른 팀원에 의해 추가된 상태였으나 전투UI에서 이를 묘사하는건 내 관할이었기에 '특수 패턴'을 사용했지만 UI상에서는 보이지 않는 버그가 있었다. 나는 이것을 몬스터가 공격할 차례에서 일반적인 메세지 대신 "특수 메세지"를 출력하게끔 고쳤다.  몬스터의 '일반 공격' 몬스터의 '특수 메세지' 출력 (특수공격 전조) 몬스터의 '특수 메세지' 출력 (특수공격 발동) 작업 결과 이렇게 내가 담당했던 '전투 시스템' 역이 마무리되면서 게임이 완성되었다. 다음 날에 결과물 코드를 main브랜치에 삽입하고 자료를 만들어서 발표하면 끝이다.

머드게임형식의 TextRPG 팀프로젝트 단위로 제출하기. 어제의 문제 main브랜치가 타 브랜치간의 병합을 통한 갱신을 꾸준히 하지 않은 탓 에 다량의 conflict가 발생하는 사고가 있었음.  → Dev브랜치에서 주기적 병합 하고 마지막 결과물을 main에 업로드 예정 오늘의 작업 주로 UI디자인 관련 작업을 실행. 기존 UI담당이 했던 디자인을 토대로 시각적으로 몰입이 되게 끔 설계, UI 통일 중. 현재 개발중인 화면 (캐릭터 생성 ~ 전투) UI를 개선하면서 발견되는 기능적 공백 부분 이나, 입력 시 전각문자 등 2바이트이상의 남은 버퍼가 다른 입력란을 침투하는 문제 등을 일부 해결. 전투 시 '크리티컬 발생' 이나 '방어 성공', '회피 성공' 등 일반적으로 발생하지 않는 이벤트 메세지를 출력 하게 끔 개선. 팀원들의 완성도가 높아지면서 팀원들의 코드 간 연결 을 시도. 본인은 전투 시스템을 담당 했으므로 전투가 발생하는 던전 시스템과 연결되도록 코드를 수정 하였다. 그 과정에서 발생하는 입출력 문제 등을 발견하고 일부 해결함. 나머지 문제는 내일 수정 필요. 발생했던 문제 플레이어의 직업별 기능을 담당했던 팀원의 연락이 두절 . 이틀 동안 모습을 비추지 않아 조장이 긴급으로 겸임 함. 팀원의 연락두절은 학창생활을 통틀어서도 생애 처음인 것 같음. 불가피한 불참이라면 메세지 하나 정돈 남겨야 한다고 생각함. 해결해야 할 문제  - 몬스터의 크리티컬, 회피 기능 추가 및 UI표시  - 보스 몬스터의 특수 패턴 추가 및 UI표시  - 전투 중 아이템 사용 시 소모품 인벤토리를 가져오기  - 그 외 UI입출력 문제 발생 시 해결하기

머드게임형식의 TextRPG 팀프로젝트 단위로 제출하기. 어제의 문제 팀원간 IDE차이로 인한 저장되는 소스코드의 인코딩방식이 달라서 호환성 오류를 일으켰었음.  → 현재는 UTF-8 BOM 으로 통일. 오늘의 작업 팀원의 연관 시스템끼리 호환되도록 통합하는 작업을 실행. 이 과정에서 인벤토리 담당, 던전진행 담당, 전투시스템 담당(본인) 의 Player클래스를 통합함. 팀원의 함수 수정 요청을 수락하기도 함. 발생했던 문제 main브랜치의 타 브랜치간의 병합을 통한 갱신을 꾸준히 하지 않은 탓 에 타 브랜치간의 변경된 코드차이가 큰 상태에서 팀원의 push미스가 발생 . 코드가 엉키는 사고가 발생했었다. 현재는 조장이 오류를 중재한 덕에 해결된 상태. 팀원간의 꾸준한 정보교류 가 중요 하다고 느껴짐. 새로 안 사실 std::endl 과 '\n' 의 차이 본인은 평소에 '\n' 보다는 std::endl 을 애용했는데(이유: endl이 좀더 C++같이 느껴졌음), 실제로는 '\n'이 속도 측면에서는 빠르다고 하여 '\n'를 쓰는 것이 일반적이라는 이야기를 들었음. std::endl - '\n'의 역할을 하나 flush()를 추가로 실행해 안정성은 높으나 속도가 느림 . 긴 문장에 적합 . '\n' - flush()과정을 생략하기 때문에 endl보다 속도가 빠르지만 flush()를 통한 버퍼청소를 하지 않으므로 긴 문자열에는 문자 소실 발생 우려 로 짧은 문장에 사용 함.

머드게임형식의 TextRPG 팀프로젝트 단위로 제출하기. 구상까지의 단계 첫 제안 : 플레이어의 체력, 방어력, 공격력 등을 가진 채로 한컴타자연습의 산성비게임처럼 스테이지단위로 플레이하고 클리어 후 상점에서 정비 후 다음 스테이지로 넘어가던 형식.  →  기존 틀인 RPG형식을 해칠 우려가 있어 턴제게임으로 선회함. 상세한 전투방식은 이후 팀원 작업물을 합치면서 기틀을 잡을 예정. 역할분담 1. 플레이어 정보 (직업, 레벨) + 몬스터 정보 2. 전투 시스템 : 랜덤한 경로 - 전투, 랜덤 이벤트, 보상 로직 3. 상점 시스템 4. 장비 및 인벤토리 5. 전투 관련 (몬스터와 전투 및 보스전) ← 6. 종합 검수 + 로그 본인은 5번을 맡게되었다 . 적과의 조우 시 발생하는 전투이벤트를 담당한다. 현재 기본적인 공격/방어 페이즈 구조를 제작 중이며, 이 과정에서 UI를 구현하는 시도 중임. 좀더 상세한 전투방식은 해당 내용 구현 후에 추가 구현할 예정. 현재 직면한 문제 타 팀원간의 IDE가 맞지않아 인코딩에러가 발생하는 중. 일단 독자적인 main.cpp를 사용하고, 본인의 시스템 구축 이후 통합할 때 해결할 예정.

String  - string은 사실 vector<char> 의 사촌 이다.  string 은 문자(char)를 연속 메모리에 담는 것 .  - 인덱스 접근방법 O(1), size(), push_back() 모두 vector와 동일  - string은 vector<char>에서 찾기, 자르기, 바꾸기 기능이 추가된 형태이다. find - 검색 위치를 반환  -  s. find ( "찾을 문자열" ) 를 호출하면 시작 인덱스(위치)를 반환한다. s.find("World") → 6  - 찾지 못하면 string::npos 라는 특별한 값을 반환한다. (npos = "no position"의 줄임말)  : find를 쓰면 반드시 npos를 체크 하여 버그를 놓치지 않도록 하자. find의 두 번째 매개변수  - find의 두 번째 매개변수를 설정하면 "어디서부터 찾을지"를 지정 한다. s. find ( "Hello" , 7 ) // 인덱스 7부터 검색 시작 시간복잡도: 최악 O(n×m) (n: 원본 길이, m: 검색어 길이) 한글자 씩 비교해나가는 방식 - 아주 긴 문서에서 Ctrl+F가 살짝 느릴 수 있는 이유 substr - 원하는 부분만 떼어내기(부분 문자열 추출)  - s.substr(시작위치, 길이)  → 일부분을 복사한 새 문자열 반환  - 두 번째 매개변수 생략 시 시작위치부터 끝까지 잘라낸다 . ※ 중요: substr 은 원본을 수정하지 않고 새 문자열을 만든다. s.substr(0,5) → "Hello" s.substr(6) → "World"  - 위치를 찾고 (find) , 그 위치를 기준으로 잘라내기 (substr)   : 실전에서 가장 많이 쓰이는 패턴이다. find, substr 활용 예시 replace - 범위를 새 문자열 교체  - s.replace(시작위치, 길이, "새문자열...

Git 사용법 1편 링크(설치, clone, commit, push) Git 사용법 2편 링크(gitignore, gitattributes, commit) Git 사용법 3편 링크(petch, pull) 브랜치(Branch) 개발을 하다보면, 특정 버전에서 독립적으로 개발을 진행해야 할 때가 생긴다. 그럴때 현재 프로젝트에서 나만의 작업 공간을 따로 갖고자 할 때 Branch를 활용한다. Branch는 나무의 나뭇가지처럼 특정 Commit으로부터 뻗어져 나온 새로운 평행세계이다. 1) 로컬 브랜치 목록. 로컬 레포지토리에 생성된 브랜치들. 2) 리모트 브랜치 목록. 리모트 레포지토리에 생성된 브랜치들. 새 리모트 브랜치 만들기 1) main 옆 역삼각형 버튼 클릭 2) View all branches 클릭 New branch 클릭 1) 새 리모트 Branch 이름 작성 2) 소스 리모트 Branch 선택    - 해당 소스 리모트 Branch 기준으로 새 리모트 Branch가 생성됨 Release 리모트 브랜치가 추가된 모습. 그래픽쉘에서 새 리모트 브랜치가 보이지 않을 때 소스트리 기준 설명 1) 새 리모트 브랜치가 안보인다면 2) Fetch를 한다. 3) Pull을 한다. 일련의 과정을 수행하면 그래픽쉘에서도 새로 만든 리모트 브랜치가 보인다. main 로컬 브랜치는 세이브 포인트다. 내가 작업하다가 문제가 생기면 지우고 main 로컬 브랜치로 돌아가야한다 . 그러므로 main 로컬브랜치에서 작업하는 것은 위험할 수 있으며, 항상 문제없는 상태로 두어야 한다. 다른 Branch를 생성해 나만의 세이브 포인트를 만들어두자. ※ 로컬 레포지토리 폴더도 원본은 세이브 포인트로 남겨둔다. 새 로컬 브랜치 만들기 소스트리 기준 설명 1) 아직 로컬 브랜치가 main 로컬 브랜치 밖에 없는 상태. 2) Branch 버튼 클릭 1) 기준이 될 소스 로컬 브랜치. 해당 로컬 브랜치를 기준 으로 새 로컬 브랜치가 생성 된다. 2) 새 로컬 브랜치 이름 작...

Visual Studio에서 필요한 환경세팅 언리얼 C++은 Visual Studio 2022 버전으로 작업하는 것이 좋다. 1) VS 프로젝트 생성 화면에서 [추가 도구 및 기능 설치] 클릭 2) [C++을 사용한 게임 개발에 체크] 후 [수정] 3) 언리얼 C++ 프로젝트 생성 후 [라이브 코딩 활성화] 체크 해제  - Visual Studio와 충돌해서 에러를 일으키는 경우가 많다. 로그 출력(UE_LOG) 해보기 1) C++ 클래스 Actor 생성 후 VS에서 UE_LOG 함수 입력해보기 2) 생성한 Actor를 레벨에 배치한 후 실행하면 출력 로그에 메세지가 출력 된다. 이렇게 UE_LOG를 통해 언리얼 엔진의 개발자용 출력 로그에서 디버깅이나 특정 정보를 확인하는 용도로 사용할 수 있다. UE_LOG의 구조 UE_LOG 는 세 가지 의 인수로 구성되어있다. 1) 카테고리 메세지의 종류(Tag)를 나타낸다. 특정 카테고리만 분류해서 보고 싶을 때 많이 활용된다. 자신만의 고유 카테고리 를 만들 수도 있고, 보통 LogTemp 를 많이 쓴다. 아래 사진처럼 엔진에서 카테고리별로 선택 가능 하다. 2) 심각성 중요도에 따라 심각성을 분류할 수 있으며, 각 로그는 색이 다르게 출력된다. 심각도 콘솔 출력 색상 Log 일반적인 메시지, 색상 없음 (기본 검정 텍스트, 흰색 배경) 또는 흰색 Display 파란색 (일반 정보를 강조하기 위해 표시) Warning 주황색 또는 노란색 (경고 메시지를 시각적으로 강조) Error 빨간색 (문제가 되는 상황을 강조) Fatal 빨간색 (치명적 오류이며 이후 프로그램 종료 ) 3) 실제 출력할 내용 로그에 출력할 실제 내용이다. < UE_LOG() 사용 예시 >

C++에서는 내용을 많이 아는 것도 중요하지만, 객체지향 적으로 코드를 구현할 수 있는 것도 상당히 중요하다. 객체지향적 프로그래밍이 중요한 이유: 1) 대부분 라이브러리 및 오픈소스는 객체지향적으로 설계되어 있다. 2) 좋은 설계로 구현된 코드는 개발 시간을 단축할 수 있다. 3) 좋은 설계로 구현된 코드는 기능 변경에 유연하게 대응할 수 있다. 응집도 응집도는 클래스 또는 모듈 내부 의 구성요소들이 얼마나 밀접 하게 관련되어 있는지를 나타낸다. 응집도가 낮은경우 서로 관련 없는 기능 들이 하나의 클래스에 포함 된 경우를 두고 '응집도가 낮다'고 한다. 응집도가 낮으면  - 하나의 목적이 아닌 따로 노는 느낌 을 주게 된다.  - 하나의 class에 모든 기능이 집중되어 있어 유지 보수가 어렵다 . ex) 피자배달 클래스 1) 피자배달 기능 2) 웹사이트 디자인 기능 3) 회사 마케팅 기능 4) 창고 관리 기능 응집도가 높은 경우 서로 관련 있는 모듈들만 하나의 클래스에 포함되어 있으면 '응집도가 높다'고 한다. 일반적으로 응집도가 높을수록 좋은 설계 로 평가된다. 응집도가 높으면  - 기능 변경이 필요할때 해당기능이 담긴 class만 수정 하면 된다.  - 관련된 class끼리 정보를 공유하여 코드의 구조가 명확 해진다. ex) 피자배달 클래스 1) 피자 배달 경로 확인 2) 주문한 고객 대응 3) 배달 예상 시간 측정 결합도 모듈 또는 클래스 간의 의존성 을 나타낸다. 일반적으로 결합도는 낮을수록 좋은 코드 로 본다. ex) 자동차의 엔진클래스      - 자동차 Class가 디젤 엔진 Class를 직접 포함하고 있다. 이 구조는 아래와 같은 문제점이 있다.      1) 새로운 엔진을 추가하면 자동차 Class도 수정해야한다 .      2) 변경이 잦으면 수정 범위가 커지고 유지 보수가 어려워진다 . 따라서 아래의 자동차 Cl...

Git 사용법 1편 링크 Git 사용법 2편 링크 Git으로 팀원과 협업하기 Git을 처음 사용할 때 제일 어려운 상황 중 하나가 팀원들과 협업할 때 어떻게 작업물을 합치고 그 과정에서 발생하는 문제를 어떻게 대처하는가에 대한 것이다. 곧 있을 언리얼 팀프로젝트 개발을 하기 위해서 팀 단위 Git 사용법을 익힐 필요가 있다. 아래 예시들을 보고 이 경우 어떻게 Git의 기능을 활용하는 지에 대해 알아보자. 다른 팀원이 프로젝트를 업로드했다고 가정하고, 로컬 레포지토리 폴더를 두 개로 나누어보자. 하나는 내가 작업 중인 로컬 레포지토리 폴더, 다른 하나는 팀원이 작업 중인 로컬 레포지토리 폴더라 가정해보자. 각각의 폴더에서 Generate Visual Studio project files 및 빌드를 진행. 경로 및 폴더명이 변경됨에 따라 프로젝트 초기화 과정이 필요함. 새로 생성한 로컬 레포지토리 폴더들을 깃허브에도 추가한다. 나와 내 동료의 로컬 레포지토리라고 가정한다. 일어날 수 있는 상황 1. 팀원이 "관련 내용 커밋 푸시 했습니다!" 라고 알렸을 때 내려 받아야 하는 상황.  → petch/pull만 하면 끝. 2. 내가 작업한 내용을 리모트 레포지토리에 올리려는데, 아주 운좋게도 작업 시작 전부터 업로드 시점까지 아무도 리모트 레포지토리를 건드리지 않은 상황.  → petch/pull 하고, merge만 하고 commit, push 하면 끝. 3. 내가 작업한 내용을 리모트 레포지토리에 올리려는데, 이미 팀원이 리모트 레포지토리에 작업 내용을 올린 상황. 하지만 또 운 좋게 팀원이 올린 작업 내용과 내 작업 내용이 다른 파일.  → petch/pull 하고, merge만 하고 commit, push 하면 끝. 4. 내가 작업한 내용을 리모트 레포지토리에 올리려는데, 이미 팀원이 리모트 레포지토리에 작업 내용을 올린 상황. 게다가 팀원과 내가 같은 파일을 작업해버려서 충돌발생.  → petch/pull 하고, merge했...