Архив недели @Suvitruf
Понедельник
Привет, котята. Эту неделю с вами Ананасик @Suvitruf.
По профилю бекендщик (нода/ts), который порой работает в геймдеве (#unity). Пишу про игры и индустрию, популяризую тему разработки игр.
Эта неделя будет, по большей части, посвящена разработке игр.
Геймдевом занимаюсь уже лет 10. Веду:
- Сайт: suvitruf.ru
- VK: vk.com/gamedev_suffer…
- Телегу: t.me/gamedev_suffer…
- На DTF по большей части про геймдев и игры: dtf.ru/u/1922
Чёткого расписания нет. Пока предварительный план по дням:
Пара слов про геймдев.
Какой движок выбрать?
Кранчи.
Поиск денег.
Про оптимизацию.
"После разработки игр я не могу в них играть".
Что-то из личного опыта.
Начнём с базовых вещей. Как вкатиться в геймдев? Зачем? Почему не стоит? Обманутые ожидания и т. д.
Геймдев, по сути, то же IT, но тут почему-то у многих новичков очень идеализированные взгляды на индустрию.
Я, как и многие, мечтал делать игры ещё со школы.
Но в реальности тут очень много рутины. Как и у разработчиков, так у геймдизайнеров (которые ПРИДУМЫВАЮТ И СОЗДАЮТ МИРЫ).
И хорошо, если вы столкнётесь с тем, что в геймдеве просто сложно. Ведь скиллы и умения можно прокачать.
Но всё может быть несколько иначе...
И это не камень в огород мобильных игр (да, это он). Это про обманутые ожидания.
Реальность такова, что вряд ли на проекте вы будете заниматься по-настоящему креативной работой.
Это касается и разработчиков, и геймдизайнеров.
Факт в том, что в России сейчас преобладает мобильный геймдев, где в основе лежит копирование/клонирование.
И если вы не можете с этими смириться и не можете находить/придумывать интересные для себя задачи сами, то вас ждёт быстрое выгорание.
Поэтому рекомендую изначально над этим вопросом подумать.
Кому-то нравится именно процесс разработки. Даже если задача скучная, всегда можно что-то новое изучить, новые подходы, алгоритмы или ещё что-то.
Это всё зависит от вас. Не нужно ждать "интересных задач сверху".
Например, можно поразвлекаться с Блюпринтами в UE4 (¬‿¬)
Ну ладно. Мы уже поняли, что развлекать себя придётся самому. А как вкатиться то? Что изучать?
Программистам в этом плане попроще, т. к. они могут руку набить на пет проектах или поучаствовать в опенсорсе.
Но ведь "там нужны какие-то специализированные знание, матан с алгоритмами". Слышали такое?
На самом деле, вы почти не будете сталкиваться со всем этим в типовых задачах.
Правда жизни в том, что тормозить в игре будут совсем другие вещи.
К примеру, если мы говорим про Unity, то во многих играх лагает не физика или отрисовка самой игры, а GUI. Хотя, казалось бы, да?
Но про конкретные движки и оптимизацию мы ещё поговорим в другие дни. А пока вернёмся про то, как же начать.
Я лично в своё время работал над корпоративной системой документооборота, а параллельно изучал геймдев, делая клоны старых NES игр на LibGDX.
Даже туториалы делал suvitruf.ru/libgdx, за которые меня до сих пор благодарят.
Сейчас больно смотреть на эти уроки и код, но это хорошая отправная точка.
Поэтому советую завести блог на какой-либо из площадок.
Это поможет вам самим систематизировать многие вещи.
@itunderhood Ты лучше скажи прямо. Бывает ли геймдев без лютого говнокода? Я вот спрашиваю коришей, говорят, что не бывает. Тогда вопрос, как вы справляетесь? Какие техники есть, чтобы с этим жить? Кодегенерация? Жёсткие кодестайлы чтобы ограничить синтаксис и конструкции?
Это тема для целого треда, но нет, без говнокода не бывает (я не встречал).
Тут множество причин, на самом деле, но основная — сроки. twitter.com/unetwarm/statu…
На стадии препродакшена и прототипирования действительно можно написать красивую архитектуру, прям конфетку.
А потом, когда начинается стадия непосредственной разработки, всё идёт к чёрту.
Почему? У проектов бюджеты не бесконечны, сроки ограничены. А если это мобильная игра, то там очень важно выпускать частые апдейты.
У вас постоянно десятки тикетов, часть из которых на новый функционал, что-то о багах. В итоге вам нужно закрыть как можно больше за меньшее время.
Если поначалу вы даже как-то умудряетесь поддерживать хорошую архитектуру, то постепенно вкорячиваете костыли, обвязываете изолентой. Код превращается в монстра, технический долго растёт.
Шутки-шутками, но картинка полностью описывает ситуацию про "хуяк-хуяк и в продакшн".
Вы не подумайте, большинство это делает не целенаправленно. Кто-то даже умудряет писать тесты, которые покрывают часть базовых вещей.
Но в какой-то момент принципы изолированности настолько нарушаются, что тестировать компоненты отдельно друг от друга становится невозможно.
Да, люди обмазываются DI, в Юнити Зенжектом.
Но достаточно вкорячить какой-то один самопальный синглтон (очень часто это какой-нить GUIManager), который намертво связывает компоненты, что потом за рефакторинг этого дела никто уже не берётся.
А как же код ревью и вот это вот всё? Выделять 15 времени на рефакторинг? Штош
Я, правда, блог создавал с целью делиться знаниями с другими. Но пока пишешь статьи, то много информации перебираешь, что очень сильно и самому помогает.
А работодатели сейчас смотрят не только на твой Гитхаб профиль, но и на публичную деятельность.
"Личный бренд" — это не просто пустой звук. Ваше имя в какой-то момент будет работать на вас, если достаточно прокачать.
Возвращаясь к сложности... Если это простенькая 2d игра, то особых знаний математики не требуется, достаточно знать базу с векторами.
Всё остальное — это уже больше про логику.
А если на проекте занимаетесь UI, то вы даже векторами оперировать не будете.
Это я всё к тому, что для старта не нужны какие-то сверхъестественные знания того, как работает под капотом рендер и прочее. Да даже без знания многих фундаментальных вещей типа дроколов и прочего можно жить.
Всё этой можно набить за первый же месяц.
Тут вопрос лишь в том, готов ли работодатель брать человека на вырост. Мой опыт показывает, что даже небольшие студии могут на это пойти.
Тут ещё остаётся вопрос, готовы ли вы на старте на даунгрейд по з/п.
Видел примеры, когда люди перекатывались из IT (например, из банковской сферы) в геймдев с даунгрейдом в 2x по з/п и не жалели об этом.
Человек, любящий своё дело, довольно быстро пойдёт в гору. И если не сравняет, то, как минимум, приблизит з/п к прошлому уровню.
Что касается "вкатиться", то вам возможно даже не надо изучать именно геймдев, чтобы работать в геймдеве.
Студии частенько пишут внутренние инструменты. Так что, если вы фронтендщик/бекендщик, то можете слёту вкатиться.
Остаётся только как-то донести мысль до руководства, что им нужны эти инструменты🤔
Видели бы вы некоторые внутренние тулзы, которые пилят студии для своих нужд...
Ну ладно. Нет ревью, нету рефакторинга. Но ты ведь должен сам стараться "писать правильно и красиво"!
Да...но...на проекте вы не один. Задачи обычно распределяются так, чтобы они не пересекались.
В итоге достаточно, чтобы всего один тиммейт слегка наговнякал (этим тиммейтов вполне можете быть именно вы), чтобы попахивал весь проект.
А в будущем при доработках этот след растянется по всему проекту.
Тред #1
@itunderhood А в других видах разработки, конечно ограничений по срокам и бюджетам нет, ога шикарно! Классное оправдание говнокода, конечно. Тут больше похоже на проебы менеджмента среднего звена.
В небольших студиях ПМ'ы — это бывшие тестеры или разработчики. Т. е. это люди, которые просто взяли на себя эти обязательства.
Но просто лычки ПМ'а недостаточно. Тут нужны специализированные знания. Вот только, к сожалению, многие себя не утруждает прочтение книг на эту тему. twitter.com/huipizdajagurd…
Я вообще склонен считать, что кранчи (про которые мы поговорим в другой день) и сдвиги сроков — это чаще всего вина именно менеджеров.
А ведь многих проблем можно было б избежать, если прочитать хотя бы тот же «Мифический человеко-месяц» Брукса.
И это относится не только к менеджерам. Другим членам команды бы тоже не помешало почитать книги по управлению/планированию.
Это как общую грамотность повысит, так и поможет в понимании того, как работают процессы в команде.
И не надо думать, что разработчики хорошие, а ПМ'ы плохие, нет.
Просто у них уровень ответственности разный. Разработчики отвечают за свои задачи, а ПМ за проект.
Поэтому к ним требования и спрос в этом плане жёстче.
Тред #2
Представьте, что вам нужно написать туториал для игры. Я часто видел, как это всё хардкодилось. И если геймдизайнер решит что-то поменять, то он будет дёргать разработчика для этого.
Оптимально ли это? Часто ли будет меняться туториал?
А что мы будем делать в следующей игре? Хм, может стоит выносить это дело в какой-то конфиг? Хотя бы в видео Json'ов.
А может сделаем визуальную тулзу с кастомизируемым туториалом, которой смогут пользоваться ГД и не отвлекать разработчиков?
А вы знали, что не обязательно любить продукт, который ты разрабатываешь?
Я и в ИТ частенько встречал, когда людям отказывали, т. к. "они не горят проектом". Или по схожим дурацким причинам.
В геймдеве необязательно любить/играть в то, что ты пилишь. Особенно это касается мобильных игр (¬‿¬)
И это никак не сказывается на работе. Почему?
Потому что тебе платят не за любовь. Ты профессионал, который выполняет поставленные задачи.
Естественно, когда какая-то сложная задача или функционал, с которым ты не работал, то тебе может понадобиться поиграть в схожие игры, поискать рефы.
Но это обычный рабочий процесс.
Всё бы так, но, к сожалению, некоторых кандидатов отсеивают на первом же интервью, когда слышат, к примеру, что те не играют в мобильные игры.
Говорит ли это что-то о скилле разработчика? Мне кажется — нет (:
Тред #3
Я бы с радостью описал процесс, но с позиции геймдизайнеров, но, к сожалению, это не ко мне.
Про ГД могу лишь общие советы дать.
И главный из них: НАУЧИТЕСЬ РАБОТАТЬ С ДВИЖКОМ!
Нафантазировать вы себе можете что угодно, но куда важней, если вы это можете нормально объяснить, а ещё лучше — показать.
Поэтому в крупных студиях прямо в требованиях на вакансию ГД указывают, что нужно умение работать с движком.
Не нужно уметь писать код, достаточно базовых знаний. Полезным ещё будет изучение инструментов визуального программирования. В UE Блюпринты, а в Юнити есть Bolt.
Всё настраивается на уровне нод без кода вообще.
И, к слову, не обязательно это делать на том же движке, на котором пилится игра. Вот это неожиданность!
Для таких вещей может подойти что-то другое с низким порогом входа.
Например, Roblox. Там даже без кода можно много чего напрототипировать. Много компонентов есть из коробки, много чего сообщество уже сделало.
А если уж нужен код, то для логики там есть простой как пробка Lua.
Кстати, мы пока обсуждали то, как вкатиться в геймдев.
Но намного сложнее из него выкатиться.
Вот вам тру стори.
Меня однажды не взяли в IT компанию, потому что, цитирую: «У нас был опыт работы с людьми из геймдева, нам не понравилось. Поэтому больше с такими не работаем».
Тред #4
@itunderhood А потом для джейсона напишем свой парсер n^2 камень известно в чей огород
Для тех, кто не в курсе, в GTA Online из-за медленного парсинга JSON'а игра очень долго грузилась.
Rockstar выпустила патч только после того как энтузиаст нашёл проблемное место.
Его наработки позволили снизить скорость загрузки на 70%.
dtf.ru/gameindustry/6… twitter.com/W122ard/status…
@itunderhood Или, если у компании был негативный опыт (найм же тоже не бесплатный)
Это тоже. На самом деле, компания тратит много денег на найм сотрудниа.
Josh Sawyer, геймдиз из Obsidian, в своём докладе назвал сумму в 20-30к $. Столько компания (в США) тратит в среднем, пока не найдёт хорошего разраба.
youtube.com/watch?v=nHWvUm… twitter.com/madesst/status…
Вторник
И вот вы решили начать делать игры. Теперь встаёт вопрос: а какой движок выбрать?
Их с каждым годом становится всё больше и больше. Выбор не всегда очевиден.
Но для начала должен предупредить.
Часто можно услышать, что для мобилок стоит брать Unity, а для 3d на ПК — Unreal Engine.
Но сейчас и устройства стали мощнее, и UE прокачался. На мобилках есть та же Life is Strange, сделанная в UE.
А на Unity, к примеру, создана прекрасная Subnautica.
Главное — не берите CRYENGINE 😅
Я не зря сразу про платформу написал, так как это важно. Впрочем, как и то, в каком жанре и какого типа игру вы будете делать. Новелла? jRPG? Игра в открытом мире?
Эти вопросы нужно сразу решить для себя, прежде чем брать движок
Да, не всегда получится всё предусмотреть. Независимо от скиллованности команды.
Бывает и так, что движок приходится менять посреди разработки, как это сделали разработчики System Shock remake, свичнувшись с Unity на Unreal engine.
kickstarter.com/projects/15988…
Суть в том, что есть большая вероятность, что вам не нужны комбайны типа Unity и UE. Возможно подойдёт узкоспециализированный движок под конкретно вашу задачу.
К примеру, для визуальных новелл есть Ren'Py.
github.com/renpy/renpy
Вы, скорей всего, слышали про игру "Бесконечное лето". Она как раз была сделана на Ren'Py.
@itunderhood Слышал, что в Unity практически невозможно пользоваться на нормальном уровне без кучи плагинов. Какие плагины для тебя являются Starter Pack'ом, с установки которых ты начинаешь разработку нового проекта?
Ситуативно. В данный момент над простенькими играми работаю. Но вот плагины, которые всегда ставлю:
Odin Inspector.
I2 Localization.
Zenject.
TextMeshPro.
DOTween. twitter.com/VNimiod/status…
Для RPG есть небезызвестный rpg maker.
Тепло принятая многими To the Moon как раз на нём сделана.
Или ламповая OneShot.
Кому-то могут зайди конструкторы типа Roblox. Например, разработчик в своё время популярной VVVVVV планирует выпустить следующую игру на нём.
В Roblox куча компонентов из коробки и много всего от сообщества. Модельки, эффекты, клиент-серверное взаимодействие с репликацией состояния, инстансами серверными сам Roblox управляет.
Скриты на Lua.
Обычно вы видите в сети сомнительного качества игры на этом движке, но...
При желании там можно создавать довольно крутые штуки.
youtube.com/watch?v=KuqvxO…
Из недавних штук, похожих на Roblox, есть Core.
manticoregames.com
Но там можно использовать лишь готовые ассеты в отличии от того же Роблокса. Нельзя загружать свои модели/текстуры.
Для 2d игр я лично работал с libgdx.
libgdx.com
Компактный, быстрый. Но в то время это был, скорее, фреймворк, чем движок. Не было никакого визуального редактора, писалось всё кодом.
Не знаю как сейчас.
Слышали когда-нибудь про XNA framework? На нём выходило немало крутых 2d игрушек.
Salt and Sanctuary, Bastion, Dust, Terraria, например.
Тут уже не раз Godot советовали. Перспективный для 2d движок. Правда, они зачем-то сейчас очень сильно упарываются по 3d.
С ним я не работал, только слежу за новостями, чтобы пощупать 4.0, когда выйдет.
Из интересных проектов слышал только про Rogue State Revolution.
Для 2d ещё есть Defold. Писать нужно на Lua.
Легковесный, билды маленькие (раза в 3-4 меньше весят, что Юнитишные). Собрать можно почти под все платформы.
Из тех игр, что на слуху, можно назвать Family Island.
Но вы можете спросить, а почему мы обсуждаем лишь готовые движки? Разве никто больше не пишет свои? Почему?
Потому что рынок очень конкурентный. Пока вы пишете движок, другие разработчики создают игру на уже готовом.
Нынче собственные движки себе могут позволить либо крупные студии, либо очень прошаренные программисты.
Создать свой полноценный движок с тулзами для нормальной работы — это дело не на 5 минут.
Движки свои пилят, если людям явно не хватает готовых или возможности оных ограничены. Но, опять же, в этом случае обычно речь про игры AAA уровня.
Тред #5
Среда
Сегодня поговорим про кранчи и то, как они вредят индустрии и «сжигают» людей.
Кранчи — это длительные переработки, продолжающиеся неделями (а порой месяцами). В индустрии разработки игр довольно часто явление, особенно при разработке AAA-игр.
В начале этого года отдельную статью опубликовал. В этом треде тезисно пройдёмся.
suvitruf.ru/2020/12/31/827…
На написание оригинальной статьи меня натолкнули обсуждения игр, где люди не понимали вреда этого явления, а кто-то даже одобрял.
Большая часть исследований не относится непосредственно к геймдеву. Многие эксперименты были вообще задолго до появления индустрии видеоигр.
Поэтому выводы из оных применимы практически на любую деятельность.
Во всей этой теме два важных фактора — интересы бизнеса и люди. И ни с одной из сторон кранчи в долгосрочной перспективе не дают ничего хорошего.
Эксперименты на тему проводятся с начала 20 века. Всем известный Генри Форд проводил исследование продолжительностью в 13 лет.
Более продолжительные периоды непрерывной работы резко снижают когнитивные функции и увеличивают вероятность катастрофической ошибки.
Более века назад доктор Эрнст Аббе проводил наблюдения за рабочим. Как директор завода он сократил рабочий день с 9 до 8 часов и вёл тщательный учёт.
Его эксперимент подтвердил наблюдения 19 века: умеренное сокращение рабочего времени увеличивало общий объём производства.
Снижение с 12 до 10 часов приводит к увеличению суточной производительности; дальнейшее сокращение до 8 часов приводит, по крайней мере, к поддержанию этого значения.
Представим себе менеджера, который считает, что если сотрудник производит 16 единиц продукции за 8 часов, он должен произвести 18 единиц за 9 часов и 20 единиц за 10 часов.
И такие люди есть, к сожалению.
Реалистичное представление должно учитывать изменения в почасовой производительности, которые происходят в основном из-за 2 причин: физической и умственной усталости.
Сидни Дж. Чепмен в «Hours of Labour» (1909) привёл такую диаграмму.
Есть точка b, в которой большее количество часов не создаёт большей ценности. Фактически, после b каждый дополнительный отработанный час даёт отрицательное значение.
Майкл Уайт в 1987, опираясь на всесторонние исследования в инженерном, строительном и полиграфическом секторах, установил, что более длительная продолжительность работы, как правило, приводит к снижению долгосрочного равновесного уровня выпуска.
La Jeunesse в 1999 подробно описывает серию исследований в США, которые предоставили доказательства, подтверждающие, что увеличение продолжительности рабочего времени ведёт к долгосрочному снижению продуктивности.
При разработке Call of Juarez: The Cartel разработчики из Techland из-за усталости совершали ошибки, которые позже приходилось исправлять.
Люди работали по 7 дней в неделю. После окончания кранчей иммунная система некоторых просто отключалась.
gameinformer.com/b/features/arc…
В геймдеве в своё время после публикации ea_spouse в LiveJournal разговоры о качестве жизни в геймдеве обрели новую жизнь и актуальность.
ea-spouse.livejournal.com/274.html
Тысячи людей в сети приняли участие в обсуждении.
В 1920-х годах Генри Форд в течение нескольких лет экспериментировал с графиками работы и, наконец, в 1926 году ввёл пятидневную 40-часовую рабочую неделю с оплатой за шесть дней.
Эксперименты показали, что рабочие на его фабриках могут произвести за 5 дней больше, чем за 6.
При 60+ часовой неделе действительно заметен небольшой прирост. Это работает в течение нескольких недель, после чего, идёт ожидаемый спад.
Производительность падает при работе 60 часов в неделю по сравнению с 40-часовой. Первоначально дополнительные 20 часов в неделю компенсируют потерю производительности, и общий объем производства действительно увеличивается.
В исследовании Business Roundtable говорится, что производительность быстро падает при переходе на 60-часовую неделю.
curt.org/pdf/156.pdf
Примерно за два месяца совокупная производительность снизилась до такой степени, что проект действительно продвинулся бы дальше, если бы вы просто всё время придерживались 40-часовой рабочей недели.
Исследование 2017 года на сотрудниках колцентра показало — по мере увеличения часов среднее время обработки вызова увеличивается, агенты становятся менее продуктивными. Это говорит о том, что утомляемость играет важную роль даже при неполной занятости
ftp.iza.org/dp10722.pdf
Внушительный анализ на Gamasutra показал, что кранчи никоим образом не улучшают конечный результат игрового проекта и никак не помогают проекту выйти из затруднительного положения.
gamasutra.com/blogs/PaulTozo…
Может посмотреть на различные исследования. Интересны ещё исследования сна.
Например, довольно масштабной на эту тему было в армии США.
usafa.af.mil/jscope/JSCOPE9…
Непрерывная работа снижает когнитивные функции на 25% каждые 24 часа. Несколько ночей подряд имеют серьёзный кумулятивный эффект.
Дизайнер Клинт Хокинг, работавший по 70-80 часов в неделю над Splinter Cell: Chaos Theory, писал про потерю памяти в результате стресса и беспокойства, связанного с разработкой игры.
web.archive.org/web/2016030421…
В исследовании около 6000 британских гос. служащих, за которым наблюдали в течение примерно 10 лет, работа от 3-х или более часов сверхурочно в день была связана с 60% повышением риска сердечных заболеваний, включая приступы, стенокардию и смерть.
webmd.com/heart-disease/…
В период кранчей возрастает % ошибок. Тесно связаны между собой усталость и несчастные случаи на производстве.
В первые часы работы, количество несчастных случаев невелико, и это число снова уменьшается после длительных пауз.
psychclassics.yorku.ca/Munster/Indust…
Анализ Британского психологического общества показал, что сотрудники, страдающие выгоранием, демонстрировали более спонтанные и нерациональные решения.
И с большей вероятностью избегали принятия решений.
sciencedaily.com/releases/2015/…
Более того, согласно исследованию Британского медицинского журнала, сотрудники, которые работают более 48 часов в неделю, с большей вероятностью будут злоупотреблять алкоголем.
sciencedaily.com/releases/2015/…
Было много всяких крупных трагедий из-за недосыпа. В том числе и в заключении Комиссии Роджерса (об аварии космического корабля «Челленджер») указывал на недосып.
history.nasa.gov/rogersrep/v2ap…
Про сон есть хорошее видео от AsapSCIENCE.
youtube.com/watch?v=fuvbS7…
А что насчёт восстановления?
Работа больше 40 часов в неделю, независимо от разбиения, приводит к необходимости восстановления. И период восстановления обычно больше периода кранчей.
В разгар кранча вы можете усиленно работать. А потом попытаетесь себя убедить, что это было правильным решением.
Но фактическая продуктивность оказывается куда ниже воображаемой, что нивелирует всю затею переработок.
Причина этого в том, что даже если люди выполняют больше реальной работы, когда люди работают более 35 часов в неделю, они дорого обходятся в производительности.
Стоит вам времени, энергии и денег на исправление ошибок.
Из-за неправильных решений на более высоком уровне, которые вы принимаете.
Дорого обходится из-за возможностей, которые вы упускаете из-за того, что слишком сосредоточены на своей работе и слишком напряжены.
La Jeunesse предполагает, что более короткая рабочая приведёт к повышению производительности.
Работая меньше, у сотрудников появляется больше времени на то, чтобы поправить своё здоровье, вкладывать средства в свое обучение, они больше отдыхают.
employment-studies.co.uk/report-summari…
В 2017 в Швеции провели 23-месячный эксперимент, в котором участвовали 68 медсестёр в двух группах.
Исследователи заметили, что медсёстры работали более эффективно, имея на два часа меньше в своем ежедневном графике.
washingtonpost.com/business/econo…
В Новой Зеландии компания, которая попробовала четырехдневную рабочую неделю, утверждает, что люди были более творческими, пунктуальными и более энергичными.
businessinsider.com/four-day-workw…
Если подвести итог, то объективно можно сказать, что кранчи вредят. Какой-то профит есть, когда кранч длится недели 3 (перед релизом, когда жопа горит), а потом команда отдыхает. Но такое редкость, ведь после релиза нужно поддерживать игру.
Так почему кранчи продолжаются?
@itunderhood Перегруженные менеджеры по закупкам, начинают закупать материалы с запасом, чтобы оттянуть момент следующего заказа, что ведёт к проблемам с оборачиваемостью и складированию денег на склад.
Или начинают докидывать людей в команду, надеясь, что это ускорит разработку.
Но по факту это не работает. Особенно, когда жопа горит. При добавлении нового человека общая продуктивность команды может не то, что не ускориться, а даже замедлиться на какое-то время. twitter.com/1984XI/status/…
Отличный тред. Мне очень надо было денег, я их заработала. А ещё кучу проблем со здоровьем и дикое выгорание. Из-за сочетания факторов теперь чудненько теряю заработанное twitter.com/itunderhood/st…
Всё так. Люди очень часто оперируют лишь краткосрочными целями.
А в долгосрочной перспективе все эти переработки (пускай и с 2x+ оплатой), могут в копеечку влететь. twitter.com/AnastasVor/sta…
Очевидно, что кранчи не закладываются в родмеп. Но когда настаёт понимание того, что сроки профуканы, люди начинают кранчить. Неделю...потом ещё...потом "не ещё одну".
Тут уже и мнимая надежда, и проблемы в планированию выползают.
Проблема не возникают внезапно. Это планомерный процесс. Хороший менеджер должен такие вещи отслеживать.
Недельные митинги, месячное подведение итогов и прочее-прочее. Не успеваете? Делаете фичекат.
Я склонен считать, что по большей части всё из-за проблем с планированием.
Кидал уже ссылку на доклад Джошуа Сойера из Obsidian.
Он там приводит примеры из практики. Один из таких: они ещё на ранних стадиях при разработке Fallout: New Vegas выделили части/фичи, которые они спокойно смогут выкинуть, если не будут успевать.
youtube.com/watch?v=nHWvUm…
И ведь проблема то, на самом деле, не в том, что вы на лечение потратите много денег. Последствия могут иметь долгосрочный характер.
Некоторые разработчики игр уходили из индустрии на годы, как это, к примеру, было с людьми, работавшими над Fable.
После 6-7 дневных рабочих недель по 12+ часов к окончанию работы над проектом люди были попросту опустошены.
polygon.com/2016/6/1/11820…
Проблема с коллективным акком в том, что я со многими мыслями прошлых авторов не согласен.
К тому же, я вижу реплаи к их твиттам, но в таком случае не ясно, как на них вообще реагировать.
Конкретно в геймдеве проблема с кранчами в том, что позиция людей из индустрии разная.
От порицания до одобрения, но в среднем люди рассуждают с позиции, что "кранчи — это неизбежное зло" и принимают как данность.
К сожалению, таких людей на руководящих должностях немало.
Из исследования Международной ассоциации разработчиков игр (IGDA): многие работодатели эмоционально давят на своих сотрудников, просят «приложить дополнительные усилия», «сделать это ради команды» и т. д, оправдывая нездоровое нарушение баланса между работой и личной жизнью.
Многие наверно слышали про ужасные переработки в Naughty Dog, которая до сих пор придерживается этой пагубной практики и «успешно» продолжала её при работе над The Last Of Us II.
kotaku.com/as-naughty-dog…
Но такое и в небольших студиях происходит. Например, жёсткие кранчи были у разработчиков Mark of the Ninja.
digitalspy.com/videogames/a46…
Это не особо со сложностью связано. У инди-студии Supergiant Games, которые недавно выпустили топовую Hades, кранчей нет, текучки нет.
Грег Касавин, геймдизайнер студии, объясняет это сознательным вниманием к здоровью сотрудников и личному росту.
kotaku.com/the-secret-to-…
В Обсидиан (довольно крупная студия), про которых я уже писал, кранчей не было, насколько я помню, со времён Нью Вегаса, т. к. они упорно работали над этим вопросом многие годы.
Чад Гренье, геймдиректор Apex Legends, выступает против кранчей и говорит, что Respawn отказывается принуждать команду к этому, чтобы доставлять контент быстрее.
gamesindustry.biz/articles/2020-…
Морган Джаффит, креативный директор Defiant Development, разработавшей Hand of Fate, говорит, что практики кранчей в компании вообще нет.
Руководство студии считает, что контрпродуктивно заставлять сотрудников перерабатывать.
Но вместо того, чтобы обсудить проблемы с издателем/инвесторами, многие студии предпочитают отмалчиваться и навязывать команде кранчи, т. к. иначе они могли бы вовсе потерять контракт.
kotaku.com/crunch-time-wh…
Тред #6
Четверг
А как учесть профессии, в которых ничего не производится? Есть способ. Интересная статья попалась (к сожалению, быстро не найду): количество осложнений операций в ночную смену выше, чем аналогичных (экстренных) в дневную. twitter.com/itunderhood/st…
Исследование, проведённое учёными из Гарвардской медицинской школы и женской больницы в Бостоне, утверждает, что работа более 24 часов заставляет стажёров совершать серьёзные медицинские ошибки и создаёт угрозу общественной безопасности.
latimes.com/archives/la-xp… twitter.com/MaraStrega/sta…
Сегодня поговорим о поиске денег на разработку своей игры (не только игры, на самом деле).
Многие почему-то думают, что за деньгами нужно идти к издателю. Чуть меньше людей знают, что есть ещё инвесторы.
Но есть и другие варианты.
Во-первых, издатель — это не про деньги, а про рекламу и продвижение. Вы пилите игру, издатель издаёт и занимается привлечением игроков и т. д.
И за это забирает от 50% прибыли.
Во-вторых, если издатель и готов вложиться в игру, то это не в виде инвестиций, а, по сути, в виде контракта. IP в таком случае частенько уходит издателю. В общем, весьма сомнительные условия.
Бывают исключения, конечно. Поинт в том, что не нужно идти к издателю за деньгами.
Есть ещё краудфандинговые площадки типа Kickstarter, в которые можно было пролезть во время бума несколько лет назад.
Сейчас это уже не про деньги, а про привлечение аудитории.
И так...инвесторы и венчурные фонды. Во-первых, тут вкладываются в команду, а не проект. У всех условия разные. Но адекватные инвесторы берут малую долю от компании, чтобы не демотивировать людей.
Есть и фонды вроде того, что есть у Мейла, там, насколько я помню, Мейл забирает контрольный пакет. И вы, по сути, начинаете работать на них.
Смотрите на условия и имейте чёткое понимание того, чего вы хотите.
Если вы думаете "вот получу деньги, а потом свалю и буду сам пилить игру", то не выйдет.
В договор вписывается на такой случай нонкомпит на год-два, в течение которых вы не сможете разрабатывать игры.
А теперь поговорим про самую интересную, как по мне, часть. Как минимум, потому что я через это прошёл лично.
С игрой можно податься в акселераторы. Что?! Но ведь это про стартапы! А чем разработка игры не стартап?
Несколько лет назад я публиковал статью про нашу команду.
Мы с игрой прошли через несколько акселераторов, в том числе и через самый крупный в мире — @ycombinator.
dtf.ru/gamedev/10999-…
Бизнес-акселератор — это организация для менторства и поддержки стартапов. Какие-то из них ещё инвестируют в команду на сид стадии.
В России есть ФРИ, например. Крайне не рекомендую.
iidf.ru
Я не буду особо останавливаться как мы к этому пришли. Но суть в том, что в какой-то момент мы начали рассылать письма к эти акселераторы и проходить интервью.
Это интервью по видео-конференции. Иногда (как в случае с @ycombinator), вас попросят прилететь для очного собеседования. В случае с YC они вам оплатят расходы (перелёт + жильё).
Первым нашим акселератором стал Flat6Labs business accelerator in Abu Dhabi.
Нас там знакомили с менторами, различными партнёрами и максимально пытались помочь.
Ну и да, за процент от компании дают посевные инвестиции.
flat6labs.com
После демодня (когда ты презентуешь проект сотням потенциальных инвесторов) мы вернулись в Россию.
После чего нас как раз приняли в YC, и мы полетели в США на несколько месяцев.
Сейчас они дают $125k pf 5-10% от компании.
Кстати, чтобы вы понимали уровень нашего прототипа, вот с таким тизером мы подавались в f6s.
Это я к тому, что не нужно иметь супер навороченный проект, чтобы пробовать податься в такие программы.
youtube.com/watch?v=QGwdtm…
Под конец игра выглядела уже так.
У Y Combinator фишка в сети контактов. Мы, к примеру, ездили в офис Bandai Namco US и общались с ними по поводу игры.
Фотка из офиса 😅
В другой раз общались с CTO из Machine Zone, авторами популярной в своё время Game of War.
@itunderhood А как вообще делаются могильные игры? Я мобилки не люблю, но кажется что там есть деньги, если самому проектом заниматься, а не просто работать на кого-то. Озвучишь технический стек той игры? И сколько людей нужно? Что они должны уметь? Возможно людям это интересно
Игра была на Unity. Серверные инстансы (комнаты игровые) тоже, просто собранные в headless режиме. Оркестратор над ними на Java. Матчмейкер на Java, апишка частично на Java, частично на ноде.
Базу использовали RethinkDB, а для кеша Redis.
Первое время было всего 3 разработчика. twitter.com/wjYggOHT9qqDsD…
Первые год-два было два человека на Unity, на бекенде только я. Под конец ещё 2-х Юнитишников наняли.
Денег в мобилках много. Все эти f2p. Но это не значит, что ваша игра будет зарабатывать. Рынок очень конкурентный.
Нужны большие рекламные бюджеты или везенье.
Но это акселераторы, которые берут себе долю акций. Но есть ещё гранты. Да, есть страны и программы, в рамках которых вам дают деньги безвозмездно.
Одна из таких — K-Startup Grand Challenge.
Денег хватает как раз на з/п + жильё.
k-startupgc.org
Неплохой способ пожить в другой стране и развивать свой продукт. Приятное с полезным.
Были в похожей программе в Чили — Start-Up Chile.
Аналогично. Небольшой грант, которого хватает на з/п. Нужно было жить в Чили несколько месяцев.
startupchile.org
И, к слову, есть ведь акселераторы, которые специализируются на околоигровых темах. Например, SparkLabs.
Они сфокусированы на: облаках, гейминге, интернет технологиях и мобильном рынке.
sparklabs.co.kr/lb/index.php
Теперь из-за ковида многие подобные программы проводят практически полностью удалённо. Разве что, придётся съездить на демодень и, возможно, на подписание документов.
Если боитесь (или не можете) выезжать за границу, то сейчас это для вас не самым плохим вариантом будет.
Тред #7
Пятница
Сегодня обсудим извечную тему с оптимизацией.
Поговорим как про общие вещи, так и те, что относятся чисто к разработке игр.
Гифка выше из игры Horizon Zero Dawn. Фича называется Occlusion Culling и позволяет не рендерить то, что не попадает в область камеры.
Давайте на примеры неё обсудим сабж.
Эта фича, думаю, по дефолту включена во всех движках. Но если и нет, то как бы вы пришли сами к такому решению?
Если игра небольшая и объектов мало, то, вполне возможно, вам бы это никогда бы и не понабилось.
Но если объектов много, то в какой-то моменты вы бы заметили проблемы (падение фпс, как минимум). Начали бы профайлерить (если ещё не) и столкнулись с тем, что движок много лишнего отрисовывает.
Что дальше?
Ищем, как же сократить число объектов для отрисовки. Решение с тем, чтобы не отрисовывать всё, а лишь видимые объекты — логично.
Отлично. Проблема решена. Возможно...
А теперь посмотрим на этот скрин. Да тут же у нас отражения объектов, которые не попадают в камеру. Но мы их выгрузили. Или нет?
Как минимум, если нам нужны относительно достоверные отражения, то нужно оставлять информацию про геометрию и какую информацию о текстурах/цвете.
Как мы уже поняли, всё это держать в памяти не выйдет. И тут опять какие-то трейдофы будут.
На консолях, к примеру, RAM меньше, чем на ПК обычно. Нужно периодически, всё же, выгружать ресурсы из памяти. Что очень медленно, если у вас HDD (как было ещё на PS4 фат).
Да и с обычным SSD всё равно не получится это делать стримить.
Поэтому сейчас так много шумихи вокруг PS5, где стримить ресурсы с диска можно напрямую в память через спец. чип для распаковки, минуя CPU.
И вот все эти выгрузки/загрузки умудряются за кадры происходить в фоне.
Вы могли слышать про Ratchet & Clank, который выходит на PS5. Там эту фичу по максимум задействовали. И в порталах даже видны куски других миров, а не просто какие-то спрайты-болванки.
Даже текущие nvme на PC не могут такого выдать, т. к. всё тормозит декомпрессинг и проход через CPU.
К примеру, в RE8 на PS5 сейвы грузятся 2 секунды, у меня на PC с nvme около 4 секунд.
Порядок то вроде тот же. И в случае с сейвами это вполне приемлемо.
Но если вам нужно стримить ресурсы в рантайме, напомню, в рамках кадра-двух, то эта разница вам не позволит такое провернуть.
При разработки игр стоит точно такой же вопрос, как и в случае любого софта: нужно ли париться об оптимизации, если "premature optimization is the root of all evil"?
Многие фразу слишком буквально трактуют. Да и оптимизации же не только самого кода касаются.
Этот вопрос тесно связан с планированием и видением продукта. Нужно хотя бы примерно представлять, в каком направление будет развитие, чтобы на ранних этапах это заложить в систему.
Всё это, по сути, тоже часть оптимизации.
Тут ещё как следствие частенько всплывает то, что люди часто доходят до оверинженеринга, что по итогу может нивелировать всё их планирование.
Много раз сам ловил себя этом. Но про это в воскресенье расскажу.
Ещё интересный вопрос: как человек понять, что нужно что-то переделать? Как сформулировать проблему?
У всех ведь разный уровень. Кто-то только начинает.
Скажем, в Unity 5.2 была проблема с лишними аллокациями при обходе циклов итерраторами. Проблема? Ну...нет наверно, если это один раз за кадр. А если не один раз? А зависит ли это от числа элементов?
Скажем, новичок умудрился заметить это в профайлере. Что он будет гуглить? "У меня странные аллокации"?
Поэтому, если начинается работать с чем-то новым, то погуглите для начала всякие best practice для этой технологии/движка.
Это в будущем кучу времени сэкономит.
И помните: правильно поставленный вопрос — это уже половина ответа.
Не "почему у меня в игре лишние аллокации", а "почему при прогонке цикла с помощью итератора у меня лишние аллокации".
Если вы столкнулись с проблемой, то для описания нужно по максимуму сузить скоуп.
На том же StackOverflow раньше даже была причина закрытия для вопросов "Слишком общий", т. к. люди не могли выделить точно проблему. Как следствие, было сложно им помочь (почти невозможно).
И нужно задавать себе постоянно вопросы. Оптимизация — это ещё и про оптимизацию работы всей команды.
Если вы делаете синглплей платформер, то есть ли в планах локальный кооп? Если да, то возможно в будущем нужен будет мультиплеер с дедикейтед серверов?
В этом платформере явно будут абилки. Планируется ли даблжамп? Если такие вопросы не задавать, то левелдизайнерам придётся по нескольку раз перекраивать уровни.
А чардж в вохдухе? Отскок от стен? Представьте, сколько раз бы пришлось переделывать Hollow Knight, если бы все эти вещи не были продуманы изначально.
Многие вещи лучше заложить заранее. Особенно, учитывая, что в движках есть поддержка таких штук. В частности, хорошо бы оптимизировать модельки. В зависимости от расстояния грузить в отдалении LOD'ы с меньшим число вершим, чтоб не нагружать рендерер.
Вы даже не заметите разницы между такими модельками, а весть они будут в десятки раз меньше, вершин там может быть в сотни/тысячи раз меньше, что очень облегчает отрисовку.
По поводу LOD'ов был отличный доклад от разработчиков Assassin's Creed на GDC, где они кучу техник рассказали. И не только про LOD'ы.
youtube.com/watch?v=Rz2cNW…
В отдалении, к примеру, когда нужно отрисовать армии врагов, это вообще были не полноценные модели, а простые меши-болванки с простой анимацией.
На них даже физики никакой не висело. С ним нельзя взаимодействовать.
Даже всякие мелочи могут сильно ускорить кадр. Много полезных советов можно найти в этом видео про Unity.
youtube.com/watch?v=mQ2KTR…
Всякие базовые вещи типа работы с геттерами/сеттерами, кеширование трансформа, кеширование deltaTime, уменьшение операций с векторами, работа с массивами вместо списков и прочее.
Всё в сумме, в примере от разработчиков INSIDE, снизило время кадра со 106 до 10 мс.
Говоря про Unity (¬‿¬ )
В том же докладе ещё отмечается, что нужно тестировать на всех платформах, где будет издаваться игра. К примеру, в INSIDE синус в редакторе и на ПК (в их кастомной реализации) работал быстрее дефолтного, на Xbox медленней.
Это же касается и окружения. Если вы пишете бекенд, то настройте такое же окружение, как на удалённом серваке.
Если на сервере nginx, то запускайте локально nginx. Не apache. Не какой-то dev-сервер. Именно nginx.
Желательно ещё работать под той же ОС (или в виртуалке).
В геймдеве чуть ли не в абсолют возведена практика предвычисления значений, а потом поиск их по таблице/хешмепе. Синусы, косинусы, поиск по графам и прочее, прочее.
Жертвуя памятью вы очень ускоряете многие вещи.
Зачем нам каждый раз прогонять алгоритм поиска пути, если у нас статичная карта и можно просто закешировать уже вычисленные пути?
Или для относительно статичных уровней использовать штуки типа Навмешей, которые всё (ну, почти) сделают за вас.
docs.unity3d.com/Manual/nav-Nav…
В реалтайме очень ресурсоёмко просчитывать свет и тени, поэтому используются различные техники, когда свет запекают в лайтмепы.
Особенно полезно для мобилок.
learn.unity.com/tutorial/confi…
Про свет в Unity был отличный доклад прошлым летом.
youtube.com/watch?v=hMnetI…
В Silent Hill был туман, ограничивающий видимость.
В Witcher 3 уровни проектировались так, чтобы ограничить обзор игрока.
Об этом и многих других трюках можно в этом докладе с GDC узнать.
youtube.com/watch?v=9vEfH9…
Я сам вряд ли смогу когда-либо поработать над такими крутыми проектами, но очень интересно читать/смотреть за тем, как люди побеждают технические проблемы.
Очень вдохновляет.
youtube.com/watch?v=wavnKZ…
Тред #8
Суббота
"После разработки игр я не могу в них играть". Такое очень часто можно услышать от разработчиков игр.
Кто-то говорит, что "хобби перестаёт быть хобби, когда становится работой".
У нас ещё часто используют термин "игровая импотенция" (хотя это не только про разработчиков).
Всё это очень индивидуально. Кто-то, работая над играми, потом начинает везде видеть косяки отрисовки: "я не могу смотреть на эти лесенки", "в этой игре SSR убог", "в этой игре нет отражений персонажа в зеркалах".
Лично мне опыт разработки позволяет понимать многие технически вещи/трюки, которые другие разработчики проворачивают. Это очень вдохновляет и подогревает интерес к игре.
Из последнего — The Last Of Us 2. Это всё скрины с фатки PS4.
Сколько усилий было вложено, чтобы выжать максимум из устаревшего железа. И при этом в игре почти не было дропов по ФПС.
Опыт позволяет на многие вещи иначе смотреть, к каким-то проблемам/багам относиться с пониманием.
Лично для меня разработка игры не было проблема для, собственно, игры в любимые тайтлы.
Разве что, я совсем перестал играть в мобильные дрочильни и прочие f2p игры. Понимание того, как там устроены пейволы и прочие механики на выкачивание денег, полностью отбивают желание к ним прикасаться.
Бывают периоды, когда совсем не хочется играть, которые могут длиться годами. Но я не думаю, что это связанно именно с проф. деятельностью. Это больше про усталость и стресс.
А эти вещи присущи любой деятельности и сфере.
Так что, основной совет сего треда — не перенапрягайтесь и, блядь, научитесь отдыхать!
Я об этих вещах ближе к 30 начал задумываться, когда из-за вечного стресса и напряжения перестал получать удовольствие от каких-то базовых вещей.
Стал чувствовать себя какой-то амёбкой.
По молодости ты готов инвестировать своё время, нарабатывая репутацию, скиллы, деньги.
Но какой в этом толк, если тебе по итогу это не приносит особого удовлетворения и ты не можешь этими вещами воспользоваться, чтобы просто наслаждаться жизнью?
У меня был период, когда не хотелось вообще игры трогать. Но я просто садился и через силу себя заставлял наслаждаться (как бы парадоксально это не звучало).
Через какое-то время втянулся и снова стал удовольствие получать. Сейчас прохожу беклог, который разросся за эти годы
Тред #9
Воскресенье
Сегодня день на расслабоне, поэтому поделюсь всякими капитанскими советами, многие из которых из личной практики.
Некоторые из этих ошибок/просчётов стали причиной закрытия нашего стартапа.
Отсутствие задокументированного плана/родмепа.
Если вы как-то свои цели документируете, то потом сложнее их менять. А если вы, всё же, их меняете, то есть тому подтверждение.
Когда же это всё только в вашей голове, то вы постоянно будете отклоняться от выбранного курса.
Это очень важно и в геймдеве, и просто у стартапов. Тут ещё можно про MVP рассказать.
Но, как по мне, лучше посмотреть одно видео от Майкла (одного из создателей Твича).
youtube.com/watch?v=1hHMwL…
Сложность проектов не должна резко скакать. Мы резко переключились с небольших сингловых игр сразу на MOBA с потенциально большим онлайном.
Из-за этого прошли через всевозможные ошибки и кучу шишек набили.
Нужно было сначала взяться за проект поменьше.
Если же вы взялись за что-то новое и у вас не хватает опыта, то не стесняйтесь найти ментора или того, кто вам на этом пути поможет.
Самый глупый вопрос — это незаданный вопрос.
Не экономьте на специалистах. Если у вас в команде нет бекендщика/девопса, то, вполне вероятно, лучше нанять отдельного человека, чем кому-то из текущих фронтендщиков начинать это дело изучать.
Быстрые итерации и mvp на первых порах. Зачем вам k8s или другая подобная система на первых порах? Вполне возможно, что сервисные инстансы можно запускать ручками. И виртуалки поднимать ручками.
А уже потом по мере роста переводить всё на новую инфраструктуру.
Сказал вам человек, который на первых порах все виртуалки настраивал с помощью bash-скриптов.
К счастью, через какое-то время я изучил Ansible и, как минимум, процесс диплоя стал куда проще и приятней.
Правильно ли я поступил, что сначала по-быстрому наговнякал скрипты на баше, а должен был взять Ansible или Puppet? Стоил ли Ansible тех время затрат, что я на него потратил?
Думаю, да (:
А вот о том, что кучу времени потратил зря, пытаясь прикрутить Apache Mesos или Kubernetes (который на то время был в бете), жалею.
Для меня это было полезно в плане расширения кругозора, конечно, но для компании/стартапа никакого толка.
Перед использованием какой-то технологии почитайте подробно про возможности и лимиты. А так же прогоните под стресс-нагрузкой.
У нас, к примеру, при определённой нагрузке кластер Rabbitmq просто разваливался.
Если в инфраструктуре есть какие-то кластерные штуки или мастер-мастер/мастер-слейв сервисы, то не поленитесь провести тесты того, как система себя поведёт, если ноды откажут.
Мы так обосрались с Redis'ом и consul'ом, т. к. там фолбек не сработал нормально.
И не забудьте убедиться, что сервисы, которые юзают Редис/Консул и т. п, нормально динамически справятся с тем, что там сменился мастер.
Совет неоднозначный, но возможно вам не нужно всё держать/настраивать самим.
К примеру, может не стоит самим поднимать Графит с Графаной у себя, а использовать какой-то готовый сервис для метрик типа Datadog'а.
Дурацкое решение №1: мы в какой-то момент решили разделить игру по регионам. Да, когда у нас там играло полтора рудокопа.
В итоге куча времени на настройку, проверку. Потом ещё на написание механизма миграции между регионами.
Дурацкое решение №2: покупки на Твиче. Мы договорились с twitch'ом, чтобы на странице игры можно было совершать внутриигровые покупки.
После привязки Твич аккаунта к игровому, игрок мог получить эту награду.
Сил и времени потратил дофига, а покупок не было совсем 🤣
Дурацкое решение №3: Battle Royale режим. Да, на волне хайпа решили запилит такой режим. Но т.к. онлайн в игре небольшой был, то в этом режиме были практически одни боты.
Куча времени на этот режим, на AI. Оно того не стоило.
Почти всё можно свести к двумя вещам:
1 - Итерируйте быстро и не пытайтесь предусмотреть и реализовать всё.
2 - Но закладывайте возможность доработок и модификаций в будущем.
Многие почему-то к проектам относятся так, будто он у них единственный и обязательно должен выстрелить.
У некоторых основателей и/или игроделов выстреливает проект только после 10 провальных попыток.
Если не получается, просто отпусти, а оставшиеся ресурсы пусти на новый проект. У вас уже есть опыт, да и скил прокачался. Шанс успеха возрастает.
Пробуйте снова и снова. Когда-нибудь у вас всё получится.
Тред #10
Закончилась неделя, посвящённая геймдеву. Надеюсь, хоть какой-то из тредов оказался вам полезным. Спасибо за лайки, ретвиты и, самое главное, за интересные вопросы.
С вами был @Suvitruf. Всем хорошей недели, котята.
Ниже закину ссылки на всё, что обсуждалось на этой неделе.
Начнём с базовых вещей. Как вкатиться в геймдев? Зачем? Почему не стоит? Обманутые ожидания и т. д.
Как войти в геймдев, как выйти и т. д.
twitter.com/itunderhood/st…
И вот вы решили начать делать игры. Теперь встаёт вопрос: а какой движок выбрать? Их с каждым годом становится всё больше и больше. Выбор не всегда очевиден. pic.twitter.com/WcmMaTwwiZ
Про выбор игрового движка.
twitter.com/itunderhood/st…
Сегодня поговорим про кранчи и то, как они вредят индустрии и «сжигают» людей. pic.twitter.com/eCkkZoGKQA
Обсудили проблему кранчей/переработок. Не только в контексте игровой индустрии.
twitter.com/itunderhood/st…
Сегодня поговорим о поиске денег на разработку своей игры (не только игры, на самом деле). pic.twitter.com/hI7Nlqa7Hq
Про поиск денег на разработку своих проектов.
twitter.com/itunderhood/st…
Сегодня обсудим извечную тему с оптимизацией. Поговорим как про общие вещи, так и те, что относятся чисто к разработке игр. pic.twitter.com/uGWLGwOZiX
Про всякие трюки и оптимизацию.
twitter.com/itunderhood/st…
"После разработки игр я не могу в них играть". Такое очень часто можно услышать от разработчиков игр. Кто-то говорит, что "хобби перестаёт быть хобби, когда становится работой". У нас ещё часто используют термин "игровая импотенция" (хотя это не только про разработчиков). pic.twitter.com/O1rAhhciwe
О том, как разработка игр влияет на отношение к играми в целом и желание в них играть.
twitter.com/itunderhood/st…
Сегодня день на расслабоне, поэтому поделюсь всякими капитанскими советами, многие из которых из личной практики. Некоторые из этих ошибок/просчётов стали причиной закрытия нашего стартапа. pic.twitter.com/7fqdTXV5DF
Капитанские советы и примеры из личного опыта.
twitter.com/itunderhood/st…
Тред #11
