В статье ведется сравнение с одной капсулы, но как по мне, это все равно считать показатели одного завода и думать, что он не сможет глобально нагреть землю. Но это ведь происходит…
А если все захотят пихать дата центры в море?? Тогда будет уже не одна капсула, а тысячи капсул нагревать море. А потом ещё и майнеры подключатся. Это уже может сказаться на экологии.
Стоит упомянуть факт, что экономии может и не быть вообще. Из-за общего потепления и подъема воды нужно поднимать и строить соответсвующие конструкции прибрежных городов, нужно бороться с экологическими проблемами или даже природными катастрофами. Конечно уже государства на это будут тратить деньги, но ведь эти деньги должны где-то получить. А где? Например увеличив те же налоги на прибыль.
Получается, что затопив свой дата центр, компания может создать себе ещё больше убытков в долгосрочной перспективе. Ну и, конечно, будет страдать куча людей (в том числе и сотрудники самой компании), как финансово, так и физически.
и тут выяснил, что есть такая замечательная «штука», как «Unity3d»
Поискали бы чуть получше и обнаружили, что есть такие замечательные вещи, как CoronaSDK, GameMaker или Construct хотя бы. В отличии от юнити, они для таких игр (2D то есть) и предназначены, да и легче.
Unity3D все же больше на 3д, несмотря на то, что 2д тоже можно. Просто с тем же успехом могли взять Unreal Engine, на нем вообще язык учить не обязательно, там есть визуальное программирование, которое идеально для новичков. Но все же это не целесообразно брать такие движки для таких простых задач.
А так поздравляю!)
Кстати попробуйте ещё выложить на Amazon'овский магазин. Там активность достаточно хорошая. А про раскрутку, то, к сожалению, загрузки пропорциональны затратам. Так что это закупка трафика, покупка статей на 4pda, посты в соц. сетях и так далее. Ну и конечно релиз постепенный, не сразу на мир, а потихоньку, с переводом на нужные языки и докупкой рекламы с трафиком на конкретные регионы.
Прочитал два раза и ничего не понял. Может я чего-то не понимаю, может ещё что, но такое ощущение, что новость месячной давности…
Да и постят уже по каждому чиху… На хабр-то такое зачем? Запостите начало истории и конец. Такие мелочи как-то не вписываются в тематику сайта. Это же не код… ИМХО
Проблема с путаницей существует и в коде тоже. Если уметь писать аккуратный код, то и в БП с такими макаронами проблем не будет. Лично у меня такое было разве что первые пол года, потом все стало норм, когда начал распихивать все по функциям, компонентам и прочему. В общем когда научился кодить :)
А по поводу Custom, то его использовать опасно, особенно когда делаешь мультиплатформу. Да и ноды оптимизируются компилятором, чего о Custom не скажешь, ибо он выполняется как есть.
Ну я к тому, что непосредственно советов по анриалу тут очень мало, да и они очень расплывчатые, без конкретики, например про профайлинг или Forward Render. Можно было выпилить эти вещи и написать общую статью, а не по анриалу. Либо уж расписать наоборот подробнее проблемы и как их решить в движке.
В общем-то это я так, просто подметил. Мне показалось это немного странным, так как читая всю статью не видел, причем тут анриал. А оказалось в конце пару строчек именно про него. :)
Полезная статья для руководителей и менеджеров. К сожалению, большинству кому не кинь её, они скажут «Статья ни о чем» или «Да я итак все это знаю», а когда говоришь про проблему, скажут «Щас на это нет времени».
Ну а в остальном спасибо. Вот только не понятно, почему тема Unreal Engine, ведь 98% статьи применимо к любому движку/проекту.
России и Украины, а это не тот рынок, на который стоит ориентироваться. У этого рынка очень низкие показатели доходности. Ориентироваться нужно на США.
Не знаю как с обычным софтом, но в игровой сфере Россия топ 3 платящая. Что ПК рынок, что мобильный рынок. Очень глупо обходить её стороной.
Я сама случайно нажала на свою рекламу во время тестирования. За это я получила бан.
Не знаю как у гугла, но я пользовался Appodeal, кликал на свою рекламу неоднократно (и случайно, и для тестов). Никакого бана не было, хотя, думаю, в системе есть защита.
Кстати советую попробовать, так как это аукцион рекламы, берет со всех площадок и ставит вам самую дорогую. Есть шанс заработать в разы больше.
Нужно поощрять юзера оставлять отзыв в Play Market — давать ему игровые монетки и т.д.
Насколько я знаю, это запрещено гуглом и за это тоже могут дать бан. В эпп сторе вроде тоже самое. Раньше было можно, но не сейчас.
Я уж обрадовался статьи по созданию собственных шейдеров, а тут просто использование Custom ноды. Укажите это в названии, пожалуйста.
Во первых, создание собственных шейдеров возможно через сам редактор материалов. Это и есть нодовый редактор шейдеров. Аналог Блупринтов относительно C++.
Во вторых, вы просто добавили свой компонент шейдера через HLSL вставку, а не написали весь шейдер. Название просто некорректное.
Создание своего шейдера подразумевает (помимо материалов), что вы создаете полностью свою шейдинговую модель, по своему работающую с освещением, например.
Так же хочу добавить от себя, что использование HLSL вставок не гарантирует мультиплатформенность шейдера. Более того, в документации было написано, что Custom ноды нужно писать на том языке, под какую платформу вы нацеливаетесь, хотя у меня Android платформа кушала вставки на HLSL, а не GLSL.
И ещё добавлю, что для использования некоторого функционала необходимо подать нужный блок на вход. Выше как-то криво это упомянули, но суть все равно не понятна… Например что бы в CustomNode использовать WorldLocation, необходимо подать его как параметр, а уже затем можно будет использовать эту функцию в коде (именно не того, что в параметре, а чисто как глобальную функцию).
Хотелось бы видеть подробнее алгоритм генерации. Качать исходники и копаться в чужом коде желания мало. А так у вас скорее не статья, а инструкция к вашему плагину :(
В остальном могу лишь сказать то, что при генерации второстепенные дороги можно тоже сделать сеткой. Гляньте любой американский город, там все сеткой.
Такой алгоритм был бы легче и избавил от кучи проблем и гемора в будущем с новыми потенциальными задачами (например поиск пути авто от точки А в точку Б).
Более того, такой подход выглядел бы реалистичнее, как мне кажется :)
Огромное спасибо за статью, подчерпнул для себя пару вещиц, которые не знал)
Единственное не очень понятно, ловушки касаются только С++ или БП?
Вызов RPC на сервере не выполнит саму функцию на сервере, только отошлёт команду выполнить её на клиенте. Если необходимо выполнить её и на сервере, надо вручную вызвать Implementation.
В БП Multicast RPC, например, вызывается и на сервере тоже, будучи вызванном с сервера.
Кстати, ещё одна ловушка в БП и плюсах:
OnRep функции от переменных вызываются на клиенте при получении репликации, а на сервере при простом изменении. Но если менять переменную не через Set, а другим способом (например инкремент или SetByRef), то OnRep на сервере не вызовется. В какой-то момент я просидел с этим долго.
А в плюсах изменение переменной вообще не вызывает OnRep на сервере, будь то инкремент или нет. Нужно после изменения вручную вызывать OnRep.
Зачастую, конечно, не нужен онреп на самом сервере, но, например, бывает полезно, когда нужно вызывать диспатчер всякий раз, когда меняется значение. При этом нужно сообщить всем, включая сервер.
NVIDIA уже пыталась сделать динамический глобальный свет. Получилось. Показали это в Unreal Engine 4 ещё в 2012 года. Сейчас эта штука работает на достаточно хороших фпс вот в таких же коридорных сценах.
Однако проблема в следующем:
-Для использования в анриале нужно собирать свою версию движка,
-На открытых пространствах не юзабельна,
-Они забили на ту технологию и, видимо, переключились на новую. Так было с многими вещами, похожими на это.
Гуглите VXGI.
Что касается представленного рейтрейса… Он так же будет юзабелен только для коридоров, в которых у нас есть итак статичное освещение. SSR и кубмапы отлично справляются пока с отражениями и прочим, при достаточно низкой потребляемости.
Я уже не говорю, что эти трейсы работают только на Volta. Кстати говоря, с VXGI было так же, он работает начиная с Maxwell. Конечно на самом деле запустить можно на чем угодно, просто на этих технологиях будет буст.
Я, как разработчик, давно ищу хороший риалтайм GI. Пока ничего лучше SVOGI в CryEngine я не видел :(
Все эти рейтрейсы представляли последние 10 лет уже очень много раз, но ничего не выходило. Даже учитывая растущее железо… Конечно через 3 года Volta будет обычным делом и будет как титан сейчас, но я все равно не верю, что эта штука может давать освещение тяжелой и большой сцене…
Статья полезная, но на самом деле вы написали статью о том, как научиться программировать игры. Стоило написать про вводные и про моделирование, про создание уровней или геймдизайн. Все же разработка игр это далеко не одно программирования. Как вы сами написали, это всего 10-20%.
Добавочка как раз тем, кто хочет научиться придумывать и стать геймдизайнером… Можно читать книги, можно смотреть на другие игры. Однако тут будет проблема в том, что вы не сделаете ничего нового. Все же копируя что-то, лучше не сделаешь.
Хорошей стороной считается то, что вы можете придумать игру не играя в игры и не читая о них, а смотря на окружающий мир.
Например всем известная игра, когда нельзя наступать на линии между плитками, когда идешь по улице. Это наблюдение, а не копирование.
Геймдизайнерам советую ещё следующую практику. Выйдите на улице или откройте какой-нибудь сайт, и пытайтесь придумать игру на основе того, что увидите.
Например я вижу, как человек чистит автомобиль от снега. Сразу наскакивает идея игры, где нужно как можно быстрее чистить машину от грязи/снега/песка на время. Или даже сделать экономический симулятор сети автомоек :)
Или, скажем, видите новость о том, что какого-нибудь чиновника посадили за отмывание денег. Сразу делаем игру о том, что нужно искать доказательства того, что человек как-то отмывает или ворует деньги. Смотреть документы с его выписками, собирать в игре новости и прочее.
Хочу уточнить. Не стоит, конечно, начинать делать сразу ММОРПГ и все такое. Но и делать какой-нибудь понг тоже, думаю, вряд ли будет шибко полезным. Точнее, оно будет полезным, но не так, как если бы вы писали что-то посложнее.
Для примера могу привести своего начальника. Он выучил на UE4 программирование буквально за пару месяцев, написав прикольный симулятор от первого лица. Конечно это костыльный код, но он может теперь написать почти что угодно. Свой проект, на котором он учился, он отдал другим людям, которые туда вставили графику и игра уже собирается выйти в стим.
Если учиться на легком, вам придется потратить куда больше, что бы понимать многие принципы и научиться писать что угодно.
Я в свое время тоже не начинал с таких простых игр. Сразу выбрал 3D игру с достаточно шустрым геймплеем. Писал лишь бы работало, много чего узнал и понял (особенно благодаря UE4 и БП). После этого мог писать уже что угодно и через пол года выложил в сеть свою первую игру, написав её за 2 месяца. www.youtube.com/watch?v=UbAox4khRKY Вот, кстати, и она. Квест, вроде портала, только с управлением временем.
Не надо использовать что-то навороченное вроде Unreal Engine.
В Unrel Engine как раз есть очень хорошие инструменты для новичков, которых нет больше нигде. Например Блупринты на замену C++, которые очень сильно облегчают задачу, дают легче понять, как строится логика, и что не менее важно, не дают сделать ошибок.
Так же в анриале есть редактор материалов, который заменяет HLSL код, позволяя строить свои шейдера.
Лично я так и смог нормально понять программирование. Ибо когда пытался учить код, у меня был ступор. Но вот визуальное программирование очень помогло. Не говоря уже о том, что оно ничем не хуже обычного.
Стоит начать с малого, но все же не с того, что умеешь. Я лично думаю, что нужно писать то, что ты не умеешь и не простые вещи. Например какой-нибудь шутер, где есть достаточно много аспектов разработки. Писать как можешь, писать костылями, ужасно запутанным кодом. Потом от этого сам начнешь понимать, что было сделано неудобно и неправильно.
Дело в том, что если вы учитесь на простом, вы не затрагиваете множество всего. Например аспекты ООП или КОП, взаимодействия с различными объектами разными способами и прочее.
Но вот на сложном проекте вы все это пройдете. На этом и стоит учиться. Более того, в наши дни движки предлагают такой инструментарий, что что-то простое на них делать не очень-то удобно. Например тот же Unity, который все же заточен под 3D. И геморится с, на каказось бы, простым 2D там не очень-то удобно.
Какие еще особенности геймдизайна при создании игр под VR? Давайте обсудим в комментариях.
Особенность ещё в том, что может этот весь геймдизайн-то и не нужен из-за того, что шлемы стоят как 50 игр. Далеко не все готовы так тратиться, из-за чего VR игра может быть не прибыльна. Но вообще это пока, потом, когда будут стоить копейки, проблема исчезнет. Возможно, уйдут и большая часть вышеописанных проблем.
Надо больше думать о безопасности пользователя.
Боюсь такое говорить на публике, но я бы не думал о безопасности… Лишняя трата времени и денег, а на планете итак перенаселение. Да и это все равно что думать о безопасности наркотиков. Пускай потребители сами решают за себя, что и как им делать при использовании подобного рода развлечений. Достаточно вначале написать фразу «Осторожнее, это может убить», что бы избежать судебных исков.
А если все захотят пихать дата центры в море?? Тогда будет уже не одна капсула, а тысячи капсул нагревать море. А потом ещё и майнеры подключатся. Это уже может сказаться на экологии.
Стоит упомянуть факт, что экономии может и не быть вообще. Из-за общего потепления и подъема воды нужно поднимать и строить соответсвующие конструкции прибрежных городов, нужно бороться с экологическими проблемами или даже природными катастрофами. Конечно уже государства на это будут тратить деньги, но ведь эти деньги должны где-то получить. А где? Например увеличив те же налоги на прибыль.
Получается, что затопив свой дата центр, компания может создать себе ещё больше убытков в долгосрочной перспективе. Ну и, конечно, будет страдать куча людей (в том числе и сотрудники самой компании), как финансово, так и физически.
Поискали бы чуть получше и обнаружили, что есть такие замечательные вещи, как CoronaSDK, GameMaker или Construct хотя бы. В отличии от юнити, они для таких игр (2D то есть) и предназначены, да и легче.
Unity3D все же больше на 3д, несмотря на то, что 2д тоже можно. Просто с тем же успехом могли взять Unreal Engine, на нем вообще язык учить не обязательно, там есть визуальное программирование, которое идеально для новичков. Но все же это не целесообразно брать такие движки для таких простых задач.
А так поздравляю!)
Кстати попробуйте ещё выложить на Amazon'овский магазин. Там активность достаточно хорошая. А про раскрутку, то, к сожалению, загрузки пропорциональны затратам. Так что это закупка трафика, покупка статей на 4pda, посты в соц. сетях и так далее. Ну и конечно релиз постепенный, не сразу на мир, а потихоньку, с переводом на нужные языки и докупкой рекламы с трафиком на конкретные регионы.
Да и постят уже по каждому чиху… На хабр-то такое зачем? Запостите начало истории и конец. Такие мелочи как-то не вписываются в тематику сайта. Это же не код… ИМХО
А по поводу Custom, то его использовать опасно, особенно когда делаешь мультиплатформу. Да и ноды оптимизируются компилятором, чего о Custom не скажешь, ибо он выполняется как есть.
В общем-то это я так, просто подметил. Мне показалось это немного странным, так как читая всю статью не видел, причем тут анриал. А оказалось в конце пару строчек именно про него. :)
Ну а в остальном спасибо. Вот только не понятно, почему тема Unreal Engine, ведь 98% статьи применимо к любому движку/проекту.
Однако хочу добавить:
Не знаю как с обычным софтом, но в игровой сфере Россия топ 3 платящая. Что ПК рынок, что мобильный рынок. Очень глупо обходить её стороной.
Не знаю как у гугла, но я пользовался Appodeal, кликал на свою рекламу неоднократно (и случайно, и для тестов). Никакого бана не было, хотя, думаю, в системе есть защита.
Кстати советую попробовать, так как это аукцион рекламы, берет со всех площадок и ставит вам самую дорогую. Есть шанс заработать в разы больше.
Насколько я знаю, это запрещено гуглом и за это тоже могут дать бан. В эпп сторе вроде тоже самое. Раньше было можно, но не сейчас.
Во первых, создание собственных шейдеров возможно через сам редактор материалов. Это и есть нодовый редактор шейдеров. Аналог Блупринтов относительно C++.
Во вторых, вы просто добавили свой компонент шейдера через HLSL вставку, а не написали весь шейдер. Название просто некорректное.
Создание своего шейдера подразумевает (помимо материалов), что вы создаете полностью свою шейдинговую модель, по своему работающую с освещением, например.
Так же хочу добавить от себя, что использование HLSL вставок не гарантирует мультиплатформенность шейдера. Более того, в документации было написано, что Custom ноды нужно писать на том языке, под какую платформу вы нацеливаетесь, хотя у меня Android платформа кушала вставки на HLSL, а не GLSL.
И ещё добавлю, что для использования некоторого функционала необходимо подать нужный блок на вход. Выше как-то криво это упомянули, но суть все равно не понятна… Например что бы в CustomNode использовать WorldLocation, необходимо подать его как параметр, а уже затем можно будет использовать эту функцию в коде (именно не того, что в параметре, а чисто как глобальную функцию).
В остальном про разработку своих шейдеров можно глянуть тут:
docs.unrealengine.com/en-us/Programming/Rendering
medium.com/@lordned/unreal-engine-4-rendering-overview-part-1-c47f2da65346
В остальном могу лишь сказать то, что при генерации второстепенные дороги можно тоже сделать сеткой. Гляньте любой американский город, там все сеткой.
Такой алгоритм был бы легче и избавил от кучи проблем и гемора в будущем с новыми потенциальными задачами (например поиск пути авто от точки А в точку Б).
Более того, такой подход выглядел бы реалистичнее, как мне кажется :)
Единственное не очень понятно, ловушки касаются только С++ или БП?
В БП Multicast RPC, например, вызывается и на сервере тоже, будучи вызванном с сервера.
Кстати, ещё одна ловушка в БП и плюсах:
OnRep функции от переменных вызываются на клиенте при получении репликации, а на сервере при простом изменении. Но если менять переменную не через Set, а другим способом (например инкремент или SetByRef), то OnRep на сервере не вызовется. В какой-то момент я просидел с этим долго.
А в плюсах изменение переменной вообще не вызывает OnRep на сервере, будь то инкремент или нет. Нужно после изменения вручную вызывать OnRep.
Зачастую, конечно, не нужен онреп на самом сервере, но, например, бывает полезно, когда нужно вызывать диспатчер всякий раз, когда меняется значение. При этом нужно сообщить всем, включая сервер.
Однако стратегия будет на Блупринтах. На С++ у нас сейчас идет серия по аркаде.
NVIDIA уже пыталась сделать динамический глобальный свет. Получилось. Показали это в Unreal Engine 4 ещё в 2012 года. Сейчас эта штука работает на достаточно хороших фпс вот в таких же коридорных сценах.
Однако проблема в следующем:
-Для использования в анриале нужно собирать свою версию движка,
-На открытых пространствах не юзабельна,
-Они забили на ту технологию и, видимо, переключились на новую. Так было с многими вещами, похожими на это.
Гуглите VXGI.
Что касается представленного рейтрейса… Он так же будет юзабелен только для коридоров, в которых у нас есть итак статичное освещение. SSR и кубмапы отлично справляются пока с отражениями и прочим, при достаточно низкой потребляемости.
Я уже не говорю, что эти трейсы работают только на Volta. Кстати говоря, с VXGI было так же, он работает начиная с Maxwell. Конечно на самом деле запустить можно на чем угодно, просто на этих технологиях будет буст.
Я, как разработчик, давно ищу хороший риалтайм GI. Пока ничего лучше SVOGI в CryEngine я не видел :(
Все эти рейтрейсы представляли последние 10 лет уже очень много раз, но ничего не выходило. Даже учитывая растущее железо… Конечно через 3 года Volta будет обычным делом и будет как титан сейчас, но я все равно не верю, что эта штука может давать освещение тяжелой и большой сцене…
Добавочка как раз тем, кто хочет научиться придумывать и стать геймдизайнером… Можно читать книги, можно смотреть на другие игры. Однако тут будет проблема в том, что вы не сделаете ничего нового. Все же копируя что-то, лучше не сделаешь.
Хорошей стороной считается то, что вы можете придумать игру не играя в игры и не читая о них, а смотря на окружающий мир.
Например всем известная игра, когда нельзя наступать на линии между плитками, когда идешь по улице. Это наблюдение, а не копирование.
Геймдизайнерам советую ещё следующую практику. Выйдите на улице или откройте какой-нибудь сайт, и пытайтесь придумать игру на основе того, что увидите.
Например я вижу, как человек чистит автомобиль от снега. Сразу наскакивает идея игры, где нужно как можно быстрее чистить машину от грязи/снега/песка на время. Или даже сделать экономический симулятор сети автомоек :)
Или, скажем, видите новость о том, что какого-нибудь чиновника посадили за отмывание денег. Сразу делаем игру о том, что нужно искать доказательства того, что человек как-то отмывает или ворует деньги. Смотреть документы с его выписками, собирать в игре новости и прочее.
Для примера могу привести своего начальника. Он выучил на UE4 программирование буквально за пару месяцев, написав прикольный симулятор от первого лица. Конечно это костыльный код, но он может теперь написать почти что угодно. Свой проект, на котором он учился, он отдал другим людям, которые туда вставили графику и игра уже собирается выйти в стим.
Если учиться на легком, вам придется потратить куда больше, что бы понимать многие принципы и научиться писать что угодно.
Я в свое время тоже не начинал с таких простых игр. Сразу выбрал 3D игру с достаточно шустрым геймплеем. Писал лишь бы работало, много чего узнал и понял (особенно благодаря UE4 и БП). После этого мог писать уже что угодно и через пол года выложил в сеть свою первую игру, написав её за 2 месяца.
www.youtube.com/watch?v=UbAox4khRKY Вот, кстати, и она. Квест, вроде портала, только с управлением временем.
В Unrel Engine как раз есть очень хорошие инструменты для новичков, которых нет больше нигде. Например Блупринты на замену C++, которые очень сильно облегчают задачу, дают легче понять, как строится логика, и что не менее важно, не дают сделать ошибок.
Так же в анриале есть редактор материалов, который заменяет HLSL код, позволяя строить свои шейдера.
Лично я так и смог нормально понять программирование. Ибо когда пытался учить код, у меня был ступор. Но вот визуальное программирование очень помогло. Не говоря уже о том, что оно ничем не хуже обычного.
Дело в том, что если вы учитесь на простом, вы не затрагиваете множество всего. Например аспекты ООП или КОП, взаимодействия с различными объектами разными способами и прочее.
Но вот на сложном проекте вы все это пройдете. На этом и стоит учиться. Более того, в наши дни движки предлагают такой инструментарий, что что-то простое на них делать не очень-то удобно. Например тот же Unity, который все же заточен под 3D. И геморится с, на каказось бы, простым 2D там не очень-то удобно.
Особенность ещё в том, что может этот весь геймдизайн-то и не нужен из-за того, что шлемы стоят как 50 игр. Далеко не все готовы так тратиться, из-за чего VR игра может быть не прибыльна. Но вообще это пока, потом, когда будут стоить копейки, проблема исчезнет. Возможно, уйдут и большая часть вышеописанных проблем.
Боюсь такое говорить на публике, но я бы не думал о безопасности… Лишняя трата времени и денег, а на планете итак перенаселение. Да и это все равно что думать о безопасности наркотиков. Пускай потребители сами решают за себя, что и как им делать при использовании подобного рода развлечений. Достаточно вначале написать фразу «Осторожнее, это может убить», что бы избежать судебных исков.
При Saturate он ставит сам saturate() как и положено.