YoungSkipper
0
Не соглашусь насчет того, что в юнити «встроенная компонентная архитектура не применяется», ведь механика добавления компонентов на объекты, их поиск и взаимодействие (даже обращение к встроенному свойству transform или поиск объекта в сцене) — как раз использование этой самой архитектуры. Даже автоматический вызов функций Update, LateUpdate, OnGUI и т.д. тоже является ее частью.


На самом деле увы и да. Практически не применяется в любом достаточно крупном коммерческом проекте. И собственные компонентная система, и свое связывание компонентов их с объектами. И даже тупо искать объект на сцене стандартными методами очень плохая идея — нужное кэширование все равно и самому отслеживать добавление и удаление объектов на сцене.

И автоматические вызовы выше перечисленные не используются — ну вернее висит один объект в сцене которые их получает, и уже через собственную компонентную систеум диспатчит в свои компоненты.

Ибо ответ простой — все что предлагает «встроенная компонентная архитектура в Юнити» можно написать самим и оно будет работать и быстре (сильно быстрее, на порядк) и удобной.
YoungSkipper
+1
С другой стороны даже на краткосрочных проектах это зло. Очень давно я занимался портирование j2me проектов на brew — на 3-4 проект, у меня, как и у любого «ленивого» программиста — родилась реализация всех базовых j2me методов на c++, плюс парсер java кода — и фактически 80% транслировалось на полу-автомате. И вместо базовых 2-3 месяцев на проект, у меня портирование стало занимать 2-3 недели. Рекорд вместо 2-х месяцев выделеных на проект — 7 рабочих дней. И не смотря на то, что у меня был фиксированная оплата за каждый проект (которую я оценивал при взятии проекта в работу) — то даже в таком случае приходилось отдавать проект сильно позже чем он был готов. Т.е. я его делал за 2 недели и потом 2 недели просто ждал. Ибо если отдавать сразу — то у посредника который собирал мне проекты, да и у заказчиков рождались неприятные мысли — типа раз все так просто, а не много ли мы платим. Или даже если они эти мысли гнали, то они пытались занижать сроки в дальнейшие проекты — что меня тоже не радовало, ибо фосмажры никто не отменял. И понятно, что в случае оплаты за время, подобного решения даже бы и не родилось. Что в целом конечно было бы в минус и мне, и посреднику и заказчикам.
YoungSkipper
0
Судя по всему задачи у вас достаточно короткие — типа сделал и через полгода-год-два забыл. В таком случае, подход хороший. Но он провоцирует прораммистов, решать задачу сугубо в рамках ТЗ, не задумывая о дальнейшем развитии и главнное поддержке проекта. Если вы себе это можете позволить — то да, почему бы нет — особенно, если вы не испытываете проблем с наймом.

Но в целом, для многих проектов это порочная практика — ибо любая задача может быть решена быстро, качественно но узкоспецилизированно, что не позволит в будушем генерализировать решение, и может привести к проблемам поддержки решения. А может за более долгое время — но в дальнешем ее расширять и поддерживать будет более просто. Ваш подход к оплате, не способствует к решениям второго типа — ибо при более долго времени есть шансы что вас оно не устроит (врядли вы в случаее успешных задач вникаете в причины почему они делались столько времени именно — для этого по сути нужно еще программиста), а во вторых если доработки будут делаться потом быстро — это не выгодно для программиста.
YoungSkipper
+1
Это практикуется во многих компаниях, в которых количество программистов измеряется тысячами. Не всегда это акции в чистом виде, но бонусы завязанные на акции это регулярная практика и неотемлемая часть оффера очень много где. Это очень удобный механизм со стороны компании — он во первых позволяет, в случае если дела компании идут не очень хорошо, в том числе и по не зависимым от нее причинам, таким как например общее падение рынка, существенно экономить на бонусах естественным путем, с другой стороны это отличный способ удержания сотрудников — ибо подобные бонусы как правило завязаны на время работы в компании могут погашатся частично, и чем дальше по времени — чем больше. И они кстати достаточно существенные зачастую — за трехлетний период они составляют часто более 50% годовой зарплаты. Я бы вообще сказал, что именно для крупных компаний это скорее обычная практика, чем для средних.
YoungSkipper
+1
>Хороший вопрос, но боюсь что ответ в простейшем случае — нет. Она ищет признаки, за которые можно зацепиться, на поиск которых >его «запрограммировал» создатель сети и проектировщик правил workflow.

Нет, нет. В этом и прогресс, в этом и отличие RNN от других алгоритмов. Никаких признаков в NN не «запрограммировали», она сама их нашла. В этом и суть. Не закладывается никаких зацепок. Изначально голая нейроная сеть, на вход которой подается пословно текст и все.

Я боюсь как раз в не понимании это особоенности NN и есть причина вашего топика.
YoungSkipper
+2
У нас различное представление о сложности. И понимании, того что такое алгоритм и почему он не связан с оценочной функцией.

>Как соотносятся два эти ваши высказывания меж собой?

Очень просто, это не будет NN играющая, только в SC — это будет NN общего характера, которую потенциально можно будет применить и к другим играм. Как сейчас одна и таже сеть обучается и играет в различные Atari игры, так и это обудет одна сеть, которая сможет играть в WarCraft и т.п. игры
YoungSkipper
+1
Смотрите.

Мы можем обучить NN по картинке отличать банан от огурца. Ровно так же как обучают человека — показвая ей много раз различные картинки и говоря каждый раз — это банан, а вот это огурец. При том, ровно же как и человек, если ей показать апельсин который она до этого не видела — то она скажет что это не банан и не огурец, а что не знает. Ровно как и человек

Мы можем обучить NN по картинки отличать обезьяну от человека, аналогично. Причем даже когда последняя в одежде (и NN сама найдет уникальный признак «волосатое лицо» — указывать ей на это не нужно).

Далее можно совместить и получить NN которая будет отвечть на вопросы выше. Но при этом, если ей показать бегемота который держит в зубах арбуз — она скажет — я не знаю, что это такое, но точно не обезяна с бананом и т… п Ровно как и человек, котрый не разу не видел арбуза и бегемота

Если вы считаете, что человек смотря на картинку обезьяны с бананом и отвечающий что это такое делает анализ, то почему вы отказываете в этом NN?

Далее, что самое интересное — если вы дообучаете NN отделять новый фрукт, то это не сломает всей системы — она сможет отвечать на вопрос — это человек или обезьяна с этим фруктом
YoungSkipper
0
А давайте еще пример.

Мы взяли человека, дале ему почитать много, много английской литературы. Потому мы даем ему кусок текста и просим определить автора — и он делает это достаточно хорошо. Делает ли он при этом анализ текста?

И опять же, если тоже самое делает NN и делает это лучше человека. Делает ли она при этом анализ текста?
YoungSkipper
+4
Никаких сложнейших алгоритмов там нету, это раз. Т.е. это просто NN и все. Т.е. это инструмент общего характера. А во вторых — это ровно то, что делает человек когда учится играть в незнакомую игру. Он пробует различные дейсвия и смотри на результат. И далее, смотрит какие дейсвия привели к наилучшему результату и на основе этого учится играть. В чем разница между NN и человеком в данном случае?

Когда я смотрю, как мой двухлетний ребенок учится играть в новую игру на айпаде — это реально очень похоже на то как обучается NN.

>Она как максимум тупо повторяет анализ человека, сделанный к тому же еще и брутом… (ну и делает распознавание заученных «картинок»)

А вот тут я не понял. Человек там не участвует, сеть обучается сама. Никаких специальных триков заточеных под специальную игру там нету.
YoungSkipper
+2
Человек посмотревший выборк сможет. И нейросеть посмотрев выборку сможет. Тут опять же хитрые нюансы — скажем так потеницальном сможет, и в ряде случаев сможет даже лучше человек.
Почитайте вот эту статью — https://habrahabr.ru/post/303196/

```Напомню прошлые вехи. Первая сетка, которая победила в Imagenet Recongition challenge, сделала это с ошибкой 15% в 2012. В конце 2015 допилили до 3.08%. Разумная оценка среднего результата человека — ~5%. Прогресс, как мне кажется, впечатляет.```

Про размеченные данные я отвечу выше. Да, там есть нюансы — но не все так однозначно.
YoungSkipper
0
А вот, даже на Хабре есть — https://habrahabr.ru/post/279729/
YoungSkipper
0
Более того, вы можете это повторить у себя дома сами
YoungSkipper
+1
Да безусловно я серьезно. Игры простые — но это вопрос в целом маштабирования (хотя и ряд других проблем есть)
Ключевые слова — deep reinforcement learning
Ключевой пейпер — http://www.nature.com/nature/journal/v518/n7540/abs/nature14236.html и https://www.cs.toronto.edu/~vmnih/docs/dqn.pdf
Ключевики для гугла — «neural network Atari games»

Насколько я знаю, в Гугле уже активно работают над игрой в StarCraft
YoungSkipper
0
При этом мы же понимаем, что человек который никогда не виде обезьян, бананов и огурцов сделать такой анализ не сможет
YoungSkipper
0
Опять же упираемся в вопрос что такое знание семантики и принципов? Т.е. если у нас в обущающей выборке будет достаточно размеченных данных по каждому пункту — то да, она сможет сделать такой анализ
YoungSkipper
0
А можно на примере? Вот сети на вход подают картинку из видео игры + данные из ячейки памяти отвечающией за score

Далее, сеть научилась играть в игры — т.е. проходить уровень за уровнем. Означает ли это что она проанализировала игру, и нашла «неизвестные» признаки — т.е. как нужно играть в игру (какие кнопки нажимать) чтобы выйграть? Т.е. по факту нашла правила игры — является ли это ответом да на ваш вопрос?
YoungSkipper
+1
API то было, но по сути это был software rendering — что на BREW телефонах того же времени делалось просто в коде самой игры. А тут просто они реализовали это в прошивке и прокинули из j2me вызов функций. Т.е. ни о каком хардварном ускорении речи не шло.

YoungSkipper
0
Ну все таки подобная графика, и наличие, на телефоне 3д ускорителя (по моему это был где-то 2004 год) и поддержка оным jst-184 сильно различные вещи. Если говорить о подобном 3д — я так 3д танчики (с видом из башни) писал еще для https://ru.wikipedia.org/wiki/Cybiko — что было раньше чем эта Нокия появилась на свет
YoungSkipper
0
Ну это легко детектиться, а вот помнится когда iOS решило кэшировать результаты POST запросов — вот это была радость понять, что не так.
YoungSkipper
+3
Про j2me можно сильно, сильно больше рассказать. О запихивании всего приложения в 3-5 классов — чтобы отыграть нужные сотни байт. Про первые IDEN моторолы с поддержкой j2me где товарищи разрабочики прешили, что если в стандарте написанно что поддержка прозрачности в png опциональная — то ее не нужно делать. И портирование игр под эти телефон — из серии режем картинку на куски по 4x4 пикселей, если там 2 непрозрачных пикселя и больше — то рисуем целиком. Этакий пиксель арт в пиксель арте.

Про BREW — ну это не грязный хак, но на части телефонов флешка и память была столь медленная, а процессоры по тем временам вполне быстрые — что держать в и на диске и в памяти все данные в zip-е и распаковывать при обращении на лету было быстрее, чем напрямую.

Или про первый мобильный телефон с 3д ускорителем и с j2me — уж не помню какая Моторола — которой мы радовались, пока не выяснилось, что заодно просто fillrate за счет большого экрана отнимал 30% от всего рендеринга, сводя на ноль пользу 3д ускорителя по сравнению с другими телефонами.

YoungSkipper
0
.
YoungSkipper
+3
https://en.wikipedia.org/wiki/IDN_homograph_attack

Таким образом, существует угроза использования доменных имен с подменой буквы “k” на “ĸ” и мне кажется что этот символ должен быть удален из таблицы латинских символов и не должен допускаться для регистрации доменных имен.

Почему только этот символ, а не множество других?
YoungSkipper
+2
Не тренировали. Более того, ее даже не тренируют между матчами текущей партии для чистоты эксперимента.
YoungSkipper
+2
Тут вполне я думаю применима Бритва Хэнлона:
Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью
YoungSkipper
+30
Instagram является частью/принадлежит Facebook
YoungSkipper
0
Уточню — что один проект (физически в одной папке находящийся) таки нельзя. Но в целом же каждый план/job — это отдельная папка.
YoungSkipper
0
С флоатами небось по конвертации забыли указать CultureInfo.InvariantCulture, а так поведение то ок — разная локаль, различное представление.

А с логом — хороший глубокий стек-трейс потянет на 3кб, ну а дальше 10к+ сущностей, по 10 записей в лог на сущность, 10+ типов бандлов (различные сжатия + sd/hd) и вуаля. У нас бандлы тоже на билд сервере собираются.

YoungSkipper
0
У юнити еще забавный, не совсем очевидный баг есть со сборкой. Если размер лог файла начинает превышать 2gb то юнити падает с невнятной ошибкой. У нас проект сборки ресурсов много писал в лог, плюс колл стеки раскрывается. И в какой-то момент, оно начало падать. Так как сборка инкрементальная — про при повторном запуске было все ок. Намучались мы.
YoungSkipper
0
По крайней мере вот это
Проекты под Unity не собираются параллельно. То есть одновременно может быть запущена только одна сборка на одном компьютере.
не верно. У нас в пиковый момент на билд сервере может одновременно думаю до проектов 7-ми собираться. Т.е. семь инстансов юнити запущено может быть — как и одной версии, так и разных.
YoungSkipper
+4
А вы уверены, что оптимизируете тяжелые вычисления лучше, чем это сделают современные с++ компиляторы? Потому как трансляция в asm.js сейчас очень близка к оптимальной.
YoungSkipper
+2
Недовольство очень простое — внутренней памяти на дешевом телефоне допустим 4 гигабайта — и ее постоянно не хватает, а карточку можно поставить на 32 гигабайта.

obb не помогут — на тех девайсах на которых getExternalStorageDirectory указывает на внутреннюю память при наличии SD карточки, obb тоже будут качаться на внутреннюю память
YoungSkipper
0
Я вот тоже не понимаю, но сколько было возмущенных пользователей которые кричали чтобы игра скачивала ресурсы именно на флешку, а не в Environment.getExternalStorageDirectory() — мы пока не сделали имели тысячи единиц в отзывах из-за этого. И кстати, все вышеописанные шаманства все равно не спасают и будут экзотические девайсы в которых определить верно не получится — поэтому еще и возможность руками ввести путь добавили.
YoungSkipper
+9
Если взять все же чуть более сложный пример, чем просто возведение в степень — то замены особо то и нету.

У нас в компании есть бот который проходит игру — т.е. чистое автоматическое тестирование, по тем или иным тригерам собирается билд, заливается на девайс и включается бот встроенный игру на прохождение игры — и бот присылает отчет в результате.

В том числе, бот начинает играть не только с начала, а с определенных сохраненных сейвов. В том числе часть (несколько сотен) этих сейвов взяты с реальных сейвов игроков которые выбраны случайным образом. Ибо игрок может загнать игру в такую комбинацию, никакой бот не загонет.

Альтернативы вот этой случаности я не вижу. Генерить собственные сейвы очень сложная задача. Можно оставлять сейвы с предыдушего прогона бота — но основные баги как раз находятся из-за доигрывания сейвов игроков.
YoungSkipper
–3
Затем что FREE увеличивает конверсию… все еще. Как перестанет, не будут писать.
YoungSkipper
+1
Задача привлечь больше денег на пожертвования — вы можете сделать малый вклад и просто пожертвовать деньги, а можете большой — облиться водой и привлечь еще участников. С учетом k-factor-а близкого к 3-ем, последнее более полезно с точки зрения благотворительности.

Ну и ничто не мешает и облиться и пожертвовать полную сумму, помимо прочего.
YoungSkipper
+9
Присылать в письме мой пароль это моветон нынче. И вообще, это навивает на мысли, что в добавок вы его еще и в открытом виде храните.
YoungSkipper
+2
Гейм-дизайнер это очень широкая профессия. Она включает туда очень многое — от собственно игровой механики, до расчета игровых метрик и построения математических моделей. Плюс UX аспекты по середине.

Просто стать гейм-дизайнером на игровом проекте крупном практически не возможно. В эту должность нужно заходить потихоньку.

Можно начать с тестера. Можно начать с менежера конктента/квестовика. Можно имея хороший бэкграунд в построении математических моделей — пойти на аналитика. И т.п.

Поработать в крупном проекте.

Я знаю много гейм-дизайнеров, часть их них с 10+ опытом в гейм деве. Но все из них первые лет 5 работали на других должностях. Как правило это варианты контент менеджера — сидели в админке заводили предметы/квесты и т.п.
YoungSkipper
0
Много идей относительно игровых механик? Отлично, это как минимум означает, что вы знакомы с игровыми механиками в текущих играх. Бериту простые, но популярные игры (10кк игроков) — и разбирайте их игровые механики — основной геймлуп, что и как, как монитизация и т.п.

Вот отличный пример — www.deconstructoroffun.com/

Пару десятков статей вот такого уровня — www.deconstructoroffun.com/2012/09/clash-of-clans-winning-formula.html

Годик регулярного ведения блога — и поверте вас заметят.
YoungSkipper
+1
Т.е. старший у вас тоже на дневной сон засыпает? Хорошо вам. Ну или если дает жене поспать с младшим — то тоже круто.

Ну я тогда расписывать не буду второй пост, более менее понятно.
Но фактически получается, что вечером у вас совместного регулярного времени с женой нет.
А утром, фактически только 1 час?

Моя будет не согласна :)
YoungSkipper
+1
Спасибо за статью. Вы молодец. Пока более быстрый вопрос, про вас понятно более менее, хочется про жену уточнить. Младший у вас на ГВ? Ибо 7 часов сна (22-5) для жены с учетом 2-3 ночных кормлений должно вырождаться в 5, ну 6 часов максимум? Как она?