Создания гибкого менеджера порождающего игровые объекты

Alexmody · 06.01.2011, 22:19

Перешел с компиляции FlashIDE на компиляцию в FleshDevelop, в связи с чем, полностью изменился подход, графика отдельно в swc, и на каждый граф объект вешается обертка (wrapper/decorator).

Встала задача создать эффективный менеджер парсинга графики из swc и создания объектов оберток.

Начал смотреть в сторону порождающих паттернов: Abstract Factory, Builder, Factory Method, Prototype и пр. Но изучить их и применить для решения данной задачи не так то легко, т.к. только начал изучение.

В общем виде, в Flash IDE создаются уровни игры, т.е. расставляются по местам граф объекты, задаются имена и сохраняются с именами/классами Level1, Level2…. и далее экспортируются в swc библиотеку.

В FD я не наследую классы от графики swc, а просто создаю уровни level1 = new Level1(); и далее перебираю клипы внутри уровня или обращаюсь по имени getChildByName), создавая для каждого граф. подобъекта уровня свою обертку.

Подскажите, какие паттерны/приемы/схемы вы используете для создания гибкого менеджера, который парсит swc и вешает обертки граф. объектам для анипулирования игровыми объектами?

mayakwd · 06.01.2011, 22:37

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

данные о графических объектах брать из библиотек описанных в картах ресурсов.

Psycho Tiger · 07.01.2011, 00:16

Цитата:

Подскажите, какие паттерны/приемы/схемы вы используете для создания гибкого менеджера,
который парсит srс и вешает обвертки граф. объектам для манипулирования игровыми объектами?

Мне вот конкретно очень тяжело в таких случаях понять - круглая ли форма у объекта или квадратная. Можно давать разные имена, типа circle1, circle2, square1... Но как-то это дело костыльно.
Дело тут в том, что придется перекомпиливать всё это дело по велению геймдизайнера, но что хуже это даже менее удобно: если не надо отображать все объекты разом, придется это дело перед началом игры забивать в память. Вариант mayakwd один из самых разумных.

Division · 07.01.2011, 00:27

Насчет формата - рекомендую yaml. Спрыгнул на него с XML - доволен очень (:

fljot · 07.01.2011, 05:24

Недавно обсуждали это, и я не вижу смысла "полностью менять подход" и городить какие-то редакторы и проч. Для этого и есть Flash IDE, и если оно доступно, то почему бы не пользоваться.

mayakwd · 07.01.2011, 19:46

потому, что вам придется «городить» двойную работу, помимо просто описательного процесса для каждого блока во flash ide придется еще делать дополнительную карту чтобы описывать какой блок что делает.

это чудовищный способ.

fljot · 07.01.2011, 19:56

Какую работу? Автор пишет, что у него появились проблемы из-за изменения workflow при переходе от компиляции во Flash IDE к компиляции mxmlc. Я говорю, что менять его не обязательно.

Котяра · 07.01.2011, 22:36

во первых, автору: вы имели в виду swc а не src (это констатация, а не вопрос)
во вторых, вам помогут: декоратор/мост и стратегия ну и и все остальные надцать паттернов.
в третьих - обёртка.
в четвертых: парсить swc не надо - это просто набор классов.

Alexmody · 07.01.2011, 23:40

mayakwd
>>по-моему, лучше будет написать собственный редактор уровней на основе view
Да, предполагаю, что свой редактор и xml это лучший вариант, но сейчас нет времени
его писать, к тому же с каждым новой игрой его придется значительно
переделывать.

Psycho Tiger
>>Можно давать разные имена, типа circle1, circle2, square1... Но как-то это дело костыльно.
>>Дело тут в том, что придется перекомпиливать всё это дело по велению геймдизайнера, но что хуже это
>>даже менее удобно: если не надо отображать все объекты разом, придется это дело перед началом игры
>>забивать в память.
Задавать имена в Flash IDE или еще хуже параметры в именах клипах это очень трудоемко и неэффективно
+ перекомпиляция swc при изменении имени/параметра.
Поэтому пока что в резерве вариант, где в FD парсятся левелы на наличие вложенных граф объектов и
создаются необходимые классы обертки на основе индентификаторов классов
граф объектов, что позволяет для каждого граф объекта в Flash IDE не прописывать имя/параметры.

Котяра
>>декоратор/мост
>>в третьих - обёртка.
На сколько я читал, декоратор и обвертка это одно и тоже, сначала
было название wrapper, а потом сменили на Decorator.
Спасибо, почитаю в первую очередь о стратегии и мосте.

JackFromChaos · 08.01.2011, 14:59

Цитата:

Сообщение от Psycho Tiger

Мне вот конкретно очень тяжело в таких случаях понять - круглая ли форма у объекта или квадратная. Можно давать разные имена, типа circle1, circle2, square1... Но как-то это дело костыльно.
Дело тут в том, что придется перекомпиливать всё это дело по велению геймдизайнера, но что хуже это даже менее удобно: если не надо отображать все объекты разом, придется это дело перед началом игры забивать в память. Вариант mayakwd один из самых разумных.

Все конечно сильно зависит от контекста того, что мы делаем, но....

Можно сделать несколько символов, врое circlem square и при редактирования уровней оперировать этими символами, тогда можно будет по типу символа определить тип объекта... Можно даже сделать их компонентами и задавать какие то дополнительные параметры.
Сделать, что бы программа могла подгружать swf уровни(на уровни отладочной версии) очень просто. Тогда геймдизайнер может править уровни в Flash IDE, компилить, а затем запускать основную flash. В общем все просто может рабтать....
Еще один вариант, это редактировать уровни во Flash, а потом с помощью JSFL экпорить их, ну например, в тот же XML. Тоже делается очень просто и быстро.(к примеру я так делал редактор уровней для пасьянсов)

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

Добавлено через 7 минут
Кстати, если влом разбираться с JSFL, можно предложить еще вариант:
Dev-версия работает с уровнями подгружая их из swf, в качестве редактора вся мощь Flash IDE

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