Что учить, чтобы вкатиться в геймдев?
#код
Как я упоминал ранее, вопрос «с чего начинать игровому программисту» один из самых частых, что я слышу. И сегодня я, как обещал, напишу развёрнутый ответ (чтобы потом на него всегда ссылаться) и даже расскажу оптимальную на мой взгляд последовательность действий.
Прежде всего, важно понять, как человек замотивирован. Самому человеку это, наверное, сложно определить; но мне по разговору и паре наводящих вопросов обычно удаётся отнести его в одну из двух групп.
Условно говоря, если человек хочет максимально быстро вкатиться в профессию, быть востребованным и получать хорошую зарплату; или у него есть Идея, которая принесёт ему миллионы; или же у него просто классный концепт игры, от которого его самого прёт, и он хочет явить её миру по фану — для всех этих людей у меня один ответ — учите Юнити и будет вам счастье.
Но если человек хочет всего того же самого, но не стать при этом юнити-программистом в плохом смысле слова и готов ради этого страдать продолжительное время, то ему стоит выбрать другую дорожку. И в этом месте может показаться, что это более правильный подход (мы же на харде привыкли играть, ага), но не нужно обманываться. Разница между группами принципиальная: если вы считаете, что главное игра, а как она там внутри написана неважно, то вам не по пути. Для вас есть Юнити. И не нужно себя ломать. Зачем зазря усложнять себе жизнь? Для тех же, кто остался, кому принципиально важно писать качественный код и быть хорошим программистом (с точки зрения других программистов, а не менеджера Васи), я предлагаю следующий маршрут:
#код
Как я упоминал ранее, вопрос «с чего начинать игровому программисту» один из самых частых, что я слышу. И сегодня я, как обещал, напишу развёрнутый ответ (чтобы потом на него всегда ссылаться) и даже расскажу оптимальную на мой взгляд последовательность действий.
Прежде всего, важно понять, как человек замотивирован. Самому человеку это, наверное, сложно определить; но мне по разговору и паре наводящих вопросов обычно удаётся отнести его в одну из двух групп.
Условно говоря, если человек хочет максимально быстро вкатиться в профессию, быть востребованным и получать хорошую зарплату; или у него есть Идея, которая принесёт ему миллионы; или же у него просто классный концепт игры, от которого его самого прёт, и он хочет явить её миру по фану — для всех этих людей у меня один ответ — учите Юнити и будет вам счастье.
Но если человек хочет всего того же самого, но не стать при этом юнити-программистом в плохом смысле слова и готов ради этого страдать продолжительное время, то ему стоит выбрать другую дорожку. И в этом месте может показаться, что это более правильный подход (мы же на харде привыкли играть, ага), но не нужно обманываться. Разница между группами принципиальная: если вы считаете, что главное игра, а как она там внутри написана неважно, то вам не по пути. Для вас есть Юнити. И не нужно себя ломать. Зачем зазря усложнять себе жизнь? Для тех же, кто остался, кому принципиально важно писать качественный код и быть хорошим программистом (с точки зрения других программистов, а не менеджера Васи), я предлагаю следующий маршрут:
1. Азы программирования.
Для начала вам нужно знать хоть какой-то язык программирования. Какой именно неважно. Главное, чтобы были переменные, функции, массивы и базовый навык их применения. Учили в школе паскаль? Прекрасно, освежите свои знания, написав сортировку пузырьком, и можете пропускать этот пункт. Говнякали сайты на джаваскрипт? Ещё лучше! Допивайте кофе и идите следом за паскалятами.
Если же знаний нет совсем, то лучше взять сразу C#. Учить надо по книге (не по ютубу). Обычно рекомендуют Герберта Шилдта, но можно и другого автора. Главное, делать упражнения из книги и побольше экспериментировать самому, а не просто читать.
Сколько это займёт времени, сильно зависит от вашего возраста и знаний. Чем больше, тем, в принципе, лучше. Хотя бы пару недель. Лучше месяц. Для закрепления и получения быстрых дофаминов можно скачать Юнити и написать какую-нибудь змейку по туториалам (но не увлекайтесь пока надолго).
2. Кресты.
То бишь C++. Да-да, без этого никуда. Углубляться сильно не нужно, но инклуды, классы, ввод/вывод и указатели освоить нужно. А также обзорно STL и шаблоны. Также по книге. Если хорошо знаете английский, то можно Tour of C++ почитать от Бьярна Страуструпа. Если нет, то, например, того же Шилдта. Главное, чтобы книга была относительно новая. Не раньше 2012 года, поскольку вам нужен как минимум С++11 (старый с++ учить смысла нет).
Если вы уже умеете программировать, то с этим пунктом можно справиться где-то за 4 дня плотного изучения. Если возникнут трудности, то, возможно, надо сменить книгу (ну, или вы рано перепрыгнули первый пункт).
3. Графон.
Теперь вооружившись знанием си, тратим недельку-другую на основы 3D-пайплайна по урокам NeHe или подобным. Нам нужно освоить хотя бы вывод треугольников, текстурирование и рендер-в-текстуру. Надо понимать фруструм- и фейс-кулинг, мипмапинг, ранний z-pass. Стенсил буфер факультативно. Лучше учить сразу с шейдерами, то есть OpenGL 3.3+, OpenGL 2.0+ или DirectX 10-11. OpenGL, мне кажется, для тех, кто больше математик (чтобы это ни значило), а DirectX — кто больше программист. Но ни в коем случае не берите DirectX 12 или Vulkan, чтобы раньше времени не спалить себе мозг.
Если шейдеры покажутся сложноватыми, можно сперва подучить более старые версии, где был Fixed Function Pipeline, а уже потом вернуться к шейдерам.
4. Шарп.
Если в первом пункте вы учили C#, то пропускаем. Если нет, то после крестов шарпик покажется лёгкой прогулкой. Он нам нужен для…
5. Unity.
Внезапно? На самом деле движок действительно отлично подходит для старта. Первую игру проще всего сделать именно на нём, как и найти первую работу. Но теперь у вас будет прививка от первичного идиотизма. Вы будете хотя бы примерно понимать, что происходит за кадром; будете представлять, что гуглить, когда возникнут графические артефакты.
6. Линейная алгебра.
К этому моменту, вы могли глубоко не вникать в матричные преобразования, думая о них, как о волшебных чёрных ящиках; но рано или поздно разобраться в подноготной стоит. Постройте матрицу перемещения, масштабирования и поворота в 2D. Разберитесь, как работает эта магия. Если хватит сил и терпения, изучите устройство матрицы перспективной проекции. Это очень полезные знания (про обычную геометрию и тригонометрию я вообще молчу: если вы не можете определить угол по двум сторонам, то в геймдеве вам придётся тяжко).
7. ???
В этом месте, когда вы уже сделали свой первый мобильный паззл или раннер, вы должны сами уже представлять, куда двигаться дальше: где у вас пробелы в знаниях или что вам более интересно. Может быть, вы захотите вернуться в лоно С++ и нырнуть поглубже по самое движкописательство; может быть, закопаетесь в графон или, преисполнившись праведного гнева к Юнити, уйдёте в Unreal. Это, в принципе, уже не столь важно. Главное, не становиться заложником одной технологии, а иметь хотя бы общее представление о том, что происходит за её пределами, и постоянно расширять кругозор.
Ну и Profit, как говорится.
Обсудить
Для начала вам нужно знать хоть какой-то язык программирования. Какой именно неважно. Главное, чтобы были переменные, функции, массивы и базовый навык их применения. Учили в школе паскаль? Прекрасно, освежите свои знания, написав сортировку пузырьком, и можете пропускать этот пункт. Говнякали сайты на джаваскрипт? Ещё лучше! Допивайте кофе и идите следом за паскалятами.
Если же знаний нет совсем, то лучше взять сразу C#. Учить надо по книге (не по ютубу). Обычно рекомендуют Герберта Шилдта, но можно и другого автора. Главное, делать упражнения из книги и побольше экспериментировать самому, а не просто читать.
Сколько это займёт времени, сильно зависит от вашего возраста и знаний. Чем больше, тем, в принципе, лучше. Хотя бы пару недель. Лучше месяц. Для закрепления и получения быстрых дофаминов можно скачать Юнити и написать какую-нибудь змейку по туториалам (но не увлекайтесь пока надолго).
2. Кресты.
То бишь C++. Да-да, без этого никуда. Углубляться сильно не нужно, но инклуды, классы, ввод/вывод и указатели освоить нужно. А также обзорно STL и шаблоны. Также по книге. Если хорошо знаете английский, то можно Tour of C++ почитать от Бьярна Страуструпа. Если нет, то, например, того же Шилдта. Главное, чтобы книга была относительно новая. Не раньше 2012 года, поскольку вам нужен как минимум С++11 (старый с++ учить смысла нет).
Если вы уже умеете программировать, то с этим пунктом можно справиться где-то за 4 дня плотного изучения. Если возникнут трудности, то, возможно, надо сменить книгу (ну, или вы рано перепрыгнули первый пункт).
3. Графон.
Теперь вооружившись знанием си, тратим недельку-другую на основы 3D-пайплайна по урокам NeHe или подобным. Нам нужно освоить хотя бы вывод треугольников, текстурирование и рендер-в-текстуру. Надо понимать фруструм- и фейс-кулинг, мипмапинг, ранний z-pass. Стенсил буфер факультативно. Лучше учить сразу с шейдерами, то есть OpenGL 3.3+, OpenGL 2.0+ или DirectX 10-11. OpenGL, мне кажется, для тех, кто больше математик (чтобы это ни значило), а DirectX — кто больше программист. Но ни в коем случае не берите DirectX 12 или Vulkan, чтобы раньше времени не спалить себе мозг.
Если шейдеры покажутся сложноватыми, можно сперва подучить более старые версии, где был Fixed Function Pipeline, а уже потом вернуться к шейдерам.
4. Шарп.
Если в первом пункте вы учили C#, то пропускаем. Если нет, то после крестов шарпик покажется лёгкой прогулкой. Он нам нужен для…
5. Unity.
Внезапно? На самом деле движок действительно отлично подходит для старта. Первую игру проще всего сделать именно на нём, как и найти первую работу. Но теперь у вас будет прививка от первичного идиотизма. Вы будете хотя бы примерно понимать, что происходит за кадром; будете представлять, что гуглить, когда возникнут графические артефакты.
6. Линейная алгебра.
К этому моменту, вы могли глубоко не вникать в матричные преобразования, думая о них, как о волшебных чёрных ящиках; но рано или поздно разобраться в подноготной стоит. Постройте матрицу перемещения, масштабирования и поворота в 2D. Разберитесь, как работает эта магия. Если хватит сил и терпения, изучите устройство матрицы перспективной проекции. Это очень полезные знания (про обычную геометрию и тригонометрию я вообще молчу: если вы не можете определить угол по двум сторонам, то в геймдеве вам придётся тяжко).
7. ???
В этом месте, когда вы уже сделали свой первый мобильный паззл или раннер, вы должны сами уже представлять, куда двигаться дальше: где у вас пробелы в знаниях или что вам более интересно. Может быть, вы захотите вернуться в лоно С++ и нырнуть поглубже по самое движкописательство; может быть, закопаетесь в графон или, преисполнившись праведного гнева к Юнити, уйдёте в Unreal. Это, в принципе, уже не столь важно. Главное, не становиться заложником одной технологии, а иметь хотя бы общее представление о том, что происходит за её пределами, и постоянно расширять кругозор.
Ну и Profit, как говорится.
Обсудить
Where in the World Is Carmen Sandiego?
#лайт
Знаете, чем хороши испаноязычные страны? Там вас будут звать сеньор, даже если на родине вы всего лишь джун. Ба-да-бумс!
К чему это я? В описании этого канала есть фраза «и немного о путешествиях», потому что когда я заводил его, я полагал, что буду делать всякие разные подводки к теме программирования через рассказы о своих поездках. На деле же оказалось, что я об этом совсем ничего не пишу, и, наоборот, чтобы заговорить о теме путешествий, мне нужно было рассказать анекдот собственного сочинения про сеньора (не закатывайте глаза: в баре за третьим бокалом пива эта шутка заходит отлично).
В общем, раз уж тема заморских стран заявлена на канале, а естественного случая рассказать не подворачивается, то давайте я просто время от времени периодически буду писать в лоб, где я есть.
В общем, в середине прошлого месяца я отправился на долгожданную зимовку по тёплым странам. Сперва, как это ни странно звучит, отправился на неделю в Питер (там просто расположен офис нашей студии и оттуда больше удобных рейсов, чем из моего домашнего Калининграда). Затем также недельку побыл сеньором в Испании, в городишке Малага, откуда родом Пикассо. Говорят, его музей стоит посетить ну просто обязательно; но вот я не советую: выставка очень маленькая и уж слишком на ценителя. Для меня кубизм с сюрреализмом могут быть весомым заявлением или, если угодно, перформансом в моменте времени, но как музейное произведение искусства для меня видеоигры всё же имеют больше художественной ценности, чем это.
Наконец, 10 дней назад я приехал в Тарифу, где зашёл на паром по своему многострадальному паспорту (мял в Мексике, мочил в Перу, терял в Исландии). На пароме я пересёк Гибралтар и сошёл в Марокко уже по другому паспорту (запасной загранник: без Шенгенской визы, но зато не в таком задроченном состоянии), где уже и нахожусь по сей день. Мароканцы, конечно, резко отличаются по менталитету от всех, кого я встречал. Чем-то неуловимо напоминает 90-ые в России. Но из самого примечательного в Танжере то, что, не смотря на то, что это Африка, тут всё же довольно холодно зимой по ночам. А отопления нет (ну, потому что Африка). Почему-то только сегодня догадался попросить у арендодателя апартаментов обогреватель. Теперь тут ок. Правда, сеньором здесь уже не называют.
Обсудить
#лайт
Знаете, чем хороши испаноязычные страны? Там вас будут звать сеньор, даже если на родине вы всего лишь джун. Ба-да-бумс!
К чему это я? В описании этого канала есть фраза «и немного о путешествиях», потому что когда я заводил его, я полагал, что буду делать всякие разные подводки к теме программирования через рассказы о своих поездках. На деле же оказалось, что я об этом совсем ничего не пишу, и, наоборот, чтобы заговорить о теме путешествий, мне нужно было рассказать анекдот собственного сочинения про сеньора (не закатывайте глаза: в баре за третьим бокалом пива эта шутка заходит отлично).
В общем, раз уж тема заморских стран заявлена на канале, а естественного случая рассказать не подворачивается, то давайте я просто время от времени периодически буду писать в лоб, где я есть.
В общем, в середине прошлого месяца я отправился на долгожданную зимовку по тёплым странам. Сперва, как это ни странно звучит, отправился на неделю в Питер (там просто расположен офис нашей студии и оттуда больше удобных рейсов, чем из моего домашнего Калининграда). Затем также недельку побыл сеньором в Испании, в городишке Малага, откуда родом Пикассо. Говорят, его музей стоит посетить ну просто обязательно; но вот я не советую: выставка очень маленькая и уж слишком на ценителя. Для меня кубизм с сюрреализмом могут быть весомым заявлением или, если угодно, перформансом в моменте времени, но как музейное произведение искусства для меня видеоигры всё же имеют больше художественной ценности, чем это.
Наконец, 10 дней назад я приехал в Тарифу, где зашёл на паром по своему многострадальному паспорту (мял в Мексике, мочил в Перу, терял в Исландии). На пароме я пересёк Гибралтар и сошёл в Марокко уже по другому паспорту (запасной загранник: без Шенгенской визы, но зато не в таком задроченном состоянии), где уже и нахожусь по сей день. Мароканцы, конечно, резко отличаются по менталитету от всех, кого я встречал. Чем-то неуловимо напоминает 90-ые в России. Но из самого примечательного в Танжере то, что, не смотря на то, что это Африка, тут всё же довольно холодно зимой по ночам. А отопления нет (ну, потому что Африка). Почему-то только сегодня догадался попросить у арендодателя апартаментов обогреватель. Теперь тут ок. Правда, сеньором здесь уже не называют.
Обсудить
Эпик стор и монополии
#лайт
Почему-то сам не догадался начать комментировать новости игровой индустрии. Это же просто неисчерпаемый источник лёгких постов! Благо, в чатике нашлось, кому подсказать.
Меня попросили сделать пост про Epic Game Store, но на днях случилось ещё одно важное событие в IT, с которым я бы хотел провести параллели. Я говорю про отказ Microsoft от собственного вэб-движка в пользу Chromium. И хотя юные фронтендеры сейчас пляшут от радости, это на самом деле очень печальный момент в истории развития интернета. Дело в том, что Edge не взлетал отнюдь не потому, что отображал сайты хуже, чем Chrome. Он не взлетал потому, что отображал их по-другому. С тех пор, как Chrome занял лидирующие позиции на рынке, он стал смелее отходить от вэб-стандартов и делать всё по-своему. Чем больше становилось отличий, тем чаще разработчики забивали на остальные браузеры и верстали их только под хром, а тот, в свою очередь, с ещё большей решимостью уходил от стандартов и делал так, как ему заблагорассудиться. Сначала сдалась Opera, теперь Microsoft. Остался лишь FireFox, который единственный во всём мире будет показывать сайты не так, как Chromium и потому на него ориентироваться будут ещё реже. Мы вступаем в эпоху нового IE6 и имя ему — Хром.
Сейчас он кажется неплохим браузером, но и IE6 был в своё время хорош. Вот только все настолько завязались на его нестандартные приколюхи, вроде ActiveX, что больше 10 лет не могли избавиться от его монополии. И хотя вокруг уже были новые современные технологии, всем ещё очень долго приходилось считаться с этим древним мамонтом. Да и по сей день существует огромное количество корпоративных приложений, которые ни в чём, кроме IE не запускаются. Спустя несколько лет мы можем оказаться примерно в такой же ситуации, хотя сейчас хром кажется добром. Потому что монополии это всегда плохо.
#лайт
Почему-то сам не догадался начать комментировать новости игровой индустрии. Это же просто неисчерпаемый источник лёгких постов! Благо, в чатике нашлось, кому подсказать.
Меня попросили сделать пост про Epic Game Store, но на днях случилось ещё одно важное событие в IT, с которым я бы хотел провести параллели. Я говорю про отказ Microsoft от собственного вэб-движка в пользу Chromium. И хотя юные фронтендеры сейчас пляшут от радости, это на самом деле очень печальный момент в истории развития интернета. Дело в том, что Edge не взлетал отнюдь не потому, что отображал сайты хуже, чем Chrome. Он не взлетал потому, что отображал их по-другому. С тех пор, как Chrome занял лидирующие позиции на рынке, он стал смелее отходить от вэб-стандартов и делать всё по-своему. Чем больше становилось отличий, тем чаще разработчики забивали на остальные браузеры и верстали их только под хром, а тот, в свою очередь, с ещё большей решимостью уходил от стандартов и делал так, как ему заблагорассудиться. Сначала сдалась Opera, теперь Microsoft. Остался лишь FireFox, который единственный во всём мире будет показывать сайты не так, как Chromium и потому на него ориентироваться будут ещё реже. Мы вступаем в эпоху нового IE6 и имя ему — Хром.
Сейчас он кажется неплохим браузером, но и IE6 был в своё время хорош. Вот только все настолько завязались на его нестандартные приколюхи, вроде ActiveX, что больше 10 лет не могли избавиться от его монополии. И хотя вокруг уже были новые современные технологии, всем ещё очень долго приходилось считаться с этим древним мамонтом. Да и по сей день существует огромное количество корпоративных приложений, которые ни в чём, кроме IE не запускаются. Спустя несколько лет мы можем оказаться примерно в такой же ситуации, хотя сейчас хром кажется добром. Потому что монополии это всегда плохо.
И вот теперь я бы хотел вернуться к Steam’у. Это тоже монополия и тоже очень плохая. Хотя бы потому, что берёт огромные 30% с разработчиков и делает вид, что это нормально. Игроки, конечно, любят Steam. Но надо помнить, что игроки — это аудитория, очень подверженная практически всем когнитивным искажениям, которые только существуют в природе. Это та аудитория, которая сломя голову бежит покупать на распродажах сотни игр, которые потом даже не запускает; и тратит на этом больше денег, чем если бы купила нужные ей игры по фулпрайзу. Эта та аудитория, которая постоянно жалуется на сломанный рандом, если он честный; и наоборот. Эта та аудитория, которая ставит минусы, если в игре нет локализации на их язык; и у которой гнев на милость к разработчику сменяется одним щелчком пальцев. Игроки в массе своей обычно всё новое встречают в штыки. Когда-то и стим не любили, а теперь к нему привыкли. Конечно, найдутся те, кто из принципа упрётся и будет делать вид, что ничего кроме стима не существует, как кто-то упирался и отказывался покупать игры в цифре, а не на дисках; но в целом ворчание геймеров можно игнорировать. Главное, какие у сервиса реальные рычаги влияния на рынок, а не то, что думают игроки по поводу его удобства.
А рычаги влияния у Epic Games Store есть. Во-первых, собственные эксклюзивы. Напомню, что именно с этого начал и сам Steam, когда это был единственный способ приобрести Half-Life 2. Да, эксклюзивы сейчас есть и у Origin и у Battle.Net, но всё-таки Dragon Age и Overwatch не идут ни в какое сравнение с Fortnite. Напомню, что это вторая по популярности (после LoL) игра на PC на данный момент в принципе. То есть у значительной части игроков магазин уже будет установлен.
Во-вторых, чужие эксклюзивы. В отличие от EA и Blizzard, у Epic Games есть доступный для других разработчиков движок. На Unreal Engine выходит огромное количество игр, и эпики вполне в состоянии предложить мелким и средним студиям эксклюзивное издание в их магазине в обмен на особые условия и помощь в разработке. В зоне риска в первую очередь всякая хайповая индюшатина.
Ну и наконец, разница в стоимости. Если игра, допустим, стоит в Steam 25$, то разработчик может поставить цену 23$ в Epic Game Store и покупки в последнем ему всё равно будут более выгодны. Потому что Steam берёт 30% комиссии, а Epic Store только 12%. Причём, если игра разрабатывалась на Unreal, то 5% комиссии уже включены в эти 12, тогда как в стим — нет. То есть в случае разработки на Unreal Engine цифры становятся 35% против 12%. Прямой демпинг в других магазинах стим, конечно, не допускает, но всегда возможны трюки со скидками, другими изданиями и релизными окнами.
Всё это вселяет надежды, что на этот раз удастся пошатнуть позиции Steam. Впрочем, Valve уже начали шевелиться и анонсировали особые условия с пониженной комиссией для наиболее крупных клиентов. Видимо, боясь, что иначе могут их потерять. Потому что монополия это плохо, а конкуренция — это всегда хорошо.
Обсудить
А рычаги влияния у Epic Games Store есть. Во-первых, собственные эксклюзивы. Напомню, что именно с этого начал и сам Steam, когда это был единственный способ приобрести Half-Life 2. Да, эксклюзивы сейчас есть и у Origin и у Battle.Net, но всё-таки Dragon Age и Overwatch не идут ни в какое сравнение с Fortnite. Напомню, что это вторая по популярности (после LoL) игра на PC на данный момент в принципе. То есть у значительной части игроков магазин уже будет установлен.
Во-вторых, чужие эксклюзивы. В отличие от EA и Blizzard, у Epic Games есть доступный для других разработчиков движок. На Unreal Engine выходит огромное количество игр, и эпики вполне в состоянии предложить мелким и средним студиям эксклюзивное издание в их магазине в обмен на особые условия и помощь в разработке. В зоне риска в первую очередь всякая хайповая индюшатина.
Ну и наконец, разница в стоимости. Если игра, допустим, стоит в Steam 25$, то разработчик может поставить цену 23$ в Epic Game Store и покупки в последнем ему всё равно будут более выгодны. Потому что Steam берёт 30% комиссии, а Epic Store только 12%. Причём, если игра разрабатывалась на Unreal, то 5% комиссии уже включены в эти 12, тогда как в стим — нет. То есть в случае разработки на Unreal Engine цифры становятся 35% против 12%. Прямой демпинг в других магазинах стим, конечно, не допускает, но всегда возможны трюки со скидками, другими изданиями и релизными окнами.
Всё это вселяет надежды, что на этот раз удастся пошатнуть позиции Steam. Впрочем, Valve уже начали шевелиться и анонсировали особые условия с пониженной комиссией для наиболее крупных клиентов. Видимо, боясь, что иначе могут их потерять. Потому что монополия это плохо, а конкуренция — это всегда хорошо.
Обсудить
Чё как вообще?
#лайт
Этот пост просто расскажет о том, какие у меня сейчас текущие проекты и чё вообще с ними происходит, чтобы вам было веселее читать этот блог и следить за моими успехами.
1. #Encased.
Это проект, которым я занимаюсь на работе. Он представляет собой RPG в стиле первых Fallout, которую мы пилим на юнити. Всего у нас 3 программиста и пока полтора скриптера (возможно, скоро будет больше), где я за главного, поэтому здесь иногда проскакивают посты об архитектурных решениях Encased. Работаем уже почти год, успешно прошли кикстартер и движемся к раннему доступу. На данный момент поиграть ещё нельзя, но можете пока добавить игру в список желаемого.
2. #Judy.
Это мой личный проект. Игровой движок, названный мной женским именем, и по совместительству мой самый главный и многострадальный долгострой. Я писал его вечерами активно в 2015-2016 годах, а потом временно заморозил в пользу рабочих проектов, что затянулось вот уже на два года. Этим летом, когда я начинал блог, я анонсировал, что возвращаюсь к движку, но как-то не пошло. Но последние две недели я снова предпринимаю попытки находить на него время, и похоже, что на этот раз таки удастся войти в рабочую струю.
В Джуди я делал реально крутые по моему мнению штуки, о которых не стыдно рассказать. С другой стороны, за это время я изменил взгляд на некоторые вещи, поэтому оставайтесь на связи, будет интересно. Сами «алмазики» можно подглядеть на github. Как это часто бывает с пет-прожектами, код там зачастую не самый лучший в виду урывочности написания, но ставить звёзды и фоловить не стесняемся :)
3. #GitTern.
Идея написать очередной клиент для git, заточенный под конкретные нужды, у меня родилась в феврале, когда мы только начинали работать над Encased и пытались подружить художников с системой контроля версий. Задумка потеряла актуальность, когда мы всей компанией перешли на PlasticSCM, но для своих личных нужд я всё равно, само собой, буду использовать git. И теперь, когда мне нужно комитить из разных операционных систем (Judy кроссплатформенный движок), я волей-неволей возвращаюсь к этой идее. Думаю, в самое ближайшее время добью его до минимального функционала и пересяду на него. В отличие от движка, который я пока не решил делать свободным, GitTern полностью open-source по MIT лицензии.
4. #Ameba.
Aggregate MEssage BAr — это агрегатор популярных мессенджеров и ещё один проект, о начале работ над которым я радостно раструбил в блоге, но который, похоже, пока ещё какое-то время полежит на полке.
5. Английский.
В числе личных проектов я также решил перечислить занятия английским, поскольку это непосредственно связано с моей прокачкой в профессиональном смысле. Сейчас я три раза в неделю занимаюсь с преподавателем онлайн, читаю Кинга на бумаге и собираюсь переводить этот блог на английский на Medium.
6. Ключевые слова Shodan’а.
Ещё один важный для меня проект по самопрокачке — пройтись по ключевым словам Андрея Аксёнова. Это, конечно, не прямое руководство к действию, но отличные дорожные ориентиры, по которым я всё собираюсь начать заполнять пробелы в своих знаниях, но никак не начну. Может быть, кто-нибудь из читателей тоже заинтересуется, и вместе будет проще?
Обсудить
#лайт
Этот пост просто расскажет о том, какие у меня сейчас текущие проекты и чё вообще с ними происходит, чтобы вам было веселее читать этот блог и следить за моими успехами.
1. #Encased.
Это проект, которым я занимаюсь на работе. Он представляет собой RPG в стиле первых Fallout, которую мы пилим на юнити. Всего у нас 3 программиста и пока полтора скриптера (возможно, скоро будет больше), где я за главного, поэтому здесь иногда проскакивают посты об архитектурных решениях Encased. Работаем уже почти год, успешно прошли кикстартер и движемся к раннему доступу. На данный момент поиграть ещё нельзя, но можете пока добавить игру в список желаемого.
2. #Judy.
Это мой личный проект. Игровой движок, названный мной женским именем, и по совместительству мой самый главный и многострадальный долгострой. Я писал его вечерами активно в 2015-2016 годах, а потом временно заморозил в пользу рабочих проектов, что затянулось вот уже на два года. Этим летом, когда я начинал блог, я анонсировал, что возвращаюсь к движку, но как-то не пошло. Но последние две недели я снова предпринимаю попытки находить на него время, и похоже, что на этот раз таки удастся войти в рабочую струю.
В Джуди я делал реально крутые по моему мнению штуки, о которых не стыдно рассказать. С другой стороны, за это время я изменил взгляд на некоторые вещи, поэтому оставайтесь на связи, будет интересно. Сами «алмазики» можно подглядеть на github. Как это часто бывает с пет-прожектами, код там зачастую не самый лучший в виду урывочности написания, но ставить звёзды и фоловить не стесняемся :)
3. #GitTern.
Идея написать очередной клиент для git, заточенный под конкретные нужды, у меня родилась в феврале, когда мы только начинали работать над Encased и пытались подружить художников с системой контроля версий. Задумка потеряла актуальность, когда мы всей компанией перешли на PlasticSCM, но для своих личных нужд я всё равно, само собой, буду использовать git. И теперь, когда мне нужно комитить из разных операционных систем (Judy кроссплатформенный движок), я волей-неволей возвращаюсь к этой идее. Думаю, в самое ближайшее время добью его до минимального функционала и пересяду на него. В отличие от движка, который я пока не решил делать свободным, GitTern полностью open-source по MIT лицензии.
4. #Ameba.
Aggregate MEssage BAr — это агрегатор популярных мессенджеров и ещё один проект, о начале работ над которым я радостно раструбил в блоге, но который, похоже, пока ещё какое-то время полежит на полке.
5. Английский.
В числе личных проектов я также решил перечислить занятия английским, поскольку это непосредственно связано с моей прокачкой в профессиональном смысле. Сейчас я три раза в неделю занимаюсь с преподавателем онлайн, читаю Кинга на бумаге и собираюсь переводить этот блог на английский на Medium.
6. Ключевые слова Shodan’а.
Ещё один важный для меня проект по самопрокачке — пройтись по ключевым словам Андрея Аксёнова. Это, конечно, не прямое руководство к действию, но отличные дорожные ориентиры, по которым я всё собираюсь начать заполнять пробелы в своих знаниях, но никак не начну. Может быть, кто-нибудь из читателей тоже заинтересуется, и вместе будет проще?
Обсудить
Ещё раз курсы по геймдизайну
#реклама
Хотели записаться на курс геймдизайна, про который я рассказывал в октябре, но замотались и не успели? Что ж, у меня для вас хорошая новость: 23 января начнётся новый поток. Как раз отдохнёте маленечко в новогодние праздники, переведёте дух — и вперёд, врываться в индустрию!
Тот же четырёхмесячный курс от Skillfactory с упором на практику на всех этапах: от концепта и механики до монетизации и продвижения.
Тот же преподаватель — Руслан Казанцев, лид геймдизайнер финской студии BON Games с восьмилетним багажом опыта.
Но новая цена. В честь нового года действует скидочка 40% на весь курс.
Записаться по ссылочке: https://goo.gl/FGC6wS
#реклама
Хотели записаться на курс геймдизайна, про который я рассказывал в октябре, но замотались и не успели? Что ж, у меня для вас хорошая новость: 23 января начнётся новый поток. Как раз отдохнёте маленечко в новогодние праздники, переведёте дух — и вперёд, врываться в индустрию!
Тот же четырёхмесячный курс от Skillfactory с упором на практику на всех этапах: от концепта и механики до монетизации и продвижения.
Тот же преподаватель — Руслан Казанцев, лид геймдизайнер финской студии BON Games с восьмилетним багажом опыта.
Но новая цена. В честь нового года действует скидочка 40% на весь курс.
Записаться по ссылочке: https://goo.gl/FGC6wS
Скрипты в Encased 1.1
#код
Что-то у меня одновременно много людей заказали размещения, поэтому чтобы канал не превращался в сплошную рекламу, придётся делать посты почаще на этой неделе.
А давайте поговорим, например, про скрипты. С прошлого раза, когда я про них рассказывал, они претерпели некоторые изменения и это должно быть интересно. Напомню, что у нас скрипты — это экземпляры классов, унаследованных от Script, которые имеют функции Start() и Update(), могут содержать сериализуемые поля, которые выполняют роль эдаких «локальных переменных», а также скрипты умеют подписываться на различные события от сущностей в мире.
Предполагалось, что на события можно как подписываться, так и отписываться в реалтайме, а текущее состояние подписок также бы попадало в файл сохранения. И всё было бы хорошо, если бы не одно «но». Судя по вопросам и фиче-реквестам, которые я получал, оказалось, что скриптеры не понимают концепт подписок на интуитивном уровне.
Их основная идея была в том, что мы подписываемся на нужные события в Start и потом, по мере обработки событий, отписываемся от них или подписываемся на новые. При этом функция Start, разумеется, больше никогда не вызовется. Даже после нажатия Сохранить/Загрузить мы получим абсолютно то же состояние подписок, которое было до этого. Но скриптеры ожидают, что они могут сохраниться, добавить подписку в функции Start, загрузиться и обработать свежедобавленый эвент. Этой ситуации у нас пока не случилось, но я предвосхищаю, что мне бы пришёл вопрос «а нельзя ли сделать, чтобы после загрузки Start() отрабатывал ещё раз?». То, что тогда получится по 2 подписки и это вообще ломает всю концепцию скриптов, никого бы не смутило.
Такое поведение скриптеров может показаться глупым, но дело в том, что если что-то может быть понято неправильно, оно обязательно будет понято не так, а я не смогу со свечкой стоять над каждым скриптом в игре. Моя задача в первую очередь не в том, чтобы сделать крутую вещь в себе, а в том, чтобы поддержать удобный пайплайн для скриптеров. Поэтому от подписок в реалтайме пришлось отказаться. Все подписки теперь статичны и устанавливаются при инициализации скрипта. Причём ручное навешивание делегатов возможно теперь только в специально отведённой для этого функции и является запасным способом. А рекомендуемым способом теперь является простая пометка функций атрибутами.
Например, мы помечаем функцию атрибутом
что означает, что функция отработает, когда мы нажмём на рубильник в игре. LeverSwitch — это константа, содержащая уникальный guid рубильника, который доступен из скриптов, потому что у нас сделана кодогенерация констант (с поддержкой последующего переименования, разумеется).
Реальной отписки от этой функции причём не существует, но она эмулируется через проверку глобальной переменной внутри тела функции или с помощью атрибутов. Вроде таких:
или ещё проще
Последний вариант означает, что функция выполнится только один раз, а 0 нужен для уникальной пометки этой функции (чтобы можно было безопасно переименовать функцию и ничего не сломать). В пределах одного файла у других функций, соответственно будет OnlyOnce(1), OnlyOnce(2) и так далее.
На поверку оказывается, что если функция не вызывается по причине того, что на её запуске стоит тест переменной, которая в данный момент не включена, то это намного проще воспринимается скриптерами, чем функция, которая не вызывается, потому что на неё никто не подписывался в истории этого сейва. Так что такая модель выглядит более перспективной в плане поддержки игры и накатывания апдейтов. Посмотрим, как она покажет себя в бою, а пока всем счастливого рождества!
Обсудить
#код
Что-то у меня одновременно много людей заказали размещения, поэтому чтобы канал не превращался в сплошную рекламу, придётся делать посты почаще на этой неделе.
А давайте поговорим, например, про скрипты. С прошлого раза, когда я про них рассказывал, они претерпели некоторые изменения и это должно быть интересно. Напомню, что у нас скрипты — это экземпляры классов, унаследованных от Script, которые имеют функции Start() и Update(), могут содержать сериализуемые поля, которые выполняют роль эдаких «локальных переменных», а также скрипты умеют подписываться на различные события от сущностей в мире.
Предполагалось, что на события можно как подписываться, так и отписываться в реалтайме, а текущее состояние подписок также бы попадало в файл сохранения. И всё было бы хорошо, если бы не одно «но». Судя по вопросам и фиче-реквестам, которые я получал, оказалось, что скриптеры не понимают концепт подписок на интуитивном уровне.
Их основная идея была в том, что мы подписываемся на нужные события в Start и потом, по мере обработки событий, отписываемся от них или подписываемся на новые. При этом функция Start, разумеется, больше никогда не вызовется. Даже после нажатия Сохранить/Загрузить мы получим абсолютно то же состояние подписок, которое было до этого. Но скриптеры ожидают, что они могут сохраниться, добавить подписку в функции Start, загрузиться и обработать свежедобавленый эвент. Этой ситуации у нас пока не случилось, но я предвосхищаю, что мне бы пришёл вопрос «а нельзя ли сделать, чтобы после загрузки Start() отрабатывал ещё раз?». То, что тогда получится по 2 подписки и это вообще ломает всю концепцию скриптов, никого бы не смутило.
Такое поведение скриптеров может показаться глупым, но дело в том, что если что-то может быть понято неправильно, оно обязательно будет понято не так, а я не смогу со свечкой стоять над каждым скриптом в игре. Моя задача в первую очередь не в том, чтобы сделать крутую вещь в себе, а в том, чтобы поддержать удобный пайплайн для скриптеров. Поэтому от подписок в реалтайме пришлось отказаться. Все подписки теперь статичны и устанавливаются при инициализации скрипта. Причём ручное навешивание делегатов возможно теперь только в специально отведённой для этого функции и является запасным способом. А рекомендуемым способом теперь является простая пометка функций атрибутами.
Например, мы помечаем функцию атрибутом
[OnUsed(Guids.Levels.MagicBalls.LeverSwitch)]
что означает, что функция отработает, когда мы нажмём на рубильник в игре. LeverSwitch — это константа, содержащая уникальный guid рубильника, который доступен из скриптов, потому что у нас сделана кодогенерация констант (с поддержкой последующего переименования, разумеется).
Реальной отписки от этой функции причём не существует, но она эмулируется через проверку глобальной переменной внутри тела функции или с помощью атрибутов. Вроде таких:
[If(BunkerVariables.LiftEnabled)]
или ещё проще
[OnlyOnce(0)]
Последний вариант означает, что функция выполнится только один раз, а 0 нужен для уникальной пометки этой функции (чтобы можно было безопасно переименовать функцию и ничего не сломать). В пределах одного файла у других функций, соответственно будет OnlyOnce(1), OnlyOnce(2) и так далее.
На поверку оказывается, что если функция не вызывается по причине того, что на её запуске стоит тест переменной, которая в данный момент не включена, то это намного проще воспринимается скриптерами, чем функция, которая не вызывается, потому что на неё никто не подписывался в истории этого сейва. Так что такая модель выглядит более перспективной в плане поддержки игры и накатывания апдейтов. Посмотрим, как она покажет себя в бою, а пока всем счастливого рождества!
Обсудить
Надо больше инфы по ECS
#реклама
Как вы знаете, Entity Component System штука не новая, но переживает сейчас невиданный пик популярности. Если бы мы начинали делать Encased сегодня, я бы наверняка задействовал юнитёвую ECS, но год назад она была ещё сырой, и мне пришлось городить свою модульную систему. Впрочем, она только внешне напоминает ECS, но ей не является, поскольку ECS это в первую очередь про расположение данных в памяти и производительность, а у меня такой задачи не стояло. Зато стояли сроки. Но вот в своём движке я, возможно, напишу уже что-то более близкое к трушной реализации. Потому что кто, чёрт возьми, не хочет кайфовую штуку в своём движке? Пописать что-то клёвое губа у меня, знаете, не дура.
Так вот, прикиньте, оказывается, есть целый телеграмм-канал, целиком и полностью посвящённый одной только ECS. Единое место, где собираются все статьи и видео по теме. Если вы подумывали над тем, чтобы разобраться и научиться пользоваться, или даже написать свою реализацию, то вам непременно стоит подписаться: https://www.tgoop.com/ecscomrade
#реклама
Как вы знаете, Entity Component System штука не новая, но переживает сейчас невиданный пик популярности. Если бы мы начинали делать Encased сегодня, я бы наверняка задействовал юнитёвую ECS, но год назад она была ещё сырой, и мне пришлось городить свою модульную систему. Впрочем, она только внешне напоминает ECS, но ей не является, поскольку ECS это в первую очередь про расположение данных в памяти и производительность, а у меня такой задачи не стояло. Зато стояли сроки. Но вот в своём движке я, возможно, напишу уже что-то более близкое к трушной реализации. Потому что кто, чёрт возьми, не хочет кайфовую штуку в своём движке? Пописать что-то клёвое губа у меня, знаете, не дура.
Так вот, прикиньте, оказывается, есть целый телеграмм-канал, целиком и полностью посвящённый одной только ECS. Единое место, где собираются все статьи и видео по теме. Если вы подумывали над тем, чтобы разобраться и научиться пользоваться, или даже написать свою реализацию, то вам непременно стоит подписаться: https://www.tgoop.com/ecscomrade
Telegram
ECS Comrade
Welcome, comrade, to ECS Community! This channel is for those who study, create and develop projects based on a system of entities and components. All stuff for studying ECS are dropped here
Feedback: @ECSCBot
Chat: @ecschat
Feedback: @ECSCBot
Chat: @ecschat
Gamedev новости
#реклама
Что читать, пока ждёте очередной лонгпост от меня? А вот хотя бы свеженький канальчик с основными новостями индустрии, ссылками на полезные статьи и всяким таким прочим про геймдев. Коротко, но зато по делу и каждый день. Автор вообще топит за краткость, и меня просил много не писать, поэтому без лишних представлений, встречайте: @Game_Dev
#реклама
Что читать, пока ждёте очередной лонгпост от меня? А вот хотя бы свеженький канальчик с основными новостями индустрии, ссылками на полезные статьи и всяким таким прочим про геймдев. Коротко, но зато по делу и каждый день. Автор вообще топит за краткость, и меня просил много не писать, поэтому без лишних представлений, встречайте: @Game_Dev
Байка про кранчи и хаки
#лайт
Признаюсь честно, был очень велик соблазн в последнем посте 2018-го подвести какие-то итоги года. Но потом я подумал: да какие могут быть итоги календарного года в геймдеве? Итоги стоит подводить, когда завершён какой-то действительно важный этап или проект, а новый год для разработчика, что для лошади свадьба. Праздники для нас зачастую означают лишь дедлайн тематического обновления, что нередко перерастает в кранчи. Так что запах хвои и мандарин непременно навевает мне и о переработках.
В этом году конец года выдался спокойный, хотя я и планирую поработать немного на каникулах, но вот два года назад бой курантов чуть не застал меня в дебагере. Я был тогда в маленькой инди-команде и мы большой рождественский апдейт, планируемый к 25 декабря, выпустили только 30-го числа, а потому большую часть 31-го занимались мониторингом ошибок и хотфиксами. Мы закончили работать лишь в 22:00 (и я даже успел приехать на торжества), а у остальных ребят в другой таймзоне на часах было и вовсе 23:00. Забавно было потом читать комментарии игроков о том, почему апдейт, который в том числе добавлял шапки Санты, вышел в канун нового года, а не на рождество. Они даже нагуглили, что разработчики из России, а православное рождество отмечается 7 января, на чём и сошлись. Но мысль о том, что мы просто не успели к 25-му декабря, никому в голову даже не пришла.
Впрочем, байка будет не про это. Мысли о кранчах навеяли мне другой случай, это будет история о моём самом злостном хаке за всю карьеру игрового программиста. Я тогда ещё был зелёным студентом и профессионально работал меньше года на полставочки. А меня взяли и отправили сразу с места в С++, портировать одну из наших матч3-игр на первый iPad, который только что представил Стив Джобс в Сан-Франциско. Ну хотя как портировать? По сути заново переписать с Делфи на кресты. А я и то и другое до этого только в универе на лабах-то и видел по большому счёту. Благо хоть не в одиночку на проект бросили, а со старшим товарищем.
Цимес ситуации в том, что iPad анонсировали 27 января, а уже 3 апреля начинались его продажи; и те приложения, что успевали к открытию, получали огромные ништяки в плане фичеринга. И вот мы сидим в последнюю ночь, кранчуем. Уже, вроде, всё сделали, но остаётся один странный баг.
Среди всего прочего, я отвечал за человечков, которые ходят снизу игрового поля и уносят с него строительный материал, который вылетает с поля во время игры. Это была чисто декоративная функция, но добавляющая живости в игру. В конце каждого уровня выпадал большой камень, который тащить человечки могли только втроём. На скрине выше как раз запечатлен этот момент. Так вот, несмотря на то, что при падении этого камня на пол в коде было явно захардкожена цифра 3 для спауна новых работников, иногда почему-то из домика выходило только двое. Они подходили к камню и вечно стояли там без дела, дожидаясь третьего товарища, который почему-то не хотел выходить из дома.
Дело уже к третьему часу ночи, общими усилиями найти баг не можем, но версию нужно отгружать. Что делать? Ну, в общем, я просто беру и пишу костыль, что после спауна 3 человек, начинаю отсчитывать время, и если через 10 секунд камень не начали тащить, то я спауню ещё одного человечка, через 10 секунд ещё одного и так далее, до тех пор, пока камень не сдвинется с места… И это ушло в релиз.
На следующий день старший товарищ нашёл баг в моём коде. Разумеется, я просто по неопытности покараптил память, запихав длинную строчку в маленький массив. Мы исправили косяк в ближайшем апдейте, но то решение навсегда останется со мной, как самый злостный хак в карьере. А какой костыль у вас был самым диким? Поделитесь в комментариях.
#лайт
Признаюсь честно, был очень велик соблазн в последнем посте 2018-го подвести какие-то итоги года. Но потом я подумал: да какие могут быть итоги календарного года в геймдеве? Итоги стоит подводить, когда завершён какой-то действительно важный этап или проект, а новый год для разработчика, что для лошади свадьба. Праздники для нас зачастую означают лишь дедлайн тематического обновления, что нередко перерастает в кранчи. Так что запах хвои и мандарин непременно навевает мне и о переработках.
В этом году конец года выдался спокойный, хотя я и планирую поработать немного на каникулах, но вот два года назад бой курантов чуть не застал меня в дебагере. Я был тогда в маленькой инди-команде и мы большой рождественский апдейт, планируемый к 25 декабря, выпустили только 30-го числа, а потому большую часть 31-го занимались мониторингом ошибок и хотфиксами. Мы закончили работать лишь в 22:00 (и я даже успел приехать на торжества), а у остальных ребят в другой таймзоне на часах было и вовсе 23:00. Забавно было потом читать комментарии игроков о том, почему апдейт, который в том числе добавлял шапки Санты, вышел в канун нового года, а не на рождество. Они даже нагуглили, что разработчики из России, а православное рождество отмечается 7 января, на чём и сошлись. Но мысль о том, что мы просто не успели к 25-му декабря, никому в голову даже не пришла.
Впрочем, байка будет не про это. Мысли о кранчах навеяли мне другой случай, это будет история о моём самом злостном хаке за всю карьеру игрового программиста. Я тогда ещё был зелёным студентом и профессионально работал меньше года на полставочки. А меня взяли и отправили сразу с места в С++, портировать одну из наших матч3-игр на первый iPad, который только что представил Стив Джобс в Сан-Франциско. Ну хотя как портировать? По сути заново переписать с Делфи на кресты. А я и то и другое до этого только в универе на лабах-то и видел по большому счёту. Благо хоть не в одиночку на проект бросили, а со старшим товарищем.
Цимес ситуации в том, что iPad анонсировали 27 января, а уже 3 апреля начинались его продажи; и те приложения, что успевали к открытию, получали огромные ништяки в плане фичеринга. И вот мы сидим в последнюю ночь, кранчуем. Уже, вроде, всё сделали, но остаётся один странный баг.
Среди всего прочего, я отвечал за человечков, которые ходят снизу игрового поля и уносят с него строительный материал, который вылетает с поля во время игры. Это была чисто декоративная функция, но добавляющая живости в игру. В конце каждого уровня выпадал большой камень, который тащить человечки могли только втроём. На скрине выше как раз запечатлен этот момент. Так вот, несмотря на то, что при падении этого камня на пол в коде было явно захардкожена цифра 3 для спауна новых работников, иногда почему-то из домика выходило только двое. Они подходили к камню и вечно стояли там без дела, дожидаясь третьего товарища, который почему-то не хотел выходить из дома.
Дело уже к третьему часу ночи, общими усилиями найти баг не можем, но версию нужно отгружать. Что делать? Ну, в общем, я просто беру и пишу костыль, что после спауна 3 человек, начинаю отсчитывать время, и если через 10 секунд камень не начали тащить, то я спауню ещё одного человечка, через 10 секунд ещё одного и так далее, до тех пор, пока камень не сдвинется с места… И это ушло в релиз.
На следующий день старший товарищ нашёл баг в моём коде. Разумеется, я просто по неопытности покараптил память, запихав длинную строчку в маленький массив. Мы исправили косяк в ближайшем апдейте, но то решение навсегда останется со мной, как самый злостный хак в карьере. А какой костыль у вас был самым диким? Поделитесь в комментариях.