개발일지

현재 퀴즈는 같은 문제가 나오지 않도록 문제 유형만 통일하고 변수들의 값을 변화를 줘서 다른 답을 제출하도록 구성해놓았다. 그런데 문득 다른 팀원 분이 이렇게 하면 문제를 클릭할 때마다 달라진다는 사실을 캐치하셨다...!! 적어도 같은 방에서는 누가 클릭해도 같은 문제를 보이게 해서, 처음 우리의 의도대로 같이 문제를 풀 수 있게 구상하기로 했다. 현재 퀴즈는 단서 없이 해당 문제만으로 답을 찾을 수 있는 A타입과, 단서가 다른 오브젝트에 있어서 단서를 찾아서 조합해 풀어야 하는 B타입이 있다. A타입은 별도로 Quiz entity를 만들어서 퀴즈를 조회할 때 저장된 값이 없으면 새로 만들어서 저장하고, 그 이후에는 db에 저장된 값을 불러오도록 하였다. B타입의 경우 현재 Room entity 안에 c..

유저의 로딩 완료 문제를 처리하다가, 로딩 중에 연결이 끊기면 어떻게 되지? 라는 질문이 나왔다. 기본적으로 클라이언트가 방에 들어오면 socket통신으로 연결되기 때문에, 연결이 끊기면 socket.io에서 가장 먼저 알게된다. 문제는 이렇게 연결이 끊긴 것을 spring 서버에서 알고 db에서 처리를 해줘야 한다는 점이다. 메인페이지에서 방 리스트를 조회할 때 방의 인원수도 같이 표시되기 때문에 업데이트를 해줘야 한다. 그래서 처음에 고민했던 것은 node에서 spring으로 바로 socket.id를 알려주는 것이다. socket의 disconnect 이벤트 안에서 spring으로 데이터를 보내줘야 하는데 socket 통신에서 HTTP 통신을 쓸 수 있는지 알 수 없었다.(불가능하지 않을까?) 서버 ..

게임을 동시에 시작하기 위해서는 해당 방의 모든 유저들의 로딩이 완료되어야 한다. 클라이언트는 자신이 로딩이 완료된 것 밖에 알 수 없기 때문에 서버를 통해서 처리하는게 필요하다. 로딩이 완료되면 api를 통해 로딩이 완료됬음을 서버에 알리고, 서버는 해당 방의 loadingCount를 올려서 방의 인원 수와 일치하는 순간(즉 모두가 로딩된 경우) true를 return하여 클라이언트에게 알려주기로 했다. 현재 S3에서 게임 resource가 저장되어 있기 때문에 aws의 람다나 다른 방법을 통해 서버가 로딩이 완료된 시점을 알 수 있는지 찾아봤는데, 로딩은 결국 클라이언트에서 방을 랜더링하는 과정까지 포함하기 때문에 서버에서 알 수 있는 방법은 없는 것 같다. 그렇다면 클라이언트에서 완료됬을 때 요청을..

실전 2주차가 시작됬다! 다른 팀원들이 S3와 로딩 문제를 봐주시는 동안 퀴즈를 어떻게 낼 것인지 생각해봤다. 우선 퀴즈는 1. 퀴즈만으로 푸는 문제, 2. clue가 필요한 문제로 나눌 수 있고 일단 각각 한 문제씩 만들었다. clue의 경우 clueA와 clueB를 만들어서 방을 개설할 때 미리 랜덤으로 값을 주게 하였고, clueA와 clueB가 필요한 문제인 Ba의 답을 해당 방의 clueA, clueB 값으로 계산하여 맞추도록 하였다. 문제를 조회하는 api는 하나를 만들고 quizType을 pathvariable로 주면 해당하는 문제와 답을 미리 내려주고, 맞는 답을 제출하면 count +1 api를 통해 해당 방의 맞춘 문제 개수를 늘려주었다. 문제를 2개 만들었는데 문제를 풀 힌트도 필요할..

오늘은 한 주의 마지막 날이다. 한 주 동안 실전 프로젝트를 진행하면서 힘든 적도 많았지만 무엇보다 처음 목표했던 RTC를 구현해서 너무 좋다. 오늘 spring서버도 HPPTS로 배포하고 socket이랑 spring 모두 잘 연결되는 것도 확인했다. 다음주 월요일에는 2명이 아니라 한명을 더 추가해서 잘 연결되는지 확인해보기로 했다. 이번 주 진행상황 리뷰하고 다음주에는 게임 방 resource를 내리는 것과 퀴즈를 구현해보기로 했다. 게임 resource는 서버에서 내릴지, 클라이언트에서 내릴지 고민했는데 우선 서버의 S3에서 내리는걸 시도해보기로 했다. 확장자가 glb라서 어떻게 내리고 어떻게 구현하는지 궁금했는데 프론트에서 라이브러리를 써서 파일만 다운받으면 가능한 것 같다. 또 eventList..

어제 https를 붙인 socket 서버를 테스트해보았다. 역시나 제대로 연결이 되지 않았다. 그런데 socekt서버를 수정하면서 햇갈렸던 부분이 있어서 그 부분을 바꿔봤는데 연결이 잘 되었다!! 프론트에서 처음에 S3로 배포해서 연결을 했는데 HTTPS 관련 에러가 떠서 프론트서버도 HTTPS로 배포했다. 현재는 1:1이지만 연결이 잘 되었다! socket 서버 event에 console.log를 찍어서 데이터가 잘 들어오는 것도 확인했다. 그리고 프론트에서 서버 2개가 연결이 되는지 확인해보기 위해 spring서버를 따로 EC2로 배포하고 axios로 api를 통해 데이터가 잘 들어오는지도 확인해봤다. 데이터도 잘 들어왔다!!! 진짜 너무 좋았다 ㅋㅋㅋㅋㅋㅋ spring서버가 아직 HTTPS가 아니라..

nodeJS로 socket.io를 구현하기 위해 먼저 노마드코더에서 무료로 제공하는 줌 클론코딩 강의를 듣고 해당 코드를 가지고 서버에 올려서 프론트와 연결해보기로 했다. 강의 듣기 전에 node에 대해서 너무 모르는 상태라서 코드잇에 있는 강의를 앞부분만 들었다. 비동기 개념이 너무 신기했고, 서버를 정말 간단하게 구현할 수 있다는 것이 놀라웠다...! 아직 스프링도 잘 이해한 상태가 아니라서 제대로 비교하기는 그렇지만 확실히 다른 타입인 것 같다. 또, 자바와 스프링을 조금 하고 공부를 시작하니 라이브러리를 인포트에서 쓴다던지, 필요한 객체를 선언하는 거라든지 클라이언트와 서버에 대한 기본적인 관계는 이해가 되어 있어서 가볍게 지나갈 수 있었다. 하나를 잘 해놓으면 다른 언어나 프레임워크를 배우기 수..

socket.io는 별도로 구현하기 때문에 이것과 상관없이 spring은 계획한대로 진행하기로 했다. API 명세 중 우선 방 만들기와 방 참여하기 부분을 구현했다. 로그인이 없이 게임을 참여할 때만 유저를 임시로 만들기로 했기 때문에 이 부분을 어떻게 처리해야 할지 고민이 많았다. 우선은 유저의 nickName을 임의로 주기로 했는데, 로직을 어떻게할지 고민이 많았다. 처음 생각했던 것은 별도의 엔티티를 생성해서 거기서 가져와 쓰는 것이었는데 이렇게 하면 유저가 추가될 때마다 DB가 조회되고, 유저샘플로 저장할 데이터가 많은 것도 아니라 그냥 방을 생성할 때 배열을 만들고 거기서 닉네임을 랜덤으로 꺼내오는 메소드를 만들었다. private String getNickName() { // User에 nic..

큰 이슈가 있었다. 우리가 구현하고자 하는 서비스는 최대 4명까지 보이스 채팅이 가능한 게임방을 만드는 것인데 spring으로 구현한 signalling 서버로는 1:1 P2P 연결만 구현할 수 있었다. P2P로 다중 연결도 가능은 하나 서버에 부하가 올 수 있고, 무엇보다 참고자료를 거의 찾을 수 없었다. spring으로 WebRTC를 구현한 케이스도 몇 개 없었는데 구글에 검색했을 때 뜨는 게 없었다. 그래서 몇 가지 안을 놓고 팀 안에서도 회의를 하고, 매니저님께도 의견을 구했다. 기능을 구현하지 못해 서비스를 축소하거나 다른 서비스를 도입하는 것은 프로젝트라는 측면에서 좋은 선택지는 아니라고 생각했고, spring으로 구현하는 것은 자료가 거의 없어서 난이도가 너무 높았다. 마지막으로 고민한 건 ..

정말 오랜만에 쓰는 개발일지이다. 실전프로젝트를 시작하고 며칠동안 정말 많은 일이 있었다. 마지막까지 고민하다가 다른 분들이 응원해주셔서 리더로 지원해볼 수 있었다. 같이 해보고 싶던 분들과 모두 한팀이 되서 너무 기쁘다. 아이디어도 금방 정하고, 중간에 피드백 받으면서 생각하지 못한 부분에서 지적받아 고민도 있었다. 아무래도 웹게임을 만들다보니 페이지 수가 적어서 디자이너 분들과도 협의가 필요했다. 매일매일 잘 하고 있는건지 고민이 많다. 기간은 한정되어 있는데 그 안에 어떻게 하면 더 잘 해낼 수 있을지, 당장 일은 어떻게 나누는게 좋을지, 무엇부터 시작해야 할지 등등!! 그래도 좋은 팀원들 만나서 서로 힘내서 할 수 있을 것 같다. 6주가 짧은 기간은 아니니, 페이스 조절을 잘 하면서 더 열심히 해..