Подкаст FGB - выпуск 5 (Sbat про HTML5)


Пятый выпуск подкаста в котором Сергей Sbat Батищев душевно рассказал про золотые годы Flash и про HTML5 а также задавал вопросы ведущим.

Выпуск подкаста на podster.fm

Содержание:

[01:00] — Как ты пришел к играм?
[02:30] — Про самарский стартап.
[05:00] — Игры как хобби.
[06:30] — Про «широкий» опыт программирования.
[07:45] — Первые успехи и Playground SDK.
[11:00] — Опыт управления командой и B2B разработка.
[13:15] — Про заграницы.
[15:00] — Юридические знания.
[16:45] — Первая игра на Flash.
[17:45] — Реализация программиста.
[19:00] — Умение смотреть вперед.
[21:15] — Вопрос Флазму про цикл разработки флэш игры.
[23:45] — Уходим в инди.
[24:15] — Первый совет начинающим инди.
[26:00] — Glue и King.com.
[30:00] — Отношения с бывшей компанией.
[31:30] — Про характер.
[34:00] — Еще вопрос Флазму про делегирование.
[36:45] — Вопрос Заркуа про вижн и про Бродского.
[39:15] — Про Glue 2 и про сиквелы.
[45:30] — Про продуктивность, GTD и другие книги.
[51:30] — Про жену и детей.
[55:30] — HTML5. Обзор рынка.
[65:45] — Про сложнось HTML5 игр.
[71:00] — Популярные жанры HTML5 игр.
[74:45] — HTML5 в Steam.
[75:45] — Стратегия на рынке HTML5. Трэш зарабатывает?
[78:15] — Про стариканов и спорт.
[78:45] — Второй совет начинающим.
[83:00] — Еще пара советов от ведущих.

Вопрос слушателям: знаете ли вы игры сделанные на HTML5 в Steam?

В следующем подкасте у нас Hanuman про порталы, а кого бы вы хотели еще услышать в качестве гостя?
  • +26

Комментарии (135)

+1
[01:00]-[55:30]
+8
ну и зачем ты это добавил?
+8
Полагаю, что эта картинка в дружеской иронической форме отмечает, что sbat настолько любит поговорить, что «приветствие и знакомство» заняли 54 минуты 30 секунд. ;) Факт! :)
0
Снова сгладил угол и замял скандал с переходом на личности. :)
0
Странно у меня время поста в прошлом, сейчас на компе 21:14 а пост 21:19, а камент заркуа 21:45 oO
  • Vel
  • Vel
0
Это же московское время )
0
Мы тут что только не тестируем, мой Android 4.0 тормозит, как сцука. Но игра Сергея норм работает. Не 30 fps. Половина точно есть:)
0
Круто, спасибо. А что за телефон?

Кстати, хинт. Chrome Developer tools могут подключиться к мобильному хрому и собирать много статистики. В том числе, пофреймово показывать, сколько и что жрет процессорного времени.

В целом Андроиды до 4.1-4.2 были в отстающих. Сафари (отчасти из-за быстрого выкатывания иОС) стал нормальным гораздо раньше.
+9
sbat шарит
0
Сергей, можешь скинуть больше ссылок на HTML порталы?
+4
Всякие спец. порталы со словом HTML5 в названии гуглятся легко, и они часто не очень интересны.

С точки зрения бизнеса интересны две группы.

1) Классические Flash порталы, которые делают ставку на HTML5. Их находить нетрудно, идешь с телефона на классические порталы и смотришь, кто и что там показывает:
m.spielaffe.de (это Кайзеровский портал)
m.agame.com
m.yepi.com

2) Сети, которые распространяют HTML5 игры. softgames.de, www.boostermedia.com, www.buongiorno.com. Они их раздают другим порталам, операторам и т.п.

3) Kongregate, Newgrounds и некоторые другие принимают HTML5 игры. Но повторю еще раз мысль из подкаста: никакого смысла писать «только для десктопа» на HTML5 сейчас нет. Флэш в 100500 раз удобнее и мощнее. На нем нужно писать игры для мобильных браузеров. Если «вдруг» управление подходит и для десктопов, то можно выложить и на НГ-Конг. Но управление сразу «для всего» — редкость. Из трех игр у меня в разработке на десктопе удобно можно играть только в одну.

В целом любым заинтересованным в этом нужно идти на www.html5gamedevs.com/, там обсуждаются спонсоры, клиенты, аспекты разработки.
+1
эмм, я тут со своими комментариями про сообщество и технологии. Вообще-то одним из первых, обративших взор на ХэТэМэЛэ 5 был elmortem, было это оч давно, когда про него только начинали петь дифирамбы и пророчества про очередного убивцу флеша (кратко говоря — несколько лет назад). А sbat только в последнее время активизировался как пропагандист богомерзкого. Или я чего-то пропустил?
Предвидя (или на всякий): как у elmortem-а сложились отношения с ХэТэМэЛэ-5 не знаю, но судя по тому, что тут он уже не особо появляется, то наверное ушел на него (или еще куда-то).
0
В твиттере он только о Unity говорит:)
+2
sbat, появись в коментах, чтобы могли навалить тебе плюсов!
  • qdrj
  • qdrj
0
html5 игры лично меня не сильно привлекают. Ограниченные по функционалу и легко тырятся :)
0
Что, кстати, с твоим участием в подкасте? Помню, был как-то разговор в комментариях к одному из подкастов, но не помню, чем закончилось.
+1
Да я разговаривать не умею голосом :)
+3
Меня как игрока 99% ХТМЛ5 игр тоже не сильно привлекает.

Что касается «легко тырятся», то в среднем серьезных отличий от флешки мало. Хочется заморочиться — компилируй в advanced режиме Google Closure compiler. Все идентификаторы будут заобфусцированы, control flow несколько запутается. Необфусцированная флешка тянется вообще несколько легче, т.к. там все в одном файле.

Ну и самое главное — клиентов (как и в мире флеш) в подавляющем большинстве случаев абсолютно не волнует, насколько игра легко «тырется». Я даже кодом для сайтлока не заморачиваюсь.

Ну а ограничения по функционалу… У любой платформы есть ограничения. Если рассматривать с точки зрения бизнеса только в том, готовы ли платить (и сколько) за продукты в рамках этих ограничений.
+1
Не знаю какие возможные ограничения существуют в ХТМЛ5 в перспективе, но такое привлечение денег приятно как минимум разработчикам. Ты делаешь что-то и тебе за это платят. Конкуренция небольшая. Игры можно делать простенькие. Годно же.
+3
а кого бы вы хотели еще услышать в качестве гостя?
Кого-то с успешной игрой на мобилах.
  • qdrj
  • qdrj
0
А я бы про флеш послушал.
А то сам уже неделю на Unity завис клепая прототипы. Нужно что-то родное, флешевое :)
0
Да тут же все говорят что флеш умер)
0
Тут много чего говорят :) Пока у одних флеш мертв — другим он регулярно приносит наследство с FGL
0
Блин, а ведь я то думал что на FGL он и мертв, а с флеша приносит наследство где то уже за его пределами)
+1
Да я имею ввиду другое. Все, у кого умер флеш — просто ничего на нем не делают серьезное :)
+4
А ну да, тут бы надо Антона Карлова пригласить, он на флеше не одну собаку сьел.( немного корейских шуточек )
0
Плюсую, думаю будет интересно его послушать.
  • Vel
  • Vel
+1
Отличные флеш приносит доходы. А кто делает что-то серьёзное, тому не нужен FGL…
0
ant-karlov.ru
+7
В следующем подкасте с Хануманом как раз будем говорить о флэш порталах и о флэш играх.
0
ееееееееее ^__^
0
Прямо радуете )
0
Недавно читал про HTML5 и наткнулся на имя Сергей Батищев…
А это sbat D: Для меня была новость.
  • z3lf
  • z3lf
+2
Интересно, понравилось.
Единственное, было бы интересно услышать конкретику: где именно (в сети) водятся все те спонсоры и ресурсы, куда можно html5 толкнуть.
  • ADF
  • ADF
+1
Если не ошибаюсь, в подкасте Сергей сказал, что вся инфа на www.html5gamedevs.com/
0
Спасибо, видать прослушал.
  • ADF
  • ADF
0
Я в ответе выше привел несколько названий, ссылок и алгоритмов поиска клиентов. И да, на сайте www.html5gamedevs.com/ есть еще больше обсуждений.
0
Спилы в следующем году инвестируют пять миллионов в HTML5.
0
*переехала
0
У меня к Сергею вопрос насчет финального совета про АйПи райтс. Судя по этому совету, у тебя была одна из двух ситуаций: либо ты однажды не согласился продать права на что-то и потом понял, что молодец, либо ты их продал и пожалел. Не расскажешь поподробнее? )
0
Скорее всего 1е, с темже glue и microsoft, он же говорил что был ексклюзив как вариант.
  • Vel
  • Vel
+1
Обе:
1) Я не отдал Gluey на эксклюзив и это было отличное решение (Майкрософт, Яху, куча других сайтлоков). Примерно в 3 раза превысило изначальную планку лучшего эксклюзива.
2) По той же Gluey и Sticky Linky я отдал мобильные права, хитами, как можно увидеть в appannie они не стали, хотя какие-то деньги принесли. Признаюсь, абсолютно не факт, что я сам бы сделал лучше (хотя всегда так кажется задним умом). Но мне кажется, что в мобильных версиях был сделан упор на некоторые не очень важные вещи (количество игровых режимов в той же Gluey) и не сделан упор на важные вещи (качество и плавность рендеринга анимации в ней же).
0
О, пользуясь случаем, еще вопросец. Ты, когда продавал сайтлоки Глюя, цену для разных порталов называл одинаковую, или она зависела от портала и его крутости? Если брать обычную простую кастомизацию — сплеш-скрин, лого.
0
> Ты, когда продавал сайтлоки Глюя, цену для разных порталов называл одинаковую, или она зависела от портала и его крутости?

Я установил стандартную цену в FGL game shop и стартовал от нее. Но в ряде случаев был готов дать скидку, если это чем-то было оправдано.
0
Во, вспомнил!
В подкасте было утверждение, что GC в JS-машинах работает быстрее и грамотнее оного в Ф.
А не может ли быть такое, что скорость его работы — лишь кажущаяся — на фоне общей медленности (даже по сравнению с флэшом) JS? :)
PS: типа, размышления в слух.
  • ADF
  • ADF
+1
JavaScript — быстрый язык, даже по сравнению с C++. Именно с этим связана популярность NodeJS.

benchmarksgame.alioth.debian.org/

Это вычислительные задачи, и в них он всего в 2-5 раз медленнее C++.

JavaScript сравним с AS3 по производительности. Это уже сильно зависит от задач, но прямой порт (читай «тупой порт») V8 benchmark на AS3 работал в 2011 сильно медленнее, чем в JS на Chrome:
0
Ссылка потерялась: iq12.com/old_blog/as3-benchmark/
+1
NodeJS — нужен свой сервер. Просто взять и прикрутить куда угодно, как это можно на PHP — не получится.
JavaScript скрипту рознь. Я считаю, что бенчмарки надо начинать и заканчивать на родных мобильных браузерах. На компе бенчи проводить нет смысла.
+1
Разумно. Но на мобильных в браузерах его не с чем сравнивать. :)

А вот с phonegap и прочими… Сейчас действительно такая ситуация, что в webview (т.е. завернутый внутрь приложения) JS работает сильно медленнее, чем в браузере. Особенно эта проблема остра на иОС, где в webview не работает jit-компиляция. Только браузеру разрешено нарушать правило «исполнение только подписанного кода». Это реальная проблема.
0
JS — это интерпретатор, ну не может он быть сравним с машинным кодом, который получается после компиляции нативного С++. В вычислительных задача разница должна быть от двух порядков (100+ раз), либо в условиях эксперимента что-то не так было.
Что касается AS3 и JS — понятно, что у них скорости примерно сравнимы, но у обоих сильно сливают плюсам. Вообще, все скрипты популярны лишь по двум причинам: 1. обеспечение кроссплатформенности; 2. Работа в режиме сэндбокса, когда доступ к реальному железу достаточно хорошо контролируется, ибо это не низкоуровневый код.
Ну да ладно, заканчиваю с банальностями :)
+1
JIT-компиляция
0
Она ко всем JS применяется или только на некоторых ВМ, только при специальной указивке? Грубо говоря, в неком усредненом бравузере — JS компилируется или интерпретируется?
Также, выражаю громкое сомнение, что JIT-компиляция эффективнее, чем обычная. А еще, если она вдруг в некий байткод, а не в бинарник — то это не считается )
PS: как человек, а не бездушный робот, имею право ошибаться :)
+2
> Грубо говоря, в неком усредненом бравузере — JS компилируется или интерпретируется?

Усредненный браузер — это как средний человек, у которого одна грудь и одной яйцо? :)

Ну а если серьезно, JS «JIT компилируется» в машинный код Chrome (VM V8) и в Сафари (VM Nitro). В том числе на мобильных платформах. На остальных не исследовал вопрос.

JIT компиляция включает формирование на лету «hidden classes». Т.е. объекты не хранятся просто как хэш-таблицы, происходит обнаружение «на лету» формы объектов, чтобы хранить их как классы в C++/Java. Прочитать про это и про другие особенности работы V8 можно тут:
www.jayconrod.com/posts/52/a-tour-of-v8-object-representation

JS не JIT компилируется (а исполняется из промежуточного кода) в Safari WebView (т.е. браузер, встроенный в другие приложения на iOS). Не из вредности Эппл. А потому, что только Safari имеет специальное право нарушать общее правильно iOS «исполняется только подписанный машинный код». Решить эту проблему элегантно Эппл пока не смог. И это реальная проблема.

> Также, выражаю громкое сомнение, что JIT-компиляция эффективнее, чем обычная.

Она вне всяких сомнений не эффективнее чем обычная. Вопрос — во сколько раз.

В статических платформах типа Java и .NET она практически такая же быстрая. Что логично, так как ничем от С++ не отличается. Современные компиляторы С++ тоже часто компилируют в промежуточный код, а потом его компилирует в целевые машинные коды (см. LLVM).

Посмотри тесты Java и C++ выше. В практических задачах по разному, но из-за того, что в Java GC быстрее _стандартного_ new/delete в C++, в «наивно написанных» задачах Java может и обогнать.

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

Эксперимент выше — это игра. Авторы пишут наиболее оптимальное решение задачи, какое они могут, на «своем» языке. JS в ней исполняется на NodeJS, NodeJS построен на V8. Скорость примерно соответствует скорости десктопного хрома.

Если есть сомнения — присоединяйся и напиши более эффективную версию на C++. :)

Я сделал только одно жульничество — это цифры «одноядерных» тестов. ;)
0
Спасибо за развернутый ответ! Каша в голове начинает превращаться в баланду ))

А вот еще интересно, typeScript пока лишь к двум с половиной конкретным IDE прикручен, а к чему-то еще его можно прикрутить? Ну, например, к тому-же FD.
0
Редактировать-то там можно… А вот чтобы с рефакторингом, подсветкой и навигацией, то, думаю, только Visual Studio и Idea. Говорят еще Тайпскриптовые плагины к Sublime набирают обороты.
+1
Спасибо за подкасты. Очень здорово сделано, можно запросто на радио, продвигать инди игрострой в массы, слушать приятно, речь грамотная, вопросы интересные. Личная просьба, в следующих выпусках касаться подхода к геймдизайну у респондента, в случае если респондент ответственен за это в команде. Конечно, сколько людей столько и мнений, но в этом и вся прелесть, у каждого в голове своя модель, которая либо укрепится после прослушивания, либо претерпит изменения. Либо ещё вариант, у человека есть какая-то модель, но не все её детали понятны до такой степени чтобы быть способным реализовать это на практике верно, в этом случае просто даже прослушивание той же теории но озвученной другим человеком, может быть с другими акцентами, помогает. Заранее спасибо.
0
Спасибо за отзыв! А что значит подход к геймдизайну? Т.е. про что конкретно спрашивать? Откуда идеи берутся и как из них выбирать хорошие? Как уровни придумываются или как балансируется игра? Поясни, что ты имеешь ввиду?
0
Извиняюсь за использование общего термина. Спрашивать только про дизайн составляющую, то есть умение представить креативную идею (механику) наиболее подходящим и эффективным способом. Как придумать крутую механику — вопрос, имхо, не конструктивный. А вот как добиться более креативного состояния (медитация по Scmorr'у например) — вполне, и это тоже можно включить, если есть желание. Спасибо.
0
sbat
интересно про хтмл5
а что используешь? какие инструменты? мне показалась, что было слова «хакс» в подкасте — да?
+1
Typescript + Visual Studio (Intellij Idea тоже неплоха) + CreateJS

Haxe только в контексте того, что какой-то паблишер недавно на ФГЛ искал игры на Хаксе. Сам я на нем не писал.
0
Скажи пожалуйста, а как лучше поставку игры делать? Кучу файлов или один большой?

Просто мой фреймворк имеет дофига файлов (Event.js, MouseEvent.js, Sprite.js, Bitmap.js, MovieClip.js, Stage.js) и в моем developer tool — это наборы файлов. Но по кнопке компиляции — эти все файлы сливаются в один, проходятся накатом минифаером и выплювывается один js. При том, что изображения игровые у меня встраиваются в сам файл в виде байтаррея (чтоб гады не тырили графику).

На выходе вообще один js файл, который долго долго грузится и бац — загрузился ) Нормальная ли техника?
Я на порталах вижу кучу файлов. Но мне это не нравится… Максимум это 2 файла. Один — прелоадер js файла и второй по загрузке уже стартует. Клиент на портал встраивает только один js и тот сам уже подхватывает и вставляет все остальное.

Какие мысли на этот счет?
0
Я делаю один JS файл. Минимицированный код редко много занимает. В моей игрушке 130кб, ну и плюс библиотеки.

Клиенты на порталы обычно встраивают игру как целый каталог с index.html. В подавляющем большинстве случаев сейчас игры просто открываются целиков в новом окне. Но есть клиенты, которые делают всякие iframe, контролы рядом с игрой и т.п.

Изображения и звуки я гружу PreloadJS (из семейства CreateJS). Это реально востребовано. Если тут упаковывается, то нужно, наверное, делать прелоадер.
0
А чем CreateJS не устроил для (Event.js, MouseEvent.js, Sprite.js, Bitmap.js, MovieClip.js, Stage.js). Его даже Адоб юзает. Нормальный вроде.
0
CreateJS действительно использует Adobe в своих последнийх продуктах. Я использую его в создании анимации во Flash CC под офисные нужды. Но что касается игрушек — что-то он не впечатлил своей непроворотливостью. У меня для офисного клиента была задача 1270х710 сделать анимацию через CreateJS. Все медленно работает. Не выдает нужное число FPS. Кучу лишнего мусора, который на 50% просто не будет использоваться в простых играх.

Аналог на собственноручно написанном фреймворке сделал больше чуда у меня. Но я отказался от поддержки вектора и т.д. Все как у Stage3D — по минимуму.
0
Забыл написать… CreateJS идеальное решение для сторонников «бери и используй». Я же отношусь к людям, которые сначала хотят свои 5 копеек вставить. А по-этому, в моем случае, этими 5ю копейками оказался свой фреймворк.
0
Планируешь опенсорснуть, когда готово будет?
0
Всегда боюсь опенсорсать проекты, т.к. первым делом говорят «ну ты дятел, это не так делается» :)
Есть подозрение, что если все будет окей и как надо — он просто станет freewarе, но не опенсорс
0
> Всегда боюсь опенсорсать проекты, т.к. первым делом говорят «ну ты дятел, это не так делается» :)

Ну ты даешь! Ты же первый всегда это говоришь (в вежливой форме, конечно)!!! :)

Удачи! Я бы с удовольствием посмотрел на то, что получится. Никак не дойдут руки форкнуть и реально доработать CreateJS, а там много чего можно улучшить.
0
А вот расскажи, насколько в итоге графика быстрее стала на самодельщине?
Createjs-ный отрисовщик — реально машину раком ставит. При одинаковой с флэшом площади перерисовки, в 2+раз и более тормозит, даже при кэшировании всего что можно и нельзя.
0
Ну я не могу однозначно сказать, но быстрее. Скиннер подтвердил, что тупит CreateJS ввиду большого количества неоптимизированного кода.
Но не стоит ожидать чуда от Canvas. Его следует рассматривать лишь как Fallback для Flash :)

Я пока не готов делиться ни тестами, ни кодом. Надо основную работу закончить и допилить свой фрейм. Потом его компилятор передывать, т.к. у меня компиляция идет его в бинарник сейчас. Создается словарь и по словарю через evel стартует вся функция. При этом первым делом убивается script файл в html dom, но он остается в памяти. Так, что любители запустить js файл и нажимающие дебаггер для вытаскивания измененного тела скрипта — остаются в пролете почти многие, кто тырит игрушки.

А бинарник — простое решение. На основе готового js кода компилятор абсолютно все повторяющиеся слова сливает в словарь и выстраивает цепочку 01F9CC35A8CC и так далее. JS на клиенте всего лишь транслирует этот байткод в строку большую и потом через зашифрованный eval стартует main() метод и удаляет тело скрипта из script тэга в html.

В итоге имеем бешенную компрессию кода + защиту от дурака, который copy-paste любит использовать :) Кстати, toString() метод у класса функции замечательно спасает от любителей через alert ( myFunc) посмотреть тело всей функции :)

Короче говоря ничего нового. Но мне интересно на это тратить время. И не скрою — сейячас увлекся больше упаковкой и защитой кода, нежели написанием фреймворка.
0
Так, надо тебя и по флэшу тоже растрясти, как там защиту правильно делать и все такое. Чтоб это было в виде статьи с понятыми (для тупых, вроде меня) примерами :) Фрэймворка не прошу, но о способах защиты и всеми этими махинациями с бинарником — очень интересно!
0
ADF, а можешь поделиться результатами в каком-то виде? Тема весьма интересна. Скорее в теоретическом плане (смысла писать на десктопе на ХТМЛ5 я сейчас не вижу, флеш во всем лучше). Но в если это createjs гадит, то это важно знать.

Ну и в принципе хочется понять, в каких случаях GPU-accelerated канвас в новом Хроме проигрывает софтверному рендеру Флеша. То, что он может Stage3D проиграть, сомнения и удивления не вызывает.
0
Да я пока только через createjs рисовал. Напрямую через канвас рисовал закрашенный прямоугольник и закрашенный кружочек :)
До нормальных тестов и самодельных отрисовщиков пока не дошли руки, в настоящий момент и без них работы хватает… В лисе и хроме существенной разницы в скорости рендеринга не увидел: и там и сям выше 30 фпс не приходится замахиваться пока.
По мере познания разных уголков яваскрипта, приходится удивляться и свирепеть :)
0
Вот ради любопытства adobe.ly/19pZtya (прошу прямую ссылку не публиковать нигде, файл через 2 недели удалю)
На качество графики внимание не обращаем. Что дали — то использовал. Делалось полностью в Flash CC и потом поверху накатывал уже мелкие javascript детали и html.
Есть точно такая же но флеш. Задача была портануть флеш в html5 canvas
0
Забавно. В хроме на Core i5 с встроенным видео у меня не получалось пока зарезать так, чтобы 60 фпс не работали простые игры на CreateJS (~50 спрайтов, без физики). На мобилах, конечно, хуже.

useRAF стоит в true (т.е. получаем enterFrame через requestAnimationFrame, а не через таймеры)? Ничего кроме отрисовки не делается? Chrome timeline где показывает bottleneck: в GPU/композиции или в исполнении кода?
0
Тормозит точно отрисовка, не код. Другие моменты пока не могу пояснить, загляну в проект завтра. У меня тут уже ночер глубокий, переходящий в ранее утро… )
0
В общем, сделано через createjs.Ticker.
На нем висит один единственный ивент. В хроме сейчас не могу глянуть, в силу ряда причин.
+2
Ticker может работать в разных режимах в createjs: RAF, RAF_SYNCHED, TIMEOUT.

В режиме Timeout вызовы не синхронизованы с фреймрейтом с соответствующими последствиями. Это хорошо видно в таймлайне в профайлере Chrome или Safari.

www.createjs.com/Docs/EaselJS/classes/Ticker.html#property_RAF

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

Я для своих игр использую канвас размером 640x712. В ограничения по скорости рисования картинок в канвас на createjs пока не упирался. Скорее уж JS тормозил.

Ну вот смотри, зелененьких полосочек («фаза композиции») почти не видно, все с огромным запасом в пределах производительности 60 FPS (но это core i7 рабочий с мощной видеокартой, не очень показательно):
screencast.com/t/4KCP3Eolos

Обрати внимание также, что в этом случае JS выполняется строго на границах фреймов отрисовки, а не как придется.
0
Прикольные носороги! :)
Спрайтшыты к сожалению разные (около 4-5 штук...) и размеры канваса больше: 960 на 720 или что-то вроде.
JS за граница кадра не выходит, с режимом тикера пошел разбираться.
Спасибо.
0
> Спрайтшыты к сожалению разные (около 4-5 штук...)

Не поместились в один 2048x2048 или по каким-то еще причинам?

> 960 на 720

На всякий случай отмечу: отрендерить в канвас 400x400, а потом через CSS этот канвас растянуть до 800x800 — почти бесплатная операция. Поскольку растяжение тоже будет на GPU.

Ведь 960x720 — это больше видимой области на iphone 4s в браузере! :)

Удачи!
0
ТЗ хитрое: айфоны не требуются, но планшетники нужны… :)
Затолкать в один спрайтшыт — просто не задумывался, что это оно важно…
Делать в low-res — в курсе, пока отложено на крайний случай.
+1
Про атласы я больше расскажу :) Чтоб выдавать более оптимально — все используемые на экране объкты в данной сцене лучше брать из одного атласа.

К примеру у нас есть 1 атлас на персонажа и 1 атлас на кровь, хелс бар. Если мы персонажу тягаем постоянно кровь и хелс бар с другого атласа — это уже загрузка в память две текстуры разные. Что уже 2х операция.

Как раз у одного товарища проблема была в старлинге :) У него юнит — один атлас. А хелспар — другой атлас. Соотв. когда GPU накатывала графику — ей приходись рисовать все с одним спрайтшитом и потом все с другим ) два дроукола ) вместо одного. Засунул он хелсбар в атлас с юнитом — дроуколы сократились и игра вообще перестала тормозить )

Надо почитать как у Canvas с этим.
0
Device/browser specific, но в целом так же. Скажу честно, на моих играх, как мне кажется, я всегда был fill rate bound и bad-ass JS bound. :) Но всегда использовал только 1 (максимум 2) спрайтшита.

Есть еще большое преимуществу крупных spritesheet: маленький канвас-картинку браузер может «деоптимизировать» и считать на ЦПУ.
0
Во флэше в drawtriangles сталкивался, что лучше из одного ресурса ему всю графику кормить. При отрисовке 2д — что-то не замечал разницы, что из одного места, что из разных.
Возвращаясь к хтмл-5 — не совсем понимаю, если я использую createjs.container и createjs.sprite (бывш. bitmapAnimation) — как подсовывать один и тот-же атлас? Он вроде только на одинаковые по размерам кадры может его разрывать, т.е. будет работать только для случая, если все элементы графики в этом атласе — одинаковых размеров.
Опять-же, сильно ли важно, откуда тот-же container брал свои потрохи, если он закэширован и обновляется относительно редко (скажем, раз в 10 кадров)?
0
Во флэше в drawtriangles сталкивался, что лучше из одного ресурса ему всю графику кормить. При отрисовке 2д — что-то не замечал разницы, что из одного места, что из разных.

Ну так если у тебя много разных спрайтширов — ты обязятельно увидишь разницу с использованием GPU для 3D. Кстати 2D или 3D — разницы никакой для видеокарты. Просто занулена координата одна
0
Двухмерный рендерер флэша использует GPU? я вроде считал, что все тормоза — не в видеокарте, а где-то на пути к ней: как флэш все это собирает в кучу, чтобы кинуть на отрисовку.
Про хтмл-5 вообще не знаю, как оно работает. Я в него только начал вникать ))
+1
Не не не :) Я думал ты о Stage3D с Starling на счет 2D :)
Что касается обычного DisplayList в режиме GPU — там часть видеокарты и часть CPU используется. Ну это так нам пишут :) Типа все рендерится в offscreen текстуру :) но управлять этим нельзя ) Я сам до конца не понимаю как и что там. Но оптимизировать это умею и четко увидел, что 1 спрайтшит работает быстрее, чем кучу мелких картинок ) и заливать в мувик картинку через bitmapfill из одного спрайта — куда быстрее )
0
Bitmapfill это да, оно примерно как drawtriangles по повадкам.
Но из двухмерной графики я последнее время все нативными средствами норовлю рисовать. Ну т.е. куча отдельных спрайтов и мувиклипов на сцене и все такое :) Вроде вполне себе приемлемо по быстродействию, кто бы что не говорил.
0
Так если правильно подходить к разработке — оно всё ровно и быстро идет. Просто люди привылки на обычном флеше работать и когда под малопроизводительные девайсы делают приложения, то начинают говорить о низкой производительности. У меня обычно один аргумент — с таким ровными руками и нативные средства разработки не помогут :) Как говорится «хочешь что-то измнить — начни с себя».

Я когда переводил первое клиентское приложение под Air на iPad — у меня вообще не запускалось :) Отваливалось из-за memory warnings :) Но подшаманил чуток, подумав — не просто загрузил, а еще и добился полного отсутствия тормозов :)
0
На десктопах и в HTML5 нужно спец. усилия приложить, чтобы тормозило. ;) А вот на мобилах…
+1
> Он вроде только на одинаковые по размерам кадры может его разрывать, т.е. будет работать только для случая, если все элементы графики в этом атласе — одинаковых размеров.

Не, он умеет произвольные, см. его формат JSON: www.createjs.com/Docs/EaselJS/classes/SpriteSheet.html

В его формате Adobe умеет экспортировать спрайтшиты. Или www.createjs.com/#!/Zoe.

> Опять-же, сильно ли важно, откуда тот-же container брал свои потрохи, если он закэширован и обновляется относительно редко (скажем, раз в 10 кадров)?

Кэширование нужно использовать осторожно. Сама операция кэширования раз в 10 кадров будет тратить время и создавать рывки с FPS. А так, конечно, не важно.
0
Для усиления драматического эффекта приведу пример роста производительности.
При одних и тех же условиях в случае разных атласов фпс падал до 35-40, после того, как полоска жизней была добавлена в каждый атлас с монстрами, фпс стал проседать в тех же случаях до 55 фпс.
0
Ага — спасибо, понятно.

Я пользуюсь только растровыми инструментами CreateJS. Т.е. Container, BitmapAnimation (Sprite), Bitmap. Если не пользоваться обработкой тапов прямо на объектах(которая делает вторую отрисовку в 1x1 pixel canvas), а использовать только события сцены, то все неплохо работает.

Хотя, иногда perframe конструкции такого типа смущают, думаю попробовать убрать:
// this ensures we don't have issues with display list changes that occur during a draw:
var list = this.children.slice(0);
for (var i=0,l=list.length; i<l; i++) {
0
А какие есть техники для защиты кода и графики? Ну помимо пресловутой обфускации и минимизации… И как делаются сайтлоки?
+6
А какие есть техники для защиты кода и графики?

Если говорить о html5 — то лишь извращенная фантазия программиста защитит.
Минимально можно графику складывать в base64 и прямо в JS коде хранить в виде строки. Отсеит школьников. Есть разные варианты. Конечно, можно вскрыть всё. Вопрос лишь в желании и наличии свободного времени.

Я сейчас пишу фреймворк свой — я компилирую JS код в hex код. Создаю словарь из используемых слов в коде. Слово тут не как строковое имею ввиду, а вообще любой символ, отличающийся от пробела ) function, var, x, «hello world» — это все «слово» в данном контексте. Дальше каждому слову присваивается код.

Шаг 1

function say(){
   alert("hello world");
}

Шаг 2

function say(){alert("hello world");}


dict['function '] = 01;
dict['say('] = 02;
dict['){'] = 03;
dict['alert('] = 04;

«hello world» преводим вместе с кавычками в hex и получаем 2268656C6C6F20776F726C6422 строку.

dict['«hello world»'] = 2268656C6C6F20776F726C6422;
dict[');}'] = 05;

На выходе у нас строка 010203042268656C6C6F20776F726C642205

Во-первых одна длинная и во-вторых работать не будет. Почему? Потому, что декодер, который надо еще создать — не поймет где начнется «hello world».
По-этому дописываем в парсер к примеру F0, который будет понимать «начало строки», дальше длинну. У 2268656C6C6F20776F726C6422 это составит 26 символов. 26 в hex будет 0х1A — откидываем 0х

Значит F01A будет значить «после 1А читаем 26 символовов
правим результирующую строку 01020304F01A2268656C6C6F20776F726C642205

дальше делаешь декодер, который будет иметь словарь :)
но не в в таком виде, dict['function '] = 01;, а тоже закодированном. Не буду приводить явные примеры — долго, лень и сами дуймате

На выходе иметь будем dict['66756E6374696F6E20'] = 01; что можно сократить ) как — не скажу.

Как будет выглядеть наш файл с функцией?

var data = '01020304F01A2268656C6C6F20776F726C642205';

распарсим его по значениям ключей dict и соберем назад
1) function
2) say(
3) ){
4) alert(
5) „hello world“
6) );}

склеим эту String в одну и засунем в eval() и у нас Javascript создаст функцию в памяти

дальше тупо вызываем say(); и без видимой say функции в коде — она все же сработает.

А чтоб защититься от любителей смотреть тело функций через alert(say) — просто делаем еще один код (лучше его первым делом делать)

Function.prototype.toString = function(){
return 'function alert(parameter){ [native code];}';
}

зачем 'function alert(parameter){ [native code] ;}'?

Просто все. Чтоб отпугнуть людей :) Конечно, можно вернуть „Cheater f*ck off“ :) Но я всегда советую страшные и похожие на какие-то серьезные вещи походить, чтоб автоматически сработало в голове „А, ну да мы тут ниче не сделаем — это ж native code“ и большая часть людей отвалит нафиг.

Потом мы в после eval должны удалить скрипт наш из кода )



проходим по всему html dom и ищем тег script где src=»js/game.js" и пернюрим ему innerHTML = "";

Что интересно — у нас в коде становится пусто, если смотреть дебаггером (именно дебагерры видят изменения на страницах в dom). Но после запуска такого дела — дебаггер нифига не увидит — будет пустой innerHTML , а самое классное — функции то в памяти будут уже и будут работать без проблем :) Можем туда для отвода глаз насувать мусора, который не работает :) Я небольшие пустышки советую туда вписывать. Чтоб человек интуитивно увидел, что там что-то есть, но править там нечего и забросил ковырять нашу игрулину. Это как в политике — воруют миллионы, но ставят скаймейки дешевые. Чтоб пенсионеры говорили «какой молодец, мне скаймейку поставил». А за миллионы забывали украденные.

Теперь что касается eval. Нельзя вызывать его так явно. Eval это часть js движка ) так же как и window == this; А у window есть этот самый eval )

если сделаем обманку:

var compiler = window['eval'];
то у нас легко будет работать такой код:


var compiler = window['eval'];
var stringMethod = 'function say(){alert("hello world");}';
compiler(stringMethod);
say();


Возращаясь к видимым и не запутанным частям кода — лично я бы не хранил window['eval'] такую строку. Как по мне то уже лучше так:


var compiler = window['\x65\x76\x61\x6C']; // в любом hex редакторе пишешь eval и в hex коде 6576716с видишь )
var stringMethod = 'function say(){alert("hello world");}';
compiler(stringMethod);
say();


но и '\x65\x76\x61\x6C' я не храрнил бы ) я бы закодировал это все так, что пока ты раскодируешь — кофе закончится и азарт :)

Теперь давай про сжатие кода.

Было function say(){alert(«hello world»);}
Стало 01020304F01A2268656C6C6F20776F726C642205

И теперь считай, сколько у тебя раз в коде будет function, ){, ;} и прочих приколов )

3 раза строка function function function (с пробелами в конце) либо 010101 ) компрессия ) да! Суть уловил? Давай теперь сам :)
0
Чо хотел добавить. Варианта создания такого комплиятора 2. Либо действитетльно создать программулину, котороая будет кушать js файлы. Либо руками.
Я всегда сторонник защиты интеллекутальной собственности. Часто вижу как люди плачут «увели игру на другой сайт». Начинаешь говорить — «защищай» и тебе в ответ «та ну это долго и не выгодно.» Ну блин… Долго и не выгодно — не ной. Тем более сделай один раз метод защиты и юзай везде. А если планируется одна игра в жизни — можно конечно не париься вообще защитой :)
0
Во, серьезное дело, основательное!

Правда перекликается с моими относительно недавними размышлениями о том, что идеальной (ну, почти идеальной :)) защитой будет создание некой полнофункциональной виртуальной машины на JS, а вся основная программа должна быть на рыбьем языке для этой самой ВМ, который внезапно не похож на нормальные языки по структуре и синтаксису. Или даже еще одну ВМ внутри забабашить. Это будет рукотворный Ад :)
0
У всех сильных методов защиты JS довольно шаткое положение. Практически все из них используются или использовались вредоносными скрипами для обхода защиты. Поэтому антивирусы не очень любят такого рода трюки, и эвалы с кодированными строками в том числе. Полагаю, если антивирус не сможет разобрать содержимое закодированного скрипта, то попросту заблокирует его как JS/Kryptik троян. И даже если метод сегодня проходит проверки, не факт, что завтра его не используют в неблаговидных целях, и не начнется повсеместное выпиливание. Такие дела.
0
Не порежут их антивирусы :) Нет сейчас времени объяснять почему :) Но в 2х словах — они память прочитают, в отличии от школьников-хаекров )
0
Мне кажется такие поползновения со стороны антивирей следует ожидать только после появления и массового внедрения нативных средств защиты для JS. Но что-то мне подсказывает, что подобных вещей в обозримом будущем не предвидится: ибо слишком хлопотное дело, а ценность — только для разработчиков, и то не для всех.

PS: и если уж возьмутся железными клешнями за безопасность js — то первым делом просто выпилят из него eval :)
0
перед тем как убегаю — последнее слово. Сейчас почти все сайты используют jquery и прочие либы. А разве там не на eval всё основанно? :) Вот на вскидку глянул — кучу разных фреймворков используют eval
0
Да: eval отменят и все сломается ))))
0
пишу с тебефона не удобноппц. именно по-этому ас нехт не сделали ибо будет тоже самое — все сломается
0
Мне кажется такие поползновения со стороны антивирей следует ожидать только после появления и массового внедрения нативных средств защиты для JS
Комплексные средства защиты, которые выполняют функции брандмауэра, уже давно фильтруют JS, также фильтрацией занимаются поисковики и браузеры, отсеивая сайты с потенциально опасным содержимым. Сама по себе eval вполне обычная функция реализующая механизм рефлекшна, пока методы работы с ней прозрачны для антивируса — все норм.
0
Так ты же сам только что описал проблемы!
Что в попытках защититься — JS может стать подозрительным для антивирусов вплоть до блокировки.
В то, что антивирусы и пр. любят блокировать вполне нормальный контент, особенно у конечных потребителей (с заводскими или близкими к ним настройками браузеров и политик «безопасности») — верю.
Так что вопрос: как же тогда защищать JS, но чтобы его не посчитали вирусом — не праздный.
0
Очевидно, использовать методы, которые прозрачны для машины, но затруднительны для анализирования человеком. Практически идеально под это подпадают обфускация и минификация. Может какие-то простые варианты кодирования, остальное нужно хорошенько проверять.

Вот, например, вчера искал няшный кодировщик, наткнулся на одном сайте:
1) wtools.biz/test/pr/encrypt_1.htm — нормально открывается
2) www.wtools.biz/test/pr/encrypt_2.htm — был выпилен NOD Smart Security как JS/Kryptik.BP, хотя вроде ничего преступного там нет, скорей всего такая реакция на document.write с кодированным содержимым.
0
doc.writы уже много лет под вирусы используются :)
+1
0
Если серьезно, то в таком открытом виде уже давно не используется, гонка вооружений не стоит на месте, как только метод начинает детектироваться, придумывают новый. Потенциально опасные элементы всегда будут под прицелом (document.write, document. createElement, eval, iframe и прочее). Вот, например, код загрузчика вредоносного скрипта двухлетней давности, построен на eval, практически то, что ты выше предлагаешь. Такого рода пакеры снимаются с помощью специальных эмуляторов работы браузеров (типа jsunpack), довольно просто.
0
Так пусть снимают :) От всех не защититься. Но от всяких нубасов, которые ничего кроме графики поменять не могут — надо закрываться :) Они же потом игры камрадов продают как рескин и умудряются еще и больше заработать :)
0
Смысл комментов выше не в «снимут» /« не снимут», а в том, что есть определенная вероятность быть заблокированным антивирусом. И при построении защиты нужно это понимать и учитывать, нужно искать баланс между эффективностью защиты и возникающими с ее использованием рисками.
0
Уговорил :) У меня есть мыло ребят из Eset и Касперский ) отправилю им на анализ, чтоб не выпиливали хардкодно :)
0
Дык и как этот баланс определить? надо знать, как работают антивирусы, что не всегда возможно.
Ну и вообще для защиты от крякинга, надо иметь какой-то опыт в этом самом крякинге. На отдельный курс лекций семестра на три тянет ))
0
Забей на балансы. Если прогу твою будет лочить антивирус — это не проблема. Во-первых на моб. девайсах его нет (а делать игру с рассчетом только под браузер компа — глупо), во-вторых ты можешь в пару-тройку основных компаний отослать варианты кода и они тебе скажут будет лочить или нет. Я это проходил лично и за это не платил. Им же надо свой «контент» обновлять ;) Да и ничего не стоит закинуть код на проверку на тот же вирустотал.
Ну и вообще для защиты от крякинга, надо иметь какой-то опыт в этом самом крякинге. На отдельный курс лекций семестра на три тянет ))
От 2х до 4х это тянет. Мне так адвокат сказал :) Давно. Но убедительно.
0
Крякинг — какбэ не значит воровать чужое бабло. Просто опыт в расколупывании чужого защищенного кода. В детстве — было абсолютно нормальным и естественным явлением, это сейчас лень и некогда… %]
0
Я свою ошибку совершил первый раз очень давно. Когда мне надоело платить провайдеру за кривой инет :) Я решил ничего не менять, кроме оплаты за инет :) Благо всё обошлось полюбовно )
0
Так ты просто огурец с дверной ручкой попутал! :)
Ему о возвышенном, а он — как капиталистов на деньги кидать ))
0
спасибо, очень круто и основательно )
когда будет нужно на практике все это применить, я у еще полную тебя платную консультацию закажу :)
0
Вот, похоже, самый действенны кодировщик JavaScript — кавайный, при одном только взгляде у злоумышленника растает его черное каменное сердце, и он уже никогда больше не захочет заниматься постыдными делишкам ^_^
0
Видел на хабре, видел раньше и где-то декодер видел :) Но не интересен он :)
0
Ты не недооцениваешь силу няшек и магию дружбы!
0
*Ты недооцениваешь силу няшек и магию дружбы!
0
(o^_^o)
0
Это SCP 173 — главное не моргать :))
0
(╯°□°)╯︵ ┻━┻
0
Эээ… я так понял, что пора делать htlm5gameblogs?
+2
Развитие игровой верстки :D
+2
Наверное даже: «Развитие игровой наценки» — по классике же должен быть надмозговый промт-перевод. Или полная версия: «Развитие игровой сверхтекстовой наценки пятого языка»
+1
Пропадает талантливый копирайтер.
0
Работал в Фаргусе — талант не пропьешь :D

+1
Наверное, точнее будет так:
«Сверхтекстовой наценки пятым языком развитие игровое»
0
По смыслу — да, но хорошо бы сохранить преемственность названий с развитием игровой вспышки: «Развитие игровой сверхтекстовой наценки пятым языком» — может.
0
Развитие игровой сверхтекстовой наценки речью пятерых :D
0
Может уже indiegameblogs.ru? Или gamedevblogs.ru?
0
indiebrods.ru )

Мне кажется на данный момент «flash» в названии является некой защитой от толп юных геймдевов, которые периодически с «проэктами» набигают на gamedev.ru )
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.