Эпик стор и монополии
#лайт
Почему-то сам не догадался начать комментировать новости игровой индустрии. Это же просто неисчерпаемый источник лёгких постов! Благо, в чатике нашлось, кому подсказать.
Меня попросили сделать пост про 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 секунд ещё одного и так далее, до тех пор, пока камень не сдвинется с места… И это ушло в релиз.
На следующий день старший товарищ нашёл баг в моём коде. Разумеется, я просто по неопытности покараптил память, запихав длинную строчку в маленький массив. Мы исправили косяк в ближайшем апдейте, но то решение навсегда останется со мной, как самый злостный хак в карьере. А какой костыль у вас был самым диким? Поделитесь в комментариях.
Гитхаб-счастье!
#лайт
Горячо любимый мною Microsoft, взявший в последние годы курс на опенсорс, продолжает меня радовать. Не так давно они возглавили крупнейший вэб-хостинг опенсорс-проектов GitHub, и на днях провели в нём первую крупную реформу: сменили тарифные планы.
Главное изменение касается бесплатных аккаунтов. Если раньше бесплатно можно было вести только публичные репозитории, то теперь можно создавать неограниченное количество приватных проектов до 3 пользователей. Напомню, что GitHub, в отличие от большинства аналогов, никак не ограничивает дисковое пространство, так что количество пользователей — это единственное условие. А трёх пользователей зачастую достаточно для современных инди-команд.
Конечно, приватные репозитории можно было заводить бесплатно и до этого на том же BitBucket, причём аж до 5 пользователей; но нововведение от GitHub — это счастье, прежде всего, для одиночек. Просто если вы программист и занимались когда-нибудь опенсорс разработкой, то у вас уже есть аккаунт и репозитории на GitHub. Если теперь вы решите пилить что-то коммерческое для себя, то вам не надо никуда ходить, можно завести приватный репозиторий здесь же. И даже можно в случае чего подключить к проекту художника или второго программиста.
Кстати, мало кто знает, но публичный репозиторий не означает, что проект опенсорный. Вам никто не мешает положить в репозиторий свою проприетарную лицензию. Более того, отсутствие какой-либо лицензии (что встречается повсеместно на гитхаб) по умолчанию оставляет все права на код за автором. Такой код можно просматривать, но нельзя копировать или перепродавать. Так что те, кто не боялся, что его код украдут, могли спокойно вести коммерческую разработку на гитхаб и до этого. Как, например, делал я. Между прочим, всем рекомендую завести публичные репозитории. Это отличное упражнение, позволяющее в короткие сроки избавиться от комплекса «здесь не прибрано», когда люди стесняются показывать неидеальный код, и в итоге вообще ничего никому не показывают.
А на картинке сверху моя плюшевая игрушка в виде маскота Github. Да, у меня и такая есть. Правда милота?
Обсудить
#лайт
Горячо любимый мною Microsoft, взявший в последние годы курс на опенсорс, продолжает меня радовать. Не так давно они возглавили крупнейший вэб-хостинг опенсорс-проектов GitHub, и на днях провели в нём первую крупную реформу: сменили тарифные планы.
Главное изменение касается бесплатных аккаунтов. Если раньше бесплатно можно было вести только публичные репозитории, то теперь можно создавать неограниченное количество приватных проектов до 3 пользователей. Напомню, что GitHub, в отличие от большинства аналогов, никак не ограничивает дисковое пространство, так что количество пользователей — это единственное условие. А трёх пользователей зачастую достаточно для современных инди-команд.
Конечно, приватные репозитории можно было заводить бесплатно и до этого на том же BitBucket, причём аж до 5 пользователей; но нововведение от GitHub — это счастье, прежде всего, для одиночек. Просто если вы программист и занимались когда-нибудь опенсорс разработкой, то у вас уже есть аккаунт и репозитории на GitHub. Если теперь вы решите пилить что-то коммерческое для себя, то вам не надо никуда ходить, можно завести приватный репозиторий здесь же. И даже можно в случае чего подключить к проекту художника или второго программиста.
Кстати, мало кто знает, но публичный репозиторий не означает, что проект опенсорный. Вам никто не мешает положить в репозиторий свою проприетарную лицензию. Более того, отсутствие какой-либо лицензии (что встречается повсеместно на гитхаб) по умолчанию оставляет все права на код за автором. Такой код можно просматривать, но нельзя копировать или перепродавать. Так что те, кто не боялся, что его код украдут, могли спокойно вести коммерческую разработку на гитхаб и до этого. Как, например, делал я. Между прочим, всем рекомендую завести публичные репозитории. Это отличное упражнение, позволяющее в короткие сроки избавиться от комплекса «здесь не прибрано», когда люди стесняются показывать неидеальный код, и в итоге вообще ничего никому не показывают.
А на картинке сверху моя плюшевая игрушка в виде маскота Github. Да, у меня и такая есть. Правда милота?
Обсудить
О трамвайчиках
#лайт
Давайте отдохнём немного от программирования и поговорим про трамвайчики. Все же любят поезда, да? Я решил побыть сегодня Ильёй Варламовым и поделиться путевыми наблюдениями об урбанистике.
Наверное, такое решение для трамвайных путей много, где встречается, но я увидел впервые в Касабланке. Здесь для трамваев проложены отдельные дороги, по которым машины не ездят. Не полосы, а именно отдельные дороги: даже если трамвайная и автомобильная дороги идут параллельно, они обязательно разделяются тротуаром, бордюром или посадкой деревьев. А вот трамвайная дорога от пешеходной зоны бордюром не отделяется!
Ограждения попросту не нужны, поскольку машин на этой дороге нет, а трамвай с рельс сойти не может. Для людей же получается огромный пешеходный проспект, который одинаково просто пересекать, как на своих двоих, так и на инвалидной коляске или велике. Да, велосипедисты используют трамвайные пути, как одну большую велодорожку, потому что почему бы и нет? Пешеходы, конечно, гуляют не по рельсам, а по тротуару, но если сравнивать с обычными улицами, то гораздо приятнее идти по визуально широкому проспекту, где или нет машин вовсе, или они спрятаны за полосой деревьев. Ни шума, ни выхлопных газов, хороший обзор на архитектуру и ощущение простора. Изредка проезжающие стильные трамваи на электротяге совсем не портят картину и не раздражают. Движутся они не очень быстро и уступают пешеходам. Словом, кайфово.
Вот такая заметка получилась. Немножко не формат, но больше такого можно читать у меня в твиттере. Там я, конечно, в основном просто старчески ворчу на всех и вся, но иногда и что-то интересное бывает. Ну и чатик как всегда работает.
#лайт
Давайте отдохнём немного от программирования и поговорим про трамвайчики. Все же любят поезда, да? Я решил побыть сегодня Ильёй Варламовым и поделиться путевыми наблюдениями об урбанистике.
Наверное, такое решение для трамвайных путей много, где встречается, но я увидел впервые в Касабланке. Здесь для трамваев проложены отдельные дороги, по которым машины не ездят. Не полосы, а именно отдельные дороги: даже если трамвайная и автомобильная дороги идут параллельно, они обязательно разделяются тротуаром, бордюром или посадкой деревьев. А вот трамвайная дорога от пешеходной зоны бордюром не отделяется!
Ограждения попросту не нужны, поскольку машин на этой дороге нет, а трамвай с рельс сойти не может. Для людей же получается огромный пешеходный проспект, который одинаково просто пересекать, как на своих двоих, так и на инвалидной коляске или велике. Да, велосипедисты используют трамвайные пути, как одну большую велодорожку, потому что почему бы и нет? Пешеходы, конечно, гуляют не по рельсам, а по тротуару, но если сравнивать с обычными улицами, то гораздо приятнее идти по визуально широкому проспекту, где или нет машин вовсе, или они спрятаны за полосой деревьев. Ни шума, ни выхлопных газов, хороший обзор на архитектуру и ощущение простора. Изредка проезжающие стильные трамваи на электротяге совсем не портят картину и не раздражают. Движутся они не очень быстро и уступают пешеходам. Словом, кайфово.
Вот такая заметка получилась. Немножко не формат, но больше такого можно читать у меня в твиттере. Там я, конечно, в основном просто старчески ворчу на всех и вся, но иногда и что-то интересное бывает. Ну и чатик как всегда работает.