high-level language Python, C++, JAVA, ... 자동으로 garbage collection 지원
◆ 왜 하필 C++이 게임에서 젤 많이 쓰일까?
Deterministic
이 프로그램이 어떻게 실행될 지 "정해져 있다"
C++는 스테이지 1 보스 나중에 더 안쓸거면, 명시적으로 메모리를 해제함
얘 다 썼으니까 메모리 죽여~ 이렇게.
반면 Python, 자바는 명시적으로 메모리를 죽이지 않음
걍 어느 순간에 자동으로, 어? 메모리 영역이 더 이상 접근 안일어나네? 그럼 내가 지워야지~ 함
그런데 이 가비지콜렉터가 언제 작동하는지는 우리가 알 수 없고, 일정하지도 않음. 그래서 디버그가 힘듦
→ 게임프로그래밍에선 완전히 컨트롤 가능한C++를 더 선호!
속도도 C++이 파이썬보다 훨빠름~
C++은 직접 메모리, 스레드, 스토리지.. 등을 관리할 수 있다.
또 C++은 시장 규모도 커서, 문제 해결할 때 굿
◆ OOP Review
지금부터 게임 엔진에서 많이 사용되는 OOP 개념들 Review 해볼 것임.
▶ Encapsulation (캡슐화)
불필요한 것들을 알 필요없게 만들어주는 것
class 내 멤버들 관리할 때, private/protected/public
public 외부에서 접근 가능
protected 상속 받은 애들끼리만 접근 가능
private 내부에서만 사용 (외부엔 숨김)
이런 거 조정해서 Encapsulation 구현
▶ Inheritance (상속)
상속은 "is-a" 관계
circle은 shape의 한 종류이다.
circle is a type of shape
▶ Multiple Inheritance (다중 상속)
여러 부모를 동시에 상속받는 것
상속 구현시 주의해야 함.
어떤 언어들은 한 클래스가 여러 개의 부모를 가지는걸지원하기도 함
좋은 점도 있지만, 알수없는 문제들이 막 발생할 것임
트리 구조가 아니라 그래프 구조가 되는 것.
▷ Diamond problem
다중 상속에서 일어날 수 있는 문제점
object의 int a가 있는데, object를 상속한 rectangle과 clickable에도 각각 int a 가 있음. 이제 button에서 부모의 int a를 상속해서 갖고 와야 하는데, 이때 뭘 갖고올지 모름(모호함).
▷ Mixin Class
다중 상속의 특별한 경우. Functionality 를 갖다쓰는 것
- 패런트 클래스"처럼" 작동함
- 서브클래스가 이 functionality를 그대로 갖다씀
보통 상속에서는, “is a” relationship (: circle is a type of shape. Circle을shape처럼 사용 가능)을 가짐
근데mixin은“is a” relationship없이 사용이 가능하게 만들어 주는 것.
Shape를 상속받은circle이mixin클래스로 설계된animator기능도갖다쓰고 싶으면,갖다쓸 수 있음
근데 전부갖고오는게 아니고 내가쓰고싶은functionality만 따로 빼와서씀
부모를 여러 개가진것처럼보이지만,실제로 "is a"관계가 성립하진 않음
필요할 때만갖다쓸 수있게 해주는 것. (아마 이렇게 되면 Diamond Problem 안 생길듯)
▶ Polymorphism (다형성)
실행 시간에 Virtual table을 통해서 어느 클래스로 가야하는지 딱 찾아오는 거
하나의 통일된 인터페이스로 여러 개의 작업을 할 수 있게 만듦(클래스 종류별로)
즉, 같은 부모의 변수, 함수를 상속받았지만, 조금씩 다른 기능을 할수있게 하는 거
예를들어 같은 Attack이라도, “누가“ Attack하는지가 바뀌면 어떤 Attack이 될지가 바뀜
따라서 맨 위 부모 클래스에 순수 가상함수 만들어놓고 밑에서 받아서 가상함수로 쓰면 됨
(순수 가상함수: 실제로 구현은 안 되어있지만 상속받을 수 있게 하는 목적으로 만들어 놓은 것)
● 근데, if 문으로 구현할 수도 있지 않나? => 가능함. 그러나 어떤 Attack이 실행될 지 모르기 때문에, 실행될 수 있는 모든 Attack에 대해서 알고 있어야 한다는 단점.
ex) 케이스가 한 100개정도 있는데 새로운 애를 확장하려고 할 때! 여기에 이미 있는지 없는지, 어떤 형태로 구현되어 있는지…이런거 다 알아야함 특히 내가 만들지 않은 프로그램 확장하려면 엄청 힘듦 ㅠㅠ
▶ Composition and Aggregation
클래스에서 life time에 관련된 것
Composition은 "owns-a" Aggregation은 "has-a"
public class Window {//composition
private Rectangle rect = new Rectangle();
}
public class Window {//aggregation
private Rectangle rect;
void setRect(Rectangle rectParam) {
this.rect = rectParam;
}
}
Composition은 내가 죽으면 rect도 같이 사라짐
Aggregation은 rectParam만 받아와서 내 rect로 세팅해 준 것이므로, rect의 실체는 안 사라짐 (레퍼런스 형태)
▶ Design Pattern - Singleton
동일한 유형의 문제가 반복적으로 발생하고 많은 다른 프로그래머들이 그 문제에 대해 매우 유사한 해결책을 사용할 때, 우리는 디자인 패턴이 발생했다고 말한다.
