Переводы уроков про PushButton Engine
 

Всем привет.
Закончил сегодня перевод 5-го официального урока про разработку игр с помощью PushButton Engine.

Ссылки на уроки:
Урок #1
Урок #2
Урок #3
Урок #4
Урок #5

Хотелось бы услышать мнение людей о том, нужны ли вообще переводы уроков про PushButton Engine и использует ли кто-нибудь на форуме данный фреймворк в своих разработках.

Официальные доки тут: http://pushbuttonengine.com/docs/

P.S.:
Если уроки вам покажутся полезными, то буду благодарен за карму на Хабре: http://flashist.habrahabr.ru/blog/99402/

Спасибо. Только почему поместили во флейм? Может быть блог заведете?

зачем ему блог, когда есть свой сайт с уроками? =)

действительно)

Огромное спасибо за ваш труд :)
Теперь знаю, что буду читать после книжек по флексу :)

2 alexcon314:
2 Furinax:
Приятно знать, что переводы будут полезны другим людям =) Спасибо вам.

Напрягает в PBE - использование Java стайл конвенций наименований..
UPD - посмотрел доки: вроде теперь нормально именуют.. исправились что ли?
А вообще мне лично этот фрэймворк и не нужен - легче самому написать то что надо, чем разбираться в этом движке. Рамки это чаще плохо, чем хорошо.

2 Котяра:
Не работал раньше с этим фреймворком, поэтому не знаю, какие раньше принципы именования в нём использовались. Лично, что мне не нравится в фреймворке — это использование «ссылок» на свойство через строковые названия, например так: "@Spatial.position".

Что касается «написать своё», то это всегда можно, но в этом случае вы не узнаете, что уже изобретено сейчас. Мне, допустим, просто интересно, как в том или ином движке/фреймворке организована работа со страницами игры, настройкой уровней через XML и т.п.

В частности, PBE имеет один очень интересный инструмент по встраиванию внешних ресурсов через [Embed], который описывается в 5-м уроке. Не прочитав этот урок, я вряд ли когда-нибудь узнал о такой возможности.

А какое отношение тег Embed имеет к PBE?

2 Diestro:
Почитайте 5-й урок.

А причем тут 5й урок? Еще раз повторяю: тег Embed никакого отношения к PBE не имеет.

Хорошо, давайте так, вы читали 5-й урок? О чём там идёт речь?

Там идет речь о встраивании изображений посредством метатега [Embed], который к самому Push Button Engine никакого отношения не имеет.

А как этот тег PBE использует в своих целях?

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

Да =) Я сейчас перечитал своё сообщение, наверно я не очень правильно выразился, было бы правильнее сказать, «…на основе информации, передаваемой через тег [Embed]…», а не «…по встраиванию внешних ресурсов через [Embed]…».

Ну на самом деле это делается и без всякого PBE.
В чём его заслуга?
В уроке кстати не указано каким образом получать доступ к MyResource.myAsset?
Через строку? Это убожество.
В общем очень странный движок и я не увидел ни одной прикольной фичи.
например там нет:
- системы сообщений (mvc)
- динамической подгурузки с прелоадерами.
- кэширование битмап.
Всё как то на очень простом уровне..

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

Так сложилось исторически, что game-engineers не любят MVC, и вообще слишком много абстракций, которые помогают в GUI / Server-Client / Enterprise приложениях, мешаются в Game Dev'е.

Nirth, так уж сложились, что ты сейчас не прав )

Так уж сложилось, что иметь три полностью инкапсулированных абстраций, в игре не нужно =)

Добавлено через 1 минуту
Если на то пошло, то можно реализовать Delegate-Model или View-(Model+Controller) но конкретно MVC – изометрических RGP – лишнии костыли.

Nirth, так уж сложилось, что они всегда имеются. в том или ином виде. ооп не нужен для существования мвц.

Ок давай конкретизируем.

В большинстве движков ( XNA, CryEngine, Unreal Development Kit ) у нас есть 2 ключевых функции:
1) обновляет данные, может называтся – update, evaluate не суть важно, далее update
2) обновляет экран - обычно называется draw.

Update и Draw могут быть синхронизированными ( update > draw > update > draw ) или нет ( update > update > draw > update > update > draw ). Например в Need for Speed идет 3 вызова update на один вызов draw.

update вычисляет новую позицию объектов ( это может быть либо физический движок, либо AI ботов ), и записывает их куда нибудь, это может быть вектор, массив, объект.
draw считывает данные и отрисовывает.

Теперь если ты понимаешь, под MVC что, M это вообще любой способ хранения информации, а в качестве контроллера может выступать и просто процедура вроде update. То да, но если ты все же сверишься с парадигмой / паттерном MVC то, так уж получается, что ты не прав.

Добавлено через 7 минут
Если уж натягивать за уши, то вот что используется в в геймдеве – http://c2.com/cgi/wiki?ModelDelegate

2BlooDHounD - в кои то веки солидарны) хотя, я уже тоже не люблю MVC и предпочитаю в render(draw) опрашивать скопом список изменённых состояний( которые, конечно, isInvalidated)
— Папа - а я уже game-engineer? :)
но в PBE, таки, об этом всём даже и не пахнет

Котяра & Bloodhound
Я вас не понимаю, вы что под MVC понимаете, любую архитектуру, где так уж сложилось, что отображение и обработка данных не в одном месте? если так то я могу 90 если не больше софта записать под MVC, но есть точные определения. Например - Модель должна "извещать", а не просто болтаться в памяти.

Это необходимый и достаточный минимум, в моих изысканиях, я называл моделью данные(вернее их холдеры), которые просто помечались изменёнными. Контроллер (в частности функция render) - просто проверяет эти изменения - это по сути отложенные сообщения, просто приходят не телеграммы, а посылки раз в неделю, за которыми надо заходить)
Здесь немного потеряна связь модель - вид, но в классике MVC вид тоже не сам изменяется - его меняет контроллер.
Вообщем, МВЦ - это как минимум разделение данных, чего в 99% случаев достаточно.

Котяра, у тебя ближе к ValueObject / DataTransferObject нежели к Model. Я просто хочу отметить, что MVC, это не просто decoupling данных, от обработки и отображения, а конткретный способ, как этот decoupling происходит. И это далеко не единственный способ. Просто один из самых стандартных и востребованных.

Model это нечто, что может отсылать сообщения, и принимать сообщения. Если у тебя просто блок данных – это не модель.

Ладно, не будем спорить, я сам пока в поисках " самого идеального фрэймворка и наилучшего паттерна"))
Просто в PBE вообще нет ничего, кроме декораций, которые сложнее чем, то что они декорируют) тАКОЕ ОЩУЩЕНИЕ, ЧТО ПОРТИРОВАЛИ САМОПИСНЫЙ ДЖАВА ДВИЖОК, НЕ ЗНАЯ, ЧТО В AS3 ЭТО ВСЁ ЕСТЬ И ТАК.

Вообще можно разделить приложения на две категории.

Приложения которые работают постоянно сами, и приложения, которые работают по требованию пользователя.

Например, если мы пишем веб приложение, или десктопное – 99 процентов времени, оно ничего не выполняет, могут быть рутины ( например RSS/Mail клиенты могут перепроверять раз в 5-10 минут ). Но чаще мы просто ждем User Input, в данном случае Model View Controller является оптимальной парадигмой, в том плане, что программу нужно пнуть, чтобы она изменилась. Юзерь кликает мышкой, вид обновляет модель, модель пинает контроллер.

Есть другая категория программ, в которые входит большинство игр – Они работают постоянно. Если пользователь отпустит мышку, контроллер, клавиатуру – игра все равно будет продолжать играть. 30-60 кадров в секунду перерисовываясь и 30-240 раз обновляя физику/ии.

В данном случае MVC является ненужным костылем, потому что, никто никого извещать не должен. Программа так и так, проверяет все данные несколько десятков раз в секунду.

Исключением являются пошаговые игры, квесты и тд, там MVC и в правду очень может пригодится, так как мы буквально ждем ввода пользователя. Но если игра real-time нам не нужны не модель, не контроллер, не вид ( вид в MVC тоже отсылает сообщения, в нашем случае рендер никому ничего не отсылает, просто ставит флаг - отрендерил ).

Добавлено через 4 минуты
А PushButton да сосет =)

злой ты Nirth, какая собака тебя покусал то?

2 Nirth:
Вы вообще не любите какие-то сторонние фреймворки или конкретно PBE считаете плохим фреймворком?

Я солидарен с Котярой, использование строковых литералов – не сть хорошо, это источник потенциальных ошибок, если в комманде есть Junior кодеры.

Вы имеете ввиду подобные записи: "@Spatial.position"? Если да, то мне это тоже не нравится, но мне хотелось бы по-больше узнать о PBE и понять, возможно, получится как-то «обходить» подобные записи.

Я не разбирался в PBE, и сомневаюсь, что я знаю кого либо, кому охота в нем разбираться.

Суровый флешер.

Просто у я ленивый, и у меня очень много ленивых друзей ^_^

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

И я так же думаю =)

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

@lowka
То есть с твоей точки зрения – Ценность PBE в том, что кто то им попользуется, забьет на него, и напишет лучше? ^_^
У меня похожая точка зрения =)

2 Nirth:
Подмена понятий и нежелание замечать фразу «может и не будет» are detected!