Comments 15
Классный перевод, спасибо! =)
Не плохо) Конечно не на angular, но я однажды нашел 3D реализацию игры 2048 marko-knoebl.github.io/2048-3D
Оу, спасибо! Обожаю 2048 и её вариации.
В принципе, если хорошо играть в классическую 2048, то объёмная версия даже проще — подтягивать циферки можно с дополнительных направлений.
В принципе, если хорошо играть в классическую 2048, то объёмная версия даже проще — подтягивать циферки можно с дополнительных направлений.
У меня во всяком случае получилось с первого раза
Теперь ждём четырёхмерную версию :)
Зачем ждать, когда можно играть?— какая-то там лотерея
huonw.github.io/2048-4D/
А когда захочется еще больше размерностей:
cesarkawakami.github.io/2048-5D/
karma-cli надо еще установить, инача команды начинающиеся на karma работать не будут.
Может, кому пригодится, но если в директории проекта создать файл .bowerrc с ниже указанным содержимым, загружаемые библиотеки будут храниться в каталоге common, а не bower_components:
{
"directory": "common"
}
Мне почему то кажется, что это оверинженеринг и такую игру можно было бы сделать куда проще. Так же у меня сомнения на счёт позиционирования элементов через классы.
А в чём именно оверинжиниринг? В использование самого ангуляр?
В целом. Если такую игру с помощью angular нельзя сделать проще то значит в angular.
Но как я уже написал выше, у меня сомнения на счёт классов, а значит SASS можно было бы в принципе убрать. JS при этом не сильно бы раздулся.
Сейчас глянул код детальнее и понял, что попытка для игры использовать абстракции angular вот главная проблема. К примеру GenerateUniqueId это уже решение проблем которые сами и создали.
Кроме того, я бы в принципе не разделял бы ячейки и плитки. Если в ячейке 0 значит она пустая, и отказался бы от логики «перемещения плиток» (не для эффекта конечно).
Но это всё поверхностно, единственное в чём я теперь уверен это то, что можно было бы сделать игру гораздо проще.
Но как я уже написал выше, у меня сомнения на счёт классов, а значит SASS можно было бы в принципе убрать. JS при этом не сильно бы раздулся.
Сейчас глянул код детальнее и понял, что попытка для игры использовать абстракции angular вот главная проблема. К примеру GenerateUniqueId это уже решение проблем которые сами и создали.
Кроме того, я бы в принципе не разделял бы ячейки и плитки. Если в ячейке 0 значит она пустая, и отказался бы от логики «перемещения плиток» (не для эффекта конечно).
Но это всё поверхностно, единственное в чём я теперь уверен это то, что можно было бы сделать игру гораздо проще.
Вы правы, эту игру действительно можно сделать проще используя angular.
Во-первых, автор оригинала построил очень странную ООП систему.
Я все никак не пойму, почему вдруг GameManager ответствует за move(), когда эта обязанность ложится на саму плитку.
Сама игра, то есть Game не должна быть синглтоном, в отличае, например, от ее настроек, так как кнопка New Game сама по себе подсказывает о создании нового инстанса игры, чистого, по существующему конфигу.
Информация о Score и high score должна лежать в отдельном объекте score, который может быть синглтоном из-за своей специфики.
Хранение в объекте грида массива с плитками вообще кажется мне диким, для этого используют репозитории, и да Вы правы, можно было бы не разделять ячейки и плитки в два разных массива, а используя один репозиторий иметь коллекцию данных в двумерном массиве.
Ну и в конце концов при перемещении плитки ее можно было бы мержить с пустой ячейкой, это легче спроектировать и поддерживать, чем разработать логику проверок и логику слияния при не пустом значении.
И так далее.
Что же касается GenerateUniqueId — это нормальная практика в системах где для некого объекта необходимо иметь один и только один глобальный идентификатор, обозначающий не только его номер в БД / Порядковый номер / Номер элемента в порядке появления, но и саму принадлежность, для избежания пересечений с другими идентификаторами других объектов системы. Подробнее тут — ru.wikipedia.org/wiki/GUID. Собственно, из за этой заметки, и заметке о создании фабрик/провайдеров и их отличие от обычных service, статья и попала ко мне в избранное. Остальное является, как мне кажется, пробой пера автора оригинальной статьи.
Так что ангуляр тут совершенно не причем, а вот у автора есть определенный ряд проблем с ООП и MVC.
Во-первых, автор оригинала построил очень странную ООП систему.
Я все никак не пойму, почему вдруг GameManager ответствует за move(), когда эта обязанность ложится на саму плитку.
Сама игра, то есть Game не должна быть синглтоном, в отличае, например, от ее настроек, так как кнопка New Game сама по себе подсказывает о создании нового инстанса игры, чистого, по существующему конфигу.
Информация о Score и high score должна лежать в отдельном объекте score, который может быть синглтоном из-за своей специфики.
Хранение в объекте грида массива с плитками вообще кажется мне диким, для этого используют репозитории, и да Вы правы, можно было бы не разделять ячейки и плитки в два разных массива, а используя один репозиторий иметь коллекцию данных в двумерном массиве.
Ну и в конце концов при перемещении плитки ее можно было бы мержить с пустой ячейкой, это легче спроектировать и поддерживать, чем разработать логику проверок и логику слияния при не пустом значении.
И так далее.
Что же касается GenerateUniqueId — это нормальная практика в системах где для некого объекта необходимо иметь один и только один глобальный идентификатор, обозначающий не только его номер в БД / Порядковый номер / Номер элемента в порядке появления, но и саму принадлежность, для избежания пересечений с другими идентификаторами других объектов системы. Подробнее тут — ru.wikipedia.org/wiki/GUID. Собственно, из за этой заметки, и заметке о создании фабрик/провайдеров и их отличие от обычных service, статья и попала ко мне в избранное. Остальное является, как мне кажется, пробой пера автора оригинальной статьи.
Так что ангуляр тут совершенно не причем, а вот у автора есть определенный ряд проблем с ООП и MVC.
Что же касается GenerateUniqueId — это нормальная практика
Согласен, но тут я не вижу необходимости делать id для плиток, так как 2 индекса для двухмерного массива однозначно определяют ячейку/плитку.
т.е. мне кажется если бы автор оригинала учёл ваши и мои замечания то необходимость в GenerateUniqueId отпала бы.
Статья интересная, но гифка на 27 МБ… Вы издеваетесь? :)
Sign up to leave a comment.
Делаем игру 2048 на AngularJS