По набору фичей для первого курса неплохой результат. Правда в реальной разработке совсем другие проблемы — миддлвара затачивается под реальные задачи использующих её приложений, и это сильно меняет процесс постановки и решения задач.
Как мне кажется, сейчас вы просто смотрите на чужие движки и делаете себе такое же. Но в коммерческой разработке такой подход будет только мешать. Я думаю, что движок эффективнее делать под конкретную игру — тогда вы получите более релевантный опыт. Так-то на рынке много программистов, умеющих реализовать сферический движок в вакууме. Но обычно эти решения не позволяют получить прибыли при использовании на реальных проектах, призванных приносить деньги. А вот программистов, оптимизирующих движки под нужды целевого проекта, — мало, они более эффективны и высоко ценятся работодателями.
В целом графика в демке смотрится интересно. Только транспорт выглядит каким-то игрушечным пластмассовым. Особенно непрозрачные стекла автомобилей усиливают такое ощущение.
Blitz — это нишевый движок, поэтому подойдёт только для небольшого спектра проектов. Среди движков общего назначения с развитой экосистемой и коммьюнити у нас так и останутся U и UE.
Судя по Вашей логике, нам стоит ждать новый язык программирования от Сбербанка или Газпрома) Но этого не будет. Это не их тема, они не смогут в это грамотно инвестировать.
Так-то даже новый язык программирования или даже ОС можно сделать силами небольшой команды. Не то что нишевый движок. Тут вопрос в первую очередь не в финансировании или численности команды, а в её квалификации и мотивации.
Что касается самоокупаемости… А почему Вы решили, что для данного стартапа это цель? Скажу по секрету, что игры — это вообще одна из худших сфер для самоокупаемости. По крайней мере из тех, в которых я работал.
Если вопрос только в маркетинговой целесообразности шутера на мобилах, то PUBG Mobile — это ответ. К управлению привыкаешь, неудобства компенсируются другими факторами. Например, можно поиграть по сети с друзьями, у которых из девайсов ничего кроме телефона отродясь не было.
U/UE в умелых руках позволяют сделать достаточно качественный с технологической точки зрения продукт. И я думаю, что команда Blitz смогла бы это сделать при желании. Тут вопрос в том, что прошло более 10 лет с тех пор, как была заложена базовая архитектура U/UE и с тех пор на этом уровне мало что поменялось. Плюс в то время основной упор был на десктопы и консоли. Мобильные девайсы и веб появились как внезапный довесок) Соответственно, видя современные расклады по 3Д для шутеров на мобилах, можно замутить на уровне движка что-то более интересное с точки зрения фичей и утилизации ресурсов железа. Главное — чтобы команда по подготовке игровых ресурсов оптимально использовала все особенности движка. Иначе может и хуже U/UE получиться.
Как человек, переходивший во времена расцвета Unity с C++ на C#, я могу сказать, что после плюсов для переезда на шарп хватает 1 дня. Тут вопрос образа жизни. Это как с Oracle перейти в Excel, как пересесть с Ferrari на Hyundai. То есть с коммерческой точки зрения это выгоднее, но не круто, совсем не круто… Стоит ли уходить со стабильной работы, чтобы создавать собственный проект на компромиссах и технологиях аля-1С?
Вобщем, я думаю тут будет рассказ не про продукт, а про образ жизни. И это интересно)
На мой взгляд концепция тут самая обычная для рядовой ОС. Есть какое-то количество интересных фичей, например, децентрализация, но это не является каким-то прорывом за рамки. Это попытка логически развить идеи построения обычных ОС как софта, базовые потребности в котором уже удовлетворены. Усилия, которые требуются для перехода на подобную программную платформу, не сопоставимы с итоговыми скромными выгодами. Поэтому и наблюдается Latest release 4th Edition / March 28, 2015.
Для успеха нужно создать то, на что легко перейти, и что даст такие большие выгоды, которые легко мотивируют на этот переход. Я думаю, тут в первую очередь стоит вопрос не технологий, а идеи и видения.
Ядро MS-DOS было написано за 6 недель одним человеком, остальные 46 недель оно переживало разнообразные маркетинговые приключения. Ядро Линукса было доведено до версии 1.0 тоже по сути одним человеком чуть более, чем за 2 года. Поэтому в контексте данных проектов 1-2 года — это и есть 1-2 человекогода.
Ну и плюс авторы QP ОС написали, что первое ядро скомпилили в 2005 году. Поэтому если даже это делали 2 человека, они скоро перевалят за 30 человеколет.
Фантом умер по причине отсутствия достаточного числа активных пользователей. И любая ОС, которая решит выкинуть легаси-пласт прикладного софта, встретится с той же проблемой. На уровне ОС эта проблема не решается, она решается на более высоком уровне абстракции.
Я рассуждаю об абстрактной фундаментальной разработке, как я бы стал её делать. И что в итоге это была бы не ОС как мы её привыкли видеть. А у QP ОС своя атмосфера, я лезть туда со своими советами не собираюсь.
Забавно, что больше всего обсуждений возникло вокруг таймеров.
Я у себя этот вопрос решаю просто. У каждого сотрудника есть определённый ежемесячный доход, который ему нужен для жизни. Это может быть фиксированная сумма, а может быть что-то плавающее. Но в любом случае оно плавает в определённых пределах. Соответственно, можно получить стоимость каждого часа содержания сотрудника — не важно, работает он, спит или играет в покемонов. Например, при ставке 100 тр/месяц стоимость каждого часа будет 100 000 р /(30 * 24 часа) ≈ 140 р/час. Таймер для сотрудников включен всегда — и ночью, и на выходных, и на праздниках.
Я могу за любой промежуток времени посмотреть что сотрудник сделал полезного и сколько компания на это потратила денег. Если виден профит для компании, то мне не важно сколько из этих часов было отработано, а сколько было потрачено на сон и покемонов. А если профита не видно, то надо или что-то менять, или прощаться друг с другом.
Непосредственный подсчёт отработанного времени хорош только с точки зрения психологии — по нему легче отчитываться перед заказчиком. Так исторически сложилось, что это — привычная для всех схема. Но насколько она эффективна для PMа в качестве инструмента контроля? Лично мне она только мешает, потому что, как уже многие заметили в других комментариях, трудно замерить какое время было рабочим, а какое — нет. Ещё более трудно понять где границы задачи и сколько времени в итоге займёт её решение. И все эти трудности приходится решать PMу в ущерб реальным полезным для проекта задачам.
Ситуация вполне реальная, но мне кажется, что в повседневной работе devhub'а она обычно не встречается. Платформа и специфика заказов таковы, что можно получать ощутимые результаты для проекта за считанные часы.
По-моему, всё происходящее очень хорошо укладывается в привычную картину мира разработки отечественных ОС. Берётся популярная концепция из прошлого века (POSIX ил WINDOWS) и начинается попытка сделать из неё что-то современное путём изменения несущественных элементов и деталей реализации. Я считаю, что нужно начинать со смены концепции. Иначе у вас получится тот же самый динозавр, что и у Microsoft, только очень-очень мелкий и беззубый.
Далее, делать локальную "только российскую" информационную систему нет ни смысла, ни возможности. Современные информационные системы живут в условиях глобализации, они развиваются международным сообществом. Повторить что-то подобное по функциональности силами одной страны невозможно. Например, если бы Торвальдс принципиально делал Линукс только силами финнов и только для нужд Финляндии, все мы прекрасно понимаем чем бы дело кончилось.
Ну и, наконец, я считаю, что время для разработки новых ОС кончилось. Ни одна новая разработка в этой области не даст ничего существенного по сравнению с имеющимися успешными решениями (Windows, Linux, MaxOS, Android, iOS и тп.). Нужно выходить на новый уровень абстракции и реализовать концепцию, которая превосходит тесные рамки ОС, но при этом содержит ОС как составную часть себя. Очень важно, что реализация первой жизнеспособной версии такой концепции должна укладываться в те же сроки, в которые были сделаны MS-DOS 1.0 и Linux 1.0. То есть в 1-2 года. Если где-то даже теоретически начали виднеться "десятки человеколет" до момента первой реальной интеграции, это провал и дальше лучше не продолжать.
Да, Вангеры — это явление в игровом мире. Российская игра, за которую не стыдно. Даже более того — гордость берёт) Тоже купил в Стиме. Более того, поставил ради этого сам Стим)
Насколько я знаю работа по созданию такого языка ведётся: https://metalanguage.tech/
По набору фичей для первого курса неплохой результат. Правда в реальной разработке совсем другие проблемы — миддлвара затачивается под реальные задачи использующих её приложений, и это сильно меняет процесс постановки и решения задач.
Как мне кажется, сейчас вы просто смотрите на чужие движки и делаете себе такое же. Но в коммерческой разработке такой подход будет только мешать. Я думаю, что движок эффективнее делать под конкретную игру — тогда вы получите более релевантный опыт. Так-то на рынке много программистов, умеющих реализовать сферический движок в вакууме. Но обычно эти решения не позволяют получить прибыли при использовании на реальных проектах, призванных приносить деньги. А вот программистов, оптимизирующих движки под нужды целевого проекта, — мало, они более эффективны и высоко ценятся работодателями.
В целом графика в демке смотрится интересно. Только транспорт выглядит каким-то игрушечным пластмассовым. Особенно непрозрачные стекла автомобилей усиливают такое ощущение.
Blitz — это нишевый движок, поэтому подойдёт только для небольшого спектра проектов. Среди движков общего назначения с развитой экосистемой и коммьюнити у нас так и останутся U и UE.
Судя по Вашей логике, нам стоит ждать новый язык программирования от Сбербанка или Газпрома) Но этого не будет. Это не их тема, они не смогут в это грамотно инвестировать.
Так-то даже новый язык программирования или даже ОС можно сделать силами небольшой команды. Не то что нишевый движок. Тут вопрос в первую очередь не в финансировании или численности команды, а в её квалификации и мотивации.
Что касается самоокупаемости… А почему Вы решили, что для данного стартапа это цель? Скажу по секрету, что игры — это вообще одна из худших сфер для самоокупаемости. По крайней мере из тех, в которых я работал.
Если вопрос только в маркетинговой целесообразности шутера на мобилах, то PUBG Mobile — это ответ. К управлению привыкаешь, неудобства компенсируются другими факторами. Например, можно поиграть по сети с друзьями, у которых из девайсов ничего кроме телефона отродясь не было.
U/UE в умелых руках позволяют сделать достаточно качественный с технологической точки зрения продукт. И я думаю, что команда Blitz смогла бы это сделать при желании. Тут вопрос в том, что прошло более 10 лет с тех пор, как была заложена базовая архитектура U/UE и с тех пор на этом уровне мало что поменялось. Плюс в то время основной упор был на десктопы и консоли. Мобильные девайсы и веб появились как внезапный довесок) Соответственно, видя современные расклады по 3Д для шутеров на мобилах, можно замутить на уровне движка что-то более интересное с точки зрения фичей и утилизации ресурсов железа. Главное — чтобы команда по подготовке игровых ресурсов оптимально использовала все особенности движка. Иначе может и хуже U/UE получиться.
Как человек, переходивший во времена расцвета Unity с C++ на C#, я могу сказать, что после плюсов для переезда на шарп хватает 1 дня. Тут вопрос образа жизни. Это как с Oracle перейти в Excel, как пересесть с Ferrari на Hyundai. То есть с коммерческой точки зрения это выгоднее, но не круто, совсем не круто… Стоит ли уходить со стабильной работы, чтобы создавать собственный проект на компромиссах и технологиях аля-1С?
Вобщем, я думаю тут будет рассказ не про продукт, а про образ жизни. И это интересно)
Raspberry Pi 4 купить из России на официальном сайте нельзя — пишут нет реселлера в вашей стране. Куда ещё податься страждущим?
К сожалению, это всё проприетарщина, поэтому публичных материалов нет.
Для успеха нужно создать то, на что легко перейти, и что даст такие большие выгоды, которые легко мотивируют на этот переход. Я думаю, тут в первую очередь стоит вопрос не технологий, а идеи и видения.
Ну и плюс авторы QP ОС написали, что первое ядро скомпилили в 2005 году. Поэтому если даже это делали 2 человека, они скоро перевалят за 30 человеколет.
Я у себя этот вопрос решаю просто. У каждого сотрудника есть определённый ежемесячный доход, который ему нужен для жизни. Это может быть фиксированная сумма, а может быть что-то плавающее. Но в любом случае оно плавает в определённых пределах. Соответственно, можно получить стоимость каждого часа содержания сотрудника — не важно, работает он, спит или играет в покемонов. Например, при ставке 100 тр/месяц стоимость каждого часа будет 100 000 р /(30 * 24 часа) ≈ 140 р/час. Таймер для сотрудников включен всегда — и ночью, и на выходных, и на праздниках.
Я могу за любой промежуток времени посмотреть что сотрудник сделал полезного и сколько компания на это потратила денег. Если виден профит для компании, то мне не важно сколько из этих часов было отработано, а сколько было потрачено на сон и покемонов. А если профита не видно, то надо или что-то менять, или прощаться друг с другом.
Непосредственный подсчёт отработанного времени хорош только с точки зрения психологии — по нему легче отчитываться перед заказчиком. Так исторически сложилось, что это — привычная для всех схема. Но насколько она эффективна для PMа в качестве инструмента контроля? Лично мне она только мешает, потому что, как уже многие заметили в других комментариях, трудно замерить какое время было рабочим, а какое — нет. Ещё более трудно понять где границы задачи и сколько времени в итоге займёт её решение. И все эти трудности приходится решать PMу в ущерб реальным полезным для проекта задачам.
Ситуация вполне реальная, но мне кажется, что в повседневной работе devhub'а она обычно не встречается. Платформа и специфика заказов таковы, что можно получать ощутимые результаты для проекта за считанные часы.
По-моему, всё происходящее очень хорошо укладывается в привычную картину мира разработки отечественных ОС. Берётся популярная концепция из прошлого века (POSIX ил WINDOWS) и начинается попытка сделать из неё что-то современное путём изменения несущественных элементов и деталей реализации. Я считаю, что нужно начинать со смены концепции. Иначе у вас получится тот же самый динозавр, что и у Microsoft, только очень-очень мелкий и беззубый.
Далее, делать локальную "только российскую" информационную систему нет ни смысла, ни возможности. Современные информационные системы живут в условиях глобализации, они развиваются международным сообществом. Повторить что-то подобное по функциональности силами одной страны невозможно. Например, если бы Торвальдс принципиально делал Линукс только силами финнов и только для нужд Финляндии, все мы прекрасно понимаем чем бы дело кончилось.
Ну и, наконец, я считаю, что время для разработки новых ОС кончилось. Ни одна новая разработка в этой области не даст ничего существенного по сравнению с имеющимися успешными решениями (Windows, Linux, MaxOS, Android, iOS и тп.). Нужно выходить на новый уровень абстракции и реализовать концепцию, которая превосходит тесные рамки ОС, но при этом содержит ОС как составную часть себя. Очень важно, что реализация первой жизнеспособной версии такой концепции должна укладываться в те же сроки, в которые были сделаны MS-DOS 1.0 и Linux 1.0. То есть в 1-2 года. Если где-то даже теоретически начали виднеться "десятки человеколет" до момента первой реальной интеграции, это провал и дальше лучше не продолжать.
Да, Вангеры — это явление в игровом мире. Российская игра, за которую не стыдно. Даже более того — гордость берёт) Тоже купил в Стиме. Более того, поставил ради этого сам Стим)
Как вариант — отправиться на обучение к тому, кто уже успешно создавал такие команды. И на практике в контексте реальной задачи всё освоить.