배우로서의 스프라이트

저는 게임 개발 질문에 경험이 없지만 프로그래머입니다. 스칼라 언어에서는 액터로 확장 가능한 멀티 태스킹을 할 수 있습니다. 심지어 수십만 대의 문제없이 한 번에 실행할 수 있습니다.

그래서 나는 이것을 2D-Sprites의 기본 클래스로 사용하여 모든 스프라이트를 통과하고 이동시키는 데 필요한 게임 루프에서 벗어날 수 있다고 생각했습니다. 기본적으로 이벤트 중심으로 움직입니다.

게임에 이치에 맞습니까? 그렇게 멀티 태스킹을 했습니까? 결국 JVM에서 실행되지만 요즘 큰 문제는 아닙니다.

편집하다:

잠시 동안 손을 대고 난 후,이 아이디어에는 Multicore Support라는 단 하나의 실질적인 이점이 있음을 알게되었습니다. 간단한 게임 루프는 하나의 코어에서만 실행되며 모든 것을 순차적으로 수행합니다.

현대 컴퓨터는 심지어 집에서도 오늘날 두 개 이상의 코어가 내장되어 있기 때문에 게임 프로그래머가 다른 코어를 효율적으로 사용할 수있게하는 것이 좋습니다. 결국, 나는 보통 플레이어가 자신의 8 코어 머신에서만 게임을 실행한다고 생각합니다.

내가 보는 또 다른 장점은 Scala에서을 가질 수 있다는 것입니다 RemoteActors. 이는 동일한 방식으로 처리되지만 다른 컴퓨터에서 실행될 수 있습니다. 따라서 이것은 네트워크 게임을 단순화 할 수도 있습니다.

가능한 빨리 스칼라 2D 엔진에 구축하려고합니다.

나는 시도하지 않았지만 스칼라 프로그래머이며 이것이 최선의 방법은 아니라고 말할 것입니다. 스프라이트는 동 기적으로 애니메이션되어야합니다. 액터는 자신이 공정하게 실행될 것이라는 보장이 없습니다. 따라서 일부 스프라이트는 다른 스프라이트보다 빠를 수 있습니다. 장벽을 사용하여 동기화 할 수는 있지만 배우를 사용하는 이유는 무엇입니까? 메시지 전달에만 의존하는 경우 이러한 종류의 동기화 구현 (1000 명 이상의 행위자에 대한 장벽 구현)은 과도합니다.

또 다른 문제는-메시지 전달을 위해 무엇을 사용 하시겠습니까? 의사 소통을하려면 스프라이트가 필요합니까? 마스터 액터가 메시지를 보내 각 스프라이트가 다음 프레임으로 이동하도록 지시 할 수 있지만 성능 측면에서 볼 때 메소드를 직접 호출하고 스프라이트 세트를 반복하는 것보다 크기와 크기가 더 큽니다.

여기에 필요한 것은 일종의 매우 가벼운 멀티 태스킹이며 메시지가 전혀 전달되지 않는 것 같습니다. 공정성을 보장하는 자신의 배우와 같은 구현으로 롤링하는 것이 아마도 이것을 보장하려면 갈 수있는 가장 좋은 방법 일 것입니다. 그러나 너무 적은 이익을 얻으려면 너무 많은 작업입니다. 살펴보아야 할 또 다른 것은 기능적 반응성 프로그래밍이며 scala.react, 이것이이 사용 사례에 더 적합하다고 생각합니다.

Scala에서 2D 아이소 메트릭 게임 엔진을 구현했습니다. 애니메이션 한 눈에 보이는 스프라이트를 업데이트하기 위해 하나의 글로벌 액터 만 사용했습니다.

액터를 사용하여 게임 로직을 구현할 수 있습니다. 예를 들어 게임 맵의 다른 부분에 대한 계산을 다른 액터에 분산시켜 게임 상태를 병렬로 업데이트하고 성능을 향상시킬 수 있습니다. 게임 오브젝트 당 단일 액터를 사용하지 않고 지역별 액터를 사용합니다. 너무 세분화하면 성능이 저하됩니다.

그래도 내가 너라면 어떻게되는지보기 위해 시도해 보겠다.

그래서 나는 이것을 2D-Sprites의 기본 클래스로 사용하여 모든 스프라이트를 통과하고 이동시키는 데 필요한 게임 루프에서 벗어날 수 있다고 생각했습니다. 기본적으로 이벤트 중심으로 움직입니다.

그들을 움직이는 사건은 무엇입니까?

프레임 당 한 번 방출되는 이벤트입니까?

그렇다면 어떻게 이것이 실질적인 방식으로 시스템을 변화 시켰습니까?

원래 C ++의 맥락에서 객체 지향을 연구 할 때 일부 사람들은 xyz.doThis(x)'doThis 메시지를 xyz (페이로드 x)로 전송하고 즉각적인 응답을 기다리는 것' 과 같은 문장을 생각하는 것을 좋아한다는 것을 알게되었습니다 . 이 수준에서 볼 때 이벤트 또는 메시지 기반 시스템과 일반적인 절차 시스템 사이에는 본질적인 차이가 없습니다.

게임 오브젝트 업데이트에 대한 멋진 접근 방식입니다. 나는 스칼라를 모른다. 그러나 나는 그것을 주사하고 그것이 어떻게 나오는지보고, 결과를 더 잘 게시한다고 말한다!

내 마음에 떠오르는 주요 질문은 다음과 같습니다. 일부 게임 개체가 다른 게임 개체보다 얼마나 자주 업데이트되는지 관리합니까? 렌더링 시스템이 1/60 초 / 30 초 / 24 초마다 프레임을 그릴 시간이 없도록 스프라이트 액터가 너무 많은주기를 소비하는 것에 대해 걱정할 필요가 있습니까?

고려해야 할 또 다른 사항은 이것이 일련의 매우 빠른 이벤트 순서에 의존하는 플레이어 대 AI 상호 작용의 해상도에 어떻게 영향을 미치는지입니다. 게임 유형에 따라 별 문제가되지 않을 수도 있습니다 .

글쎄, 나도 그다지 프로그래머는 아니지만 제안에 아무런 문제가 없다. 나는 배우를 개발하는 그런 방법을 생각조차하지 않았다.

IA는 매우 정확해야하기 때문에 의심의 여지가없는 행동을 피해야하므로 상당히 어려운 과제 일 수 있습니다.

스프라이트에 의해 게임 엔티티 를 의미 한다면 확실합니다.

게임 엔터티는 절대로 스스로를 그려서는 안됩니다. 위치와 방법을 설명하는 그래픽 핸들을 업데이트해야합니다. 렌더 시스템 또는 장면 그래프 또는 실제 드로잉을 수행하는 모든 것 하나의 그래픽 카드가 있으며 16ms마다 그래픽 카드를 동기화해야합니다. 이와 같은 설정은 분산 비동기 처리에 적합하지 않습니다.

렌더 시스템은 하나의 액터 여야합니다 (혹은 까다로운 커플 일 수도 있습니다). 게임 개체가 그래픽 핸들을 업데이트하면 렌더링 시스템에 메시지를 보냅니다. 렌더 시스템은 배치 렌더링, 오 클루 전, 물리 지터 스무딩 등과 같은 모든 종류의 결정 및 / 또는 최적화를 수행 할 수 있습니다.

저는 스칼라 개발자는 아니지만 Erlang으로 많은 일을했습니다. 스칼라 용어 중 일부가 틀리면 용서해주세요.