По итогам прошлых частей у меня 39 часов 45 минут. И объем 158кб
Сроки немного пугают. Ожидалось что к 40 часам будет уже что-то играющее, но проект оказался слишком трудным. Впрочем теперь уже поздно что-то менять, да и не надо ничего менять. И этот осилю.
Продолжаю работу над менеджером.
Смог предусмотреть довольно запутанную логическую ошибку. Опыт )))
Когда мы оцениваем количество свободных ячеек на складах, то у этих ячее изначально свободный тип. Но когда эта ячейка бронируется за каким-то предметом, то тип сменится. В каждой ячейке десять мест. Так вот пустых мест может быть только одно, и уже потом, после того, как ячейка примет тип предмета, ее можно учитывать, как ячейку содержащую десять мест. Потому, что если мы изначально зададим десять мест с свободным типом, то на одну ячейку могут в итоге прийти предметы разного типа. А это ошибка.
Уже 43 часа. Я все еще пилю менеджер задач.
Медленно(хотя как медленно, файл весит уже 21кб)
Но верно. Время потраченное на рефакторинг поиска пути оправдывается. Часть задач требует A*, часть требует широкий поиск. И главное не запутаться где какая задача и какой поиск, почему ей нужен поиск именно этого типа, и куда потом девать его результаты.
Так и не смог допилить к ночи. На следующее утро сразу включился в код, разобрался с вчерашними затруднениями (вот что значит здоровый сон) и продолжаю его пилить.
Внезапно понял очевидную вещь. Не обязательно обсчитывать все задачи, которые есть в игре. Нужно лишь обсчитать первые Х, по количеству свободных хомяков. Оптимизация ))
Хотя есть и проблема. Как одновременно совместить приоритет задач и при этом давать хомяку задачи ближние к нему. Да всякие коэффициенты можно придумать, но это опять переписывать коды… Надо подумать.
Нужно менять порядки расчетов для случаев когда хомяков больше чем задач, и для случаев когда хомяков меньше чем задач.
Когда хомяков больше чем задач, то задача выбирает ближнего хомяка.
Когда хомяков меньше чем задач, то хомяк выбирает ближнюю задачу.
Блин я еще прежний вариант не допилил, а уже усложнил идею (((
Решил для начала реализовать то, что наметил, потому, что усложнение ни капли не отменит существующий код, а только дополнит.
И в итоге на 45 часу хомяк сам выполняет задачу! Ну наконец-то!!
Правда осталось еще разобраться с бронированием, порядком отображения некоторых слоев и вообще во время тестов вылезли какие-то неожиданности, но в целом разработка двигается вперед.
Разобрался еще с несколькими вещами, хотя и довольно мало работал на выходных
И по итогам 47 часов и почти ровно 200кб могу показать вот это.
Хомяк обнаруживает, что есть коробка до которой он может дойти и которую он может донести на (пока что невидимый) склад.
Автор: Elsper.ru
Elsper, а под какие платформы будешь эту игру адаптировать? (или под одну платформу?)
Я делаю под мобилы. Может быть будет повод попробовать стим, если пойдет.
Веселая графа у хомяка)))
>> Сроки немного пугают. Ожидалось что к 40 часам будет уже что-то играющее
Если я правильно понимаю, то движок у тебя уже готов, алгоритмические трудности разрешены, теперь осталось только игровую механику реализовать, ну и всё сопутствующее ей, то есть самое сложное позади.
Да, даже если и вылезут еще алгоритмы, думаю самая сложная часть позади.
Ну если только что-то принципиально иное и сложное не захочу прикрутить.
выскажи плиз свое мнение по поводу swift.
Тем более, что google уже давно объявил, что swift заменит java на android и станет основным языком.
Имеет смысл сейчас серьезно взяться за swift?
ps юнити, ксамарины и постпроцессоры (тем более с js) для себя отверг сразу, тк игры — не профильное. есть желание довести хотя бы одну игрушку до конца, но нет желания разово разбираться с фреймворком (платформой, библиотекой — не суть).
У меня нет мнения по swift
А почему бы тебе задания не добавлять в пул… и постепенно выполнять в той же последовательности. Хомяки тоже могут быть в пуле, берем первого свбодного, потом первое задание давай вперед =) Если данных хомяк не может выполнить это задание проверяем следующее в списке задание (если такое может произойти), если ни одно из заданий он не может выполнить, то переносим хомяка в конец списка и берем следующего, повторяя логику. Так у тебя будет ОДНА логика на все три случая.
Потому, что может возникнуть ситуация при которой точка входа в задание на первом этаже, а хомяк, который его берет на пятом, а следующее задание на пятом этаже, а хомяк, который его берет на первом.
Это совсем неправильно и будет очень раздражать, и я сам бы поставил такой игре единицу )))
Я хочу наоборот еще больше усложнить алгоритм.
То есть, предположим вариант один хомяк на десятом этаже, один хомяк на первом этаже и у нас есть две задачи на первом этаже. Так вот будет быстрее если нижний хомяк сделает обе задачи, чем если одну из задач возьмет на себя хомяк с десятого этажа. Я знаю как это сделать, хотя пока не реализовал.
Тогда у тебя должен быть расчет заранее сколько уйдет времени на выполнение задания. И тут уже поиска оптималмьного распределения задач, одновременно для всех доступных хомяков… я не знал что у тебя будет многоэтажное здание. Тогда самое простое это все же масив в двух измерениях 🙂
п.с. У меня сегодня наконец реальный код пошел, разбирал как через Phaser собрать составную кнопку с прогресом (у меня на главной их три). Возникли сложности с вертикальным позиционированием (из за шрифта), надо будет подобрать шрифт с цифрами на всю высоту линии, либо что бы по центру были, или заменить на растровый шрифт. Пока не решил что лучше
Время на выполнение — это просто длина маршрута ))
Оно не только многоэтажное, оно еще и имеет глубину на каждом этаже. Поэтому я писал о поиске в трехмерном пространстве.
Да начальные технические нюансы, конечно, утомительны )))
Ну после первой кнопки, следующие уже просто по образцу пойдут. )
Я у себя просто рассчитываю высоту текста и дальше позиционирую без проблем. А вообще за каждым пикселем гнаться не обязательно, конечно.
Ну или шрифт нормальный выбрать. Иногда никакие расчеты не помогут, если шрифт неудачный.
// по поводу swift
есть два варианта хороших
Java + LibGDX (кроссплатформа, можно тестить на десктопе прототип или вообще параллельно пилить под 2 платформы — пк и мобилки)
phaser.io — это javascript и web, но заточено так, чтобы и на мобилках отлично работало.
swift на Андроиде никак
у Phaser’а и ему подобных производительность гумно т.к. на выходе не натив
Вместо Phaser лучше Gideros, шустрые нативные приложения на выходе
только по Gideros мало туториалов и готовых модулей, приблуд всяких
Надо было тебе изначально про это сказать в первых постах или я упустил? Теперь понимаю почему ты сказал, что хомяки это не простая игра. Если оставлять двухмерный массив, я полумал можно ввести три типа комнат: просто комната, комната с лестницей справа, комната с лестницей слева. Это позволит иметь двухмерный массив и легко рассчитывать путь (известно до какой клетки надо добижать, что бы пробижать еще пол клетк и начать спуск по этажам).
Жека — про доки Phaser-а я сегодня планирую написать. Не смотря на то что она есть, зачастую пользы от нее ноль.
Спасибо за информацию.
По swift и андроид сейчас — я в курсе. Но тем не менее заявление от google есть, что swift станет первым языком.
По Java + LibGDX — почитал. Очень интересный вариант.
Вот по поводу js — сомнения. Хотя js как раз знаю (на уровне web, простенькой анимации, промисов, работы с html5 — аудио, видео). Но javascript мне сам по себе неприятен. Стараюсь по минимуму только для web использовать.
Если есть идея 2D игры и даже графика уже нарисована и алгоритмы продуманы, то на чем все же быстрее будет реализовать? На Gideros или Phaser или LibGDX (java тоже на базовом уровне, примерно как и js).
// у Phaser’а и ему подобных производительность гумно
Чувак, ты не над той производительностью думаешь. Думать над над своей производительностью. В Phaser очень быстро набрасывается игра, запускается и тестится, тонна документации и туториалов.
Во-вторых, ты там 3D шутер что ли собрался делать? Или семь тысяч юнитов в RTS? У меня для тебя плохие новости — производительность самой игры будет последним, что будет тормозить твой проект в создании )) А вот для идл кликеров, ферм и 2хмерных рогаликов производительности Фазера более чем достаточно
// javascript мне сам по себе неприятен
Может быть, проблема в том, как пишут код в туториалах по нему — одним файлом, запутанно, лапшой? Пиши классы в отдельных файлах, дроби по максимуму, будет легче.
Согласен, что после языков с типами и строгой структурой на этапе компиляции JavaScript, в котором можно создавать поля и методы в объектах, кажется макаронным адом.
По Java + LibGDX — что могу сказать? Несомненный плюс — ты после этого фреймворка всегда сможешь в любой момент уйти в Джависты-программисты на хлебную работу. Ибо Джава.
Минусы — очень много возни, типичной для Джавы. Возни около самого программирования, понимание системы сборок, настройки проектов. Я после простых Флеш-игр просто охреневал от лишних и ненужных (кажущихся ненужными) действий, которые нужны для разработки под Java и вообще современные крупные фреймворк.
// Если есть идея 2D игры и даже графика уже нарисована и алгоритмы продуманы, то на чем все же быстрее будет реализовать
Надо смотреть, какие возможности предоставляет фреймворк. Простой кликер-ферма все-таки очень быстро тестируется на Phaser. Да даже то, что Эльспер сейчас с хомяками пытается замутить — может вполне работать как веб-игра на этом движке. Там сейчас очень серьезные подвижки в плане оптимизиции быстродействия графики и будут еще больше, когда WebAssembly будет захватывать браузеры
Эльспер, извини за такой поток комментов.
Просто хочу сказать спасибо пацанам за наводку на Gideros. Люблю изучать новые фреймворки и этот выглядит крутым (по лендингу, ха-ха).
Огорчает лишь тот факт, что он разрабатывается давно, а известен не так широко. Значит, есть какие-то подводные камни, возможно, косяки у самой команды, поддерживающей проект. Я так недавно с Overlap2D напоролся — искал хороший редактор сцен для LibGDX, Overlap2D выглядел просто отлично — вах! — но….
1. вывода для HTML5 движков нет (заявлено, но сдохло в стадии эмбриона)
2. сайт в последние дни сдох и не отзывался
3. документация — очень мало в текст, все в виде ебучих ютуб-роликов. И опять же, что есть — все на сайте, который лежал или еще лежит в дауне.
Боюсь, как бы с Gideros чего подобного не вышло.
Все-таки популярный фреймворк — это и большое количество возможностей, и большое количество знаний. А по поводу оптимизации производительности, пацаны, я все-таки считаю, что
а. средний комп растет в производительности быстрее, чем сам разработчик игры
б. для кликеров, ферм, простых мини-игр приносящих бабло — достаточно даже сраного Canvas. Не гонитесь за технологической скоростью, ищите, как увеличить скорость свою. А для этого нужны доки, инструменты и другие разработчики — как можно больше. И их дают чаще всего популярные фреймворки.
ВитринныйКапчеРобот ты выше такой комент оставил, что у меня закралось подозрение, что ты кодишь или кодил в Phaser-е… а также вижу ты упомянул ключевое для меня слово «редактор сцен», можешь что-то посоветовать? Я пока смотрел Phaser Editor, MightyEditor, Tiled но как-то пока не определился. Спасибо!
Советовать особо не могу — редакторы сцен стал щупать только недавно, когда выросла работа по верстке экранов. Пока позиционирую в коде.
Если не определился — пробуй все )
Вижу лишь такие недостатки, что MightyEditor только онлайновый, а Phaser Editor потом попросит 75 баксов через две недели.
Tiled бесплатный и у него есть рецепты внедрения сцен под кучу фреймворков-языков. Для LibGDX (это моя основная работа), скорее всего, выберу Tiled.
PS: безусловный плюс MightyEditor или Phaser Editor — то, что они сразу ориентированы на работу с движком и генерят готовый код.
В Tiled ты отдельно редактируешь карту-уровень, а затем отдельно еще надо её как-то внедрить в свой код. Универсальность тормозит.
Если бы работал только на Phaser, однозначно брал бы Phaser Editor или Mighty.
«Эльспер, извини за такой поток комментов.»
Да я не против. )))
Поправлю только вот тут: «с хомяками пытается замутить» не «пытается», а делает )))
ВитринныйКапчеРобот спасибо! Дело вот в чем, код я пишу на JavaScript 6 а не 5. Причину я у себя на блоге в 7 части подробно описал, но в двух словах: возможность писать классы, наследование и импорт кода из другого файла. А в редакторах JavaScript 5.
Про Tiled буду писать сегодня. Он мне подходил пока я планировал делать сложные компоненты игры через спраиты. Но я позже сообразил что если использовать спраиты вместо группы, придеться использовать битмап, на который буду все рисовать, а его уже непосредстеввно на спраит. А в таком случае будет сложно реализовать анимацию отдельной части (в последней части есть ссылка на игру, точней ее состояние на данный момент). Но может я пока не знаю чего то?
В Tiled нет возможности добавить группу на место tile, можно только кастомный спраит. А ты вот составную кнопку делаешь спраитом или все же группой? (у меня там фон, секция с уровнем, иконка, и анимированный прогресс)
Элспер я немного продвинулся, полу анимированное меню сделал 🙂 http://html5-game.ru/chast-9-igrovye-sceny-v-phaser-i-zachem-oni-nuzhny/ ссылка на игру в конце. Хорошо что послушал тебя и не стал пока тратить больше времени на позиционирование числа в кружочке.
После поста (отчета) сегодня, буду переделывать… во первых есть мысль как решить проблему с неровным шрифтом (обрати внимание на число уровеня для умения), а также буду делать новый класс для автоматического равномерного расположения компонентов внутри него, этакая «панель».
Но есть мысль использовать физику и жесткие связи, что бы интерфейс как бы собрать в один физический объект. Как это делать Android Studio или Swift для интерфейсов. Это даст возможность проще перемещать отдельные части при другом расширении или если попытка провалиться, сделаю как ты советовал: полосками
Меню выглядит симпатично. цифрам легче мне кажется просто добавить несколько пикселей при позиционировании, если это возможно технически.
Запускал с телефона. Оно не масштабировалось, но думаю, это нюансы о которых ты итак знаешь.
Спасибо, про порцию пока не разбирал. Вроде в Phaser она автоматическая, но надо будет проверить. Сегодня еще два поста отчета сделал по поводу создания собственных prefeb-ов и проблеме с centerX/centerY у групп (больше похоже на баг), но забирает много времени.
Завтра в планах анимировать кнопки внизу экрана (хочу что бы при выборе навыка, нижняя полоска с доп кнопками настроек, топ и т.д. уезжала вправо, а слева въезжал текст с кратким описанием навыка и кнопка со стрелкой для запуска). и если повезет, cгенерирую простой bitmap шрифт для 10 цифр. что бы они по центру были…
Элспер, у самого желание просто опустить текст на несколько пикселей, но рука не подымается =)
А как у тебя продвижение с хомячками или если быть совсем точным, с их анимацией? Очень интересно как это будет выглядеть. Когда будет готов скелет в программе, сделай скриншот, очень интересно посмотреть =)
«А как у тебя продвижение с хомячками или если быть совсем точным, с их анимацией? »
Анимацию хомяков я попросил делать в конце разработки, чтобы сейчас направить силы на более фундаментальный арт.