Реализовать игру полоски в виде двух проектов обычный windows forms и wpf

Обновлено: 07.07.2024

В предыдущем разделе мы определили, что такое WPF и начали обсуждение более старого фреймворка - WinForms. В этом разделе я постараюсь сравнить данные модели, так как, несмотря на одинаковое предназначение, между ними существует множество различий. Если Вы никогда не работали до этого с WinForms и, особенно, если WPF это Ваш первый в изучении GUI фреймворк - можете пропустить текущий раздел, но если все же интересно, прочитайте ниже про различия между WPF и WinForms.

Одним из самых важных различий между WinForms и WPF является тот факт, что в WinForms интерфейс пользователя это всего лишь графический слой, использующий стандартные элементы управления Windows (например TextBox), а WPF-интерфейс, в свою очередь, построен "с чистого листа", не опираясь в большинстве случаев на стандартные элементы. Это может показаться весьма тонкой гранью между рассматриваемыми моделями, но в действительности это не так, и Вы обязательно обратите на это внимание при работе с фреймворком, базирующимся на Win32/WinAPI.

В качестве примера вышеописанной ситуации можно рассмотреть кнопку с изображением и текстом на ней. Этот элемент управления не является стандартом Windows, и, в таком случае, WinForms не предоставляет готового решения. В результате Вы будете вынуждены создать изображение и заимплементировать собственную кнопку, поддерживающую изображения либо воспользоваться готовыми нестандартными решениями. Кнопка в WPF, в свою очередь, может иметь внутри что угодно, так как это просто "рамка", содержащая графический контент, находящаяся в разных состояниях (например: нажатая, ненажатая, реагирующая на наведенный курсор). Ее можно трактовать как "невидимую" (это относится к большинству других элементов управления WPF), это значит, что она может содержать в себе ряд других элементов внутри. Вы хотите получить кнопку с изображением и текстом? Просто поместите элементы Image и TextBlock внутрь кнопки и она готова! В рамках элементов управления WinForms Вы просто не ощутите той гибкости при разработке, что является причиной процветания рынка, который предлагает готовые простые реализации таких элементов как "кнопка с изображением" и подобных.

Слабой стороной гибкости, о которой шла речь является то, что Вам придется больше работать для достижения результата, который просто можно было бы достичь в WinForms, так как она была создана для определенных сценариев. Как минимум, это будет ощутимо в начале, когда Вы захотите например создать шаблон ListView с изображением и хорошо выровненным текстом, тогда как ListView в WinForms это всего лишь одна строка кода.

Выше было представлено лишь одно из различий, но когда Вы начнете работать с WPF, то поймете, что оно является причиной большого количества других - просто WPF устроен по своему, хорошо это или плохо - решать Вам. Больше никаких ограничений элементами управления платформы Windows, но для того, что достичь гибкости, о которой шла речь - придется приложить больше усилий, по сравнению с созданием стандартных Windows интерфейсой пользователя.

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

Прошло довольно много времени с момента написания предыдущей статьи. Как и обещал я написал вторую часть. Хотелось бы сказать спасибо всем тем, кто давал советы в комментариях, из всех их я смог узнать что-то новое. Ну а для тех кому хочется сразу посмотреть проект вот ссылка на GitHub проекта.

Сразу хочется отметить, что всё, что было добавлено и изменено в этой версии делалось с очень
большим трудом, большим количеством ошибок. мой гугл наполнился большим количеством запросов начиная от особенностей реализации MVP, до асинхронных методов.

Обновления

Добавлен свой собственный редактор карт(как в оригинале игры).
Реализован эхолот.
Добавлена возможность ловить на донку и на спиннинг.
Добавлено много видов рыбы.
Сильно улучшена производительность проекта.
Исправлено большое количество багов.
Так же значительное улучшение архитектуры приложения(точнее её появление).
Добавлено сохранение профиля игрока.
Реализованы трофеи.
Добавлена смена дня и ночи.
Добавлены путешествия.
Реализован продуктовый магазин.
Реализован патерн MVP.
Реализована система событий в игре
Реализована прикормка, с возможностью миксования ингредиентов
Добавлена озвучка
Добавлены анимации
Реализован износ удилищ, в зависимости от размера рыбы и времени вываживания

Как чужой код ввёл в заблуждение.

Мы видим на скриншоте редактор карт для рыбалки, а именно сетку глубины для каждой локации (Это элементы Label с FormBorderStyle = 0, для того, чтобы показать рамку). Кстати скриншот сделан с использованием моих собственных ножниц. В чём заключалась проблема?

Здесь мы видим простой проход по двумерному массиву(причём не правильный). Потом мы вычисляем по теореме Пифагора гипотенузу, и если она < 20, мы определяем нужную клетку. Но этот метод очень плохо работает даже с квадратом. А тут прямоугольники. Поэтому часто клетка определяется неправильно. В своё оправдание могу сказать, что этот код я взял с YouTube.

Итак, нам нужно определить в какой клетке находится курсор. Для этого можно применить данный исходный код:

Здесь мы берем координаты курсора, кастим их в PointToClient, и передаём в конструктор Rectangle, размеры указываем 1 и 1. Потом мы используем стандартный метод IntersectsWith проверяем, пересечение курсора, и label. Также, мы не можем просто обработать клик по label, так как форма с ними не показывается.
Также, это позволило реализовать поддержку 3-х удилищ для ловли.

Генерация рыбы

Итак, основная часть игры это генерация рыбы. Она происходит в несколько этапов:
1.При заходе на локацию мы из строки типа:
Карась Золотой:25 250-400 [Сыр, Червь, Опарыш, Кукуруза] Где содержится размер рыбы в процентах от максимального, глубина минимальная, глубина максимальная, и список наживок получаем объект рыбы(Не забыв предварительно проверив строку через регулярные выражения). Для красоты кода я определил оператор который кастит строку к рыбе.

В итоге такой подход позволяет нам написать:

Код приведен для примера и не встречается в проекте в подобном виде.

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

3. Из этого списка случайно выбираем рыбу. Проверяем может ли съесть установленную наживку, и также проверяем, чтобы время суток активности рыбы соответствовало текущему времени в игре.

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

Благодаря процессу генерации, я стал уверенным пользователем LINQ.

Сама игра

Скриншот продуктового магазина.

Его исходник можно посмотреть в репозитории. Там довольно интересно выполнены обработчики MouseEnter и MouseLeft для изменения изображений еды.

Скриншот формы для путешествий. (Все водоёмы являются тестовыми и их названия не являются подлинными.)

Скриншот игрового мира

Планы

Сделать клиент-сервер для игры
Junior FPGA(ПЛИС) Developer
Распознавание лиц через Веб камеру(Ищу литературу, которая может быть полезна)
Замена обычных ListView на ObjectListView

Вывод

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

Всем спасибо, кто прочитал до конца, любая критика исходного кода приветствуется и будет сразу рассмотрена.

Эта статья будет посвящена двум совершенно разным подходам к разработке прикладных программ на основании WPF ( Windows Presentation Foundation ) и Windows Forms ( WinForms ). Идея написания статьи возникла после наблюдения за начинающими разработчиками, которые решают, переходить им на WPF / XAML или нет. Основное их стремление изучать WPF основывается на том, что эта технология становится сейчас очень популярной. А язык декларативной разметки XAML ( eXtensible A pplication M arkup L anguage ) позволяет писать код как для WPF , так и, например, к тому же Silverlight или для Windows Phone . Будучи ярым поклонником WPF и языка декларативной разметки XAML , в данном контексте не буду прибегать к субъективизму, расхваливая некую технологию, а постараюсь описать, в каких случаях применять тот или иной способ разработки. Почему-то многие разработчики после перехода с Windows Forms на WPF начинают критиковать Windows Forms , часто наблюдается и обратная реакция. Мне приходилось бывать в шкуре как первых, так и вторых.

В первую очередь, стоит охладить пыл новичков, которые, увидев возможности визуального интерфейса WPF , начинают максимально использовать его, не думая о последствиях. Во-первых, использовать WPF или Windows Form нужно исходя из решаемой задачи. Если у Вас простой интерфейс на парочку кнопочек и форм, то делайте задачу на том, на чем у Вас выйдет быстрее. В первую очередь анализируем то, что нужно реализовать, а затем делаем.

public override Size GetPreferredSize( Size szProposed)

var iRadius = ( int ) Math .Sqrt( Math .Pow(szf.Width / 2, 2) +

protected override void OnPaint( PaintEventArgs args)

bool bPressed = Capture & ((MouseButtons & MouseButtons .Left) != 0) &

pgbr.CenterPoint = new PointF (k * (rect.Left + rect.Right) / 3,

pgbr.CenterColor = bPressed ? Color .Blue : Color .White;

// Draw the text centered in the rectangle (grayed if disabled).

strfmt.Alignment = strfmt.LineAlignment = StringAlignment .Center;

br = Enabled ? SystemBrushes .WindowText : SystemBrushes .GrayText;

// Draw dotted line around text if button has input focus.

xmlns ="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

< Setter TargetName ="outerCircle" Property ="Fill" Value ="Orange"/>

Больше примеров кода не будет. Только рисунки и диаграммы. Для начала рассмотрим, в чем отличие этих двух подходов.

Подход к разработке прикладных программ на Windows Forms основывается на графическом интерфейсе GDI (Graphics Device Interface, Graphical Device Interface) - это интерфейс Windows для представления графических объектов и передачи их на устройства отображения, такие как мониторы и принтеры.

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

Рассмотрим паттерн Model-View-Presenter (MVP), который часто используют для Windows Forms . MVP - шаблон проектирования пользовательского интерфейса, который был разработан для облегчения автоматического модульного тестирования и улучшения разделения ответственности в презентационной логике (отделения логики от отображения):

Модель

Model

определяющий

данные

Представление ( View ) - это интерфейс, который отображает данные (Модель) и маршрутизирует пользовательские команды (или события) Presenter-у, чтобы тот действовал над этими данными.

На схемее ниже показано графическое представление MVP .

На данный момент контролы для Windows Forms по количеству превосходят WPF контролы в несколько раз. Это связано, в первую очередь, с тем, что Windows Forms появился в . Net Framework 2.0 , а WPF - в . Net Framework 3. 0 . Разрабатывать приложения на Windows Forms очень просто. Для визуального интерфейса в основном большая часть логики связана с перетаскиванием нужных контролов на форму.

Подход к разработке прикладных программ на Windows Presentation Foundation ( WPF ) основан на DirectX . Весь код транслируется в код для трансляции в DirectX с помощью библиотеки milcore . dll . В основе WPF лежит векторная система визуализации, не зависящая от разрешения устройства вывода и созданная с учётом возможностей современного графического оборудования. WPF предоставляет средства для создания визуального интерфейса, включая язык XAML (Extensible Application Markup Language), элементы управления, привязку данных, макеты, двухмерную и трёхмерную графику, анимацию, стили, шаблоны, документы, текст, мультимедиа и оформление.

Графической технологией, лежащей в основе WPF, является DirectX, в отличие от Windows Forms, где используется GDI/GDI+ . Производительность WPF выше, чем у GDI+, за счёт использования аппаратного ускорения графики через DirectX. С помощью XAML мы можем создавать визуально е представление ( view ), по сути, на xml - подобном языке с мощными возможностями. Приложения на WPF не являются переносимыми и могут быть использованы только в операционной системе Windows . Для написания корпоративных решений используется паттерн MVVM ( Model - View - ViewModel ) предназначен для создания приложений для WPF / Silverlight . Основная особенность данного паттерна заключается в том, что весь код с View (представления) выносится в ViewModel (модель представления), а вся привязка осуществляется черед байндинг, прописанный в XAML -разметке. Для простоты работы с MVVM был разработан MVVM Toolkit , который включает шаблон для Visual Studio и позволяет использовать данный паттерн без особых усилий. Если Вы не знакомы с данным паттерном, рекомендую ознакомиться с моей статьей "Основы паттерна MVVM" . Благодаря этому паттерну в приложении WPF можно разделить реализацию интерфейса и логики . Реализаций интерфейса могут заниматься дизайнеры на инструменте Expression Blend (либо во встроенном редакторе студии), а программисты будут заниматься исключительно логикой работы программы. Как выглядит представление паттерна MVVM , можно увидеть ниже на рисунке.

WPF предоставляет мощную систему байндинга, которая намного мощнее используемой в Windows Forms . Сейчас пришла пора объяснить код с овальной кнопкой, приведенный в начале статьи. В отличие от Windows Forms , для того, чтобы сделать нестандартный интерфейс в каком либо существующем контроле, не нужно создавать новый контрол. Достаточно для этой кнопки сделать новый стиль и привязать его к данному контролу через свойство Template . Это намного удобнее, чем в WPF . Но в большинстве случаев не нужно перерисовывать внешний вид контрола, в таких случаях полностью подойдет Windows Forms . WPF имеет также преимущество перед Windows Forms в поддержке 2 D /3 D объектов. Также WPF имеется мощный инструмент для работы с анимацией через XAML код. В Windows Forms простая анимация обычно требует объект таймер и отрисовки нужной информации по событию tick этого таймера. Еще одно достоинство - работа с аудио, видео и голосом.

В данной статье я постарался описать сравнение двух подходов к разработке прикладного программного обеспечения, основываясь на подходе с использованием Windows Forms и WPF . При усилиях быть объективным к этим технологиям разработки, WPF в материале получилась все же более восхваленная, чем Windows Forms . Возможно, аргументом в пользу этого будет тот факт, что WPF имеет намного больше возможностей по написанию программ, чем Windows Forms . Прежде чем выбрать какую то технологию для разработки, нужно проанализировать, что Вам больше подходит по дизайну. Если в Вашем приложении простой дизайн, то WPF в этом случае, по сути, незачем. Также нужно учитывать скорость разработки продукта на первой и второй технологии. Если на Windows Forms это займет у Вас 3 дня, а на WPF - 7 дней, то не имеет смысла использовать WPF . То же самое касается паттернов MVP / MVVM : если у Вас приложение, которое занимает несколько дней для разработки, и если Вы неопытный разработчик, то применение данных паттернов только отсрочит написание проекта. У опытных разработчиков же либо есть наработки, либо они могут взять какой-то из MVVM -тулкитов для построения своего приложения.

WPF и Windows Forms представляют две разные архитектуры для создания интерфейсов приложений. System.Windows.Forms.IntegrationПространство имен предоставляет классы, обеспечивающие общие сценарии взаимодействия. Двумя ключевыми классами, реализующими возможности взаимодействия, являются WindowsFormsHost и ElementHost . В этом разделе описано, какие сценарии взаимодействия поддерживаются, а какие нет.

Особое внимание уделено сценарию гибридного элемента управления. Гибридный элемент управления — это элемент управления на основе одной технологии, в который вложен элемент управления на основе другой технологии. Это также называется вложенным взаимодействием. В многоуровневом гибридном элементе управления более одного уровня вложения. Примером многоуровневого вложенной операции является элемент управления Windows Forms, содержащий WPF элемент управления, который содержит другой элемент управления Windows Forms. Многоуровневые гибридные элементы управления не поддерживаются.

Размещение элементов управления Windows Forms в WPF

При размещении элемента управления Windows Forms поддерживаются следующие сценарии взаимодействия WPF :

WPFЭлемент управления может содержать один или несколько элементов управления Windows Forms с помощью XAML.

В нем может размещаться один или несколько элементов управления Windows Forms с помощью кода.

В нем могут размещаться Windows Forms контейнерные элементы управления, которые содержат другие элементы управления Windows Forms.

В ней может размещаться форма «основной/подробности WPF » с главным и Windows Forms сведениями.

В нем может размещаться форма «основной/подробности» с Windows Forms главным и WPF подробными сведениями.

В ней может размещаться один или несколько элементов управления ActiveX.

В него могут быть вложены один или несколько составных элементов управления.

С помощью Язык XAML в него могут быть вложены гибридные элементы управления.

С помощью кода в него могут быть вложены гибридные элементы управления.

Поддержка макета

В следующем списке описаны известные ограничения при WindowsFormsHost попытке элемента интегрировать элемент управления, размещенный Windows Forms, в WPF систему макета.

В некоторых случаях размеры элементов управления Windows Forms не могут изменяться или их размер можно изменять только до определенных размеров. Например, ComboBox элемент управления Windows Forms поддерживает только одну высоту, которая определяется размером шрифта элемента управления. В WPF динамическом макете, в котором предполагается, что элементы могут растягиваться вертикально, размещаемый ComboBox элемент управления не будет растягиваться должным образом.

Элементы управления Windows Forms нельзя поворачивать или расклонять. Например, при повороте пользовательского интерфейса на 90 градусов размещаемые элементы управления Windows Forms будут поддерживать свое вертикальное расположение.

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

В пользовательском интерфейсе WPF можно изменить z-порядок элементов для контроля поведения перекрывания. Размещенный элемент управления Windows Forms рисуется в отдельном HWND, поэтому он всегда рисуется поверх WPF элементов.

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

Внешние свойства

Некоторые свойства окружения WPF элементов управления имеют Windows Forms эквиваленты. Эти внешние свойства распространяются на размещенные элементы управления Windows Forms и предоставляются как общие свойства WindowsFormsHost элемента управления. WindowsFormsHostЭлемент управления преобразует каждое WPF внешнее свойство в его Windows Forms эквивалент.

Поведение

В приведенной ниже таблице описаны возможности взаимодействия.

Переход от WPF элемента управления к Windows Forms элементу управления с клавишей TAB и Shift + Tab работает как обычно.

Windows Forms элементы управления, имеющие TabStop значение свойства, false не получают фокус при использовании вкладок пользователя через элементы управления.

Размещение элементов управления WPF в Windows Forms

При размещении элемента управления Windows Forms поддерживаются следующие сценарии взаимодействия WPF :

Вложение одного или нескольких элементов управления WPF с помощью кода.

Связывание страницы свойств с одним или несколькими вложенными элементами управления WPF.

Вложение одной или нескольких страниц WPF в форму.

Запуск окна WPF.

Размещение формы «основной/подробности» с Windows Forms главным и WPF подробными сведениями.

Размещение формы «основной/подробности» с WPF главной и Windows Forms сведениями.

Вложение пользовательских элементов управления WPF.

Вложение гибридных элементов управления.

Внешние свойства

Некоторые свойства окружения элементов управления Windows Forms имеют WPF эквиваленты. Эти внешние свойства распространяются на размещенные WPF элементы управления и предоставляются как общие свойства ElementHost элемента управления. ElementHostЭлемент управления преобразует каждое Windows Forms внешнее свойство в его WPF эквивалент.

Читайте также: