ТОМ2 - платформа для парсерных игр

Объявление

Платформа ТОМ предназначена для создания текстовых игр на русском языке и имеет развитый парсер, позволяющий взаимодействовать с играми с помощью команд на близком к естественному языке. В данный момент активно разрабатывается версия ТОМ 2.
Последнюю версию платформы можно скачать здесь.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.



Новый ТОМ

Сообщений 31 страница 60 из 62

31

20%

32

Ты писал, что первый ТОМ не прижился, т.к. на нём было трудно писать. Я тут разбирался с альфой ТОМ2, так мне показалось что он значительно сложнее чем первый. Сейчас вместо знаний основ программирования и набивания лексем надо лезть вглубь лингвистики, высшей математики и логики отношений. Усугубляет положение полное отсутствие документации. Идёт просто перечисление нововведений (и то в лучшем случае). А ведь в очень маленьком примере to_pawn уже можно заметить очень много разных "категорий". И если с "слово", "предлог", "локация" ещё можно разобраться. То все эти свойства, правила, признаки, отношения, факты, действия гарантированно обрубают нить понимания. Остаётся только тусклая надежда, что стандартная библиотека упростит программирование на ТОМе.

Кстати, проект ещё жив или уже закрыт? А то может зря я всё это пишу.

Отредактировано Alexandr (2012-08-09 14:12:29)

33

Жив, жив проект  :flag:
Спасибо за поддержку и не ослабевающий интерес!

Вообще да, все сложности придумываются для написания стандартной библиотеки. Без них реализовать приемлемый уровень платформы не получается, на первом ТОМе это проверено.
Никто не будет заставлять авторов этим всем пользоваться непосредственно.

Проект затормозился по 2м причинам:
- Сейчас приходится переписывать много кода и отлаживать его заново, что действительно нужно, но не очень вдохновляет.
- Билдер 6 меня подвёл. Перестал компилиться отладчик, сделанный примерно уже на половину. Причем ошибка в недрах VCL и ничего с ней не поделаешь. Буду переписывать на билдере 2009. В итоге получиться даже лучше, но из колеи это выбило...

Что касается документации, то писать её для альфы рановато... всё еще очень зыбко и не устоялось.
Например, я полностью выкинул старую систему локаций и заменил её на лучшую. Очень хорошо что не потратил время на документацию для неё :)

Впрочем, никто не запрещает задавать вопросы :)
Для 1го ТОМа это у нас неплохо же получалось ;)

34

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

35

40%

36

Деструкторы по прежнему не будут поддерживаться ТОМ-ом? Т.е. один раз созданный объект в игровом мире нельзя будет удалить/выгрузить из памяти платформы до перезагрузки? А что именно мешает сделать такой механизм выгрузки объектов? Во что упирается это ограничение?

37

Вот как раз текущий рефакторинг позволяет сделать удаление объектов. (Но я не уверен что для игр это нужно).
До этого удалять их было проблематично, так как ссылки хранились в виде прямых указателей на объекты. Т.е. нужен был бы сборщик мусора, который умел бы проходить по всей базе и подчищать указатели на удаляемый объект.
Сейчас я ввел внутренний id объекта. С ним всё гораздо удобнее, но скорость доступа к объекту, правда, немного теряется.

38

ASBer написал(а):

Вот как раз текущий рефакторинг позволяет сделать удаление объектов. (Но я не уверен что для игр это нужно).

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

ASBer написал(а):

Сейчас я ввел внутренний id объекта. С ним всё гораздо удобнее, но скорость доступа к объекту, правда, немного теряется.

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

39

Да, глобальный список объектов с бинарным поиском по id конечно же есть :)

40

50% или около того...
Сегодня-завтра опубликую демку.

41

Да, РИЛ сообщество совсем не заглядывает на форум и энтузиазм что-то делать куда-то пропал.
Если так трудно делать ТОМ одному или если времени совсем мало, то может будет неплохой альтернативой залить ТОМ куда-нить на SVN и дорабатывать его вдвоём? Я не говорю, что у меня особо много времени, особенно после последних событий, но может вдвоём оно будет как-то веселей и энтузиазм вновь появится.
Вообще, какие причины? Мало времени, отсутствие заинтересованных в ТОМе лиц, личные причины, или может подход к созданию текстового парсера ТОМ вдруг оказался неработоспособным/нереализуемым?

42

Alexandr написал(а):

Если так трудно делать ТОМ одному или если времени совсем мало, то может будет неплохой альтернативой залить ТОМ куда-нить на SVN и дорабатывать его вдвоём?

Ох, боюсь что администрирование совместной разработки съест всю выгоду от дополнительной пары рук.

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

Вообще нужно добить движок, хотя бы с минимальной функциональностью. Далее там будет большая работа со словарём и стандартной библиотекой, вот её можно попробовать поделить.

Вообще, какие причины? Мало времени, отсутствие заинтересованных в ТОМе лиц, личные причины, или может подход к созданию текстового парсера ТОМ вдруг оказался неработоспособным/нереализуемым?

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

43

ASBer написал(а):

Ох, боюсь что администрирование совместной разработки съест всю выгоду от дополнительной пары рук.

Тебе решать. К тому-же знаниями C++ я особо не блещу. Но SVN довольно простая штука, я как-то вёл проекты, так там баг-трекер есть (очень удобная вещь), сервер сам сверяет различия в ревизиях и сливает правки разных программистов в одну версию.

ASBer написал(а):

Вообще нужно добить движок, хотя бы с минимальной функциональностью. Далее там будет большая работа со словарём и стандартной библиотекой, вот её можно попробовать поделить.

Возиться со словарями я люблю :)

ASBer написал(а):

Видимо любой долгоиграющий проект вызывает "усталость" от проекта. Я просто выдохся

Отдых тоже нужен. Я как-то разрабатывал не свой проект около полугода, изматывает сильно. А ты ведь уже больше трёх лет ТОМ делаешь?

ASBer написал(а):

Вобщем, я надеюсь на новогодние каникулы.

Только сильно не усердствуй. Новый год тоже отмечать надо.  ^^

44

Alexandr написал(а):

Возиться со словарями я люблю

Запустить MySQL не получилось? Очень надо  8-)

45

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

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

46

Ждём :crazy:

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

47

Alexandr написал(а):

Жаль что отладку пришлось выкинуть.

Тут речь не о пошаговой отладке кода, а о логе работы парсера. Какие парсерные комбинаторы в какой последовательности срабатывают и почему. После тщательной настройки парсера необходимость ковыряться в этих логах скорее всего пропадет.
А пошаговый отладчик кода все еще стоит в отдалённых планах (если осилю  :crazy: )

48

Встал в тупик при подборе русского аналога для ключевого слова this.
Слово "это" уже занято... а больше на ум что-то ничего не идёт: "этот", "этот_объект" - коряво всё.
Есть еще вариант вообще заменить на focus и фокус, так может даже понятнее будет, хотя и не в традиции ООП.

49

В делфи аналогом является Self (переводится как "сам"), что тоже не очень звучит. А сложно сделать определение контекста употребления слова "это"? Ведь можно чётко определить в каком из смыслов употребляется это слово в коде:

Код:
стол это мебель
если это = мебель то ...

Или это тоже не в традиции ООП, или сложно реализовать? В любом случае, если не придумаешь что-нибудь другое, то оставляй "фокус". Хоть и смысл совсем другой. This - это объект, в котором сейчас описывается код. А фокус больше похоже на "отмеченный" в данный момент объект.
Плохо совпало, что it и this одинаково переводятся как "это".

Отредактировано Alexandr (2013-04-21 12:47:36)

50

Alexandr написал(а):

А сложно сделать определение контекста употребления слова "это"? Ведь можно чётко определить в каком из смыслов употребляется это слово в коде

Да, так можно было бы сделать, но есть одна пакость: если это = is и это = this, то и is = this.
То есть будут работать и такие конструкции:

Код:
стол this мебель
если is = мебель то ...

а этого не хочется...

51

Alexandr написал(а):

В делфи аналогом является Self (переводится как "сам"), что тоже не очень звучит.

Мне этот вариант всё больше и больше нравится. В коде игры Self (или Сам) будет чаще всего применяться по отношению к персонажу в коде функций-действий. И в этом контексте применение слова "Сам" выглядит вполне осмысленно =)

52

Чем дальше углубляюсь в написание библиотеки, тем вылезающие баги платформы всё тоньше и тоньше...
:crazy:

53

ASBer написал(а):

если у Маши нет мяча тогда дать Маше мяч //ключевые слова TOML заменены русскими синонимами
дать Маше мяч если у неё его нет //директива полностью на естественном языке


В правильном направлении идете, товарищи! Но вы ползете через горы, а нужно по прямой.

54

Сейчас уже готов выложить очередную версию. Всё что хотелось сделать в движке в этом релизе - сделано.

Но есть много всякого, не такого важного, чем хотелось бы позаниматься:
- Вылизывание веб-интерфейса. Иногда лезут непонятные ошибки сокетов, видимо не всё я с ними правильно делаю. Хотя на работу интерфейса ни как не влияет - ругается но работает =))
- Переписывание библиотеки с использованием новых возможностей движка. Сокращается масса кода.
- Оформление демо-игры. Хочется использовать возможности html, и сделать наконец всё красиво.

В общем, подожду пока релизиться. Поковыряюсь еще пока не надоест, как надоест - выложу.

55

Платформа наконец достигла того состояния, когда можно спокойно заняться библиотечным кодом.
Цель №1 - догнать по количеству выполняемых стандартных действий ТОМ 0.9;
Цель №2 - догнать по количеству выполняемых стандартных действий рТАДС 2.

56

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

Работаем =)

57

Неплохо бы иметь возможность удобно посмотреть содержимое стандартной библиотеки. Раньше была программка dic_viewer, но для новых версий её нет. В TOM2IDE я не разобрался толком, не нашёл где там посмотреть полное дерево классов. Вот копался сейчас с платформой, хотел создать объект "бутылочка зелья", но не могу посмотреть, от какого класса её лучше создать и какие свойства там уже есть, какие придётся переписывать/дописывать.

58

Alexandr написал(а):

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

Да, необходимость в dic_viewer отпала. Режим отладки делает всё тоже самое и еще больше.

Alexandr написал(а):

В TOM2IDE я не разобрался толком, не нашёл где там посмотреть полное дерево классов. Вот копался сейчас с платформой, хотел создать объект "бутылочка зелья", но не могу посмотреть, от какого класса её лучше создать и какие свойства там уже есть, какие придётся переписывать/дописывать.

Достаточно вбить интересующие слова в командную строку:
http://sa.uploads.ru/t/sp3RX.png
На скрине видно, что про бутылочку платформа честно говорит, что такого слова не знает, и следовательно класса такого тоже нет.
Для слова "бутылка" видно что найден класс "@бутылка", и для него можно посмотреть словарную статью, дерево классов и список свойств.
Если пройти по всему дереву классов, можно увидеть все унаследованные свойства объекта.

59

Вот интересный вопрос выявился: бой идёт до смерти одного из противников; по окончании боя проигравшему присваивается признак "мёртвое".
А как же быть с нежитью? Ведь она с самого начала мертвая  :confused:
Чем "мёртвое" нежити отличается от "мёртвого" живого? Понятно что это магия и одним признаком тут не обойтись, но как это сделать более логично вообще никак в голову не идёт... что может быть не логичнее зомби, скелетов и вурдалаков?

60

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