Кажется, теперь становится понятным, как мы будем терять работу. конкретно игры будут генерироваться.

GameNGen — первый игровой движок, который сгенерировал игру, и, конечно же, это Doom.

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

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

Считывать инпут с периферийных устройств явно не будет проблемой, т.е. вы всё так же сможете крутить мышкой и кликать по клавиатуре, а в перспективе и просто думать, что идёте, и чип поможет двигать вашего аватара в игре.

Doom рано или поздно запустят на человеческих мозгах. Только лет 30 надо подождать.
@cgit_vines

Value Proposition Builder или из чего складывается и на чём стоит ценностное предложение продукта

🧱 ПРОБЛЕМА И ЕЁ РЕШЕНИЕ

Глубокое понимание проблемы должно включать не только полное понимание её текущего решения(ий), но и понимание всех ПРЕДЫДУЩИХ решений, которые когда-либо во времени были опробованы людьми для решения такой проблемы.

🧱 ЦЕННОСТНОЕ ПРЕДЛОЖЕНИЕ

Ценностное предложение это НЕ функция, которую вы создаёте в продукте (функция есть решение), а его Суть или Обещание, которое вы даёте пользователям и которое доносите с помощью фунции(ий).

🧱 СТРАТЕГИЧЕСКОЕ ОТЛИЧИЕ

Стратегическое отличие сосредоточено на описании того, какими уникальными возможностями будет обладать ваше предложение и построенное на нём решение и какие преимущества оно будет использовать для того, чтобы сделать его безупречным.

По теме:

– 5 видов пользовательского опыта
– Business Model Canvas (Остервальд)

4 неочевидных ошибки при разработке и внедрении фич

№1. Игнорирование индивидуальности функций

Не все фичи одинаковы (полезны)– каждая функция имеет собственные уникальные механики, которые необходимо учитывать не только для её разработки, но и ДЛЯ будущего позиционирования, вывода и доставки этой функции до пользователей (рынка).

№2. Неправильная упаковка функций

Функции также бывают разных форм и размеров.

Такие факторы, как частота использования, масштаб решаемой проблемы, «ценность» фичи в глазах клиента, стоимость эксплуатации и т. д. – всё это влияет на установление приоритета, доступов и цен на функции.

– Советы по ценообразованию фич

Особенно актуально, когда функция реализована как автономное масштабируемое дополнение к основному продукту.

– Делаем фичу или суб-продукт?

№3. Несбалансированное развёртывание функций

Вытекает из предыдущих – даже 1 фичу не нужно запускать сразу для всех пользователей.

Поэтапное внедрение фичи по гео/когортам/тирам даёт продуктовым командам самое главное – время и свободу для сбора аналитики, багов, отзывов, тестов и их анализу.

№4. Рассхинхрон фич с сапортами/продажниками/маркетингом

Задержка в обновлении и доставке фич и инфы о продукте/фичах до юзеров и менеджеров – классика многих продуктов, которая снижает конверсии:

а) новой фичи, с которой не сможет разобраться юзер;

б) время до закрытия тикета/лида менеджером (читай – его KPI-зарплату-мотивацию-выгорание-эффективность).

Другая классика – когда сейлзы/маркетинг продают фичи "как они лучше продаются", а не такими, какими фичи является в реальности.

Задача продуктовой команды – систематически проверять и сверять фичи на актуальность целей, затрат, выгод и формулировок, которые дают пользователям ваши маркетологи, сапорт и... сами фичи (продукт).