Следующий доклад с Pixonic DevGAMM Talks, который мы расшифровали, немного философский — это выступление Константина Гладышева.
Он является ведущим игровым программистом в «1С Игровая студия» и рассказал о принципе управления сложностью разработки в разрезе всего продукта, а не отдельных функций.
И показал на примерах, почему главное в разработке — определить, чего не надо делать.
О других отчетах вы можете прочитать по ссылкам в конце статьи.
Хотел поговорить о севере, но мы решили сделать философский доклад о том, что надо делать проще.
Я работал над Postal III, Indestructible, War Robots и сейчас делаю Caliber — сессионный онлайн-шутер от 1С и Wargaming. 
Почему мы решили поговорить о KISS (будь проще, глупый)? Потому что даже пенсионеры с 20-летним стажем или технические директора часто продолжают что-то лепить и изобретать.
Но нам нужно сделать это проще.
На самом деле, это больше о YAGNI (он вам не понадобится) и немного философии.
Сразу отмечу, что речь не идет о совсем идиотских решениях типа «найти х», мы говорим о более-менее простых решениях.
Почему иногда это слишком сложно? Все начинается с благих намерений, а они, как известно, ведут в ад. Вот комикс по этому поводу.
Причины этого примерно те же, но я назвал их по-другому:
- Универсальные решения .
Есть какая-то особенность и мы сразу делаем из нее библиотеку, миллион дополнительных случаев.
А что, если наш шутер вдруг превратится в ферму? Или «в следующий раз сделаю еще один шутер, точно такой же».
Вряд ли, скорее всего, у вас это изменится.
- На будущее .
Почти то же самое – это несуществующие проблемы.
«А если у меня сразу миллион пользователей, нужно ли мне поддерживать 22 промежуточных сервераЭ» и т. д. Чтобы начать зарабатывать, вам достаточно одного сервера.
- Использование неправильных инструментов .
Когда вы используете неподходящие инструменты и упорствуете в своем заблуждении.
- И все знают преждевременная оптимизация .
Ребята, которые нам помогали, тогда решили сразу сделать суперсериализатор на последнем C++.
В итоге получилось не так как я хотел, неудобно было отправлять частичное состояние, потому что шаблоны не очень понимают, где оно нужно, а где нет, или где нужно добавить какие-то флаги.
Со временем даже автор не понял ошибок, которые были в этом коде шаблона.
Тогда один из программистов буквально за два часа переписал все это добро в одну страницу кода на языке C, который делал только то, что нам нужно было именно тогда.
И это сработало чудесно.
Другой пример.
У нас была Postal III и она была сделана на движке Source. Там такой открытый мир, можно ходить между картами, камера от третьего лица, множество одноэтажных домов в американском стиле с окнами, боты могут бегать и в панике открывать двери.
В результате весь БСП не работал.
Рассчитывать пришлось очень долго, из-за окон получилось миллион секторов и все равно ничего не сделал.
Занимало много памяти и долго загружалось.
Half-Life, для которого был сделан движок, представляет собой шутер от первого лица, и от третьего лица некоторые вещи делать было неудобно.
Все полезное из Half-Life нас совершенно не устраивало.
Анимации тоже должно было быть много, потому что от третьего лица нужно перелезать и т. д. Пришлось менять движок, но тогда варианта не было.
Что делать, когда все плохо, сложно и нас подталкивают? Во-первых, выполняйте функции в правильном порядке, потому что оптимизация заранее — одна из проблем.
Некоторые начинают приклеивать стразы еще до того, как сшить платье, а потом не могут шить, потому что стразы мешаются.
Сначала сделайте самую простую фичу, чтобы она просто работала, затем стабилизируйте ее, а потом уже оптимизируйте.
Именно в этом порядке все остальное неправильно.
Под визуализацией мы подразумеваем, что это минимально функциональный продукт, т.е.
MVP (minimum viable Product).
Далее вы оцениваете его потенциал.
Допустим, геймдизайнеры придумывают фичи, прибегает программист и говорит «Я сделаю хорошо, плохо не сделаю, поэтому сразу нарисуйте классный геймдизайн».
Но откуда он знает? Он не играл, не знает, хорошо это или плохо.
Поэтому в идеале делаешь фичу, играешь и если ок, то делаешь дальше.
Это ненормально - выбросили, не жалею.
Тысячу лет назад Сунь Цзы сказал, что победа в 100 битвах – это не вершина, вершина – победа без боя.
Те.
не делай того, чего не можешь сделать.
Стабилизация.
Вы внесли фичи и дальше стабилизируете его без лишних дополнений.
Вам нужно колесо на дереве, на верёвке? Оно висит. Ничего больше.
Соответственно, если вдруг выяснится (без каких-либо доказательств в будущем), что функцию нужно изменить, начните заново.
Просто сделайте прототип, стабилизируйте его и не пытайтесь угадать заранее.
Вы все равно не догадаетесь.
Ну и преждевременная оптимизация.
Это всегда плохо.
Оптимизировать нужно в самом конце, когда вы точно знаете, что эта функция важна, ее стоит оптимизировать и она не изменится кардинально в ближайшее время.
Потому что оптимизация — это набор частных случаев.
Ухудшается читаемость кода, ломаются абстракции, переносимость, как правило, тоже сильно ухудшается.
Это провокационный слайд, потому что костыли на самом деле вредны.
Но это показывает ситуацию, когда есть куча унылых фич и прототипов, все плохо и кажется, что все рухнет. Но это неправда.
Смотрите – это опалубка, в нее заливают бетон и подпирают «костыли», пока он сохнет. Те.
ситуация абсолютно нормальная, "костыли" потом уберут, но не сразу, без паники.
Коротко о философии.
Универсально правильных решений не существует. Не пытайтесь создать рамки на 100 лет вперед или на все случаи жизни.
Вместо этого сделайте много маленьких деталей, которые хорошо выполняют свою работу.
Как можно скорее выбрасывайте ненужные вещи, не пытайтесь их саботировать.
И когда вы пишете код, делайте его явным.
Иногда лучше написать явный код, который вы сериализуете вручную, а не отражение или что-то еще.
Использование действия зависимости, когда оно вам не нужно, также является плохой идеей.
Это очень сложно читать, половина ошибок находится во время выполнения.
Явное лучше неявного.
И делайте это максимально просто, чтобы избежать ошибок, когда кто-то что-то не понимает или совсем забывает. Как сказал Брюс Ли, простота – это высшая степень искусства.
Однажды актер, которого он обучал Джит Кун До, спросил его: «В чем суть твоего боевого искусства Джит Кун ДоЭ» В этот момент Брюс Ли уронил свой кошелек, актер поднял его, и Брюс Ли сказал: «Видите ли, вы просто наклонились и подняли кошелек, и если бы вы стояли в позе всадника, делая ката, вы бы никогда не подобрали его».
Вопросы из зала
— Вы сказали, что преждевременная оптимизация — это зло.Стоит ли писать преждевременные тесты, когда проект только стартует? — В моем понимании вообще все преждевременное вредно.
Я не очень хорош в тестировании, потому что в разработке игр (во многих случаях) тесты ближе к концу разработки.
В начале все меняется так быстро, что к моменту написания теста геймдизайнер уже все поменяет. Я думаю, что плохо тратить энергию на тестирование того, что изменится за два часа.
Это необходимо сделать на этапе стабилизации.
Но не на стадии прототипа.
Но если команда может быстро писать тесты, это, наверное, хорошо.
Если нет, то нет. — Вы упомянули, что костыли уберут, но есть замечательный тезис — нет ничего более постоянного, чем временное.
Мы все занимаемся разработкой игр, у нас есть сроки, производители, потом новая функция и так далее.
Как часто вы видели ситуацию, когда вы чистили костыли? И были ли они сведены к нулю? — В ноль, наверное, нет. Если проект жив, у вас всегда будут какие-то костыли.
Все это работает, если чистить их систематически.
Те.
ты сделал фичу - ее тут же исправили.
— То есть, должен ли в компании быть выстроен определенный процесс? Как официальная фаза чистки костылей? - Да, я думаю, это надо включить в задание.
Те.
если вам нужно выполнить рефакторинг в процессе выполнения задачи, выполните рефакторинг.
Грубо говоря, здесь даже нет слова рефакторинг — он внутри задачи.
— Возможно ли это сделать на практике? Вы приходите к продюсеру и говорите, планируя новую итерацию, что нам нужно две недели на чистку, рефакторинг и т. д. А он говорит, что для бизнеса это нулевая ценность, сейчас мы делаем фичу x, а потом вы можете ее немного подчистить.
вечер после работы.
Что делать в такой ситуации? - Нам это удается.
Продюсер знает, что есть какие-то долги, которые вы исправляете, но своевременно.
Не то чтобы у вас новый релиз, в нем нет ни одной новой функции, но есть какой-то рефакторинг.
Просто выберите подходящего производителя.
— С опытом приходит понимание, что чем проще, тем лучше.
Но начинающие программисты пытаются создавать сложные, страшные, большие и гигантские системы.
Вопрос: как удержать их от этого, кроме твердого «нет»? «Я думаю, это проблема с обучением».
Нам нужно как можно раньше показать, какие решения работают, какие нет и почему.
Когда у тебя есть опыт и ты можешь объяснить, почему не стоит этого делать, ты можешь просто привести массу примеров и это уже хорошо работает. Подавайте пример и постоянно следите за тем, чтобы все было просто.
Ставьте их на прототипы, чтобы они чаще переписывались — когда переписываешь часто, писать много уже не хочется и они пишут все проще и проще.
— Если уже есть что-то очень сложное, что используется на нескольких проектах, и эта сложность уже не помогает, а скорее мешает, как проще всего перейти к простым решениям? - Мое мнение – просто начать делать это снова.
В идеале какая-то отдельная команда, прямо с нуля.
Скорее всего, вы очень быстро восстановите 80% своей функциональности.
В новой и чистой библиотеке.
И тогда вы догоните.
— Например, есть какой-то мощный сериализатор и редактор игровой логики, но он сильно устарел… - Это такие же неудобные инструменты.
Берите удобные.
Единство, например.
— Расскажите, какое планирование у вас в кодексе, насколько оно детальное? Главный программист решает все мелкие вопросы, все задачи? — У нас такая анархия, достаточно плоская структура, людей не очень много.
Мы доверяем всем и просто распределяем, кто возьмет прототип, а кто нет. Это может быть любой человек.
Больше выступлений от Pixonic DevGAMM Talks
- Использование Consul для масштабирования сервисов с отслеживанием состояния (Иван Бубнов, DevOps в BIT.GAMES);
- CICD: плавное развертывание в распределенных кластерных системах без простоев (Егор Панов, системный администратор Pixonic);
- Попрактикуйтесь в использовании модели актера на серверной платформе игры Quake Champions. (Роман Рогозин, бэкенд-разработчик Sabre Interactive);
- Мета-серверная архитектура мобильного онлайн-шутера Tacticool (Павел Платто, ведущий инженер-программист PanzerDog);
- Как ECS, C# Job System и SRP меняют подход к архитектуре (Валентин Симонов, полевой инженер Unity);
- Общая логика игры на клиенте и сервере (Антон Григорьев, заместитель технического директора Pixonic).
- Cucumber в облаке: использование BDD-скриптов для нагрузочного тестирования продукта (Антон Косякин, технический менеджер по продукту ALICE Platform).
-
Как Manychat Перешел На Php8
19 Oct, 24 -
Quadcast – Звук Настоящий
19 Oct, 24 -
Компианино
19 Oct, 24 -
Привет Всей России? Это Скайп!
19 Oct, 24 -
Создайте Галактику В 30 Строк
19 Oct, 24
