Doom и Super Mario Bros. на момент выхода были технически прорывными. Это как сейчас AAA. И называть их простенькими где геймплей был самым главным не корректно.
Сложность была во преки, а не во благо. В одном случае это было наследие аркадных автоматов - игру можно было пройти условно за 40 минут, но платить 70$ за 40 минут вызывало вопросы, поэтому игру специально переусложняли. В другом случае это баги как Европейская версия Ninja Gaiden или Американская версия Castlevania III.
Музыка из игр это вообще отдельная вселенная. Она может быть прекрасна, но игра ужасная. Для некоторых игр использовали специальные звуковые чипы. Описанный тезис так же применим и к современным играм.
Эмуляторы — от NES до PS1.
Берём шире, от Magnavox Odyssey до PS4
По итогу никаких интересных ретро игр названо не было. Снова doom, quake и wolfenstein. Игры которые можно запустить и без настольного компьютера :-).
Данное утверждение о том, что авторы, команды, компании интерпретируют разработку по разному - заблуждение. Каждому проекту своя методология - это факт. Но база должна быть и особенно это важно для студентов, что бы у них было правильное понимание и восприятие правил игры. То, о чём я писал выше, это не я придумал - это многолетний опыт индустрии под название SWEBOK. Так же существует русский перевод: https://github.com/ligurio/swebok-2004-in-russian
Действительно крутая возможность для студентов! Есть небольшая ремарка по слайду Проектирование -> Разработка -> Тестирование -> Документация.
Блок "Проектирование" не относится к таковому. На этом этапе идёт только анализ, а уже как раз поле него идёт проектирование где на выходе и получается дизайн-документ о котором написано ниже. Изучение материалов не приводит к проектированию. Проектирование это отдельный процесс со своими особенностями.
Ну и финальный блок "Документация" выглядит как добивание студента :-D. Две самые не любимые вещи которые делает программист - это тестирование и документирование. Дизайн документ точно не описывает все нюансы, он даёт направление (в моём понимании) и в ходе реализации функциональности если не прибегать к документации, то в финале будет очень много рутины и проблем. Поэтому этап документирования должен протекать на этапе всей работы начиная от момента одобрения дизайн-документа.
Не согласен с тезисами в самом начале.
Doom и Super Mario Bros. на момент выхода были технически прорывными. Это как сейчас AAA. И называть их простенькими где геймплей был самым главным не корректно.
Сложность была во преки, а не во благо. В одном случае это было наследие аркадных автоматов - игру можно было пройти условно за 40 минут, но платить 70$ за 40 минут вызывало вопросы, поэтому игру специально переусложняли. В другом случае это баги как Европейская версия Ninja Gaiden или Американская версия Castlevania III.
Музыка из игр это вообще отдельная вселенная. Она может быть прекрасна, но игра ужасная. Для некоторых игр использовали специальные звуковые чипы. Описанный тезис так же применим и к современным играм.
Берём шире, от Magnavox Odyssey до PS4
По итогу никаких интересных ретро игр названо не было. Снова doom, quake и wolfenstein. Игры которые можно запустить и без настольного компьютера :-).
Данное утверждение о том, что авторы, команды, компании интерпретируют разработку по разному - заблуждение. Каждому проекту своя методология - это факт. Но база должна быть и особенно это важно для студентов, что бы у них было правильное понимание и восприятие правил игры. То, о чём я писал выше, это не я придумал - это многолетний опыт индустрии под название SWEBOK. Так же существует русский перевод: https://github.com/ligurio/swebok-2004-in-russian
Действительно крутая возможность для студентов!
Есть небольшая ремарка по слайду Проектирование -> Разработка -> Тестирование -> Документация.
Блок "Проектирование" не относится к таковому. На этом этапе идёт только анализ, а уже как раз поле него идёт проектирование где на выходе и получается дизайн-документ о котором написано ниже. Изучение материалов не приводит к проектированию. Проектирование это отдельный процесс со своими особенностями.
Ну и финальный блок "Документация" выглядит как добивание студента :-D. Две самые не любимые вещи которые делает программист - это тестирование и документирование. Дизайн документ точно не описывает все нюансы, он даёт направление (в моём понимании) и в ходе реализации функциональности если не прибегать к документации, то в финале будет очень много рутины и проблем. Поэтому этап документирования должен протекать на этапе всей работы начиная от момента одобрения дизайн-документа.
Использования Nix или Guix это более сложный уровень и требует дополнительного погружения.
Старая версия Emacs в репозиториях или свежая в snap/flatpack - это не проблема Emacs, а проблема используемого дистрибутива.