Comments 15
В ближайшее время планирую открыть полностью проект и выложить на GitHub, но сперва будут реализованы задуманные вещи.
А не могли бы заранее создать репозиторий, чтобы на него подписаться?
Вот, пожалуйста: github.com/AndrewShmig/Sapper-RoyalEngineer
Обновленная ссылка: github.com/NonAtomicGames/Sapper-RoyalEngineer
Идея про открытость проекта нравится. Кстати, у картинок в оформлении поста есть параметры width=" ", height =" ", а обширный код можно в спойлеры прятать.
Раз отказались от 4 и всего, что ниже, значит рисовать надо только под ретину — отлично!
5 от 4 и 4s отличается только размером экрана.
Три вещи над которыми дизайнер дольше всего работал:
Анимация взрыва бомбы
Посмотрите на бесплатный Explosion Generator 3
ширина текстовой надписи (UILabel) изменялась и менялось само расстояние между символами, что нас не устраивало
Нужно было сразу или искать моноширный шрифт или делать его самому как bitmap font (что надо было делать с самого начала, если вы конечно считаете draw calls).
Не обижайтесь, но сам подход «подгонка по пикселям GUI» не будет работать ни на одной платформе нормально. После выхода 6го айфона неумение работать с разными разрешениями вам аукнется. Я молчу про андроид.
Удивительно что на такой простой сцене у вас возникли какие-то проблемы с производительностью. Вы использовали стандартные техники SpriteFrameCache и SpriteBatchNode?
Посмотрите на бесплатный Explosion Generator 3
Большое спасибо, глянем.
Не обижайтесь, но сам подход «подгонка по пикселям GUI» не будет работать ни на одной платформе нормально. После выхода 6го айфона неумение работать с разными разрешениями вам аукнется. Я молчу про андроид.
Здесь я согласен с вами, но возможная потеря пропорций меня напрягала. Как с этим бороться?
Удивительно что на такой простой сцене у вас возникли какие-то проблемы с производительностью. Вы использовали стандартные техники SpriteFrameCache и SpriteBatchNode?
SpriteKit, а не Cocos2D.
SpriteKit, а не Cocos2D.
Я думал они 1 в 1 передрали API кокоса. Значит я вам не помогу с этим, к сожалению.
Здесь я согласен с вами, но возможная потеря пропорций меня напрягала. Как с этим бороться?
Универсального рецепта нет, к сожалению. Для приложений вроде вашего, где вся сцена должна располагаться на одном экране (если я правильно понял), техники примерно могут быть следующими:
— при поддержке 4+ айфонов, можно принимать размер экрана 4ки за всю активную игровую сцену (с клетками), а на 5+ девайсах добавлять арт, компенсирующий разницу в высоте. В вашем случае можно было сделать разные элементы управления: вашу текущую версию оставить для 5+, а для 4+ сделать более компактное меню (ваше вполне можно уменьшить в пару раз без потери функциональности).
— при поддержке зоопарка андроидов, а так же 6+ айфонов, делать несколько наборов ассетов + скалирование. Для вашего случая за минимальный размер экрана можно было бы выбрать 4й айфон, условно говоря это был бы размер 1х. При загрузке игры расчитывать размер клетки (исходя из разрешения экрана и количества клеток по вертикали-горизонтали). Если размер больше 4го айфоновского, но меньше условного 1.5х, то брать ассеты размера 1.5х и скейлить до нужного размера. Если больше 1.5х, то скейлить из 2х и т.д. Все зависит от спектра поддерживаемых разрешений. По хорошему вы должны требовать от художника всего арта в нескольких размерах сразу, к примеру исходный, 2х и 4х для планшетов. В идеале вы должны следить, что бы ассеты были нарисованы под каждый размер (с уменьшением/увеличением детализации), а не просто отскейлеными в фотошопе, но это будет очень дорого, особенно учитывая анимации.
— весь код должен работать с design resolution, а не напрямую с физическим разрешением экрана. Как дела обстоят в вашем фреймворке я не знаю.
Да, скалирование не бесплатная операция, но я не знаком с sprite kit, поэтому не могу дать какие-то советы на этот счет.
для 4+ сделать более компактное меню (ваше вполне можно уменьшить в пару раз без потери функциональности).
Хм, это вариант, надо посмотреть, что из этого получится. Хотя, есть подозрение, что выглядеть это будет криво.
Вот, как выглядит игровой экран на 3.5:
Снизу обрезаются 11 и 12 ряды ячеек и немного 10. При уменьшении размеров верхней панели никак не получится отобразить 2 ряда без ресайза, а ресайз опять таки скажется на пропорциях. Делать поле со скроллом — может и выход, но пока мне этот вариант не нравится.
позиционирование элементов и указание позиций
Да уж. Позиционирования элементов в пикселях от края… неужели в фреймворке нет умных лэйаутов как в Qt, WPF.
О поле на разных размерах экранов — Вам товарищ «murr» правильно сказал, игровое поле (клетки с минами и без) можно не масштабировать, а обнести их столбиками с оранжевой лентой для визуального отделения минного поля от не игрового пространства. А зная размер экрана и поля добавить по 4м сторонам заливку травой без разделения на клетки. Ваш игровой экран 3х5 нельзя осознать — где там минное поле, где безопасная зона.
Да уж. Позиционирования элементов в пикселях от края… неужели в фреймворке нет умных лэйаутов как в Qt, WPF.
Проблема в сохранении пропорций, а не в автоматическом позиционировании элементов относительно друг друга.
Возьмите те же спрайты на игровом поле, они у нас квадратные, если изменить поле (уменьшить по высоте), то при изменении scale тайлы станут прямоугольными, что нам не надо. Вот и возникает вопрос о сохранности и размеров поля и пропорций.
можно не масштабировать, а обнести их столбиками с оранжевой лентой для визуального отделения минного поля от не игрового пространства. А зная размер экрана и поля добавить по 4м сторонам заливку травой без разделения на клетки.
В это что-то есть, такое решение даст несколько положительных моментов в сочетании со скроллом — различные размеры поля.
Но опять же, вы предлагаете решение для случая, когда размеры поля _меньше_ размеров экрана, а не наоборот.
Ваш игровой экран 3х5 нельзя осознать — где там минное поле, где безопасная зона.
Не совсем вас понял. Разъясните подробнее пожалуйста.
Самое интересное в пост не влезло, а именно: что было с игрой после одобрения эпплом? Скачало ли ее больше чем 10 человек, продвигали ли ее как-то и сели да, то как? Сделать игру нынче 10% дела, остальные 90% — сделать так, чтоб в нее хоть кто-то поиграл.
После публикации вот такой график (статистика за 30 апреля, 1 мая и 2 мая):
Никаким продвижением не занимались, у нас цель была пройти все этапы самим, разобраться, где и какие вопросы возникнут, решить какие-то проблемы. Игра для нас тестовая и, в своем роде, полигон, для отработки каких-то навыков.
Никаким продвижением не занимались, у нас цель была пройти все этапы самим, разобраться, где и какие вопросы возникнут, решить какие-то проблемы. Игра для нас тестовая и, в своем роде, полигон, для отработки каких-то навыков.
а сколько сейчас уже загрузок у игры?
Не забудьте выложить игру на гитхаб, как вы обещали ранее! Данные ранее ссылки на гитхаб дают 404.
Не забудьте выложить игру на гитхаб, как вы обещали ранее! Данные ранее ссылки на гитхаб дают 404.
Ссылка на игру: github.com/NonAtomicGames/Sapper--Royal-Engineer
Статистика, примерно такая (от Флурри), если нужна еще какая-то инфа, спрашивайте:
Статистика, примерно такая (от Флурри), если нужна еще какая-то инфа, спрашивайте:
Sign up to leave a comment.
Sapper: Royal Engineer