Спрайт як актори

Я не досвідчений з питань розвитку ігор, але як програміст. Мовою Scala, ви можете мати масштабну багатозадачність з "Акторами", дуже стабільну, як я чую. Ви навіть можете без проблем працювати сотні тисяч.

Тому я подумав, можливо, ви можете використовувати їх як базовий клас для 2D-Sprites, щоб вийти з ігрового циклу, який вимагає пройти всі спрайти та перемістити їх. В основному вони рухаються самі, керовані подіями.

Чи має це сенс для гри? Маючи це багатозадачно? Зрештою, він працюватиме на JVM, хоча це не повинно бути великою проблемою в наш час.

Редагувати:

Помирившись на деякий час, я помітив, що існує лише одна реальна перевага цієї ідеї: підтримка багатоядерних. Простий цикл гри буде працювати лише на одному ядрі і працюватиме все послідовно.

Оскільки в сучасних комп’ютерах, навіть вдома, сьогодні є вбудовані два або більше ядер, я думаю, що це гарна ідея, щоб програмісти ігор могли ефективно використовувати інші ядра. Зрештою, я думаю, що зазвичай у гравця буде лише гра, яка працює на його восьмиядерній машині, так чому б і ні.

Інша перевага, яку я бачу, полягає в тому, що у Scala ви можете мати RemoteActors, до якого можна поводитись так само, але працювати на іншому комп’ютері. Тож, можливо, це може також спростити мережеві ігри.

Я маю намір вкласти це в свій двигун Scala 2D, як тільки можу.

Я не намагався, але я програміст Scala, і я б сказав, що це не найкращий підхід. Прайтів потрібно анімувати синхронно. Актори не мають гарантій, що вони будуть виконані справедливо - таким чином, деякі спрайти можуть бути швидшими за інших, а це не те, що ви хочете. Ви можете використовувати бар'єр для їх синхронізації, але тоді - навіщо використовувати акторів. Якщо ви покладаєтесь лише на передачу повідомлень, реалізація подібного роду синхронізації (впровадження бар'єру для 1000+ акторів) - це надлишок.

Інше питання - для чого б ви використовували передачу повідомлень? Вам потрібні спрати для спілкування? Ви можете надіслати повідомлення головного актора, сказавши кожному спрайту перейти до наступного кадру, але з точки зору продуктивності це величини та величини більше, ніж виклик методів безпосередньо та повторення через набір спрайтів.

Мені здається, що вам тут потрібна якась дуже легка багатозадачність, і жодне повідомлення не проходить. Роль у вашій власній акторській реалізації, яка забезпечує справедливість - це, мабуть, найкращий шлях, якщо ви хочете це зробити, але це занадто багато роботи для занадто малого виграшу. Інша річ, на яку слід звернути увагу, - це функціональне реактивне програмування, і scala.reactя вважаю, що це краща відповідність для цього випадку використання.

Я реалізував 2d ізометричний ігровий двигун у Scala. Я використовував лише 1 глобального актора для оновлення видимих ​​спрайтів, які були анімовані.

Можливо, ви хочете реалізувати свою логіку гри за допомогою акторів - наприклад, розподілити обчислення на різних частинах вашої ігрової карти різним акторам, щоб вони паралельно оновлювали стан гри - і отримували підвищення продуктивності. Я б не використовував жодного актора на кожен ігровий об’єкт, скоріше, актора на регіон. Якщо ви занадто дрібнозернисті, продуктивність страждає.

І все-таки, якби я був ти, я б спробував це, тільки щоб побачити, що відбувається.

Тому я подумав, можливо, ви можете використовувати їх як базовий клас для 2D-Sprites, щоб вийти з ігрового циклу, який вимагає пройти всі спрайти та перемістити їх. В основному вони рухаються самі, керовані подіями.

Якою була б подія, яка їх рухає?

Це буде подія, яку ви проводите один раз за кадр?

І якщо так, то як це змінило систему будь-яким практичним способом?

Первісно вивчаючи об'єктну орієнтацію в контексті C ++, я дізнався, що деяким людям подобається думати про таке твердження, як, наприклад xyz.doThis(x), значення "надіслати повідомлення doThis до xyz (з корисним навантаженням x) і чекати негайної відповіді". Якщо дивитися на цьому рівні, то між внутрішньою системою подій чи повідомлень та звичайною процедурною системою немає ніякої суттєвої різниці.

Це класний підхід до роздумів про оновлення ігрових об'єктів. Я не знаю, Скала, але я кажу, дайте це зйомки і подивіться, як це виходить, і ще краще опублікуйте свої результати!

Основні питання, які мені спадають на думку, такі: як ви керуєте тим, як часто деякі ігрові об’єкти оновлюються порівняно з іншими? Вам потрібно буде турбуватися про те, що актори спрайту займають занадто багато циклів, щоб система рендерінгу не встигла намалювати рамку кожні 1/60-та | 30-та | 24-я секунди?

Інша річ, що слід врахувати, як це вплине на вирішення взаємодій гравця проти AI, які залежать від порядку послідовності дуже швидких подій. Залежно від типу гри, можливо , це не матиме великого значення.

Ну, я не такий вже й великий програміст, але я не бачу жодної проблеми у вашій пропозиції. Я навіть не думав про такий спосіб розвитку акторів.

Це може бути досить складною проблемою, оскільки ІА має бути дуже точним, щоб уникнути несподіваної поведінки, але крім цього я бачу, що це досить гарна пропозиція

Якщо під спрайтом ви маєте на увазі ігрову сутність, то обов'язково.

Ігрові утворення ніколи не повинні малювати себе. Вони повинні оновити графічну ручку, яка описує, де і як їх потрібно намалювати. Система візуалізації або графік сцени або все, що робить фактичний малюнок. Є одна графічна карта, крім того, що відеокарта повинна синхронізуватися кожні 16 мс. Такий набір просто не працює добре для розподіленої асинхронної обробки.

У системі візуалізації повинен бути один актор (або, можливо, пара, якщо ви хитрі). Коли ігрові особи оновлюють графічну ручку, вона надсилає повідомлення в систему візуалізації. Система візуалізації, чи може вони приймати всілякі рішення та / або оптимізації, наприклад, пакетне візуалізація, оклюзія, згладжування фізичного тремтіння тощо.

Я не розробник Scala, але я досить багато робив з Erlang. Тож якщо деякі мої терміни Scala є невірними, пробачте мене.