우리가 이동 구현을 이제 이렇게 했는데, 이것을 이렇게 하드 코딩해서

뭔가를, 사실 그 표현을 하지는 않죠.

사용을 그대로 하지는 않죠. 아까 우리가 이제 화면에서

그리는 이 네모 또한 이동을 시킬 때 뭘로 묻겠죠?

당연히 윈도우에서 얘가 이렇게 이동을

할 때, 이 친구 또한 하나의 객체로 만들어서 처리를 해 줘야 될 겁니다.

그래서 보시면, 게임 오브젝트라고 이렇게 클래스를 하나 설계를 해

놨습니다. 자, 게임 오브젝트라는 말이 뭘까요?

오브젝트가 사전을 검색해 보면, 자, 물체라고 나오는데,

딱히 이렇게 해서 와닿는 것보다는

보통 저는 이제 이미지로 검색을 많이 하거든요. 이미지로 검색하시면 정확히

이제 제 몸에 와닿습니다. 요런 것들을 이제 우리가

얘기하는 거죠. 이런 것들, 나무가 되기도 하고, 버섯이

되기도 하고, 이렇게 복숭아가 되기도 하고. 그래서 게임

오브젝트라고 지었죠. 게임에서 뭔가 화면에 나오는

이런 친구들을 전부 다 게임 오브젝트라고 하는

거거든요. 그래서 오브젝트라고 이제 우리가 표현을

하니까 지금 보면 여기 공이 있고요, 그리고 뭐

벽도 있고, 동전도 있고, 글씨도 있죠.

이런 게 이제 다 하나의 게임 오브젝트가 될 수 있는 겁니다.

게임에서 꼭 배치돼 있는 그런 움직이는 애들뿐만 아니라, 이런

UI 조차도 하나의 오브젝트가 될 수 있는

거예요. 근데 그러면 이렇게 눈에

보이는 것만 생각할 수도 있는데, 사실 게임에서는 이 게임에 아마

이렇게 캐릭터가 움직이면 이 친구가

계속 이렇게 생성이 되면서 내쪽으로 올

겁니다. 그러면은 이 동전과 벽을 생성해 주는 이쪽 화면에 보이지 않는

클래스나 객체들이 있을 거란 말이에요. 오브젝트들이, 뭐 예를 들어서

스폰 매니저 이런 걸 만들었다고 합시다. 1초에 벽을 하나씩 랜덤하게

생성을 해 주네요. 이 친구도 게임 오브젝트가 될

수 있는 거예요. 눈에 보이지 않는 애도 오브젝트가 될 수 있는 겁니다. 그래서

게임 오브젝트라고 우리가 클래스를 설계했는데,

이 친구는 어떻게 사용이 될 거냐? 게임에서

객체를 표현할 수 있는 실제 메모리를 할당해서 뭔가

데이터를 표현하죠. 액체를 표현할

수 있는, 표현 가능한 모든 것은 오브젝트가 될 수

있어요. 자, 그래서요. 오브젝트, 우리가 이

오브젝트를 많이 만들어서 설계하고 서로 간의 데이터를 주거니

받거니 하면서 프로그래밍하는 방식을 객체지향 프로그래밍이라고

얘기합니다. 객체지향 프로그래밍, 오브젝트

오리엔티드 프로그래밍이라고 얘기를

하죠. 근데 이 객체지향 프로그래밍을

설계할 때 대부분 이제 많이, 조금 착각하는 부분들이 있거든요. 액체라고

하니까 실제 현실에서 일어나는 일을 객체처럼 클래스로 설계해서

내가 데이터를 주고받으며 처리하는데, 여러

객체 간에 내 생각이, 저 객체 지향 설계를 할

때 객체 지향 설계할 때 어떻게 하냐 그

실제 객체에 가두었습니다. 이게 무슨 말이냐? 예를

들어서, 자 콜라가 있다고 생각을 해 볼게요. 콜라 객체를 하나 만들었어요.

Coke, 그 클래스.  Coke 클래스가 있고, 클래스, 여기 뭐야, People이

있어요. 콜라 객체를 하나 만들었습니다. NewCoke 해 가지고 New Coke가

있어요. 콜라는 요만큼 들어 있어요. 자, 그리고 사람이 하나 있어요.

로 만든 거. 자, 그럼 우리가 객체 지향 설계를 한다면 대부분의 사람들은 요렇게

설계를 할 겁니다. 콜라를 마시는 걸 이제 구현을

한다. void drinkCoke(Coke coke). 이거 그대로 넘기면 복사가

일어나니까 원본이 사라지잖아요. 포인터나

레퍼런스로 이렇게. 바이 안에서 뭐야,

이렇게. 여기 amount라는 변수가 있는 거죠. 자, 요게 이제 우리가 봤을 때

의 통상적인 객체 프로그램입니다. 왜 콜라를

일반적으로 우리 일반적인 환경에서 콜라를 누가 마셔요? 사람이 콜라를

마셔요. 콜라를 이렇게 받아 가지고, 요게

맞아요. 근데 이 프로그래밍에서는 더 자율성이 주어져요.

현실 세계에 우리가 굳이 묶여서 생각을

할 필요가 없는 겁니다. 만약에 이렇게 계속 구현이 되면

이 콜라의 양을 직접 여기에 접근을

해서 그렇죠. 값을 줄이고 있거든요. 지금은 어마운트뿐이지만, 뭐

콜라를 한 번 마실 때마다 콜라 온도도

줄어들고, 콜라의 양이 줄기 때문에 값어치도 막

줄어들어요. 가격(Price), 이런 것들이 이제 계속

그 점(degree), 마이너스 뭐 1°C,  보크 점...

Price 마이너스, 여기 뭐야, 얘는 막

가격을 하나, 조금 마실수록 감소가

더 팍팍 들어갑니다. 뭐 2에다가 여기 뭐 제곱근 n, 뭐 이렇게 해서

계산을 해요. 음, 그럼 내가 이 드링크 관련된 거

뭐 동작을 하나가 여기에 추가될 때마다

여기 내가 변수를 추가를 해요. 그죠? 그러면 이쪽 함수도

찾아서 고쳐 줘야 되거든요. 계속 새로 추가될 수 있잖아요.

그 이쪽 함수도 찾아서 계속 고쳐 줘야 되고, 드링크뿐만 아니라 저기

우리 집 고양이도 콜라를 마셔요.

드링크 호크. 그러면 여기도 또 찾아서 다

고쳐 줘야 돼요. 그러면은 객체지향을 사용하고 있지만, 뭔가

우리가 이 데이터가 변할 때마다 영향을 받는 부분들이 굉장히

많아지죠. 이쪽도 영향을 받고, 이쪽도

영향을 받습니다. 그래서 요거는 이제 기본적인

우리가 생각의 사고에서 조금 벗어나야 돼요. 어떻게 구현을

하냐? 이 콜라를 인자로 받지 않는 거예요.

여기 함수를 딱 바꿉니다. 그래서 특정 콜라를 받았다

내 콜라의 양을 줄이는 게 아니라, 호크 드링크를 구현해 줘요.

이렇게 호출만 해 주는 거야. 호출만. 그리고 여기도 호크 드링크를

호출만 해 줍니다. 그러면 이 안에 이제 우리가 드링크 함수를 구현을

하죠. 그래서 얘는 그냥 뭐냐, 자기

자신의 양을 어마운트 10만큼 줄이고,

디 그리는 1만큼 줄이고, 라이스도 뭐

2만큼 줄이고, 자기 자신을 자기가 줄여 버리는

거예요. 그러니까 무슨 느낌이냐 이런

느낌인 거예요. 야, 나 콜라 먹었어! 신호만 보내는 겁니다. 그래서

중간에 우리가 뭐 드링크를 이렇게

함수를 호출했다. 이 함수를 호출하는 클래스를 하나 둬서 얘를 이렇게 동작만 하게

만든다든지, 뭐 이벤트 타입, 또 뭐 그런 패턴들이 있죠. 옵저버 패턴, 뭐

객체지향에 대한 사실과 오해 (GameObject클래스)

어려운 게임 개발을 쉽게 배우는 방법!



얌얌코딩 (게임 개발)

게임 오브젝트 클래스 설계 및 개념 설명

하드 코딩된 이동 구현의 문제점과 객체지향적 해결 방안 제시

게임 오브젝트의 의미: 게임 화면에 나타나는 모든 요소 (공, 벽, 동전, UI 등)

눈에 보이지 않는 객체 (예: 스폰 매니저)도 게임 오브젝트로 포함

게임 오브젝트의 사용: 게임 내 객체 표현을 위한 메모리 할당 및 데이터 관리

객체지향 프로그래밍 개념과 오해

객체지향 프로그래밍 정의: 여러 객체 생성 및 데이터 교환을 통한 프로그래밍 방식

객체지향 설계 시의 흔한 오류: 현실 세계의 사건을 그대로 클래스로 구현하려는 시도

콜라 마시기 예시를 통한 잘못된 객체지향 설계 설명 (직접 데이터 접근)

개선된 객체지향 설계: 콜라 객체가 자체적으로 양을 줄이는 방식

객체지향 설계의 핵심 및 게임 오브젝트 클래스 개선

객체지향의 핵심: 객체가 자기 자신을 직접 처리하는 독립적인 동작 구현

게임 오브젝트 클래스 개선: 기존 값들을 클래스로 옮기고, get/set 함수 사용

get/set 함수 사용의 이점: 예외 처리 및 유지보수 용이성 증가

public 접근 제한자 대신 get/set 함수 사용 이유: 예외 처리 및 버그 수정 용이성

코드 수정: 게임 오브젝트 클래스 내 업데이트 및 렌더링 함수로 코드 이전

객체지향에 대한 사실과 오해 (GameObject클래스)

객체지향에 대한 사실과 오해 (GameObject클래스)

스크립트