А я и не знал что бывают такие штуки:
http://stackoverflow.com/questions/2527561/is-it-p...e-to-do-a-define-in-adobe-flex
И даже отдельные препроцессоры для AS3 есть. Очень интересно, можно все настроить и использовать макросы.
Для FlashBuilder: http://blog.joa-ebert.com/2006/02/27/actionscript3-preprocessor/
Для FlashDevelop: http://www.flashdevelop.org/community/viewtopic.php?f=5&t=1188
И вообще их много.
Также макросы есть в apparat: http://code.google.com/p/apparat/wiki/MacroExpansion
Для встраивания inline функций надо использовать тулзу tdsi, которая есть здесь: http://makc.googlecode.com/svn/trunk/flash/fd_inline/tdsitest/
А ещё можно делать макросы в AS3 через gpp (http://en.nothingisreal.com/wiki/GPP).
Вот он: http://makc.googlecode.com/svn/trunk/gpp.2.24-windows/
Вот тестовый проект под FD с ним: http://makc.googlecode.com/svn/trunk/flash/fd_inline/gpptest/

Я не знал, каюсь. Не знал что все вещественные числа считаются совершенно не правильно. Недавно столкнулся с этим в AS3 при вычислении текстурных координат. Долго копал, а потом узнал это: http://www.yur.ru/science/computer/IEEE754.htm

В AS3 например такая операция 0.4 + 0.2 даёт результат 0.6000000000000001. Из-за этого текстурные координаты берутся от другого пикселя и картинка становится неверной. В моём случае достаточно было просто обрезать вычисленный результат. Наиболее быстрый способ это сделать такой: int(10000000*x) / 10000000. И делать надо это после каждой арифметической операции с вещественным числом x.

А вообще проблема очень серьёзная и решений на сегодняшний день нет. Подробности в статье по ссылке выше.

Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина Flash Player. Иследования проводились только для версии 11.1 standalone debugger for win32. В следующих версиях Flash Player могли как улучшить работу с памятью так и ухудшить, но скорее всего всё осталось также. Итак, garbage collector (GC) исключительно хреново работает с памятью. Он её попросту не очищает во многих случаях или выделяет в разы больше чем требуется.

Вы наверняка знаете, что такое сильные и слабые ссылки и как GC их считает чтобы понять нужен этот объект или нет... Всё это написано во многих местах, в т.ч. в документации по AS3. Я всё это повторять не буду. Здесь описано как всё должно хорошо очищаться: http://help.adobe.com/en_US/as3/mobile/flashplatform_optimizing_content.pdf
Но нифига оно так не работает к сожалению. При соблюдении всех этих правил моя программа всё равно жрала память как сумасшедшая при загрузке, а потом Flash Player просто падал, когда кончалась физическая память в операционной системе. Вот так он работает на самом деле.

Всё началось вот с этой темы в Juick: http://juick.com/eugene20237@ya.ru/2009006 и моего вопроса на StackOverflow: http://stackoverflow.com/questions/11833009/as3-bitmapdata-memory-leaks
Почитайте, если хотите, узнаете много нового о флеше. А ещё почитайте вот эту статью о том что надо реально сделать для оптимизации по памяти на флеше.

Дальше уже обнаружились другие интересные особенности. Моя оптимизация касалась в основном выделения памяти для множества картинок, на которых у меня строятся кадры анимации. Далее я просто резюмирую выводы, к которым пришел в ходе многочасовых экспериментов с BitmapData.

• Loader в дефолтном своем применении порождает утечки памяти. Поэтому если через него загружается картинка, то надо брать её BitmapData и делать bitmapData.clone(), сохраняя в другую переменную. А потом диспозить существующую картинку в Loader, а затем делать loader.unload(). Ещё на всякий случай можно cacheAsBitmap=false.
  

  PHP:
  
  
  var bitmapData:BitmapData = (loader.contentLoaderInfo.content as Bitmap).bitmapData.clone();
  
  (loader.content as Bitmap).cacheAsBitmap = false;
  
  (loader.content as Bitmap).bitmapData.dispose();
  
  (loader.content as Bitmap).bitmapData = null;
  
  (loader.contentLoaderInfo.content as Bitmap).bitmapData = null;
  
  loader.unload();
  font>
  

  
  Только тогда он работает нормально. И то с учетом, что память очищается секундой позднее. Но очищается. Во всех остальных случаях можно сушить вёсла... При этом Loader остаётся единственным способом загружать картинки без утечек памяти.


• C Embed ресурсами всё гораздо хуже. Под них выделяется всегда в разы больше памяти (в 2 раза обычно) и далее она не очищается никогда. Поэтому просто так Embed ресурсы использовать нельзя. Причина заключается в том, что они построены на Flex-компонентах, а в них много неоптимальной фигни. Юзайте Loader. А если нужно встроить ресурс в приложение, то делайте бинарный Embded, а затем Loader.loadBytes(...). Другого пути пока не найдено.
  

  PHP:
  
  
  [Embed(source="../media/128.png", mimeType="application/octet-stream")]
  
  static private const EmbedBMP:Class;
  
  ..............
  
  loader.loadBytes(new EmbedBMP() as ByteArrayAsset);
  font>
  

  
  


• Использовать много мелких картинок - плохая идея. Флеш будет выделять больше памяти чем требуется. Если же для большой группы картинок (допустим 100 шт.) вызывается dispose(), то их память будет очищена, но не сразу, а как повезет: может через минуту или как угодно Богу Мусорщику. Если же использовать десяток больших картинок (допустим 4096x4096), то память под них будет выделять и очищаться абсолютно корректно и сразу же.


• Выделение памяти под BitmapData происходит не при создании объекта BitmapData, а при первой операции рисования на ней или копирования данных пикселей в неё. Это внутренняя оптимизация BitmapData.


• Говорят, что BitmapData иногда выделяет памяти больше чем надо из-за внутреннего мипмеппинга. Этот мипмеппинг отключить никак нельзя. Также есть информация, что он отключается, если задать размеры картинки не являющиеся степенью двойки. У меня на практике это совсем не подтвердилось, так что никакой возможности управления мипмеппингом скорее всего уже нет.


• Сюда же поделюсь опытом использования трюка с local connection. Так вот, в исходном варианте этого хака LocalConnection создаётся два раза внутри try. Мои эксперименты показали, что надо вписать там три строчки, а не две.

Читать далее...

Хочу поделиться совсем небольшим, но всё таки опытом создания графических спец-эффектов для игр. Я имею в виду всякие вспышки, магию и всё что угодно, что делается системами частиц. Но в первую очередь это конечно взрывы :)

На выходе мне нужны были наборы PNG файлов, которые затем я экспортировал специальной своей тулзой.

• Сначала делал их в 3dmax. Но это долго и сложно. Также есть плагин FumeFX для 3dmax, который всё это упрощает. Обратите на него внимание, если собираетесь заняться спецэффектами взрывов профессионально.
  [x200]


• Затем нашёл такую русскую фиговину как Magic Particles 3D. Это фактически бесплатная программа, которая позволяет создавать системы частиц и экспортировать их как в простые PNG файлы, так и в нечто большее. Помимо экспорта итоговой картинки там есть множество API для разных популярных игровых движков, что позволяет использовать разработанные системы частиц в играх, вычисляя их в realtime. В программе есть большое количество встроенных готовых эффектов (samples). Среди них парочка вменяемых взрывов.
  [x200]


• Совсем недавно обнаружил программку Particle Illusion. Стоит денег. На сей момент: $389. Выглядит более солидно чем Magic Particles. Пресетов для неё, судя по всему, очень много. Взрывы более качественные. Экспорт есть во что пожелаешь. Буду делать всё в ней теперь. API для игр правда нет, но мне и не надо.
  [x200]


• Ещё есть Adobe After Effects, но готовых взрывов для него я не нашёл, а изучать всё это долго. Но это средство предназначено именно для спецэффектов, так что если кто-то взялся за это серьёзно, есть смысл изучать After Effects. Стоит $175 на текущий момент.
  [x200]

Вот такой скупой обзорчик получился для тех кто не в курсе.

У меня появилась идея: экспортировать персонажей из Poser/DAZ и вставлять в свой игровой движок. Если такая возможность существует, то перспектива очень заманчивая, потому что моделей для Poser/DAZ существует дофигища. Это бы решило проблему поиска или создания нужных персонажей для игр. Но экспортировать надо в low-poly. Сразу же погуглил на эту тему и нашёл вот это обсуждение на англоязычном форуме. Там много интересного. Короче, выходы есть и так действительно можно.

[показать]

В середине этой темы есть ссылка на утилиту под названием Decimator for DAZ Studio. Она может создавать низкополигональные модели из стандартных дазовских. А именно умеет:
"Decimator for DAZ Studio allows users to create any number of lower polygon versions of a high resolution model known as Levels of Detail (LODs). Use LOD features in DAZ Studio to automatically switch between models depending on factors such as distance from the camera.
Features:
- Create Levels of Detail (LODs)
- Remove invisible Nodes following decimation.
- Remove invisible Surfaces following decimation.
- Prepare to Decimate – (Convert polygons to triangles).
- Decimate complete model including all objects in scene.
- Decimate only selected objects.
- Decimate by percentage.
- Decimate to fixed number of faces."

Кроме того: "In Poser you have high poly meshes and low poly meshes. No need to use some plugin. the low poly meshes are like 2000 polys... perfect." Это очень радует.

Эта заметка написана ламером для ламеров. Так что если, кто-то знает как эти вещи делать правильно, расскажите! Если же вы не эксперт в 3dmax, но вам нужно экспортировать какую-то модель с единой текстурой, как мне, эта заметка для вас. Экспорт всех материалов сцены, а также освещения в одну простую текстуру нужен в частности для некоторых игровых движков. Короче, если вы не знаете зачем это надо, идите лесом..)

Дело в том, что пытаясь сделать эту процедуру я по незнанию сделал ряд ошибок и в итоге всё экспортировалось неправильно. Ошибки эти от кривости рук и недостатка опыта. Возможно кто-то из вас тоже мог на них напороться. В этой заметке я кратко опишу весь процесс работающего экспорта чтобы люди не тратили время методом тыка. Все действия описываются для 3dmax 2012. В других версиях всё аналогично.

Откройте свою модель в 3dmax и после этого никогда не сохраняйте, потому что мы будем её херить в процессе экспорта :) Экспортируемый объект должен быть только один. Если у вас их несколько, то сконвертируйте их в editable poly или editable mesh, а затем соедините с другими объектами с помощью кнопки Attach. Далее выделите полученный объект, который вы хотите экспортировать. На этом этапе у вас уже должно быть расставлено освещение и отлажен итоговый вид с помощью обычного рендеринга в 3dmax. Теперь кликаем Rendering -> Render to texture или просто нажмите клавишу "0" на клавиатуре.

[300x]
Откроется окно рендеринга в текстуру, с помощью которого мы соединим все наши текстуры и освещение в одном графическом файле. Если вы не знаете что такое запекание текстуры в 3dmax, то почитайте эту или вот эту статью. Идите отсюда, читайте. Почитали, но всё ещё не знаете как всё экспортировать? Не беда, сейчас всё будет ясно. Выставьте настройки, как показано на скриншоте. Красным я выделил те пункты, которые изменил для себя. Обратите на них внимание. Если вы понимаете (а вы должны) для чего каждый пункт нужен, можете изменить его под себя. Важно тут выставить автоматическую генерацию новых текстурных координат. Почему? Потому что если оставить Use existing channel, то освещение в текстуре будет неправильным, образуются черные резкие полигоны в совершенно неожиданных местах. Так что рендеринг с использованием существующих текстурных координат к сожалению не работает. Поэтому выставляем Use automatic unwrap в какой-нибудь несуществующий Channel.

После выбора настроек в самом низу окна нажмите кнопку Render. Вы получите примерно такой результат:
[500x]
3dmax рассчитает новые текстурные координаты и добавит в стек модификаторов штуку под названием Automatic Flatten UVs. Этот модификатор накладывает на модель новые текстурные координаты. Если его удалить из стека, вступят в силу предыдущие текстурные координаты. Кроме того, после рендеринга текстуры будут изменены ваши материалы в сцене. В Diffuse map будет вставлена свежезапечённая текстура, а сам объект в итоге может выглядит тёмно. Т.е. в 3dmax он будет отображаться неправильно. Но это всё неважно...)

Теперь важный момент. Ни в коем случае не надо нигде использовать изображение текстуры из окна результата рендеринга. С виду оно нормальное, но на самом деле сильно отличается от файла, который вы указали в target настройке. Если использовать картинку из того окошка, то при наложении на объект появятся резкие белые или тёмные рёбра. Неизвестно почему, но это происходит, так что надо использовать файл, который сгенерил рендерер. Если открыть этот файл в фотошопе, то мы увидим примерно следующую картинку:
[500x]
Текстура может оказаться темноватой, как здесь. Это из-за того, что 3dmax зачем-то прописал в PNG файл нестандартную гамму, более тёмную. Не знаю почему и зачем, но вы возможно знаете. Так или иначе, это можно исправить в фотошопе с помощью Image -> Adjusments -> Levels или каким-то другим способом откорректировать гамму текстуры. Полученную текстуру можно уже использовать в игровом движке или там где вам надо.

Но это ещё не всё. Если вы экспортировали модель до этого, то она будет Читать далее...

Это цитата сообщения Джоан Оригинальное сообщение

[показать] Поддержка ваших библиотек Все файлы Poser должны находиться в основной директории (файловой директории) Runtime. В ранних версиях Poser директория Runtime могла располагаться исключительно в той же папке, что и исполняемый файл Poser. Другими словами, если вы устанавливаете Poser 4 в папку, указанную по умолчанию, директория Runtime будет создана по адресу C ==> Program Files ==> Curious Labs ==> Poser 4, как и файл Poser.exe. При работе с Poser 5 и более поздними версиями в корневой директории появится папка Downloads. Эта папка содержит дополнительную директорию Runtime, в которой сохраняется весь купленный или загруженный вами материал. Если вы разделите новый материал и материал, установленный вместе с программой Poser, это значительно упростит вашу работу.Читать далее   Жанна-Джоан.

 

Про вдохновение. Нашел для себя один его источник. Нужно сделать в ютубе поиск по абревиатуре DIY. "do it yourself" - сделай сам. Там будут видео про то, как разные чуваки мастерят что-то хайтехническое. Области самые разные. Можно найти клипы и на русском языке.

Есть идея насчёт ИИ... Надо не забыть.

Допустим мы купили в магазине ИИ и даём ему задачу: сделать за нас всю интеллектуальную работу. Нам нет разницы за секунду он это сделает или за минуту, но для самого ИИ, живущего в темпе процессорных тиков, это огромное подспорье. В начале он ничего не умеет делать на тему нашей задачи, это его великая цель, которая сейчас недостижима. Поэтому браться за ключевую задачу сразу для ИИ смысла нет. Но просто так учиться он тоже не сможет, потому что тогда он углубится в какую-нибудь иную сторону и обучение затянется навечно. Поэтому нужно дать ему направление. Тут можно использовать принцип "реки жизни". Когда ИИ получает навыки, которые приближают его к цели, он получает от управляющей системы особые сигналы типа "успех" и, соответственно, если он изучает навык, который не имеет отношения к главной задаче, ИИ получит сигнал типа "провал". В программе ИИ должно быть заложено воспринимать сигналы "успех" как направление исследований, а сигналов "провал" он будет усиленно избегать. Таким образом, ИИ будет "плыть по течению" и сможет вплотную подойти к решению своей главной задачи.

Кроме того, можно разбить его обучение на этапы. Это может оказаться более эффективным, т.к. некоторые вещи для ИИ лучше изучать отдельно, не применяя опыт, полученный из предыдущих сессий. Таким образом, можно разбить обучении ИИ на несколько "жизней", после каждой из которых агрегировать опыт и корректировать его для следующего этапа. Т.к. времени в процессорных тиках у ИИ очень много, то он может "прожить" миллионы "жизней". За этот срок пройдёт какая-нибудь минута реального времени, а ИИ обучится главной задаче и выполнит за нас всю работу.

Вот ещё один метод. Цитирую.

"Подскажу другую методику: о понятии трудового ража. Напомню, что способом его намеренного вызова является мечтание о работе, воображение себе, как будешь мыть пол, надевая тряпку на швабру, или как порежешь овощи и забросишь их в кипящую пучину. А чтобы не отвлечься раньше времени, категорически запрещается себя жалеть. Лишь только появляются такие позывы (у тебя это названо "задумались о лучшей доле") - в этот момент нужно вообразить себе, как хорошо будет пойти бакланить уже с чистой совестью, когда все сделано. А в довесок полезно в такой момент пообещать себе награду: конфетку, пироженко, фильмик. Работа за вознаграждение, как показывает практика, куда более полезный способ "любить себя", чем попытки баловать внутреннее дитя без особой на то причины.

А если удастся в качестве наградной конфетки обещать себе другое занятие (чтение форума, написание рассказика) - тогда и вовсе удастся создать непрерывную цепь действий, повышающую эффективность жизни. Кстати, это должно быть очень легко в силу мучающего многих людей сенсорного голода: они не могут ни единого мига без поступления какой-либо информации. Им обязательно нужно куда-то уткнуться и чем-то заполнить мозг.

Кстати, любопытное наблюдение насчет этой пустоты, которая появляется при безделии: во-первых, она постоянно стремится заполниться внутренним диалогом либо какой-то навязчивым мотивчиков, либо индульгированием (в кастанедианском понимании). Если же этого нет, остается пугающее Ничто, которое в то же время совершенно и составляет основу человеческого существа, побуждая к действию, а в бездействии ведя к всезнанию и всегармонии, Нирване.

Так вот, при определенной практике эта пустота чем-то заполняется. Легче всего ее наполнить болью - тогда, стоит уйти всему другому, остается боль. И это уже очень полезная практика.
Почему?
Да потому что можно залить туда любую эмоцию в итоге, в том числе и неисчислимое счастье."

Мне пришла идея о том, почему нам иногда не хочется что-то делать. Работаешь себе, а потом вдруг понимаешь, что это "скучно", "нудно", "неинтересно" и вообще нафиг это дело. Забиваешь и лежишь на печи. Работа стоит, а срок идёт. И вроде бы уже ничего не поделать с этим состоянием, кроме как действовать "через не хочу". Я заинтересовался тем, откуда берётся это состояние.

Во всём виноват ум и его компаньон - внутренний диалог. Во время исполнения привычной работы он включается и начинает говорить. Это происходит, потому что ничто его не загружает, т.к. работа привычная. А говорит он следующее: "То, что я делаю, скучно и гораздо веселее было бы бакланить. Есть тысячу дел, которые приносят больше удовольствия чем это.". А теперь стоп! Задумайтесь, откуда всё это? Это действительно ВАШЕ желание забить? Я задумался и мне показалось, что нет.

Давайте разберёмся, почему возникает эта мысль. Я думаю, что причина в следующем. Не секрет, что нас постоянно все учат: окружающие, СМИ, книги. Мы уже давно стали конгломератом чужих ценностей и инкубатором распорядков. Так вот, среди этой информации, которая уже давно прочно вшита в наш мозг, есть такой "опыт":
Делаем простую работу -> Забиваем -> Бакланим = Должен быть прирост удовольствия
Уверяю вас, подобные цепочки действий есть в "арсенале" каждого из нас. Вроде бы всё верно: да, типа был такой опыт у нас, когда мы впервые забили на работу и нам стало хорошо. Вот в школе например. Вспомните свои ощущения, когда впервые прогуляли урок. Лёгкость есть? У меня была.

Но дальше начинается путаница. На наш собственный небольшой опыт, накладываются мнения друзей, которые абсолютно идентичны этим. Затем из таких мнений формируется мировоззрение целого общества. Общество школьников, например, или студентов. Забить на уроки всегда было модно, а быть ботаном - да ему не даст никто никогда! Всё это прописывается в наш мозг и укореняется в нём в виде представлений о том, как должно меняться наше состояние. Мы убеждены, что если "забить", то станет легче и веселей. Но так было многие годы назад!!! Мы изменились, работа уже никуда не денется. Нужны новые убеждения, а их ещё нет в нашем "арсенале".

Некоторые люди предлагают переписать outdated-привычки на новые. Это не всегда удаётся, но если есть такая возможность, то лучше прошить в голову новую цепочку. Это работает. Я же предлагаю fast and dirty решение, которое тоже прекрасно работает. Суть его в том, что мы должны детектить ленивые мысли и всяческие мечты о более интересном. Что же делать когда враг обнаружен? Отсекать их? Нет, это не сработает, враг слишком глубоко засел. Поэтому мы "ударим по площадям", а именно просто напросто отключим весь внутренний диалог.
Делаем простую работу -> Задумались о лучшей доли -> Отключаем внутренний диалог = Работаем с удовольствием
Вот вам заклинание на все случаи жизни, пользуйтесь!

Примечание о внутреннем диалоге
Имеется в виду просто отключить все мысли. Инструкции придётся искать самим, потому что всё индивидуально. Один из способов: сконцентрироваться на дыхании. Просто контролировать дыхание. За то время, пока ты его контролируешь напрямую, внутренний диалог не вякнет. Другое дело что в итоге ум всё равно нас обманывает и уводит в сторону, начиная болтовню с собой. Когда же внутренний диалог отключается по настоящему, возникает новое ощущение - лёгкость. Иногда можно реально почувствовать как что-то помимо мозга вмешивается и даёт команду: "Остановить внутренний диалог". Вот к этому надо идти. А вот классический метод, для отдельной тренировки, описанный ещё у Карлоса.

В этом посте речь пойдёт о принципах построения искусственной жизни на основе ИИ, описанного ранее. Я обнаружил одну важную особенность: каждое действие неразрывно связано с состоянием, в котором его можно применять. Под состоянием (S) понимается все необходимые условия, в которых действие может быть исполнено. Т.е. в неоптимизированном идеальном варианте это совокупность всех параметров мира, в модели которого живёт ИИ. В оптимизированном варианте это только явно необходимые параметры без учета "погоды на Марсе".

Если ИИ нашёл новое сложносоставное действие с помощью анализа лога экспериментов, рассмотренного в предыдущем посте, то он обязан привязать это действие к набору параметров S, при которых оно может быть выполнено. Таким образом, к одному и тому же эффекту (состоянию), могут вести несколько действий, как примитивных, так и составных. Подходящее действие ИИ выбирает исходя из условий, в которых он находится.

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

Пусть A0 - множество всех действий прошитых в ИИ при рождении, а S - состояние системы. Тогда в общем виде алгоритм искусственной жизни будет выглядеть следующим образом.

PHP:


// необходимо достичь предустановленного эффекта S1

1.) случайный_перебор_действий(A0, S1)

// эффект S1 достигнут, а также найдены многие другие действия и сохранены в множество A1

// необходимо достичь предустановленного эффекта S2

2.) случайный_перебор_действий(A0 + A1, S2)

// эффект S2 достигнут, а также найдены многие другие действия и сохранены в множество A2

// необходимо достичь предустановленного эффекта S1 и есть действие a75 для его достижения в условиях S75

3.) случайный_перебор_действий(A0 + A1 + A2, S75)

// достигнуты условия S75, теперь можно выполнять действия для достижения цели S1

4.) выполнение_набора_действий(a75)

// эффект S1 достигнут, многие действия откорректированы

...
font>

На шаге 3 и 4 демонстрируется как ИИ выбирает промежуточный эффект S75 в качестве цели для достижения эффекта S1. Теперь о том, что такое случайный_перебор_действий(...) и как он может быть запрограммирован. Всё очень просто:

PHP:


случайный_перебор_действий(A: множество действий, St: целевое состояние системы)

{

  Ac = найти_действия_приводящие_к_эффекту(A, St)

  Ss = извлечь_начальные_условия(Ac)

  while (S != St && not(S in Ss))

  {

    a = A0[random(LEN(A))]

    выполнение_примитивного_действия(a)

  }

  if (S == St)

    return;

  if (S in Ss)

  {

    a = найти_действие_по_начальным_условиям(Ac, S)

    выполнение_набора_действий(a)

    if (S == St)

      return;

    else

      exit("Критическая ошибка, обратитесь к разработчикам.");

  }

}
font>

Функция случайный_перебор_действий(...) всегда должна завершаться удачно, т.е. приводить к искомому эффекту St. Эта функция пытается найти промежуточные точки для перехода к состоянию St и далее перебирает примитивные действия до тех пор пока одна из этих точек не будет достигнута. Если таких точек не нашлось вовсе, эта функция будет делать перебор примитивных действий до тех пор пока не достигнуто условие St.

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

В этом посте я приведу очень простой пример предметной области и алгоритм анализатора экспериментов, указанного в схеме к прошлому посту. Вообще, лог экспериментов - это аналог последовательности команд на языке ассемблера. Поэтому в нём могут быть скрыты условные переходы и циклы за логикой примитивных операций. В данном посте я не рассматриваю варианты поиска циклов и условных переходов в логе экспериментов. Для упрощения понимания сути работы анализатора он будет искать одну единственную каноническую конструкцию - простую последовательность операций. Операция в данном случае означает действие ИИ на объект исследования, выполняемое в ходе эксперимента.

Предметная область
Существует единственный объект исследования, состояние которого описывается набором дискретных параметров. Каждый параметр представляет собой флаг, т.е. может принимать только значения 0 и 1. Для этого объекта допустимо несколько примитивных действий, каждое из которых определённым образом меняет состояние объекта. Изменение состояния объекта имеет внутреннюю логику и недоступно извне. Т.е. объект исследования является для нас "чёрным ящиком". Однако, каждое примитивное воздействие всегда оказывает однозначный простой эффект. Кроме того, существует несколько фиксированных последовательностей команд, которые оказывают на объект новые эффекты. Эти эффекты меняют параметры состояния объекта отлично от примитивных действий.

Над объектом исследования проводится большое количество экспериментов, каждый из которых состоит в применении случайного примитивного действия к объекту и записи в лог его нового состояния.

Цель и задача
Анализатор просматривает лог экспериментов и пытается обнаружить все последовательности команд и новые эффекты, которые они оказывают на объект. Полученные наборы действий являются новыми стратегиями поведения ИИ, что есть результат его обучения. Требуется определить все эти наборы действий.

Модель данных
A - это множество примитивных действий, допустимых для объекта исследования.
A = { a1, ..., ax }.
C - это эксперименты, т.е. последовательность наших действий, применяемых к объекту.
C = { c1, ..., cn }, где ci принадлежит множеству действий A.
S - состояние системы после каждого эксперимента. Каждое состояние объекта состоит из m флагов.
S = { s1, ..., sm }, где si может быть 0 или 1.

Если проанализировать последовательности C и S, то можно выявить удачные блоки, приводящие к новым эффектам на множестве S. E = { e1, ..., el } - это искомые последовательности действий, где ei принадлежит множеству команд A = { a1, ..., ax }.

Алгоритм анализа экспериментов
Для начала необходимо сопоставить каждому действию ci эффект, который оно оказывает на объект исследования. Эффект воздействия - это изменение переменных состояния из множества S. Для того чтобы собрать эту информацию введём хранилище эффектов воздействий и обозначим его множеством D.
D = { d1, ..., dx }, где di = { ds1, ..., dsn };
Каждый эффект - это изменение параметров состояния объекта, которое хранится во множестве S и меняется после каждого эксперимента. Обозначим изменение каждого параметра из множества S структурой ds:
dsi = { S[i][j-1], S[i][j] }.
Как видно из формулы, эта структура хранит два состояния параметра S[i] - до эксперимента под номером j и после. Здесь j - номер эксперимента, который лежит в интервале от 1 до n.
Для построения множества D можно использовать следующий простой алгоритм.

PHP:


j = 2

while (j<=n && LEN(D) < x)

{

  c = C[j]

  a = A[c]

  if (D[a] == NULL)

  {

    d = {}

    for (i=1; i<=m; i++)

    {

      ds = { S[i][j-1], S[i][j] }

      d[i] = ds

    }

    D[a] = d 

  }

  j++

}
font>

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

Теперь можно анализировать весь лог экспериментов C, чтобы найти в нём последовательности действий приводящие к неожиданным эффектам. Для этого предлагается просматривать лог до появления неожиданного изменения состояния и когда оно будет замечено, сохранить несколько предыдущих экспериментов, привязав их к этому эффекту. В данном случае мы будем запоминать 10 предыдущих экспериментов в список T. Далее продолжаем просматривать лог C и при обнаружении уже запомненного эффекта добавляем ему в соответствие новые 10 предыдущих экспериментов. Делаем так до тех пор, пока для каждого эффекта не накопится достаточно количество появлений и соответствующих экспериментов. В данном случае мы ограничимся 3-мя появлениями каждого эффекта. Три эффекта будем считать уже закономерностью. Теперь для каждого эффекта сравниваем группы экспериментов и, если среди них есть одинаковые последовательности команд, Читать далее...

Вот подумалось, так что мысли сырые. А что если изобрести такой стиль программирования, где все объекты жили бы в реальном времени и обменивались сообщениями? Представьте себе стратежку типа Старкрафта. В ней юниты и здания - это программные объекты, которые друг с другом взаимодействуют и в итоге чего там строют. Так вот, если программные объекты представить в виде таких же юнитов, то для них можно будет писать функции жизни, а не реакции на события, как в традиционном ООП. Т.е. представлять себе процесс не виде алгоритма, а в виде взаимодействий объектов, как в реальной жизни.

В традиционном ООП есть корневой объект, который создает другие. Те в свою очередь создают ещё более другие и т.д. В предлагаемом подходе нет никаких внешних контролирующих алгоритмов. Это должна делать виртуальная машина, которая ведёт себя аналогично какой-нибудь стратежке, но с более широкими возможностями программирования юинтов-объектов.

Было бы интересно. Просто для фана, поиграться. А потом, глядишь, и выйдет чего.

UPDATE: всё это называется многоагентными системами. Программировать в них можно вот так например.

Я уже начинаю путаться в своих рассуждениях об искусственном интеллекте. Рассуждения эти происходят исключительно в моей голове, поэтому я забываю, где я нахожусь и к чему пришёл. Чтобы не запутаться во всём этом, я решил написать этот пост, в котором постараюсь обозначить исходную точку своих рассуждений.

Суть самообучения нашего маленького виртуального мозга состоит в том, что он анализирует данные о своих экспериментах и на основе этого анализа строит и запоминает алгоритмы успешного поведения. Для упрощения задачи будем считать, что ВИ (виртуальный интеллект) живёт исключительно ради собственных исследований. Его смыслом жизни является постоянное увеличение базы построенных алгоритмов. Новые алгоритмы поведения будем называть "жизненным опытом", а их построение - "обучением".

Что же он умеет? ВИ умеет совершать различные "действия", которых у него в "арсенале" ограниченное количество. С помощью этих действий он может взаимодействовать с внешней средой. Кроме того, ВИ может считывать "ответы" окружающей среды на его действия. Информация от внешнего мира поступает в виде фиксированного набора "параметров". Ядро ВИ не знает ничего об этих параметрах, для него это просто числа. Система ввода-вывода поставляет ВИ параметрические ответы и обеспечивает исполнение действий, которые ей заказывает ядро. При этом система ввода-вывода может расширить набор доступных действий и сообщить об этом ядру ВИ.

Далее я мог бы расписать математическую модель того как всё это происходит, но я размышляю не формулами, поэтому на данном этапе они ни к чему. Вместо суровых математических значков я приведу пример.

Итак, наш маленький ВИ поселился в сети и теперь общается в чате с девушками, которые, как обычно, ищут эмоций и не знают, что на самом деле их собеседник является программой. Для упрощения рассказа предположим, что ВИ уже достаточно прошарен в искусстве обольщения и у него в арсенале есть такие сложные действия как "поговорить о погоде", "поговорить о кошках", "распросить девушку музыке", "поговорить о романтических фильмах", "распросить девушку о предпочтениях в сексе", "рассказать о своих увлечениях" и т.д. ВИ может с лёгкостью распознавать эмоции в ответах девушки и преобразовывать их свой числовой формат. Также он умеет распознавать в тексте новую информацию, которую ещё не знает. Её он преобразует в числовой параметр "интерес". Кроме того, ВИ умеет определять текущую тему разговора и отслеживать моменты смены темы девушкой. Ему доступны и другие параметры, которые может предоставить система ввода вывода.

Так как девушки - существа пассивные, наш маленький друг будет инициативным. Он сам ломится к разным девушкам и начинает общение. Он пишет им одну из оригинальных фраз для знакомства, использую действие "познакомиться". Некоторые из них не отвечают или посылают его - их он обходит стороной, реагируя на ответ среды "отказ". Когда же девушка ответила что-то более приветливое, ВИ также адекватно реагирует на это, выбирая одну из тем, на которую он будет раскручивать девушку.
Т.к. никаких знаний о собеседнике на этом этапе у нас нет, начинается случайный перебор возможных действий. Всегда, в условиях полной неизвестности которые были у нас лишь в глубоком детстве, мы используем случайный выбор любого из возможных действий.
Выбрав одну из тем и пообщавшись на эту тему с девушкой, ВИ оценивает ответ среды в виде параметров "интерес", "эмоциональность", "знание", "благосклонность девушки" и возможно некоторых других. ВИ запоминает соответствие его действия ответным параметрам, которые пришли от внешнего мира. Далее ВИ продолжает случайным образом перебирать темы, запоминая параметрические ответы окружающей среды на его действия. Разговор на каждую тему является для ВИ экспериментом. После каждого проведённого эксперимента знаний об объекте исследования, коим для него является девушка, становится больше. ВИ уже не будет говорить с ней о недавнем матче Спартака и ЦСКА, если после предложенной аналогичной темы о футболе девушка написала нечто такое, что все параметры ответа оказались достаточно низкими. Однако, если ответ девушки на какой-либо вопрос оказался, например, эмоциональным и благосклонность при этом не уменьшилась, то ВИ конечно разовьёт эту тему, а также все схожие темы, потому что в таком случае он построит новое поведение:

PHP:


action вызывать_переживания()

{

  выбрать_случайную_тему("секс", "гарри-поттер", "бывший бойфренд", "аниме");

  говорить_на_выбранную_тему();

}
font>

Построение такого поведенческого алгоритма станет возможным, если девушка каждый раз будет эмоционально реагировать на каждую из этих тем. Как же ВИ делает такой вывод не будучи конкретно запрограммированным на данную предметную область? Он анализирует результаты проведённых им экспериментов:
[SIZE=2][PHP]
выбрать_тему("секс");
говорить_на_выбранную_тему();
-> проанализирована ответная реакция: { интерес: +2, эмоциональность: +5, знание: 0, благосклонность_девушки: 0 Читать далее...

Моя девушка решила меня порадовать и написала Hello World. Так приятно это!

<input type="button" value=" Нажми меня " ONCLICK="AlertButton()" >
<script>
function AlertButton()
{
window.alert("Hello, World!");
}
</script>

- Достаточно ли уделять час своего времени для работы на эгрегор миссии? (для души)
- По началу.
- Как это по началу?
- А потом втянешься и сам будешь хотеть больше.
- А вот правда. Я вот что подумал. Если у меня начинает теряться интерес к работе, значит я в ходе своей деятельности не работаю даже часа в течение дня на свой эгрегор. Т.е. как-то не так работаю. Сразу приходит в голову такой костыль: вырезать этот час из рабочего времени и заниматься в течение часа чем-то интересным для себя. Это должно восстановить баланс.
- Если теряется интерес - значит ты эксплуатируешь старые наработки и не развиваешься. Очень хорошо, что ты это сразу отслеживаешь.
- Разумеется, но асфальт класть надо довольно часто. Это не идеальное решение, это костыль. В идеале нужно было бы сделать асфальтирование интересным. И если я прав, то эта формула подходит для любой рутинной деятельности. Потому что ранее я посвящал рутинным задачам весь день или не работал вообще - это была ошибка.
- Начнешь заниматься чем-то включающим, поработаешь на энергии часика 2, а потом уже можно будет на этой энергии продолжить класть асфальт, насколько ее хватит.
- Только бы сработало!

Вобщем мотивационный метод использовал такой: берёшь лист бумаги и пишешь там текущие задачи. Слева от каждой задачи рисуешь пустой квадратик как в бланке для голосования. Когда задача будет выполнена, ставишь в квадратике галочку. Листок держишь перед глазами на столе. Очень скоро руки сами полезут выполнять эти задачи. Для меня работает.

Ещё одна очевидная истина о повышении мотивации в работе:
Чтение образовательных книг о конкретном деле повышает интерес к этому делу.
К.О.

Пару дней ковырялся чтобы настроить IDE для серверной и клиентской части одного проекта. Захотелось мне заставить IDE одновременно работать как серверной так и с клиентской частью чтобы не тратить внимание на переключение между разными средами. Сложность в том, что клиент и сервер на разных языках, соответственно на Флеше и на Питоне. И вот наконец получилось!

В качестве основы взял среду FDT4, потому что она быстрая и на ней уже работает Флеш. Установил в неё PyDev и кучу разных плагинов, в т.ч. для синхронизации с удалёнными серверами. Серверную часть пока запускаю на той же машине, что и клиентскую, но ничто не мешает и править серверный код удаленно потому что есть RSE для Эклипса. Отдельная проблема была с FlashPlayer, потому что для юнит-тестов он совершенно не нужен и его окошко надо было спрятать. Как это сделать нормально пока не знаю, может быть надо писать тесты на Adobe AIR. Я же извратился и вызываю плеер через браузер в одной и той же вкладке, а само окно браузера скрыл навсегда сторонней утилиткой. В результате у меня получилась IDE с двумя консолями и двумя проектами, где ничто не отвлекает от сути.

[700x526]