본문 바로가기
프로젝트

24/08/29 - [개인] 로그 라이크 게임(3): 최종 결과물 및 피드백

by Jini_Lamp 2024. 8. 29.

이전에 만들었던 로그 라이크 게임의 피드백이 나왔다

하여, 오늘은 프로젝트의 최종 결과물과 피드백, 그 이후로 개선된 사항들을 기록하고자 한다.

깃허브 링크: https://github.com/jini031104/Rogue-likes-game

 

 

 

게임 로직

  1. 게임은 총 10번 진행된다.
  2. 플레이어 초기 능력치
    • HP: 100
    • 공격력: 3 ~ 5
    • 연속 공격 성공률: 25%
    • 방어 성공률: 40%
    • 도망 성공률: 30%
  3. 몬스터 초기 능력치
    • HP: 10
    • 공격력: 10
  4. 플레이어는 공격, 연속 공격, 방어, 도망 中 1개를 선택할 수 있다.
    • 공격
      1. 플레이어는 몬스터를 공격한다.
      2. 몬스터는 대미지를 입는다.
      3. 몬스터의 체력이 0보다 크면, 몬스터도 플레이어를 공격하다.
      4. 플레이어는 대미지를 입는다.
    • 연속 공격
      1. 25% 확률로 연속 공격이 성공한다.
      2. 공격 실패시, 몬스터가 공격하여 플레이어는 대미지를 입는다.
      3. 공격 성공시, 몬스터는 공격하지 못한다.
    • 방어
      1. 40% 확률로 방어에 성공한다.
      2. 방어 실패시, 몬스터가 공격하여 플레이어는 대미지를 입는다.
      3. 방어 성공시, 플레이어는 반격하여 몬스터에게 공격력 * 0.6 만큼 대미지를 입힌다.
    • 도망
      1. 30% 확률로 플레이어는 도망이 가능하다.
      2. 도망 실패시, 몬스터가 공격하여 플레이어는 대미지를 입는다.
      3. 도망 성공시, 플레이어는 다음 스테이지로 넘어간다.
  5. 도망에 성공하거나 몬스터의 HP가 0이하가 되면, 다음 스테이지로 넘어간다.
  6. 스테이지가 바뀌면 플레이어는 다음 이벤트 중 1개가 랜덤으로 진행된다.
    • HP 20 ~ 50 회복
      단, 최대 HP 이상으로는 회복할 수 없다.
    • 공격력 5 ~ 20 상승
    • 연속 공격 성공 확률 3 ~ 7 상승
    • 방어 성공 확률 3 ~ 10 상승
    • 도망 성공 확률 3 ~ 10 상승
  7. 몬스터의 HP와 공격력은 스테이지에 비례하여 상승한다.
    • HP: 10 + ((스테이지 - 1) * 10)
    • 공격력: 10 + ((스테이지 - 1) * 5)

 

 

 

최종 결과물

https://youtu.be/cSUC6iGcKE4?si=w0-6ZfXKBageP4QD

 

 

 

파일 구조

파일 구조

functionTest.js

해당 파일에선 sleep()기능 구현이나 랜덤 기능이 저장되어 있다. 또한 몬스터의 상태나 display를 출력하는 등 정적인 부분이 이루어져 있다.

 

game.js

플레이어&몬스터 클래스를 비롯해 게임의 기능들이 저장된 파일이다.

 

server.js

게임을 동작시킨다. 처음 메인 화면은 이곳에서 출력된다.

 

 

 

피드백

  1. == 보다는 ===을 사용하는 게 더 좋다.
    ==의 경우 타입 형변환이 발생하기 때문에 원하지 않는 결과가 나올수도 있다고 한다.
    나름 신경써서 ===를 사용했다고 생각했는데, 중간중간 나도 모르게 ==를 사용한 곳이 있었다. 다음부터는 좀 더 주의해야겠다.

  2. 함수는 소문자로 시작하라.
    JS에서는 클래스만 대문자로 시작한다고 한다. 평소 쓰던 습관대로 썼더니 이런 문제가... 이 부분도 주의해야겠다.

  3. 변수도 소문자로 시작하라.
    몰랐는데 딱 한 부분 나도모르게 대문자로 시작한 곳이 있더라. 왜 그랬나 생각해보니, 원래 있던 변수명에서 뒷부분만 잘라서 사용한거라 소문자로 수정을 못했다. 물론 변명이다... 다음부터는 좀 더 조심하자.

  4. 중복 코드 줄이기.
    제일 뼈 아픈 부분이다. 로직을 보면 [플레이어 공격 → 몬스터 대미지] 부분이 꽤 많은데, 이 부분을 지적받았다. 안 그래도 코드를 작성하면서 느꼈던 터라 해당 부분을 함수로 빼는 방식으로 수정해야할 것 같다.

  5. 초기화 값 주의.
    스테이지가 시작될 때마다 도망 성공 여부를 초기화하도록 관리하고 있었다(왜냐하면 이전에 도망을 쳤을 시, 해당 부분이 다음 스테이지에서 유지되면 안되니까.)
    그런데 이렇게 하면 추후 초기화 값이 늘어날 수 있기에 플레이어 클래스에 값을 초기화하는 함수를 만들어 사용하는 것이 더 좋을 것 같다고 한다.

  6. 커밋 메시지.
    메시지에 좀 더 정확한 작업 내용을 적어주면 좋을 것 같다고 한다. 보통 제목에 요약해서 적었는데... 해당 습관을 고쳐야겠다.

 

+) 24/08/30 추가

같은 날 받았던 피드백이지만, 궁금점이 있었기에 추가하지 않았던 피드백들이다. 해당 내용들은 현재 튜터님께 설명을 듣고 이해하였기에 지금에서야 올린다.

  1. getter가 있으면 getter로 접근하기
    클래스 내에서 생성자 함수에 있는 변수를 사용할 때, 그대로 _를 붙여서 사용했다. 예를 들면 아래와 같다.

    this._isRun = true;

    그런데 _isRun은 이미 getter/setter 둘 다 있는 상황이었다. 하지만 강의에선 클래스 내부에선 전부 this._변수명으로 사용했는데... 개발자들간의 약속이라서 그런 거 아닌가?

    싶었던 과거가 있었다.
    들어보니 그런 건 아니란다. 나는 하나의 약속인 줄.... getter/setter를 사용하는 이유는 강의에서 배웠던 내용과 동일하다.
  2. getter 사용
    플레이어 클래스의 생성자 함수 내에 let을 이용하여 플레이어의 최대 HP를 저장하는 변수를 private로 선언했다. 이는 기획한 게임 구조 상 최대 HP는 변동할 일이 없기 때문인데, 그래서 함부로 접근하지 못하도록 그렇게 만들었다. 하지만 아예 접근을 안 할 수는 없었고(이유: 플레이어 상태를 출력할 때는 필요했음) 따라서 똑같이 생성자 함수 내에 this.getMaxHP = functon() ~ 을 통아여 값을 보일 수 있게했다.

    하지만 피드백에서는 getter을 사용하는 게 더 좋지 않겠냐고 했다. 왜 그런가하니, 이후 배우게 될 타입스크립트에서는 private를 명시해서 사용할 수 있다고 한다.
    대충 작성해보면 이런 소리인 것 같다.(아직 타입스크립트를 배우지 않아 틀릴 수도 있음)
class Player {
    private eventSelect: number; // private number 타입의 속성 선언

    constructor() {
        this.eventSelect = -1; // 생성자에서 eventSelect 초기화
    }

    get eventSelectValue(): number { // getter 메서드
        return this.eventSelect;
    }
}

let player = new Player();
console.log(player.eventSelectValue); // -1 출력

 

 

 

후기

솔직히 처음에는 만만하게 봤던 프로젝트다. 기존에 알았던 내용을 활용하기만 하는 문제였으니까. 실제로 구현 자체는 그리 어렵지 않았다.

하지만 서로 다른 언어에서 생기는 차이점 때문에 조금 힘들었던 것 같다.(지옥의 private......)

또한 처음부터 코드를 혼자 짜거나, 협력 진행으로 다른 사람의 코드를 수정한 적은 있어도(이마저도 처음부터 같이 시작했음) 다른 사람이 미리 짜둔 코드를 기반으로 기능을 추가하는 건 이번이 처음이었다. 때문에 조금 신선한 경험이었다. 이 코드가 무슨 기능인지 파악하는 시간도 조금 걸렸고... 무엇보다, 이미 틀이 짜여져 있어 파일을 나누는데 어려움을 겪었다. 이로써 다른 사람의 코드를 좀 더 많이 읽어봐야 할 필요성을 느꼈다.

 

한가지 아쉬운 점이 있다면 좀 더 창의적이지 못한 점?

오늘 두 분이 과제를 발표했는데, 각각 코드 실력이나 기획이 엄청났다. 정말 이걸 이렇게? 싶은 부분이 정말 많았다. 해당 부분을 본 받아 나도 과제를 과제로서 끝내지 말고 좀 더 도전하는 개발자가 되어야 겠다.