Object-Oriented Programming 1 with Game Programming

SYiee·2023년 1월 1일
1

게임엔진

목록 보기
3/5

💁‍♀️ Introduction

게임 프로그래밍과 관련된 OOP는 크게 두 개의 챕터로 나누어져 있습니다! OOP의 여러 요소에 대해 간략하게 학습하고 게임 프로그래밍과 게임 산업에 대입하여 살펴봅니다.

Programming Language for Game

  • 게임업계에서 주류 언어는 c++이다.

Low-level languages

→ 원래는 어셈블리어가 로우레벨이었지만 요즘은 c++로 로우레벨 취급

  • 컴퓨터 명령어 집합(instruction set)의 abstraction을 거의 제공하지 않는다.
  • 엔지니어가 메모리 관리를 직접해주어야 한다

High-level languages

  • 강한 abstraction제공해서 원하는 일을 하는데 집중하도록
  • 영어로 코딩
  • computing system에 중요한 부분들을 자동으로 해준다.
    → 메모리 관리, garbage collection(Java, c#) - 메모리 할당을 했을 때 그냥 내맘대로 지워버리는 애들, 직접 할당하고 삭제하면 이거 아님.

Python

  • 유행하는 언어~ why?
    • Deep learning이 유행해서
    • 배우기 쉬워서 - 코딩을 하지 않는 사람들에게 넘 좋아
  • 높은 유연성과 가독성

Go

  • memory safety, garbage collection, and structural typing
  • structural typing
    → 구조체 쓸 때

The advantage of C++ over other languages are as follows[C++]:

  1. deterministic 하다
    → 코드를 여러번 반복해서 돌렸을 때 같은 결과를 낸다.
    • python garbage collection - 어떤 임의의 시간에 당신이 변수를 쓰고 있지 않으니 지우겠어요. 임의의 → 돌릴때마다 다름. 버그가 나는데 일정 확률로 버그 발생. deterministic 언어를 쓰면 모든 버그가 확률적인 버그가 됨.
  2. high performance 제공
    → 퍼포먼스가 매출, 유저의 불만으로 이어짐.
  1. 밑으로 내려가서 고칠 수 있는게 많음
    python 구조, 메모리 관리가 불가하지만 c++을 가능

📌 Python vs C++

Python

  • 장점 ) 배우기 쉽고 라이블러리 쉽게 접근 가능 굉장히 많은 커뮤니티에서 의견을 나눈다.
  • 단점) 느리다, 타입이 정해져있지 않고

C++

  • 장) 속도가 빠르고 미리 컴파일이 되기 때문에 빠르게 돌릴 수 있다. Typed, Modern professional libraries(지금도 논의되고 바뀌고 있다)
  • 단) 배우기 어렵다. 라이브러리 가져다 쓰기 어렵다

OOP

Classes and objects

  • Class : a collection of attributes (data) and behaviors (code)

ex) Plater Character Name이라는 클래스를 만들고 int player id, string name 등의 변수가 있고 클래스에 인스턴스가 존재. 플레이어 a,b,c가 있는데 모두 같은 클래스의 인스턴스.

ex) 학생클래스, 각각의 인스턴스는 이름도 다르고 학년도 다르고~

Encapsulation

  • Encapsulation : an object presents only a limited interface to the outside world; the object’s internal state and implementation details are kept hidden.

  • 인스턴스의 입장에서 나한테 접근할수 있는 권한을 제한

  • public : 모두가 나에게 접근 가능

  • private : 접근 불가 → 다른 방법으로 접근해야함.

    • 코드의 유지 보수 측면에서도 좋음
    • 협업을 할 때 함부로 접근해서 바꾸지 못하도록

Inheritance

  • shape을 상속받아 circle, rectagle, triangle을 만듬.

  • 삼각형 육각형을 따로 클래스를 만드는 것보다 shaped을 상속받아 만들면 나중에 코딩적으로 이득이 되는 경우가 있다.

  • 이미 존재하는 클래스의 확정성을 제시

  • parent class = base class or superclass

  • class child = derived class or subclass

Multiple Inheritance

  • 유지 보수가 힘들어지고 코드가 꼬일 수 있어서 많이 안 사용한다.
  • 멀티플 상속이 가능. 속성을 여러개 만들어두고 도형 클래스 상속 + 그릴수 있는 오브젝트 클래스 상속
  • 어디서 상속을 받았는지 모르게된다.

  • 그래서 대부분 c++ 개발자는 Multiple Inheritance 개발을 피하거나 굉장히 제한적인 형태로 사용

Mixin

  • 가끔 사용
  • 부모 클래스처럼 작동하면서 기능들을 제공
  • 믹스인 클래스 애니메이트만 따로 쓸 수 있게 함
    → 특정한 형태의 함수만 추가하고 싶다거나 뭔가만 가져다가 쓰고 싶을 때
  • 왜 사용할까?
    • 좀 많이 쓰이는 클래스에 있는 함수를 가져닥 써야할 때 할 때마다 정의해주기가 좀 그래서 mixin 형태로 만듬
    • 코드 재사용을 할 수 있게 만들어줌
    • 일반 상속을 받으면 Multiple Inheritance 문제가 발생하기 때문에 Mixin을 사용해서 Parent 클래스로부터 모든 것을 받아오는 것이 아닌 필요한 것만 가지고 온다.
      그냥 상속 : 다 가져다 씀
      Mixin : 특정 함수만 가져다 씀

Polymorphism

  • 다른 종류의 코드, 오븍제츠 구현할 때 하나의 공통된 인터페이스를 사용해 구현할 때 Polymorphism 지원

1번 방식 - switch

원래는 for문을 돌면서 하나씩 circle일때 draw, rectangle일 때 draw,… 이렇게 써주어야 했는데 ..

💣 문제점

  • shape의 종류를 다 알아야 한다.
    → 다른 프로그래머가 와서 육각형을 그리려면 코드에 들어가서 circle, rectangle, triangle 다 있는지 확인하고 맨 밑에 육각형을 추가해주어야 한다. switch 가 커지면 커질수록 문제가 됨.
    새로운 코더가 왔을 때 코드를 다 알아야 한다.
  • 이런식으로 짜면 간단은 하지만 code의 사이즈가 커지고 복잡도도 높아진다. 새로운 타입 시스템을 하나 추가하는 것 자체가 굉장히 힘듬
    ex) 옵치 1 엔진 코드가 rpg 게임이어서 확장성이 너무 떨어졌다. 캐릭터 하나 추가하는데 너무 힘들었다.
  • 새 shape 가 하나 추가되면 그게 등장하는 모든 곳에 가서 수정을 해주어야 한다.

✨ 해결책 Polymorphism - 2번 방식
이렇게 할 필요 없이 for문에 pShape→Draw 하나만 해주면 된다.

  • 대부분의 코드를 잘 몰라도 되는 쪽으로 바꿈
  • 비록 트라이앵글, 서클, … 모두 다른 애들이지만s shape 상속 받아서 만들어진 것이기 때문에 shape 제공하는 인터페이스로 핸들링이 가능하고 draw 함수를 사용할 수 있다.
  • virtual function
    • 함수이름을 만들어 두고 나머진 만들지 않고 설명은 인터페이스에 사용함 이렇게 씀
    • 다형성을 위해 씀
    • 각각의 세부 구현을 함
    • 원을 그리고 세모를 그리고 이건 각자 함수 안에서 구현을 하되, 그려라는 이것들을 실행하는 draw 명령어는 통일함

Composition and Aggregation

  • Composition : 복잡한 것을 간단한 거에서 가져오는 것이다.
    → 소유한 오브젝트의 life tim을 책임진다.
    "나 & 내 팔"의 관계
    : 내가 죽으면 내 팔도 ㅜㅜ 안뇽...
    “I own an object and I am responsible for its lifetime.”
  • Aggregation : 레퍼런스를 통해 다른 클래스를 정의
    → rec을 외부에서 받아오기 때문에 내가 죽어도 이것의 life time은 책임지지 않는다.
    "나 & 내 시계"의 관계
    : 내가 죽어도 내 시계는 멀쩡
    “I have an object which I’ve borrowed from someone else. When I die, the object may live on.”

Design Patterns

  • 옛날에는 붐이었는데, 사람들이 예쁜 예술적인 코드에 집중해서 오히려 더 유지보수 비용이 늘어나 실전에서 안 좋다는 것이 퍼졌는데.. 살아남은 것이 싱글톤
  • 같은 문제가 발생을 많이 하는데 이러한 문제가 있을 때 이게 정답이야 해서 묶어둔 것을 말한다.

Singleton

  • 정보가 반복되어서 글로벌 하게 다루었으면 좋겠어.
    게임 옵션을 싱글톤으로 제작, 옵션은 게임하다가도 시작화면에서도 계속 얻어오려고 한다. 이 클래스의 코드에서 싱글톤이 있으면 어딘가에 static으로 큰 애가 있어서 부르면 필요한거 준다.
  • 적당히 해야하는데 다 때려 넣으면 안 좋아질 수도 있다…..

OOP Example in the Field

weapon 클래스를 상속받아 sword, spear, …을 만든다

  1. weapon 의 종류가 무엇이 있는지 외부에서 몰라도 된다.
  2. game logic을 신경쓰지 않고 만들 수 있다. 그냥 weapon의 damage, durability 변수를 채우면 된다.

🖇 Reference

해당 포스트는 강형엽 교수님게임엔진기초 [GameEngine-22-2] 수업을 수강하고 정리한 내용입니다. 잘못된 내용이 있다면 댓글로 알려주시면 감사하겠습니다😊

profile
게임 개발자

0개의 댓글