Как с помощью ООП смоделировать сложный игровой мир? Всем доброго времени суток!
Впервые столкнулся с тем, что почти не представляю, как решить проблему моделирования системы с помощью ООП, а потому крайне нуждаюсь в советах и рекомендациях от более опытных коллег.
В чём, собственно вопрос? Я для себя постоянно что-то пишу, велосипежу, так сказать, и сейчас мой взор направлен на создание RPG-движка с невероятно высокими требованиями по реалистичности. Ну, чтобы можно было камень с земли подобрать, кинуть в кого-то, или, например, ножку от стула оторвать, да пришить негодяя, либо снега отведать (почему нет?) и многое другое.
Всё это крайне пересекается с действительностью, а потому путь свой я начал с разработки системы онтологических категорий: `Entity`, `AbstractEntity`, `MaterialEntity`, `PhysicalObject`, ну и т.д. И всё было прекрасно до тех пор, пока я всерьёз не задумался о том, что действительно из себя представляют окружающие объекты?
Например, гитара. Это, вроде музыкальный инструмент, не так ли? Да вот как бы не так. Ещё это может быть оружием, а иногда - дровами для печки (если сильно надо).
К сожалению, ООП вынуждает описывать все поведенческие характеристики в типе объекта либо с помощью явно выраженных методов, либо с помощью реализации интерфейсов, однако это, на мой взгляд, не совсем подходит к текущей ситуации, потому что, анализируя тот или иной объект, я прихожу к выводу, что представление объекта как целого (о чём и есть ООП) складывается вместе с представлением о его внутренней структуре.
Т.е. вместо того, чтобы смотреть на гитару и думать: "О, это гитара, сейчас как сыграю!", я, вероятнее всего, мыслю: "Визуальные свойства данного объекта связаны с уже известным понятием гитара, которое связано с понятиями музыкальный инструмент, дерево, рукоять, опасность порвать струну и т.д.".
Как вариант решения я вижу: АОП + КОП, но пока не уверен, что это не потому, что мои познания в ООП чересчур малы.
В общем, товарищи и коллеги, надеюсь, кто-то подсобит советом и рекомендациями, хотя бы с тем, где искать ответы на свои вопросы. Спасибо!Update 1: добавлю немного кода.public abstract class Entity
{
public int Guid;
}
public abstract class MaterialEntity : Entity
{
public Vector4 Position;
public Vector3 Size;
}
public abstract class PhysicalObject : Entity
{
public Mass Mass;
public Temperature Temperature;
}
// Существо.
public abstract class Creature : PhysicalObject
{
// Здоровье, мана и прочее.
}
// Предмет какой-нибудь.
public abstract class Thing : PhysicalObject
{
}
Собственно, как классифицировать дальше, и нужно ли, с учётом того, сколько различных видов поведения может сквозить то тут, то там?
Например, на существо можно надеть одежду. Одежда - это Thing. Но её можно надеть не только на существо, но и на манекен, который также - Thing.
Ещё пример: оружие. Если продолжить так:public class Weapon : Thing
{
public int Damage;
}
public abstract class MusicalInstrument : Thing
{
public abstract void PlayMusic();
}
То как потом показать, что гитара - может быть как музыкальным инструментом, так и оружием, в зависимости от желания и контекста? Кажется, что наследование не помогает.
Если инкапсулировать поведение в объекты, как в паттерне Стратегия, то где их располагать? Отвечая на такие вопросы я пришёл к выводу, что поможет исключительно КОП, т.к. я хочу динамические сущности с динамическим поведением, но, быть может, существуют практики, о которых ещё не знаю, которые позволяют справляться с такой сложностью.Update 2: к сожалению и к моему удивлению, вопрос был многими неверно понят и, вероятнее всего, причиной этому послужила его неоднозначность и сложность интерпретации.
Так или иначе, для тех, кто, всё же, нашёл в нём что-то знакомое, с чем обязательно столкнулся бы всякий разработчик игр, пытающийся реализовать детскую мечту реалистичной игровой Вселенной, чем-то похожей на, скажем, серию TES (чем она и меня в своё время столь привлекала) и многие другие, я решил предоставить несколько наводок касаемо того, где искать ответ:
1. КОП - компонентно-ориентированное программирование. Примеры: Unity. Отсюда ES (Entity systems) - Artemis (C#).
2. АОП - аспектно-ориентированное программирование. Судя по описанию, в теории, может помочь.
3. Кажется (только половину прочёл), в книге Криса Партриджа Business objects: Re-engineering for Re-use вскрываются абсолютно те же проблемы, а также даётся полное описание того, как можно перепрошить парадигму мышления на иной лад, более похожий на действительность.
4. Также есть подозрения, что ответы будут в книге Object Thinking.
Всем спасибо за ответы и успехов!
Как с помощью ООП смоделировать сложный игровой мир? Всем доброго времени суток!
Впервые столкнулся с тем, что почти не представляю, как решить проблему моделирования системы с помощью ООП, а потому крайне нуждаюсь в советах и рекомендациях от более опытных коллег.
В чём, собственно вопрос? Я для себя постоянно что-то пишу, велосипежу, так сказать, и сейчас мой взор направлен на создание RPG-движка с невероятно высокими требованиями по реалистичности. Ну, чтобы можно было камень с земли подобрать, кинуть в кого-то, или, например, ножку от стула оторвать, да пришить негодяя, либо снега отведать (почему нет?) и многое другое.
Всё это крайне пересекается с действительностью, а потому путь свой я начал с разработки системы онтологических категорий: `Entity`, `AbstractEntity`, `MaterialEntity`, `PhysicalObject`, ну и т.д. И всё было прекрасно до тех пор, пока я всерьёз не задумался о том, что действительно из себя представляют окружающие объекты?
Например, гитара. Это, вроде музыкальный инструмент, не так ли? Да вот как бы не так. Ещё это может быть оружием, а иногда - дровами для печки (если сильно надо).
К сожалению, ООП вынуждает описывать все поведенческие характеристики в типе объекта либо с помощью явно выраженных методов, либо с помощью реализации интерфейсов, однако это, на мой взгляд, не совсем подходит к текущей ситуации, потому что, анализируя тот или иной объект, я прихожу к выводу, что представление объекта как целого (о чём и есть ООП) складывается вместе с представлением о его внутренней структуре.
Т.е. вместо того, чтобы смотреть на гитару и думать: "О, это гитара, сейчас как сыграю!", я, вероятнее всего, мыслю: "Визуальные свойства данного объекта связаны с уже известным понятием гитара, которое связано с понятиями музыкальный инструмент, дерево, рукоять, опасность порвать струну и т.д.".
Как вариант решения я вижу: АОП + КОП, но пока не уверен, что это не потому, что мои познания в ООП чересчур малы.
В общем, товарищи и коллеги, надеюсь, кто-то подсобит советом и рекомендациями, хотя бы с тем, где искать ответы на свои вопросы. Спасибо!Update 1: добавлю немного кода.public abstract class Entity
{
public int Guid;
}
public abstract class MaterialEntity : Entity
{
public Vector4 Position;
public Vector3 Size;
}
public abstract class PhysicalObject : Entity
{
public Mass Mass;
public Temperature Temperature;
}
// Существо.
public abstract class Creature : PhysicalObject
{
// Здоровье, мана и прочее.
}
// Предмет какой-нибудь.
public abstract class Thing : PhysicalObject
{
}
Собственно, как классифицировать дальше, и нужно ли, с учётом того, сколько различных видов поведения может сквозить то тут, то там?
Например, на существо можно надеть одежду. Одежда - это Thing. Но её можно надеть не только на существо, но и на манекен, который также - Thing.
Ещё пример: оружие. Если продолжить так:public class Weapon : Thing
{
public int Damage;
}
public abstract class MusicalInstrument : Thing
{
public abstract void PlayMusic();
}
То как потом показать, что гитара - может быть как музыкальным инструментом, так и оружием, в зависимости от желания и контекста? Кажется, что наследование не помогает.
Если инкапсулировать поведение в объекты, как в паттерне Стратегия, то где их располагать? Отвечая на такие вопросы я пришёл к выводу, что поможет исключительно КОП, т.к. я хочу динамические сущности с динамическим поведением, но, быть может, существуют практики, о которых ещё не знаю, которые позволяют справляться с такой сложностью.Update 2: к сожалению и к моему удивлению, вопрос был многими неверно понят и, вероятнее всего, причиной этому послужила его неоднозначность и сложность интерпретации.
Так или иначе, для тех, кто, всё же, нашёл в нём что-то знакомое, с чем обязательно столкнулся бы всякий разработчик игр, пытающийся реализовать детскую мечту реалистичной игровой Вселенной, чем-то похожей на, скажем, серию TES (чем она и меня в своё время столь привлекала) и многие другие, я решил предоставить несколько наводок касаемо того, где искать ответ:
1. КОП - компонентно-ориентированное программирование. Примеры: Unity. Отсюда ES (Entity systems) - Artemis (C#).
2. АОП - аспектно-ориентированное программирование. Судя по описанию, в теории, может помочь.
3. Кажется (только половину прочёл), в книге Криса Партриджа Business objects: Re-engineering for Re-use вскрываются абсолютно те же проблемы, а также даётся полное описание того, как можно перепрошить парадигму мышления на иной лад, более похожий на действительность.
4. Также есть подозрения, что ответы будут в книге Object Thinking.
Всем спасибо за ответы и успехов!
Впервые столкнулся с тем, что почти не представляю, как решить проблему моделирования системы с помощью ООП, а потому крайне нуждаюсь в советах и рекомендациях от более опытных коллег.
В чём, собственно вопрос? Я для себя постоянно что-то пишу, велосипежу, так сказать, и сейчас мой взор направлен на создание RPG-движка с невероятно высокими требованиями по реалистичности. Ну, чтобы можно было камень с земли подобрать, кинуть в кого-то, или, например, ножку от стула оторвать, да пришить негодяя, либо снега отведать (почему нет?) и многое другое.
Всё это крайне пересекается с действительностью, а потому путь свой я начал с разработки системы онтологических категорий: `Entity`, `AbstractEntity`, `MaterialEntity`, `PhysicalObject`, ну и т.д. И всё было прекрасно до тех пор, пока я всерьёз не задумался о том, что действительно из себя представляют окружающие объекты?
Например, гитара. Это, вроде музыкальный инструмент, не так ли? Да вот как бы не так. Ещё это может быть оружием, а иногда - дровами для печки (если сильно надо).
К сожалению, ООП вынуждает описывать все поведенческие характеристики в типе объекта либо с помощью явно выраженных методов, либо с помощью реализации интерфейсов, однако это, на мой взгляд, не совсем подходит к текущей ситуации, потому что, анализируя тот или иной объект, я прихожу к выводу, что представление объекта как целого (о чём и есть ООП) складывается вместе с представлением о его внутренней структуре.
Т.е. вместо того, чтобы смотреть на гитару и думать: "О, это гитара, сейчас как сыграю!", я, вероятнее всего, мыслю: "Визуальные свойства данного объекта связаны с уже известным понятием гитара, которое связано с понятиями музыкальный инструмент, дерево, рукоять, опасность порвать струну и т.д.".
Как вариант решения я вижу: АОП + КОП, но пока не уверен, что это не потому, что мои познания в ООП чересчур малы.
В общем, товарищи и коллеги, надеюсь, кто-то подсобит советом и рекомендациями, хотя бы с тем, где искать ответы на свои вопросы. Спасибо!Update 1: добавлю немного кода.public abstract class Entity
{
public int Guid;
}
public abstract class MaterialEntity : Entity
{
public Vector4 Position;
public Vector3 Size;
}
public abstract class PhysicalObject : Entity
{
public Mass Mass;
public Temperature Temperature;
}
// Существо.
public abstract class Creature : PhysicalObject
{
// Здоровье, мана и прочее.
}
// Предмет какой-нибудь.
public abstract class Thing : PhysicalObject
{
}
Собственно, как классифицировать дальше, и нужно ли, с учётом того, сколько различных видов поведения может сквозить то тут, то там?
Например, на существо можно надеть одежду. Одежда - это Thing. Но её можно надеть не только на существо, но и на манекен, который также - Thing.
Ещё пример: оружие. Если продолжить так:public class Weapon : Thing
{
public int Damage;
}
public abstract class MusicalInstrument : Thing
{
public abstract void PlayMusic();
}
То как потом показать, что гитара - может быть как музыкальным инструментом, так и оружием, в зависимости от желания и контекста? Кажется, что наследование не помогает.
Если инкапсулировать поведение в объекты, как в паттерне Стратегия, то где их располагать? Отвечая на такие вопросы я пришёл к выводу, что поможет исключительно КОП, т.к. я хочу динамические сущности с динамическим поведением, но, быть может, существуют практики, о которых ещё не знаю, которые позволяют справляться с такой сложностью.Update 2: к сожалению и к моему удивлению, вопрос был многими неверно понят и, вероятнее всего, причиной этому послужила его неоднозначность и сложность интерпретации.
Так или иначе, для тех, кто, всё же, нашёл в нём что-то знакомое, с чем обязательно столкнулся бы всякий разработчик игр, пытающийся реализовать детскую мечту реалистичной игровой Вселенной, чем-то похожей на, скажем, серию TES (чем она и меня в своё время столь привлекала) и многие другие, я решил предоставить несколько наводок касаемо того, где искать ответ:
1. КОП - компонентно-ориентированное программирование. Примеры: Unity. Отсюда ES (Entity systems) - Artemis (C#).
2. АОП - аспектно-ориентированное программирование. Судя по описанию, в теории, может помочь.
3. Кажется (только половину прочёл), в книге Криса Партриджа Business objects: Re-engineering for Re-use вскрываются абсолютно те же проблемы, а также даётся полное описание того, как можно перепрошить парадигму мышления на иной лад, более похожий на действительность.
4. Также есть подозрения, что ответы будут в книге Object Thinking.
Всем спасибо за ответы и успехов!
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Для моделирования сложного игрового мира с помощью ООП рекомендуется следовать принципам SOLID, создавая гибкую и расширяемую систему.
Создайте базовые классы для различных типов объектов в игровом мире, например, Entity, PhysicalObject, Creature, Thing, Weapon, MusicalInstrument и другие, как вы сделали в вашем примере кода.
Используйте наследование для определения отношений между различными типами объектов, чтобы дать каждому объекту доступ к общим характеристикам и методам.
Используйте интерфейсы для описания специфического поведения объектов. Например, создайте интерфейсы Playable, Weaponizable и другие для определения специфических действий, которые объекты могут выполнять.
Разделите поведение объектов на отдельные компоненты, которые могут быть добавлены или удалены во время выполнения. Этот подход, известный как компонентно-ориентированное программирование Component−basedprogrammingComponent-based programmingComponent−basedprogramming, позволит вам динамически изменять поведение объектов в зависимости от контекста.
Изучите паттерны проектирования, такие как Стратегия StrategyStrategyStrategy, Команда CommandCommandCommand, Состояние StateStateState и другие, чтобы найти подходящие способы реализации сложного поведения объектов в игровом мире.
Изучение принципов компонентно-ориентированного программирования и использование паттернов проектирования поможет вам создать гибкую и масштабируемую систему для моделирования сложного игрового мира. Не бойтесь экспериментировать и пробовать различные подходы, пока не найдете наиболее подходящий для вашего проекта. Удачи вам в разработке вашего RPG-движка!