Класс статических или нестатических тел в игровом движке C#
Привет,
Я создал простой игровой движок C# и теперь думаю о структуре OO моего кода.
Все "тела" - такие как космические корабли игроков, вражеские космические корабли, астероиды и т. д.-помещаются в список "тела" и находятся в классе, называемом телами.
Моя интуиция говорит, что большинство из них сделало бы класс тел "нормальным" классом и унаследовало бы его, как обычно. Однако, поскольку в игре будет только один такой список, я установил класс в статический, а затем позволил всем другим классам использовать его, написав такие вещи, как
float theWidth = Bodies.bodylist[72].Width;
...а также
Bodies.bodylist[72].Width = theWidth;
В данный момент я думаю о том, что bodylist может быть изменен только с помощью методов в классе Bodies, а не непосредственно из других классов (инкапсуляция). Мне удалось сделать это с помощью следующего:
static private List<Body> bodylist;
static public List<Body> Bodylist
{
get { return bodylist; }
private set { bodylist = value; }
}
..но я все еще задаюсь вопросом, будет ли это предпочтительным способом.
Так что же мне делать? Я мог бы удалить ключевое слово static и позволить другим классам наследовать класс Bodies, но, на мой взгляд, это концептуально неправильно. Кроме того, это может вызвать проблемы, поскольку и класс контроллера, и класс физики, и класс BoardSetup работают против bodylist. Пожалуйста, помогите мне!
(У меня также есть класс переменных, класс утилит и класс звуков. Они тоже могут быть установлены либо статическими, либо нет, и основные рассуждения, вероятно, будут там одинаковыми, или я ошибаюсь? Я думаю, что, по крайней мере, класс переменных должен быть установлен в статическое состояние.)
Что я уже пробовал:
Я пробовал несколько подходов к этой проблеме, но не могу ее решить, так как не знаю, какое решение было бы наиболее предпочтительным. (Код и так работал нормально, просто он был не очень ОО.)
Я также прочитал отличное объяснение OriginalGriff здесь:
[^] но в этом примере я предполагаю, что класс "мать" должен быть статичным. В любом случае, в моей игре будет только один Sounds.cs, один Bodies.cs и т. д.
BillWoodruff
Интересный вопрос, поскольку обычно" игровое "приложение ставит скорость/производительность своих визуальных элементов в ответ на взаимодействие с пользователем выше всего остального ... конечно, эта "типичная" игра также будет использовать какой-то движок растрового рендеринга, например Unity.
Вы пишете эту игру с помощью WinForms ? или WPF ?
Посмотрите, есть ли у вас какие-либо идеи из этого примера статического класса "фабрика" :
https://www.codeproject.com/Answers/1197724/Csharp-why-I-need-to-use-type-gettype-when-I-make
petter2012
Привет Билл,
Спасибо за Ваш (как всегда) хорошо поставленный и информативный ответ. Я нашел ваш ответ в ссылке очень интересным, хотя я думаю, что мог бы придерживаться статического класса, так как он все-таки работает и на самом деле не злоупотребляет концепцией OO (или я так думаю). Я научился программировать еще до того, как ООП стал стандартом, и работал в основном с WinForms и традиционными ASP.NET мне никогда не приходилось по-настоящему углубляться в более сложные части архитектуры ОО.
Рад видеть ваш отзыв о проекте игрового движка. Я думал, что (еще) еще один бесплатный движок для 2D-игр будет малоинтересен. Однако этот игровой движок на самом деле НЕ о скорости / производительности. Вместо этого он написан для образовательной среды (очевидно, без ориентации на объектно-ориентированный подход :)). Он чрезвычайно гибкий, так как все может все контролировать. Например, в моей игре под названием «Марио в Мории» Супер Марио стреляет синими огненными шарами по гоблинам. Чем дольше огненные шары удаляются от Марио, тем бледнее они становятся (меняется прозрачность). Урон, нанесенный гоблину, в свою очередь, связан с непрозрачностью огненного шара. Кроме того, поскольку все объекты имеют "хитпоинты" (если использовать старый термин D&D), при желании все может быть повреждено. Таким образом, если Марио застревает в темнице Мории, он всегда может выстрелить множеством огненных шаров в каменную стену, чтобы в конечном итоге разрушить ее.
Несколько месяцев назад мои студенты (с очень небольшим знанием программирования) создали все виды игр, включая гравитацию, такие как футбольный матч, несколько игр, где падающие объекты должны быть спасены, космический шутер, игру "Пингу" и отличную игру ниндзя-истребителя. В игре ниндзя происходило много всего (они тоже могли стрелять), но производительность никогда не была проблемой.
Я планирую написать статью об этом игровом движке здесь, на CodeProject, где-нибудь после лета. Игровой движок сначала был написан для UWP, но так как у нас в университете не было Win 10, я сменил его на WPF. По замыслу, на самом деле существует очень мало фреймворка или специфичного для языка кода, поэтому я предполагаю, что, например, Java-разработчик мог бы очень легко перевести это на Java или, возможно, просто использовать такие вещи, как (довольно простой) физический файл для вдохновения.
Помимо обучения, я также думаю, что этот игровой движок может пригодиться гейм-дизайнерам, которые могут работать с другими людьми, которые на самом деле пишут код. В таком сценарии этот игровой движок может быть подходящим для прототипирования, особенно для игр, которые не являются традиционными по типу (поскольку его лучшая особенность - его гибкость). Поскольку код такой короткий и сравнительно простой, не возникнет риска отказа от программного обеспечения - нетрудно добавить собственный физический код или что-то подобное. Кстати, я надеюсь, что другие захотят добавить свои собственные методы в этот игровой движок, чтобы он мог процветать и стать более мощным, чем я могу надеяться достичь сам.
BillWoodruff
Привет, Петтер, я рад, что ты нашел мой комментарий полезным ! Еще в 1983 году я создал первую компьютерную образовательную программу для франко-американской двуязычной школы в Сан-Франциско: я поделился своим опытом удивления и восторга от творчества учеников :)
Теперь, когда я лучше понимаю, что вы делаете, я могу опубликовать здесь еще один ответ, основанный на идее (предвзятости?), что для прототипирования приложения ООП-дизайн-это очень хорошая вещь. твое здоровье, Билл
petter2012
Привет еще раз Билл,
Спасибо, что поделились своей историей о своем преподавательском опыте.
Сейчас я нахожусь в процессе написания документации для игрового движка и только что описал связь с парадигмой ОО. У меня есть скромное предложение: почему бы не принять участие в этом проекте и не сделать его игровым движком для образовательных настроек? :) Раньше я учил своих студентов обертке Physics Helper (Энди Болье) и базовому физическому движку Farseer, но с этим движком гораздо проще работать, но он более гибкий. На самом деле, я описал весь код двигателя в двухчасовой лекции. Чего у него нет, так это сложного обнаружения столкновений, но опять же, это не совсем смысл этого конкретного игрового движка.
Он действительно идет хорошо, и если вы хотите, я могу отправить вам предрелизный zip-файл моей последней игры, выпущенной вместе с ним.
/ Петтер