Gamedev backend/client dev
Лайфхак который делают артдиректоры - в Фотошопе фильтрами убирают цвет, оставляют ЧБ контрастность. Дальше весь кликабельный арт(персонажи, точки интереса..) должны быть контрастнее чем фоны. В идеале 2 группы контрастности, чтобы разные персонажи были в группе высокой контрастности, а разные фоны в группе низкой. По идее перерисовывать ничего не недо, просто подкрутить
Такой рынок, без транзакций компании закрываются пачками.
Ты уже 200 раз в комментариях написал что тебе тяжело 👍 на это сил хватило
Много у кого проблемы, но ты себя при жизни похоронил. Хотя бы 2 часа в день что-то новое учи, может понравится и найдешь себе дело по жизни. Твое занятие уже позавчерашний день. Сегодня ИИ все что ты делаешь сейчас - сделает лучше и быстрее, а завтра что будет?
Тут вообще много чего нет, это учебный проект / каркас для экспериментов для тех кому интересна тема, но не знают с чего начать. Если есть конкретные вопросы я готов подсказать.
Привет, он закончен
Ios так же использует тысячи open source компонентов. Сегодня что бы ты ни делал, с нуля не получится, а только на основе чего-то
Подставь вместо мобильного геймдева свою индустрию и подумай ещё раз хорошо если ты без работы будешь или плохо.
Ещё раньше ui делали в другом потоке, во времена, когда его через flash делали. В общем я за то, чтобы инструменты позволяли писать однопоточный код и прятали все сложности, всех не научишь тонкостям блокировок
В разных играх в разное упирается, мне кажется всегда большинство игр будет в 1 потоке. Хорошо когда движок в другой поток умеет анимации выводить, а бизнес логику в шутане параллелить сложно и мало пользы
Игру заруинить может 1 ричиттело, а платить будут те, кого не спрашивают что делать. Никто не пойдет работать под таким контрактом
Помню как Яндекс слили 50 тысяч строк базы из доставки еды, где было что и кто заказывал и где живёт. Наказали штрафом 60к₽. А ещё у них был 100% слив всех исходников всех проектов Яндекса. После такого угроза последующих взломов повышается
Оптимизации дальнейшие тянут на статью) Этот учебный, поэтому упрощён. На работе рабочие, но про них я не могу рассказывать. Синкаю потоки давно, поэтому уже не весело, а просто работа.
Конечно если вы не используете unity headless build, там вряд-ли даже 500 получится, там тоже все в 1 поток упрётся
В плане производительности всё сильно зависит от оптимизаций. Тот же asp.net c# обгоняет любые go web framework. в топе самых производительных веб фреймворков по всем языкам. О node.js - он однопоточный и никогда c# не догонит( его потоко-процессы слишком много накладных расходов несут). Всё зависит от железа, если у вас тысячи на go, то и на c# можно сделать тысячи
Так же очень важно как именно сделан переход между серверами, если это бесшовно и незаметно для игрока, то и 500 хватит за глаза
Да, это учебная программа, в реальной было бы больше оптимизаций и техник, но на реальных учить сложнее и делать их значительно дольше. Тем не менее 500 это больше чем сессионка или батл рояль)
Если геймдизайнер /левелдизайнер перестали играть это печально и сказывается негативно на качестве продукта
По своим коллегам - все приходят в геймдев из любви к играм. С годами разработки половина перестаёт в них играть. Представь что ты 6 лет играешь дьяблу каждый день - для них это не игра уже, а просто продукт
В текущей реализации около 100, т.к. упирается в лимит 1400 байт на сообщение со слепком мира. Это можно улучшить заменив 1 глобальный слепок на локальные для каждого игрока. Во втором варианте в одной из игр на i7 8700k держал 500 онлайна. Дальнейшее масштабирование лучше делать горизонтально
Читал про него, когда делал на mirror демку, звучит достойно для своих целей. Сам свои эксперименты на quantum планирую делать
Запускал несколько проектов, где оплачивал работу других людей - их доводил до релиза. Те проекты, где все были на энтузиазме - чаще заканчиваются ничем, даже если мы раньше уже делали игры вместе. Мне кажется на энтузиазме должны быть 1-2 человека, а не 10, тогда всё будет лучше и быстрее делаться. Если говорить о работе, то мне интереснее долгострои амбициозные, где хотя бы год до релиза, т.к. они технически сложнее устроены
Привет, цель была сделать каркас расширяемый, без амбиций релизить в одиночку
Я показал как люди проверяют тестовые, тебе может не нравиться как это происходит. Я считаю лучше знать неприятную правду, чем придумать себе удобную
Уши почисти. Я похвалил автора тестового, что в текстовом файле написал комментарий, что player prefs он использует как упрощение.
Сильно свой стек - это минус, а не плюс. Должны доплачивать за то, что по выходу от них у программиста опыт, который никому не нужен.
Яндекс так делает чтобы задеть самооценку и платить меньше в конце концов. + Отсесть всех, кто просто ищет работу, без желания конкретно в Яндекс попасть. Т.к. 5 собеседований не пройду я или другой кандидат, которому через дорогу после 1 собеса дадут оффер
Через разговор на тему того что программист делал раньше, что умеет, что нравится. Плюс у программиста тоже может быть портфолио с открытым кодом
Даже больше, тестовое должно быть отдельным и не может быть использовано в проекте компании, хотя бы потому что права не переданы. Ни разу не видел чтобы кто-то оплачивал тестовые. Я за то чтобы платили, но не платят :) обычно дают тестовые если нет примеров кода, либо если компания упёрлась рогом в регламенты. Во втором случае предпочитаю искать другую
В общем опыт полезный, не знаю работал ли ты в геймдеве до этого, но с таким опытом ты легко устроишься на ГД в крупную компанию. Там работая в окружении талантливых людей сможешь многому научиться гораздо быстрее чем на своих ошибках. Да и приятно после долгостроя в режиме выживания отдохнуть на 5/2)