Dmitry__, с таким же успехом может быть применено почти к большинству сообщений на форуме.
Scorpio, на шарпе сделать вообще проблем мало во всех смыслах. популярных и хорошо зарекомендовавших подходов на самом деле очень мало, тем не менее реализовывают их ооооочень сильно по разному, иногда даже не сразу и понятно, какой подход использован или какие намешаны. да и fsm, goap, strips, htn, behaviour tree,... это одно, а есть ещё куча других вещей, которые куда сильней влияют на всё. наглядней наверно проще будет, вот один из предыдущих вариантов реализаций с деревьями
http://pasteboard.co/1CdJR4kMR.jpgсамый простой вариант - в самом дереве нет событий, прерывателей, автоматической сборки, настройки и кучи других полезных вещей. на всякий, в wait и sleep оно не торчит всё это время - вызвалось, вернуло результат и всё. это работа с итераторами, в данном случае с yield. когда в другом проекте эксперементировал с гуи программированим, было удобней ссылки хранить - ветка задавалась не жестко в коде, все нужные данные заносились в переменные (генератор кода и компиляция конечно вариант, но неоправданно много возни с этим). ещё один момент - к wait или sleep оно может и не вернуться, т.е. хоть никогда. более поздний вариант
http://pasteboard.co/1Cuhb3ivt.jpgреализация дерева (библиотека деревьев) вообще не менялась, а в общем отличается очень сильно - есть прерыватели, события, код в общем слабо связанный. вот пара примеров как происходит сборка некоторых вещей
http://pasteboard.co/1CsKL5vzP.jpghttp://pasteboard.co/1CtdRAlO7.jpgвнедрения зависимостей тут даёт больше гибкости - сборка и настройка контейнеров может быть автоматической, вручную в коде, с использованием конфигурационных настроек (в файле, базе,...) и комбинировать. если работал где-то с контейнерами, это понимаешь. нет, почитай про внедрение зависимостей (ioc, di и т.д.), посмотри как оно на практике используется, как вариант в wcf или asp.
ещё одна особенность в переделанном коде в том, что активно используются интерфейсы и за счёт этого в дереве ещё менее жестко логика работы задаётся - по данным выбирается наиболее подходящая реализация интерфейсов. может вызваться простенькая ф-я в которой x_new += (t_new - t_old) * speed. а может вызываться что-то очень ресурсоёмкое, с вычислениями сложных траекторий в пространстве или с использованием планировщика пути, который ещё может результат обсчитывать асинхронно, т.е. не сразу результат возвращается. нужно передать сообщение, без разницы где получатель, какие протоколы, по каким интерфейсам (уарт, эзернет, блютуз,...) будет передаваться. работа с датчиками, разделение платформозависимого кода и т.д., т.е. все плюшки интерфейсов. а код дерева при этом не изменен.
так это небольшие изменения. а если сравнишь, допустим с nodecanvas и подобными вещами в unity3d, так сильных различий будет очень много.
"есть ещё куча других вещей, которые куда сильней влияют на всё". хорошие библиотеки, которые в играх используются зачастую платные, но если есть желание, некоторые игры элементарно декомпилировать. может помнишь, была такая мертворожденная роботикс студия от майкрософта. по прямому назначанию использовать не стоит, а вот посмотреть как сделаны различные вещи очень даже стоит. с теми контейнерами, что выше показывал используется, рефлексия. иногда она очень полезна и удобна, особенно в связке с использованием атрибутов. держи маленький примерчик, может пригодится для создания локальной или удалённой консоли или ещё для чего полезного
Код:
enum CmdType { immediate, queue }
static List<string> console_commands_names = new List<string>();
[AttributeUsage(AttributeTargets.Method)]
public class CmdAttribute : Attribute
{
public CmdType cmdtype { get; set; }
public string ConsoleName { get; set; }
public string InternalName { get; set; }
}
public static class Commands
{
[Cmd(cmdtype = CmdType.immediate, InternalName = "cls", ConsoleName = "cls")]
public static void cls(object parameters)
{
...
}
[Cmd(cmdtype = CmdType.queue, InternalName = "help", ConsoleName = "help")]
public static void help(object parameters)
{
Console.Echo("command list:");
foreach (string s in console_commands_names)
Console.Echo(s);
}
[Cmd(cmdtype = CmdType.immediate, InternalName = "someaction", ConsoleName = "a")]
public static void someaction(object parameters)
{
...
}
}
void autoregister()
{
Type[] alltypes = Assembly.GetExecutingAssembly().GetTypes();
foreach (Type t in alltypes)
{
MethodInfo[] all_mi = t.GetMethods(BindingFlags.Public | BindingFlags.Static);
foreach (MethodInfo mi in all_mi)
{
CmdAttribute attr = mi.GetCustomAttribute<CmdAttribute>();
if (attr != null)
{
CommandInfo ci = new CommandInfo();
ci.attribute = attr;
ci.action = new Action<object>((obj) => mi.Invoke(mi.Name, new object[] { obj }));
RegisterCommand(ci);
}
}
}
кстати о дотнетах, пока вспомнил. кроме mono есть .net core (сейчас делится на native и asp). пробовал, мне очень понравилось. всё гладко, не всё гладко с этими mono или core на линуксах, то такое - платки с двух или четырёх ядерными старшими армами сейчас с доставкой примерно от 10$ и на них можно делать намного более сложные вещи, чем на микроконтроллерах. одно из текущих направлений, чем сейчас занимаюсь это как раз разработка фреймворка для использования на недорогих малопотребляющих камушках (старших армах, интел), который можно будет применять в том числе и на различных роботах. таких ограничений по времени как с ботом нет, так что могу позволить полностью заново проработать всю архитектуру и не делать это всё узкоспециализированным.
кроме .net core есть .net mf. ставил давно на 4ю дискавери - интересно, но требовало много памяти и тактов. сейчас намного интересней стало. текущий mf делится на две ветки. первая это интерпретируемый вариант и в данном случае не интересен. вторая ветка "illium" и интересна тем, что код компилируется в машинный код. разница в производительности между не компилированным в машинный код и компилируемым очень значительна. пока эта ветка на начальной стадии разработки, но поэкспериментировать с ней уже можно. недавно для теста подготавливал вот такой кодик
http://pasteboard.co/1CjmF3oHZ.jpgна 4ю дискавери не интересно, хочется или на 51/52 нрфки или что-то уровня 103стм, чуть позже как будет время продолжу эксперементы с illium.
Вход
Регистрация
FAQ
Поиск
какие на данный момент есть возможности, тем и пользуюсь и пока всё устраивает. хочешь привнести хорошие идеи в дотнет или ускорить разработку, все будут только за, держи 
, железяка куда как ближе к роботам 
не торопись, все ещё на паскале и турбо си в досе.
