입력한 플레이어 이름을 머리 위에 띄우며 플레이어 생성

[Joseph-Cha]

1. 플레이어 생성 설계 자료 (#42)

1. 게임 시작 전 플레이어 이름 입력
   • 유저 ⇒ InputField : 입력 // InputField에 캐릭터 이름 입력
   • InputField ⇒ StartData : SavePlayerData // InputField의 text 값을 PlayerPrefs에 저장
2. 입력한 플레이어 이름을 머리 위에 띄우며 플레이어 생성
   • GameManager ⇒ Player : CreatePlayer // 본 게임 시작되면 Player를 생성
   • Player ⇒ PlayerPrefs : GetPlayerData // 인트로씬에서 저장한 Player의 데이터를 가지고 옴
   • Player ⇒ Player : InitPlayerSetting // Player가 생성될 때 데이터 초기화

차후 작업 예정

1. 테스트 코드 작성 -> 입력한 데이터로 플레이어가 생성되는지 테스트
2. 본격적인 Player 클래스 설계
   • 필드(HP, 공격력, 이동 속도 등)
   • 메서드(이동, 공격 등)

설계 문서는 사전에 PR로 드렸지만 여기서도 볼 수 있으면 좀더 좋을 것 같아서 같이 올립니다.
Player 클래스 설계부터 본게임 느낌이네요!

[jongfeel]

제가 이거 pull request 올라오고 다음 날엔가 적었었는데
제가 적어서 submit 했다고 착각했나 봅니다.

내용도 없어져서 지금이라도 다시 review 진행해 봅니다.

[jongfeel]

PlayerUI class와 Player class를 분리해서 작성해 봤으면 좋겠습니다.

그러니까 MonoBehaviour를 상속받는 Player는 사실 PlayerUI 역할을 하고 실제 데이터는 Player에서 가져와서 해보는 거죠.
MVC 패턴에 V에 해당하는 PlayerUI와 M에 해당하는 Player를 나누면 어떻겠냐의 제안입니다.

[Joseph-Cha]

#39 에서 Player 설계를 진행했을 때 PlayerData 클래스와 Player 클래스를 구분했었는데 그때 속성(PlayerData)과 행위(Player)를 구분하는 것보다 한 곳에서 하는게 좋다는 조언을 해주셨습니다. 위에 해주신 것과 다르면서도 같은 느낌이라 다소 혼란스럽네요 ㅠ

크게 두 가지 부분이 헷갈립니당

1. UI로 보여주는 부분만 분리해서 가는 것이 좋다는 이야기일까요?
2. 만일 실제 데이터를 Player에서 가지고 있다면 Player의 메서드를 구현하는 클래스도 일단 Player로 가는 방법으로 유지할까요?

[jongfeel]

다시 설명드리면 PlayerData + Player가 합쳐지는 건 맞고요 이걸 Player라는 class로 만드는 방향으로 가는 것도 맞습니다.

다만, MonoBehaviour를 상속 받는 class가 PlayerUI의 역할을 하고 있으니까 Player와 구분해서 구현해 보자로 얘기한 거고요.

그런 의미에서 1번 질문에 대한 대답이 될 수 있을 거라 생각합니다. 2번 질문도 자연스럽게 대답이 된 거 같군요.

[Joseph-Cha]

우선 조언해주신 PlayerUI와 Player를 구분해서 작업을 해보았습니다.

[jongfeel]

LGTM