[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Область видимость функций, обсервер, полиморф, хук
I++
Собственно продолжаю медитации на разнообразные паттерны и всетакое.

Но вот встала задача, сделать систему с плагинами.

Теория:

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

Например есть переменная $a она обрабатывается в ядре, нам требуется в плагинах изменять её состояние, отлично на помощь нам могут придти хуки и навешивать таких хуков можно сколько угодно, а так же прерывать дальнейшее попадание в хуки по списку все это понятно, но есть НО!

Например в СИ-лайк-скрипт языках мы можем сделать примерно так:

Псевдокод:

function enteryPoint()
{
regiser_event('entityThink', 'myFunc'); // Тип евента, функция
}

// Когда в ядре происходит событие, поочередно вызываются все функции которые были зарегистрированы с определенным событием в ядре.
function myFunc(int a)
{
setVar(a, 2); // Функция устанавливает переменную в значение 2, в php можно упросить передевая пременную по ссылке.
return CONTINUE; // Так как в ядре используются хуки, есть константы например CONTINUE что будет означать продолжить выполнение следующих функций после вызова этой функции. Можно поставить другой ретурн который будет запрещать последующий после этой функции последовательный вызов.
}


Вот такой код копируется несколько раз и регистрируется ядром в котором по очереди каждый enteryPoint и вызывается, с учетом области видимости, но в php нет областей видимости функций и цейцнот.

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

Теперь для чего я весь этот геморой придумываю.

Уже не первый день пытаюсь собрать игрульку типо бегающие человечки на экране которые могут делать пиу-пау с сетевыми возможностями, все енто основано на js + libevent + pthreads(пока в плане).

Почему я выбрал именно такой подход, да потому что он элементарный.

Есть базовая функция например движения которая делает так: $x = $x + 1; И мой человечек будет двигаться туда ---->>>

А если сделать хуки, которые могут эту переменную изменять то код становится просто до идиотизма простым, вот пример псевдокода:

function enteryPoint()
{
regiser_event('WalkStep', 'walk'); // Тип евента, функция
}

function walk(int cord[2])
{
cord[0] = cord[0] + 20; // Мегабыстрый чел, напился адреналина
cord[1] = cord[1] + 20; // Мегабыстрый чел, напился адреналина
}


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

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

И вот у меня таких enteryPoint набивается с 20ку например, а ядро их периодически запускает по очереди обходя, в данном примере лишь были зареганы хуки например WalkStep локальная функция walk, геморой в том, что в пыхе нет локальных функций, а лепить целый класс из него делать объект, а потом обходить все это обсервер + хуки, что вызывает уныние, просадка будет очевидна от такого подхода, при том, что ресурс будет тратиться впустую, на 1 единственный инстанс который будет обрабатываться достаточно часто.
------------

При таком подходе я так же могу раскидать просчет коллизии, координат, векторов на потоки с помощью pthreads, это будет интереснее, чем в цикле каждый игровой фрейм делать просчеты в цикле для 100 например объектов, так раскидал задачи по тредам и отлично :)
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.