Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).

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

Данная статья - перевод с английского языка итоговой сводки по написанию требований.

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

Короткое резюме 10 постулатов по улучшению таблиц, опубликованных в Journal of Benefit Cost Analysis экономистом Jon Schwabish.

Проверьте свои финансовые и ежедневные отчеты - каждое ли из 10 правил Вы соблюдаете?

Имеется древняя игрушка LaserAge, которая написана на Flash (на очень древнем Macromedia Flash 4) и работает только под Windows. В детстве она мне очень понравилась, поэтому я решил для души портировать её, чтобы можно было играть с браузера со всех устройств.

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

При уничтожении всех противников на уровне происходит переключение на следующий уровень. Всего 100 уровней.

В терминах игры уровень — волна (Wave), а несколько волн объединены в большой уровень (Level), который представляет из себя просто смену заднего фона, т.е. всего 4 больших уровня в каждом из которых 25 волн. В последней волне большого уровня обычно бывает босс — противник с огромным значением жизни и мощным оружием.

Содержание

• Что такое предварительные шаги тест-кейса
• Правила их составления
  
  • 1. Писать нужно обезличено
  • 2. Писать нужно в едином стиле
  • 3. Можно ссылаться на другие тест-кейсы
  • 4. Но не доходя до маразма
  • 5. Выкидывать текст ради текста нужно
  • 6. Предварительных шагов может и не быть — это нормально
• Итого

Что такое предварительные шаги тест-кейса

Фиксируем требования к результату

• Предметы должны быть похожи на другие подобные предметы из прошлых вторжений;
• Будет 5 типов предметов — кольца, браслеты, броши, подвески и камни;
• У каждого типа предмета будет три степени редкости. Чем более редкий предмет, тем больше силы он дает;
• Степень редкости предмета нужно как-то показать визуально;
• У камней помимо редкости есть 4 цвета — синий, красный, желтый и зеленый;
• Предметы выпадают из бойцов армии вторжения, поэтому должны иметь характерные для этих противников черты и цвета;
• Картинки нужны в формате Tga, размер — 128x128 пикселей.

Первый инструмент: уровни в дизайне

• дизайнера — «непонятно как получить прибавку к зарплате и куда дальше развиваться, на какие курсы ходить?»;
• компании — «как систематизировать развитие дизайнеров в нужном направлении?».

Второй инструмент: оценка навыков

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

В первой части я попытался показать, что черная кошка ООП в темной комнате графических языков существует, даже если это не кошка, а полудохлый кот живодера Шредингера, который то есть, то его нет. Был показан пример реализации методологии объектно-ориентированного программирования, когда программа – это не код на языке С++ или Java, а диаграмма Simulink, SimInTech, SimulationX или SCADE Esterel, — любая графическая нотация описания алгоритма.

В рекламных материалах Мatlab Simulink часто используют термин МОП — Модельно Ориентированное Проектирование (Model-based design). Во многих текстах они подчёркивают, что графическая схема алгоритма это модель, что, конечно, верно. Однако в первоначальном определении МОП, модель – это прежде всего модель объекта, к которому разрабатывают систему управления, включая управляющее программное обеспечение. Подробнее методолгия МОП описана здесь. Таким образом, разрабатывая систему управления по методологии МОП можно и нужно использовать методологию ООП для разработки управляющего ПО. И что бы окончательно закрыть вопрос с моделями, вот вам картинка с отличиями одного от другого. Если все понятно, то можно дальше не читать.