» Эволюция в виртуальной машине

Цитата:

Вам стоит подумать над системой плагинов, чтобы любой мог подключить к вам своего "монстра"

идея безусловно великолепная, но мы с этим пока подождем. Сейчас задача -- создать простую и понятную схему с минимальным набором параметров. Любые замечания и предложения принимаются с радостью, так же, как и критика. Признаюсь, что с C# не работал. Однако не хочу его использовать не поэтому. Для меня прежде всего важны алгоритмы и структуры данных. А язык -- всего лишь надстройка. Еще раз повторю: можно (и нужно) писать на любом языке. Но для этого нужно разработать базу. Вот ее-то сейчас и попытаемся реализовать на C/C++.

Да, ну так че с нашими классами?

beeos
Базовые классы надо реализовывать абстрагируясь от языка. Тогда можно будет с лёгкостью их реализовать через файлы настроек. Ведь только представь, какой гемморой тебе предстоит при общении между классами из разных языков ? Тогда уж тут и COM, DCOM, ActiveX и пр. лабуда полезет. Поэтому, имхо, вам надо создать "язык" описания creatures, их свойств и поведений. Потому что начав разработку на С++ (который, я тоже очень люблю ), вы заранее ограничиваете себя в дальнейших разработках.
Меня это тоже интересует, потому как одной из первых программ была программа "Жизнь"/"Life" в далеком 86 году

Кто-то слышал про Tierra?
Я ее как-то скачивал, смотрел... Кажется, это одна из самых знаменитых програм, даже где-то исходники есть. Может ее покалупать в поисках идей или будем использовать только свою фантазию.

Я за то, чтобы писать на С++.

Давайте обсуждать классы!!!

Повторюсь, что я человек здесь случайный, но, думаю, что к моему совету "разработать бизнес-модель" абстрагировавшись от языка программирования стоит прислушаться. Поверьте опыту человека с не одним успешным проектом, в том числе и на мировом уровне [нескромно ? зато честно ]
Просто не хочется, чтобы проект умер после пары тысяч строк кода

Я согласен с тем что писать надо абстрагируясь от строгостей Си. Поэтому и говорю - давайте на Дельфи ибо Дельфи ближе к языку человека.
Но в принципе мысль вообще не привязываться к языку тоже правильная.

Плагины это круто

beeos
Создавая

Цитата:

простую и понятную схему с минимальным набором параметров

нужно не забывать о универсальности и расширяемости. Это вполне сочитаемо я думаю.

допустим есть некий объект

TArea // ячейка местности
x,y // ее координаты в "матрице"
t // средняя температура в ячейке
food //количество еды (ессно вегетарианской)
plod // плодородность (скорость восстановления еды (ессно вегетарианской) )
nice // духовная красота ячейки (насколько по кайфу в ней находится для высокоразвитого сущ-ва)
accs //доступность ячейки (сколько энергии надо потратить для входа/выхода/проезда мимо)

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

Unconnected, это не серьезно.
Говорилы - балакалы... Читайте выше, там уже описано много свойств и немного детальнее...

Независимо от того, к чему прийдет общественная мысля в этой теме, конкретно я писать буду на С++. Точнее - на Билдере.

Crazy_Shrike
Там где как ты говоришь, написано, не указаны ни комментарии, ничего.
Ты думаешь написав
Код: class CEssence
{
public:
CEssence();

int GetLifeTime();
int GetMass();
void AddMass();
int GetEnergy();
void AddEnergy();
int GetSex();
int GetLibido();

Цитата:

нужно не забывать о универсальности и расширяемости. Это вполне сочитаемо я думаю.

Цитата:

совету "разработать бизнес-модель" абстрагировавшись от языка программирования

Солидарен со всеми в принципе это и имел ввиду...

Цитата:

Сейчас задача -- создать простую и понятную схему с минимальным набором параметров

и
Цитата:

А язык -- всего лишь надстройка

Еще раз:

Цитата:

Ведь только представь, какой гемморой тебе предстоит при общении между классами из разных языков

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

Crazy_Shrike

Цитата:

Unconnected, это не серьезно. Говорилы - балакалы...

Не согласен. Есть интересные идеи.

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

Гм. Сорри.
В команде не писал, правда.

класс CEssence - класс для наших объектов.

CEssence - конструктор (случайная инициализация хромосомы, координат x,y)

int GetLifeTime() - вытягивает из хромосомы (двоичной) значение времени жизни и возвращает как целое...

int GetMass() - то же, возвращает массу...

int GetEnergy() - ...энергию...

int GetSex() - пол...

int GetLibido() - ... радиус видимости потенциального портнера...

Методы типа IncMass(), IncEnergy() - добавляет единиу к соответсвующему атрибуту...

по аналогии, DecMass(), DecEnergy() - вычитает единицу...


Итак,

class CEssence
{
public:
CEssence();

int GetLifeTime();

int GetMass();
void IncMass();
void DecMass();

int GetEnergy();
void IncEnergy();
void DecEnergy();

int GetSex();

int GetLibido();
void IncLibido();
void DecLibido();

private:
bool hromosoma[100];
int x;
int y;

};

Схема хромосомы: название, длина, диапазон возможных значений, диапазон битов в хромосоме, соответственно:

Life time - 20 bit, [~10^6]; 0-19
Mass - 10 bit, [~10^3]; 20-29
Energy - 10 bit, [~10^3]; 30-39
Sex - 1 bit; 40
Libido - 10 bit, [~1^3]; 41-50

Атрибуты - двоичная хромосома длинной 100 бит, две координаты.

И я ни кого не обзываю, просто есть атрибуты, которые мы уже довольно подробно и поочереди обсудили.




Добавлено
Гм. Сорри.
В команде не писал, правда.

класс CEssence - класс для наших объектов.

CEssence - конструктор (случайная инициализация хромосомы, координат x,y)

int GetLifeTime() - вытягивает из хромосомы (двоичной) значение времени жизни и возвращает как целое...

int GetMass() - то же, возвращает массу...

int GetEnergy() - ...энергию...

int GetSex() - пол...

int GetLibido() - ... радиус видимости потенциального портнера...

Методы типа IncMass(), IncEnergy() - добавляет единиу к соответсвующему атрибуту...

по аналогии, DecMass(), DecEnergy() - вычитает единицу...


Итак,

class CEssence
{
public:
CEssence();

int GetLifeTime();

int GetMass();
void IncMass();
void DecMass();

int GetEnergy();
void IncEnergy();
void DecEnergy();

int GetSex();

int GetLibido();
void IncLibido();
void DecLibido();

private:
bool hromosoma[100];
int x;
int y;

};

Схема хромосомы: название, длина, диапазон возможных значений, диапазон битов в хромосоме, соответственно:

Life time - 20 bit, [~10^6]; 0-19
Mass - 10 bit, [~10^3]; 20-29
Energy - 10 bit, [~10^3]; 30-39
Sex - 1 bit; 40
Libido - 10 bit, [~1^3]; 41-50

Атрибуты - двоичная хромосома длинной 100 бит, две координаты.

И я ни кого не обзываю, просто есть атрибуты, которые мы уже довольно подробно и поочереди обсудили.

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

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

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

2Crazy_Shrike
Вот твой класс ячейки

Код: class CCell
{
public:
void SetEnergy();
int GetEnergy();
void SetMass();
int GetMass();

private:
int energy;
int mass;
};

Я как-бы и не видел твоего класса...

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

Цитата:

TArea // ячейка местности
x,y // ее координаты в "матрице"
t // средняя температура в ячейке
food //количество еды (ессно вегетарианской)
plod // плодородность (скорость восстановления еды (ессно вегетарианской) )
nice // духовная красота ячейки (насколько по кайфу в ней находится для высокоразвитого сущ-ва)
accs //доступность ячейки (сколько энергии надо потратить для входа/выхода/проезда мимо)

Не упираясь в язык программирования - это он и есть

Ок.
Тогда вопросы...

За что отвечает температура ячейки и духовная красота? ... или на что влияет.

Не напрасно ли Вы спорите?
Имхо UncoNNecteD более прав - есть смысл абстрагироваться от синтаксиса конкретного языка программирования и составить описание модели человеческим (приближенным к нему) языком.
В свою очередь скажу, что все (?) параметры ячейки/существа со временем могут менятся?
Но в начале вс-же стоит просто описать модельь БЕЗ учета возможных измененений.

ALL
модель нашей вселенной с помощью UML не желаете порисовать?

GreyGendalf
Это как ?

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

Духовная красота - абстракция, например приятно находится в светлой большой комнате, а не в душном маленьком подвале. Этот параметр необходим, что бы Искуственной Жизни придать окрас реальности - чтобы существа стремились к чему то.
Этот параметр, я думаю, можно складывать из нескольких (например формульно объем+красота/количество_смертей_в_ячейке - это естественно просто пример, надо его прорабатывать, к чему и призываю)

unhappy
thnx за понимание
Что ты подразумеваешь под "изменяться" ?

Добавлено
З.Ы. Забыл заметить, что любовь к духовной красоте тоже желательно прописать в генах, например отталкиваясь от интеллекта...

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

Добавлено
объем ячейки, имхо, - это лишнее... На что он будет влиять?

1. Глупо помоему - время жизни не зависит от условий проживания ? Посмотрю я на тебя - поживи ка на вокзале в обнимку с мусоркой...

2. Объем надо задавать - он влияет на то - сколько там может жить тварей и если процент заполнения высок - понижать компфортность (аналог гибели от перенаселения в ЖИЗНИ)

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

Да! Объем говорит о том как много особей сможет себя комфортно чувствовать одновременно в одной ячейке. При превышении нормы уже штрафы пойдут.

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

В связи с этим предлагаю следующий тип объекта коордтнаты:

class t_coord
{
double x,y;
double energy,garbage;
constr ...
destr ...
friend get_new_coord(double dx,double dy);
friend get_new_energy(double x,double y,double *obj_energy, double *obj_garbage);
friend get_new_garbage(x,y,*obj_energy,*obj_garbage,*world_garbage);
};


class t_obj
{
...
t_coord my_coord;
class t_gen_set;
...
};


class t_gen_set
{
...
double my_energy,my_garbage,my_age;
...
};

Здрасьте.

Я тут немного покодировал за последние дни, с динамическими массивами разобрался...
Нужно ли все-таки вводить объем ячейки? Было предложено, что объемом будет выступать максимально возможное количество особей, пребывающих в ней одновременно. Я так и не понимаю цели этого. Не лучше ли, что бы просто шла борьба за лучшие ячейки? А нападать можно только с соседних, где условия, по всей видимости, хуже. Еще один аргумент - если в одной ячейке будет несколько организмов, а поле 100х100, какова же может быть численность популяции? У меня она автоматичнски ограничивается числом ячеек - 10*4. Господа! В ходе проведенных экспериментов выяснилось, что на обработку одного такта при популяции 3 тыс. особей уходит больше секунды! (P-IV, 1,6GHz) Это при том, что выполнялось всего несколько методов кодирующих и декодирующих параметры двоичной хромосомы. Имхо, аргумент сильный. Можно, конечно, уменьшить размеры среды... но это будет уже не интересно.
Насчет псевдобесконечности пространства, я почти ничего не понял, но если то, о чем я подумал, пространство можно легко замкнуть, т.е. когда после 100-й ячейки идет нулевая, ну и т.п.

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

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

А на счет времени, при меньшей популяции (10) и при большей (100000) время сильно изменялось? Ведь Вы же проходите все клетки поля, а экономнее было бы только те, в которых кто-то есть.

И, опять же, цель жизни объектов не занять клетки, а увеличить свою популяцию.

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

Насчет разных видов... Я это пробовал раньше. У меня был основной вид, вид, который слыжит для него пищей и истребитель, который кушал первых. От вида, который представлял еду, де еще, как объекты (т.е. каждый организм еды был тоже объектом, но сильно упрощенным), я отказался, т.к. в этом пропал смысл. Снова-таки, лишние машинные ресурсы для работы с популяцией "еды", да и идея просто "искать" еду показалась более правильной. Объект бродит себе ("осознанно" или случайно) и собирает ресурсы. Потом я со скрипом в зубах решил отказаться и от единственного истребителя, заменив его на естественный отбор, что, как мне кажется, тоже верно. Вот так я скатился от цепочки из трех звеньев к одной.

И я снова не понимаю... Вы предлагаете заменить пищевую пирамиду на неограниченный объем... Вапще не понял. Что между этим общего???

Если этого не сделать, то популяция обречена на полное уничтожение (не хватит ресурсов) через конечное время, а при неограниченном мире их будут сдерживать от разбегания необходимость размножения, так получиться более-менее стабильное равновесие.

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

Кстати, это... кто говорил, что динимический массив и индексация - извиняюсь, геморрой. Ниче подобного, даже, где-то, красиво...

Посмотрите на реализацию координаты выше. Каждая координата прикреплена к объекту, и новая координата генерируется friend функцией, для данного объекта.

А зачем трудности с регенерацией, они только усложнят код. Так получается, что нужно всего 4-5 функций. для нахождения новых координат, энергии, возраста, загрязнения, и размножения.

А сами объекты можно хранить где угодно, хоть в списке, хоть в массиве.

Тут, мы, наверное, разойдемся во мнениях. Я делаю более прямолиннейнее, при этом отдавая себе отчет, что прямолинейность не всегда оптимальна. Зато прозрачна.
Лучше еще раз обсудим бесконечность. Мне эта идея нравится все больше. Я так понимаю, Вы предлагаете не ограничивать координаты. Что помешает им бесконечно увеличиваться?