Интерактивные программы
Poly, он этим подробно занимался.
В самых общих чертах: есть десятки различных методов позднего связывания. Зачем тебе собирать все стратегии в один исходник?
Также есть средства, позволяющие ограничить язык.
Что касается готовых игрушек, поищи "бои в памяти". Там, правда, вроде, обычно свои языки используются.
есть хорошие методы. Обратись лучше к
Чисто случайно пробегал вчера мимоВ самых общих чертах: есть десятки различных методов позднего связывания. Зачем тебе собирать все стратегии в один исходник?
Также есть средства, позволяющие ограничить язык.
Что касается готовых игрушек, поищи "бои в памяти". Там, правда, вроде, обычно свои языки используются.
2) Создается абстрактный язык и под него пишется интерпретатор. Тогда здесь есть полный контроль, в целом все что надо, но недостаток, в том, что пользователям нужно работать на непривычной языке, непонятно как отлаживаться и т.д. Кроме того для хорошего (достаточно сложного) языка сложно написать интерпретатор.
Этот вариант самый реальный, так как:
1. Обычные языки мало приспособлены к решению подобных задач - они скорее универсальные - лучше использовать специализированный язык - он будет проще, поэтому на нем смогут научиться программить даже те, кто программить до этого не умел;
2. Для многих языков есть так называемые компиляторы компиляторов (на Java такое точно есть - пробовал, про остальное только слышал, поэтому не помню так что основная сложность - придумать язык, а интерпретатор писать не придется
![](/images/graemlins/cool.gif)
Один вариант придумался - можно написать на флэше контейнер, в который будут загружаться флэшки со стратегией пользователя (причем контейнер может выглядеть как поле битвы, а флэшки - как бойцы, например). Тогда достаточно будет оговорить ограничения на структуру этих флэшек и каждый сможет наваять, что захочет.
Но у флэша нет продвинутых средств контроля за ресурсами для такой ситуации, поэтому возможно случайное/нарочное создание бойцов, которые будут убивать арену
![](/images/graemlins/grin.gif)
Наглая ложь скрыта здесь.
---
...Я работаю антинаучным аферистом...
Хороший и достаточно сложный - в лучшем случае независимые характеристики ЯП.
---
...Я работаю антинаучным аферистом...
Только ни за что не пытайся запускать пользовательские приложения как отдельные треды, которые будут постоянно что-то делать. С.Б. Березин один раз такое сделал, и мне, как участнику, результат нифига не понравился - ужасно тормозно и ненадёжно всё получается, плюс огромное пространство для злоупотреблений.
Лучше всего сделать "виртуальное время" и несложный интерфейс с одной функцией клиента "Обработать Очередной Виртуальный Таймслайс". Причём входная информация в каждом клиентском таймслайсе всегда относится к его началу, а вот принятые решения (команды на управление виртуальным танком) могут приниматься виртуальной системой управления как в условно-реальном времени, так и после возвращения из функции. Ну так вот, длительность каждого слайса точно замеряется, а потом слайсы разных клиентов кладутся на одну и ту же временную ось.
Плюс, естественно, отдельный тред, который будет вырубать подвисших клиентов.
Придумывать свой интерпретируемый язык - это Настоящее Зло. Потому что неопытный человек ни за что не придумает хороший язык. Я когда-то давно хотел поучавствовать в каких-то сибирских robot warz, скачал описание их объектно-ориентированного макроассемблера, почитал немножко, срочно проблевался и решил не учавствовать.
В данном случае лучше даже не просто .net, а mono. Плюсы: там сразу будет и бейсик и паскаль, а главное, будет работать где угодно (Win, Mac, Nix).
Имхо, вариант с написанием интерпретатора лучше.
когда мы с Poly обсуждали эту идею (тогда планировалась джава пришли к выводу, что удобно делать парсер джавовского кода на предмет допустимых (или недопустимых) конструкций. После чего просто юзать проверенные классы, линкуя их на лету.
Чем лучше?
Я когда-то давно хотел поучавствовать в каких-то сибирских robot warz, скачал описание их объектно-ориентированного макроассемблера, почитал немножко, срочно проблевался и решил не учавствовать.Ой, как не хочется влезать в изначальный флейм
Но имхо, эта фраза вообще ничего не доказывает и ни о чём не говорит;)
Контролем:)
А в .net для этого есть Code Access Security =)
Про игру Террариум слышали? Microsoft проводило ее в 2002 году перед запуском релиза Visual Studio .Net. Суть была в следующем: есть миры (на каждом из компов участников там живут растения и животные. Участнику предлагалось написать свое животное или растение (физически - класс в .net). В процессе игры существа могли попадать на чужие компьютеры. Участники не смогли выйти за пределы своей песочницы. Так была продемонстрирована надежность политик безопасного выполнения кода в .net
если не ошибаюсь, Поли это потом один, без меня, реализовал. В дотнете. Наверно, именно с CAS.
Но не сложилось%)
Ну, значит, .Net
![](/images/graemlins/wink.gif)
![](/images/graemlins/smirk.gif)
Как предлагается интегрировать в рамках Лиспа программы на Pascal и С? Как назначить им необходимые права и не дать больше, чем захочет администратор системы?
squirrel, от одного из разработчиков FarCry (http://www.squirrel-lang.org)
lua, используется во многих играх и пр., море документации и исходников (http://www.lua.org)
"Войны машин"
Отличная игруха - всю ночь стратегии писал, спасибо за ссылочку.
А что-то подобное для Паскаля есть?
2. На худой конец, можно поддерживать ограниченное подмножество языка,
для которого и песочницы не понадобится.
---
"You've got TECO. What more do you want?"
---
...Я работаю антинаучным аферистом...
>Как предлагается интегрировать в рамках Лиспа программы на Pascal и С? Как назначить им необходимые права и не дать больше, чем захочет администратор системы?
B Лиспе есть функция eval, которая позволяет исполнять любой лисповый код. Если перед этим производить фильтрацию этого кода, и разрешая символы только из юзерского package и COMMON-LISP package (запретив символы связанные с вводом/выводом и т.п. - можно заменить их на безопасные из другого package то юзер не сможет сделать ничего плохого (в стандарте Common Lisp очень мало потенциально опасных функций).
какая стоимость и надежность этого решения?
ps
понятно, что на любом языке можно сделать все что угодно - все упирается только во время, стоимость и качество разработки.
>Как предлагается интегрировать в рамках Лиспа программы на Pascal и С? Как назначить им необходимые права и не дать больше, чем захочет администратор системы?
На эти вопросы простого ответа Лисп не дает?
С надёжностью сложнее, но и это осуществимо.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Ни один вменяемый человек не будет решать такие сложные задачи на паскале или сях, если есть лисп.
Кроме того, почти всегда есть FFI.
На худой конец, есть IPC.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Автору темы надо было написать систему, которая будет хостить программы на Pascal и C (т.е. это уже дано, нельзя заставлять всех пользователей системы писать на Лисп) в своем адресном пространстве, причем с требуемыми разрешениями на код. Так вот, на Лиспе простого решения не видно.
А чо, уже появился эффективный компилятор лиспа?
![](/images/graemlins/smile.gif)
Всем спасибо за советы. Немного информации я для себя из обсуждения извлек. Учитывая, что конкретных предложений фактически не поступило, предлагаю завершать обсуждение темы.
Почему бы ещё лет десять не поспать?
---
...Я работаю антинаучным аферистом...
>> 2) Создается абстрактный язык и под него пишется интерпретатор.
---
...Я работаю антинаучным аферистом...
Оставить комментарий
dam555
Хочется разработать модуль (игровой сервер который бы позволил участникам писать свои стратегии (на паскали и/или си чтобы потом эти стратегии можно было стравливать друг с другом и проводить соревнования. С точки зрения участников должно быть все прозрачно - они подключают некоторую библиотеку, к которой выдается документация, вызывают функции этой библиотеки в нужном порядке и тем самым описывают свою стратегию. Проблема возникает с самим модулем. Можете ли вы описать архитектуру этого модуля? Эта разработка нужна для летней школы и не требует профессионального подхода, безопастности и т.д.Я знаю несколько подходов но в моем случае они не работают:
1) Если язык программирования один, тогда все стратегии можно было бы объединить в один большой исходник, все компильнуть и потом смотреть результаты. Недостаток, здесь в том, что если падает одна из стратегий участников, то сразу все соревнование накрывается. Видимо нужно стратегии запускать в разных процессах, но при этом должна быть возможность полноценной отладки своих программ.
2) Создается абстрактный язык и под него пишется интерпретатор. Тогда здесь есть полный контроль, в целом все что надо, но недостаток, в том, что пользователям нужно работать на непривычной языке, непонятно как отлаживаться и т.д. Кроме того для хорошего (достаточно сложного) языка сложно написать интерпретатор.
Может быть кто-то сталкивался с такими игрушками в интернете и видел удачное простое решение?