Почему для игр нужно писать дегрокод

Disclaimer: топик является своеобразным продолжением моей предыдущей темы Чем я хочу поделиться с новичкам в геймдеве и предназначен, в основном, для энтузиастов геймдева, а вовсе не тем, кто трудится над играми в коммерческих компаниях.

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

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

- желание переписывать функционал уже имеющихся библиотек, на создание и отладку которых
немало людей уже потратили прилично своего времени. Действительно, очень частая картина, когда игродела ну никак не устраивают готовые решения по работе, к примеру, с JSON, сериализацией, Entity Component System (ECS), разными форматами данных и т.д. В особо запущенном случае, может даже случится переключение на написание своего сервера с нуля, так сказать, from scratch.

- трата времени на стандарты и процессы. Это относится к тем, для кого почему-то становится очень важным соблюдение code style, формата doxygen комментариев и т.д. Кодовую базу вряд-ли потом увидит и пара человек, но разраб, с завидным упорством, будет переделывать snake style на camel style в названиях методов (чтобы все обязательно было в одном стиле) и/или же писать аннотации ко всем параметрам и member'ам. Сюда также относится, к примеру, стремление расписывать разные UML диаграммы для своего поделия, типа: диаграммы классов, диаграммы последовательностей, компонентов и т.д.

Но правда в том, что существует огромная разница между enterprise разработкой в софтверной компании и одиночкой инди. В первом случае, требуется согласованная работа многих людей, для чего единообразие и стандарты необходимы. Также соблюдение стандартов обычно связано с наличием жестких требований к продукту. Для инди же это все несущественно, а вот выпуск продукта за разумное время - да. Конечно, такое случалось в истории, когда кодовая база какого-либо инди проекта, в конечном счете, попадала в компанию для дальнейшего развития (типа Minecraft'а или движок Build в 3D Realms), но это все-таки не то на что следует рассчитывать при работе над каждой своей новой задумкой.

Многие, конечно, возразят, что их корпоративный опыт в программировании не позволяет что-то делать на скорую руку. Типа, раз уже приучился все делать как надо, то теперь для любого кода руки сами пытаются делать все "правильно" и "качественно". Если у такого индивида возникает, например, архитектурная проблема, то предложение добавить парочку костылей будет отметаться как что-то сродни богохульству, типа потом это аукнется при расширении проекта. Замечание о том, что можно и без, например, doxygen комментариев обойтись вызовет недоумение на тему того, что это все очень важно для дальнейшего развития проекта, чтобы потом всегда все было понятно. Переписывание библиотек - туда же - аргумент, что якобы свое решение будет заточено именно под себя и потом переиспользоваться во всех прочих своих проектах. И т.д.

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

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

1) избавьтесь от соблюдения ненужного code style - именуйте переменные, методы, параметры и поля классов каждый раз в разном стиле. Если никак не получается, то попробуйте каждый отдельно взятый класс или модуль в своем стиле писать.

2) не тратьте время на комментарии - однострочных пометок в транслите будет достаточно

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

4) не отвлекайтесь на написание документации, в т.ч. UML диаграмм и т.д. - это тоже уход в сторону от цели. В конце концов, вы же не будете примерять на себя роль System Architect в проекте из одного человека?

5) не переписывайте код. Привыкайте выжимать максимум из того, что уже есть.

6) избавьтесь от тяги ко всяким модным штукам - в топку разные ECS, MVC и т.д.

7) не вздумайте писать тесты (unit, модульные, интеграционные и т.д.), ведь команды тестировщиков у вас, скорее всего, не будет. TDD тоже мимо - это плохая практика для инди, а для оценки регрессии по тестам у вас не тот масштаб проекта.

8) напишите себе стикер, повести плакат, повторяйте перед сном: "я использую готовые решения, вместо переписывания их заново". Каждый раз себя одергивайте, если вдруг, вместо написания игры, захочется заимплементить свои Сигналы-Слоты, сериализацию, декодер PNG и тому подобное.

9) если пришли к выводу, что требуется рефакторинг, то задайте себе вопрос: как можно изящно решить проблему с помощью нескольких костылей? Например: конечный автомат слишком усложнился? - не проблема, смело добавляйте флаги для переключения состояний!

10) пересмотрите свое отношение к спагетти-коду. В конце концов, определенная порция хаоса не повредит, особенно когда будут возникать разные забавные и непредсказуемые ситуации в игре от этого. Помните баги из Dwarf Fortress или из Oblivion? - они в свое время приносили немало радости игрокам и обзорщикам. Поймите: намного интереснее поддерживать проект, когда есть комьюнити, из которого прилетают баг-репорты и забавные видосики про игровые глюки, чем чахнуть над вечно недоделанной игрой в которой все "правильно", но играть нельзя.

11) добавьте что-то свое по вкусу... ;-)

Бенни
> не вздумайте писать тесты (unit, модульные, интеграционные и т.д.), ведь
> команды тестировщиков у вас, скорее всего, не будет
именно поэтому нужно автоматизировать тестирование и писать тесты самому

#!
> именно поэтому нужно автоматизировать тестирование и писать тесты самому
я сначала подумал, что всё в серьёз написано, но потом понял, что тема тупо поржать.
Хотя в принципе годных советов два:

Хороший программист - ленивый программист.

А зачем бы кому-то писать комменты транслитом?

#!
> именно поэтому нужно автоматизировать тестирование и писать тесты самому
не не не... еще и автоматизацию тестирования?.. нафиг, это все не доведет до добра. Вот пусть лучше потенциальные потребители тестируют.

skalogryz
> я сначала подумал, что всё в серьёз написано, но потом понял, что тема тупо
> поржать.
Одно другому не мешает. Кое-что - это обобщение горького опыта, в котором тоже смешного хватает, если под несколько другим углом посмотреть.
Да и потом, не обязательно тупо поржать - можно и умно поржать :-)

Der FlugSimulator
> А зачем бы кому-то писать комменты транслитом?
Например, чтобы не тратить время на переключение раскладки :-)
Впрочем, на русском тоже можно, основной поинт - не запариваться с такой мелочью, как комментарии..

Бенни
> Например, чтобы не тратить время на переключение раскладки :-)

А почему по английски сразу нельзя?

Бенни
> еще и автоматизацию тестирования?
так это тривиально делается, например для С++ есть gtest или catch2, и можно руками запускать периодически
я же не говорю про CI travis/jenkins хотя и в open source много кто использует такое

Der FlugSimulator
> А почему по английски сразу нельзя?
исходя из нуль поста, чтобы английский не учить

#!
> travis/jenkins хотя и в open source много кто использует такое
Travis вроде всё, потому что он стал бабло требовать

Бенни
> 1) избавьтесь от ...
тут автоматизация привычкой.
если привык в одном стиле, то уже не задумываешься, как писать.

Бенни
> не тратте время на комментарии
комментарии мне нужны для более быстрой навигации по коду, т.е. они ускоряют моё чтение.

Бенни
> 3) никаких паттернов проектирования
вреднейший совет.
но никогда не пользуюсь книжными, каждый раз изобретаю заново диктуемое потребностью.

Бенни
> 4) не отвлекайтесь на написание документации
UML в топку, но всегда мне полезна общая схема.

Бенни
> 5) не переписывайте код
обычно первый код это код вместо ТЗ,
если проектировать сверху вниз, то только расширяется и переписывать == отлаживать.

Бенни
> 6) избавьтесь от тяги ко всяким модным штукам - в топку разные ECS, MVC
как раз залезть на плечи джедаев это гуд или снова писать свой движок?

Бенни
> 7) не вздумайте писать тесты
т.е. ваще не заниматься проектированием?
вот когда не хочешь им заниматься, а просто пишешь тесты,
то автоматом получается у тя проектирование, а не просто одно гавнокодирование.

Бенни
> 8) напишите себе стикер
да.

Бенни
> 9) если пришли к выводу, что требуется рефакторинг
если было проектирование, то рефакт не обязательно делать полностью.

Бенни
> 10) пересмотрите свое отношение к спагетти-коду
назад в школу?

Бенни
> 11) добавьте
KinematicBody2D в выбранном мною движке не умеет вращения,
именно это факт затормозил кодирование мною моего небольшого теста-демки.

Sbtrn. Devil
> Der FlugSimulator
> > А зачем бы кому-то писать комменты транслитом?
а я так понял:
британофилия головного моска + отсутствие знания инглиша.

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

Der FlugSimulator
> > Например, чтобы не тратить время на переключение раскладки :-)
>
> А почему по английски сразу нельзя?
ты свободно изъясняешься на английском? если - да, и у тебя не отнимает время написание комментариев на нем - пожалуйста, на здоровье! У меня же на основной работе все по-английски, но по-прежнему, бывает, начинаю задумываться, все ли правильно пишу с точки зрения грамматики и т.д. Бывает, лезу в переводчик. Для комментариев в инди игрульке это не нужно - пофиг какой там фразовый глагол и везде ли артикли правильно стоят. Поэтому, чтобы не тратить время, можно, как вариант, на транслите писать и не загоняться. Тем более, с высокой вероятностью, код вашего инди-поделия никто кроме вас потом читать не будет.

> > еще и автоматизацию тестирования?
> так это тривиально делается, например для С++ есть gtest или catch2, и можно
> руками запускать периодически
> я же не говорю про CI travis/jenkins хотя и в open source много кто использует
> такое
да-да-да. Видел. Круто, когда Jenkins build автоматически запускается для pull request'ов и тесты автоматом прогоняются на серваке, а потом генерится красивый репорт и рассылается по email'ам. Но занятие DevOps'ом вместо написание игры - это уход в стороннюю деятельность.

Кстати, насчет фреймворков для тестирования, есть еще более навороченные вещи, которые очень хорошие для enterprise.

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

xlat-code
> > 1) избавьтесь от ...
> тут автоматизация привычкой.
> если привык в одном стиле, то уже не задумываешься, как писать.
ну, как минимум, будешь задумываться о поддержании этого общего стиля. Т.е. тратить время и силы на побочную активность. Впрочем, если у тебя все автоматом - ради бога, дело твое.

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

xlat-code
> > 3) никаких паттернов проектирования
> вреднейший совет.
> но никогда не пользуюсь книжными, каждый раз изобретаю заново диктуемое
> потребностью.
Лол. Если ты каждый раз изобретаешь заново под ситуацию, то это не паттерн уже.
Но, правильно - больше гибкости! ;-)

xlat-code
> > 6) избавьтесь от тяги ко всяким модным штукам - в топку разные ECS, MVC
> как раз залезть на плечи джедаев это гуд или снова писать свой движок?
Писать свой движок точно не нужно. Вместо модных штук - искать пути упрощения и не пытаться слишком много задумываться. Еще не хватало, чтобы вместо своего проекта начал запариваться о том [например], не слишком ли много всего в "контроллере" и точно ли это "view", а может все уже в MVVM обернулось? Вот когда такие загоны начинаются и лезешь на форум, где дискутируешь и теоретизируешь вместо написания своей игры, тогда - все, приплыл.

xlat-code
> > 7) не вздумайте писать тесты
> т.е. ваще не заниматься проектированием?
Так, стоп! Проектирование и тестирование - это разные вещи. Не путай!

> вот когда не хочешь им заниматься, а просто пишешь тесты,
> то автоматом получается у тя проектирование, а не просто одно гавнокодирование.
Когда просто сидишь и пишешь тесты, то просто отрываешь время от написания своего проекта.

Говнокод-проект, в который можно играть - это лучше, чем неиграбельный заброшенный проект с кодом, близким к идеальному. Да-да, именно так...

xlat-code
> если было проектирование, то рефакт не обязательно делать полностью.
Я не отрицаю, что проектирование полезно. Я лишь утверждаю, что слишком серьезное отношение к нему не нужно. А то видел, как некоторые проектировали, проектировали и допроектировались, что никакой игры не написали. Зато больше тех, кто хреновенько проектировал, но костылей и спагетти-кода не чурался и хотя бы играбельный прототип получил.

xlat-code
> > 10) пересмотрите свое отношение к спагетти-коду
> назад в школу?
Напротив - вперед пожаловать в реальность.

xlat-code
> KinematicBody2D в выбранном мною движке не умеет вращения,
> именно это факт затормозил кодирование мною моего небольшого теста-демки.
И каковы твои действия? Решил переписать часть физического движка? Свой написать и приделать?
Навскидку, можно во-первых попытаться приспособить Dynamic Body (т.е. покостылить). Я надеюсь, у тебя не такая игра, где все прям на этих кинематик телах завязано? Если такая - сочувствую, может другой движок подобрать, где все нормально с этим?

Бенни
> Так, стоп! Проектирование и тестирование - это разные вещи. Не путай!
тут такая штука:
сам для себя это неожиданно открыл.

СИЛА В ОБОБЩЕНИИ.

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

Бенни
> Когда просто сидишь и пишешь тесты, то просто отрываешь время от написания
> своего проекта.
и всё же мне кажется что в целом вы лукавите:
крах проекта, как раз в том, что автор уже никак не может починить свои семантические баги,

а не в том, что он пишет тесты)))

xlat-code
> > > А зачем бы кому-то писать комменты транслитом?
> а я так понял:
> британофилия головного моска + отсутствие знания инглиша.
Во-во, верно, насчет британофилии. Задолбало это и на основной работе: всякие англицизмы пихают сверх всякой меры, навроде: "они контрибьютат в проект", "у нас все по аджайлу", "мы должны провести синк" и т.д. Реально тошнит уже.

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