Лига Геймеров

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

Не трудно предположить, что российским разработчикам (те, что ещё ими числятся) придётся делать две версии игры: международную и отечественную, без запрещённого контента. Учитывая, что российский рынок несопоставим с зарубежным, запросто может оказаться так, что никакой российской версии игры не появится.

Помимо необходимости авторизации, депутаты предложили новые меры ограничения для детей. Например, глава Комитета Госдумы по защите семьи Нина Останина считает, что:

«Если ребенок слишком надолго завис у монитора, система может напомнить ему об этом всплывающим окном либо же игра будет замедлена. Технологически это реализуемо.»

Что подразумевается под «замедлено», Нина Останина не пояснила. Первое, что приходит на ум — ограничение FPS. И опять-таки, возвращаемся к необходимости выпуска сразу двух версий игр.

А первый зампред думского Комитета по просвещению Яна Лантратова предложила пойти ещё дальше и выдавать играм прокатные удостоверения, как фильмам. Ну и вырезать из них сцены, противоречащие законам.

По словам автора законопроекта Антона Горелкина, цель разрабатываемого документа - не усложнить жизнь игроков и разработчиков, а

«заложить основу для инвестиций и развития отрасли и, конечно, защитить детей от информации, которая для них вредна».

P.S. Ещё у меня есть бессмысленные и беспощадные ТГ-каналы (ну а как без них?):

О науке, творчестве и прочей дичи: https://t.me/deeplabscience

Об играх и игровой индустрии: https://t.me/gameprodev

Мы планировали добавить в игру три магические сферы, временно усиливающие персонажа: увеличение опыта, серебра и количества добываемых предметов. Концепция понятная, механика — полезная. Мы быстро согласовали идею, написали ТЗ и приступили к работе. Но, как часто бывает, дьявол скрылся в мелочах.

Мы не учли все возможные сценарии использования: можно ли активировать орб во время боя или только в городе, как будет работать продление эффекта, где отображать таймер, что делать, если игрок мертв. Кроме того, дополнительные осложнения возникли, когда мы задумались о торговле орбами: потребовался удобный интерфейс и отдельная логика для продажи стаками, в отличии от экипировки, где каждый предмет продавался отдельно.

В результате простая идея «купить, использовать, продать» разрослась в целый пласт дополнительных задач, затронувших механику инвентаря, торговли и взаимодействия с предметами. Каждая упущенная деталь на этапе проектирования значительно усложнила изначальную задачу.

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

Так мы столкнулись с классической проблемой разработки: каждая "мелочь" превратилась в отдельный мини-проект, пожирающий время. Пока одни члены команды пытались освоить новую механику, другие исправляли проблемы в существующих системах.

Когда стало ясно, что мы в тупике, пришлось срочно менять план действий. И тут, сами того не осознавая, мы начали применять принципы Agile-методологии: разбили всю работу на эпики, таски и сабтаски - так стало лучше видно, что происходит с проектом. Выяснилось, что одни задачи являются блокерами для других, и пока они не решены, дальнейшее развитие проекта невозможно.

За каждой задачей мы закрепили ответственного и полностью изменили подход: вместо параллельной работы над множеством направлений решили фокусироваться на одной задаче и доводить её до конца, прежде чем переходить к следующей. Так мы на собственном опыте открыли для себя гибкие методологии разработки, наступив на грабли классического waterfall-подхода.