Время и фантастическая тусовочка
#лайт
Несколько недель я ничего не писал сюда и на то у меня целых две причины.
Во-первых, ничего и не происходит. Как это ни прискорбно признавать, но мои личные проекты — главный по задумке источник постов в блоге — не развиваются от слова совсем. Все мои многочисленные попытки реанимировать работу над ними раз за разом проваливаются. Я связываю это с удалённой работой. Как перестал ходить в офис два года назад, так проблемы с пет-прожектами меня и не покидают.
Дело в том, что когда ты ходишь на работу по расписанию, то у тебя есть некоторое количество свободного времени, из которого ты выделяешь какую-то часть под личные проекты. Ты, конечно, при этом много прокрастинируешь, ленишься и просто неэффективно управляешь временем, но хоть сколько-то часов, да перепадает на пет-прожекты.
А когда ты работаешь дома с гибким графиком, то у тебя всё время как бы свободное, из которого ты уже самостоятельно выделяешь часть на работу. Разумеется, прокрастинация и плохой таймменеджмент никуда не деваются, а потому работаешь если не меньше положенного времени, то по крайней мере впритык точно. И это с учётом ночей и выходных, когда порой нагоняешь отставание. На личные проекты, сами понимаете, в таких условиях время выделять уже просто неоткуда.
Поэтому, боюсь, пока я работаю над Encased, ситуация не поменяется.
Вторая причина долгого молчания заключается в том, что последнее время, так совпало, я постоянно тратил все буквы на что-то другое: то документацию писал по проекту, то свои рассказы, то отзывы на чужие.
Если с документацией всё понятно, то про рассказы у меня есть пару слов. Вот уже год с небольшим, как я снова стал писать. Ну, то есть как писать? Регулярно ходить на литературные конкурсы. Принцип тот же, что на Ludum Dare, только не игры, а рассказы: задаётся тема, три дня все пишут, потом читают друг друга и голосуют (до объявления результатов все рассказы анонимные).
Так вот. Кто бы вы думали, ходит на такие контесты? Ну, во-первых, писатели профессиональны — это понятно. А кто ещё? К моему большому удивлению, я обнаружил, что каждый второй (если не больше) участник-любитель на таких конкурсах — это либо человек из геймдева (геймдизайнер, сценарист, игрожур), либо айтишник. В моём случае, так и то и другое.
Мне кажется, это довольно интересное наблюдение, поскольку как-то принято считать, что программисты люди не творческие (по крайней мере в гуманитарном смысле), а на самом деле только они в основном и пишут. Ну или айтишники просто слишком хорошо живут, так что у них есть возможность заниматься чем-то, кроме работы.
Обсудить
#лайт
Несколько недель я ничего не писал сюда и на то у меня целых две причины.
Во-первых, ничего и не происходит. Как это ни прискорбно признавать, но мои личные проекты — главный по задумке источник постов в блоге — не развиваются от слова совсем. Все мои многочисленные попытки реанимировать работу над ними раз за разом проваливаются. Я связываю это с удалённой работой. Как перестал ходить в офис два года назад, так проблемы с пет-прожектами меня и не покидают.
Дело в том, что когда ты ходишь на работу по расписанию, то у тебя есть некоторое количество свободного времени, из которого ты выделяешь какую-то часть под личные проекты. Ты, конечно, при этом много прокрастинируешь, ленишься и просто неэффективно управляешь временем, но хоть сколько-то часов, да перепадает на пет-прожекты.
А когда ты работаешь дома с гибким графиком, то у тебя всё время как бы свободное, из которого ты уже самостоятельно выделяешь часть на работу. Разумеется, прокрастинация и плохой таймменеджмент никуда не деваются, а потому работаешь если не меньше положенного времени, то по крайней мере впритык точно. И это с учётом ночей и выходных, когда порой нагоняешь отставание. На личные проекты, сами понимаете, в таких условиях время выделять уже просто неоткуда.
Поэтому, боюсь, пока я работаю над Encased, ситуация не поменяется.
Вторая причина долгого молчания заключается в том, что последнее время, так совпало, я постоянно тратил все буквы на что-то другое: то документацию писал по проекту, то свои рассказы, то отзывы на чужие.
Если с документацией всё понятно, то про рассказы у меня есть пару слов. Вот уже год с небольшим, как я снова стал писать. Ну, то есть как писать? Регулярно ходить на литературные конкурсы. Принцип тот же, что на Ludum Dare, только не игры, а рассказы: задаётся тема, три дня все пишут, потом читают друг друга и голосуют (до объявления результатов все рассказы анонимные).
Так вот. Кто бы вы думали, ходит на такие контесты? Ну, во-первых, писатели профессиональны — это понятно. А кто ещё? К моему большому удивлению, я обнаружил, что каждый второй (если не больше) участник-любитель на таких конкурсах — это либо человек из геймдева (геймдизайнер, сценарист, игрожур), либо айтишник. В моём случае, так и то и другое.
Мне кажется, это довольно интересное наблюдение, поскольку как-то принято считать, что программисты люди не творческие (по крайней мере в гуманитарном смысле), а на самом деле только они в основном и пишут. Ну или айтишники просто слишком хорошо живут, так что у них есть возможность заниматься чем-то, кроме работы.
Обсудить
Силуэтики и обводочки
#кодище
Ох и затяжные каникулы сами собой получились на канале! Что ж, давайте попробуем начать что-то вроде второго сезона. Я даже второй гуглдоковский файл завёл по этому поводу.
И начнём мы с такой привычной всем штуки, как силуэты. Способов их делать существует бесчисленное множество. Мы, как водится, запилили нечто своё. Чем-то похожее на то, как везде; а чем-то, возможно, и необычное. Не претендуем на супер новизну или крутость техники, но, тем не менее, кому-нибудь может быть интересно.
Прежде всего надо отметить, что у нас в понятие силуэт входит сразу два цвета: заливка объекта (на скриншоте белый) и обводка (жёлтый). Обводка показывается всегда, а заливка только для тех областей, которые перекрыты какими-то другими объектами. В зависимости от игровой ситуации, геймплейный код помечает объекты, которые нам нужно обвести: дескать, вот этого врага надо залить розовым с красной обводкой, игрока салатовым с зелёным, а вон тот стул — только обвести белым, но не заливать. При этом все объекты могут, само собой, как угодно друг с другом пересекаться.
Мы решаем это так. Сперва берём все комбинации обводка + заливка и загоняем в StructuredBuffer, чтобы обозначать комбинацию одним байтом по индексу. Не более 256 разных вариантов в кадре получается. Нам этого не то, что на один кадр, нам этого на всю игру хватает, так что буфер меняться в процессе не будет.
Затем берём полноэкранный буфер и начинаем рисовать в него все подсвеченные объекты по следующей схеме:
Причём достигаем мы этого аж двумя пассами. Для первого прохода выставлена опция ZTest == Equal, то есть он записывает только те пиксели, что не перекрыты другими объектами. По схеме выше выглядит это примерно так (_SilhouetteIndex — это глобальный uniform для текущего draw):
Второй же пасс пишет с опцией ZTest == Greater, то есть, напротив, только те пиксели, которые оказались под чем-то. R и G составляющие выглядят точно также, а для B мы вычисляем значение opacity силуэта, которое зависит от того, насколько глубоко объект перекрыт другой геометрией (сравниваем с текущим значением ZBuffer). Это нужно для того, чтобы маскировать мелкие косяки анимации, когда меш слегка погружается в пол при ходьбе по лестницам и подобным неровным местам.
А вот в альфа-канал на втором пассе мы вообще ничего не пишем! Если кто-то записал 1 в альфу, то она должна там остаться навсегда. Этот трюк необходим как раз для правильной обработки перекрытий силуэтов друг друга. Конечно, цвет испортится, но если силуэт ничем не перекрыт, то нам он и не нужен. Впрочем, при очень большом желании мы могли бы и его сохранить через блендинг вида OneMinusSrcAlpha SrcAlpha.
Но мы отвлеклись. Полноэкранный буфер с мета-инфой о силуэтах это, конечно, прекрасно, но как нарисовать силуэты? А с помощью того шейдера, что показан на скриншоте (разумеется, рисуем не полноэкранно, а только небольшие квады в тех местах, где у нас есть силуэты).
Как видно по коду, там где мы отрисовали силуэт, мы просто достаём цвет заливки и покрываем им скрытые части объекта (видимые не трогаем). А для тех мест, где силуэт не отрисован, мы делаем однопиксельное смещение во все стороны. И если находим хотя бы один пиксель силуэта, то считает это место местом обводки. Цвет обводки берётся при этом как среднее из всех найденных силуэтов вокруг этого пикселя.
Вот примерно такие дела. Надеюсь, не слишком запутанно вышло.
Обсудить
#кодище
Ох и затяжные каникулы сами собой получились на канале! Что ж, давайте попробуем начать что-то вроде второго сезона. Я даже второй гуглдоковский файл завёл по этому поводу.
И начнём мы с такой привычной всем штуки, как силуэты. Способов их делать существует бесчисленное множество. Мы, как водится, запилили нечто своё. Чем-то похожее на то, как везде; а чем-то, возможно, и необычное. Не претендуем на супер новизну или крутость техники, но, тем не менее, кому-нибудь может быть интересно.
Прежде всего надо отметить, что у нас в понятие силуэт входит сразу два цвета: заливка объекта (на скриншоте белый) и обводка (жёлтый). Обводка показывается всегда, а заливка только для тех областей, которые перекрыты какими-то другими объектами. В зависимости от игровой ситуации, геймплейный код помечает объекты, которые нам нужно обвести: дескать, вот этого врага надо залить розовым с красной обводкой, игрока салатовым с зелёным, а вон тот стул — только обвести белым, но не заливать. При этом все объекты могут, само собой, как угодно друг с другом пересекаться.
Мы решаем это так. Сперва берём все комбинации обводка + заливка и загоняем в StructuredBuffer, чтобы обозначать комбинацию одним байтом по индексу. Не более 256 разных вариантов в кадре получается. Нам этого не то, что на один кадр, нам этого на всю игру хватает, так что буфер меняться в процессе не будет.
Затем берём полноэкранный буфер и начинаем рисовать в него все подсвеченные объекты по следующей схеме:
// R — Always 1 (indicate that silhouette exists)
// G — Index of silhouette colors
// B — Opacity if hidden
// A — Is pixel visible? (1 — visible, 0 — hidden by other objects)
Причём достигаем мы этого аж двумя пассами. Для первого прохода выставлена опция ZTest == Equal, то есть он записывает только те пиксели, что не перекрыты другими объектами. По схеме выше выглядит это примерно так (_SilhouetteIndex — это глобальный uniform для текущего draw):
return float4(1, (float)_SilhouetteIndex / 255, 0, 1);
Второй же пасс пишет с опцией ZTest == Greater, то есть, напротив, только те пиксели, которые оказались под чем-то. R и G составляющие выглядят точно также, а для B мы вычисляем значение opacity силуэта, которое зависит от того, насколько глубоко объект перекрыт другой геометрией (сравниваем с текущим значением ZBuffer). Это нужно для того, чтобы маскировать мелкие косяки анимации, когда меш слегка погружается в пол при ходьбе по лестницам и подобным неровным местам.
А вот в альфа-канал на втором пассе мы вообще ничего не пишем! Если кто-то записал 1 в альфу, то она должна там остаться навсегда. Этот трюк необходим как раз для правильной обработки перекрытий силуэтов друг друга. Конечно, цвет испортится, но если силуэт ничем не перекрыт, то нам он и не нужен. Впрочем, при очень большом желании мы могли бы и его сохранить через блендинг вида OneMinusSrcAlpha SrcAlpha.
Но мы отвлеклись. Полноэкранный буфер с мета-инфой о силуэтах это, конечно, прекрасно, но как нарисовать силуэты? А с помощью того шейдера, что показан на скриншоте (разумеется, рисуем не полноэкранно, а только небольшие квады в тех местах, где у нас есть силуэты).
Как видно по коду, там где мы отрисовали силуэт, мы просто достаём цвет заливки и покрываем им скрытые части объекта (видимые не трогаем). А для тех мест, где силуэт не отрисован, мы делаем однопиксельное смещение во все стороны. И если находим хотя бы один пиксель силуэта, то считает это место местом обводки. Цвет обводки берётся при этом как среднее из всех найденных силуэтов вокруг этого пикселя.
Вот примерно такие дела. Надеюсь, не слишком запутанно вышло.
Обсудить
Работа с QIWI
#реклама #работа
Небезызвестная компания QIWI ищет исполнителей геймдев-проектов. На «пилотный» проект отводится до 3 миллионов рублей и 5 месяцев. Компания рассматривает как полное финансирование аутсорс команды, так и варианты с разделением роялти (как договоритесь).
Пилотных геймдев-проекта, собственно, два (участвующих команд при этом будет отобрано 10 — по 5 на каждый проект):
1. Обучающая игра для повышения финансовой и цифровой грамотности детей и подростков.
2. Игра (или другая геймификация), направленная на возвращение пользователей к терминалам.
Более подробно почитать по задачам и посмотреть видео можно на сайте universe.qiwi.com. Заявку нужно подать до конца недели (19 мая), так что торопитесь! Все вопросы можно задать в чате компании @QU_product_hub
#реклама #работа
Небезызвестная компания QIWI ищет исполнителей геймдев-проектов. На «пилотный» проект отводится до 3 миллионов рублей и 5 месяцев. Компания рассматривает как полное финансирование аутсорс команды, так и варианты с разделением роялти (как договоритесь).
Пилотных геймдев-проекта, собственно, два (участвующих команд при этом будет отобрано 10 — по 5 на каждый проект):
1. Обучающая игра для повышения финансовой и цифровой грамотности детей и подростков.
2. Игра (или другая геймификация), направленная на возвращение пользователей к терминалам.
Более подробно почитать по задачам и посмотреть видео можно на сайте universe.qiwi.com. Заявку нужно подать до конца недели (19 мая), так что торопитесь! Все вопросы можно задать в чате компании @QU_product_hub
Послушайте не меня, так умных людей
#лайт
Я уже как-то упоминал, что Джонатан Блоу входит в мой персональный шорт-лист чуваков, на которых действительно стоит равнятся (кстати, перечитайте. я там интересно про философию разработки игр рассказывал).
Так вот. На прошедший DevGAMM, который закончился буквально пару дней назад, организаторам удалось затащить Блоу в качестве спикера, и он там сказал много правильных слов. Как по мне, ничего принципиально нового по сравнению с моей знаменитой расстановкой точек над Unity там не прозвучало (только масштаб больше). Но товарищ, который прислал мне видео, говорит, что формулировки Блоу для него убедительнее. Так что если к моим доводам вы отнеслись скептически, то послушайте людей более толковых.
Если, конечно, в ладах с английским на слух. Если не в ладах, то вот вам короткая версия:
— Люди постоянно утрачивают технологии;
— Потеря технологий в истории часто вела к падению цивилизаций;
— Наша цивилизация стоит на софте и скоро мы разучимся его писать;
— Наш софт говно уже сейчас, и плавно ухудшается, мы просто не замечаем этих процессов;
— Он ухудшается потому, что всё больше абстракций, а низкий уровень никто не понимает;
— Уже выросло поколение юнитологов, не умеющих в low level и дальше будет только хуже, потому что знания не передаются;
— Когда один пишет на юнити/анрил, это даёт ему конкурентное преимущество, когда все пишут на готовых движках — страдает вся индустрия;
— Игровая индустрия — это технологическая передовая железа, и если не можем мы, то в смежных отраслях всё ещё хуже;
— Если так продолжится, то наступит конец света.
Ну, ладно: последний пункт это уже моя отсебятинка. Но общий посыл был примерно такой. Мир глобально утрачивает способность писать хороший код. Каково, а? И это ведь он говорит за всю индустрию. А локально у нас в СНГ геймдеве коллапс уже случился.
Вот такие эсхатологические пироги. Хорошего вам дня, и когда сегодня будете править скрипт на шарпе, постарайтесь не думать о том, что медленно разрушаете нашу цивилизацию.
Обсудить
#лайт
Я уже как-то упоминал, что Джонатан Блоу входит в мой персональный шорт-лист чуваков, на которых действительно стоит равнятся (кстати, перечитайте. я там интересно про философию разработки игр рассказывал).
Так вот. На прошедший DevGAMM, который закончился буквально пару дней назад, организаторам удалось затащить Блоу в качестве спикера, и он там сказал много правильных слов. Как по мне, ничего принципиально нового по сравнению с моей знаменитой расстановкой точек над Unity там не прозвучало (только масштаб больше). Но товарищ, который прислал мне видео, говорит, что формулировки Блоу для него убедительнее. Так что если к моим доводам вы отнеслись скептически, то послушайте людей более толковых.
Если, конечно, в ладах с английским на слух. Если не в ладах, то вот вам короткая версия:
— Люди постоянно утрачивают технологии;
— Потеря технологий в истории часто вела к падению цивилизаций;
— Наша цивилизация стоит на софте и скоро мы разучимся его писать;
— Наш софт говно уже сейчас, и плавно ухудшается, мы просто не замечаем этих процессов;
— Он ухудшается потому, что всё больше абстракций, а низкий уровень никто не понимает;
— Уже выросло поколение юнитологов, не умеющих в low level и дальше будет только хуже, потому что знания не передаются;
— Когда один пишет на юнити/анрил, это даёт ему конкурентное преимущество, когда все пишут на готовых движках — страдает вся индустрия;
— Игровая индустрия — это технологическая передовая железа, и если не можем мы, то в смежных отраслях всё ещё хуже;
— Если так продолжится, то наступит конец света.
Ну, ладно: последний пункт это уже моя отсебятинка. Но общий посыл был примерно такой. Мир глобально утрачивает способность писать хороший код. Каково, а? И это ведь он говорит за всю индустрию. А локально у нас в СНГ геймдеве коллапс уже случился.
Вот такие эсхатологические пироги. Хорошего вам дня, и когда сегодня будете править скрипт на шарпе, постарайтесь не думать о том, что медленно разрушаете нашу цивилизацию.
Обсудить
А на каком языке думаешь ты?
#лайт
На днях бложику стукнул год. А я и не заметил. Как же быстро всё-таки летит время. Но сейчас не об этом. Тема сегодняшней записи «Язык определяет сознание». Это довольно древняя гипотеза и в наши дни большинством из нас принимаемая. То, что язык программирования также определяет сознание, мысль, в общем-то, тоже не новая, но довольно важная.
Задумывались ли вы насколько глубоко он его определяет? И я сейчас даже не про то, что каждая парадигма предполагает перестроить мышление. Я говорю о более фундаментальных вещах. О том, что вшивается нам в подсознание и в каких терминах мы начинаем думать.
Вы наверняка слышали в той или иной вариации цитату Дейкстры: «студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации».
Так уж вышло, что моим родным языком был как раз бейсик (да-да, я был из тех детей, которые больные ублюдки). И я очень долго не слазил с бейсика принципиально. Как так вышло и как это повлияло на меня, я, может быть, расскажу в следующий раз (спойлер: деграднул я на отличненько). Так или иначе, в си-подобные языки я пришёл уже с некоторым бэкграундом и учил их, как иностранные. Это значит, что на работе я переводил код в голове на бейсик, решал на нём задачу и переводил обратно. Не строчка за строчкой, разумеется, но, по крайней мере, в более привычную мне терминологию. Прошло пару лет, прежде чем я научился думать сразу в сишных терминах. Статическая функция, виртуальная функция — это те слова, которыми я теперь оперирую в голове. И если встречаю новый язык, я продолжаю думать в этих же терминах, даже если там для этого используются другие ключевые слова. То есть снова перевожу в голове.
— Что за бред? — возможно, подумали вы сейчас. — Ключевые слова меняются, но само понятие переводить не нужно. Статическая функция — она и в Африке статическая.
— Gotcha! — отвечу я вам. — Нет такого объективного явления, как статическая функция. Почему она статическая? Что в ней статичного? Переменные действительно статические, потому что они не меняются от вызова к вызову функции. А функции-то почему статические? Только потому, что кто-то в своё время пожалел на них новые ключевые слова? По смыслу бы больше подошло «общие функции».
С виртуальностью такая же история. Это устоявшаяся в ООП терминология, но представьте, что вы магл, ничего не знаете о программировании и слышите все эти «виртуальная функция», «чистая виртуальная функция», «абстрактный класс», «изолированный (sealed) класс». Многое ли вы поняли? Если подумать, это почти рандомные слова, мало отражающие явление. А теперь сравните с Overridable, NotOverridable, MustOverride, Inherits, MustInherit… Гораздо больше смысла, не правда ли? Если вы ещё не догадались, в бейсике именно так. И Shared для статических функций. Но говорить нам привычнее на птичьем языке виртуальности. И если вы попробуете писать на VB.Net, вы наверняка будете в голове переводить overridable в virtual.
Думаю, многие не поймут, о чём эта заметка. Для них это останется какой-то сомнительной речью о том, что уродский многословный синтаксис бейсика лучше ёмких устоявшихся терминов. Впрочем, так и должно быть. Ведь язык определяет сознание.
Обсудить
#лайт
На днях бложику стукнул год. А я и не заметил. Как же быстро всё-таки летит время. Но сейчас не об этом. Тема сегодняшней записи «Язык определяет сознание». Это довольно древняя гипотеза и в наши дни большинством из нас принимаемая. То, что язык программирования также определяет сознание, мысль, в общем-то, тоже не новая, но довольно важная.
Задумывались ли вы насколько глубоко он его определяет? И я сейчас даже не про то, что каждая парадигма предполагает перестроить мышление. Я говорю о более фундаментальных вещах. О том, что вшивается нам в подсознание и в каких терминах мы начинаем думать.
Вы наверняка слышали в той или иной вариации цитату Дейкстры: «студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации».
Так уж вышло, что моим родным языком был как раз бейсик (да-да, я был из тех детей, которые больные ублюдки). И я очень долго не слазил с бейсика принципиально. Как так вышло и как это повлияло на меня, я, может быть, расскажу в следующий раз (спойлер: деграднул я на отличненько). Так или иначе, в си-подобные языки я пришёл уже с некоторым бэкграундом и учил их, как иностранные. Это значит, что на работе я переводил код в голове на бейсик, решал на нём задачу и переводил обратно. Не строчка за строчкой, разумеется, но, по крайней мере, в более привычную мне терминологию. Прошло пару лет, прежде чем я научился думать сразу в сишных терминах. Статическая функция, виртуальная функция — это те слова, которыми я теперь оперирую в голове. И если встречаю новый язык, я продолжаю думать в этих же терминах, даже если там для этого используются другие ключевые слова. То есть снова перевожу в голове.
— Что за бред? — возможно, подумали вы сейчас. — Ключевые слова меняются, но само понятие переводить не нужно. Статическая функция — она и в Африке статическая.
— Gotcha! — отвечу я вам. — Нет такого объективного явления, как статическая функция. Почему она статическая? Что в ней статичного? Переменные действительно статические, потому что они не меняются от вызова к вызову функции. А функции-то почему статические? Только потому, что кто-то в своё время пожалел на них новые ключевые слова? По смыслу бы больше подошло «общие функции».
С виртуальностью такая же история. Это устоявшаяся в ООП терминология, но представьте, что вы магл, ничего не знаете о программировании и слышите все эти «виртуальная функция», «чистая виртуальная функция», «абстрактный класс», «изолированный (sealed) класс». Многое ли вы поняли? Если подумать, это почти рандомные слова, мало отражающие явление. А теперь сравните с Overridable, NotOverridable, MustOverride, Inherits, MustInherit… Гораздо больше смысла, не правда ли? Если вы ещё не догадались, в бейсике именно так. И Shared для статических функций. Но говорить нам привычнее на птичьем языке виртуальности. И если вы попробуете писать на VB.Net, вы наверняка будете в голове переводить overridable в virtual.
Думаю, многие не поймут, о чём эта заметка. Для них это останется какой-то сомнительной речью о том, что уродский многословный синтаксис бейсика лучше ёмких устоявшихся терминов. Впрочем, так и должно быть. Ведь язык определяет сознание.
Обсудить
Будни геймдева
#пиарчик
Dark Crystal Games — студия нетипичная. Мы и не совсем сопливое инди (шутка ли: больше 20 человек!), но и бесконечно далеки от корпоративной культуры серьёзных компаний. Учитывая жанр и масштаб нашей игры, 20 человек (из которых многие заняты частично или удалённо) — это всё-таки полугаражное производство с нотками романтики и переработок.
Не то, чтобы это была уникальная ситуация, но всё же довольно редкая. Поэтому судить о всей индустрии по моему блогу не следует. Если вы начинающий разработчик из стран РУБКи (Россия, Украина, Беларусь, Казахстан), то скорее всего вы рано или поздно будете заниматься Match-3 или Hidden Object. Я в своей жизни написал не один матч-3. И не на одном языке. Так что если вы хотите подготовиться к реальному геймдеву, то вам следует почитать кого-нибудь из этой области.
Вот, например, бложек с говорящим названием «Будни геймдева» — о том, чем реально живёт и дышит отечественный геймдев сегодня и чем занимается изо дня в день (спойлер: не только матч-3). Это бложек о выстраивании процессов, о продвижении, плейтестах и выставках.
Подписывайтесь: @devmygame
#пиарчик
Dark Crystal Games — студия нетипичная. Мы и не совсем сопливое инди (шутка ли: больше 20 человек!), но и бесконечно далеки от корпоративной культуры серьёзных компаний. Учитывая жанр и масштаб нашей игры, 20 человек (из которых многие заняты частично или удалённо) — это всё-таки полугаражное производство с нотками романтики и переработок.
Не то, чтобы это была уникальная ситуация, но всё же довольно редкая. Поэтому судить о всей индустрии по моему блогу не следует. Если вы начинающий разработчик из стран РУБКи (Россия, Украина, Беларусь, Казахстан), то скорее всего вы рано или поздно будете заниматься Match-3 или Hidden Object. Я в своей жизни написал не один матч-3. И не на одном языке. Так что если вы хотите подготовиться к реальному геймдеву, то вам следует почитать кого-нибудь из этой области.
Вот, например, бложек с говорящим названием «Будни геймдева» — о том, чем реально живёт и дышит отечественный геймдев сегодня и чем занимается изо дня в день (спойлер: не только матч-3). Это бложек о выстраивании процессов, о продвижении, плейтестах и выставках.
Подписывайтесь: @devmygame
Несколько банальных мыслей про облака и кроссплатформу
#лайт
В интересное время живём, друзья. Не так давно прошло E3 и я, как и многие из вас, смотрел большинство трансляций в прямом эфире. Только вот для меня главным событием конференции были не анонсы игр, а упор на облачные сервисы. XCloud у Microsoft, Орион у Беседки, подписка на игры Ubisoft в Google Stadia. О стриминговых сервисах говорили и раньше, но теперь это становится всеобщим трендом.
Тренды в игровой индустрии бывали всякие: мобилочки, VR, да те же батлрояли, в конце концов. Но всё это были ответвления — иногда успешные, иногда не очень — но всё же просто ответвления, а не полный переход к чему-то новому. А вот стриминг может в перспективе охватить 100% индустрии.
Я знаю, о чём вы сейчас подумали. Огромные лаги, которые невозможно преодолеть физически. Но это решается локальными серверами. Это лишь дело времени. Давайте заглянем прямиком в то время, когда игровой датацентр стоит уже и в вашем регионе. Что это будет означать для индустрии? Несколько вещей. И каждая из них интересна.
Во-первых, нас ждёт подписочная модель вместо покупки конкретных игр. Я очень болею за любые сервисы, которые пытаются составить конкуренцию Steam, потому что он мешает развитию индустрии; и подписочные сервисы могут не только посодействовать этому процессу, но и гарантировать, что победитель не станет новым драконом. Ведь подписка меняет само отношение к играм, разрушает главный механизм психологического рабства у конкретного сервиса — коллекционирование.
#лайт
В интересное время живём, друзья. Не так давно прошло E3 и я, как и многие из вас, смотрел большинство трансляций в прямом эфире. Только вот для меня главным событием конференции были не анонсы игр, а упор на облачные сервисы. XCloud у Microsoft, Орион у Беседки, подписка на игры Ubisoft в Google Stadia. О стриминговых сервисах говорили и раньше, но теперь это становится всеобщим трендом.
Тренды в игровой индустрии бывали всякие: мобилочки, VR, да те же батлрояли, в конце концов. Но всё это были ответвления — иногда успешные, иногда не очень — но всё же просто ответвления, а не полный переход к чему-то новому. А вот стриминг может в перспективе охватить 100% индустрии.
Я знаю, о чём вы сейчас подумали. Огромные лаги, которые невозможно преодолеть физически. Но это решается локальными серверами. Это лишь дело времени. Давайте заглянем прямиком в то время, когда игровой датацентр стоит уже и в вашем регионе. Что это будет означать для индустрии? Несколько вещей. И каждая из них интересна.
Во-первых, нас ждёт подписочная модель вместо покупки конкретных игр. Я очень болею за любые сервисы, которые пытаются составить конкуренцию Steam, потому что он мешает развитию индустрии; и подписочные сервисы могут не только посодействовать этому процессу, но и гарантировать, что победитель не станет новым драконом. Ведь подписка меняет само отношение к играм, разрушает главный механизм психологического рабства у конкретного сервиса — коллекционирование.
Во-вторых, кроссплатформенные (в старом значении слова) движки постепенно утратят актуальность. Незачем уметь запускаться нативно на всех платформах, когда можно написать игру под одну, а на остальные стримить. И не урезанный Ведьмак 3 на Switch, как это сделано сейчас, а самый что ни на есть полноценный. Мне этот пункт особенно важен, так как я долгое время следил за развитием кроссплатформенности графики. До 2007 года всем было по фиг на OpenGL в большом геймдеве. Писали на том, на чём было удобно, так что DirectX был де факто стандартом индустрии. Всякая срань, типа Wii и NDS отличалась технически настолько, что там о какой-то кроссплатформенности из коробки речи обычно не шло. Там было полноценное портирование (то есть переписывание значительных частей кода). Самым заметным исключением был, пожалуй, RenderWare — кроссплатформенный движок, который стал популярным в основном благодаря тому, что на PS2 не было никакого графического API. «Sony DirectX», как его называли. Но на консоли выходило не так уж и много проектов. А вот с появлением мобилок кроссплатформенность стала мейнстримом, с OpenGL начали считаться (и именно поэтому массовый геймдев пришёл заодно и на Linux с OSX). И началась эра трансляции шейдеров и безудержных костылей. Cg сдохло окончательно, а на каждую платформу появлялось своё GAPI со своими шейдерами: HLSL, GLSL, MSL, PSSL — вот это вот всё. Писать кроссплатформенно под всё становилось проблемным. Вендорам было выгодно, чтобы вы завязывались только на их устройства. И вот только-только начало что-то устаканиваться в лице стандартного SPIR-V и тулзов вокруг него, как начали наступать облака, отменяющие в этом необходимость. Даже немного грустно. Но зато не нужно будет идти на компромиссы, а снова писать под то, на чём удобно. Кто по-вашему будет популярнее: DirectX или Vulkan? Можно обсудить в чатике.
Ну и наконец последнее, что хотелось бы закинуть в тему облаков, это то, что они неизбежно повлияют на hardware. Может так случиться, что дома мы будем пользоваться достаточно простой железкой, а все мощные вычисления уйдут на сервера. Это может пугать, но на самом деле это отличная оптимизация в масштабах планеты: процессорные мощности не простаивают у нас дома, а распределяются. Видеопамять не дублируется у каждого игрока, а может хранить ресурсы одной игры, обслуживая при этом нужды нескольких (очевидно, железо нужно будет специфическое для таких вещей). И всё это отлично укладывается в общую мировую тенденцию по уберизации и отказу от личного транспорта. В интересное время живём, друзья.
Ну и наконец последнее, что хотелось бы закинуть в тему облаков, это то, что они неизбежно повлияют на hardware. Может так случиться, что дома мы будем пользоваться достаточно простой железкой, а все мощные вычисления уйдут на сервера. Это может пугать, но на самом деле это отличная оптимизация в масштабах планеты: процессорные мощности не простаивают у нас дома, а распределяются. Видеопамять не дублируется у каждого игрока, а может хранить ресурсы одной игры, обслуживая при этом нужды нескольких (очевидно, железо нужно будет специфическое для таких вещей). И всё это отлично укладывается в общую мировую тенденцию по уберизации и отказу от личного транспорта. В интересное время живём, друзья.
Про видеотуториалы и выжимки из статей
#реклама
В каком виде вы предпочитаете получать информацию, нужную по работе? Видеотуториалы или классический текст? Если первый вариант, то у меня для вас плохие новости. Ролики — это выбор ленивых. Это и очень долго (даже с ускорением, потому что глазами вперёд текста не пробежаться) и, если понадобится вернуться к кому-то моменту, то потом уже не найдёшь (Ctrl+F в видео не работает).
Кроме того, это ещё и очень легко. Включил себе ролик и на самом деле отдыхаешь. Всякого рода менеджеры любят такой фигнёй заниматься: запустят себе плейлист обучающих лекций, и типа это они работают. А давайте я — программист — так буду делать в рабочее время? :) Нет, я, конечно, смотрю иногда доклады, но в свободное время в качестве хобби и саморазвития. А на работе надо работать, поэтому если оперативно нужна информация, то только текст.
В общем, если не врать самому себе, то потреблять информацию в тексте почти всегда эффективнее (кроме редких случаев, когда нужна наглядность). И было бы круто, если бы существовал канал, который бы делал краткие текстовые перессказы видосов. А вот есть такой! И не только из видео, но и из длинных статей. Подписывайтесь: Product Gamedev.
Жалко только, что статьи лишь на тему продакт менеджмента, аналитики и геймдизайна. Был бы такой канал по программированию, цены бы ему не было. А может уже есть такой? Подскажите в чатике.
#реклама
В каком виде вы предпочитаете получать информацию, нужную по работе? Видеотуториалы или классический текст? Если первый вариант, то у меня для вас плохие новости. Ролики — это выбор ленивых. Это и очень долго (даже с ускорением, потому что глазами вперёд текста не пробежаться) и, если понадобится вернуться к кому-то моменту, то потом уже не найдёшь (Ctrl+F в видео не работает).
Кроме того, это ещё и очень легко. Включил себе ролик и на самом деле отдыхаешь. Всякого рода менеджеры любят такой фигнёй заниматься: запустят себе плейлист обучающих лекций, и типа это они работают. А давайте я — программист — так буду делать в рабочее время? :) Нет, я, конечно, смотрю иногда доклады, но в свободное время в качестве хобби и саморазвития. А на работе надо работать, поэтому если оперативно нужна информация, то только текст.
В общем, если не врать самому себе, то потреблять информацию в тексте почти всегда эффективнее (кроме редких случаев, когда нужна наглядность). И было бы круто, если бы существовал канал, который бы делал краткие текстовые перессказы видосов. А вот есть такой! И не только из видео, но и из длинных статей. Подписывайтесь: Product Gamedev.
Жалко только, что статьи лишь на тему продакт менеджмента, аналитики и геймдизайна. Был бы такой канал по программированию, цены бы ему не было. А может уже есть такой? Подскажите в чатике.
Про бег и уравнения
#код
По моим наблюдениям практически единственное, что у людей остаётся в памяти из школьной программы по математике — это как находить дискриминант квадратного уравнения. Забавно, но при разработке игр это как раз надо крайне редко. Я вот, например, без гугла и не скажу, где там минус и из кого. А вот тригонометрию всякую помню наизусть, потому что нужно каждый день. Но иногда всё-таки дискриминант тоже нужен. Сейчас приведу пример. Собственно, весь дальнейший пост будет просто иллюстрацией типичного случая, когда нужно немножко математики (серьёзно, ничего другого не будет).
Вот потребовалось мне сделать, чтобы человек на бегу останавливался синхронно с анимацией. У нас в аниматоре есть параметр скорости движения. Один метр в секунду — лёгкий шаг, два быстрый, три и более — бег. И так настроено, что ноги двигаются аккурат с этой скоростью. Резко этот параметр дёргать нельзя (будет скачок), надо плавненько. Но и когда моделька на месте стоит, долго крутить ползунки тоже нельзя — будет ногами в воздухе болтать. В идеале надо чтобы всегда скорость движения персонажа совпадала с анимацией. То есть для этого надо начать тормозить чуть заранее фактической остановки.
А двигается персонаж у нас по точкам. От точки к точке по прямым линиям. Если точка последняя в маршруте или там очень резкий поворот, то, очевидно, в этом месте персонаж должен полностью остановиться (и развернуться). Если же поворот не сильный, то можно лишь слегка притормозить, а то и вообще пройти поворот на максимальной скорости.
Вот и получается, что в каждый момент времени у нас есть текущая скорость, расстояние до ближайшей поворотной точки и скорость, которая должна быть на финише. Если персонаж разгоняется до максимальной скорости, скажем, за один метр пути, а тормозит за два, и при этом у нас 100 метров до финиша, то вопросов не возникает. Но как быть, если расстояние до следующей маршрутной точки всего метр? Сколько времени мы можем позволить себе разгоняться на этом пятачке, прежде, чем начать тормозить, чтобы остановиться точно в конце? А может у нас уже ненулевая скорость и вообще нет времени сопли жевать и пора экстренно тормозить? Может быть даже резче обычного (если дверь закрылась прямо перед носом). Ну и, конечно же, надо, чтобы всё эта байда от FPS никак не зависела.
Как быть в этой ситуации? Известно как: составлять систему уравнений и решать, как в школе. Сперва я, правда, вычитаю дистанцию, которую персонажу в любом случае надо пройти, чтобы компенсировать разницу между начальной и конечной скоростями. Так что в начале и в конце манёвра мы имеем одинаковую известную скорость v1. А в конце ускорения (и перед началом торможения) неизвестную скорость v2. Ещё нам известна общая длина пути s, а также a1 и a2, то есть ускорения разгона и торможения соответственно, но неизвестны их длительности t1 и t2.
Записываем это в виде формул равноускоренного движения и понеслась. Я имею привычку набрасывать решения в paint.net, так что весь процесс вы можете наблюдать в шапке поста. В конце остаётся посчитать коэффициенты и найти корни квадратного уравнения.
Вот примерно так у нас теперь персонажи ходят. Всё, правда, несколько сложнее, потому что надо ещё погемороиться с поворотами, но это уже другая история.
Обсудить
#код
По моим наблюдениям практически единственное, что у людей остаётся в памяти из школьной программы по математике — это как находить дискриминант квадратного уравнения. Забавно, но при разработке игр это как раз надо крайне редко. Я вот, например, без гугла и не скажу, где там минус и из кого. А вот тригонометрию всякую помню наизусть, потому что нужно каждый день. Но иногда всё-таки дискриминант тоже нужен. Сейчас приведу пример. Собственно, весь дальнейший пост будет просто иллюстрацией типичного случая, когда нужно немножко математики (серьёзно, ничего другого не будет).
Вот потребовалось мне сделать, чтобы человек на бегу останавливался синхронно с анимацией. У нас в аниматоре есть параметр скорости движения. Один метр в секунду — лёгкий шаг, два быстрый, три и более — бег. И так настроено, что ноги двигаются аккурат с этой скоростью. Резко этот параметр дёргать нельзя (будет скачок), надо плавненько. Но и когда моделька на месте стоит, долго крутить ползунки тоже нельзя — будет ногами в воздухе болтать. В идеале надо чтобы всегда скорость движения персонажа совпадала с анимацией. То есть для этого надо начать тормозить чуть заранее фактической остановки.
А двигается персонаж у нас по точкам. От точки к точке по прямым линиям. Если точка последняя в маршруте или там очень резкий поворот, то, очевидно, в этом месте персонаж должен полностью остановиться (и развернуться). Если же поворот не сильный, то можно лишь слегка притормозить, а то и вообще пройти поворот на максимальной скорости.
Вот и получается, что в каждый момент времени у нас есть текущая скорость, расстояние до ближайшей поворотной точки и скорость, которая должна быть на финише. Если персонаж разгоняется до максимальной скорости, скажем, за один метр пути, а тормозит за два, и при этом у нас 100 метров до финиша, то вопросов не возникает. Но как быть, если расстояние до следующей маршрутной точки всего метр? Сколько времени мы можем позволить себе разгоняться на этом пятачке, прежде, чем начать тормозить, чтобы остановиться точно в конце? А может у нас уже ненулевая скорость и вообще нет времени сопли жевать и пора экстренно тормозить? Может быть даже резче обычного (если дверь закрылась прямо перед носом). Ну и, конечно же, надо, чтобы всё эта байда от FPS никак не зависела.
Как быть в этой ситуации? Известно как: составлять систему уравнений и решать, как в школе. Сперва я, правда, вычитаю дистанцию, которую персонажу в любом случае надо пройти, чтобы компенсировать разницу между начальной и конечной скоростями. Так что в начале и в конце манёвра мы имеем одинаковую известную скорость v1. А в конце ускорения (и перед началом торможения) неизвестную скорость v2. Ещё нам известна общая длина пути s, а также a1 и a2, то есть ускорения разгона и торможения соответственно, но неизвестны их длительности t1 и t2.
Записываем это в виде формул равноускоренного движения и понеслась. Я имею привычку набрасывать решения в paint.net, так что весь процесс вы можете наблюдать в шапке поста. В конце остаётся посчитать коэффициенты и найти корни квадратного уравнения.
Вот примерно так у нас теперь персонажи ходят. Всё, правда, несколько сложнее, потому что надо ещё погемороиться с поворотами, но это уже другая история.
Обсудить
Две истории моей юности про вирусы
#код
Чатик ожил и пристыдил меня за молчание на канале. Что ж, давайте я вам расскажу две истории про вирусы. В первой я буду выступать злостным создателем вредоносного ПО, а в другой, напротив, окажусь доблестным антихакером (блин, количество баек, которые я могу рассказывать в барчиках стремительно сокращается из-за бложека).
Когда мне было лет 14, я уже два года писал примитивные игры на бейсике, делал карты для Half-Life (иногда даже на заказ), и тому подобные вещи. Словом, файлы моего производства распространялись среди знакомых довольно широко и запускались несмотря на угрозы антивируса без подозрений. А ещё мы тогда играли в StarCraft через HyperTerminal (некоторые подписчики, наверняка, таких слов даже не слышали, но это была такая штука, позволяющая соединяться в локальную сеть через телефонные модемы). Само собой, я тоже захотел сделать сетевую игру. После успешного релиза и плейтеста моих крестиков-ноликов на WinSockets, у меня появился мой первый (и последний) коварный план по написанию вирусов. Идея была поистине хитроумной для моих лет. Я собирался написать клиент шахмат, который бы также позволял лазить по файловой системе другого игрока, пока ты якобы размышляешь над ходами. Му-ха-ха! Оценили масштаб вероломства?
От злодеяния меня тогда остановила только внутренняя тяга к свету и уважение личных границ… Сейчас, глядя на код тех крестиков-ноликов, можно подумать, что меня также остановила техническая неспособность написать что-то столь сложное, как шахматы. Но пару лет спустя, уже в университетские годы, когда я написал сетевые «точки» (родственник игры «го»), я всё-таки встроил в клиента возможность лазить по чужой файловой системе. Встроил, сыграл с жертвой, но не воспользовался. Потому что я кайфанул от самого факта «взлома», а шпионить за людьми всё же нехорошо.
Первая история была для разминки, но вторая будет более захватывающей. Родители никогда не воспринимали всерьёз моё увлечение разработкой игр, поскольку не особенно отличали это занятие от собственно игр, долго отговаривали поступать на программиста, но в какой-то момент всё же смирились и даже в середине первого курса подарили мне личный ноутбук. Даже у старшего брата не было отдельного компа, а у меня был. И я с гордостью таскался с этой почти 5-килограммовой махиной в универ. Опять же, некоторые подписчики могут офигеть, но тогда это был нормальный вес для ноутбука и в них, представьте себе, пихали даже CD-ROM.
Так вот. Родители на тот момент хотя и расщедрились, но всё же не особо видели во мне программиста. Всё изменилось, когда однажды родители подхватили вирус. Стандартное по тем временам дерьмо про то, что комп заблокирован, и вы должны куда-то там перевести деньги. Курсор не реагирует, диспетчер задач не вызывается, безопасный режим не помогает. Переустанавливать винду не хочется.
В определённый момент я запихиваю в привод диск какой-то игрушки и слышу, что играет музыка автоплея, хотя самого окна на экране нет. В это мгновение я понимаю, как вирус работает. Я тогда как раз читал книгу форума VBStreets — сборник различных нетривиальных ухищрений с Visual Basic. Среди всего прочего там был пример по созданию дополнительных рабочих столов в Windows. Если кто не знал, такая возможность программно была встроена даже в XP, просто не была протянута в интерфейс. И вот то, как вёл себя вирус, было чертовски похоже на запуск примеров кода по рабочим столам (если тебя переключили на другой стол, ты никак не можешь повлиять на другие).
Что же делаю я? Я сообщаю родителям, что могу написать антивирус, сажусь за ноутбук, пишу за час-другой программу, которая создаёт новый десктоп и открывает там окно-переключалку между столами; создаю файл autoplay и записываю его на болванку. Затем вставляю свежезапечённый диск в заражённую машину и — о чудо — на экране появляется окошко с кнопкой, возвращающей управление компьютером. После чего уже руками нахожу и убиваю остатки вируса. Стоит ли говорить, как после этого выросло уважение ко мне со стороны родителей?
Обсудить
#код
Чатик ожил и пристыдил меня за молчание на канале. Что ж, давайте я вам расскажу две истории про вирусы. В первой я буду выступать злостным создателем вредоносного ПО, а в другой, напротив, окажусь доблестным антихакером (блин, количество баек, которые я могу рассказывать в барчиках стремительно сокращается из-за бложека).
Когда мне было лет 14, я уже два года писал примитивные игры на бейсике, делал карты для Half-Life (иногда даже на заказ), и тому подобные вещи. Словом, файлы моего производства распространялись среди знакомых довольно широко и запускались несмотря на угрозы антивируса без подозрений. А ещё мы тогда играли в StarCraft через HyperTerminal (некоторые подписчики, наверняка, таких слов даже не слышали, но это была такая штука, позволяющая соединяться в локальную сеть через телефонные модемы). Само собой, я тоже захотел сделать сетевую игру. После успешного релиза и плейтеста моих крестиков-ноликов на WinSockets, у меня появился мой первый (и последний) коварный план по написанию вирусов. Идея была поистине хитроумной для моих лет. Я собирался написать клиент шахмат, который бы также позволял лазить по файловой системе другого игрока, пока ты якобы размышляешь над ходами. Му-ха-ха! Оценили масштаб вероломства?
От злодеяния меня тогда остановила только внутренняя тяга к свету и уважение личных границ… Сейчас, глядя на код тех крестиков-ноликов, можно подумать, что меня также остановила техническая неспособность написать что-то столь сложное, как шахматы. Но пару лет спустя, уже в университетские годы, когда я написал сетевые «точки» (родственник игры «го»), я всё-таки встроил в клиента возможность лазить по чужой файловой системе. Встроил, сыграл с жертвой, но не воспользовался. Потому что я кайфанул от самого факта «взлома», а шпионить за людьми всё же нехорошо.
Первая история была для разминки, но вторая будет более захватывающей. Родители никогда не воспринимали всерьёз моё увлечение разработкой игр, поскольку не особенно отличали это занятие от собственно игр, долго отговаривали поступать на программиста, но в какой-то момент всё же смирились и даже в середине первого курса подарили мне личный ноутбук. Даже у старшего брата не было отдельного компа, а у меня был. И я с гордостью таскался с этой почти 5-килограммовой махиной в универ. Опять же, некоторые подписчики могут офигеть, но тогда это был нормальный вес для ноутбука и в них, представьте себе, пихали даже CD-ROM.
Так вот. Родители на тот момент хотя и расщедрились, но всё же не особо видели во мне программиста. Всё изменилось, когда однажды родители подхватили вирус. Стандартное по тем временам дерьмо про то, что комп заблокирован, и вы должны куда-то там перевести деньги. Курсор не реагирует, диспетчер задач не вызывается, безопасный режим не помогает. Переустанавливать винду не хочется.
В определённый момент я запихиваю в привод диск какой-то игрушки и слышу, что играет музыка автоплея, хотя самого окна на экране нет. В это мгновение я понимаю, как вирус работает. Я тогда как раз читал книгу форума VBStreets — сборник различных нетривиальных ухищрений с Visual Basic. Среди всего прочего там был пример по созданию дополнительных рабочих столов в Windows. Если кто не знал, такая возможность программно была встроена даже в XP, просто не была протянута в интерфейс. И вот то, как вёл себя вирус, было чертовски похоже на запуск примеров кода по рабочим столам (если тебя переключили на другой стол, ты никак не можешь повлиять на другие).
Что же делаю я? Я сообщаю родителям, что могу написать антивирус, сажусь за ноутбук, пишу за час-другой программу, которая создаёт новый десктоп и открывает там окно-переключалку между столами; создаю файл autoplay и записываю его на болванку. Затем вставляю свежезапечённый диск в заражённую машину и — о чудо — на экране появляется окошко с кнопкой, возвращающей управление компьютером. После чего уже руками нахожу и убиваю остатки вируса. Стоит ли говорить, как после этого выросло уважение ко мне со стороны родителей?
Обсудить