Наследник Monobehaviour навешиваемый на GO — это и есть компонент в данном контексте. И можно писать в таком стиле, что данные компоненты будут View-Model. Можно писать в другом стиле. Я скорее не понял суть вопроса :) Есть такой стиль архитектуры для проекта. Это не раскрывается, потому что как в юнити пишутся разные архитектурные схемы, почему любой крупный проект это всегда гибрид, и где лучше реактивный подход, а где другой — это не тема статьи :)
Брать джунов и мидлов нужно только затем, что нужны новые сеньоры. Иначе скоро один сеньор будет стоить, как крыло от боинга (хотя я не скажу, что я против) :) В остальном в 99% случаев - это расход ресурсов и денег :) Сеньоры делают быстрее всё. И рутину, и сложные задачи. Что рутину часто впадлу делать - это другой вопрос. Но когда ты задачу решал 150 раз, то в 151 ты делаешь её примерно за минуту. Сеньорам есть что обсудить на ревью, и часто сеньорам лень менять компанию, так как денег платят везде на определённом уровне в тех же корпах +- одинаково. И если ты уже "устал от приключений", ты просто работаешь на проекте и не паришься. Чаще всего мотивацией смены работы я видел скуку, а не вопрос деньгах. Лидами вообще многие становится в принципе не хотят.
В большинстве своём сеньоры - это такие бывалые, уставшие профессионалы, которым плевать что делать, так как они умеют очень многое и на контекст задачи смотрят, как на предметную область. Бывает кто-то ещё горит работой, но за 6 лет+ ты начинаешь к программированию (коммерческому) относится филосовски. Пилишь какой-то пет проектик, если тебе не надоело программировать, так как там никто не меняет бизнес требования, не переобувается на лету, не нужно думать о коммерческих рисках использования той или иной технологии. А коммерция вся +- одна и та же, меняется по моему опыту разве что контекст. Поэтому нет смысла менять особо компанию, так как поменяешь в большинстве случаев одно на другое, если не подвернётся действительно супер интересный проект :)
Ну с компьютами в рядах случаев удобнее работать именно в графе. Но тут есть несколько нюансов. Я очень долго был старовером не пользующимся нодовыми редакторами, но сейчас я возможностью делать кастом ноды я больше склоняюсь к ним. И тут есть свои плюсы и минусы в одном флаконе
1. Высокий уровень абстракции может оптимизироваться автоматически
Шейдеры написанные на glsl и hlsl нельзя оптимизировать компилятором, так как это довольно чёткие инструкции о том, что надо сделать. А вот графы проще оптимизировать, проще подсовывать им реализации под VR с сингл пасс стерео рендером, так как это условно "логическое описание, а не чёткая инструкция". Но как обратная сторона любой абстракции высокого уровня, её нельзя тонко настраивать и зная юнитеков, если там будут баги - это может стать проблемой
2. Дебаг шейдеров
Чуть быстрее процесс редактирования, чуть проще организовать пере использование, но при этом ещё каждый шаг может иметь визуальный вывод, что оно делает. И вот последним шейдерный код не обладает. Типа нужно удалять куски, писать какие-то утилиты, чтобы иметь пошаговый вывод, чтобы проще было дебагать шейдер
В общем кодом я так же шейдеры пишу, но сейчас я пишу и так, и так. Просто если не требуется прям до спичек оптимизировать - графы норм. Если нужно сначала за прототипировать, описать сам эффект, глянуть его, а потом уже переписать нормально - граф в среднем будет быстрее с точки зрения "попробовать разное". А когда сам шейдер идейно готов, уже можно написать оптимально, если вдруг тормозит.
Пил пол года XD А так хз, я просто что называется "на своём месте". Выгорание у меня обычно связано со стрессом бизнеса, а не с работой. Кассовые разрывы (я терпеть не могу кому-то задерживать выплаты, но деньги из воздуха тоже пока не умею делать) и тому подобное, иногда груз ответственности
А сидеть и чё-то делать по работе я могу просто сутками и по сути не уставать. Так как это интересно)
Я скажу так. Да, название немного кликбейтное. Но по студии в чём история.
3 года она зарабатывала, не скажу что много, но на зарплаты и т.п. хватало и себе тоже. Потом я сделал ставку на конгрессно-выставочную индустрию в начале 2019 года. И тут пандемия грянула. В целом и это можно было пережить. Но я тогда уже выгорел быть постоянно в стрессе и ритме вечной работы. Выплатил всем сотрудникам доп. оклад, распустил команду, и ушёл на пол года в консалт. Так как на данный момент я один из людей разбирающихся в технологиях трекинга. Не единственный, но таких немного на вольных хлебах. От OpenCV до Vicon и Optitrack. Я перечитал очень много статей научных, делал прототипов и в целом работал с этой группой технологий последние 6 лет + учился всякому у трекинг инженеров вайкона.
Согласен. Тут важно только не столько "что значит техдир", а в том числе в какой индустрии. Я работаю В AR/VR и интерактивных визуализациях. Поэтому по моей терминологии техдир в данной индустрии, это человек который может: 1. Составить роадмап разработки продукта в данной области 2. Составить технологический стек и его обоснование, причём коммерческое 3. Составить смету на роадмап (хотя бы на пол года), понимать какой нужен штат для реализации проекта с технической точки зрения 4. Составить техническую схему решения. С оборудованием и прочими прелестями жизни. Зная какая железка лучше и почему 5. Иметь опыт реализации подобного класса проектов
И да техдир - это больше менеджер, чем технарь. Я разбираюсь в Unity, в .Net, в нюансах процессоров (кешлайн сплит, выравнивание памяти) в основном по мануалам интела, компьютерной графике (можно почитать мои статьи и мой блог), математике (когда-то давно я занимался математическим моделированием), технологиях трекинга и так далее. И в некоторых вещах я разбираюсь достаточно глубоко, так как считаю, что фундаментальные знания важнее практических. И типа по графике вот пример поста, где я по-русски пытался объяснить низкоуровневый нюанс работы гпу в паре с шиной https://t.me/dyadichenkoga/206 И докер разверну, и шел скрипт напишу. Ещё я очень поверхностно знаю реакт, питон. И прям чуть-чуть плюсы. Читать и портировать смогу, писать на нём - очень сложно и это делают какие-то ниндзя. Я конечно помню смарт поинтеры и частично 11 стандарт, но как писать быстрый код на плюсах я не знаю. Чистая архитектура, солид и т.п. У меня в целом в блоге есть разбор паттернов в контексте Unity. TCP/IP, RSTP, WebRTC и т.п. С этим всем я тоже работал, писал кастомные протоколы стриминга и много чего ещё. Но просто это в плане техдирства, особенно глубокие задачи решать, не так важно. Так как это будут делать сеньоры, которые разбираются лучше.
И вот тут может показаться уже, что я хвастаюсь. Но я также могу хвастаться числом статей, выступлениями, то что я организовывал мероприятия на 200+ человек для разработчиков, да хоть репозиториями со звёздочками (хотя там вообще ничего великого, по-моему мнению) И вот это на мой взгляд будет странно. А в статье я просто рассказал, какой путь на данный момент прошёл.
И всё это небольшая индустрия. Я конечно же не говорю, что "да ща я техдиром Яндекса стану". Но отличие техдира от техлида в том, что он знает широкий спектр технологий и может построить команду и довести её до финала в сложном интеграционном проекте. С беком, фронтом и сложными технологиями. А не в рамках узкого стека технологий. Так как техлиды часто разбираются в своём стеке (хотя тоже бывают разные) Поэтому я ушёл в "продюсирование проектов на заказ" с подбором команды под проект, и работаю сам по себе.
Просто безусловно существуют разные масштабы команд, компаний и т.п. Я ща на вольных хлебах и консультирую часть компаний и стартапов. Просто писал я немного не о том.
Выше есть комент про L7+ FAANG, и с ним я согласен за исключением одного нюанса. Это всё оптимальная стратегия, когда ты хотя бы номинально сеньор. Я же писал скорее про путь джун-сеньор. С позиции сеньора варианты развития в разы разнообразнее, сложнее и интереснее. А проходить так участок пути джун-сеньор - оптимальнее.
Любой работодатель знает, что хай левел сотрудник начинает приносить прибыль минимум через полгода. С моим зарплатным запросом если я уйду после испытательного, я просто потрачу деньги компании. В чём я не вижу смысла, а уходить на испытательном, если мне не подходит работа — нормальная практика.
Это та позиция, которую мне предлагают. В студии я отвечал не только за техническую часть, но это особо значения не имеет) В студии — это была моя компания)
Скучно не технически, а по спектру обязанностей. А на сеньора мне нет идти смысла из-за текущего дохода даже в теории. И свои обязательства перед заказчиками я соблюдаю вне зависимости от интереса. Вы считали какой-то не тот посыл :)
Я не пойду на работу, так как мне не особо это интересно, а не то, что я технически узнал всё что можно было.
Я просто трудоголик. У меня был свой митап Unity Moscow Meetup и CGDevs, я основатель http://gamedev-calendar.ru/, 28 статей на хабре, пара выступлений (как пример https://www.youtube.com/watch?v=GUhs-emib_8 ) и много чего ещё. А так я просто рано начал работать, по сути 8 лет назад. И с тех пор работаю сутками. Плюс везло очень много, особенно с теми, кто мне по ходу что-то объяснял :)
Ну сводно всю инфу я тут собрал https://noxatra.ru/ чё я делал за последние годы. А так, работа и везение. Ну и маховик времени конечно же :)
Дак я прогорел в своё время. У меня была своя студия, которую я закрыл не от хорошей жизни) Был неопытный, совершил много ошибок, но добила меня пандемия. Так что согласен, но просто я наверное опустил ряд деталей про которые можно рассказать. Закрывал я студию, не как успешный кейс с чемоданом денег, а с минусом в несколько миллионов рублей. И этот минус я разгребал ещё пару лет.
Тут может показаться, что это история успеха, так как я в целом всегда на позитиве. Но на самом деле — это просто история на данный момент, и всё ещё впереди :) И деятельность моя текущая не всем подойдёт, она тоже имеет свои скажем так особенности. Но карьерные советы рабочие, так как просто я понимаю с разных точек зрения как сейчас устроен рынок найма.
У меня ща конечно всё норм, есть свой продукт небольшой и куча всяких дел. Но так как я уже разорялся, я знаю что и сейчас хожу "по ох***но тонкому льду" и что всегда нужно держать руку на пульсе. Но в любом случае спасибо, всегда интересно послушать мнение со стороны :)
В статье просто небольшая опечатка. Сейчас поправлю 65535 конечно же. Откуда? Достаточно посмотреть структуру пакета TCP. И порт там занимает 16 бит. 2^16-1 = 65535. Но всё ещё не понимаю реакцию, так как это явно опечатка
Ну я даже немного распространю. Плохое соединение на выставках - это скорее не перегружен траффик, а радиошум. Так как много железа, телефонов и другого оборудования. Можно решить 100% - дорогим оборудованием, но с обычным тут могут быть риски задержек. Причём весьма высоких. Но эту проблему можно решить только шнуром. Потому что там и персистент коннект не спасёт, так как оборудование банально пингуется долго. Поэтому обычно когда такая штука разворачивается, ставятся специфичные условия. Хотя бы приличный роутер :)
Но геймпад это один пример применения вшитого http сервера. Есть геймплеи где задержка нажатия в 1 секунду не играет вообще никакой роли. Иногда нужно администрировать Unity приложения, которые вообще не игры. И удобнее это делать с планшетов. Но при этом с точки зрения апдейта и деплоя в разы проще просто обновлять контейнер на сервере в котором и веб лежит.
Да вы правы. Это можно немного решить, если поддержать Keep-Alive, но в общем да. Тут скорее "нет смысла в контексте рассматриваемых условий". А я рассматриваю условия "хорошие". В среднем сейчас слабый сервер, как контекст, скорее редкость, а вот плохое соединение может сыграть роль
Просто в статье не вижу смысла углубляться в детали структуры пакетов и того, как работает весь стек TCP/IP. Во-первых, по этой теме есть целые книги. Во-вторых, это не является топиком статьи. А так в модели OSI на транспортном уровне всё это описано. Можно почитать специализированную литературу по этой теме, если вдруг интересно
А что это по вашему? Это неотрицательное число от 0 до 65353 записываемое в заголовках в транспортной модели OSI. То есть просто условное число в заголовке пакета
Если у нас порт стоит 10021 на серваке. Если в термины веба переводить. Ну там ещё есть запрос UP. Можно почитать, как реализовано уже в репах. При этом почему веб на пикси? Мультитач работает нормально, события работают нормально. Только с вёрсткой конечно без css грустно и с рендером текстов там не всё гладко. Но зато быстро. Я изначально пробовал на реакте в чистую написать, но там на айос ниже 15.2 очень мешал баг с "magnifying glass" плюс мультитач там работал странно мягко говоря. Вебгл и пикси в этом плане в разы по приятнее. Хотя тоже пришлось повозиться
Вполне. Ну можно скачать репозиторий да протестировать. В локальной сети - да. Ну в этом решении никак, в кастомных решениях для заказчиков - по-разному. Это сингл плеер упрощённый пример. Может потом допишу, как делается мультиплеер и аутентификация пользователей в подобных системах. А также система очередей. Так как на реальном ивенте может быть проблема, что пользователей коннектится сразу очень много, и там нужно выстраивать очередь игроков. Но в целом всё реализуемо
Наследник Monobehaviour навешиваемый на GO — это и есть компонент в данном контексте. И можно писать в таком стиле, что данные компоненты будут View-Model. Можно писать в другом стиле. Я скорее не понял суть вопроса :) Есть такой стиль архитектуры для проекта. Это не раскрывается, потому что как в юнити пишутся разные архитектурные схемы, почему любой крупный проект это всегда гибрид, и где лучше реактивный подход, а где другой — это не тема статьи :)
Брать джунов и мидлов нужно только затем, что нужны новые сеньоры. Иначе скоро один сеньор будет стоить, как крыло от боинга (хотя я не скажу, что я против) :) В остальном в 99% случаев - это расход ресурсов и денег :) Сеньоры делают быстрее всё. И рутину, и сложные задачи. Что рутину часто впадлу делать - это другой вопрос. Но когда ты задачу решал 150 раз, то в 151 ты делаешь её примерно за минуту. Сеньорам есть что обсудить на ревью, и часто сеньорам лень менять компанию, так как денег платят везде на определённом уровне в тех же корпах +- одинаково. И если ты уже "устал от приключений", ты просто работаешь на проекте и не паришься. Чаще всего мотивацией смены работы я видел скуку, а не вопрос деньгах. Лидами вообще многие становится в принципе не хотят.
В большинстве своём сеньоры - это такие бывалые, уставшие профессионалы, которым плевать что делать, так как они умеют очень многое и на контекст задачи смотрят, как на предметную область. Бывает кто-то ещё горит работой, но за 6 лет+ ты начинаешь к программированию (коммерческому) относится филосовски. Пилишь какой-то пет проектик, если тебе не надоело программировать, так как там никто не меняет бизнес требования, не переобувается на лету, не нужно думать о коммерческих рисках использования той или иной технологии. А коммерция вся +- одна и та же, меняется по моему опыту разве что контекст. Поэтому нет смысла менять особо компанию, так как поменяешь в большинстве случаев одно на другое, если не подвернётся действительно супер интересный проект :)
Ну с компьютами в рядах случаев удобнее работать именно в графе. Но тут есть несколько нюансов. Я очень долго был старовером не пользующимся нодовыми редакторами, но сейчас я возможностью делать кастом ноды я больше склоняюсь к ним. И тут есть свои плюсы и минусы в одном флаконе
1. Высокий уровень абстракции может оптимизироваться автоматически
Шейдеры написанные на glsl и hlsl нельзя оптимизировать компилятором, так как это довольно чёткие инструкции о том, что надо сделать. А вот графы проще оптимизировать, проще подсовывать им реализации под VR с сингл пасс стерео рендером, так как это условно "логическое описание, а не чёткая инструкция". Но как обратная сторона любой абстракции высокого уровня, её нельзя тонко настраивать и зная юнитеков, если там будут баги - это может стать проблемой
2. Дебаг шейдеров
Чуть быстрее процесс редактирования, чуть проще организовать пере использование, но при этом ещё каждый шаг может иметь визуальный вывод, что оно делает. И вот последним шейдерный код не обладает. Типа нужно удалять куски, писать какие-то утилиты, чтобы иметь пошаговый вывод, чтобы проще было дебагать шейдер
В общем кодом я так же шейдеры пишу, но сейчас я пишу и так, и так. Просто если не требуется прям до спичек оптимизировать - графы норм. Если нужно сначала за прототипировать, описать сам эффект, глянуть его, а потом уже переписать нормально - граф в среднем будет быстрее с точки зрения "попробовать разное". А когда сам шейдер идейно готов, уже можно написать оптимально, если вдруг тормозит.
Мне кажется более стандартное решение в виде BSP-дерева было бы лучше, и было бы интересно посмотреть сравнение результатов R*-дерева с ним
Пил пол года XD А так хз, я просто что называется "на своём месте". Выгорание у меня обычно связано со стрессом бизнеса, а не с работой. Кассовые разрывы (я терпеть не могу кому-то задерживать выплаты, но деньги из воздуха тоже пока не умею делать) и тому подобное, иногда груз ответственности
А сидеть и чё-то делать по работе я могу просто сутками и по сути не уставать. Так как это интересно)
Я скажу так. Да, название немного кликбейтное. Но по студии в чём история.
3 года она зарабатывала, не скажу что много, но на зарплаты и т.п. хватало и себе тоже. Потом я сделал ставку на конгрессно-выставочную индустрию в начале 2019 года. И тут пандемия грянула. В целом и это можно было пережить. Но я тогда уже выгорел быть постоянно в стрессе и ритме вечной работы. Выплатил всем сотрудникам доп. оклад, распустил команду, и ушёл на пол года в консалт. Так как на данный момент я один из людей разбирающихся в технологиях трекинга. Не единственный, но таких немного на вольных хлебах. От OpenCV до Vicon и Optitrack. Я перечитал очень много статей научных, делал прототипов и в целом работал с этой группой технологий последние 6 лет + учился всякому у трекинг инженеров вайкона.
Согласен. Тут важно только не столько "что значит техдир", а в том числе в какой индустрии. Я работаю В AR/VR и интерактивных визуализациях. Поэтому по моей терминологии техдир в данной индустрии, это человек который может:
1. Составить роадмап разработки продукта в данной области
2. Составить технологический стек и его обоснование, причём коммерческое
3. Составить смету на роадмап (хотя бы на пол года), понимать какой нужен штат для реализации проекта с технической точки зрения
4. Составить техническую схему решения. С оборудованием и прочими прелестями жизни. Зная какая железка лучше и почему
5. Иметь опыт реализации подобного класса проектов
И да техдир - это больше менеджер, чем технарь. Я разбираюсь в Unity, в .Net, в нюансах процессоров (кешлайн сплит, выравнивание памяти) в основном по мануалам интела, компьютерной графике (можно почитать мои статьи и мой блог), математике (когда-то давно я занимался математическим моделированием), технологиях трекинга и так далее. И в некоторых вещах я разбираюсь достаточно глубоко, так как считаю, что фундаментальные знания важнее практических. И типа по графике вот пример поста, где я по-русски пытался объяснить низкоуровневый нюанс работы гпу в паре с шиной https://t.me/dyadichenkoga/206 И докер разверну, и шел скрипт напишу. Ещё я очень поверхностно знаю реакт, питон. И прям чуть-чуть плюсы. Читать и портировать смогу, писать на нём - очень сложно и это делают какие-то ниндзя. Я конечно помню смарт поинтеры и частично 11 стандарт, но как писать быстрый код на плюсах я не знаю. Чистая архитектура, солид и т.п. У меня в целом в блоге есть разбор паттернов в контексте Unity. TCP/IP, RSTP, WebRTC и т.п. С этим всем я тоже работал, писал кастомные протоколы стриминга и много чего ещё. Но просто это в плане техдирства, особенно глубокие задачи решать, не так важно. Так как это будут делать сеньоры, которые разбираются лучше.
И вот тут может показаться уже, что я хвастаюсь. Но я также могу хвастаться числом статей, выступлениями, то что я организовывал мероприятия на 200+ человек для разработчиков, да хоть репозиториями со звёздочками (хотя там вообще ничего великого, по-моему мнению) И вот это на мой взгляд будет странно. А в статье я просто рассказал, какой путь на данный момент прошёл.
И всё это небольшая индустрия. Я конечно же не говорю, что "да ща я техдиром Яндекса стану". Но отличие техдира от техлида в том, что он знает широкий спектр технологий и может построить команду и довести её до финала в сложном интеграционном проекте. С беком, фронтом и сложными технологиями. А не в рамках узкого стека технологий. Так как техлиды часто разбираются в своём стеке (хотя тоже бывают разные) Поэтому я ушёл в "продюсирование проектов на заказ" с подбором команды под проект, и работаю сам по себе.
Просто безусловно существуют разные масштабы команд, компаний и т.п. Я ща на вольных хлебах и консультирую часть компаний и стартапов. Просто писал я немного не о том.
Выше есть комент про L7+ FAANG, и с ним я согласен за исключением одного нюанса. Это всё оптимальная стратегия, когда ты хотя бы номинально сеньор. Я же писал скорее про путь джун-сеньор. С позиции сеньора варианты развития в разы разнообразнее, сложнее и интереснее. А проходить так участок пути джун-сеньор - оптимальнее.
Любой работодатель знает, что хай левел сотрудник начинает приносить прибыль минимум через полгода. С моим зарплатным запросом если я уйду после испытательного, я просто потрачу деньги компании. В чём я не вижу смысла, а уходить на испытательном, если мне не подходит работа — нормальная практика.
Это та позиция, которую мне предлагают. В студии я отвечал не только за техническую часть, но это особо значения не имеет) В студии — это была моя компания)
Скучно не технически, а по спектру обязанностей. А на сеньора мне нет идти смысла из-за текущего дохода даже в теории. И свои обязательства перед заказчиками я соблюдаю вне зависимости от интереса. Вы считали какой-то не тот посыл :)
Я не пойду на работу, так как мне не особо это интересно, а не то, что я технически узнал всё что можно было.
Я просто трудоголик. У меня был свой митап Unity Moscow Meetup и CGDevs, я основатель http://gamedev-calendar.ru/, 28 статей на хабре, пара выступлений (как пример https://www.youtube.com/watch?v=GUhs-emib_8 ) и много чего ещё. А так я просто рано начал работать, по сути 8 лет назад. И с тех пор работаю сутками. Плюс везло очень много, особенно с теми, кто мне по ходу что-то объяснял :)
Ну сводно всю инфу я тут собрал https://noxatra.ru/ чё я делал за последние годы. А так, работа и везение. Ну и маховик времени конечно же :)
Дак я прогорел в своё время. У меня была своя студия, которую я закрыл не от хорошей жизни) Был неопытный, совершил много ошибок, но добила меня пандемия. Так что согласен, но просто я наверное опустил ряд деталей про которые можно рассказать. Закрывал я студию, не как успешный кейс с чемоданом денег, а с минусом в несколько миллионов рублей. И этот минус я разгребал ещё пару лет.
Тут может показаться, что это история успеха, так как я в целом всегда на позитиве. Но на самом деле — это просто история на данный момент, и всё ещё впереди :) И деятельность моя текущая не всем подойдёт, она тоже имеет свои скажем так особенности. Но карьерные советы рабочие, так как просто я понимаю с разных точек зрения как сейчас устроен рынок найма.
У меня ща конечно всё норм, есть свой продукт небольшой и куча всяких дел. Но так как я уже разорялся, я знаю что и сейчас хожу "по ох***но тонкому льду" и что всегда нужно держать руку на пульсе. Но в любом случае спасибо, всегда интересно послушать мнение со стороны :)
Да мне кармы не жалко) Главное, чтобы статья была полезна тем, кому будет полезна. А в остальном. Минусов бояться — на хабр не писать :)
Плюсы за другие статьи думаю сохранят её положительной :)
https://github.com/Nox7atra/UnitySimpleHttpServer
Дак этож копипаста) Порядок 65353 или 65535 не так сильно бросается в глаза :) Я просто не увидел)
В статье просто небольшая опечатка. Сейчас поправлю 65535 конечно же. Откуда? Достаточно посмотреть структуру пакета TCP. И порт там занимает 16 бит. 2^16-1 = 65535. Но всё ещё не понимаю реакцию, так как это явно опечатка
Ну я даже немного распространю. Плохое соединение на выставках - это скорее не перегружен траффик, а радиошум. Так как много железа, телефонов и другого оборудования. Можно решить 100% - дорогим оборудованием, но с обычным тут могут быть риски задержек. Причём весьма высоких. Но эту проблему можно решить только шнуром. Потому что там и персистент коннект не спасёт, так как оборудование банально пингуется долго. Поэтому обычно когда такая штука разворачивается, ставятся специфичные условия. Хотя бы приличный роутер :)
Но геймпад это один пример применения вшитого http сервера. Есть геймплеи где задержка нажатия в 1 секунду не играет вообще никакой роли. Иногда нужно администрировать Unity приложения, которые вообще не игры. И удобнее это делать с планшетов. Но при этом с точки зрения апдейта и деплоя в разы проще просто обновлять контейнер на сервере в котором и веб лежит.
Да вы правы. Это можно немного решить, если поддержать Keep-Alive, но в общем да. Тут скорее "нет смысла в контексте рассматриваемых условий". А я рассматриваю условия "хорошие". В среднем сейчас слабый сервер, как контекст, скорее редкость, а вот плохое соединение может сыграть роль
Вот тут неплохо зарисована структура TCP пакета. https://webhamster.ru/mytetrashare/index/mtb0/1501768410v2kmovcru6#:~:text=Структура пакета TCP (формат заголовка сегмента)&text=Эти 16-битные поля содержат,клиенту на основании этого номера. Собственно там есть порт. А на уровне уже транспорта в модели OSI это всё резолвится, то есть на уровне протокола. Но в моём тезисе нет ничего неправильного. Так как HTTP это у нас пока настройка над TCP и там это собственно так и работает. Так что не совсем понял вопрос
Просто в статье не вижу смысла углубляться в детали структуры пакетов и того, как работает весь стек TCP/IP. Во-первых, по этой теме есть целые книги. Во-вторых, это не является топиком статьи. А так в модели OSI на транспортном уровне всё это описано. Можно почитать специализированную литературу по этой теме, если вдруг интересно
А что это по вашему? Это неотрицательное число от 0 до 65353 записываемое в заголовках в транспортной модели OSI. То есть просто условное число в заголовке пакета
А ну да по работе. Ага. Ну считай
Если у нас порт стоит 10021 на серваке. Если в термины веба переводить. Ну там ещё есть запрос UP. Можно почитать, как реализовано уже в репах. При этом почему веб на пикси? Мультитач работает нормально, события работают нормально. Только с вёрсткой конечно без css грустно и с рендером текстов там не всё гладко. Но зато быстро. Я изначально пробовал на реакте в чистую написать, но там на айос ниже 15.2 очень мешал баг с "magnifying glass" плюс мультитач там работал странно мягко говоря. Вебгл и пикси в этом плане в разы по приятнее. Хотя тоже пришлось повозиться
Вполне. Ну можно скачать репозиторий да протестировать. В локальной сети - да. Ну в этом решении никак, в кастомных решениях для заказчиков - по-разному. Это сингл плеер упрощённый пример. Может потом допишу, как делается мультиплеер и аутентификация пользователей в подобных системах. А также система очередей. Так как на реальном ивенте может быть проблема, что пользователей коннектится сразу очень много, и там нужно выстраивать очередь игроков. Но в целом всё реализуемо