Просмотр полной версии : Переводы уроков про PushButton Engine
koIIImarik
18.07.2010, 16:19
Всем привет.
Закончил сегодня перевод 5-го официального урока про разработку игр с помощью PushButton Engine (http://pushbuttonengine.com/).
Ссылки на уроки:
Урок #1 (http://flashist.ru/lessons/pushbutton-engine-urok-1)
Урок #2 (http://flashist.ru/lessons/pushbutton-engine-urok-2)
Урок #3 (http://flashist.ru/lessons/pushbutton-engine-urok-3)
Урок #4 (http://flashist.ru/lessons/pushbutton-engine-urok-4)
Урок #5 (http://flashist.ru/lessons/pushbutton-engine-urok-5)
Хотелось бы услышать мнение людей о том, нужны ли вообще переводы уроков про PushButton Engine и использует ли кто-нибудь на форуме данный фреймворк в своих разработках.
Официальные доки тут: http://pushbuttonengine.com/docs/
P.S.:
Если уроки вам покажутся полезными, то буду благодарен за карму на Хабре: http://flashist.habrahabr.ru/blog/99402/
alexcon314
19.07.2010, 10:30
Спасибо. Только почему поместили во флейм? Может быть блог заведете?
Contemplator
19.07.2010, 12:06
Спасибо. Только почему поместили во флейм? Может быть блог заведете?
зачем ему блог, когда есть свой сайт с уроками? =)
alexcon314
19.07.2010, 12:16
действительно)
Огромное спасибо за ваш труд :)
Теперь знаю, что буду читать после книжек по флексу :)
koIIImarik
19.07.2010, 13:00
2 alexcon314:
2 Furinax:
Приятно знать, что переводы будут полезны другим людям =) Спасибо вам.
Напрягает в PBE - использование Java стайл конвенций наименований..
UPD - посмотрел доки: вроде теперь нормально именуют.. исправились что ли?
А вообще мне лично этот фрэймворк и не нужен - легче самому написать то что надо, чем разбираться в этом движке. Рамки это чаще плохо, чем хорошо.
koIIImarik
19.07.2010, 13:52
2 Котяра:
Не работал раньше с этим фреймворком, поэтому не знаю, какие раньше принципы именования в нём использовались. Лично, что мне не нравится в фреймворке — это использование «ссылок» на свойство через строковые названия, например так: "@Spatial.position".
Что касается «написать своё», то это всегда можно, но в этом случае вы не узнаете, что уже изобретено сейчас. Мне, допустим, просто интересно, как в том или ином движке/фреймворке организована работа со страницами игры, настройкой уровней через XML и т.п.
В частности, PBE имеет один очень интересный инструмент по встраиванию внешних ресурсов через [Embed], который описывается в 5-м уроке (http://flashist.ru/lessons/pushbutton-engine-urok-5). Не прочитав этот урок, я вряд ли когда-нибудь узнал о такой возможности.
А какое отношение тег Embed имеет к PBE?
koIIImarik
19.07.2010, 13:58
2 Diestro:
Почитайте 5-й урок.
А причем тут 5й урок? Еще раз повторяю: тег Embed никакого отношения к PBE не имеет.
koIIImarik
19.07.2010, 14:55
Хорошо, давайте так, вы читали 5-й урок? О чём там идёт речь?
Там идет речь о встраивании изображений посредством метатега [Embed], который к самому Push Button Engine никакого отношения не имеет.
koIIImarik
19.07.2010, 15:03
А как этот тег PBE использует в своих целях?
:) Великолепный диалог.
Я вступил в диалог увидев вот это:
2 Котяра:
В частности, PBE имеет один очень интересный инструмент по встраиванию внешних ресурсов через [Embed]
и в ответ написал что тег Embed не имеет никакого отношения к самому движку. Этим метатегом можно пользоваться в любом AS3 проекте.
koIIImarik
19.07.2010, 15:18
Да =) Я сейчас перечитал своё сообщение, наверно я не очень правильно выразился, было бы правильнее сказать, «…на основе информации, передаваемой через тег [Embed]…», а не «…по встраиванию внешних ресурсов через [Embed]…».
Ну на самом деле это делается и без всякого PBE.
В чём его заслуга?
В уроке кстати не указано каким образом получать доступ к MyResource.myAsset?
Через строку? Это убожество.
В общем очень странный движок и я не увидел ни одной прикольной фичи.
например там нет:
- системы сообщений (mvc)
- динамической подгурузки с прелоадерами.
- кэширование битмап.
Всё как то на очень простом уровне..
koIIImarik
19.07.2010, 17:07
2 Котяра:
Ну на самом деле это делается и без всякого PBE.
В чём его заслуга?
Его заслуга в том, что вам не нужно ничего дописывать и там, на мой взгляд достаточно удобно, организована проверка на встроенность файлов, и если файл встроен, он не будет подгружаться извне, а будет браться из библиотеки встроенных файлов.
- системы сообщений (mvc)
Так сложилось исторически, что game-engineers не любят MVC, и вообще слишком много абстракций, которые помогают в GUI / Server-Client / Enterprise приложениях, мешаются в Game Dev'е.
BlooDHounD
19.07.2010, 23:40
Nirth, так уж сложились, что ты сейчас не прав )
Так уж сложилось, что иметь три полностью инкапсулированных абстраций, в игре не нужно =)
Добавлено через 1 минуту
Если на то пошло, то можно реализовать Delegate-Model или View-(Model+Controller) но конкретно MVC – изометрических RGP – лишнии костыли.
BlooDHounD
19.07.2010, 23:57
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 минуты
PBE вообще нет ничего
А PushButton да сосет =)
злой ты Nirth, какая собака тебя покусал то?
koIIImarik
20.07.2010, 11:33
2 Nirth:
Вы вообще не любите какие-то сторонние фреймворки или конкретно PBE считаете плохим фреймворком?
Я солидарен с Котярой, использование строковых литералов – не сть хорошо, это источник потенциальных ошибок, если в комманде есть Junior кодеры.
koIIImarik
20.07.2010, 13:47
Вы имеете ввиду подобные записи: "@Spatial.position"? Если да, то мне это тоже не нравится, но мне хотелось бы по-больше узнать о PBE и понять, возможно, получится как-то «обходить» подобные записи.
Я не разбирался в PBE, и сомневаюсь, что я знаю кого либо, кому охота в нем разбираться.
koIIImarik
20.07.2010, 13:53
Суровый флешер.
Просто у я ленивый, и у меня очень много ленивых друзей ^_^
На самом деле мы можем все ошибатся, по-играйся, посмотри, может литералы не так сильно мешают. Может есть альтернативные способы доступа к полям. Даже если PBE сосет, и ты в нем разочаруешься, все равно вынесешь опыт – как фреймворки далеть не надо.
koIIImarik
20.07.2010, 14:36
Даже если PBE сосет, и ты в нем разочаруешься, все равно вынесешь опыт
И я так же думаю =)
Ладно, не будем спорить, я сам пока в поисках " самого идеального фрэймворка и наилучшего паттерна"))
Просто в PBE вообще нет ничего, кроме декораций, которые сложнее чем, то что они декорируют) тАКОЕ ОЩУЩЕНИЕ, ЧТО ПОРТИРОВАЛИ САМОПИСНЫЙ ДЖАВА ДВИЖОК, НЕ ЗНАЯ, ЧТО В AS3 ЭТО ВСЁ ЕСТЬ И ТАК.
компонентная архитектура там есть. (смотрел PBE пару месяцев назад и в неком роде она там присутствовала)
вот не знал кто-нибудь об ней - посмотрит, обдумает, может и не будет он использовать данный движок, но интересную штуку узнает-таки и возьмет на вооружение.
@lowka
То есть с твоей точки зрения – Ценность PBE в том, что кто то им попользуется, забьет на него, и напишет лучше? ^_^
У меня похожая точка зрения =)
koIIImarik
20.07.2010, 22:35
2 Nirth:
Подмена понятий и нежелание замечать фразу «может и не будет» are detected!
@koIIImarik
И в правду, извиняюсь.
vitalik14
06.10.2010, 03:31
Пользуюсь PBE, и скажу честно убожество(( ...вот несколько проблем
1.Длинные литеры свойств утомляют.
2. Плохая работа с swf (кто бы мог подумать.. )..когда поочередно добавляешь layerIndex, первый может наложится на последний. Все приходится переопределять очень муторная работа((.
3.Координаты сущности начинаются с центра, а если. преобразовываешь в DisplayObject, то левый верхний ...ужас! достает постоянная синхронизация DisplayObject и сущность(нельзя присвоить одинаковые координаты).
Есть конечно и положительные моменты.. это как работа с XML единая загрузка и разгрузка левела. но тоже баги есть если в xml по шаблону получаешь объекты нельзя получить свойство target обекта=).
Остановлюсь пока на этом....нервные клетки очень плохо восстанавливаются).
Правда физику еще не затрагивал (столкновение объектов и т д) но чета мало верится в удачу.
Работа на PBE напоминает выживание в тупиковых условиях. приходится выкручиваться так что потом сам удивляешься что из поломанного трактора делаешь велосипед.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.