Все три пункта идут от того, что вы изначально планировали обратный подход.
По пунктам 1 и 3 (разные движки и языки) я соглашусь. Можно было бы выбрать другие технологии и тогда можно было бы частично одинаковый код.
Пункт 2 же про более оптимальное и точное поведение. На вышеупомянутых примерах:
1. Прозрачность объектов. Зачем серверу знать об этом и тратить на это вычислительные ресурсы? Более того, в нашем случае сервер даже не знает о том, как выглядят деревья. Для него существует только та часть ствола, которая является препятствием.
2. Столкновения динамических объектов. Какая бы ни была идеальная синхронизация, состояния объектов в двух независимых процессах будут отличаться. Соответственно клиент не может со 100% уверенностью гарантировать (вот кто-то так же думает)
Подобные различия можно было бы вынести и использовать дополнительно к общей логике, здесь я согласен.
Отдельный вопрос по нагрузке на I/O. Слать постоянные снапшоты нам не хотелось. От этого подхода мы отказались почти сразу.
Это трудно достижимо по ряду причин:
1. Разные движки на клиенте и сервере. Которые работают по-разному
2. Логика на клиенте не может быть полностью такой же как на сервере, т.к. состояния на клиенте и сервере всегда разные. А на клиенте присутствует логика, которая не нужна серверу (например прозрачность деревьев)
3. Сервер — java (можно считать это требованием), клиент — JS
Не совсем понял ваш вопрос. Отвечу на то, что точно понял:
1. Нельзя было терять ни минуты. Т.е. если бы сперва закончили клиент, а потом принялись бы за сервер, точно не успели его сделать.
2. На клиенте и на сервере разная физика. Например, столкновения движущихся объектов на клиенте не проверяются, потому что клиент не может знать реальное положение объектов в данный момент времени
Просто нажимая клавишу часто. Важный момент — запас снежков ограничен (см. правый нижний угол). Потом они постепенно восстанавливаются. Соответственно пока снежки есть, можно хоть все 5 одновременно бросить. А потом бросать только со скоростью восстановления.
(Этот запас многие вообще не замечают, это к вопросу об игровом тестировании)
Спасибо большое за фидбек! Касаемо продолжения, очень двоякие мысли. С одной стороны это был проект «попробовать и выкинуть», с другой стороны в процессе создания захотелось сделать что-то более стоящее из этого начинания. Но после того как закончился этот интенсивный месяц, осталось желание не делать абсолютно ничего, т.к. выдохлись. Сейчас уже отошли и посмотрим как жить дальше.
Два из ваших пожеланий для нас новые: чат и командное соревнование.
Остальное планировалось/хотелось, но к сожалению не успелось.
Точно, обманул я :( Эта проблема проявляется когда фокус из окна уходит. И Phaser не замечает отжатия клавишы и лишь перебором клавиш 10-20 раз это иногда лечится… Но баг не совсем наш :)
Проявляется он не так часто, поэтому я решил не делать workaround для этого.
Это наша игра и статья.
Касаемо box2d — возможно это был сильный оверхед, зато без собственных велосипедов в данном плане гораздо приятнее. И опыт использования движков на будущее.
PS зашел на сервер — кто-то там бегает уже :)
Интересно. У меня на предыдущем проекте к гредлу не было совсем никаких вопросов в плане производительности.
Однако сейчас делаю мини-проект на андроид и гредл действительно долго собирает. Но сдается мне, что там слишком много лишнего от самого андроида.
На текущий момент слишком много заточено на мэйвен. Просто так взять и перейти на что-то более современное будет слишком трудозатратно и не будет иметь много смысла (ведь всё и сейчас работает).
В стратегическом плане, конечно, рано или поздно перейдем, я думаю, но до этого момента нужно ещё как-то дожить.
Могу вам только позавидовать :) Gradle эту проблему действительно решает очень хорошо.
К сожалению, в моем случае перейти на gradle не так просто, но "мы работаем над этим..."
@sndl, я правильно понимаю, что Pants это не дополнение к maven, а альтернатива? Т.е. если кто-то уже на maven, глубоко и серьезно, то Pants не поможет?
Так-то есть gradle, который инкрементальный из коробки (помимо других преимуществ перед maven). Но смена билд системы это не всегда легко и просто
Спасибо за комментарий.
В целом, предложенное решение в первую очередь полезно для локальной сборки. В локальной сборке этим недостатком можно пренебречь.
Адаптация для билд-сервера это просто приятный бонус. Если этот самый билд-сервер не настолько умный. Если все зависимые модули лежат в одном большом проекте, то этого недостатка в предложенном подходе не будет.
По моему мнению лучше не пытаться использовать один vcs репозиторий для всех модулей.
В идеале: один репозиторий – один модуль.
Отчасти согласен. С точки зрения идеальной организации кода это правильно. Но если у вас сотни или тысячи модулей, то порой гораздо удобнее их хранить вместе. В том числе для работы в IDE.
На мой взгляд, стоит добавить, что HTML5 предоставляет относительно удобный способ кастомной валидации в JS, задействующий те же механизмы, что и перечисленные в статье аттрибуты. Достаточно вызвать для нужного вам поля field.setCustomValidity(text)
При этом, если text пустой, то считается, что элемент валидный, в противном случае — невалидный и переданный текст отображается как ошибка валидации.
Также стоит отметить возможность использования css псевдо-классов :valid и :invalid при использовании стандартной HTML5 валидации.
пс полностью согласен с предыдущим комментарием насчет безопасности — проверка ввода это удобство пользователя, а не защита собственного сервиса.
ппс когда я использовал аттрибут required, он засчитывал наличие любых символов (в т.ч. пробелов). Поэтому писал собственную проверку с использованием trim. Если кто-то подскажет, если это как-то настраиваемо, буду благодарен
Исправил ряд проблем, связанных с win-несовместимостью, написал тестовый скрипт/конфиг и проверил на вин7. Вроде работает.
Если все ещё есть желание попробовать, можете скачать последнюю версию с гита: https://github.com/bugy/script-server
Все мы разные, у всех свои привычки, сильные и слабые стороны. Лично для меня искать с регексом и делать паттерн для замены гораздо дольше, чем выделить 3 символа, нажать 1 хоткий, нажать delete.
Я с радостью стал применять мультиселект вместо автозамены в большинстве случаев, когда джет брейнс реализовали эту фичу. Но до этого не понимал, зачем нужен мультиселект, если есть автозамена. Хотя на тот момент мне было известно только про селект через alt+выделение, который действительно редко нужен.
Не говоря уже о том, что если мы говорим про IDEA и язык, для которого поддерживается рефакторинг, то правильнее будет просто нажать Shift-F6, стоя на нужном нам идентификаторе.
В примере я привел 2 идентификатора осознанно. В данном случае рефакторинг бы потребовался для обоих. К тому же рефакторинг доступен далеко не всегда: текст в джаве, текстовые файлы и т.п.
Всему свое время и место. Если есть возможность использовать рефакторинг, лучше использовать его. Если предстоит сложная замена, то лучше использовать её. Однако если нужно заменить несколько одинаковых паттернов в пределе одного небольшого метода, то для меня мультиселект лучше и быстрее по ряду причин.
По пунктам 1 и 3 (разные движки и языки) я соглашусь. Можно было бы выбрать другие технологии и тогда можно было бы частично одинаковый код.
Пункт 2 же про более оптимальное и точное поведение. На вышеупомянутых примерах:
1. Прозрачность объектов. Зачем серверу знать об этом и тратить на это вычислительные ресурсы? Более того, в нашем случае сервер даже не знает о том, как выглядят деревья. Для него существует только та часть ствола, которая является препятствием.
2. Столкновения динамических объектов. Какая бы ни была идеальная синхронизация, состояния объектов в двух независимых процессах будут отличаться. Соответственно клиент не может со 100% уверенностью гарантировать (вот кто-то так же думает)
Подобные различия можно было бы вынести и использовать дополнительно к общей логике, здесь я согласен.
Отдельный вопрос по нагрузке на I/O. Слать постоянные снапшоты нам не хотелось. От этого подхода мы отказались почти сразу.
1. Разные движки на клиенте и сервере. Которые работают по-разному
2. Логика на клиенте не может быть полностью такой же как на сервере, т.к. состояния на клиенте и сервере всегда разные. А на клиенте присутствует логика, которая не нужна серверу (например прозрачность деревьев)
3. Сервер — java (можно считать это требованием), клиент — JS
1. Нельзя было терять ни минуты. Т.е. если бы сперва закончили клиент, а потом принялись бы за сервер, точно не успели его сделать.
2. На клиенте и на сервере разная физика. Например, столкновения движущихся объектов на клиенте не проверяются, потому что клиент не может знать реальное положение объектов в данный момент времени
(Этот запас многие вообще не замечают, это к вопросу об игровом тестировании)
Два из ваших пожеланий для нас новые: чат и командное соревнование.
Остальное планировалось/хотелось, но к сожалению не успелось.
Оно есть, но только на сервере и на клиенте это не показывается.
Именно из-за этого
Мини-баг, который не влияет на процесс игры :)
Но спасибо за комментарий и наблюдение!
Проявляется он не так часто, поэтому я решил не делать workaround для этого.
Касаемо box2d — возможно это был сильный оверхед, зато без собственных велосипедов в данном плане гораздо приятнее. И опыт использования движков на будущее.
PS зашел на сервер — кто-то там бегает уже :)
Фраза, которую я часто слышу, с тоже "слегка" искаженным значением слова:
Если вдруг кто подписан и кому интересно, появилась возможность работы с Git. Пока пробная версия: https://github.com/bugy/incremaven/releases/tag/1.1.3a
Интересно. У меня на предыдущем проекте к гредлу не было совсем никаких вопросов в плане производительности.
Однако сейчас делаю мини-проект на андроид и гредл действительно долго собирает. Но сдается мне, что там слишком много лишнего от самого андроида.
На текущий момент слишком много заточено на мэйвен. Просто так взять и перейти на что-то более современное будет слишком трудозатратно и не будет иметь много смысла (ведь всё и сейчас работает).
В стратегическом плане, конечно, рано или поздно перейдем, я думаю, но до этого момента нужно ещё как-то дожить.
Могу вам только позавидовать :) Gradle эту проблему действительно решает очень хорошо.
К сожалению, в моем случае перейти на gradle не так просто, но "мы работаем над этим..."
@sndl, я правильно понимаю, что Pants это не дополнение к maven, а альтернатива? Т.е. если кто-то уже на maven, глубоко и серьезно, то Pants не поможет?
Так-то есть gradle, который инкрементальный из коробки (помимо других преимуществ перед maven). Но смена билд системы это не всегда легко и просто
Спасибо за комментарий.
В целом, предложенное решение в первую очередь полезно для локальной сборки. В локальной сборке этим недостатком можно пренебречь.
Адаптация для билд-сервера это просто приятный бонус. Если этот самый билд-сервер не настолько умный. Если все зависимые модули лежат в одном большом проекте, то этого недостатка в предложенном подходе не будет.
На мой взгляд, стоит добавить, что HTML5 предоставляет относительно удобный способ кастомной валидации в JS, задействующий те же механизмы, что и перечисленные в статье аттрибуты. Достаточно вызвать для нужного вам поля field.setCustomValidity(text)
При этом, если text пустой, то считается, что элемент валидный, в противном случае — невалидный и переданный текст отображается как ошибка валидации.
Также стоит отметить возможность использования css псевдо-классов :valid и :invalid при использовании стандартной HTML5 валидации.
пс полностью согласен с предыдущим комментарием насчет безопасности — проверка ввода это удобство пользователя, а не защита собственного сервиса.
ппс когда я использовал аттрибут required, он засчитывал наличие любых символов (в т.ч. пробелов). Поэтому писал собственную проверку с использованием trim. Если кто-то подскажет, если это как-то настраиваемо, буду благодарен
Добрый день, не подскажете, трансляции возможно будет посмотреть позже оффлайн?
Исправил ряд проблем, связанных с win-несовместимостью, написал тестовый скрипт/конфиг и проверил на вин7. Вроде работает.
Если все ещё есть желание попробовать, можете скачать последнюю версию с гита: https://github.com/bugy/script-server
Все мы разные, у всех свои привычки, сильные и слабые стороны. Лично для меня искать с регексом и делать паттерн для замены гораздо дольше, чем выделить 3 символа, нажать 1 хоткий, нажать delete.
Я с радостью стал применять мультиселект вместо автозамены в большинстве случаев, когда джет брейнс реализовали эту фичу. Но до этого не понимал, зачем нужен мультиселект, если есть автозамена. Хотя на тот момент мне было известно только про селект через alt+выделение, который действительно редко нужен.
В примере я привел 2 идентификатора осознанно. В данном случае рефакторинг бы потребовался для обоих. К тому же рефакторинг доступен далеко не всегда: текст в джаве, текстовые файлы и т.п.
Всему свое время и место. Если есть возможность использовать рефакторинг, лучше использовать его. Если предстоит сложная замена, то лучше использовать её. Однако если нужно заменить несколько одинаковых паттернов в пределе одного небольшого метода, то для меня мультиселект лучше и быстрее по ряду причин.