교수님이 상을 당하셔서 임시 교수님의 수업을 기록해보았다.
visual studio 실행
나중에 unity를 쓰면 서버 에디터로 notepad++ 많이 사용한다. 오늘 개인 컴퓨터 사용자는 이거 깔아서 사용해도 된다.
IDE라는 통합개발환경 툴을 쓸때 VS를 많이 쓴다 VC를 쓰는 경우도 있지만 회사에서는 결국 VS를 쓰게 된다 .
얘는 기본적으로 뒤에 붙는 이름이 많다.
우리가 처음 만날거는 10/13/15/17/19/22
이 6개를 만날 확률이 높다. 20이 생략된 출시 연도
더 낮은 버전을 사용하기도 한다.
해당 게임이 출시된 버전에 맞춰서 유지 보수 해가면서 쓴다.
버전이 바뀌면서 많은 기능들이 빠져나가기 때문에 이미 잘 돌아가고 있는 게임의 버전을 바꾸는 것은 리스크가 있다.
추천되는 버전은 19버전. 2022가 최신이지만 아직 안정화 검증이 안 되어 있다.
설치를 걸어 놓을 때 언어 설정이 가능한데 게임을 다루려면 C++/C# 둘다 다루게 되기 때문에 C#만 설치할 필요가 없다. 한번에 같이 설치하자.
수업은 2022로 진행할 것이며 우리는 19로 실습을 한다.
오늘 메인은 코드를 보여주기보다 프로세스를 확인하는 내용이기 때문에 안 깔려있어도 괜찮다.
설치할 때 커뮤니티를 깔아야한다. 설정 할 때 유니티 C++ C#만 설치해도 충분
설정이 오래 걸리기 때문에 노트패드++만 사용하는 걸로
—---
새 프로젝트 만들기에서 C# 선택 -> 우리가 공부하는 내용이 얘네를 이해하기 위한 내용이다.
// 주석 만들기
// : 한줄 주석 - 코드에는 영향을 주지 않는다.
내가 또는 타인을 위해 메모를 남기는 것
프로그래밍을 하다보면 결국 효율성으로 귀결 된다.
10줄의 주석을 만들려면 //가 10번 들어간다.
어짜피 주석인데 10번 쓰는거 비효율적이니까 C#에서는 /* */를 활용하여 단위 주석을 쓸 수 있다.
컴퓨터는 굉장히 똑똑하지만 유도리가 없다.
주석을 썼을 때 초록색이 된다.
주석 없이 한글을 적으면 빨간줄과 에러가 뜬다.
컴퓨터가 알고있는 문법에 등록되어 있지 않기 때문에 에러가 뜨는 것
그래서 정확한 명령을 컴퓨터에게 주어야 한다.
단위 주석을 사용하면 내부에 내용이 전부 주석 처리 된다.
초기 세팅
도구 탭 -> 옵션 -> 환경 탭에 글꼴이 있다.
여기서 각자 편한걸 정할 수 있지만 개발자들 끼리 정해놓은 규칙이 있다.
C#은 주로 모나코를 사용하고 C++은 주로 콘솔라스 쓴다.
글꼴이 생각보다 중요하다.
1iIlL00o 전부 다르게 쓴 내용인데 구분이 안된다.
혼자하는 작업이 아니기 때문에 서로 구분하기 위해 규칙을 정해놓은 것이다.
형태를 먼저 보자
중앙에 단위주석이 들어가있고
#region 프로그래밍 언어 #endregion
컴퓨터는 유도리가 없기 때문에 이 유도리를 위해 프로그래머가 시작과 끝을 명시해줘야 한다.
#은 명령 지시자
명령을 내리겠다고 선언하는 것
region이라는 명령을 지시한 것
얘 자체는 안에 내용을 단락으로 묶어주는 역할을 한다.
게임에 플레이어든 적이든 다양한 기능이 있을 텐데 이것들을 하나씩 그룹화하기 위해 사용한다.
이렇게 하여 더 빠르게 액세스가 가능하다.
프로그래밍이란
프로그램+ing 지금 프로그램을 하고있다 라고 직역 가능
지금 프로그램을 하고 있다라는 말= 프로그램을 만드는 것 = 개발
프로그래밍 언어란
컴퓨터와 대화 또는 명령을 할 수 있는 일련의 명령문을 작성할 수 있는 언어를 의미한다.
언어를 이용하면 프로그램을 만들 수 있다.
언어는 다양하지만 크게 2가지로 분류할 수 있다.
특정 기능 구현에 최적화 된 언어
범용적 언어
우리가 배우게 될 C#은 범용적 언어라고 생각할 수 있다. 근데 배우다 보면 이게 1번에 해당되는 걸 깨닫게 될 것이다.
루아나 루비같은 애들이 특정 기능 구현에 최적화 되어 있는 거 같지만
C#은 메모리 접근이 불가능 하기 때문에 2번이 될 수 없다
최근 출시 된 갓오브워 칼리스토 같은 애들 C#으로 구현이 안 된다.
C++과 C#의 차이
면접에서 많이 물어보는데 C#을 중점적으로 답변하라는 문제가 많이 나온다.
*C#은 메모리 접근 불가
트리플 A게임들을 구축할 때, 멀티플랫폼을 사용하게 되면 다양한 기기에서 플레이 할 수 있게 된다.
플스 한정 게임, 플스는 스펙이 정해져 있다. 컴퓨터는 분포도가 다르다.
램도 사람마다 다르고 근데 플스는 그게 안된다 fixed 고정된 사양
빔프로젝트 화면이 약 100개의 메모리가 필요하다고 하면 실제로 100개의 메모리를 할당해줘야한다.
다음 씬으로 넘어갈 때 역시 동일하다
근데 플스에 전체 메모리가 100개면 이게 안된다.
두번째 신에 꽉 채웠기 때문에 이전씬으로 돌아가기도 어렵다.
메모리를 돌려 막은 것
얘를 들어 몬스터를 잡아서 사라진다면 더이상 메모리를 차지할 이유가 없다.
얘를 메모리에서 들어내면 좋은데 C#은 그게 어렵다.
이 과정이 반복되면 유저들이 freezing(렉이 걸리는 현상)을 보기 시작한다.
C# 내부에서 메모리를 계속해서 순환시키고 있기 때문.
12345라는 적이 있고 한번에 다 죽이면 그룹화 시켜서 한번에 지우면 효율적이다.
근데 C#언어에서는 죽을 때 하나하나 접근한다.
최적화 할 때 절차가 많아지면 느려진다.
죽은 첫번째 적을 찾아 지우고 이 과정을 5번 잡는 식으로 진행된다.
죽는 순간 시체를 눕혀놨다가 나중에 시체를 그룹화 시켜서 없애려면 C# 언어에서는 불가능
C++은 가능
이렇게만 들으면 C++이 무조건 좋아보이는데 얘가 범용적 언어라는 것은 많은 기능이 들어있다는 뜻
실제 게임에서 40%도 안 쓰더라도 전체 언어를 다 불러와야 쓸 수 있게 된다
요즘 대세 언어 자바
자바는 웹개발에 매우 최적화 되어 있다.
메모리 들어내고 이런 과정이 필요없기 때문에
그래서 사람들의 사용량이 늘어나니까 커뮤니티가 활성화되고 기능이 강력해진다
유니티도 자바를 쓰지만 기능적 한계가 너무 적고
그래서 C#으로 대체된 것
언리얼까지 가면 C++
컴파일러
프로그래밍 언어를 컴퓨터에서 이해하는 방법
컴퓨터 언어로 작성되어 있는 코드는 컴퓨터가 직접 이해할 수는 없기 때문에
이를 중간에서 해석해주는 번역가 역할을 하는 무언가가 필요하다.
C#은 중간언어로 변환이 필요하다
이것이 컴파일러
컴파일러는 해당 코드를 컴퓨터가 이해할 수 있는 언어로 변환하는 역할을 한다.
C#에는 컴파일러 없이 컴파일만 진행되고 C C++에는 컴파일러가 존재한다.
머리 속으로 이해해도 손으로 안쳐보면 이해가 안될 수도 있다.
눈코딩이라는 은어가 있는데 쳐보는 연습을 하는게 좋다.
사람(프로그래머) - 컴파일러 - 컴퓨터
컴퓨터는 아무리 하드웨어가 좋아져도 명령을 주면 컴퓨터는 어셈블리 2진법으로 들어가게 된다. 0과 1로 이루어진 2진법. 내가 스페이스 눌렀을 때 캐릭터가 점프하는 과정도 전부 2진화된다. 결국은 프로그래머가 명령을 컴퓨터에게 주면 변환이 필요하다. 내가 작성한 명령문을 2진법으로. 근데 내가 직접 바꾸려니까 난해하다. 불가능한건 아니지만 갈아넣게 된다. 그래서 효율이 떨어진다. 이 과정을 단순화 하기 위해 컴파일러가 필요하다
그렇다면 컴파일러는 사람의 언어와 2진법 둘다를 알고 있어야한다. 그래서 사람이 쓴 명령문을 받아주고 이걸 2진법으로 변환하여 컴퓨터에게 넘긴다. 컴퓨터는 이제 2진법으로 넘어온걸 받아 실행 결과를 다시 컴파일러에게 2진법으로 돌려주고 컴파일러가 우리가 알아볼 수 있게 끔 변환해준다.
회사에서 C#만 했다고 하면 많이 물어보는 질문이 컴파일러가 아닌 컴파일만 하게 된다.
clr .net 같은거 아직 안다뤘는데
C와 C++ / C#의 가장 큰 차이가 이 컴파일러의 유무
C#을 중간 언어가 필요하다.
왜 컴파일러가 없을까요? -> 컴파일 과정에 대한 전반적인 지식
유니티만 알고 네이티브 언어만 알면 깊이가 얕다.
그래서 컴파일러란 인터프리터 C계열이 갖고 있는 좋은 기능
서브툴 없이 바로 읽어서 진행 가능
그러나 변환 과정을 수행해야하기 때문에 무거워진다.
C++이 low language - 컴퓨터가 좋아하는것
C#은 high language - 사람이 좋아하는 것
컴파일과 인터프리터
오른쪽에 솔루션 탐색기라는 기능들이 모여 있는데
컴파일러의 기능
오타를 임의로 내면 빨간줄이 뜬다 = 돌려보지 않아도 오류
컴파일러의 한계점
오른쪽에 뭔가 기능을 하는 것들이 있는데
2진법으로 바꾸고 오다가 코드를 읽고 ;를 보면 내려가고
52라인에 오타가 발견되어(오류가 발생하면)
기억하고 아래로 내려간다.
그다음에 존재하는 모든 기능을 다 돌린 뒤에 오류를 표시한다
=> 안정성이 좋다 : 싹다 확인하고 오류 표시
<= 불필요한 작업을 수행한다.
유니티도 컴파일하는데 코드를 읽어들이는 과정을 하고 모델링이 불러와 지지 않으면 이미 오류 근데 스킬이 작성되어 있으면 스킬이 안 나가는 걸 프로그래머는 알고 있다.
근데 컴퓨터는 끝까지 돌려봐야 한다. 컴파일에 한 세월이 걸린다.
cf. 언어 문법 == 같다 != 같지 않다.
그래서 이런 컴파일러의 한계점 때문에 인터프리터 있다
인터프리터는 오류를 만나면 멈춘다.
그래서 엔진에는 컴파일러 대신 인터프리터와 컴파일의 구조로 이루어져있다.
컴파일 타임 VS 런 타임
컴파일 타임은 코드를 읽어들이는데 걸리는 시간
문제가 없으면 이제 실행
이 실행되는데 걸리는 시간이 런 타임
뭔가 행동을 하면 실시간으로 바뀌는 것들이 있다.
ex 캐릭터 생성시 1000골드의 고정값을 갖고 있다고 해보는데
행동 과정 중에 늘어나거나 줄 수 있다.
컴파일 중에는 이런 걸 알 수 없다.
유저가 행동 한 결과는 런 타임에 처리한다.
컴파일 때 컴파일러
런타임 때 인터프리터가 작용한다.
프로그래밍 기술 및 기법
절차 지향
구조적 프로그래밍
객체지향
컴포넌트 기반 프로그래밍프로그래밍 기술은 점차 발전해왔고 앞으로도 계속 발전해 나갈 것이다. 현재는 크게 4가지로 분류해서 파악 해두면 좋다.
네이티브 언어를 안 해두면 C#이 갖고 있는 태생적 문제인 절차지향과 구조적 프로그래밍이 약하다.
오류를 많이 고쳐보는 것이 경험치가 되어 코드를 작성하는데 도움이 된다.
엔진 안에서 나오는 오류는 포괄적이다.
그래서 추론해내는 기술을 익히면 좋다.
아직 코드를 배워본 적 없다. 평생을 걸쳐도 전부 다 알기란 불가능하다.
언어기 때문에 계속 발전하고 개정되기 때문에 계속 배워야한다.
그렇기 때문에 프로그래밍적 사고 = 논리가 있는지 추론이 가능한지가 프로그래머의 자질로 필요하다.
이런 처음보는 코드를 마주했을 때
C계열 언어기 때문에 # 명령 지시자가 있다.
include가 명령어 뒤에 있는것들이 내용
io 입출력
random 뭔지 몰라도 임의
string 문자열
이런식으로 추론 가능해야 한다.
그래서 아까 4가지 구분을 유추해보자
절차지향 - 순서적으로 읽겠다.
ex 수업 프로젝트 열고 위에서부터 아래로 내용을 작성한 과정
구조적 - C++ 함수 C# 메서드를 알아야 이해가 된다.
객체지향 C#은 바로 여기부터
뭔가 독립된 느낌의 객체들을 서로 보존해준다라는 느낌
컴포넌트 기반 프로그래밍
이것이 최신
절차 지향
롤로 치면 챔프가 150개 정도 있다고 치자
절차 지향으로 만들려면 150개의 챔프에 대한 스킬 정보 전부다 입력되어 있는 것
유지보수가 매우 힘들다 <= C언어의 방식이자 한계
구조적 프로그래밍
150개 챔프를 블록화해서 묶는다
{} 중괄호로 묶어서
무지성으로 늘여놓은 걸 그나마 구조화 한 것
이렇게 했을 때 장점 = 좁혀놓고 하나씩 볼 수 있다.
그래도 많다. 묶어만 놨을 뿐 라인이 줄어들 진 않는다.
그래서 C++ 객체지향이 파생
객체지향
게임이 시작되면 협곡에 애들이 모인다.
리스폰 되는 곳이 협곡 여기를 중점으로 애들을 모듈화 기능으로 묶어둔다
class란 키워드로 묶는다.
베인 전용 코딩 공간 정해주고 선택하면 뿌리고 선택 안되면 안 뿌리고
솔루션 탐색기에 각각의 폴더들이 각각의 챔프로 생각해볼 수 있다.
각각을 객체화 한 것
구조적<->객체지향
구조적 프로그래밍에서 {열리면 어디서 닫히는 지 가보자}
하나의 페이지 안에 여러개의 함수/메서드가 나열되어 있다.
그러나 객체지향에서는 각각 분리되어 얘가 모듈로 나눠져있다.
객체지향에서는 필요한 부분을 참조만 한다.
이걸 하는 거는 완벽한 이해가 아니라 본 수업 전에 봐둬라 느낌
위의 세개 정리
절차 지향은 가장 초기부터 사용된 기법으로 코드의 흐름에 따라 프로그래밍 하는 기술
요약하면 프로그램의 실행부터 종료까지의 흐름을 그대로 프로그래밍 한다.
편리하지만 정해진 흐름을 따라가기 때문에 구조적이지 못하고
코드가 여기저기 흩어져 있어 유지보수가 매우 어렵다는 단점이 있다.
구조적은 순차적 프로그래밍의 단점을 보완하기 위해 나온 방식으로 코드의 구조를 기능 단위로 묶는 방식을 뜻한다.
함수 지향 프로그래밍이라고 부르며 순차적 프로그래밍보다는 유지보수가 용이하다.
※이러한 기능들을 한데 묶어 모듈이라는 형태로 만들게 되고 이는 프로그래밍 라이브러리의 형태로 발전하게 된다.
객체지향은 위의 두 방식과는 전혀 다른 방식으로 코드의 기준을 객체라는 단위로 묶어 프로그래밍 하는 기법을 의미한다.
모든 대상에는 속성과 메서드가 있고 이를 하나로 묶어 객체로 만드는 방식이며 여기에서 말하는 대상에는 눈에 보이지 않는 것도 포함이 된다.
객체 지향에는 4대 특징과 5대 설계 원칙이 있다.
—-
컴포넌트 기반
들어가기 전에
처음 배울때 착각하기 쉬운게 12를 안쓰고 3번을 쓴다 생각하는데
3번 안에 1번과 2번이 포함되어 있는 것이다.
순차적으로 읽고 구조적으로 묶어 놓는다.
이걸 퉁쳐서 객체가 되는 것
객체지향이 아무리 좋더라도 갖고 있는 한계점이 분명하다.
절단이 발생했을 때 잘린 팔을 어디로 가는가
팔이 떨어진 원래 객체는 원형인가 아닌가
처음에 붙어 있다는 가정을 하고 설계 했는데
그리고 플레이어도 팔이 잘릴 수도 있다.
객체가 존재한 상태에서 부품만 바뀌는데 객체 지향에서는 머리부터 발끝까지 통으로 객체이다.
여기에 의수나 기계팔을 달아주면 처음에는 고려되지 않은 대상이다.
이러니까 의수를 달았을 때 의수를 단 캐릭터/기계팔이 달린 캐릭터/안 달린 캐릭터/안짤린 캐릭터 이렇게 각각이 필요하게 된다.
그래서 객체를 부분별로 컴포넌트화 시켜서 교체가 가능하도록 한 것이 컴포넌트 기반 프로그램으로 유니티에서 강력하게 밀고 있는 부분이다.
점프를 하는 특성이 있는데 다리가 부러져서 못 뛰게 되면 그 컴포넌트를 뽑아버리는 느낌, 무기에 참 박는 느낌이다
캐릭터에 날개를 단다 생각하면 인간형 캐릭터는 처음에는 그를 고려하지 않고 설계된다. 이때, 날개가 컴포넌트고 붙였다 뗐다 가능하다.
근데 객체 지향에서는 날개를 달고 있는 캐릭터 하나의 객체가 따로 필요하다. 이러면 객체의 상태값이 늘어난다.
컴포넌트 기반 프로그래밍은 비교적 최근에 등장한 개념이며 코딩의 기준을 객체가 아닌 컴포넌트 단위로 프로그래밍 하는 방식 (유니티가 추구하는 방식)
객체 지향 프로그래밍이 사람이라는 객체를 단위로 프로그래밍 한다면 컴포넌트 방식은 사람이 가지고 있는 컴포넌트 즉, 다리, 팔, 머리 등의 부품으로 세분화하여 코딩한다.
각각의 컴포넌트는 독립적으로 움직이는 부품과 같으므로 다리를 떼서 동물에게 붙여주면 걷거나 달리는 것이 가능하게 되며 앞으로 배우게 될 유니티에서 추구하는 방식이라고 할 수 있다.
다양한 많은 컴포넌트가 있고 이곳을 추가하는 것만으로 원하는 기능을 간단하게 구현할 수 있다.
