Публичная разработка игры. Часть 9. С гифками игрового процесса.

Продолжаем. Прошлая по ссылке

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

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

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

Гифка

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

Работаем дальше.

Еще спустя пол часа и после исправления пары мелких ошибок хомяки приносят ресурсы к готовому рабочему столу на переработку. Теперь надо заставлять хомяка самого вставать за стол и работать.

Начал думать над этой задачей, и понял, что там снова целый крупный пласт работы.

___

78 часов 40 минут

Столы теперь стали полноценными рабочими местами.

81 час
414кб кода

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

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

 

 


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 5.3/10 (6 votes cast)
Публичная разработка игры. Часть 9. С гифками игрового процесса., 5.3 out of 10 based on 6 ratings

30 thoughts on “Публичная разработка игры. Часть 9. С гифками игрового процесса.

  1. Elsper, так и не пойму, как будет игра выглядеть окончательно, процесс геймплея? Это типа кликер, но чуть попродвинутей?
    Есть какая-то подобная на google.play, на которую ты ориентируешься?

  2. Это не кликер.
    Это полноценная экономическая стратегия.

    В чем-то это немного похоже на «Knight and Merchants» и «Banished». Там люди тоже носят ресурсы, работают на рабочих местах, и потребляют ресурсы (у меня хомяки будут еду кушать, как минимум).
    Но это компьютерные примеры. А мобильных подобных не знаю.

  3. Шикарно продвинулся Элспер!

    1) А ты в какой программе эти гифки делаешь? А то мне в лом выкладывать программу при каждом обновлении, да и гифки смотряться намного наглядней =)

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

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

    Спасибо

  4. Про техническую сторону интересно было бы узнать. На чем ведется разработка и т.д.

  5. Выглядит здорово! Сколько, по твоим оценкам, часов работы ещё нужно? Предыдущие посты читал и оценки видел, но сейчас кажется, что доделывать осталось меньше, чем ты писал там.

  6. Андрей,
    да продвинулся, хотя ожидал даже чуть побольше.

    Программа LICEcap маленькая и достаточно удобная.

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

    Что касается данных для сцен, у меня просто есть классы в которых хранятся все переменные и описаны они как public static и обращение к этим переменным доступно из любого места программы. Или JS настолько недоязык, что не поддерживает таких вещей?

  7. Some, уже неоднократно говорил, пишу на флеше.

    AS3 (язык) + adobeAIR(это дает выход на мобилки) + Starling (дает выход на GPU)

  8. FinReader, последняя оценка была 80-130 часов. Так, что вниз мне точно корректировать не надо ))

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

  9. Да нет, в JS можно создать глобальный объект, но я думал может в играх есть спец поход для хранения данных. Мне пришлось использовать глобальный объект впервые в Android Studio, там по другому данные между экранами и не передаш.

    На счет программы спасибо. Я вот еще не могу найти у тебя на блоге… помнишь ты мне говорил формулу по расчету роста цены. Там была константа, но в добавок использовалось значение из предыдщего числа… где-то в коментах, ты не помнишь? или кинь формулу повторно… я хочу штраф за не правильный ответ сделать по геометрической прогрессии…

  10. Сделал по формуле: штраф(n)=штраф(n-1)*0.95. Как раз то что нужно, три ошибки и пользователь не зарабатывает с уровня, еще гесть ошибок и он на минимальной прибыли. Вроде все готово, ща буду сохранять прогресс и можно показывать 🙂

    п.с. В Phaser нашел еще одну ошибку с scale-ом, а также пришлось усовершенствовать события touch, что бы оно не срабатывало при swipe жесте

  11. Сегодня написал первые строчки следующего поста.
    На данный момент 88 часа. Думаю пост буду публиковать ближе к 95.
    Много мелких правок и ошибочек, так, что ничего конкретного пока не добавилось.

  12. Привет Элспер, как продвижение? У меня сегодня выходной… больше недели выдержал сумашедший график, но последние дни начала потеть шея и затылок. Думал кондиционер глючит, а как оказалось часть мозга отвечающая за логику и воображение переутомилась и на грани работает. Так что решил один день выспаться (а то спал от 4 до 6 часов), кушать и смотреть развлекательные программы (про японию хорошее обновление у «мир на изнанку», раньше «орел и решку» смотрел, но они скатились на уровень бессмысленно дорогой еды и отеля, информации ноль).

    Как ты и писал раньше, даже когда все с виду сделано, много мелких задач, багов, недочетов проектирования игры. Сейчас перехожу к мини игре правда или лож, которая будет давать игроку утомительно НО бесплатно восстанавливать силу. Дизайнер уже отрисовала эту сцену, мне нравиться на 80%, но лучшего решения я и сам предложить не могу.

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

    Ты сам Элспер как делаешь сложные панельки? Собираешь их программно а в своем визуальном редакторе только позиционируешь контейнер?

  13. Привет.
    Я на этой неделе работал преимущественно над другими играми.
    По хомякам только +полтора часа сделал.
    А так-то я работаю горааааздо меньше тебя. Для меня 2 часа в день норма. А если 3-4, то уже совсем молодец получаюсь ))

    По сложным панелькам не совсем понимаю.
    У флеша структура такая. Есть класс спрайтов(их можно при желании назвать контейнерами) и есть класс просто картинок (они могут обрабатывать нажатия и превращаться в кнопки)
    В моей системе сцена = спрайт. А картинки — они и есть картинки.

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

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

    > А так-то я работаю горааааздо меньше тебя.
    Это я очередной эксперимент провожу. Отправил жену на отдых, а сам решил проверить как это отразиться на продуктивности. Из за того, что мне не с кем разговаривать, работаю офигенно много НО через неделю такого ритма появились боли в затылке, от напряжения =)

    На счет составного элемента, вот у меня есть кнопка: https://www.screencast.com/t/dzaqQPaY Она составная: фон, иконка и звездочки. Сейчас сама кнопка собирается программно из трех картинок. Место каждой картинки заранее известно относительно центра кнопки. Визуально (в Tiled редакторе) я позиционирую только фоновое изображение (так как цельное изображение кнопки генерируется программно): https://www.screencast.com/t/zB2SslXWX Фактически визуальный редактор мне помогает указать координаты и размеры будущей кнопки. Но если надо что-то поменять в самой кнопке, то надо менять сам код генерации кнопки. Вот это я считаю не правильным!

    Любая графическая среда разработки программ, позволяет добавлять на сцену (форму) не просто фото или текст, а объект любого класса (созданный разработчиком). А вот все редакторы сцен умеют только добавлять фото или текст. Если я соберу кнопку как отдельные картинки, то при scale будет ошибка… так как размер будет меняться только у одного фонового изображения кнопки.

    Теперь споилер моего следующего поста, который написал вчера но не хватило сил отредактировать и опубликовать:

    Хотя я и сэкономил много строк кода на генерации элементов сцены, но все равно… я считаю моей работой должно быть только создание карты в JSON формате, а все остальное должен делать код на автомате. Я не должен тратить время на написание класса для сложных элементов интерфейса.

    По этому Элспер, я подумал, а что если каждой картинке или тексту задать в редакторе parent_id, а при генерации сцены программно, проверять наличие такого свойства у картинки и при необходимости ее как child другого изображения. Тогда я могу в редакторе переместить картинку звездочки в кнопке, а код автоматом обновится и не надо писать класс для каждого сложного элемента интерфейса.

  15. Нее отдых не получился… вечером решил пару часов покодить и затянуло. Вот как тебя в свое время когда ты себе редактор делал =) Вроде новый алгоритм кодинга оправдал себя, зацени Элспер. Вот как все выглядит визуально:

    https://www.screencast.com/t/enTH6rfbyG

    Вот все работает, кнопки нажимаются, прогресс анимируется:

    http://html5-game.ru/wp-content/uploads/chapter-32/new_code_method_demo.gif

    А теперь самый прикол, вот весь код:

    this.button_false = this._create_group(stage_map, ‘false’, ButtonGroup);
    this.button_false.onTap.add(function() {
    this.power.progress = this.game.rnd.integerInRange(0, 8);
    }, this);
    this.button_true = this._create_group(stage_map, ‘true’, ButtonGroup);
    this.misc = this._create_group(stage_map, ‘misc’);
    this.power = this._create_group(stage_map, ‘power’, PowerProgressGroup);
    this.card = this._create_group(stage_map, ‘card’);
    this.menu = this._create_group(stage_map, ‘menu’);

    Пришлось всю генерацию на базе JSON файла делать самому. Хоть и ушло несколько часов пока все заработало как надо, но весь код генератора это строк 20-30 не больше. Правда пока не удалось понять, почему при использовании textbounds на тексте, появляется баг при anchor 0.5 (без textbounds все грамотно ресаизится по центру)

    Теперь назад к моему вопросу, вот если тебе нужно потом анимировать две картинки кнопка и икона на ней, как ты это делаешь? Или Flash автоматом делает линк между ними и все пропорционально меняется?

  16. Это все видимо какая-то специфика языка/платформы/фреймворка.

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

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

    А больше ничего особенного.

  17. Офигеть, вот везет же людям 🙂 Я вот аналог спраита, в котором все сразу пропорционально двигаеться или уменьшаеться пытаюсь у себя найти в фреймворке. Можно одну картинку добавлять в виде child и тогда работает как спраит у тебя, вот только приходиться делать программно. Вчера написал свой обработчик карты, который не просто создает новую картинку, а именно добавляет ее в виде child. Все почти прошло гладко, но вот текст у них позиционируеться с изменением координат системы, что автоматом меняеться при scale 🙁 и текс уже не верно позиционируеться при масштабировании. Вот почему надо писать в крупных фреймворках, там такие ошибки уже исправлены (я конечно все исправил, переопределив функцию позиционирования, но ведь ушло несколь часов на А/Б тестов пока нагел источник)

    Про технический спраит: у тебя есть метод выравнивания содержимого по сетке, верно? А также такой класс поддерживает прокрутку

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

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

  18. Спрайты, кстати, по сути и реализованны как контейнер для child.
    Чтобы добавить объект на спрайт я так и пишу addChild();

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

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

  19. Элспер, можно не скромный вопрос? Можешь показать как выглядит главная игровая сцена в твоем редакторе? Мне хочеться поеять, где проходит грань между ручном и автоматическом создании картинок и спраитов.

    Я постарался сделать так, что бы визуальный редактор генерировал мне расположение картинки или текста (и хранил их уникальные свойства, необходимые для их создания anchor к примеру или размер шрифта). Чуть позже я сообразил как хранить в этом файле инструкцию объединения картинок в спрайты. Но остаеться не решенным задача с динамическими списками… стоит ли писать метод клонирования спраита и программного выравнивания? Элспер, или ты думаешь это уже перебор?

  20. Башня почти полностью вручную сделана. Только под конец для пары интерфейсных окон использовал project pencil.

    По конкретным советам не знаю. Повторюсь, тут многое видимо зависит от технологий.

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

  22. Могу тебя заверить Элспер, свой движок я не делаю и старый код не меняю =) Просто осбираю для себя опыт и каждую сцену делаю новым способом. Сцену игры кстати закончил всего за полтора и весь код это реальн код игры. Как ты правильно заметил, из за специфики среды разработки и из за отсутсвия опыта, изначально у меня много времени ушло на решение простых задач.

    Игру фактически закончил, сейчас уже с дизайнером работаем над инструкциями… а я пока добавлю два других режима: произношение и правописание. Но тут снова техническая проблема… сцена изучения слов и произношения на 80% идентична, мне просто продублировать код и внести правки или все же вынести функционал в отдельный файл и использовать в каждом из навыков?

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

  23. «Но тут снова техническая проблема… сцена изучения слов и произношения на 80% идентична, мне просто продублировать код и внести правки или все же вынести функционал в отдельный файл и использовать в каждом из навыков?»

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

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

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

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

    На счет опыта не надо Элспер, я его оцениваю не количеством времени а результатами. Вот у тебя запущена не одна игра и они дают результат. Ты можешь содержать жену и жить в Таиланде, а какие у кого еще вопросы? =)

    Вообще скажу словами Ходжи Насредина — сыт не тот, кто больше времени провел в чайхане, а тот кто больше съел =)

  25. Жена столько труда вносит в общее дело, что сказать что я ее просто содержу у меня язык не повернется )

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

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

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