WPF верстка для сложной карточной игры

Question

В качестве моего первого проекта WPF я пытаюсь создать приложение для карточной игры, похожей на Magic the Gathering. Мне не понятно, как выложить основную игровую площадку. Вы можете увидеть некоторые примеры, которые похожи на то, что я пытаюсь сделать, взглянув на пример 1 или пример 2 . Области чата / информации справа будут отдельными пользовательскими элементами управления.

Карты должны поддерживать свои пропорции, и каждая игровая зона должна начинаться с 10 столбцов и двух рядов карт. По мере того, как будет сыграно больше карт, количество столбцов и / или строк может измениться. Каждая зона игрока может иметь различное количество столбцов и / или рядов. Карты могут накладываться друг на друга и могут располагаться сбоку (постукивать). Карты во всех областях должны быть одинакового размера (хотя они могут быть обрезаны в некоторых областях). Карты не должны лежать точно на сетке (они не обязательно привязываются к сетке).

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

Учитывая эти требования, я испытываю желание использовать один большой пользовательский элемент управления, полученный из Canvas, с объектами изображений для каждой карты (наряду с другими формами для разграничения областей). Это подразумевает, что я буду выполнять большую работу во время события OnRenderSizeChanged, чтобы расположить дочерние элементы на холсте (макет вручную).

Использование сетки мне не представляется возможным из-за размещения произвольной формы и перекрытия.

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

Есть ли лучшая альтернатива одному большому элементу управления на основе холста? Кажется неправильным делать ручную разметку в WPF, но я не вижу альтернативы.

Answer 1

Вы сказали:

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

Но это не правильно.Разложение является абсолютно правильным подходом, и это не помешает картам расширяться в смежные пользовательские элементы управления.Причина в том, что вы можете использовать RenderTransform вместо LayoutTransform.См. этот пример Чарльза Петцольда или эту статью , чтобы увидеть разницу.Поскольку RenderTransform применяется после того, как раскладка уже произошла, ваши карты смогут расширяться за их пределы.

Учитывая, что разложение является правильным подходом, я бы упорядочил ваши различные коллекции карт в Grid с каждой коллекцией, являющейся ItemsControl.ItemsControl должен связать его свойство ItemsSource с какой-либо коллекцией, и тогда вы можете предоставить пользовательский ItemTemplate, который будет отображать изображение и любую другую информацию.Я не решался бы использовать Canvas, поскольку это ограничило бы вас жестким кодированием позиций для карт (что является очень похожим на WinForms решением для проблемы, которая может быть гораздо более элегантно решена).Воспользуйтесь преимуществами фантастического движка макетов WPF и используйте вложенные сетки и элементы управления элементами для создания динамического макета.Это гарантирует, что ваша игровая доска хорошо выглядит при любом разрешении и при растяжении до различных размеров.

Answer 2

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

Выезд: http://msdn.microsoft.com/en-us/library/ff649780.aspx

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

Answer 3

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

Если вы беспокоитесь о том, что содержимое вашей «Карты» перемещается при изменении размера коробки, поместите ее в окно просмотра. Он будет управлять всем вашим масштабированием для вас, и гарантирует, что ваша карта использует столько недвижимости, сколько она может получить. В качестве альтернативы вы можете использовать RenderTransform, но многие из них могут замедлить вашу программу (эксперты: работает ли viewbox с использованием RenderTransforms? Если это так, то это спорный вопрос)

Чтобы гарантировать, что карты сохраняют свои пропорции, убедитесь, что для атрибута Stretch каждого изображения установлено значение «Uniform», чтобы все они имели одинаковый размер, что можно сделать, назначив мастер-карту и привязав высоты и ширины всех последующих карт к эта оригинальная карта, хотя она немного грязная и не позволяет картам расширяться. Другое решение состоит в том, чтобы установить один размер для каждой карты вручную, анимируя это, когда вы хотите увеличить или уменьшить.

Answer 4

Я рекомендую вам взглянуть на проект этого парня . В Java я знаю, но если бы я пошел по пути построения карточной игры. Это было бы то, от чего я бы ушел.