오브젝트 지향은 게임 만들기에 향하지 않는다 그 5

1: htps : // 이 m / ma s-o / / ms / 43101d2에 5에 f073 a 1f3f5
그 2 : htps : // 이 m / ma s-o / / ms / f802b5 a 6 a 6b3f47 예 d71
그 3 : htps : // 이 m / ma s-o / / ms / cd0d fu 3348 A98b24
4: htps : // m / ma s-o / / ms / c10 네 3c8939 어 d6 어 c71

전회는, ECS로 설계한 내려다 보이는 형 액션 게임의 토대에, 「하늘을 날리는 적」을 추가로 실장한다고 하는 것을 상정해, 설계를 생각해 보았습니다.



이와 같이, MoveAttribute 컴퍼넌트를 추가하는 것으로, 하늘을 날리는 상태를 표현한 것이었습니다.

그런데, 다음에, 「깃털의 아이템을 사용하면 플레이어는 하늘을 날 수 있게 한다」 이것을 설계해 봅시다.

UseItem 구성 요소, MoveAttribute 시스템

우선 새로운 컴퍼넌트로서 아이템의 사용 상태를 가지는 UseItem 컴퍼넌트를 생각합니다.
아이템을 사용한다는 것은 일반적으로 플레이어의 입력에 의해 결정됩니다만, 여기서는 상세는 생략합니다.

이번 사양에서는, UseItem 에 의존해 MoveAttribute 가 바뀌면 OK, 라고 하는 것이군요.
따라서 MoveAttribute 시스템을 추가하고 UseItem 를 참조하도록 합니다.


MoveAttribute 업데이트는 MoveAttribute 시스템에서 담당합니다.

지난 번 (자세한 내용은 생략했지만), MoveAttribute는 어떤 마스터 데이터를 참조하여 적이 "하늘을 날지, 땅을 걷는지"를 결정한다고 가정했습니다.

이번에는 게다가 UseItem 가 「날개 아이템을 사용한다」라고 하는 상태였을 때에 MoveAttribute 를 「비행」으로 설정합니다.

이와 같이, 당초는 정적인 정보에 의해 결정되는 거동이, 동적인 것으로 바뀌었다고 해도, 큰 영향 없이, 구현을 할 수 있습니다.

객체 지향 설계와 비교하면 어떻습니까?

그 1 그리고 객체 지향으로 설계했을 때, 「하늘을 날리는」지 어떤지는 클래스에 의해 정해져 있었습니다. 따라서, 나중에 동적으로 하늘을 날 수 있게 되는 기능이 필요했을 때에, 곤란해 버렸네요.

이번에는 ECS의 설계로 잘 피할 수 있습니다.

요약

이상, 전 5회에 걸쳐, 오브젝트 지향에 의한 설계의 단점과, 그것을 ECS에 의해 어떻게 극복할 수 있을까에 대해, 봐 왔습니다.
프로그래밍을 배울 때, 많은 분들은, 수속형으로부터, 오브젝트 지향과 배워 왔다고 생각합니다.

오브젝트 지향에 의한 설계는, 현실 세계에 맞추어 생각하기 때문에 알기 쉽습니다만, 한 번 설계한 클래스를 나중에 간단하게는 바꿀 수 없기 때문에, 항상 사양 변경·기능 추가를 반복하는 게임의 프로그래밍에는, 맞지 않는 면 또한 있습니다.

거기에 데이터 지향 설계(=Entity Component System)가 주목받고 있는 이유도 있습니다.
ECS에 의한 유연하고 버그가 생기기 어려운 프로그램 설계를 해, 모두 행복하게 합시다.

ECS로 게임을 만들면 어떤 느낌이 되는지,
htps : // 기주 b. 코 m / 마 s - 요 / 루 st - cs -
여기에서 실험하고 있습니다. (언어는 Rust입니다)
흥미가 있는 분은 봐 주세요.