Як гра може обробити всіх персонажів одночасно?

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

Приклад

Я створюю гру в оборону вежі, в якій є 15 гнізд на башті, де будуються вежі, і кожна башта викидає снаряд з певною швидкістю; скажемо, що щосекунди по кожній з веж створюється 2 снаряди , а на поле битви йдуть вороги, скажімо 70 (у кожного з 10 видів атрибутів, таких як HP, Mana та ін.), які змінюватимуться, коли вони рухатимуться навколо поле бою).

Підсумок

Кількість башти = 15
снарядів, створених кожною вежею на секунду = 2
загальна кількість створених снарядів за секунду = 30
одиниць у кол. Поля бою = 70

Тепер, чи гра обробляє ці 30 снарядів і 70 одиниць , обробляючи їх на 100 різних нитках (що занадто багато для ПК) або 1 нитка, яка переміщує їх усіх, зменшує їх значення тощо (що буде неначе повільним) , Я думаю)?

Я не маю поняття про це, тому хтось може мене направити на те, як це вийде?

Тепер, як гра обробляє ці 30 снарядів і 70 одиниць, обробляючи їх на 100 різних нитках

Ні, ніколи цього не робіть. Ніколи не створюйте новий потік на ресурс, це не масштабує роботу в мережі, як і в оновленнях об'єктів. (Хтось пам’ятає часи, коли у вас була одна нитка для читання на сокет в Java?)

1 нитка, яка переміщує їх, зменшує їх значення тощо?

Так, для початку це шлях. "Великі двигуни" розділили деяку роботу між нитками, але це не потрібно для початку такої простої гри, як гра в оборону вежі. Мабуть, ще більше роботи, щоб зробити кожен галочку, яку ви також зробите в цій одній нитці. О так, і візуалізація звичайно.

(який буде повільним, я думаю)

Ну ... Яке ваше визначення повільного ? Для 100 організацій це не повинно зайняти більше половини мілісекунди, можливо, навіть менше, залежно від якості коду та мови, з якою ви працюєте. І навіть якщо на це знадобиться дві повних мілісекунди, все одно досить добре натиснути на 60 секунд (тик на секунду, не кажучи про кадри в цьому випадку).

Правило номер одне з багатопотокових читає таке: Не використовуйте його, якщо вам не потрібно паралелізувати декілька ядер процесора для продуктивності чи чутливості. Вимога "x і y має відбуватися одночасно з точки зору користувачів" ще не є достатнім приводом для використання багатопотокової.

Чому?

Багатопоточність - це важко. Ви не маєте контролю над виконанням кожної нитки, що може призвести до неможливості відтворення проблем ("умови перегону"). Існують методи уникнення цього (блокування синхронізації, критичні розділи), але вони мають свій набір проблем ("тупикові").

Зазвичай ігри, що мають справу з такою низькою кількістю об'єктів, як всього кілька сотень (так, це не так вже й багато в розробці ігор), як правило, обробляють їх послідовно, кожен логічний галочок, використовуючи загальний forцикл.

Навіть порівняно слабкіші процесори смартфонів можуть виконувати мільярди інструкцій в секунду. Це означає, що навіть коли логіка оновлення ваших об'єктів є складною і займає близько 1000 інструкцій на об'єкт і галочку, і ви прагнете отримати щедрі 100 кліщів в секунду, у вас є достатня ємність процесора для десятків тисяч об'єктів. Так, це значно спрощений розрахунок зворотної конверти, але це дає вам уявлення.

Також загальною мудрістю в розробці ігор є те, що логіка гри дуже рідко є вузьким місцем гри. Критична продуктивність - це майже завжди графіка. Так, навіть для 2d ігор.

Інші відповіді стосуються різьблення та потужності сучасних комп'ютерів. Однак для вирішення більшого питання, те, що ви намагаєтеся тут зробити, - це уникати ситуацій з "n квадратами".

Наприклад, якщо у вас 1000 снарядів і 1000 ворогів, наївним рішенням є просто перевірити їх усіх один проти одного.

Це означає, що ви закінчите з p * e = 1,000 * 1,000 = 1,000,000 різних перевірок! Це О (п ^ 2).

З іншого боку, якщо ви краще організуєте свої дані, ви зможете уникнути багато цього.

Наприклад, якщо ви перераховуєте на кожному квадраті сітки, які вороги знаходяться в цьому квадраті, ви можете перевести через 1000 снарядів і просто перевірити квадрат на сітці. Тепер вам просто потрібно перевірити кожен снаряд проти квадрата, це О (n). Замість мільйона чеків кожного кадру вам потрібно лише тисяча.

Думка про організацію ваших даних та їх ефективну обробку завдяки цій організації - це найбільша оптимізація, яку ви можете зробити.

Не створюйте потоки на ресурс / об'єкт, а на розділ логіки програми. Наприклад:

1. Нитка для оновлення одиниць і снарядів - логічна нитка
2. Нитка для візуалізації екрана - нитка GUI
3. Нитка для мережі (наприклад, мультиплеєр) - потік вводу-виводу

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

Навіть космічні загарбники управляли десятками взаємодіючих об'єктів. Тоді як декодування одного кадра відео H264 HD включає сотні мільйонів арифметичних операцій. У вас є багато потужності для обробки.

Однак, ви все ще можете зробити це повільним, якщо витратите його. Проблема полягає не стільки в кількості об’єктів, скільки в кількості проведених випробувань на зіткнення; простий підхід перевірки кожного об'єкта один проти одного квадратує кількість необхідних обчислень. Для тестування 1001 об’єкта для зіткнень таким чином знадобиться мільйон порівнянь. Часто це вирішується, наприклад, не перевіряючи снаряди на зіткнення один з одним.

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

Ваше запитання - хороший приклад логіки, який, мабуть, відокремлений, якщо ви можете додати додаткову логіку поверх нього. Наприклад, ви можете запустити кілька потоків виявлення звернень, або заблокувавши потоки у певних областях простору, або зафіксувавши прив'язку об'єктів, що займаються.

Ви, мабуть, НЕ хочете одного потоку для кожного можливого зіткнення, тільки тому, що це, ймовірно, зашкодить планувальник; також є вартість, пов’язана зі створенням та руйнуванням ниток. Краще зробити деяку кількість потоків навколо ядер системи (або використовувати метрику на зразок старої #cores * 2 + 4), а потім повторно використовувати їх, коли процес завершиться.

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

Більшість ігор не роблять цього просто тому, що це складніше, ніж середній розробник ігор готовий / вміє впоратися з тим, що зазвичай не є вузьким місцем в першу чергу. Переважна більшість ігор обмежена графічним процесором, а не процесором. Хоча підвищення швидкості процесора може допомогти в цілому, це зазвичай не фокус.

Однак, фізичні двигуни часто використовують декілька потоків, і я можу назвати декілька ігор, які, на мою думку, виграли б з декількох логічних потоків (наприклад, Paradox RTS-ігри, такі як HOI3 і такі, наприклад).

Я погоджуюся з іншими повідомленнями, що вам, мабуть, не доведеться використовувати нитки в цьому конкретному прикладі, навіть якщо це може бути корисним. Нитка повинна бути зарезервована у випадках, коли у вас надмірне завантаження процесора, яке неможливо оптимізувати за допомогою інших методів. Це величезне завдання і вплине на фундаментальну структуру двигуна; це не те, з чим можна братися за фактом.

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

Комп'ютер не обробляє відразу всі об'єкти в грі. Він обробляє їх послідовно.

Комп'ютерна гра просувається в дискретні часові кроки. Залежно від гри та швидкості роботи ПК, ці кроки, як правило, або 30, або 60 кроків в секунду, або стільки / кілька кроків, скільки ПК може обчислити.

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

Середній процесор повинен бути 2 ГГц або швидше, це означає 10 ⁹ тактових циклів в секунду. Якщо ми обчислимо 60 тимчасових кроків в секунду, що листи 10 ⁹ циклів / 60 тактів = 16666666 годин за час кроку. Маючи 70 одиниць, у нас залишається приблизно 2400 000 тактових циклів на одиницю. Якби нам довелося оптимізувати, ми могли б оновлювати кожну одиницю всього за 240 циклів, залежно від складності логіки гри. Як бачите, наш комп’ютер приблизно в 10000 разів швидше, ніж потрібно для цього завдання.

Відмова: Мій улюблений тип гри у всі часи - це текстовий текст, і я пишу це як давній програміст старого MUD.

Я думаю, що важливе питання, яке ви повинні задати собі, це таке: чи вам навіть потрібні нитки? Я розумію, що в графічній грі, мабуть, більше використовується MT, але я думаю, що це також залежить від механіки гри. (Можливо, варто також врахувати, що з графічними процесорами, процесорами та всіма іншими ресурсами, які ми сьогодні маємо, набагато сильніше, що робить ваші проблеми щодо ресурсів настільки ж проблемними, як вам може здатися; дійсно 100 об’єктів практично нульові). Це також залежить від того, як ви визначаєте "всіх символів відразу". Ви маєте на увазі точно в той самий час? У вас цього не буде, як справедливо вказує Петро, ​​так що все відразу не має значення в прямому сенсі; вона з'являється лише таким чином.

Якщо припустити, що ви підете з теми: Ви точно не повинні враховувати 100 потоків (і я навіть не збираюся вникати в те, чи занадто це для вашого процесора чи ні; я маю на увазі лише ускладнення та практичність цього).

Але пам’ятайте це: багатократна нарізка не є легкою (як вказує Філіпп) і має багато проблем. Інші мають набагато більше досвіду (на багато), ніж у мене з МТ, але я б сказав, що вони теж пропонують те саме (хоча б вони були більш здібними, ніж я - особливо без практики з мого боку).

Деякі стверджують, що вони не згодні з тим, що потоки не є корисними, а деякі стверджують, що кожен об'єкт повинен мати нитку. Але (і знову це весь текст, але навіть якщо ви вважаєте, що більше однієї теми вам не потрібно - і не слід - розглядати її для кожного об'єкта), як Філіп зазначає, що ігри, як правило, повторюються за списками. Але це не тільки (як він пропонує, хоча я розумію, що він відповідає лише на ваші параметри так мало об'єктів) для такої кількості об'єктів. У MUD Я програміст, оскільки ми маємо наступне (і це не вся діяльність, яка відбувається в режимі реального часу, тому майте це на увазі):

(Кількість екземплярів залежить від курсу - вище та нижче)

Мобілі (NPC, тобто персонаж не гравця): 2614; прототипи: 1360 Об'єкти: 4457; прототипи: 2281 Кімнати: 7983; прототипи: 7983. Кожна кімната зазвичай має власний примірник, але у нас також є динамічні кімнати, тобто кімнати всередині кімнати; або кімнати всередині мобільного, наприклад, шлунок дракона; або кімнати в предметах, наприклад, ви вводите магічний предмет). Майте на увазі, що ці динамічні кімнати існують на об'єкт / кімнату / мобільний телефон, який фактично має їх визначено. Так, це дуже схоже на World of Warcraft (я не граю в нього, але друг змусив мене грати його, коли у мене була машина Windows, якийсь час) уявлення про випадки, за винятком того, що ми мали це задовго до того, як World of Warcraft навіть існував.

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

Як ми впораємося з усім цим без зволікань?

• розетки: select (), черги (введення, виведення, події, інші речі), буфери (введення, виведення, інші речі) тощо. Вони опитуються 10 разів на секунду.

• символи, предмети, кімнати, бій, все: все в центральному циклі на різних імпульсах.

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