Спасибо за комментарий, про пошаговое движение уже многие тоже написали — так что, думаю, мы исправим это в одном из ближайших обновлений.
А про проектирование, думаю, здесь только опыт может помочь: с учетом количества допущенных ошибок, упомянутых в статье, мне еще тоже есть чему учиться :)
Полосатый фон и рамочки использованы только для скриншотов, в самой игре их нет.
В любом случае спасибо, постараемся учесть это и улучшить интерфейс :)
Совершенно согласен и, более того, упоминал об этом в статье. Змейку гораздо проще и быстрее было бы написать на «голом» ADT, но одной из целей было как раз познакомиться с Unity, поэтому выбрали что-то не сложное.
Мы смотрели пару других платформ, но ни одна не заинтересовала так, как Unity.
Спасибо за отзыв :)
Может быть есть какие-то конкретные рекомендации по визуальному оформлению? По сути мы сейчас развиваемся методом проб и ошибок, поэтому нам крайне важно получить независимую оценку. Кроме того, данный интерфейс (версии 1.3) уже существенно отличается в лучшую сторону от первоначального (версий 1.0-1.2).
Видимо, вы меня не правильно поняли.
Пусть существует q такое, что для S1 и S2 верно m1 = m(S1 -> N, q); m2 = m(S2 -> N, q). Причем даже в общем случае может быть m1 <> m2. При этом существуют q1 и q2 такие, что !m1 = m(N -> S1, q1); !m2 = m(N -> S2, q2). Очевидно, что в зависимости от исходного состояния и q1, и q2 являются обратным заклинанием для q.
На самом деле, сейчас понял, что проблема даже глубже. Мы ввели множество состояний S, на котором должна быть определенаоперация q, для которой мы вводим метрику m. Дальше следуют три свойства метрики m. Но операцию q мы не ввели и не указали ее свойств.
Если расширять существующую физическую модель мира до магической, то я бы выбрал иное направление. За основу взять предположение, что существует некоторое магическое поле, по своим свойствам аналогичное электро-магнитному полю.
Все предметы и существа обладают некоторой собственной частотой колебаний магического состояния и способностями улавливать, накапливать и отражать магию. Тогда простейшее заклинание должно строиться аналогично электро-магнитному колебательному контуру, сила заклинания будет равна частоте колебаний в данном контуре.
Возможно ли создание заклинания, переводящего объект из любого состояния в состояние несуществования (N)? Проще говоря — заклинание уничтожения объекта?
Если для некоторого объекта существует хотя бы одно заклинание q, способное перевести данный объект из любого состояния S в состояние несуществования N, то как для такого заклинания следует определять обратное ему !q?
Возможно, конфликт во втором постулате. Видимо, следует добавить ограничение, что S[0] и S[1] не равны N, либо допустить, что обратных заклинаний для q может быть бесконечное множество.
На мой взгляд, дело в той IDE, которую используете, и корпоративном стиле.
Например, для MySQL в своих проектах я использую MySQL Workbench — он делает выгрузку в один create script с дополнительной возможностью генерации alter script на его же основе. Этот скрипт лежит в папке data под управлением svn и используется всеми разработчиками для создания своей локальной версии проекта.
На работе коллеги, работающие с Oracle организовывают работу примерно как вы описали — один объект в одном файле, и все файлы лежат опять же в svn. Используется PL/SQL Developer.
Если говорить о движке, написанном «для себя», то, на мой взгляд — самое важное это удобство его поддержки и расширения. Вторым важным моментом является скорость разворота движка на новом сайте.
ВРЕМЯ РАЗВОРОТА
Начну со второго пункта: сколько времени занимает разворот вашего движка на новом сайте?
В моем понимании время разворота движка на новом сайте включает в себя три стадии: 1) разворот базовой версии — создание файлов, папок, создание структуры БД, возможно — выбор начальной конфигурации модулей, идеально — делать это автоматизированно. 2) Натягивание дизайна для заказчика — видимо, за это отвечает модуль template, однако вопрос к вам: шаблон (я имею ввиду сам html-код) с формой, например для логина пользователя — это часть модуля template или auth? 3) докрутка стандартных модулей под желания заказчика — часто чисто внешнего вида, но иногда по желанию заказчика к модулю добавляется новая интересная возможность
Отдельно идет написание новых модулей по заказу или просто в порыве вдохновения. Во время разворота это не включается.
ПОДДЕРЖКА ДВИЖКА
Теперь более интересный вопрос.
Если говорить о CMS, тогда нужно говорить об организации исходного кода и ведении общего репозитория (git или svn — не важно) для разных проектов.
Допустим, у вас есть движок в начальном состоянии его развития. Появляется первый клиент, вы делаете для него сайт, попутно добавляя новые фичи в движок. Проект сдали, выпили шампанского (или пива) и подняли вопрос — а вот мы в модуле [MODULE_NAME] добавили такую прикольную фичу, давайте включим это в базовую версию движка? Но при этом тот же модуль содержит ряд кастомизаций, специфичных для клиента, которые нет смысла вносить в общее решение. Как вы разрешаете (или планируете разрешать) подобные вопросы?
Собственно, для себя я пока вижу только одно интересное решение — организация исходного кода так, чтобы можно было выделить в чистом виде код модуля и хранить все их в одном репозитории, на который ссылаться из каждого отдельного проекта (не знаю, есть ли понятие ссылок в git, но в svn есть и довольно удобно), а все кастомизации вносить в переопределенный класс, который хранится в репозитории заказчка (условно).
Вы не думали о таком структурировании?
Начало взято из фильма. Пример — всего лишь то, что натолкнуло на мысль написать такое. Возможно, я описал свои впечатления не очень удачно, но пару раз меня посещала мысль о «душе» :)
Изначально, конечно, я использовал KeyPress. Но дело в том, что нажатие клавиши на софт-клавиатуре на кпк не посылает событие KeyPress.
И да, вы правы, в случае KeyPress такой ошибки просто не могло быть
Ничего не произойдет, потому что длина текста либо уменьшится (в случае нескольких символов), либо останется такой же.
Пожалуй с точки зрения логики функции, это ошибка.
А про проектирование, думаю, здесь только опыт может помочь: с учетом количества допущенных ошибок, упомянутых в статье, мне еще тоже есть чему учиться :)
В любом случае спасибо, постараемся учесть это и улучшить интерфейс :)
Мы смотрели пару других платформ, но ни одна не заинтересовала так, как Unity.
Может быть есть какие-то конкретные рекомендации по визуальному оформлению? По сути мы сейчас развиваемся методом проб и ошибок, поэтому нам крайне важно получить независимую оценку. Кроме того, данный интерфейс (версии 1.3) уже существенно отличается в лучшую сторону от первоначального (версий 1.0-1.2).
Дело в том, что, имея iframe-приложение, я должен решить, стоит ли вкладывать деньги в ssl доступ к нему или можно пока забить.
Пусть существует q такое, что для S1 и S2 верно m1 = m(S1 -> N, q); m2 = m(S2 -> N, q). Причем даже в общем случае может быть m1 <> m2. При этом существуют q1 и q2 такие, что !m1 = m(N -> S1, q1); !m2 = m(N -> S2, q2). Очевидно, что в зависимости от исходного состояния и q1, и q2 являются обратным заклинанием для q.
На самом деле, сейчас понял, что проблема даже глубже. Мы ввели множество состояний S, на котором должна быть определена операция q, для которой мы вводим метрику m. Дальше следуют три свойства метрики m. Но операцию q мы не ввели и не указали ее свойств.
Все предметы и существа обладают некоторой собственной частотой колебаний магического состояния и способностями улавливать, накапливать и отражать магию. Тогда простейшее заклинание должно строиться аналогично электро-магнитному колебательному контуру, сила заклинания будет равна частоте колебаний в данном контуре.
Если для некоторого объекта существует хотя бы одно заклинание q, способное перевести данный объект из любого состояния S в состояние несуществования N, то как для такого заклинания следует определять обратное ему !q?
Возможно, конфликт во втором постулате. Видимо, следует добавить ограничение, что S[0] и S[1] не равны N, либо допустить, что обратных заклинаний для q может быть бесконечное множество.
Например, для MySQL в своих проектах я использую MySQL Workbench — он делает выгрузку в один create script с дополнительной возможностью генерации alter script на его же основе. Этот скрипт лежит в папке data под управлением svn и используется всеми разработчиками для создания своей локальной версии проекта.
На работе коллеги, работающие с Oracle организовывают работу примерно как вы описали — один объект в одном файле, и все файлы лежат опять же в svn. Используется PL/SQL Developer.
ВРЕМЯ РАЗВОРОТА
Начну со второго пункта: сколько времени занимает разворот вашего движка на новом сайте?
В моем понимании время разворота движка на новом сайте включает в себя три стадии:
1) разворот базовой версии — создание файлов, папок, создание структуры БД, возможно — выбор начальной конфигурации модулей, идеально — делать это автоматизированно.
2) Натягивание дизайна для заказчика — видимо, за это отвечает модуль template, однако вопрос к вам: шаблон (я имею ввиду сам html-код) с формой, например для логина пользователя — это часть модуля template или auth?
3) докрутка стандартных модулей под желания заказчика — часто чисто внешнего вида, но иногда по желанию заказчика к модулю добавляется новая интересная возможность
Отдельно идет написание новых модулей по заказу или просто в порыве вдохновения. Во время разворота это не включается.
ПОДДЕРЖКА ДВИЖКА
Теперь более интересный вопрос.
Если говорить о CMS, тогда нужно говорить об организации исходного кода и ведении общего репозитория (git или svn — не важно) для разных проектов.
Допустим, у вас есть движок в начальном состоянии его развития. Появляется первый клиент, вы делаете для него сайт, попутно добавляя новые фичи в движок. Проект сдали, выпили шампанского (или пива) и подняли вопрос — а вот мы в модуле [MODULE_NAME] добавили такую прикольную фичу, давайте включим это в базовую версию движка? Но при этом тот же модуль содержит ряд кастомизаций, специфичных для клиента, которые нет смысла вносить в общее решение.
Как вы разрешаете (или планируете разрешать) подобные вопросы?
Собственно, для себя я пока вижу только одно интересное решение — организация исходного кода так, чтобы можно было выделить в чистом виде код модуля и хранить все их в одном репозитории, на который ссылаться из каждого отдельного проекта (не знаю, есть ли понятие ссылок в git, но в svn есть и довольно удобно), а все кастомизации вносить в переопределенный класс, который хранится в репозитории заказчка (условно).
Вы не думали о таком структурировании?
И да, вы правы, в случае KeyPress такой ошибки просто не могло быть
Пожалуй с точки зрения логики функции, это ошибка.