Portfolio - Java Game
프로젝트 기록
- 주제 : 자유롭게 게임 제작
주제선정 과정
의견 1 - 포커, 화투, 주사위 게임
- 반려 사유 – 사행성 게임으로 치중될 위험성이 높다
의견 2 – 유희왕 카드
- 반려 사유 – 확률에만 의존하는 게임에, 프로젝트의 크기가 기한 대비 작다
의견 3 – 메이플스토리
- 반려 사유 – 기능이 너무 많아 지금 실력으로 기한 내 구현 가능성이 낮다
절충안 – TCG 장르와 RPG 장르의 진행방식을 합쳐보자,
- 필수 구현항목과, 추후 업데이트 방식으로 구현할 항목을 나누어
- 기한 내 구현 가능하도록 프로젝트의 안정성을 우선으로 하자
개발 계획 수립
필수 구현 항목을 기준으로, 전체 게임 스토리 제작과 진행방식을 정한 뒤 연관성이 높은 항목끼리 분류하고 class로 묶는다
각 class 별 난이도를 고려하여 역할 분담을 한다
- 개발 속도가 비교적 낮은 팀원에게 개발 자유도가 높은 character 관련 class 배정, 전체적인 개발 속도 균형을 맞추고자 함
개발 과정에서 구현하고자 하는 세부적인 정보들을 field로 선별하고
개발 시 효율성을 높이고, 위험성을 최소화 하고자 class와 field의 변수명을 같이 지음
사용자 정의서 작성
게임 관련 배경 지식이 많은 팀원이 게임 내 세부 수치, 스토리 보드를 기반으로 작성하였고
다른 팀원이 전체 프로그램에 대한 flow chart를 작성, 초안 완성
flow-chart
개발 시작
- Dg, Boss class 담당 맡음
Dg
main 메소드에서 흐름에 따라 코드 먼저 작성 후 연관된 변수, 기능에 따라 4개의 메소드(몹 설정, 몹 등장, 레벨업, 던전플레이)로 나누었음
static을 언제 사용해야하는지에 대해 개인적인 기준을 갖게 되었음
-
일단 무분별한 static은 지양하고, 랜덤숫자 선택 메소드나, y/n 입력확인 메소드처럼 광범위하고 빈번하게 쓰일 경우 static이 더 나은 것 같다는 판단
-
혹은 유저네임처럼 변하지 않는 값, class간 이동이 잦은 필드의 경우 static을 사용했을 때 활용성이 높아 유용했음
파라미터의 수나 타입이 다른 같은 이름의 메소드를 만들 수도 있다는 걸 알게 됨
outer: 라벨링을 해주면 다중 반복문 사용시 편리함! 한번에 라벨링된 반복문까지 break, continue를 할 수 있음
Boss
Dg 와 동일한 방식으로 코드를 먼저 작성하고, 보스플레이, 결투, 승리, 패배 4가지의 class로 나눔
필드를 변수에 담고 변수를 변경시에 변경값은 필드에 반영되지 않는다는 것을 알게 됨
- 여러 메소드의 이부분에서 에러가 발생하였고, 주의가 필요한 작업인 듯함
메소드의 파라미터 값이 많거나, return값이 많으면 array로 대체하는 것도 괜찮은 방법같고,
여러값을 return 할수 있는 class를 따로 만들어 사용하는 방법도 있음
프로젝트 후기
처음부터 목표는 “좋은 결과”가 아닌 “좋은 과정”을 삼았음
퀄리티 높은 결과물보다 협업을 통한 프로젝트 과정을 중요시함
협업이 목표가 아니라면 자바의 객체지향성이란 메리트를 온전히 이용하지 못한다고 생각했기 때문에.
객체 지향성이란 성격을 최대한으로 이용하기 위해서 클래스와 메소드, 필드를 나누고 변수 이름을 작업 시작 전에 팀원과 같이 결정함
의도했던 바와 같이 실제 각 팀원의 개발 속도, 내용과 무관하게 프로그램 속에 개개인의 개성이 담긴 코드를 녹여낼 수 있었고,
최종본을 만들 때에도 각자 맡은 서로의 클래스에 호출을 통해 이어주는 몇 번의 작업으로 통합 작업을 끝낼 수 있었음
“객체지향”의 장점이 너무나도 돋보이는 기회였음
왜 자바를 많이 이용하는지 깨닫게 됨
처음부터 큰 크림에 복잡하거나 조급하지 않아 하드코딩을 하지 않게 되고,
오류가 나도 프로그램 전체가 아닌 메소드, 필드 단위의 확인 절차에 디버깅 시간도 단축되고,
무엇보다 “객체”를 이용하면 프로그램의 확장성이 좋아 아이디어를 구현하기 최적화된 환경이라 생각됨
KPT
Keep
-
구현할 프로그램의 로직을 짜고
-
클래스별 역할 분담을 하고
-
코드작성 전 클래스와 필드명을 팀원과 같이 짓는다
Problem
-
최종 제출까지 시간이 얼마 남지 않았을 때, 오류 수정 과정에서 일방적으로 진행했던 잘못을 저질렀다
- 팀원 간의 불화가 있을 가능성이 높았고, 팀원의 노력에 대한 부분을 충분히 고려하지 못했다
Try
- 다행이 운이 좋아서 큰 불화가 없었지만, 다른 팀의 갈등과정을 지켜보며 개발 시작 전에 서로 간 지켜야할 점들을 토의하고 시작해봐야겠다