Почему так плохо оптимизировать слишком рано?

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

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

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

Может кто-нибудь объяснить мне, почему такая плохая идея слишком рано оптимизировать?

161 голос | спросил Matthew Inglis 22 Mayam17 2017, 02:04:17

9 ответов


228

Преамбула:

В комментариях было высказано несколько возражений, и я думаю, что они в основном связаны с неправильным пониманием того, что мы имеем в виду, когда говорим «преждевременная оптимизация», поэтому я хотел добавить немного разъяснений.

«Не оптимизировать преждевременно». not означает «код записи, который, как вы знаете, плох, потому что Кнут говорит, что вам не разрешено очищать его до конца»

Это означает: «Не жертвуйте время и удобочитаемость для оптимизации, пока не узнаете, какие части вашей программы действительно нуждаются в ускорении». Поскольку типичная программа проводит большую часть своего времени в нескольких узких местах, инвестирование в оптимизацию «всего» может не дать вам такого же ускорения скорости, как фокусировка на том же капиталовложении только на узком коде.

Это означает, что , когда сомневаешься , мы должны:

  • Предпочтительный код, который просто писать, понимать и легко модифицировать для запуска

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

    /li>

Преждевременная оптимизация not :

  • Архитектурные решения для структурирования вашего кода таким образом, который будет масштабироваться для ваших нужд - выбор соответствующих модулей /обязанностей /интерфейсов /систем связи рассмотренным способом.

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

  • Использование правильного алгоритма для задания. A * является более оптимальным и более сложным, чем исчерпывающий поиск графа траектории. Это также отраслевой стандарт. Повторяя тему, придерживаясь проверенных методов, подобных этому, вы можете сделать код более понятным, чем если бы вы делали что-то простое, но противостояли известным лучшим практикам. Если у вас есть опыт работы с узкими местами, реализующими игровые функции X одним способом в предыдущем проекте, вам не нужно снова сталкиваться с этим узким местом в этом проекте, чтобы знать, что это реально - вы можете и должны повторно использовать решения, которые работали в прошлом игры.

Все эти типы оптимизаций хорошо обоснованы и, как правило, не будут помечены как «преждевременные» (если вы не идете вниз по кроличьей дыре, внедряя передовую траекторию для вашей карты шахматной доски 8x8 ...)

Итак, теперь, когда это устранено, на why , мы могли бы найти эту политику полезной в играх конкретно:


В gamedev особенно, скорость итерации - самая ценная вещь. Мы будем часто реализовывать и повторно внедрять гораздо больше идей, чем в конечном итоге поставлять готовые игры, пытаясь «найти удовольствие».

Если вы можете прототип механика в прямом и амперном режиме; может быть, немного наивным способом и играть на нем на следующий день, вы находитесь в гораздо лучшем положении, чем если бы вы провели неделю, сделав самую оптимальную версию этого в первую очередь. Особенно, если это сосать, и вы в конечном итоге выбрасываете эту функцию. Выполнение этого простого способа, чтобы вы могли протестировать на раннем этапе, может сэкономить массу ненужного рабочего кода оптимизации, который вы не сохраняете.

Не оптимизированный код также, как правило, проще модифицировать и пробовать разные варианты, чем код, который тонко настраивается, чтобы сделать одну точную вещь оптимально, которая, как правило, хрупка и сложнее модифицировать, не разбивая ее, не обнаруживая ошибок или не замедляя ее вниз. Поэтому, сохраняя код простым и легко меняющимся, часто стоит небольшая неэффективность во время разработки (мы обычно развиваемся на машинах выше целевой спецификации, поэтому мы можем поглотить накладные расходы и сосредоточиться на получении целевого опыта в первую очередь), пока мы «Мы заблокировали то, что нам нужно от этой функции, и можем оптимизировать те части, которые мы сейчас знаем, являются медленными.

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

Игры странные и экспериментальные - трудно предсказать, как будет развиваться игровой проект и его технические потребности, и где производительность будет самой сильной. На практике мы часто в конечном итоге беспокоимся о неправильных вещах - ищем здесь вопросы производительности, и вы увидите общую тему появления разработчиков, которые отвлекаются на бумаге, что, вероятно, не является проблемой вообще.

Возьмем драматический пример: если ваша игра связана с GPU (не редкость), то все это время тратило гипер-оптимизацию и потоки работы процессораможет вообще не принести ощутимой пользы. Все эти часы dev могли быть потрачены на внедрение & вместо этого, для улучшения игрового процесса, для улучшения игрового процесса.

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

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

ответил DMGregory 22 Mayam17 2017, 02:32:57
41

примечание: этот ответ начался как комментарий к ответу DMGregory, и поэтому он не дублирует очень хорошие моменты, которые он делает.

«Не было бы невероятно сложно изменить некоторые основные структуры игры в конце, а не разрабатывать их в первый раз с учетом производительности?»

Это, для меня, суть вопроса.

При создании оригинального дизайна вы должны пытаться проектировать для эффективности - на верхнем уровне. Это меньше оптимизация и больше о структуре.

Пример:
Вам нужно создать систему, чтобы пересечь реку. Очевидными проектами являются мост или паром, так что вы выбираете?
Ответ, конечно, зависит от размера пересечения и объема трафика. Это не оптимизация, а вместо этого начинается дизайн, подходящий для вашей проблемы.

При представлении вариантов дизайна вы выбираете наиболее подходящее для того, что вы хотите сделать.

Итак, скажем, что наш объем трафика довольно низок, поэтому мы решили построить два терминала и купить паром для обработки трафика. Хорошая простая реализация
К сожалению, как только мы его запускаем, мы обнаруживаем, что он видит больше трафика, чем ожидалось. Нам нужно оптимизировать паром! (потому что он работает, и строительство моста сейчас не является хорошим планом)

Параметры:

  • Купить второй паром (параллельная обработка)
  • Добавить еще одну автомобильную палубу на паром (сжатие трафика).
  • Обновите двигатель парома, чтобы ускорить его (переписанные алгоритмы обработки)

Здесь вы должны попытаться сделать ваш оригинальный дизайн максимально модульным.
Все вышесказанное является возможной оптимизацией, и вы даже можете сделать все три.
Но как вы делаете эти изменения без больших структурных изменений?

Если у вас модульный дизайн с четко определенными интерфейсами, то должен быть простым в реализации этих изменений.
Если ваш код не плотно связан, изменения в модулях не влияют на окружающую структуру.

Давайте посмотрим на добавление дополнительного паром.
«Плохая» программа может быть построена вокруг идеи одного парома и иметь состояния доков и состояние парома и положение всех связанных и разделяющих состояний. Это будет трудно изменить, чтобы добавить дополнительный паром в систему.
Лучшим вариантом было бы иметь доки и паром в качестве отдельных объектов. Между ними нет никакой жесткой связи, но у них есть интерфейс, где может прибыть парома, разгружать пассажиров, брать новые и уходить. Док-станция и паром разделяют только этот интерфейс, и это позволяет легко вносить изменения в систему, в этом случае добавив второй паром. Док не заботится о том, какие паромы существуют на самом деле, все, о чем идет речь, заключается в том, что что-то (что-то) использует его интерфейс.

TL; др:

  • В первую очередь попробуйте разработать эффективность.
  • Когда вы представляете два варианта, вы выбираете более эффективный.
  • Напишите свой код как можно более модульно с четко определенными интерфейсами.

Затем вы можете изменить механизмы внутри каждого модуля, не реструктурируя всю кодовую базу, когда вам нужно оптимизировать.

ответил Baldrickk 22 Maypm17 2017, 13:11:52
22

«Не оптимизировать раннее» не означает «выбрать худший способ сделать что-то». Вам все равно нужно учитывать последствия для производительности (если только вы не прототипируете). Дело не в том, чтобы калечить другие, более важные вещи в этот момент развития - такие как гибкость, надежность и т. Д. Выбирайте простые, безопасные оптимизации - выбирайте то, что вы ограничиваете, и вещи, которые вы держите свободными; отслеживать затраты. Должны ли вы использовать сильную печать? Большинство игр сделано и работает нормально; сколько стоило бы вам удалить это, если бы вы нашли интересное использование гибкости для игры?

Намного сложнее изменить оптимизированный код, особенно «умный» код. Это всегда выбор, который делает некоторые вещи лучше, а другие хуже (например, вы можете торговать процессорным временем для использования памяти). Когда вы делаете этот выбор, вам нужно знать все последствия - они могут быть катастрофическими, но они также могут быть полезными.

Например, Commander Keen, Wolfenstein и Doom были построены на основе оптимизированного механизма рендеринга. У каждого был свой «трюк», который позволил игре существовать в первую очередь (каждая из них также имела дальнейшую оптимизацию с течением времени, но это не важно здесь). Это нормально . Все в порядке, чтобы сильно оптимизировать основное ядро ​​игры, думаю, что это делает игру возможной; особенно если вы изучаете новую территорию, где эта конкретная оптимизированная функция позволяет вам рассмотреть игровые проекты, которые мало изучены. Ограничения, которые предлагает оптимизация, могут также дать вам интересный игровой процесс (например, лимит количества экземпляров в играх RTS, возможно, начался как способ повышения производительности, но также имеет эффект игрового процесса).

Но обратите внимание, что в каждом из этих примеров игра не может существовать без оптимизации. Они не начинались с «полностью оптимизированного» движка - они начинались с насущной необходимости и пробивались вверх. Они разрабатывали новые технологии и использовали их для создания забавных игр. И трюки с двигателем были ограничены как можно малой частью кодовой базы - более тяжелые оптимизации были введены только тогда, когда основной процесс игры был выполнен, или где он позволил создать интересную новую функцию.

Теперь рассмотрим игру, которую вы, возможно, захотите сделать. Есть ли какое-то технологическое чудо, которое делает или ломает эту игру? Может быть, вы представляете игру открытого мира в бесконечном мире. Это действительно центральная часть игры? Будет ли игра просто без нее работать? Возможно, вы думаете об игре, где ландшафт деформируется без ограничений, с реалистичной геологией и т. Д .; вы можете заставить его работать с меньшим объемом? Будет ли он работать в 2D вместо 3D? Получите что-нибудь интересное как можно скорее - даже если оптимизация может потребовать от вас переработать огромный кусок вашего существующего кода, это может стоить того; и вы даже можете понять, что делать вещи больше не делает игру лучше.

В качестве примера недавней игры с большим количеством оптимизаций я бы указал на Factorio. Одной из важнейших составляющих игры являются ремни - их много тысяч, и они несут много отдельных кусков материалов по всей вашей фабрике. Началась ли игра с сильно оптимизированного двигателя ремня? Нет! Фактически, дизайн оригинального пояса практически невозможно было оптимизировать - это было физическое моделирование предметов на поясе, что создало интересные вещи, которые вы могли бы сделать (так вы получаете «возникающий» геймплей - геймплей, который удивляет дизайнер), но это означало, что вам нужно было имитировать каждый предмет на поясе. С тысячами поясов вы получаете десятки тысяч физически смоделированных предметов - даже просто удаляя это и позволяя поясам выполнять работу, вы можете сократить время процессора на 95-99%, даже не учитывая такие вещи, как память. Но это полезно только тогда, когда вы действительно достигаете этих пределов.

Практически все, что имело отношение к поясам, нужно было переделать, чтобы можно было оптимизировать ремни. И ремни должны были быть оптимизированы, потому что вам понадобилось много ремней для большой фабрики, а крупные фабрики - одна из привлекательных возможностей игры. В конце концов, если у вас не может быть крупных заводов, почему есть бесконечный мир? Забавно, что вы должны спросить - ранние версии did not :) Игра была переработана и переделана много раз, чтобы добраться туда, где они сейчас, в том числе 100% римейк на месте, когда они поняли, что Java isn ' t путь для игры как это и переключился на C ++. И это отлично работало для Factorio (хотя было еще хорошо, что он не был оптимизирован с самого начала - тем более, что это был хобби-проект, который, возможно, просто провалился иначе из-за отсутствия интереса).

Но дело в том, что есть много вещей, которые вы можете сделать с фабрикой с ограниченным объемом, - и многие игры показали именно это. Ограничения могут быть еще более полезными для удовольствия, чем свободы; будет ли Spacechem более увлекательным, если бы «карты» были бесконечными? Если вы начали с сильно оптимизированных «поясов», вы бы в значительной степени быливынужден идти таким образом; и вы не могли исследовать другие направления проектирования (например, посмотреть, какие интересные вещи вы можете сделать с физико-имитируемыми конвейерными лентами). Вы ограничиваете свой потенциальный дизайн-пространство. Возможно, это не так, потому что вы не видите много незавершенных игр, но тяжелая часть - это удовольствие - для каждой веселой игры вы видите, что, вероятно, сотни, которые просто не могли добраться туда и были пересмотрены (или хуже, выпущенные как ужасные беспорядки). Если оптимизация поможет вам это сделать - продолжайте. Если это не так ... скорее всего, преждевременно. Если вы думаете, что какой-то игровой механик отлично работает, но нуждается в оптимизации, чтобы по-настоящему сиять - идите вперед. Если у вас нет интересной механики, не оптимизируйте их . Сначала найдите самое интересное - вы найдете большинство оптимизаций, которые не помогают в этом, и часто являются некриминальными.

Наконец, у вас отличная игра. Имеет ли смысл оптимизировать сейчас ? Ха! Это все еще не так ясно, как вы думаете. Есть ли что-то fun , которое вы можете сделать вместо этого? Не забывайте, что ваше время по-прежнему ограничено. Все требует усилий, и вы хотите сосредоточить усилия на том, где это важно. Да, даже если вы делаете «бесплатную игру» или игру с открытым исходным кодом. Смотрите, как игра играется; обратите внимание, что производительность становится узким местом. Оптимизирует ли эти места больше удовольствия (например, строительство все больших, все более запутанных фабрик)? Позволяет ли вам привлекать больше игроков (например, с более слабыми компьютерами или на разных платформах)? Вы всегда должны уделять первоочередное внимание - обратите внимание на усилие, чтобы обеспечить коэффициент. Вы, скорее всего, найдете много низко висящих фруктов, просто играя в свою игру и наблюдая, как другие играют в игру. Но обратите внимание на важную часть - чтобы попасть туда, вам нужна игра . Сосредоточьтесь на этом.

Как вишня сверху, подумайте, что оптимизация никогда не заканчивается. Это не задача с небольшой галочкой, которую вы заканчиваете, и переходите к другим задачам. Всегда есть «еще одна оптимизация», и большая часть любого развития понимает приоритеты. Вы не оптимизируете оптимизацию - вы делаете это для достижения определенной цели (например, «200 единиц на экране сразу на Pentium 333 МГц» - отличная цель). Не теряйте цели конечной цели только потому, что слишком много внимания уделяете промежуточным целям, которые больше не могут быть предпосылками для конечной цели.

ответил Luaan 22 Maypm17 2017, 12:20:40
9

Многие ответы, похоже, много фокусируются на аспекте производительности «оптимизации», в то время как мне самому нравится оптимизировать и все испытания оптимизировать слишком рано на более абстрактном уровне.

Юмор, когда я пытаюсь подробно остановиться на моей перспективе с помощью полиномино.

Предположим, что у нас есть фиксированные границы, установленные каркасом или движком, с которым мы работаем.

 введите описание изображения здесь>> </a> </p>

<p> Затем мы приступим к созданию нашего первого уровня /модуля игры. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Двигаясь вперед, мы создаем второй слой /модуль. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> В этот момент мы могли заметить, что между этими двумя модулями имеется некоторое пространство, и у нас может возникнуть соблазн оптимизировать его, чтобы в полной мере использовать выделенные нам границы. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Отлично, теперь приложение полностью использует доступные нам ресурсы, приложение лучше, хорошо? </p>

<p> Мы приступим к созданию третьего слоя /модуля нашего приложения, и вдруг мы приступим к реализации (возможно, даже той, которую мы не могли предвидеть во время первоначального планирования), что 3-й уровень /модуль не работает для нас. </p >

<p> Мы ищем альтернативу, мы находим один, и, в конце концов, это также требует от нас изменить 2-й модуль нашего приложения, поскольку он несовместим с нашим недавно выбранным 3-м модулем. (К счастью, он несколько совместим с нашим 1-м модулем, поэтому нам не нужно переписывать все с нуля.) </p>

<p> Итак, мы все собрали вместе ... </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Хм, видите ли, что случилось? </p>

<p> Оптимизируя слишком рано, мы теперь на самом деле сделали вещи хуже по эффективности, поскольку то, что мы оптимизировали, не является тем, что мы закончили с нисходящей линией. </p>

<p> И если бы мы захотели добавить некоторые дополнительные модули или дополнительные лакомые кусочки позже, мы могли бы не иметь возможности делать их на этом этапе. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> И настройка самого низкого уровня нашей системы уже невозможна, поскольку она была похоронена под всеми другими слоями. </p>

<p> Если бы мы, однако, предпочли бы с нашим желанием оптимизировать его немедленно, мы бы закончили с чем-то вроде этого: </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> И теперь, если мы выполним оптимизацию в этот момент, мы получим что-то приятное, чтобы посмотреть. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Надеюсь, хотя бы некоторым из вас было так весело читать это, как я получал удовольствие от этого :), и если теперь вы чувствуете, что у вас есть лучшее понимание предмета - тем лучше. </p></body></html>

ответил Ceiling Gecko 25 Maypm17 2017, 15:56:38
8

Деньги.

Все сводится к этому. Деньги. Поскольку время - это деньги *, тем больше времени вы тратите на мероприятия, которые не гарантируют получение большего количества денег (т.е. вы не можете рассматривать эти действия как инвестиции ), тем больше денег вы рискуете потратить впустую, а меньше денег вы будете делать с игрой.

Вот еще несколько побочных эффектов потенциал для оптимизации слишком рано, и почему вы должны избегать этого:

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

* В других ответах достаточно хорошо выделена часть времени


Как примечание, обычно , опыт помогает определить, что есть и что не является преждевременной оптимизацией, и что имеет значение для бизнеса, а что нет.

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

ответил Alexandre Vaillancourt 22 Mayam17 2017, 02:55:06
6

Оптимизация - это, по определению, процесс повышения эффективности решения вплоть до того момента, когда он теряет свою эффективность. Этот процесс подразумевает тогда сокращение пространства решения.

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

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

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

Сделать работу первой. Затем затяните веревки.

ответил Earendel 22 Maypm17 2017, 14:26:55
2

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

Это распространенная ошибка для разработчиков новичков, которым нравится сосредоточиться на получении удовольствия от «выполнения полезной работы», например оптимизации, а не задумываясь о том, правильно ли это сделать. По мере того как вы получаете опыт программирования больших проектов, таких как игры, вы узнаете, когда требуется оптимизировать существующую кодовую базу, а когда это будет слишком рано. Не бойтесь совершить эту ошибку, вам будет полезно извлечь уроки из нее.

В общем, оптимизируйте только в том случае, если вы действительно не сможете работать с разработкой прямо сейчас. Например, если вы создаете и удаляете миллионы объектов 60 раз в секунду.

Итак, я бы сказал, что хорошо, с точки зрения обучения, оптимизировать ранние несколько раз: p

ответил user1306322 22 Mayam17 2017, 07:13:07
2

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

Оптимизация не дает понимания. Это заставляет компьютер работать меньше и программист больше.

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

ответил user101307 22 Mayam17 2017, 10:47:44
2

Я категорически не согласен со всеми этими утверждениями, что код не следует оптимизировать на ранних стадиях. Это зависит от того, на какой стадии вы находитесь. Если это MVP - прототип, и вы просто пытаетесь посмотреть на игру, которая занимает от 1 до 2 недель, вы готовы переписать все, что вы уже писали. Да, оптимизация не имеет значения. Но если вы уже работаете над игрой, которая, как вы знаете, будет выпущена, она должна иметь оптимизированный код. Рассказы, которые люди говорят о новых возможностях и вещах, которые могут быть добавлены, - это промахи. Это плохо разработанная архитектура кода, а не оптимизированный код. Вам не нужно переписывать что-либо, чтобы добавить новые элементы, если у вас хороший дизайн кода.

Например, если у вас есть алгоритм поиска A *, не было бы лучше написать его наиболее оптимальным способом? Вместо того, чтобы позже изменить половину кода, который у вас есть, потому что вам пришлось внести некоторые изменения в алгоритм, потому что теперь ему нужны другие вызовы методов и обратные вызовы? И если у вас уже есть оптимизированный код с самого начала, это сэкономит вам много времени. Поскольку вы можете нарисовать себе отношения между объектами и как они взаимодействуют, вместо того, чтобы вслепую создавать тонны новых скриптов и сразу составлять все соединения - это приводит к неясному коду сфагетти.

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

ответил Candid Moon 22 Maypm17 2017, 16:50:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132