Простите за глупый вопрос / Форум / MirGames - сообщество разработчиков игр

Wallhow

31.01.13 23:37

Ещё раз извиняюсь за такой глупый вопрос, но что-то не как не могу толком сообразить, просто теоретически представил как это сделать, а на практике...увы не работает...
Что мне требуется:
Требуется, по нажатию ЛКМ по спрайту, проверить его и при определённых условиях изменить в нем некоторые данные.
Вот как я это делаю:

[CodeBox]
#region - Поворот кристалов по касанию
bool tab=false;
if (mat.onPressed())
{
tab = true;
}

if(Intersect.IntersectRect(new Rect2D(mat.getTouchPos(),new Size(1,1)),diamond.Rect))//Проверяет если курсор наведен на спрайт
{
if (diamond.getDirection() == Diamond.DIAMOND_DIRECTION_LU && tab)
{
diamond.setDirection(Diamond.DIAMOND_DIRECTION_U);
diamond.setFrame(0);
tab = false;
}
if (diamond.getDirection() == Diamond.DIAMOND_DIRECTION_UR && mat.onPressed())
{
diamond.setDirection(Diamond.DIAMOND_DIRECTION_LU);
diamond.setFrame(7);
tab = false;
}
if (diamond.getDirection() == Diamond.DIAMOND_DIRECTION_U && mat.onPressed())
{
diamond.setDirection(Diamond.DIAMOND_DIRECTION_UR);
diamond.setFrame(1);
tab = false;
}

}

#endregion
[/CodeBox]

Фишка в чём, в том что при клике спрайт начинает нервно менятся... предполагаю что надо как-то после нажатия на него сделать некую задержку в опросе..

Алгоритмы

← предыдущая
1
2
следующая →

#21

phomm

18.03.13 10:10

Оба примера нормик. У Дэна, конечно, именно массив (как запросил WallHow), и, соответственно, код не учитывает изменение архитектуры коллекции, но линку (хоть и безразличен к типу коллекции), всё же, не есть пуля, имхо, ибо кто его знает, чего там в хна (автор пишет с нею) с линку в общем случае - надо курить.
Мой вариант.
GameObject имеет ссылку на своего родителя, а Alive - свойство, как только свойство устанавливается в false - уведомляем родителя - и он сам разберётся, чего сделать.
Из плюсов схемы - нет постоянного прогона всей коллекции при каждом шаге игрового цикла.

Отредактировано: 18.03.13 10:12

#22

Said

Хранитель Флейма

18.03.13 17:40

Цитата

всё же, не есть пуля, имхо, ибо кто его знает, чего там в хна (автор пишет с нею) с линку в общем случае - надо курить

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

XNA тут не причем, все упирается в версию .NET и не более того. (но в случае ТС все ок)

В любом случае написать свою списковую абстракцию, такую как all - очень легко, даже в языке где нет лямбд и шаблонов. :)

И да, у Дана пример полное говно:
* Плохо читается.
* Плохо оптимизирован: проверка будет выполнена для каждого элемента, даже если это не требуется после проверки первого элемента.
* Алгоритм сложнее сделать многопоточным.

Цитата

GameObject имеет ссылку на своего родителя, а Alive - свойство, как только свойство устанавливается в false - уведомляем родителя - и он сам разберётся, чего сделать.
Из плюсов схемы - нет постоянного прогона всей коллекции при каждом шаге игрового цикла.

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

#23

phomm

19.03.13 09:33

Блин, невнимателен немного.

Цитата

если все объекты соответствуют true, то выполнить определённое действие

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

А вот с выгодой от отсутствия необходимости перебора массива постоянно не споришь )

Насчёт

Цитата

* Плохо оптимизирован: проверка будет выполнена для каждого элемента, даже если это не требуется после проверки первого элемента.

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

Насчёт речи - можно считать, что я стажируюсь на граммарнаци ))

Отредактировано: 19.03.13 09:34

#24

Said

Хранитель Флейма

19.03.13 15:44

Цитата

Ну ок, твой подход все равно плохой, загибаем пальцы:

* Трудно понять логику: она будет размазана по двум уровням: владелец-подчиненный.
* Событийно-ориентированный код сложнее отлаживать.
* Высокая связанность такой схемы не позволит гибко менять логику.

Что на счет "мнимости оптимизации" - из задачи не следует что оптимизация в данном случае бесполезна.

----------
И сравни со моим способом:

* Подчиненные объекты ничего не знают о владельцах.
* Легко сделать параллельным.
* Легко прочитать (почти как естественный язык).
* Легко модифицировать, вся логика находится в одном месте.
* Легко отлаживать и легко тестировать.

* Ну и да, изменять условия задачи, для того что бы она решалась удобным для тебя способом - дурной тон.

#25

Wallhow

26.03.13 02:16

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

Стоит ли это так пытаться сделать? ^_^
(просто подумываю(додумываю :) ) что можно всё это проще(а может и не проще) сделать.

Отредактировано: 26.03.13 02:18

#26

Said

Хранитель Флейма

26.03.13 06:03

Узнаю себя 9 лет назад. Я задал ДРОНу точно такой же вопрос, а он сказал что я дурак и шел бы учиться.

#27

phomm

26.03.13 09:38

Саид, сорри, что не ответил тогда, начинал набирать пост, меж работой, вылазками, (правил его, как всегда проверяя смысл сказанного, не постил) а потом что-то подзатянулось, да ещё опера комп ушёл в ребут, пост я потерял.

Сейчас напишу кратенько, что было в том посте.

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

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

Теперь про чёрную дыру. Физ модель такая, как написал, а что именно не получается, не приведёшь ?

Саид, поясни на какой именно вопрос )) ? "стоит ли пытаться так делать ?" ?

#28

Said

Хранитель Флейма

26.03.13 22:24

Цитата

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

Причем тут это? Твоя фраза звучит примерно так: "солнце светит потому что вода мокрая".
Связанность у тебя большая, т.к. изменение условия задачи приведет к изменениям в зависимых объектах, куда ты умудрился запихать логику. Например, найден способ еще лучше оптимизировать код, в твоем случае нужно будет менять: объект, его владельца, места где была затребована подписка на событие и собственно участок кода, который принимает решение вызывать какую-либо логику в случае если все объекты удовлетворяют состоянию. Т.е. в лучшем случае 4 места придется изменить. Это и есть высокая связанность.

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

Единственный плюс - у тебя более производительная схема. Но решения мы так и не увидели, ты только на пальцах объяснил.

Цитата

Саид, поясни на какой именно вопрос

Я просил то же самое что и автор. Слово в слово.

#29

phomm

27.03.13 09:57

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

По остальным пунктам согласен. Связанность в случае замены или сильного усложнения всей цепочки работы не позволит аккуратно и гибко менять/подстраиваться.
Спасибо за дискуссию.

А в целом, прошу прощения у Wallhow за некоторый оффтоп (в т.ч. и моими силами).
Будем ждать Ваших дальнейших работ и, видимо, вопросов )

#{{post.Index}}

Отредактировано: {{post.UpdatedDate | date:'dd.MM.yy HH:mm'}}

← предыдущая
1
2
следующая →

Форумы / Алгоритмы

Простите за глупый вопрос