Есть разное понимание позиции CTO. Удивительно но есть компании, которые считают что CTO, это человек, который должен настроить инфраструктуру, и следить за тем чтобы она работала. Что-то типа мега-админ.
Следующий уровень — это компании, где CTO это понимание CTO как технического менеджера. Обычно представление такое: это человек, который занимается процессами, инфраструктурой, и управлением техническими специалистами. Как правило человек должен быть технически грамотным, и уметь находить язык с технарями.
Есть на мой взгляд третий уровень, это CTO в моем понимании — то есть настоящий CTO. Это технический визионер. Человек который может придумать и сделать технологии, инфраструктуру, технические процессы которые помогут компании добиться технического преимущества на рынке.
Это не просто сотрудник который настроит инфраструктуру, это человек который придумает технологии, которые позволят вашей компании добиться технического превосходства.
Как правило такие CTO, это CTO, которые видят новые идеи, и инновационные подходы, и глубоко погружены в программирование и технологии. Как правило такие CTO это CTO которые пропагандируют культуру того что все сотрудники даже включая CTO пишут код.
Это может звучат невероятно, но CTO крупнейших компаний писали и пишут код собственноручно, чтобы проверить какие-то новаторские идеи. Как правило это новейшие исследовательские разработки и инновационные эксперименты. Опять же в таких компаниях, технические лиды, тоже пишут код. Потому-что это лучшие специалисты, и если они не будут писать код, то код будут писать специалисты ниже уровнем и скиллом.
Приведу несколько примеров:
id Software — легендарный Джон Кармак — писал код, и продолжает его писать.
Epic Games — легендарный Тим Свини — не знаю пишет ли он код сейчас, но части UE4 он еще писал собственноручно.
Facebook — не менее легендарный Mark Zuсkerberg, долгое время даже продолжая рулить компанией огромного маштаба продолжал писать код
Можно привести больше примеров, но я твердо уверен, что если CTO отказался решить алгоритмическую задачку, то это путь в никуда для компании.
Get Started — будет. Не обещаю что скоро :-) но обещаю что будет.
С зависимостями сейчас думаем как это сделать лучше. После перехода на cmake, думаю станет проще.
Выбор технологии это был серьезный вопрос, который поднимался несколько раз в процессе разработки. Подходили к нему тоже достаточно серьезно. Просто не формат статьи детально про это писать, ситуация 3 года назад, это не ситуация сейчас, и конечно сейчас надо смотреть на выбор технологии по новому.
Но если по ситуации на 3 года назад то было вот так:
— 3 года назад, Unity для мобильных был очень сырой. Там фактически не было ничего.
Сейчас конечно надо оценивать заново, однако надо понимать, что когда движок пишется специально под какую-то задачу, он как правило лучше выполняет эту задачу.
— UE3 — не был доступен публично для лицензирования, он появился где-то уже через год нашей разработки. Цена UE3 для приватного лицензирования, была приличная. Так же как и UE4 сегодня, без 5% от gross revenue.
— Ни в одном из этих движков тогда не было нормального UI, а для нашей игры, это было критично.
Сейчас ситуация другая, однако все равно на текущий момент Unity и UE4 обладают рядом недостатков, которые люди решают в своих движках. Есть вполне резонное обоснование.
Инструкции выложим в ближайшее время, сейчас активно переходим на cmake, чтобы стало проще с зависимостями. Сейчас можете пробовать собрать TemplateProject. Для смелых ResourceEditor. Это редактор сцен.
Пока не планируем. Код который не используется, автоматически вырезается на линковке. Если будут желающие сделать казуалочку, им пригодиться.
Раньше поддержка 2D была в 2-х видах, UI и Scene2D. Сейчас активно будем поддерживать UI, Scene2D пока нет необходимости.
Да, постоянно оптимизируем. Большой проект очень для мобильных платформ, количество задач и проблем огромно :-) работаем над всем, по приоритетам. Одна из основных это производительность, и батарея.
Unity, как раз таки тот вариант когда компоненты могут быть полиморфны. Тоже хороший подход, однако, мы пошли дальше. ECS это больше возможностей для производительности на современном железе.
Свой движок это плюс. На некотором железе как выяснилось мы появляемся быстрее Unity. Возможно потому-что Unity уже очень большой, и неповоротливый.
Производительность Unity, это отдельный вопрос. Не исследовал его детально, но из того что слышал, от коллег по цеху, люди сталкиваются с проблемами особенно на Android.
Следующий уровень — это компании, где CTO это понимание CTO как технического менеджера. Обычно представление такое: это человек, который занимается процессами, инфраструктурой, и управлением техническими специалистами. Как правило человек должен быть технически грамотным, и уметь находить язык с технарями.
Есть на мой взгляд третий уровень, это CTO в моем понимании — то есть настоящий CTO. Это технический визионер. Человек который может придумать и сделать технологии, инфраструктуру, технические процессы которые помогут компании добиться технического преимущества на рынке.
Это не просто сотрудник который настроит инфраструктуру, это человек который придумает технологии, которые позволят вашей компании добиться технического превосходства.
Как правило такие CTO, это CTO, которые видят новые идеи, и инновационные подходы, и глубоко погружены в программирование и технологии. Как правило такие CTO это CTO которые пропагандируют культуру того что все сотрудники даже включая CTO пишут код.
Это может звучат невероятно, но CTO крупнейших компаний писали и пишут код собственноручно, чтобы проверить какие-то новаторские идеи. Как правило это новейшие исследовательские разработки и инновационные эксперименты. Опять же в таких компаниях, технические лиды, тоже пишут код. Потому-что это лучшие специалисты, и если они не будут писать код, то код будут писать специалисты ниже уровнем и скиллом.
Приведу несколько примеров:
id Software — легендарный Джон Кармак — писал код, и продолжает его писать.
Epic Games — легендарный Тим Свини — не знаю пишет ли он код сейчас, но части UE4 он еще писал собственноручно.
Facebook — не менее легендарный Mark Zuсkerberg, долгое время даже продолжая рулить компанией огромного маштаба продолжал писать код
Можно привести больше примеров, но я твердо уверен, что если CTO отказался решить алгоритмическую задачку, то это путь в никуда для компании.
twitter.com/TimSweeneyEpic/status/1265451572353552384 — post Tim Sweeney в 2020, CEO гигантской технологической компании продолжает решать алгоритмические задачки.
С зависимостями сейчас думаем как это сделать лучше. После перехода на cmake, думаю станет проще.
Но если по ситуации на 3 года назад то было вот так:
— 3 года назад, Unity для мобильных был очень сырой. Там фактически не было ничего.
Сейчас конечно надо оценивать заново, однако надо понимать, что когда движок пишется специально под какую-то задачу, он как правило лучше выполняет эту задачу.
— UE3 — не был доступен публично для лицензирования, он появился где-то уже через год нашей разработки. Цена UE3 для приватного лицензирования, была приличная. Так же как и UE4 сегодня, без 5% от gross revenue.
— Ни в одном из этих движков тогда не было нормального UI, а для нашей игры, это было критично.
Сейчас ситуация другая, однако все равно на текущий момент Unity и UE4 обладают рядом недостатков, которые люди решают в своих движках. Есть вполне резонное обоснование.
надеюсь что сайт поднимут.
Раньше поддержка 2D была в 2-х видах, UI и Scene2D. Сейчас активно будем поддерживать UI, Scene2D пока нет необходимости.
Свой движок это плюс. На некотором железе как выяснилось мы появляемся быстрее Unity. Возможно потому-что Unity уже очень большой, и неповоротливый.
Производительность Unity, это отдельный вопрос. Не исследовал его детально, но из того что слышал, от коллег по цеху, люди сталкиваются с проблемами особенно на Android.