
Подкаст 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
- flazm
Комментарии (135)
Кстати, хинт. Chrome Developer tools могут подключиться к мобильному хрому и собирать много статистики. В том числе, пофреймово показывать, сколько и что жрет процессорного времени.
В целом Андроиды до 4.1-4.2 были в отстающих. Сафари (отчасти из-за быстрого выкатывания иОС) стал нормальным гораздо раньше.
С точки зрения бизнеса интересны две группы.
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/, там обсуждаются спонсоры, клиенты, аспекты разработки.
Предвидя (или на всякий): как у elmortem-а сложились отношения с ХэТэМэЛэ-5 не знаю, но судя по тому, что тут он уже не особо появляется, то наверное ушел на него (или еще куда-то).
Что касается «легко тырятся», то в среднем серьезных отличий от флешки мало. Хочется заморочиться — компилируй в advanced режиме Google Closure compiler. Все идентификаторы будут заобфусцированы, control flow несколько запутается. Необфусцированная флешка тянется вообще несколько легче, т.к. там все в одном файле.
Ну и самое главное — клиентов (как и в мире флеш) в подавляющем большинстве случаев абсолютно не волнует, насколько игра легко «тырется». Я даже кодом для сайтлока не заморачиваюсь.
Ну а ограничения по функционалу… У любой платформы есть ограничения. Если рассматривать с точки зрения бизнеса только в том, готовы ли платить (и сколько) за продукты в рамках этих ограничений.
А то сам уже неделю на Unity завис клепая прототипы. Нужно что-то родное, флешевое :)
А это sbat D: Для меня была новость.
Единственное, было бы интересно услышать конкретику: где именно (в сети) водятся все те спонсоры и ресурсы, куда можно html5 толкнуть.
1) Я не отдал Gluey на эксклюзив и это было отличное решение (Майкрософт, Яху, куча других сайтлоков). Примерно в 3 раза превысило изначальную планку лучшего эксклюзива.
2) По той же Gluey и Sticky Linky я отдал мобильные права, хитами, как можно увидеть в appannie они не стали, хотя какие-то деньги принесли. Признаюсь, абсолютно не факт, что я сам бы сделал лучше (хотя всегда так кажется задним умом). Но мне кажется, что в мобильных версиях был сделан упор на некоторые не очень важные вещи (количество игровых режимов в той же Gluey) и не сделан упор на важные вещи (качество и плавность рендеринга анимации в ней же).
Я установил стандартную цену в FGL game shop и стартовал от нее. Но в ряде случаев был готов дать скидку, если это чем-то было оправдано.
В подкасте было утверждение, что GC в JS-машинах работает быстрее и грамотнее оного в Ф.
А не может ли быть такое, что скорость его работы — лишь кажущаяся — на фоне общей медленности (даже по сравнению с флэшом) JS? :)
PS: типа, размышления в слух.
benchmarksgame.alioth.debian.org/
Это вычислительные задачи, и в них он всего в 2-5 раз медленнее C++.
JavaScript сравним с AS3 по производительности. Это уже сильно зависит от задач, но прямой порт (читай «тупой порт») V8 benchmark на AS3 работал в 2011 сильно медленнее, чем в JS на Chrome:
JavaScript скрипту рознь. Я считаю, что бенчмарки надо начинать и заканчивать на родных мобильных браузерах. На компе бенчи проводить нет смысла.
А вот с phonegap и прочими… Сейчас действительно такая ситуация, что в webview (т.е. завернутый внутрь приложения) JS работает сильно медленнее, чем в браузере. Особенно эта проблема остра на иОС, где в webview не работает jit-компиляция. Только браузеру разрешено нарушать правило «исполнение только подписанного кода». Это реальная проблема.
Что касается AS3 и JS — понятно, что у них скорости примерно сравнимы, но у обоих сильно сливают плюсам. Вообще, все скрипты популярны лишь по двум причинам: 1. обеспечение кроссплатформенности; 2. Работа в режиме сэндбокса, когда доступ к реальному железу достаточно хорошо контролируется, ибо это не низкоуровневый код.
Ну да ладно, заканчиваю с банальностями :)
Также, выражаю громкое сомнение, что JIT-компиляция эффективнее, чем обычная. А еще, если она вдруг в некий байткод, а не в бинарник — то это не считается )
PS: как человек, а не бездушный робот, имею право ошибаться :)
Усредненный браузер — это как средний человек, у которого одна грудь и одной яйцо? :)
Ну а если серьезно, 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++. :)
Я сделал только одно жульничество — это цифры «одноядерных» тестов. ;)
А вот еще интересно, typeScript пока лишь к двум с половиной конкретным IDE прикручен, а к чему-то еще его можно прикрутить? Ну, например, к тому-же FD.
интересно про хтмл5
а что используешь? какие инструменты? мне показалась, что было слова «хакс» в подкасте — да?
Haxe только в контексте того, что какой-то паблишер недавно на ФГЛ искал игры на Хаксе. Сам я на нем не писал.
Просто мой фреймворк имеет дофига файлов (Event.js, MouseEvent.js, Sprite.js, Bitmap.js, MovieClip.js, Stage.js) и в моем developer tool — это наборы файлов. Но по кнопке компиляции — эти все файлы сливаются в один, проходятся накатом минифаером и выплювывается один js. При том, что изображения игровые у меня встраиваются в сам файл в виде байтаррея (чтоб гады не тырили графику).
На выходе вообще один js файл, который долго долго грузится и бац — загрузился ) Нормальная ли техника?
Я на порталах вижу кучу файлов. Но мне это не нравится… Максимум это 2 файла. Один — прелоадер js файла и второй по загрузке уже стартует. Клиент на портал встраивает только один js и тот сам уже подхватывает и вставляет все остальное.
Какие мысли на этот счет?
Клиенты на порталы обычно встраивают игру как целый каталог с index.html. В подавляющем большинстве случаев сейчас игры просто открываются целиков в новом окне. Но есть клиенты, которые делают всякие iframe, контролы рядом с игрой и т.п.
Изображения и звуки я гружу PreloadJS (из семейства CreateJS). Это реально востребовано. Если тут упаковывается, то нужно, наверное, делать прелоадер.
Аналог на собственноручно написанном фреймворке сделал больше чуда у меня. Но я отказался от поддержки вектора и т.д. Все как у Stage3D — по минимуму.
Есть подозрение, что если все будет окей и как надо — он просто станет freewarе, но не опенсорс
Ну ты даешь! Ты же первый всегда это говоришь (в вежливой форме, конечно)!!! :)
Удачи! Я бы с удовольствием посмотрел на то, что получится. Никак не дойдут руки форкнуть и реально доработать CreateJS, а там много чего можно улучшить.
Createjs-ный отрисовщик — реально машину раком ставит. При одинаковой с флэшом площади перерисовки, в 2+раз и более тормозит, даже при кэшировании всего что можно и нельзя.
Но не стоит ожидать чуда от Canvas. Его следует рассматривать лишь как Fallback для Flash :)
Я пока не готов делиться ни тестами, ни кодом. Надо основную работу закончить и допилить свой фрейм. Потом его компилятор передывать, т.к. у меня компиляция идет его в бинарник сейчас. Создается словарь и по словарю через evel стартует вся функция. При этом первым делом убивается script файл в html dom, но он остается в памяти. Так, что любители запустить js файл и нажимающие дебаггер для вытаскивания измененного тела скрипта — остаются в пролете почти многие, кто тырит игрушки.
А бинарник — простое решение. На основе готового js кода компилятор абсолютно все повторяющиеся слова сливает в словарь и выстраивает цепочку 01F9CC35A8CC и так далее. JS на клиенте всего лишь транслирует этот байткод в строку большую и потом через зашифрованный eval стартует main() метод и удаляет тело скрипта из script тэга в html.
В итоге имеем бешенную компрессию кода + защиту от дурака, который copy-paste любит использовать :) Кстати, toString() метод у
классафункции замечательно спасает от любителей через alert ( myFunc) посмотреть тело всей функции :)Короче говоря ничего нового. Но мне интересно на это тратить время. И не скрою — сейячас увлекся больше упаковкой и защитой кода, нежели написанием фреймворка.
Ну и в принципе хочется понять, в каких случаях GPU-accelerated канвас в новом Хроме проигрывает софтверному рендеру Флеша. То, что он может Stage3D проиграть, сомнения и удивления не вызывает.
До нормальных тестов и самодельных отрисовщиков пока не дошли руки, в настоящий момент и без них работы хватает… В лисе и хроме существенной разницы в скорости рендеринга не увидел: и там и сям выше 30 фпс не приходится замахиваться пока.
По мере познания разных уголков яваскрипта, приходится удивляться и свирепеть :)
На качество графики внимание не обращаем. Что дали — то использовал. Делалось полностью в Flash CC и потом поверху накатывал уже мелкие javascript детали и html.
Есть точно такая же но флеш. Задача была портануть флеш в html5 canvas
useRAF стоит в true (т.е. получаем enterFrame через requestAnimationFrame, а не через таймеры)? Ничего кроме отрисовки не делается? Chrome timeline где показывает bottleneck: в GPU/композиции или в исполнении кода?
На нем висит один единственный ивент. В хроме сейчас не могу глянуть, в силу ряда причин.
В режиме 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 выполняется строго на границах фреймов отрисовки, а не как придется.
Спрайтшыты к сожалению разные (около 4-5 штук...) и размеры канваса больше: 960 на 720 или что-то вроде.
JS за граница кадра не выходит, с режимом тикера пошел разбираться.
Спасибо.
Не поместились в один 2048x2048 или по каким-то еще причинам?
> 960 на 720
На всякий случай отмечу: отрендерить в канвас 400x400, а потом через CSS этот канвас растянуть до 800x800 — почти бесплатная операция. Поскольку растяжение тоже будет на GPU.
Ведь 960x720 — это больше видимой области на iphone 4s в браузере! :)
Удачи!
Затолкать в один спрайтшыт — просто не задумывался, что это оно важно…
Делать в low-res — в курсе, пока отложено на крайний случай.
К примеру у нас есть 1 атлас на персонажа и 1 атлас на кровь, хелс бар. Если мы персонажу тягаем постоянно кровь и хелс бар с другого атласа — это уже загрузка в память две текстуры разные. Что уже 2х операция.
Как раз у одного товарища проблема была в старлинге :) У него юнит — один атлас. А хелспар — другой атлас. Соотв. когда GPU накатывала графику — ей приходись рисовать все с одним спрайтшитом и потом все с другим ) два дроукола ) вместо одного. Засунул он хелсбар в атлас с юнитом — дроуколы сократились и игра вообще перестала тормозить )
Надо почитать как у Canvas с этим.
Есть еще большое преимуществу крупных spritesheet: маленький канвас-картинку браузер может «деоптимизировать» и считать на ЦПУ.
Возвращаясь к хтмл-5 — не совсем понимаю, если я использую createjs.container и createjs.sprite (бывш. bitmapAnimation) — как подсовывать один и тот-же атлас? Он вроде только на одинаковые по размерам кадры может его разрывать, т.е. будет работать только для случая, если все элементы графики в этом атласе — одинаковых размеров.
Опять-же, сильно ли важно, откуда тот-же container брал свои потрохи, если он закэширован и обновляется относительно редко (скажем, раз в 10 кадров)?
Ну так если у тебя много разных спрайтширов — ты обязятельно увидишь разницу с использованием GPU для 3D. Кстати 2D или 3D — разницы никакой для видеокарты. Просто занулена координата одна
Про хтмл-5 вообще не знаю, как оно работает. Я в него только начал вникать ))
Что касается обычного DisplayList в режиме GPU — там часть видеокарты и часть CPU используется. Ну это так нам пишут :) Типа все рендерится в offscreen текстуру :) но управлять этим нельзя ) Я сам до конца не понимаю как и что там. Но оптимизировать это умею и четко увидел, что 1 спрайтшит работает быстрее, чем кучу мелких картинок ) и заливать в мувик картинку через bitmapfill из одного спрайта — куда быстрее )
Но из двухмерной графики я последнее время все нативными средствами норовлю рисовать. Ну т.е. куча отдельных спрайтов и мувиклипов на сцене и все такое :) Вроде вполне себе приемлемо по быстродействию, кто бы что не говорил.
Я когда переводил первое клиентское приложение под Air на iPad — у меня вообще не запускалось :) Отваливалось из-за memory warnings :) Но подшаманил чуток, подумав — не просто загрузил, а еще и добился полного отсутствия тормозов :)
Не, он умеет произвольные, см. его формат JSON: www.createjs.com/Docs/EaselJS/classes/SpriteSheet.html
В его формате Adobe умеет экспортировать спрайтшиты. Или www.createjs.com/#!/Zoe.
> Опять-же, сильно ли важно, откуда тот-же container брал свои потрохи, если он закэширован и обновляется относительно редко (скажем, раз в 10 кадров)?
Кэширование нужно использовать осторожно. Сама операция кэширования раз в 10 кадров будет тратить время и создавать рывки с FPS. А так, конечно, не важно.
При одних и тех же условиях в случае разных атласов фпс падал до 35-40, после того, как полоска жизней была добавлена в каждый атлас с монстрами, фпс стал проседать в тех же случаях до 55 фпс.
Я пользуюсь только растровыми инструментами 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++) {
Если говорить о html5 — то лишь извращенная фантазия программиста защитит.
Минимально можно графику складывать в base64 и прямо в JS коде хранить в виде строки. Отсеит школьников. Есть разные варианты. Конечно, можно вскрыть всё. Вопрос лишь в желании и наличии свободного времени.
Я сейчас пишу фреймворк свой — я компилирую JS код в hex код. Создаю словарь из используемых слов в коде. Слово тут не как строковое имею ввиду, а вообще любой символ, отличающийся от пробела ) function, var, x, «hello world» — это все «слово» в данном контексте. Дальше каждому слову присваивается код.
Шаг 1
Шаг 2
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'];
то у нас легко будет работать такой код:
Возращаясь к видимым и не запутанным частям кода — лично я бы не хранил window['eval'] такую строку. Как по мне то уже лучше так:
но и '\x65\x76\x61\x6C' я не храрнил бы ) я бы закодировал это все так, что пока ты раскодируешь — кофе закончится и азарт :)
Теперь давай про сжатие кода.
Было function say(){alert(«hello world»);}
Стало 01020304F01A2268656C6C6F20776F726C642205
И теперь считай, сколько у тебя раз в коде будет function, ){, ;} и прочих приколов )
3 раза строка function function function (с пробелами в конце) либо 010101 ) компрессия ) да! Суть уловил? Давай теперь сам :)
Я всегда сторонник защиты интеллекутальной собственности. Часто вижу как люди плачут «увели игру на другой сайт». Начинаешь говорить — «защищай» и тебе в ответ «та ну это долго и не выгодно.» Ну блин… Долго и не выгодно — не ной. Тем более сделай один раз метод защиты и юзай везде. А если планируется одна игра в жизни — можно конечно не париься вообще защитой :)
Правда перекликается с моими относительно недавними размышлениями о том, что идеальной (ну, почти идеальной :)) защитой будет создание некой полнофункциональной виртуальной машины на JS, а вся основная программа должна быть на рыбьем языке для этой самой ВМ, который внезапно не похож на нормальные языки по структуре и синтаксису. Или даже еще одну ВМ внутри забабашить. Это будет рукотворный Ад :)
PS: и если уж возьмутся железными клешнями за безопасность js — то первым делом просто выпилят из него eval :)
Что в попытках защититься — JS может стать подозрительным для антивирусов вплоть до блокировки.
В то, что антивирусы и пр. любят блокировать вполне нормальный контент, особенно у конечных потребителей (с заводскими или близкими к ним настройками браузеров и политик «безопасности») — верю.
Так что вопрос: как же тогда защищать JS, но чтобы его не посчитали вирусом — не праздный.
Вот, например, вчера искал няшный кодировщик, наткнулся на одном сайте:
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 с кодированным содержимым.
Ну и вообще для защиты от крякинга, надо иметь какой-то опыт в этом самом крякинге. На отдельный курс лекций семестра на три тянет ))
От 2х до 4х это тянет. Мне так адвокат сказал :) Давно. Но убедительно.
Ему о возвышенном, а он — как капиталистов на деньги кидать ))
когда будет нужно на практике все это применить, я у еще полную тебя платную консультацию закажу :)
«Сверхтекстовой наценки пятым языком развитие игровое»
Мне кажется на данный момент «flash» в названии является некой защитой от толп юных геймдевов, которые периодически с «проэктами» набигают на gamedev.ru )