Публичная разработка игры. Часть 3.

Позади 15 часов разработки.

По итогам прошлого поста у меня уже есть возможность строить первые столы и лестницы.

Теперь надо расширение здания реализовать. Я уделяю этому особое внимание потому, что у меня инвертированный игрек, и потому, что я использую одномерный массив вместо двухмерного для описания двухмерного пространства. Я делаю это, потому что такой подход самый быстрый технически. Но немного запутанный логически. В общем приступаю:

Неожиданно расширение оказалось проще высоты. Вставить дополнительные клеточки в нужные места списка просто. А вот поехавший игрек у всех объектов — это уже сложно. Возможно стоит развернуть игрек, а то дальше станет еще запутанней.

В итоге оказалось легче смириться с тем, что отсчет идет с верху вниз. Легче подвинуть все элементы, чем каждый раз у каждого элемента в каждой строке, отвечающей за графику, при отображении инвертировать игрек.

И еще маленькая проблема с лестницами была, но уже решена. Состояние на 16 часов.

Следующая задача — комната кормушка. Собственно на данный момент это просто будет. «Что-то» отличающееся от стола, чтобы мне самому было понятно, что происходит. Функционал самого питания будет позже.

Начинаю уже чувствовать потребность в рефакторинге, а то с этими разными объектами нагородил…

Но приступлю наконец к хомякам. Хомяки на текущем этапе с зданиями не сильно то пересекаются и мутный код зданий не помешает коду хомяков.
Что должен делать хомяк? Бегать, кушать, работать за столом, носить предметы.

Бег. Само перемещение это лишь вершина айсберга. Бег включает в себя поиск пути, использование лестниц и их обход, выход из за стола и заход за стол. И возможно я что-то еще не учел.

Но просто сферический бег в вакууме очень скучно делать, поэтому я сразу начну с цикла, который смотрит на хомяков и управляет ими. Цикл вызывается каждую перерисовку, но привязан к времени (смотрит сколько миллисекунд прошло с прошлого вызова цикла) и управляет жизнью хомяков, как она поменялась за эти миллисекунды, у кого-то упадет параметр сытости, кто-то сделает какую-то деталь за рабочим столом, кто-то просто переместится.

Дальше больше. Все задачи перемещения можно свести к поиску пути + построению цепочки шагов, в которой каждое звено соответствует каждым (условно) 500 миллисекундам. Время идет, игра знает на какой цепочке текущего маршрута сейчас находится хомяк и помещает его туда, плюс делает смещение и включает необходимую анимацию.
На словах то просто, но сложности начинаются уже на этапе «поиск пути».
Сложности усиливаются на этапе «поиск пути в трехмерном пространстве, которое предварительно надо генерировать из нашего здания»

Ну а что, никто и не обещал, что будет легко. Наоборот я сразу написал, что игра будет соответствовать моему текущему уровню скила, а поиск пути в трехмерном пространстве я уж как нибудь осилю.

Впрочем подумав еще, я наоборот отказался от трехмерного пространства, ведь маршруты мимо комнат, мимо лестниц, заход за стол, подступ к лестнице и т.д.. они все статичны и их можно заранее описать и тратить ресурсы процессора на полноценный поиск пути с обсчетом каждого шага, не нужно. Но все равно остается поиск пути и создание цепочки пусть даже из предопределенных шагов.

Подготовил сцену.

Сделал поиск пути по алгоритму A*
Понял, что нужен алгоритм «Поиск в ширину», сделал и его.

Первый алгоритм находит кратчайший путь до заданной точки, это когда мы точно знаем куда хомяку надо бежать.
Второй алгоритм находит кратчайший путь до ближайшей подходящей точки. (то есть находит и путь и точку). Это когда хомяку надо куда-нибудь, и лучше бы это место было поближе. Например ближняя кормушка, или ближний склад на котором хранятся нужные предметы.

В общем тут тоже заминка.
Сейчас 20 часов. Описываю движение внутри комнаты. Немного нудновато, но где-то ведь все равно надо описать как он будет двигаться, как он будет заходить за стол, как выходить из за него. Как залезать на лестницу, слазить с нее, как обходить ее.

А как иначе, поведение хомяка внутри комнаты — это часть описания комнаты. Не думаю что это можно сделать как-то иначе. Ситуация усложняется тем, что мне нужен не только порядок клеточек где он будет, но и его положение (спиной, лицом, боком влево, боком вправо), анимация и скорость движения в этом месте.

….

В итоге я все же придумал как быть. Вариант похож, но немного другой. Я задаю только направления шагов, а весь остальной обсчет пусть делает код. Я думаю это окончательное лучшее возможное решение.

….

И в конечном итоге я вернулся к решению делать почти трехмерный поиск пути. (обсчитываю подробно начальный и конечный этаж, а промежуточные этажи если они есть упрошено делаю, от полного трехмерного отказался, чтобы игре не приходилось обсчитывать слишком большой массив)

Вот эта вот часть самая неприятная во всей разработке, когда перебираешь в голове варианты реализации, а потом внезапно оказывается, что ты что-то упустил и выбранное решение не лучшее (в предыдущем варианте с предопределенными маршрутами возможны абсурдные ситуации когда хомяку надо перейти за соседний стол, и он вместо того, чтобы просто пойти за соседний стол, будет сначала вылазить на главную дорогу, а потом уходить с нее).
Кому-то со стороны кажется даже, что такое метание между решениями признак некомпетентности и любой студент на моем месте запросто выберет правильный вариант и быстренько все реализует.

Еще покодил и пошел спать. Итак засиделся.

На свежую голову за час допил. В итоге у меня 24часа 50 минут, 157килобайт кода и достаточно быстрый алгоритм построения пути, ходящий по лестницам, учитывающий внутренности комнат и то, что хомяки не просто из комнаты в комнату ходят, а ходят в разные места этой комнаты и стартуют из разных мест комнаты.

Вместо игры пилю движок блин.

Еще пара часов на косяки, прикручивание маршрутов к самим хомякам, и установку актуального арта, и в итоге 27 часов.

Конечно, любой студент сделает все быстрее и лучше, учтет все-все нюансы, ведь тут всего то поиск пути (по мнению самого студента), но у меня вот так.
Думаю предполагаемые 50-100 часов на проект нужно скорректировать в сторону 70-130… ((

 


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 0.0/10 (0 votes cast)

25 thoughts on “Публичная разработка игры. Часть 3.

  1. Я упоминал в последнем комментарии как раз, загугли «Задача о кратчайшем пути» и «Алгоритм Дейкстры», может это как раз то, что нужно. ЕМНИП, всякие маршруты на гугл картах как раз по Дэйкстре строятся. Перебором это ни одна мобилка не справится. Еще можно гуглануть «транспортную задачу», тоже вроде как релейтид чуток.

  2. Я знаю о алгоритмах поиска пути и их и реализовал.
    Просто к одному только поиску не сводится вся задача.

  3. Нет планов написать об этом подробнее? Т. е. в рамках цикла, но посты именно про алгоритмические решения и логику, на каком этапе понял, что нужен рефакторинг и будет ли он по факту… Мне было бы интересно, может еще и ниже кто к реквесту подключится :3

  4. tulvit, эм ну можно и про логику, я наоборот стараюсь не углубляться сильно, чтобы не утомлять )))
    К тому же у меня не то качество кода, которым хотелось бы хвастаться, так что в любом случае буду описывать простыми словами.

    Конкретно тут поиск сделал так:
    У каждого объекта расположенного на этаже есть своя маска клеточек, доступных для движения. Ничего изощренного, но все же, прямо через стол, например ходить нельзя будет ))
    Из этих масок генерируется внутренняя карта конкретного этажа.
    Движение хомяка тоже не просто из комнаты в комнату происходит, а из конкретного места в конкретное место.
    Если хомяк и его цель находятся на одном этаже то беру карту этажа и делаю поиск чисто на ней. Результат функции поиска пути у меня массив с последовательностью шагов хомяка.
    Если хомяку надо сменить этаж, да не один, то обсчитываю сначала все здание по большим секторам (создавая дополнительные непроходимые линии между этажами, которые прорезаются лестницами). Нахожу по каким лестницам и по каким секторам он пойдет.
    При составлении цепочки шагов проверяю, если текущий этаж это стартовый или целевой этаж, то тогда игнорирую рассчеты по секторам и делаю рассчет конкретно этого этажа, просто вместо второй точки ставлю место где хомяк хочет сменить этаж.
    Если у нас движение по лестнице или движение по не целевому и не начальному этажу, то за каждый большой сектор просто добавляю в цепочку действий несколько заранее очевидных шагов. Например движение по лестнице это 10 шагов по вертикали. Движение по этажу это 2 шага за сектор. (это позволяет не обсчитывать весь этаж, если он не несет значимой информации о движении)
    Ну а в итоге последовательность шагов. И по срабатыванию таймера берется первый элемент и применяется к текущим координатам хомяка, смещая его в одну из 4 сторон.
    Такой подход позволяет проложить маршрут один раз и идти по нему, пока он не кончится, не пересчитывая его каждый раз.

    Рефакторинг нужен чтобы это не было похоже на кое-как прикрученный костыль, и чтобы это можно было использовать в следующих играх с минимумом правок )))
    Плюс просто скомканная немного структура получается, а это вызывает дискомфорт и путаницу, а это в свою очередь снижает мотивацию к разработке.

    Основное препятствие для рефакторинга это не моя лень, а то, что таймер разработки вырастет еще на Х часов, а игра не продвинется ((

  5. Спасибо.

    Чьерт, как жи захотелось пойти игры кодить, тут хотя бы действительно на погроммирование процесс смахивает, в отличии от пинания того же фронтэнда. От одного только прочтения комментарии в голове что-то начало шевелиться, лол. Присматриваюсь давно уже к PhoneGap и подобным, на ванильном ЯС писать. Хотя у меня с идеями все швах, прошелся поиском по своим старым чятикам, нашел только это, «Базовая идея — кликер, по экрану летают жопы и надо их все скликать. По-моему, гениально.» 🙁

    > это не моя лень, а то, что таймер разработки вырастет еще на Х часов, а игра не продвинется

    Так это же инвистяшка в собственные скиллы и т. д., т. е. я бы не смотрел так однобоко на это. Если по времени и по финансам тянешь все сделать по уму с левел-апом по скиллам — то черт с ними, с часами, профит на долгой дистанции будет выше. Хотя это я со своей далеко не самой лучшей колокольни))00

  6. Дальше будет меньше логики. )) Я специально с основного каркаса начал, чтобы игра быстрее приобрела рабочие очертания.

    А кликкер — отличный старт. )))))

    Да, инвестиция. Но в текущей игре код вроде работает, а для другой все равно придется делать какую-то адаптацию.
    Ну и я все же потихонечку рефакторю, когда приходится что-то менять в функциях, или когда неудобная структура объектов и классов становится очевидной.

  7. Max, хомяки имеют отдельный массив классов графических объектов.
    И отдельный массив логических объектов самих хомяков. У логического класса пока, что только есть параметры координат и маршрута.

    Классы комнат сложней и запутанней. И я наверное их переделаю.
    Сейчас есть отдельный графический массив лестниц, отдельный логический массив лестниц. Графический и логический массивы комнат.
    Плюс еще отдельный массив с описанием позиционирования картинок внутри комнаты.
    Плюс массив секторов.
    Буду объединять комнаты и лестницы, а может даже и сектора.

  8. Спасибо за подробное освещение разработки, редко кто делится!
    Хотелось бы побольше узнать как расчитываете баланс в кликерах.

  9. После первого поста я думал, что игра будет плоской (с псевдо-3D), типа как большинство игр для денди. Однако твоё решение поиска пути выглядит вполне адекватным для 3D. Интересно только на сколько хомяков хватит ресурсов среднего телефона. Или бегать будут только те хомяки, которых видно на экране? Кстати, какое среднее ожидаемое количество этажей и хомяков на один этаж должно быть у игроков?

    Не очень понятна работа со структурами данных: ты пишешь, что у тебя для всех сущностей есть логические и графические массивы. А зачем? Почему не массив объектов, которые хранят всю информацию о сущности?
    Проблема с нумерацией этажей из-за инвертированного игрека тоже не очень понятна: пусть этажи хранятся в списке, новый этаж добавляется в начало списка, отрисовываешь их как обычно сверху вниз, а если нужно нумеровать, то номер этажа — это (длина_списка)-(индекс_текущего_элемента).

  10. FinReader, отличные вопросы.

    3d это громко сказано. Просто этажи имеют глубину.

    Поиск пути не будет отнимать много ресов. Потому, что делается один раз на весь путь. И поэтому для каждого хомяка будет делаться не так уж и часто.

    Ограничение обсчета видимой зоной я еще не сделал, но я заложил эту возможность. И чтобы эта возможность существовала, мне пришлось писать более сложный и запутанный код для обработки пальцевого масштабирования и перемещения сцены (о котором я писал в первой части еще). Мой алгоритм вычисляет каждый объект отдельно. И следовательно я всега буду знать видим конкретный объект или нет.
    Более просто решение — создать отдельную сцену и двигать/масштабировать ее целиком. Легче код движения/масштабирования, но хуже контроль за конкретными элементами.

    Суммарное количество этажей и ширину этажей буду прикидывать позже это вопрос баланса.
    Общее количество видимых секторов ограниченно минимальным масштабом.

    Так же при совсем маленьком масштабе можно упростить хомяков отображая вместо анимации просто их иконки.
    Дело в том, что количество анимации которую игра потянет без тормозов, ограниченно (я об этом писал в начале второй части).

    А вот графических одиночных элементов запросто можно тысячу поставить без видимых лагов.

    __

    В следующей части, которая еще не дописана, я описал рефакторинг. Там я свел сущности в более компактные массивы. Но разделение на графику и логику я все равно оставлю.
    1) Графика в любом случае имеет свой отдельный графический класс и мне кажется логичным иметь массив именно этих графических элементов, и взаимодействовать при обсчете графики только с этим массивом.
    2) Отдельный логический массив легче сохранять/загружать.
    3) Я не уверен (надо делать тесты), но скорее всего при попытках манипуляции с логикой больших классов (в которых помимо логики еще и графика), это будет происходить медленней, чем просто манипуляция в логическом массиве «без мусора». Надо тесты делать, но так, как я все равно не буду объединять массивы, то не буду тратить время на тесты.
    4) Я просто уже привык разделять логику и вывод графики.

    Про этажи я тоже написал в новой части.
    «новый этаж добавляется в начало списка» и тогда ВСЕ игровые элементы смещаются, и я предполагаю, что какая-нибудь проблема всплыла бы еще по ходу разработки.
    Я сначала и делал с добавлением этажа в начало списка. Но на данный момент уже все перевернул.
    Логически нулевой этаж сейчас в самом низу, а графически у него наоборот самый большой и о графике я могу больше не думать (вот еще один пример разделения логики и графики)

  11. Reader, а с балансом просто.

    Постепенно снижаю соотношение награды к затратам. То есть если в начале можно потратить условных 100 монет и окупить их за пол минуты. То по мере игры это время будет увеличиваться. И, например, вложенные 6000 монет буду окупаться уже час, а не пол часа. Мне кажется все примерно так и делают.

  12. Общий смысл понятен.
    Расчитываешь в таблицах что-то или как-то по-другому?

  13. У меня вопрос, а чем тебя двухмерный массив не устраивал? Разве не легче было представить все в виде матрицы? Или ты не хочешь что бы комнаты распологались на одной высоте и на одинаковом расстоянии друг от друга? Если бы у тебя был двумерный массив, то найти путь можно очень просто. И анимацию разбить для себя на переход хомяка из квадрата в квадрат… если это не конечная точка то бежим, если поилка то анимация питья, если комната со столом то анимация как хомяк садиться за него. Но возможно у тебя сама среда ограничивает и ты вынужден кодить по другому

  14. Этаж двухмерный. (не одномерный)
    Лестница дает третье измерение.
    Да можно сделать лестницы, как аналог тоннелей между этажами, но
    1) уже поздно.
    2) я хотел, чтобы на лестницы надо было забираться с их начала, чтобы за лестницами можно было проходить и чтобы хомяк спускался по лестнице спиной (в тоннеле он бы «спускался» лицом к игроку). Короче хотел полноценную лестницу.

    А массивы у меня, кстати, по возможности одномерные. Они быстрее двухмерных по процессорному времени. )))) Хотя и замедляют разработку и отладку из за недостаточной наглядности.

  15. Лестницы как я понимаю динамические, игрок их будет покупать, что бы ускорить комуникацию между этажами, верно? Про третье измерение понятно и ключевым фактором являеться первый пункт «уже поздно». Лестницы между комнатами смотряться эффектней, тут я согласен.

    Если у тебя одномерный массив дает преимущество в скорости, я предполагаю ты не используешь фреймворк и всю работу по обновлению сцены делаешь самостоятельно, верно?

  16. Без лестниц вообще нельзя попасть на другой этаж будет )

    Свой фреймворк я тут вообще не использую. Весь код написан без участия моей системы.
    Слишком уникальная задача.

    Когда пойдут интерфейсы, тогда моя система покажет себя во всей красе.

  17. Без фреймворка тебе разве не сложно будет управлять всем кодом? Я раньше программировал в Flash5/6, можно даже сказать в веб пришел именно через него. Но позже переключился на РНР и вовсе отказался от Win32 разработки.

    А вот на счет блога, я написал 5 статей: https://html5-game.ru/ начиная от идеи, заканчивая обдумыванием цели, придумыванием низкого порога для игрока… завтра планирую уже написать программу для подготовки рабочего места (в планах было сегодня, но как ты и писал, мелкие детали в конце всегда отвлекают) и разбора фреймворка в котором буду все реализоывать.

    Если будет время, можешь указать на ошибки или дать совет, что бы я в третий раз не наступил на теже грабли. У тебя опыта больше, и ты не должно быть сложно представить весь проект. Спасибо!

    Думаю марафон можно считать открытым? Управимся за месяц? =)

  18. Я не совсем понял, ты хочешь допилить/переделать уже существующую или сделать новую?

    У тебя получается не игра, а геймифицированная обучающая программа.

    У игр есть спрос по умолчанию, а тут уже могут быть сложности. ))
    Оцени сколько установок у аналогичных карточных программ. Если ни у одной нету и 100000, то ниша вообще не востребована.

    С другой стороны, игры — это «баловство», а обучающая программа — это «по взрослому» это можно будет использовать при попытках получит бесплатную или недорогую рекламу в тех же ВК сообществах, по изучению языка

    Большая проблема в том, что игра рассчитана на русскую аудиторию. Это в 10 раз сокращает потенциал.

    Вижу потенциальную проблему в самих карточках. Точнее в их количестве. Сколько там слов? На каждое слово арт? Сколько это будет стоить? Оправданны ли эти затраты?
    Я бы не рискнул делать первым проект, опирающийся на арт, да я даже сейчас имея в распоряжении и художников и деньги на них делаю игры с бОльшей нагрузкой на меня, на геймплей. А по арту экономлю (как минимум из соображений ограниченной памяти на телефоне, хотя я точно не знаю какова ее граница, может она в 10 раз больше используемого мной объема и я зря ограничиваю объем арта)

    Но если арт уже есть и его объем не вводит устройство в ступор, то тогда тут нет никаких проблем, наоборот слабая сторона (необходимость большого количества арта) превращается в сильную. (наличие большого количества нужного арта)

    Так же вижу проблему в заработке.
    В именно игре можно наставить кучу мест, и заставить игрока каждый день на протяжении месяца смотреть рекламу по 10 раз. Сколько раз у твоего игрока возникнет потребность в просмотре рекламы за все время, что он играет? Сколько в день? Сколько за игровую сессию?

    Если ты хочешь именно свою обучающую программу, то конечно делай ее.
    Если хочешь влиться в индустрию и сменить направление деятельности, то надо придумать более «игровую» игру. Если сделать Idle/Clicker то установки будут точно. Я этот жанр изнутри знаю и сам его фанат. ))

    Мне со стороны (чего уж скромничать) успешного разработчика кажется, что главная ошибка начинающих взрослых игроделов, в том, что они смотрят на игру, так же как на нее смотрят игроки. Нет, на игру обязательно надо уметь смотреть, как на нее смотрит игрок, но надо смотреть и как разработчик. Игрок видит что в игру можно играть неделю, месяц, год, два. Но игродел в большинстве своем не создает контента на месяц. Он распределяет уже имеющийся, чтобы игрок играл в игру месяц. В идеале один и тот же контент подается игроку под разным углом много раз.
    Частный случай контента создаваемого «на один раз» — это уровни в логической игре. Хорошо, конечно, когда в игре есть разные уровни. Нет ничего плохого в том, что часть контента используется 1-2 раза. Например обучение используется один раз. Плохо (для разработки), если уровни это главный контент и тогда получается что вся игра одноразовая. И даже если игрок найдется, то после прохождения игры его больше ничего держать не будет. То есть затрачено много сил, а выхлоп будет маленький.

    С другой стороны уровни создают цели и разделяют процессы. Так, что плюсы и тут можно найти. Но повторюсь, если каждый уровень приходится делать уникальный контент, то нерационально. Но если карточки уже есть, то все эти рассуждения не актуальны. )

    ___
    По срокам. Мы получается делаем самую сложную нашу игру. Неправильно надеяться, что она будет сделана за месяц. Уже прошло 8-10 дней очень активной работы, а у нас еще только процентов 10 сделано.
    Если у тебя нет картинок карточек, то ты тоже не можешь быть уверенным, что они будут через месяц.

    Если карточки есть, то да ставь месячный срок. Лучше немного сорвать срок, но работать активно, чем заложить пол года, 5 месяцев ничего не делать и потом за тот же месяц пытаться успеть и в итоге тоже не успеть.

    Если переживаешь, что какой-то странный марафон получился с разными сроками ))) То с моей стороны можно ожидать полный прототип с ограниченным содержимым. (это как если бы ты сделал свой проект на 10-20 карточек)
    Думаю тут можно ставить на месяц.

    Все, побежал работать. А то уже 7 утра, а за сегодня ни минуты ни сделано.

  19. «Без фреймворка тебе разве не сложно будет управлять всем кодом?»
    Про это не понял. Может мы немного разные вещи называем фреймворком ))

    Я под фреймворком подразумеваю свои классы, связанные с интерфейсом, отображением, сценами. Основное что я пишу сейчас это логика. Если говорить о графике, то сейчас тут одна сцена, нет интерфейсов, и нестандартное построение картинки для отображения.

    Свои классы я буду использовать там, где задачи более стандартизированы (зеленые кнопки — это мои классы)

  20. Спасибо за развернутый ответ. Все верно, первые попытки можно считать прототипом. Это не совсем игра, но я рассчитываю за этот счет удерживать игрока.

    Я вчера поиграл Башню — понял, я слишком мягко приподношу рекламу… Это же надо три раза просмотреть рекламу, только что бы понять что надо делать в игре 😀 (хотя по мне он больше на менеджер ресурсов похож) Не говоря что я вчера за вечер восем раз рекламу посмотрел добровольно и еще один раз сегодня утром насильно 🙂

    В целом ты задал верный вопрос: куда пихать рекламу? У меня сейчас рекламу можно предложить за бонусы сердечек и времени на экзамен, но экзамен это попытка перейти на след уровень, это не часто происходит, раз в несколько суток (но попыток может быть много). С другой стороны появилась новая мысль сделать «power bar» — к нему часто прибегаю игры, что бы ограничить количество сессий игр в сутки. Он автоматом наполняеться за время и вот тут можно за рекламу его наполнять. Относительно просто реализовать и должно вписаться в процесс. За игру (в зависимости от результата) восстанавливать «силу». А раз экзамен игрок будет сдавать много раз то и сила быстро будет тратиться, так что придеться смотреть рекламу.

    А какие у тебя еще предложения? Как вставить просмотр рекламы?

    На счет арта ты правильно предположил, он уже есть, я его два месяца медленно рисовал (точней художница). Обошлось не очень дорого, так как я подбирал для каждого слова иллюстрацию, которую художница использовала при отрисовке.

    Программа расчитана сразу на 7 языков, НО есть проблема… среди него нет АНГЛИЙСКОГО. А это самый крупный и платежеспособный маркет.

    «это можно будет использовать при попытках получит бесплатную или недорогую рекламу в тех же ВК сообществах, по изучению языка» писать в личку и просить сделать бесплатный пост об обучающей игре?

    п.с. в принципе то что ты описал это тоже фреймворк, но наверно фреймворк кликер игры (о таком облегчении труда я даже не думал :)), я про графический… у тебя ведь хомяки бегать будут, а это анимация и не простая

  21. С силой нормальная идея.
    Можно попробовать сделать половину игры платной. Заодно сделать, чтобы покупка отключала рекламу.

    7 языков?
    То есть есть возможность учить английский на семи языках и английского нет, потому, что бессмысленно учить английский на английском? ))
    Если у тебя несколько языков и переводы привязаны к карточкам то и сделай для каждого языка семь языков. Вот и на английский рынок сможешь зайти.

    Как быть с ВК не знаю. Я пока сам этого не делал. Наверное все же не просить «сделать» пост, а просить чтобы разрешили опубликовать, а то делать то лень будет.

    Что касается анимации она не представляет для меня никакой сложности. Я ее добавляю буквально двумя строчками, все остальное или делает ранее созданный код. Или делает художница, которая собственно анимирует.

  22. У других языках проблема АУДИО. Я для английского три мужских и два женских голоса записал, а использую только один. Со звуком много возни 🙁

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Спoнcopcкиe ссылки