Чим розробка ігор відрізняється від іншої розробки програмного забезпечення? [зачинено]

Для солідного розробника програмного забезпечення загального призначення, що конкретно відрізняється від розробки ігор, принципово чи просто різницею в ступені?

Я робив іграшки з іграшками, такими як Tic-tac-toe, Tetris, і жорстокий вирішувач судоку (з користувальницьким інтерфейсом), і зараз я починаю проект середнього розміру (середнього розміру, щоб бути єдиним розробником і не мати зробив багато ігор) і одне, що я виявив у цьому конкретному проекті, полягає в тому, що розділити проблеми набагато складніше, оскільки все впливає на стан, і кожен об'єкт може взаємодіяти з усіма іншими об'єктами безліч способів.

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

Гра, над якою я працюю, покрокова, і графіка буде досить простою (на веб-основі, в основному через маніпуляції з DOM), тому реальний час і 3d робота не дуже застосовні для мене, але я все одно буду зацікавлені у відповідях щодо тих, якщо вони цікаві. Хоча найбільше цікавить загальна логіка гри.

PS Не соромтеся це повторно позначити, я не дуже впевнений, які теги застосовні.

Є одна основна відмінність. На мою думку, це єдина різниця, яка насправді має значення.

Ми можемо переконатися в технічних деталях, чому це різне, впевнений. 3D-двигуни, фізика частинок, багато різних речей вступають у гру.

Але до багатьох програмних форм додаються рядки. Програмне забезпечення для моделювання має робити багато одних і тих же речей. Кожен фрагмент важливого програмного забезпечення має якусь спеціалізовану бібліотеку, яку він повинен використовувати.

Отже, що робить ІГРИ різними?

Ось це: Програмне забезпечення призначене для задоволення потреби бізнесу. Вам потрібна система інвентаризації? Ви можете визначити, з якими типами предметів ви обробляєтесь. Ви можете визначити, що потрібно для планування виробництва. Ви можете все це зробити. Або якщо ви хочете отримати банківське програмне забезпечення, ви можете визначити, що ви хочете з цим робити.

З іграми ваша потреба в бізнесі - це "розвага". Спробуйте написати технічну специфікацію для "веселощів".

Це, на мою скромну думку розробника, те, що робить ігри різними, ніж звичайні програми. Ви просто не можете сказати "Чудово! Зараз це програмне забезпечення завершено відповідно до запитів клієнта!" адже все, що вони хочуть - це розважитися.

Коли говорити, вам не потрібна 3d графіка та екстравагантна фізика, щоб щось було весело. Чому люди все ще грають у тетріс? Його фізика складається з "блоку переміщення вниз", "не дозволяйте блоку вийти за межі" та "зупинити блок, коли він щось вдарить", і хоча протягом багатьох років було чимало версій, деякі з більш вигадливою графікою, ніж інші, але Суть - це весело !!

Тож якщо ви хочете бути чудовим розробником ігор, не викидайте те, що ви дізналися як звичайний розробник програмного забезпечення. Це все ще дуже корисні речі. І @Sion має рацію щодо поділу компонентів, як і у звичайному програмному забезпеченні. Але найважливіша особливість, яку ви можете додати до своєї гри - це веселощі. Весело весело весело весело. Ось чому розробка ігор існує, саме це потрібно для того, щоб ваша гра була успішною. І повірте мені, на цьому хоч весело грати, це принаймні 10 разів так весело зробити !!

Удачі вам у грі-розробки !! : D

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

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

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

Деякі легко ідентифіковані та відокремлені системи?

• Виявлення зіткнення
• Відповідь на зіткнення
• Фізика
• Анімація
• Графіка (2D та 3D)
• Штучний інтелект
• Введення користувача
• Введення / виведення файлів
• Мережі

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

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

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

Я думаю, що у вас є відповідь, є багато взаємодій. Я зробив кілька ігор з XNA (C #), тепер я роблю гру середнього розміру, як ви кажете, стратегічно-імітаційну гру, працюю над нею вже майже 2 місяці, і я роблю це наодинці без сторонньої допомоги, тому я повинен просто використовувати мій код. Я вважаю, що важлива різниця полягає в тому, щоб зрозуміти та спроектувати одні класи для функціональності, а інші - для малювання. Це допомагає зробити вашу програму більш чистою. Звичайно, якщо ви займаєтесь грою, вам потрібно мати більше ресурсів, як-от зображення (2d або 3d) та музика (або звуки). Отже, є відмінності, я думаю, що це важче, але це дуже смішно.

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

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

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

PS: Я використовую найновіші інструменти для розробки програмного забезпечення, HTML5, Asp.Net, C # і т.д. Я все ще вважаю DirectX, UDK, XNA, Unity цікавіше кодувати.