В теории все звучит красиво (особенно про неподверженность логическим ошибкам), но когда дело доходит до практики, у меня ступор начинается.
Вот конкретное требование из примера в статье:
нужно взять из руки три кубика: один синий или зеленый, второй фиолетовый или желтый, третий синий или белый
Как проверить, правильно ли написано правило для такого рода требований? Кроме предложенного «обезьяньего» варианта брать кубики по очереди и говорить «окей»/«не окей» я ничего путного придумать не могу.
Не пугайтесь, половина из описанного не так и важна. Иначе так можно и не начать никогда.
Что до статьи, то она нацелена больше на людей, которые имеют опыт разработки неигровых приложений, знают про модные методики (и UML им не чужд), имеют мечту, но не решаются воплощать ее в жизнь.
Сервис draw.io. Еще у Visual Paradigm есть хороший визуализатор, но в бесплатной версии он ограничен (хотя UML там есть — возможно, если бы я наткнулся на него раньше, то использовал бы его).
Пусть такая мелочь, как незнание какой-то конкретной технологии, не становится препятствием на пути к вашей мечте (ну или не конкретно вашей — я ко всем обращаюсь). Замените java на basic, а kotlin на malborge — суть от этого не поменяется.
Увы, я не эксперт в написании тестов, потому спорить не буду. Тесты действительно требуют недюжинного внимания, скрупулезности и маниакальности. Ну, или можно писать тесты для тестов…
убежал патентовать идею...
Конкретно по примеру из статьи: даже не знаю, как тут можно улучшить. В руке у нас 10 активных позиций, каждая может быть или выбрана, или нет, что дает 1024 возможных варианта. В тесте рассмотрены только некоторые (как казалось, наиболее характерные). В защиту скажу, что тест очень помог при реализации метода (а процесс реализации помог найти ошибки в тесте — возможно, это обоюдный процесс).
Ну или я лось, и всё можно было сделать гораздо проще — чем не вариант?
Как ни зайду в Steam или Google Play — везде одно и то же. Суровость русскоязычных комментариев компенсируется лишь полным отсутствием реакции со стороны разработчиков.
Согласен. Зато без особо специфических талантов можно написать хорошую интересную игру (особенно если вы имеете опыт разработки неигровых приложений). О чем и статья.
Потому я и посоветовал поначалу с этим не заморачиваться, а писать конкретно игру. При грамотном подходе нужные библиотеки можно прикрутить позже — и ничего не сломается.
Вы совершенно правы — разрабатывать серьезный продукт на собственных велосипедах долго и бессмысленно. Однако для начала неплохо бы иметь представление о том, чем эти библиотеки в своем «нутре» занимаются. Например, я когда-то писал изометрическую игру (:-)) — и она работала жутко медленно по причине плохой оптимизации. Зато удовольствие получил просто непередаваемое. Да и теорию запомнил на всю жизнь — теперь ни один изометрический движок меня не смутит.
Если проводить аналогию с оператором when из Kotlin (который, вероятно, являлся прообразом для нового switch), то первый вариант (только в Java заставят case каждый раз писать, хе-хе). Иначе смысла особого нет.
Вот за «Android Programming: The Big Nerd Ranch Guide» спасибо большое. А то все: «Kotlin! Rx!» и прочие совершенно необязательные вещи. А так чтоб полностью и основательно с вопросом ознакомиться (новичку, например), эта книга из представленных подходит лучше всего.
Эх, а я все ждал, что в статье расскажут, почему юниты и строения в игре вышли такими непропорциональными. Видимо, технические ограничения (кстати, проблема исправлена в AoE II).
Вот конкретное требование из примера в статье:
Как проверить, правильно ли написано правило для такого рода требований? Кроме предложенного «обезьяньего» варианта брать кубики по очереди и говорить «окей»/«не окей» я ничего путного придумать не могу.
А вы можете?
Что до статьи, то она нацелена больше на людей, которые имеют опыт разработки неигровых приложений, знают про модные методики (и UML им не чужд), имеют мечту, но не решаются воплощать ее в жизнь.
Ну и ближе к теме статьи, хе-хе.
Пусть такая мелочь, как незнание какой-то конкретной технологии, не становится препятствием на пути к вашей мечте (ну или не конкретно вашей — я ко всем обращаюсь). Замените java на basic, а kotlin на malborge — суть от этого не поменяется.
Выбирайте те инструменты, с которыми вам удобнее.
убежал патентовать идею...
Конкретно по примеру из статьи: даже не знаю, как тут можно улучшить. В руке у нас 10 активных позиций, каждая может быть или выбрана, или нет, что дает 1024 возможных варианта. В тесте рассмотрены только некоторые (как казалось, наиболее характерные). В защиту скажу, что тест очень помог при реализации метода (а процесс реализации помог найти ошибки в тесте — возможно, это обоюдный процесс).
Ну или я лось, и всё можно было сделать гораздо проще — чем не вариант?
Уж и не рассчитывал, что вы будете продолжать.
Спасибо, ребята!