Инди
Netless
2730

Быть инди значит быть слепым

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

В закладки
Аудио

Писать код для игроков, а не для программистов

Качество кода всегда будет горячей темой в любой дискуссии о разработке. Это один из камней преткновения на пути любого инди разработчика. Дилемма между "высокодуховным" кодом и накиданными в скорости "записульками" стоит перед каждым из нас и наступают моменты когда мы думаем "Ну это точно нужно переписывать"...

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

Верить себе

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

Если вы придумали какой-либо концепт и считаете, что он достаточно интересен - творите! Просто слепо следуйте своей вере в это и не слушайте никого. Да, это сложно. Да, люди будут вас отговаривать. Да, даже ваши близкие будут против вас. Но такой путь инди и его нужно проходить. Раз за разом, релиз за релизом.

Решать проблемы по мере их поступления

Есть такой термин "Premature Optimization" (преждевременная оптимизация). Об этой проблеме написано много статей, много говорится в разных книгах и с этим термином должен быть знаком каждый программист. Если выразиться кратко, то преждевременная оптимизация это попытка решить какую-либо проблему до её наступления.

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

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

Знать свои сильные\слабые стороны и использовать их

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

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

Уметь проигрывать

Провал не означает смерть. Если вы потерпели неудачу, то это не означает, что вы ничтожество. Мне довелось крутиться в среде стартаперов в конце первого десятка нулевых (imo самый пик популярности культуры стартаперов) и благодаря этому я усвоил один важный урок: потерпеть неудачу намного полезнее чем просто выстрелить. Выстрелив, вы можете не обуздать эту волну хайпа и перенести неудачу будет намного сложнее чем если вы вначале набьёте шишки на коленях провалами и потом с точностью швецарских часов выстрелите, став машинистом хайп-трейна.

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

Быть инди значит слепо писать код, который работает, а не академический идеальный код.

Быть инди значит слепо верить в свои идеи даже если все вокруг против тебя.

Быть инди значит слепо игнорировать проблемы пока они не остановят работу.

Быть инди значит слепо делать то, что умеешь делать хорошо.

Быть инди значит слепо верить в успех, даже если впереди только провал.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Netless", "author_type": "self", "tags": [], "comments": 87, "likes": 24, "favorites": 77, "is_advertisement": false, "subsite_label": "indie", "id": 65817, "is_wide": false, "is_ugc": true, "date": "Sat, 24 Aug 2019 18:12:20 +0300", "is_special": false }
0
{ "id": 65817, "author_id": 116280, "diff_limit": 1000, "urls": {"diff":"\/comments\/65817\/get","add":"\/comments\/65817\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/65817"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64960, "last_count_and_date": null }
87 комментариев
Популярные
По порядку
Написать комментарий...
50

То что описано в статье - это вредные советы. Они имеют в общем верное направление, но сами по себе плохи.
1. Писать код на отъебись так же плохо для вас как и выдрачивать код до идеала. Вы в обоих случаях потеряете время, во втором на разработку, в первом на исправление всех выстрелов в ногу которые вы успеете понаделать в своём фанатичном желании сделать хоть как. Нужен баланс между тем и тем. Вам стоит стараться писать свой код как можно лучше, но не слишком в этом упорствовать. Запланируйте время которое вы собираетесь потратить на задачу и постарайтесь сделать лучшее что успеете за это время. Со временем вы наберетесь опыта наступив по паре раз на каждые грабли и в дальнейшем научитесь их избегать. Главное умеренное желание становиться в этом деле лучше.
2. Верить - да, слепо - нет. Возможно ваша идея замечательная и её никто не понимает, но скорее всего вы где-то допустили дизайнерский просчет. Для выявления слабых мест своего дизайна нужны плейтесты и вам нужно уметь выделять из критики указания на эти слабые места. Автор мешаяет в одну кучу фразы вроде "лучше бы ты запилил очередное 3-в-ряд с батлроялем, а не выдумывал" и вроде "слушай, вот эта твоя механика выдёргивания волос из носа - реально унылая". Первые - действительно не то что вам нужно, но второе - важно для вас. Если обобщить НЕ ПРЕНЕБРЕГАЙТЕ ПЛЕЙТЕСТАМИ.
3. Если вы замечаете проблему только тогда, когда уперлись в нее и уже ничего нельзя сделать - вы определенно что-то делаете неверно. Тут как с первым пунктом, автор кидается в другую дурацкую крайность. Вам нужна середина. Старайтесь предполагать наиболее вероятные риски, вроде технически ограничений, недостатка времени, необходимости например арта и постарайтесь прикинуть как вы будете с ними бороться не сильно углубляясь в подробности. УМЕРЕННО будьте готовы, иначе очередная внезапно появившаяся проблема может стоить вам слишком дорого
4. Если ты делаешь что-то слепо - значит ты не можешь оценить делаешь ли ты это хорошо. Опять всё перекручено.
Вам действительно нужно обращаться за советом к людям, у которых есть опыт в том, в чем нет у вас. Если какого-то навыка у вас нет - вам нужна помощь. Не будьте слепы. Вы потратите гораздо меньше времени если не будете изобретать велосипед, а обратитесь к велосипедному мастеру.
5. Не надо слепо верить. Нужно трезво оценивать свои шансы. Надеяться на лучшее можно на что угодно, но готовиться надо к худшему. Отрицательный результат - тоже результат. Стремитесь к своей цели, но не кидайтесь в омут с головой.

Короче TLDR
1. Делайте лучшее, что можете за отведенное время.
2. Не пренебрегайте результатами плейтестов, но выделяйте в них, что сделано недостаточно хорошо или плохо, а не советы вроде "сделай как у всех"
3. Смотрите на пару шагов вперед, чтобы проблемы не застали вас в расплох
4. Обращайтесь за экспертизой к тем, у кого она есть.
5. Не ломитесь к цели сломя голову. Лучше прийти к цели шаг за шагом чем наебнуться на бегу в яму.
6. КРИТИЧЕСКИ ОТНОСИТЕСЬ К СОВЕТАМ В ИНТЕРНЕТЕ

Мои советы основываются на 8ми годах комерческой разработки, в течении которых я наступал на многие грабли из того, что автор выдаёт за советы.

Чтобы быть инди не обязательно быть идиотом.

Ответить
2

Как боженька смолвил

Ответить
2

Отличный пост вместо ОП.
Но его стоит похвалить в одном (и тут не поругали за это) - абзац про сильные и слабые стороны в целом правильный. Правда, актуален только для соло-разрабов.

Ответить
0

Вы свои проекты делали или outsource?

Ответить
0

и то и то плюс разработка продукта

Ответить
27

Нет, не нужно. Такой путь мышления - ошибка. Не трате время на это бесполезное занятие, оно не приведёт вас к более быстрому релизу.

Аргументировать я это, конечно же, не буду (с)

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

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

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

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

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

Ответить
7

У автора поста за плечами пара VR-прототипов из низов библиотеки Стима, ни о каких играх с полноценным продакшеном здесь речь не идет. Откуда столько гонора - неизвестно.

Ответить
2

Ну давайте поаргументируем друг друга.
Если ваша цель написать идеальный академический код, то значит вы вылизываете его до потери сознания. Если ваша задача - разработать игру, то вылизывая код вы не движетесь к этому, а стоите на месте т.к. рефакторинг != имплементация нового функционала.

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

Как раз таки наоборот если вы НЕ будете строить огромные монструозные конструкции из сотен уровней абстракций, то реализация нового функционала будет занимать у вас меньше времени. Сложнее выпиливать подсистемы, а не писать\интегрировать новые.

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

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

Ответить
5

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

Я сказал, что нужно планировать и продумывать наперёд. Не знаю, про какой "академический код" вы говорите.

Как раз таки наоборот если вы НЕ будете строить огромные монструозные конструкции из сотен уровней абстракций

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

У вас типичное заблуждение человека, который не может побороть в себе проблему преждевременной оптимизации

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

Ответить
3

Тогда мы говорим с вами о разных вещах. В статье ведётся речь про рефакторинг с целью довести до идеала код (так называемого "академического" состояния).
Думать наперёд никто не запрещает, но нужды использовать всё "здесь и сейчас" нет.
Мой мессейдж всего лишь в том, что если вы создаёте велосипед, то создавайте его. В будущем возможно вам потребуется добавить к нему электромотор, но если ЗДЕСЬ И СЕЙЧАС вам это не требуется, то не нужно тратить на это время.
Иными словами: ложка дорога к обеду.

Ответить
6

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

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

код пишут не для программистов и не для игроков, а для себя.

Ответить
2

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

Ответить
1

да, спасибо, "оформляют для себя" и имелось ввиду, так более правильно

Ответить
12

Если ваше творение не завоевало аудиторию, не выполнило поставленные вами цели, то это не значит, что пора идти на завод.

Тут следует помнить, что жизнь всё-таки конечна и количество попыток ограничено. Если в среднем разработка игры занимает 5 лет, то у человека всего 8 попыток до того, как ему стукнет 60 и он станет стариком. Не так уж и много.

Ответить
7

На мой взгляд, такой расчет допустим если после каждой разработки тебе стирают память и ты начинаешь всё снова.
После 1-2 попыток ты в любом случае начнешь анализировать что ты делаешь не так, и что нужно сделать, чтобы стало так, потому что уже будешь располагать множеством данных.

Ответить
0

Не понимаю какая тут взаимосвязь с заводом. Можете более развёрнуто сказать?

Ответить
5

Перечитав понял, сорри.

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

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

Ответить
1

Чем ты моложе, тем больше у тебя сил и времени, чтобы пробовать что-то новое и работать на себя. С возрастом возможности снижаются, так что сугубо говоря, количество попыток еще меньше чем 8-мь, потому что 5 лет в 20 лет и 5 лет в 55 это не одно и то же, более старый участник будет работать медленнее и успеет гораздо меньше, чем молодой, к тому же ему будет мешать груз прошлого опыта. То есть если ты не получил требуемой отдачи в молодости, потом получить её будет еще сложнее и будет лучше пойти на "завод". Естественно, мы рассматриваем абстрактные случаи "в вакууме", в реальности может быть и по другому.

Ответить
10

С такими советами мы и получаем неоптимизированные игры в раннем доступе)

Ответить
0

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

Ответить
2

Забей, не программисты в 99.99% случаев не имеют ни малейшего понятия о том, что такое оптимизация. Они услышали это слово от блогера на ютубе (который тоже никакого понятия не имеет) и теперь просто используют его в любой ситуации. "Меня устраивает производительность" = хорошо оптимизировали, "меня не устраивает производительность" = плохо оптимизировали.

Ответить
9

Не трате время на это

Как баженька смолвил. Не трачу, закрываю статью, удачи котики.

Ответить
8

Переписывать нужно только то, что не работает

И то что работает слишком дорого с точки зрения потребления процессорного времени/памяти.
А если в команде хотя бы два программиста - говнокод уже самому себе выстрел в колено.

Ответить
3

Большинство фатальных проблем можно предотвратить изначально...Чего только стоят злощастные Update, Tick , UpdatePhysics функции и отрисовки Draw call, убивающий фпс на любом железе (проблемы 99% инди выживачей).

Ответить
0

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

Ответить
6

Народ не минусите этого парня, да тон не очень может, но такие статьи должны быть. Пжлст.

Ответить
5

Что значит быть инди разработчиком глазами инди разработчика.

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

Ответить
0

Настоящие разработчики

Это кто?

Ответить
0

Тоби Фокс например.

Ответить
0
the source code for undertale is literally just a bunch of rubber bands and tape stuck to a paper saying "DETERMINATION"
Ответить
1

Для меня служат вдохновляющим примером китайцы которые в одиночку разрабатывают серьёзные АА проекты. LostSoulAside (пока его сони не нашла), Thymesia, Bright Memory, Bloody Spell (не уверен что там один человек).
Статья как раз о тех, кто пишет игры

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

Ответить
1

Я вам привёл пруф того, что сам "настоящий разработчик" (по вашим ярлыкам) говорит, что его код низкого качества, а вы дальше маневрировать. Забавно.

Ответить
0

Каким образом качество кода влияет на оценку игры?

Ответить
0

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

Ответить
1

"Плохой код" Нотча потом ТАК аукнулся мододелам, что странно что Нотч от икания не помер. Он обещал нормальное моддинг-API, но так и не смог. Вот и думай после этого? Или главное что игра продалась? Но те идни о которых пишут в статье вроде не про это?

Ответить
0

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

Нотч давно уже не у руля, но его идея продолжает жить и это круто.

Ответить
0

Главное, что его идея была воплощена в жизнь

Лучше вообще ничего не выкладывать, чем множить белый шум, отнимать чужое время и нервы некачественным продуктом. Главная ошибка в инди, считать что твоя идея что - то стоит, просто по факту её существования.

Ответить
1

Даже не знаю... Ваше сообщение - это такой сильный инфантилизм или просто троллинг?

Ответить
0

"Главная ошибка на дтф, считать что твоя коммент что - то стоит, просто по факту его существования."
Сортируйте потребляемый контент, если вы так цените свое время. И за кого вы переживаете так, нервы тратите?

Ответить
0

Ну хм, что бы изменилось если бы Майнкрафт или Террария у которой такие же проблемы были бы сделаны качественнее и продуманее изначально? Конкуренты то не давили(потому их небыло). А игра бы в гораздо лучше форме. И для того что бы моды для Майнкрафта пилить не надо было бы иметь mid в java.

Ответить
0

Легко говорить сейчас.

Был ли код плох настолько? Если он прям был ужасен, то почему моды всё-таки делали? Если он был прям настолько ужасен, то почему игра всё же выжила?

Как и встречный вопрос: что бы изменилось если бы он сразу сделал качественное мод апи? Игра стала бы намного популярнее? (конечно нет, игра и так сверхпопулярная)

Ответ прост: Нотч понимал, что пишет игру для игроков, а не для программистов и писал такой код, который работает, а не какой-то эфемерный идеальный. Даже с таким кодом игра осталась расширяема, а значит этот код можно назвать good enough в контексте качества.
Как не крутите, кач-во кода это не цель инди игры и не по кач-ву кода игру судят, а по геймплею.

Ответить
1

Легко говорить сейчас.

Я люблю инди и играл в кучу игр в ЕА и прочее. И я знаю штук 20 отличных игр в плане идей, с катастрофически плохим техническим исполнением. В результате изначальное качество ниже плинтуса похоронило всю игру.
А сколько игр выстрелило у которых были технические проблемы изначально?

Ответить
0

Плохое исполнение в чём? Похоже вы путаете кач-во кода под капотом, которое скрыто от пользователя, с кач-вом кода, который отвечает за то, что пользователь видит (например, геймплей, игровые механики какие-либо и т.д. т.е. бизнес логика)

Ответить
0

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

Ответить
0

В статье нет ни слова о том, что инди должен писать high coupling, low cohesion код. Проблема, которую вы описываете не обсуждается в статье вообще.

Ответить
0

а значит этот код можно назвать good enough в контексте качества

Ох уж эти ваши программистские штучки))
Ради интереса - что потеряется, если сказать "код достаточно хороший", вместо "код good enough" ?

Ответить
0

Английский головного мозга. Бывает иногда, просто русские слова вылетают из головы)

Ответить
5

Кратко: положите болт на оптимизацию, не смотрите наперед и пишите костыли по мере их необходимости, вместо устранения ошибок.

Ответить
0

Кратко: положите болт на оптимизацию

Вы видимо читали другую статью раз такое пишите. Покажите где в этой статье идёт речь про такое.

Ответить
0

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

Хотел бы поинтересоваться, а какие игры вы издали? Спрашиваю без негатива и т.п., может мне стоит поменять свои взгляды или как-то иначе их воспринять.

Ответить
0

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

Ответить
0

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

И да, так какие проекты вы завершили?

Ответить
0

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

Ответить
1

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

Ответить
0

Есть пословица: "На зеркало неча пенять, коли рожа крива". Учитесь читать, а не додумывать и интерпретировать его в вольной форме.

Ответить
1

Хамло обыкновенное.
Главное - везде минусы проставьте, чтобы все знали.

Проектов озвучено не будет, я правильно понимаю?

Ответить
0

перековеркал слова автора поста

обвинил автора в "неправильном" тексте из-за того, что сам не смог прочитать чёрным по белому текст и понять его смысл

после этого обиделся и назвал "хамлом" автора за народную пословицу

Вы правда надеетесь на какой-либо диалог после этого? Повзрослейте.

Ответить
1

Текст, судя по комментариям, "не поняли" почти все. Про проекты я спросил ранее, вы так же тактично проигнорировали вопрос.

Скорее ваш материал и комментарии (как и трепетное отношение к своему мнению) кричат о том, что кому-то нужно если не "повзрослеть", так что-то поменять.

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

Ответить
–1

Текст, судя по комментариям, "не поняли" почти все.

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

Ответить
4

Насчет кода я до сих пор в сомнениях, но есть мысль по этому поводу.
То, о чем в комментариях спорят Andrey Apanasik и Netless - для меня это спор между enterprise-подходом (SOLID, паттерны, тесты, CI/Docker/настроенная рабочая среда) и RAD-разработкой (тратить время на скриптинг геймплея, а не на создание архитектуры, главная идея ты делаешь продукт, а не код), только вот я не поддерживаю обоих, которые пытаются зациклиться на чем-то одном доведя это до абсурда.
Они оба неправы, разъясню свою мысль, заодно открою тред (надеюсь более опытные люди поделятся мыслями).

Каждый подход имеет свой контекст и выбирать нужно исходя из ситуации. Какой-то период я не понимал, зачем вообще SOLID условный в геймдеве сингловом (не о f2p match3 online hypercasual mobile программах речь) нужен где время жизни продукта (в плане сопровождения) не такое большое чтобы заморачиваться о качестве кода для будущего расширения, но архитектура хорошая ведь должна позволять ещё и реюзабельный код писать по-хорошему.
Для меня такой пример это framework agnostic, не знаю есть ли аналог в геймдеве, но суть в том чтобы писать бизнес-логику, классы и архитектуру без привязки к фреймворку чтобы его можно было перенести легко на что угодно в идеале. Примерно с таким подходом можно писать код: да, это потребует больше времени чтобы развиваться как программист и выгоду свою такой подход к лейту только принесет, но тут уже дилемма самого разработчика. Лично я за то, чтобы стараться качественно писать, при этом стараясь соблюдать грань между RAD/Enterprise - потому что я знаю, каково удариться в крайность и начать писать на PHP блог, разработка которого затянулась на полгода за которые я в итоге написал MVC микрофреймворк из пакетов Laravel/Symfony.
Т.е нужно четко знать: можешь ли ты себе в этом проекте позволить тратить время на то, чтобы прокачиваться в этом направлении / развивать качество кода. Можно не заморачиваться и делать игры, но так ты упускаешь возможность писать качественный реиспользуемый код, на написание которого уйдет поначалу много времени (обучение + сам процесс написания), эта возможность в долгосрочной перспективе:
1. Ускорит разработку игр ближе к лейту;
2. Повысит твою компетенцию как программиста и ты сможешь работать в около-enterprise геймдеве на хорошей должности;

Главные проблемы:
1. Может затянуться срок разработки, если переборщить и слишком много акцента делать, можно начать не игру делать, а архитектуру.
Самое главное здесь не быть перфекционистом, потому что этот процесс ОЧЕНЬ болезненный.
По своему опыту знаю.
2. Серебрянные пули. Не всегда подобное требуется самому проекту, и не всем нужно развиваться как программисту, уходя в сторону "качественной" разработки - если вы геймдизайнер, который как инди просто вынужден совмещать одну из компетенций, то я думаю не стоит налегать на software engineering часть. Просто пишите RAD код, стараясь сделать его рабочим, потому что главная компетенция у вас другая, а в будущем при расширении просто найдете фрилансера-программиста который уже будет в этом шарить (его компетенция).

В итоге сам я больше склоняюсь к тому, чтобы:
1. Научиться делать таски, не слишком заморачиваясь о качестве кода (развивать умение делать дела/проект, чисто набитая рука на API инструмента который пользуешься, т.е шарить в RAD разработке на каком-то уровне;
2. Параллельно выделить время вне и в разработке на улучшение качества кода, постепенное; внедрять это так, чтобы минимизировать минусы того что ты код качественный пишешь вместо того чтобы игру делать (а минусы один хер будут, опять же, ты тратишь время на архитектуру и код который никто кроме тебя не увидит зачастую, в начальном этапе это бессмысленно и профит с такого ты сможешь получить когда научишься так писать, а это нескоро, при том профит в виде реиспользуемого кода который сэкономит время в будущем и развитии скилла чтобы ты мог в норм место свалить работать если с инди разработкой не выгорит).

Но лучше вообще хуй забить и аниме смотреть.

Ответить
2

Я придерживаюсь такого принципа:
Вначале разработки я создаю\готовлю инструменты, которые потребуются мне во время разработки, а потом просто пишу MVP. Если что-либо не работает, то я это привожу в рабочее состояние. Если где-то мне не хватает функционала, то я расширяю его. И всё. Это позволяет разрабатывать продукт быстро и не утопать в каких-либо вещах.

Долго запрягаю, но быстро еду, как говорится.

Ответить
0

Последнюю строку в начало в tl;dr вынести =)

Ответить

Комментарий удален

3

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

Бесезда, It just works!

Ответить
1

Просто тодд говард станет не нужным если они сменят движок . Все таки он он написал первые наброски движка из кусков Gamebryo.

Ответить
3

Идеальный код - это не идеальная игра.

Когда кодер 2 месяца делает "архитектуру" а ГД надо посмотреть прототип на играбельность и интересность геймплея, в топку такую разработку, потому, что:
- Если плейтесты покажут, что идея шлак , то код и возможно вообще всё, один хрен придется переделывать - а время "ПОТРАЧЕНО".

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

Плейтесты вскроют все пункты перечисленные в статье и еще парочку отсутствующих. Сэкономив время и нервы индюка.

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

Он так же указал, что это не относится к большим командам разработчиков, там правят бал другие стандарты (после прототипирования). Там с "твоим" кодом работать другим людям. И за говнокод и отсутствие пайплайна разработки в целом, могут и побить =D

Ответить
1

Кстати, как я понимаю отчасти поэтому, прототипировать не на том, на чем пишешь - защита от соблазна сохранить куски говнокода в релизе :)

Ответить
3

Не согласен с пунктом : верь себе .

Знакома ситуация когда вы рассказываете кому-либо идею своей игры в ответ вам говорят "Это будет не интересно"?

Идеи ничего не стоят и идут десять центов за дюжину — так что идеи пока вы не сделали прототип ничего не стоят .

Ответить
0

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

Ответить
1

Написано всё в целом правильно. Единственное что можно добавить - найдите способ зарабатывать хотя бы какие-то деньги. Т.к. жить и кушать надо на что-то.

Ответить
0

Последний текстовый блок - если убрать ненужное слово "слепо" - смысл не изменится, но будет отсутствовать некий оттенок фанатизма.

Ответить
3

Весь посыл в этом "фанатизме" и состоит. Без него легко можно свернуть с дорожки и забросить разработку.

Ответить
0

Хм, а я воспринял этот фанатизм с несколько негативной стороны..

Ответить
0

Инди - и есть фанатизм. Не те инди, что по 10 релизов в день делают, абы иметь свои 200 баксов в месяц. А вот именно те, что делают свою "игру мечты". Это и труба здоровью, и труба средствам...и вообще весело)

Ответить
1

Инди это желание работать на себя прежде всего.

Ответить
0

И таких работателей на себя - полный Стим сегодня) Это говно назвать Инди - язык не поворачивается

Ответить
0

С чего то нужно начинать или стартовать. Нельзя перепрыгнуть несколько ступенек просто так и сразу выдать А проект. К тому же покупать никто не заставляет. SIC PARVIS MAGNA )

Ответить
0

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

Ответить
0

Скорее так: работать на себя - одно из основных желаний.

Ответить
0

Адекватный текст. Но только именно про инди разработку. Заложенная идея раскрыта и при этом игра работает без критических багов - что еще нужно независимому разрабу без ресурсов и репутации?))

Ответить
0

Автор, я понял что ты хотел хотел донести, но также понимаю комментаторов, которые в шоке от такого подхода.

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

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

Ответить
0

Вы пишите код для игроков, а не для программистов.

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

Ответить
0

Да хоть на выложенные исходники :)

Ответить
0

*мимо*

Ответить
0

Статья выглядит так, будто автор искренне верит, что все проблемы решаются исключительно верой в себя и стремлением вперёд.

Ответить
0

Слова ради слов... пустые. Все проще. Если ты что-то не знаешь, то знаний нет до тех пор, пока не переживешь опыт, а потом применишь его. Потом ты не пишешь на эту тему статью, потому что знаешь, что она никому не поможет.

Ответить
0

Потом ты не пишешь на эту тему статью, потому что знаешь, что она никому не поможет.

Всё верно, пишут только те, кто не знают. Жаль, что Деннис Ритчи не дожил до вашего комментария...

Ответить

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovz", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]