Чому так рано погано оптимізувати?

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

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

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

Може хтось пояснить мені, чому така погана ідея занадто рано оптимізувати?

Преамбула:

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

"Не оптимізуйте передчасно" не означає "писати код, який ви знаєте, погано, тому що Кнут каже, що вам заборонено його очищати до кінця"

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

Це означає, що при сумнівах ми повинні:

• Віддайте перевагу коду, який простий у написанні, зрозумілий для розуміння та легкий для зміни для початку

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

Передчасна оптимізація не є :

• Архітектурні рішення структурувати ваш код таким чином, щоб відповідати вашим потребам - вибір відповідних модулів / обов'язків / інтерфейсів / комунікаційних систем розглянутим способом.

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

• Використання правильного алгоритму для завдання. A * є більш оптимальним і складнішим, ніж вичерпний пошук графіка прокладання маршрутів. Це також галузевий стандарт. Повторюючи тему, дотримуючись перевірених методів на кшталт цього, насправді можна полегшити розуміння коду, ніж якщо ви робите щось просте, але суперечить відомим найкращим практикам. Якщо у вас є досвід стикання з вузькими місцями, що реалізують ігрову функцію X в одну сторону на попередньому проекті, вам не потрібно повторювати те саме вузьке місце на цьому проекті, щоб знати, що це реально - ви можете і повинні повторно використовувати рішення, які працювали за минулий ігри.

Усі ці типи оптимізацій є виправданими і, як правило, не позначаються як "передчасні" (якщо ви не збираєтеся в кролячій норі, використовуючи передову обробку шляху для вашої карти шахів 8x8 ...)

Отож, з цим з’ясуємо, чому ми можемо вважати цю політику корисною саме в іграх:

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

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

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

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

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

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

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

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

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

"Чи не було б неймовірно складно змінити деякі основні структури гри наприкінці, а не розвивати їх вперше з врахуванням продуктивності?"

Це, на мій погляд, суть питання.

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

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

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

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

Параметри:

• Купуйте другий пором (паралельна обробка)
• Додайте ще одну палубу автомобіля на паром (стиснення руху)
• Оновіть двигун пором, щоб зробити його швидшим (переписані алгоритми обробки)

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

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

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

tl; dr:

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

Потім ви можете змінити механізми всередині кожного модуля без реструктуризації всієї бази коду, коли вам потрібно оптимізувати.

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

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

Наприклад, командири Кін, Вольфенштейн та Дум були побудовані на основі оптимізованого двигуна візуалізації. У кожного був свій «трюк», який дозволяв грі існувати в першу чергу (для кожної також були розроблені подальші оптимізації з часом, але це тут не важливо). Це добре . Добре сильно оптимізувати саму суть гри, думка, яка робить гру можливою; особливо, якщо ви вивчаєте нову територію, де саме ця оптимізована функція дозволяє розглянути ігрові дизайни, які не були дуже вивчені. Обмеження, які вводить оптимізація, можуть дати вам і цікавий геймплей (наприклад, обмеження кількості одиниць в іграх RTS, можливо, почалися як спосіб підвищення продуктивності, але вони також мають ефект гри).

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

Тепер розглянемо гру, яку, можливо, ви хочете зробити. Чи справді є якесь технологічне диво, яке робить або порушує цю гру? Можливо, ви передбачаєте гру відкритого світу про нескінченний світ. Це справді центральна частина гри? Чи гра без нього просто не працюватиме? Можливо, ви думаєте про гру, де місцевість деформується без обмежень, з реалістичною геологією і подібною; чи можете ви змусити його працювати з меншим розмахом? Він би працював у 2D замість 3D? Отримайте щось веселе якнайшвидше - навіть якщо оптимізація може зажадати від вас переробити величезний фрагмент наявного коду, можливо, це варто того; і ви навіть можете усвідомити, що збільшення речі насправді не робить гру кращою.

Як приклад нещодавньої гри з великою кількістю оптимізацій, я назначу Factorio. Однією з важливих частин гри є ремені - їх багато тисяч, і вони несуть безліч окремих шматочків матеріалів по всій фабриці. Чи розпочалася гра з сильно оптимізованим ремінним двигуном? Немає! Насправді оригінальну конструкцію пояса неможливо було оптимізувати - вона на зразок фізичного моделювання предметів на поясі, що створило кілька цікавих речей, які ви могли зробити (саме таким чином ви отримуєте "виникаючий" геймплей - геймплей, який дивує дизайнер), але означало, що вам доведеться моделювати кожен предмет на поясі. З тисячами ременів ви отримуєте десятки тисяч фізично модельованих предметів - навіть просто видалення цього та надання ременів виконувати роботу дозволяє скоротити пов'язаний час процесора на 95-99%, навіть не враховуючи таких речей, як локальність пам'яті. Але це корисно робити лише тоді, коли ви дійсно досягнете цих меж.

Практично все, що мало відношення до ременів, потрібно було переробити, щоб оптимізувати пояси. І ремені потрібно було оптимізувати, адже вам потрібно було багато ременів для великої фабрики, а великі фабрики - одна привабливість гри. Зрештою, якщо ви не можете мати великі заводи, навіщо мати нескінченний світ? Смішно запитати - ранні версії не виходили :) Гра перероблялася та перероблялася протягом багатьох разів, щоб знайти там, де вони є зараз, - включаючи 100% ремейк, коли зрозуміли, що Java - це не шлях до така гра і перейшла на C ++. І це спрацювало чудово для Факторио (хоча це все-таки добре, що його не оптимізували з початку роботи - тим більше, що це був проект хобі, який, можливо, просто не вдався б інакше через відсутність інтересу).

Але справа в тому, що єВи можете зробити багато речей з фабрикою з обмеженою сферою - і багато ігор показали саме це. Обмеження можуть бути навіть більш широкими можливостями для розваги, ніж свободи; Чи було б Spacechem веселіше, якби "карти" були нескінченними? Якби ви почали із сильно оптимізованих "ременів", ви майже змушені були б піти цим шляхом; і ви не змогли вивчити інші напрямки проектування (наприклад, побачити, що цікавого ви можете зробити з імітованими фізикою конвеєрами). Ви обмежуєте потенційний дизайн-простір. Це може здатися не таким, тому що ви не бачите багато незавершених ігор, але важка частина отримує задоволення правильно - для кожної веселої гри, яку ви бачите, напевно є сотні, які просто не змогли дістатися і були забиті (або гірше, випущений як жахливі безлад). Якщо оптимізація допоможе вам у цьому - продовжуйте роботу. Якщо це не так ... це, ймовірно, передчасно. Якщо ви думаєте, що якийсь механік геймплея працює чудово, але йому потрібні оптимізації, щоб справді блищати - продовжуйте. Якщо у вас немає цікавої механіки,не оптимізуйте їх . Спершу знайдіть задоволення - ви знайдете, що більшість оптимізацій не допомагають у цьому і часто є злочинними.

Нарешті, у вас чудова, весела гра. Чи є сенс оптимізувати зараз ? Га! Це все ще не так зрозуміло, як ви могли подумати. Чи є щось веселе?ви можете зробити замість цього? Не забувайте, що ваш час все ще обмежений. Все вимагає зусиль, і ви хочете зосередити це на тому, де це найбільше важливо. Так, навіть якщо ви робите "безкоштовну гру" або гру з відкритим кодом. Дивіться, як грається гра; зауважте, де вистава стає вузьким місцем. Чи оптимізація цих місць робить для себе більше задоволення (як будівництво все більших, все більш заплутаних заводів)? Чи дозволяє вам залучати більше гравців (наприклад, із слабшими комп'ютерами або на різних платформах)? Завжди потрібно розставляти пріоритети - шукайте коефіцієнт зусиль та врожайності. Ви, ймовірно, знайдете велику кількість низько висячих фруктів лише від того, щоб грати у свою гру і спостерігати, як інші грають у цю гру. Але зауважте важливу частину - щоб потрапити туди, вам потрібна гра . Зосередьтеся на цьому.

Як вишня зверху, вважайте, що оптимізація ніколи не закінчується. Це не завдання з невеликою галочкою, яку ви закінчите та переходите до інших завдань. Завжди можна зробити «ще одну оптимізацію», і велика частина будь-якої розробки - це розуміння пріоритетів. Ви не здійснюєте оптимізацію заради оптимізації - ви робите це для досягнення певної мети (наприклад, "200 одиниць на екрані одразу на 333 МГц Пентію" - чудова мета). Не втрачайте слідів кінцевої мети лише тому, що ви занадто сильно зосереджуєтесь на проміжних цілях, які вже навіть не можуть бути передумовою для кінцевої цілі.

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

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

Припустимо, у нас є певні межі, встановлені рамкою або двигуном, з яким ми працюємо.

Потім ми переходимо до створення нашого першого шару / модуля гри так.

Рухаючись далі, ми будуємо наш другий шар / модуль.

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

Ідеально, тепер додаток повністю використовує доступні нам ресурси, додаток краще, добре?

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

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

Тож ми все це склали ...

Хм, ти бачиш, що сталося?

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

І якби ми хотіли б потім додати кілька додаткових модулів або додаткових ласощів, ми, можливо, більше не зможемо виконати їх.

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

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

А тепер, якщо в цей момент ми виконаємо оптимізацію, ми отримаємо щось задоволення.

Сподіваємось, принаймні дехто з вас так весело читав це, як і мені було весело, роблячи це :), і якщо тепер вам здається, що ви краще зрозумієте цю тему - тим краще.

Гроші.

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

Ось ще кілька потенційних побічних ефектів оптимізації занадто рано, і причини, чому вам слід цього уникати:

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

^{* Інші відповіді досить добре виділили частину часу}

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

Наприклад, якщо ви працювали над грою A і до кінця проекту зрозуміли, що функція XYZ була особливо важка для вашого ігрового циклу, і ви, зрештою, почнете працювати над грою B, яка має точно таку особливість, вирішивши переписати функцію та оптимізувати її з самого початку - це насправді не передчасна оптимізація, оскільки ви знаєте, що це буде вузьким місцем, якщо нічого не буде зроблено.

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

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

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

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

Зробіть це першим. Потім затягніть мотузки.

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

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

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

Отже, я б сказав, що добре, з точки зору досвіду навчання, кілька разів оптимізувати: p

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

Оптимізація не дає зрозуміти. Це змушує роботу комп'ютера менше, а програміста більше.

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

Я категорично не згоден з усіма цими твердженнями, що код не слід оптимізувати на ранніх етапах. Це залежить від того, на якому етапі ти знаходишся. Якщо це прототип MVP, і ви просто намагаєтеся подивитися на гру, яка займає від 1 до 2 тижнів, ви готові переписати все, що вже написали. Так, оптимізація не має значення. Але якщо ви вже працюєте над грою, яка, як ви знаєте, буде випущена, вона повинна весь час оптимізувати код. Казки, які люди говорять про нові риси та речі, які можна було б додати, - це помилкова думка. Це погано розроблена архітектура коду, а не оптимізований код. Вам не потрібно нічого переписувати, щоб додати нові елементи, якщо у вас гарний дизайн коду.

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

Останнє, що я хочу додати, це те, що пізніше, навіть якщо ви більше не хочете робити гру, у вас є оптимізований алгоритм A *, який ви можете використовувати для своїх наступних ігор. Багаторазовість. Наприклад, у багатьох іграх є інвентар, пошук маршрутів, генерація процедур, взаємодія між npc, бойовою системою, AI, взаємодія інтерфейсів, управління введеннями. Тепер слід запитати себе - "Скільки разів я переписав ці елементи з нуля?" Вони складають 70-80% гри. Вам справді потрібно весь час їх переписувати? А що робити, якщо вони неоптимізовані?