센로그
3. Object-oriented programming (1) 본문
◆ Programming Language for Game
절차지향인 경우, 게임으로 가면 문제가 많아짐
하나 바꿀려면 그거 관련해서 다른거에 영향주는 거 다 찾아서 바꿔야 함
객체지향은 그거 하나만 바꾸면 되니까 굿
◆ low-level language vs high-level languange
- low-level language
어셈블리어, 기계어
직접 메모리 관리 해줘야 함 - high-level language
Python, C++, JAVA, ...
자동으로 garbage collection 지원
◆ 왜 하필 C++이 게임에서 젤 많이 쓰일까?
Deterministic
이 프로그램이 어떻게 실행될 지 "정해져 있다"
C++는 스테이지 1 보스 나중에 더 안쓸거면, 명시적으로 메모리를 해제함
얘 다 썼으니까 메모리 죽여~ 이렇게.
반면 Python, 자바는 명시적으로 메모리를 죽이지 않음
걍 어느 순간에 자동으로, 어? 메모리 영역이 더 이상 접근 안일어나네? 그럼 내가 지워야지~ 함
그런데 이 가비지 콜렉터가 언제 작동하는지는 우리가 알 수 없고, 일정하지도 않음. 그래서 디버그가 힘듦
속도도 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
동일한 유형의 문제가 반복적으로 발생하고 많은 다른 프로그래머들이 그 문제에 대해 매우 유사한 해결책을 사용할 때, 우리는 디자인 패턴이 발생했다고 말한다.
클래스가 하나의 인스턴스만 가지게 하고, 이것을 어디서든 접근가능하게 만드는 것.
게임 옵션, 스테이지 등의 파라미터 세팅할 때 사용
Static 따위를 활용해 구현
'게임 > 게임 엔진 기초' 카테고리의 다른 글
6. Game Engine Support System (2) (0) | 2022.12.08 |
---|---|
5. Game Engine Support System (1) (1) | 2022.12.08 |
4. Object-oriented programming (2) (0) | 2022.12.07 |
2. Game Engine Architecture (2) (1) | 2022.12.07 |
1. Game Engine Architecture (1) (1) | 2022.12.07 |