Comments 23
Так, игра должна быть основана на прекоде от команды курса, код должен быть написан с использованием ООП
Так сделайте шаблон готового репозитория где будут requirements.txt, ридми, настроенные линтеры, прекоммитхуки и всё подготовленное для написания тестов.
Это некоторый оверхед для студентов, но зато с места в настоящую разработку. И это будет проект который не стыдно показать.
На самом деле именно так и сделано: студентам на базе шаблона генерируется индивидуальный репозиторий, который уже содержит базовый прекод, тесты, настройки линтера и прочее. В итоге ревьюер получает работу, в которой уже не надо тратить время на замечания по поводу форматирования или на проверку ключевых пунктов из задания, а можно сфокусироваться на самом коде и на лучших практиках.
Это будет уже не "оверхед", а чистый "кыш отсюда" для большей части студентов. Ведь многие приходят совсем зеленые (вот как Марина в статье).
Курс рассчитан на постепенное погружение в настоящую разработку - после года обучения они уже все перечисленное: requirements.txt, ридми, линтеры и даже больше - понимают и применяют.
А в первом проекте это не нужно. Лучше не пугать, а мотивировать на обучение.
Какие критерии для оценки что используется ООП?
Решение должно быть реализовано на принципах ООП. Необходимо реализовать базовые классы, применить наследование, полиморфизм и инкапсуляцию. То есть решение исключительно на функциях не будет принято, но вспомогательные функции использовать можно. Часть задания проверяется автоматическими тестами на базе Pytest (что есть определенные в задании классы, есть наследники этих классов и так далее), а финальная проверка и решение о принятии работы после доработок в зоне ответственности ревьюера.
Есть примитивное дерево из классов для фигур, которые можно показывать: общий базовый, наследник Яблоко, наследник Змея. Метод для отрисовки фигуры лежит в базовом, а реализован в каждом из наследников.
хотелось бы технических подробностей реализации растущей змеи. Какие подходы используют студенты? У меня тоже где-то валяется моя студенческая змейка начала 2000-х, хотелось бы сравнить.
В статье есть ссылки на репозитории студентов, где можно посмотреть все подробности именно их реализаций.
Ох! Десятки их!
Чего только не выдумывают. Хорошо известно, что новички выдумывают такое, что опытным никогда в голову не придет.
Но если змея бегает и ест яблоки, то все это считается правильным.
После питона предлагаю написать клоны игры Filler (https://ru.wikipedia.org/wiki/Filler), разумеется на python.
Третьим пунктом пусть будет игра "точки"
( https://ru.wikipedia.org/wiki/Точки_(игра) )
На мой взгляд лучше давать разные задачи. Веб сервер, обучить модельку, поиграться с базой данных и каким-нибудь API, простенький парсер.
Если бы мне доверили - я точно бы заставлял делать Пентамино.
Сам на разных языках писал - очень помогает понимать где в языке засада по нагрузочным вычислениям.
И еще алгоритмические скилы прокачивает.
Раз уж напомнили. Игрался недавно с нерегулярной сеткой и чисто поржать сделал на ней змейку. С ограничением на количество поворотов (планировать маршрут надо) получилось занятно :)
Но вообще прикручивание классов к змейке (которая в минимуме строчек на 10 тянет) приучает лепить их по любому поводу. А потом в проекте живёт куча классов типа обёртки для msgbox, которая... просто обёртка классом системной функции. Понятно, что это учебный процесс, но стоит уметь обходиться и без обёрток, когда в этом нет явного смысла.
А вы мозаики Пенроуза не хотите попробовать?
Жестоко! Но идея интересаная :D
Правда это будет совсем не играбельно. Грани не выпуклые и прикинуть маршрут больше чем на пару клеток будет нереально. Даже тут иногда сложно, когда образуются развилки и промах на 1 клетку отправляет в противоположном направлении.
Там есть несколько разных наборов базовых фигур. Если не ошибаюсь, один из них совершенно выпуклый.
Посмотрел. Да, есть пара наборов, на которых можно сделать. И в целом при наличии связей между плитками - не сложно. Тут тоже всё на связях, так что можно просто воткнуть сюда другую сетку. Но это будет лютая жесть. Там слишком резкие повороты на каждой плитке. Т.е. надо будет рулить на каждом шаге, что нереально на каком-то осмысленном промежутке времени. Если же разбивать дополнительно, чтобы была какая-то вменяемая сетка, то визуально от текущего варианта разницы почти не будет. Исходное разбиение визуально полностью потеряется. Мой вариант тоже изначально состоял из ромбов и треугольников (что немного выдают границы области).
Тут классы немного имеют смысл как контейнеры для состояний. Хотя я бы заменил на NamedTuple и композицию. Развернуть всю силу ООП не очень получится.
Изгиб питона: 6 взглядов на игру из 1970-х