[TIL]2024-4-15 / 70일차 - 최종 프로젝트 7주차 1일차

 

1. 오늘의 알고리즘 코드카타 - 바탕화면 정리

 

답안 : 

 

//문제 길이가 아침부터 안읽힌다.
//문제 내용은 결국 모든 파일을 드래그해서 삭제하려는데
//이때 최소한의 이동 지점을 return하라는 문제
//역시 문제는 무시하고 입출력 예부터 보는게 편하다...

//격자판 특성상 배열을 이용하는 것이 좋아보인다.
//처음엔 조건문으로 따지는 구조를 생각했지만,
//다른사람의 답안에서 Max/MinValue 이용하는 것을 보고
//간략화하기 좋은 것 같아 몰래 베껴왔다...

using System;

public class Solution {
    public int[] solution(string[] wallpaper) {
        int[] answer = new int[]{int.MaxValue, int.MaxValue, int.MinValue, int.MinValue};

        // 배열의 행
        for (int i = 0; i < wallpaper.Length; i++)
        {
            // 현재 행의 문자
            for (int j = 0; j < wallpaper[i].Length; j++)
            {
                // 파일이 있는 칸인지 체크
                if (wallpaper[i][j] == '#')
                {
                    // 드래그 지점의 최소 행과 열
                    answer[0] = Math.Min(answer[0], i);
                    answer[1] = Math.Min(answer[1], j);
                    
                    // 드래그 지점의 최대 행과 열
                    // 행과 열 좌표에 1을 더하기 = 드래그 지점의 너비와 높이를 고려
                    answer[2] = Math.Max(answer[2], i + 1);
                    answer[3] = Math.Max(answer[3], j + 1);
                }
            }
        }         
        return answer;
    }
}

---

2. 오늘의 기술 면접 - MVC 모델이란 무엇인지 설명해주세요.

MVC 모델은 Model-View-Controller 디자인 패턴을 의미합니다. 

프로젝트의 구성 요소를 세가지 역할로 구분하는 패턴으로, 각 구성 요소는 다음과 같습니다.

 

1. 모델

모델은 정보와 데이터를 나타냅니다.

데이터와 정보의 가공을 담당하며 이러한 변경에 대해 통지할 수 있는 처리 방법이 필요합니다.

또한 모델은 재사용 할 수 있어야 하며 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 합니다.

또한 뷰나 컨트롤러에 대한 정보를 담아서는 안됩니다.

 

2. 뷰

뷰는 사용자 인터페이스 즉 UI 요소를 나타냅니다. 

텍스트나 이미지 등을 말하며 모델의 데이터를 기반으로 사용자 인터페이스를 보여줍니다.

뷰는 모델이 가질 정보를 따로 저장해서는 안되며, 모델처럼 다른 구성 요소를 가져서는 안되고

오직 보여주는 기능만을 담당하며, 이 또한 변경이 일어나면 변경에 대한 통지를 할 수 있는 처리 방법이 필요합니다.

(ex = 사용자가 화면에 표시된 내용을 변경하게 되었을 때)

 

3. 컨트롤러

컨트롤러는 이벤트를 처리하는 파트로 모델과 뷰를 이어주는 역할을 합니다.

모델이나 뷰는 서로의 존재를 모르는 대신 변경을 외부로 통지하고 수신할 수 있는데,

이를 컨트롤러가 중계 해주는 역할로 메인 로직을 담당하게 됩니다.

이를 위해서 모델과 뷰에 대해서 알고 있어야 하며, 이를 모니터링 할 수 있어야 합니다.

 

즉 사용자가 컨트롤러를 조작하면 컨트롤러는 모델을 통해 데이터를 가져오고 이를 뷰가 사용자가 볼 수 있는

시각적인 정보로 전달하게 되는 구조를 뜻합니다.

 

해당 패턴을 사용하는 이유는 각각 맡은 바에 기능을 집중 시키기 위함으로

유지보수의 용이성, 확장성 등을 고려하기 유리하고 중복코딩이 발생할 상황을 줄여줍니다.

그렇지만 MVC패넡의 단점은 뷰와 모델 사이의 의존성이 높아 해당 프로젝트가 규모가 많이 커지게 된다면

유지보수가 어려워질 수 있습니다.

---

3. 오늘의 작업

 

오늘은 플레이 테스트를 위해 잔잔바리 버그들을 많이 수정했다.

우선 오브젝트를 들고 옮기는 기능을 다듬어서 이제 박스 오브젝트들도 제대로 이용할 수 있도록 만들어 두었고

 

여태까지 미뤄뒀던 레이어 / 랜더링 소트 오더 정리도 한꺼번에 처리했다.

이전에 초기 프로젝트에서나 사용하던 태그 비교 방법은 비효율적이기에

많은 부분이 레이케스트와 각종 레이어 마스크를 사용하고 있는 만큼 다 정리하려니 많이 고민할 거리가 많았다.

 

그래서 사용 용도, 필요 기능에 따라 레이어를 구분했다.

 

해당 오브젝트가 레이어 마스크 판정을 할 때 따져야 할 필요한 기능을 위주로 구분한 뒤 미래를 위해

공간을 미리 많이 띄워뒀다.

 

소트 오더 또한 맵과 배경 제작을 위해 확실히 구분해 두었고

 

이번에 알게 된 사실로 레이어를 구분할 때에

Map/BackGround 와 Map/ForeGround 와 같이 구분해두면

 

이런 식으로 자동적으로 탭이 만들어진다는 소소한 사실을 알았다.

 

또한 트러블슈팅으로

 

 

팀원이 만들어 준 파괴되는 효과를 위해 쓰던 머테리얼이 있는데

이를 사용 시 오브젝트들이 반투명 해지는 버그가 생겼다.

머테리얼 적용 시에만 발생하는 것으로 보아 쉐이더 문제라고 생각되어 쉐이더를 살펴 보았는데

 

 

보니 서페이스 타입이 반투명 이었고 머테리얼 자체도 2D 스프라이트에서 사용하는 Sprite-Lit 타입이 아닌 Lit타입이었다.

 

 

이를 Sprite Lit으로 바꿔주고 아래에 파괴되는 이펙트에서 Split으로 알파값만 빼내어 머테리얼의 알파값으로 넘겨주고

자체적인 파괴 색상 설정도 기존의 알파값0에서 255로 변경해주었다.

 

이를 통해 문제가 해결되었다.

 

 

또 테스트를 위한 맵을 조금씩 수정하고 추가하여

 

 

처음 접속 시 보게 될 스테이지 셀렉트 로비 <캐릭터 변경, 기초적인 협동으로 문을 열어 스테이지 선택 장치로 다가가기>

 

 

기초 캐릭터 액션만으로 해결되는 튜토리얼1

 

 

기초 캐릭터 협동 액션과 기초 상호작용을 통해 해결할 수 있는 튜토리얼2

 

 

기초적인 물체 간 상호작용과 장애물을 오브젝트로 막는 과정을 필요로 하는 튜토리얼3

 

 

 

그리고 이후 보다 복잡한 물체 상호작용 로직을 위한 스테이지 맵을 하나 예시로 만들어 보았다.

지금 생각해보니 열쇠를 하나 없애는 편이 보다 의도대로 깨도록 유도할 수 있을 것 같다.

 

 

 

맵들은 보다싶이 자체적인 맵 에디터를 제작하여 이를 통해 만들어 데이터화 하고 있어

이런 기초적인 맵들도 초기 구현하는 데에 시간이 많이 소요되었다.

 

사실 그냥 배치하는 방식의 퍼즐게임을 구상했었던 방식 그대로 진행했더라면 훨씬 빠른 제작이 가능했을 것 같지만

포트폴리오와 인게임 외적 요소를 위해 추가 된 기능인데, 인게임 에디터까지 만들고 있다보니 생각보다 여러 부분의 작업에 영향을 미쳐야 했던 것은 예상 밖의 요소 였다.

장애물 오브젝트를 구상할 때에도 에디터에서 어떻게 배치할 수 있어야 하는지

ex = 움직이는 플랫폼의 이동거리와 속도 설정은 어떻게 시킬 수 있도록 해야 하고 UI는 어떻게  해야 할지 등등

 

 

지금은 많이 심심한 튜토리얼 맵도, 장식물 추가 에디터 탭도 따로 만들었기에

여러 조작 설명들이 들어갈 예정이다.

 

이왕 늦어진 김에 플레이 테스트를 더 높은 완성도로 받고 싶기에 이번 주는 모두 열심히 해야한다.