오늘 한 일
- 프로그래머스
- 줄 서는 방법 (Level 3)
- 실내 운동
문제 풀이
줄 서는 방법 (Level 3)
n명이 줄서는 방법을 사전순으로 나열하였을때 k 번째 순서를 돌려주기.
풀이 완료
문제에서 주어진 줄서는 방법의 가지수는 예시나 k의 제한 조건에서 보이다시피 n!이다. 따라서 모든 방법을 직접 구현해가면서 찾는 방식은 기각 된다.
해서 생각한 방식은 주어진 수 k 와 현재 사람수보다 1명 적을때의 줄서는 방법의 가지수를 바탕으로 조합을 찾아 가는 방식이다. 예시를 바탕으로 이야기 해보자면 사람수가 3명 일때 사람 1을 선택시 사람 2,3 을 배치하는 두가지 방법이 있다. 물론 2,와 3을 선택해도 동일한 가지수의 방법이 있다.
또한 위 조합들의 순서는 예문에 보인것처럼 사람 1을 선택한것이 먼저이고 그다음 2 와 3이다. 이것을 배열의 인덱스로 생각해 보았다. 그러니까 사람1의 조합들은 index [0,1], 사람2는 [2,3] 사람 3은 [4,5] 처럼.
그리고 각각의 조합에서 첫 값으로 조합의 나머지 인덱스를 뺀경우 0: [0,1], 2:[0,1], 4:[0,1] 이 된다 앞의 값을 제외하면 인덱스가 동일해진다. 또한 앞의 값은 자신이전의 조합의 가지수와 일치하는 것을 볼수 있다. 이를 바탕으로 n명의 사람이 존재할때 k 번째 조합을 찾아가는 지침을 구성하였다.
예문의 예시를 바탕으로 다시 진행 해보면 n-1의 가지수는 2개 이고 k-1을 가지수로 나눈 몫은 2이다. 따라서 현재 존재하는 사람의 배열에서(초기에 오름차순으로 정렬된) index가 2인 사람을 선택한다.
사람 3이 선택 되었고 남은 사람의 배열은 [1,2] 이다. 사람 3으로 시작되는 조합중 앞선 조합들을제외하였으므로 k에서 4를 제하고 남은 k에 1을 뺀값을 현재 조합 가지수 1!로 나누어 몫을 구하면 0을 구할수 있다. 따라서 사람 1이 선택되고 같은 방법으로 나머지 사람 2도 선택한다.
물론 이미 사람 1이 선택된 시점에서 남은 사람이 2뿐이기에 그 자리에서 2도 선택해도 무방하다.
위 방식을 사용하여 우선 사람들의 배열을 구성하고 위방식을 따르는 재귀함수를 구성하고 구성된 재귀함수를 사용하여 결과를 돌려주는 방식을 취하여 해당 문제를 풀이하였다.
길게 생각해볼것
코딩 문제 풀이 잘못된 폴더 선택 문제
- 커밋기록 유지한채로 폴더 옮기는 법 찾는 중
개인프로젝트
홈페이지 만들기
- 클라이언트와 연결된 서버 서버와 서버서버를 통괄하는 메인서버로 구성할 예정
- 서버스택은 node.js, express, typescript를 사용할 예정
- 데이터 베이스는 mysql 를 바탕으로 typeorm을 사용할 예정
- 배포는 aws를 사용 할 예정.(새로 생성한 계정을 이용)
- 제작 기간은 딱히 정하진 않음 - 생각하고 정리되면 그에 맞춰 행동할 예정
- 클라이언트 부분중 생각했엇던 기능:
- 홈페이지는 그동안 연습하거나 했던 것들을 담아둘 공간으로서 제작하려고 햇기에 해당 영역을 기능으로 구현해야한다. 이후 개별프로젝트나 새로운 언어 기능을 학습할때의 결과도 같이 올려둘 예정.
- 가능하다면 벨로그에 작성중인 블로그를 같이 게시할수 있었으면 한다. 해서 해당 부분을 고민해볼 것.
- 그 외 연습하고자 하는 기능들을 추가해볼 영역이 별도로 필요로 할듯하다.
- 클라이언트 외형(메인페이지)
- 상단에 얇은 바를 구성 위에 언급한 기능으로 가는 메뉴를 나열 시킴
- 사이드 페이지
- 메인페이지에서 구성된 바는 공통으로 나타나게하고 좌측에 사이드 바를 구성 별개의 세부 메뉴를 나타나게 구성함. (세부적인 크기 위치는 확정 되지 않음. )
pathfinder(미로 길찾기 게임)
- 기본적인 스택은 위 홈페이지와 유사할것으로 생각.
- 3개의 난이도 구분을 가정
- 미로 구성은 랜덤성을 포함함 예정
- 전장의 안개처럼 가지않은곳의 시야을 막아둘예정
- 움직이는 캐릭터의 성장은 갖게되는 무기의 성장으로 대변할 예정
- 피로도 개념 추가
- 회복약, 스테니머 회복은 하나의 아이템으로 전용
- 기타등등 정의되지 않은 생각이 있음.
프론트 엔드 구성
- 메인 페이지(로그인)
- 게스트 입장 가능
- 가입 방식 추가 고려(카카오톡, 구글, 네이버 등등...)
- 상단에 타이틀 하단에 로그인 모달 구성
- 배경은 울창한 숲 사이에 난 길을 배경으로 하고 싶지만 찾지못함.
- 난이도 선택 부터 나머지 페이지 우측에는 사이드 바 를 구성
- 난이도 선택 페이지
- 자동저장시 현재페이지가 메인페이지 바로 뒤에 오게됨
- 선택페이지를 3분할(A|B|C 형태로)하여 각각의 난이도로 정의
- 해당 난이도의 최근 결과 혹은 최고 결과를 보여줌
- 자동 저장 사용 시 진행중인 단계에 표시할 무언가를 생각할 것
- 자동저장 사용시 진행중인 이야기를 제거하고 새 이야기를 시작할수 있게 구성할 것
- 외부 맵 페이지
- 영역으로 구성된 맵을 보여주는 페이지
- 이지단계는 입구 1개 크기 3x3 을 생각하고 있음.
- 이후 단계의 규모는 5x5, 7x7을 가정하고 있다.
- 현재 위치로 지정된 sector의 경우 녹색 계열에 반짝이는 효과를 구현한다.
- 현재 위치로 지정된 sector와 연결된 구역은 구분가능한 계열의 색으로 칠한다.(색미정)
- 그외 지역중 방문한 영역은 회색 혹은 하얀색으로 미방문지역은 검은색으로 표현한다.
- 현재 위치로 지정된 sector와 연결되었지만 플레이어가 해당 통로에 방문하지 않은 경우를 표현하는 색을 정의해야한다.
- 내부 맵 페이지
- 실제 미로 영역
- 미로의 크기는 아직 미정
- 미로 구성은 랜덤성을 바탕으로 구성됨 영역간의 입구는 우선은 전부 연결되는 형태를 가정
- 움직이면서 몹과 싸우기도 하고 보물을 발견하기도 하는 형태로 구성예정.
- 움직이지 않은 영역은 보이지 않게 구성할 예정
- 피로도 시스템을 고려하려고 하지만 어떤 방식으로 할지는 생각중
- 우측 사이드 바
- 캐릭터의 장비 나 인벤토리 버튼 구성
- 기록을 열람할수 있는 통계 버튼 구성?
- 아직 세부적인 정리가 진행되지 않음
- 맵 상단의 작은 바
- 피로도를 보여줄 장소
- 세부적인 구성은 아직 생각 중
미로 생성, 미로 탐색
- 알고리즘을 직접 구현해서 사용하려하였으나. 시간이 오래걸리고 좋은 퀄리티가 나올 것같지않아 이미 많이 알려진 알고리즘에서 골라 사용하기로 결정
- 참조하기로한 미로 생성 알고리즘을 재현 완료. 제작 중인 코드에 적용 완료.
서버 구성
/Map
- /:level/map/ 형태의 path 로 고정
- 구분자 map의 위치를 수정할지 고민중
/Sector
- /:level/sector/:sid/ 형태의 path 로 고정
- 구분자 sector의 위치를 수정할지 고민중
/Save
- api path만 구성중 사용 방식은 고민중
/User
- api path만 구성중 사용 방식은 고민중
/Record
- api path만 구성중 사용 방식은 고민중
DB Entity 구성
Map
- id, level createdAt, updatedAt 을 칼럼으로 보유
- User 와 M:1 관계를 가짐
- User 와 Cascase 관계 설정
MapTile
- tid 를 칼럼으로 보유
- Map 와 M:1 관계를 가짐
- Sector 와 1:M 관계를 가짐
- Map 과 Cascase 관계 설정
Sector
- sid 를 칼럼으로 보유
- MapTile 와 M:1 관계를 가짐
- MapTile 과 Cascase 관계 설정
Save
- id, level, time, updatedAt 을 칼럼으로 보유
- Map 과 1:M 관계를 가짐
- User 와 Cascase 관계 설정
Tile
- id, pass, here, visit, invite, createdAt, updatedAt 을 칼럼으로 보유
- MapTile 과 Secter 에 상속 됨.
User
- id, username, password, email, createdAt, updatedAt 을 칼럼으로 보유
- Map, Save, Record 와 1:M 관계를 가짐
Record
- id, level, time, updatedAt 을 칼럼으로 보유
- User 와 M:1 관계를 가짐
추가
DB Entity 구성
MapTile
- MapTile 에서 Maptile로 수정 (mysql 상에서 테이블 네임의 변경현상을 확인하고 수정)
오늘은...
Map Entitiy에 대한 동작 확인 완료
이전에 지도 데이터가 db에 저장 되지 않은 문제의 원인은 cascade 옵션의 사용법에 대해 무지하였던 결과 이다. cascade 옵션이 true일경우 하부 엔티티의 데이터를 해당 엔티티 저장시 같이 넣어야 한는듯하다. 그리고 별개 저장이나 업데이트는 거부하는듯하다. 해서 해당 옵션을 제거시만 호라성화되게 수정하였고, 그 이후에는 데이터 저장이 잘 이루어졌다.
Map, Secter API 기능 구성
두 API 의 기능을 구성하려 어떤식으로 진행할지를 고민하다가 Tile 객체의 형식을 일부 수정하였다. 또한 기능 추가를 위해 고민하다보니 해당 기능이 동작하는 시점에대한 고민으로 넘어 가게 되었다.
기본적으로는 유저 로그인 이후 유저정보를 가지고 있는 상태에서 해당 정보를 얻고 적요하여야 하는데. 현재 시점에서는 map 단일로 저장하는 방식을 고민하다보니 해당 과정을 어떻게 진행해야할지 고민이 되었다.
또한 게스트 입장을 고려하고 있는터라 해당 부분을 어떤식으로 구현할지에 대한 고민도 추가되었다. 길게길게 고민을 이어나가야 할 것 같다.
