오늘은 콘솔로 만드는 RPG 게임 개인과제를 마무리하는 날이다.
오늘 한 것
버그 목록 작성 후 수정, 함수들을 클래스로 세분화
버그 목록
1. 스테이지 실패 시 플레이어 체력의 반을 깎아야 하는데 플레이어의 고정체력이 아닌 실시간으로 변하는 체력 기준에서 반을 깎아버림 -> 고정된 HP50을 깎도록 수정 (기존 최대체력 100)
2. 아이템을 장착할 때 공격템을 처음 장착할 때, 방어템을 처음 장착할 때, 공격템을 장착 후, 다른 공격템을 장착할 때, 방어템을 장착 후 다른 방어템을 장착할 때, 공격템을 장착 후, 방어템을 뺄 때, 방어템을 장착 후 공격템을 뺄 때 이러한 경우를 잘 고려해서 코드를 짰어야 했는데 쓸데없는 코드가 있고 if문 판정식도 이상해서 공격템과 방어템이 하나 씩만 장착돼야 하는데 3개 이상껴지는 버그가 발생 -> if문 수정 및 쓸데없는 코드 삭제
3. 아이템을 장착하고 0번을 누르면 시작 클래스인 Start 클래스에 있느 함수에 가게되는데 장착 판정을 하는 변수가 아이템 장착을 관리하는 Inventory클래스에 있어서 예를 들어 공격템을 장착 후 나갔다가 다시 인벤토리에서 공격템이 장착되는 버그 발견 - > 이유는 Start클래스에서 Inventory클래스자체를 재호출하기 때문에 아이템 장착 변수가 재초기화 되버린 상황. 그렇기에 변수를 Start 클래스에 넣어서 싱글톤으로 관리
4. 상점 아이템 목록과 현재 플레이어의 아이템이 서로 같은 객체를 바라보고 있다. 여기서 소지한 아이템을 강화한다면 상점 아이템 목록에도 강화 수치가 반영되는 문제 발견 -> 상속받는 Item인터페이스에 원본 공격(방어)력 프로퍼티를 추가하여 실시간으로 오르는 공격(방어)력과 본래의 공격(방어)력을 추가했다. 그리고 그것을 상점 함수에 원본 값을 추가하니 해결
5. 장비를 장착 한 후 강화를 진행하면 수치가 이상해지는 문제 발견, 코드를 너무 많이 짜놔서 수치를 담당하는 변수를 막 건들 수 없는 상황 ->사실 장비 강화의 느낌은 재련소에 장비를 올려 놓는 느낌이어서 장비를 해제해야만 강화할 수 있게 변경. 내가 생각하는 해결법은 수치를 담당하는 변수를 인터페이스 프로퍼티로 뺏어야 됐는데 전역변수로 써서 문제가 발생한 것 같다.
코드 정리
코드 정리를 하는 부분이 정말 많은 시간이 걸렸다. 그냥 한 클래스에 모두 다 때려넣어서 만들었기 때문에 한 클래스에 약 2천줄이 넘는 상황이 발생했다. 그렇기에 각각의 함수들을 기능별로 나누어 클래스 파일로 집어 넣었다.
여기서 발생한 아주 큰 문제는 기본 시작 클래스은 Start 클래스와 그것을 담당하는 기능 클래스들이 서로 인자를 필요로 했다. 그래서 Start에서도 객체 생성하고 기능함수에서도 객체 생성을 했는데 스택오버플로우가 발생했다. 우선은 한 곳은 클래스 부분에 다른 한곳은 함수에 했다면? 가능했을 지도 모른다. 근데 이런 방법은 정말 안좋은 방법이고 오류가 발생하기 쉬웠다. 그렇게 한참을 고민하던 도중 팀원의 조언으로 해결했다. 그것은 싱글톤이라는 방법인데 원래의 코드는 각각 클래스가 계속 객체를 생성해서 받아오니 굉장히 연결이 불안하고 관리도 힘들었다. 하지만 Start클래스에 싱글톤을 사용하니 모든 기능의 클래스에서 Start에서 바라보고 있는 객체의 내용들을 똑같이 사용할 수 있었다.
예를 들어 Start 클래스에 싱글톤 패턴 적용 -> 다른 클래스에서 Start 이름 = Start.싱글톤 선언 변수명 -> 다른 클래스는 이제 인자를 메인이나 다른클래스에서 따로 받아올 필요가 없어짐. 공유하는 Start객체를 사용하고 있기 때문에 -> Start클래스에서는 다른클래스를 Store라고 가정하면 Store 이름 = new Store()로 사용. 여기서 주의할 점은 클래스의 전역변수쪽이 아닌 함수안에 써야된다. 안그러면 스택오버플로우 발생. 여기서 중요한건 Store가 객체정보를 생성자로 필요했다면? Store에 또 정보를 넣어야하고 그러면 또 저기에도 넣어야하고 여기에도 넣어야하고 많은 문제가 발생하는데 그것을 방지해주는 것이 싱글톤 방법이다.
요약
같은 객체를 바라보면서 여러 함수들과 클래스를 관리해야 할 때는 싱글톤 패턴을 사용해보자.
스택오버플로우는 클래스끼리 생성자를 무한대로 호출할 때 발생한다.
내일 할 것
사실 싱글톤 패턴 이전에 인터페이스를 잘 활용하고 체계적으로 설계했다면 문제가 쉽게 해결됐을 것이다. 하지만 오히려 이번기회에 싱글톤 패턴을 확실히 배워서 장점도 있다.
그렇기에 싱글톤은 배웠으니 이젠 어떻게 인터페이스를 설계하고 사용해야하는지에 대하여 학습할 것이다.
'TIL > C#' 카테고리의 다른 글
C# 문자열의 다양한 변환 (0) | 2023.08.25 |
---|---|
C# LINQ (0) | 2023.08.24 |
개인 프로젝트 ConsoleRPG 3일 차 (0) | 2023.08.22 |
개인 프로젝트 ConsoleRPG 2일 차 (0) | 2023.08.21 |
개인 프로젝트 ConsoleRPG 1일 차 (0) | 2023.08.18 |