Змагається з C ++ для програмування ігор

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

Це просто тому, що це швидко? Це якась інша особливість у мові, наприклад парадигма ОО або переносимість? Це через всі створені з часом бібліотеки? Або якесь поєднання всіх цих (та інших) причин?

Якби хтось міг би мене заповнити, я був би дуже радий. :-)

Численні причини:

• Великий, який ви пропустили: це портативний, спрощує порти вашого ігрового двигуна до iOS, XBOX, PS3, будь-що
• Це швидко
• Усі SDK підтримують це на самому світі
• Доступно багато бібліотек
• Усі, хто пише ігри, знають це, тому легко найняти досвідчених розробників ігор для своєї команди
• Вбудовувати таку мову сценаріїв ігрового двигуна, як Lua, нереально

Є кілька причин, які я хотів би зазначити на додаток до того, що підніс @Graham.

• Спадковий код - у багатьох студіях є багато коду С ++, йдеться про вашу згадку про бібліотеки.
• C ++ справді є високомобільним асемблером прямий доступ до апаратних засобів (настільки ж прямих, як можна принаймні працювати над поверхнею Операційної системи) і досить швидко. Якщо ви хочете, в C ++ ви можете перейти безпосередньо до мови складання для контролю рівня інструкцій (не те, що це завжди розумно, просто неможливо з Java, C #, Python тощо)
• DirectX і OpenGL в основному підтримують C ++, більшість інших мов мають "прив'язку" до базових бібліотек через проміжні шари, тобто не кажучи, що вони не швидкі або не можуть робити багато одних і тих же речей, але це додає шару програмного забезпечення між вашу гру та обладнання.
• Як згадує @Graham, багато програмістів знають це, тому його легко знайти досвідчених розробників, а також його досить портативний, порівняно з C #, який застряг у .NET Framework (є Mono, але він, як правило, відстає на покоління позаду впровадження Microsoft .)

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

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

У C ++ ви можете виділити локальні змінні, які зникають після закінчення функції. Зазвичай вони виділяються на стек.

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

Java та C # виділяють пам'ять динамічно, за винятком примітивних типів. Ці мови залежать від середовища виконання, яке буде позначати змінну, яку потрібно видалити, а потім запустити збирач сміття з випадковими (позаплановими) інтервалами для повернення пам'яті. Взагалі програміст не має контролю над тим, коли змінна буде позначена для видалення, а також коли вона буде відтворена (рекультивація використовуваної пам'яті - це вдосконалена тема, з якою більшість програмістів на C ++ та Java не відчувають).

Швидкість C ++ пов'язана насамперед з його прямим перекладом у виконуваний код. Java та C # складаються з проміжного коду, який потім інтерпретується віртуальною машиною. Взагалі мови інтерпретації є більш повільними, ніж безпосередньо перекладені.

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

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

Свого часу C ++ здавалося гарною ідеєю, і сьогодні більшість ігор - це C ++, але інженери зараз борються про повернення до C, і це може насправді статися. Мені б хотілося попрацювати над грою в C, і так би багато колег. У C ++ немає жодної функції, яка, на мою думку, покращує ігри.

Здавалося б, зараз, коли комп'ютери в 1000 разів швидше, ніж кілька років тому, мова високого рівня зменшить час розробки ($), зробивши C застарілим.

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

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

Ігрові програмісти не лише працюють мовою низького рівня, але й уникають структури даних та алгоритми високого рівня. Зазвичай ігри не мають пов'язаних списків і рідко мають дерева. Існує рух до уникнення покажчиків, коли це можливо *. Будь-який алгоритм з більш ніж O (N) часом або O (1) простором, як правило, не знаходить широкого застосування.

* Якщо вказівник не викликає пропущення кешу, то навіщо витрачати 32 біти на його зберігання? Якщо вказівник викликає пропущення кеш-пам'яті, найкраще позбудьтесь цього пропуску кешу.

Кожна мова програмування має сильні та слабкі сторони в різних факторах. Прикладами таких факторів є:

• Швидкість на певній платформі
• Використання пам'яті на певній платформі
• Яку функціональність вона відкриває легше
• На яких платформах існує
• Які міркування програміст повинен взяти на борт

Одним з найважливіших факторів, про який піклується ігровий програміст, є продуктивність. Вони хочуть створити інтерактивний досвід, а це означає, що він повинен бути реактивним і здатним виводити якомога більше корисних (або цікавих) даних. Ви хочете знати, яке здоров’я ви маєте в будь-який час, і не хочете його чекати. А якщо натиснути кнопку, ви очікуєте, що пістолет вистрілить, або ваш персонаж підскочить, коли ви це скажете. Невелике відставання може заважати цій інтерактивності, тому вам потрібна продуктивність.

Ще одним важливим фактором є віддавання переваги програмуванню мовою проблеми, а не мовою реалізації. Ігровий програміст хоче мати справу з людьми, орками та гоночними автомобілями, а не реєстром пам'яті ED0. Вони все ще хочуть зануритись у деталі реалізації, якщо їм потрібна продуктивність, але було б чудово, якби здебільшого вони могли мати справу з рівнем суб'єктів у своєму ігровому світі. Їм вистачає турбуватися про імітацію ігрового світу, не завжди дбаючи про те, як працює пов'язаний список.

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

• Збірка: Це сировина. Те, що ви пишете, це в основному те, що робить процесор. Але на кожному етапі потрібно знати, що відбувається з регістрами та наслідками цього, і це ніколи не схоже на сутності у вашому ігровому світі. Програміст повинен скласти ментальну відповідність того, що робить їх код, порівняно з тим, що відбувається в грі. Це може бути досить розумовим накладним.
• C: Тут ми маємо хороші показники, але ми можемо використовувати досвід гуру, щоб виконати стандартні речі (наприклад, виділити пам'ять, працювати на струнах і використовувати стандартні математичні функції). Ми наближаємось до виразності тут, але мова більш-менш змушує вас зосередитись на реалізації, оскільки ви дійсно можете працювати лише на звичайних типах даних. Все справді є чаром, інтом чи подібним. структури, покажчики та масиви можуть утримувати речі разом, але все-таки треба думати про внутрішні.
• Java: Ми перестрибуємо через C ++ і дістаємось до Java. Java відштовхується від деталей впровадження. Насправді, більшу частину часу ти не отримуєш доступу до нижчих рівнів. Java абстрагує більшу частину деталей про реалізацію (наприклад, який процесор або ОС ви використовуєте) з тієї причини, що вона хоче бути платформою. Ви не можете отримати доступ до деталей, оскільки їх там немає. Ви не програмуєте на комп’ютер, ви програмуєте на платформу (платформа Java, яка, як правило, існує на більшості комп'ютерів). Більше того, Java має, мабуть, кращу мову для вирішення мови проблеми, ніж C ++. Не можна оптимізувати конкретний комп'ютер. Чи це робить практичну різницю, чи ні, зводиться до специфіки програми та комп'ютера.
• Мова скриптових ігор: Під цим я маю на увазі щось на зразок UnrealScript або власні мови сценаріїв, прив'язані до ігрового двигуна. У них у вас немає доступу до основного двигуна. Ви делегуєте міркування щодо продуктивності двигуна, залишаючи себе вільно турбуватися про створення гри. Простіше написати гру, складніше оптимізувати її продуктивність самостійно.
• Haskell (або улюблена незрозуміла мова): Будь -яка мова програмування, повністю завершена Тьюрінгом, еквівалентна будь-якій іншій. Отже, хоча ви можете написати будь-яку програму будь-якою мовою, ви робите компроміси, деякі об'єктивні, якісь суб'єктивні. Мова на зразок Haskell більше зосереджена на роботі в математичному дусі. Проблеми, на які вона спрямована, дещо відрізняються від проблем, що виникають в іграх. Це не означає, що він не може або не повинен використовуватися для ігор, він просто не підходить для нього.

Останній пункт - це щось історичне та політичне. Багато вогняних воєн велися між різними мовами програмування. Наприклад, C # може бути настільки ж підходящим для розробки ігор, але він з'явився після C ++. Або людям не подобається, що це від Microsoft. Деякі люди перейшли на C #, деякі - ні. Деякі люди все ще програмують ігри на BASIC, Pascal та C. Що б програмістам було комфортно, вони будуть дотримуватися. Ігрові програмісти в основному зручніше з C ++, можливо, тому, що вони виросли на C і C ++, і це відповідало їхнім потребам. Якщо комп'ютерна галузь перебуває у стані, коли продуктивність та сприйняття Java задовольняє достатньо людей, то, можливо, Java буде фактично стандартною мовою розвитку ігор.

Спадщина та імпульс.

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

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

Якщо ви розробляєте для консолей, у вас немає вибору: професійні SDK мають лише C ++. Зазвичай вони також мають доступ до більшості.

Оскільки багато розробників - консолі + ПК, є сенс робити всі свої ПК на тій же мові та безпосередньо ділитися технологіями.

Оскільки саме там живе професійна галузь, і більшість всіх хоче стати частиною цього, більшість ігрових програмістів - це програмісти C ++.

Оскільки все це відбувається, більшість розробників двигунів теж є розробниками C ++, тож при оцінці двигунів професійного класу майже всі ваші варіанти будуть C ++.

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

FWIW: C # набирає популярності для розвитку ігор. Дивіться допис у блозі Мігеля де Ікази . Дуже цікаво читати, ІМХО.

Хоча я досить сильно проти C, C і C ++, одна річ, яку вони РОЗДІЛУЮТЬ у небагатьох інших мовах, - це повний контроль над платформою, на якій вона працює, ви можете бути впевнені, що саме відбуватиметься постійно, ні GC, жодних збоїв.

Це не так важливо в наші дні, але це може бути для слабких платформ.

На ПК / Mac / Linux це, мабуть, найменш портативна мова, з якою ви стикаєтесь у ці дні, і бонус за швидкість вже не є великою різницею - Minecraft (Java) плавний і працює на досить мінімальних платформах (і будь-якій ОС) з єдиним виконуваним файлом - я ще не бачив програми для C / C ++ з низькою робочою силою з такою ж функціональністю і мало помилок, не кажучи вже про роботу на трьох платформах.

Тож на цьому етапі я б сказав, що більшість із них - це інертність і уявлення про те, що реальні ігри завжди робляться в C / C ++, хоча можливість "портувати" на iPhone та консолі є важливою (Хоча я досить впевнений, що більшість користувальницького інтерфейсу ігор вимагають багато зусиль, щоб перенести порт, за винятком Windows та XBox).