Докуметация Cтарт Статьи Форум Лента Вход
Не официальное русскоязычное сообщество
Главная
    Документация jMonkeyEngine
        jMonkeyEngine Уроки и Документация
            Вклады
                Система Сущностей Zay-ES
                    Система Сущностей Детали

Система Сущностей Детали

Опубликованно: 13.07.2017, 17:50
Последняя редакция, Andry: 30.07.2017 19:46

Hello ES

Эта вики предназначена тем, кто хочет заниматься изучением Системы Сущностей.

Для начала вы должны прочитать краткое введение здесь, если еще не прочитали: Система Сущностей Введение

И возможно у вас все еще есть некоторые сомнения по поводу того, в нужном ли вы месте!

Эта вики — собрана из разных известных статей, из Интернета и нашего форума. Исправления приветствуются! Основным источником является обсуждение в этом разделе форума: Entity System topic (united)!

Зачем ты здесь?

Причины:

  1. Вы могли прочитать знаменитую статью T-machine о системах сущностей в mmorpg.
  2. Вы могли придти из Unity, UDK или других используемых движков
  3. Вы могли придти из базы данных и веб-мира
  4. Вы прочитали много статей, форумов и попробовали несколько проектов из интересных дискуссий

Но:

  1. Вы по-прежнему не уверены/нет ясности о ООП, КОП, управлении данными …
  2. У вас есть сомнения в понимании концепции ES, и вы не можете сделать ES правильно
  3. Вы хотите узнать больше

Я надеюсь, что эта страница поможет вам хотя бы на 30% добраться до вашей цели. Это место, где мы затрагиваем тему конструкции и премудростей ES, и рассмотрим его подробную реализацию на Java, и в конечном итоге интегрируем в JME3 для игры в реальном времени.

Прежде чем вы начнете, я также хочу упомянуть, что в JME3 реализовано несколько ES. После того как вы прочитаете эту страницу, вы сможете судить о дизайне каждой из них и выбрать одну из них. Также прочитайте интервью каждого автора об его подходах!

Темы и Структура этой страницы

1) Введение:

  1. Основная идея ES: Entity, Processor(System), другие термины.
  2. Элементы ядра и альтернатива
  3. Что НЕ является ES …

2) Зачем, когда, и где нужна ES.

  1. Плюсы и Минусы?
  2. Узнать о проблемах
  3. ООП для КОП, или что то еще
  4. Изменение мышления

КОП Системы Сущностей в ООП java

Система Сущностей в свою очередь является Ядром и фундаментальной и наиболее очевидной реализацией дизайна КОП (компонентно-ориентированного программирования) в масштабе приложений реального времени!!!

На самом деле детали реализации системы Сущностей различны, некоторые могут напоминать ядро базы данных, некоторые могут иметь проблемы из за несовместимости с ООП, некоторые могут показаться полезными для функционального языка…

Но обратите внимание, что Система Сущностей действительно опирается на собственную терминологию изложенной на этой странице:

Мы говорим о ES на КОП, но реализуем чистую ООП, такую как Java.

Идеи и концепции


Идея


Концепция

Слайды

Картинки


Элементы ядра и альтернатива

Обозначения определений:
  • Нормальный — очевидное/нет причин для сомнения в определении.
  • Жирный — это ключевые слова.
  • Наклонный — примеры.
  • Подчеркивание — это наличие сомнений
  • Зачеркнуто — значит подробностей реализации, нет в описании

Сущность(Entity)

Сущность(Entity) — это просто уникальный идентификатор(ID). Каждый Unit, Item, Bullet и.т.д. в вашей игре будет представлен одним из этих идентификаторов(ID) сущностей.

Компонент(Component)

Компонент(Component) — это класс, который содержит только данные. Это означает, что у него есть конструктор и только методы getter. Примерами Компонентов могут быть: * PositionComponent * MovementComponent * CollsisionComponent

Компоненты добавляются к Сущностям.

Одновременно может существовать только один компонент одного и того же класса для одной сущности.

Как вы можете видеть, сущности могут состоять из разных Компонентов что делает их достаточного гибкими. Вам нужен иметь бронированного робота? Нет проблем, вам нужно только объединить нужные компоненты. Кроме того, вы можете удалить/изменить/добавить компоненты во время игры, что является огромным преимуществом Системы Сущностей.

Система(Systems)

Если говорить просто, то все остальные классы, кроме компонентов и сущностей, можно рассматривать как системы. Вы должны обратить на этот момент внимание, когда читаете о других Системах Сущностей, потому что они могут иметь другое представление о том, что такое система.

В системах вы можете запросить все Сущности, которые имеют специальные компоненты. Например, вы можете сказать, что вам нужно вычисляли новую позицию у всех Сущностей, у которых есть компонент позиции и движения, и затем перезаписать старые компоненты позиции новыми.

Сходство идей:

От Компонентно-ориентированной архитектуры:

  1. Разделённость
  2. Многоразовость
  3. Простые блоки

От архитектуры ориентированной на управление Данными:

  1. Данные, которые принимают решения

От архитектуры ориентированной на Данные:

  1. Всё данные
  2. Существование хранилища
  3. Однородность данных
  4. Регулярная рабочая нагрузка
  5. Простой поток данных

Краткое пояснение

  1. Разделённость: каждая часть может работать вместе с другими, не зная при этом о существовании друг друга.
  2. Многоразовость: можно легко использовать снова в другом месте
  3. Простые блоки: каждая часть состоит из простейшей формы, которая содержит, собственную реализацию.
  4. Данные, которые решают: данные решают каждый результат, деятельность программного обеспечения
  5. Всё данные: все части в программной системе — это Данные
  6. Существование хранилища: существует место, где хранятся все данные, и один способ для их получения
  7. Однородные данные: данные обрабатываются одинаково
  8. Регулярная рабочая нагрузка: программное обеспечение, которое работает по регулярном темпе, представляет собой компромиссный баланс между производительностью и сложностью
  9. Простой поток данных: поток данных легко наблюдать, проверять, запускать, манипулировать. Нужно главным образом для регулярной рабочей нагрузки!

Сходство идей здесь на самом деле является следствием десятилетий истории возобновления парадигмы. Вот почему вы увидите, что те же понятия системы Сущностей появляются повсюду в базах данных в репозиториях. Конечно, потому что он имеет один и тот же корень. Ознакомьтесь с главой «Плюсы и Минусы», чтобы получить полную, подробную идею и цели достижения.

Термины

Ниже перечислены некоторые термины, но обычно они ошибочно или неуместны из-за их путаницы. Попытайтесь изучить их в первую очередь, чтобы убедиться, что вы четко поняли все определения!
  1. Объектно Ориентированное Программирование(Object Oriented Programming)
  2. Программирование Ориентированное на Данные(Data Oriented Programming)
  3. Компонентно Ориентированное Программирование(Component Oriented Programming)
  4. Программирование, управляемое данными(Data driven programming)
  5. Способы управления Данными (архитектура)(Data driven solution)

Вот короткая, статья которая поможет вам быстрее в этом разобраться: термины


Что НЕ является ES?

Если смотреть с более «открытой» точки зрения элементы ядра можно рассматривать так, но помните, что имя существительное может вводить в заблуждение: это вылилось в дискуссию @pspeed и toolforger, в конечном счете, это скептический вопрос, это действительно интересно тем, как мы все видим эту проблему смущающую поначалу!!

   Сущность -> ID. Он просто связывает компоненты вместе, в том смысле, что есть одна функция, которая создает связку компонентов с одним ID и одну функцию для уничтожения всех компонентов для связанных с этим ID. Сущность - это набор объектов, имеющих один ID на всех, сущности не существуют как целостные объекты внутри кода.

   Компонент -> грань. Позиция - это грань сущности, ее скорость, здоровье, доспехи, все что угодно. Если сущности были объектами Java, грани были бы группами взаимосвязанных свойств.

   Система -> Процессор. Функция, которая работает с частями компонентов.

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

Подводные камни и Практическая мудрость

Эта область содержит некоторые подводные камни и хорошие практические мудрости при работе с ES. Я поднял это на более высокую позицию страницы, потому что я думаю, что практические работы будет полезна нам больше, чем теории. Эта страница может быть названа «Дизайн-курс» но без этого раздела! 😊

Система ~ Процессор?

В чистой ES это не объект. Некоторые реализации навязывают это вам, потому что они не могут придумать, как эффективней выполнять работу ES ... но это все еще не объект. Весь ваш код, который не является ES, является «системой», технически.

System = все, что не является Сущностью или Компонентом, но использует Сущности и Компоненты.

Сущности ~ ИгровойОбъект?

Сущность должна просто интерпретироваться как связка ее Компонентов. ИгровойОбъект или что-либо еще, представленное в виде Сущности, выполняется случайным образом. Таким образом, нет никакой силы представляющей «все что есть» игровыеобъекты как Сущность; И нет силы, что «все что есть» Сущности делает игровымиобъектами.

Имеет(Has) ~ Является(Is)?

От проектировщик программного обеспечения на мой взгляд отношение к КОП является чувствительной темой; По своей природе, Компонент против (или переопределения) Связей.

Хитрость «Имеет» связь между Сущностью и ее Компонентом на самом деле представляет по разному в литературе «Является» или «Имеет» .. к «связанному с». НО имейте в виду, это размытие и почти всегда реализуется как косвенный доступ, а не как свойство в объекте, но оно включает в себя скрытую обработку-поиска! Таким образом, ва может быть трудно обнаружить, их отличие от вашего традиционного ООП дизайна программного обеспечения!

Некоторые идеи

Это место, где вы можете делиться «реальными» трудностями при работе с ES, здесь, в JME3 или в других движках. В Практических мудростях будут поднимать некоторые известные решения для них. Этот раздел может оживить часть разделов Минусы или известных проблем, на практике.

Практические мудрости

Сделать правильно ES

Поскольку этот вопрос достаточно спорный, у нас нет конкретного кандидата для ES, уже сделанного, с моей точки зрения, но Zay-ES и Artemis являются самыми близкими к этому, Zay-ES немного лучше, чем его немного более поздний родственник.

Почему спорный [Short]?

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

Эта тема почти всегда разжигает дискуссию, кто-то считает что должно быть как ООП а не КОП, ES не для всех, и.т.д. Сначала дебаты должны быть сосредоточены в определенной области, конкретном жанре. Здесь (на этой странице) мы по-прежнему размещаем распространенные утверждения. Но позже в интервью вы можете увидеть некоторые «реальные приложения и реализации».

Должно быть?

Теоретически ES сделанный правильно на Java, должен представлять из себя:

  1. Чистые данные: очень спорные
    1. — Изменчивый: как компонент с сеттером и геттером
    2. — Без изменений: как компонент с геттером, следует заменить, что бы изменить.
  2. Многопоточность, возможность параллелизма: очень спорные
    1. — По моему опыту работы, нет простой информации и нет, ясной договорённости как успешно применять многопоточность. Подумайте, ведь есть и другие вещи в вашей программе происходящие за пределами области ES, и поэтому нет точной гарантии того, что эти компоненты не будут затронуты никаким другим потоком.
    2. — Кроме того, если есть необходимость, что бы ни один другой поток не касается этих данных, в стиле Java через синхронизацию или другую парадигму, такую как actor… многопоточность можно реализовать успешно, но это будет сложнее!
  3. Обмен информацией: очень спорный
    1. — Возможность обмена сообщениями о событиях
    2. — Нет событий или сообщений: обновление бита, отсутствие необходимости в inter-com или событиях. Как мы можем делать сетевые сообщения?
  4. Является ли дружественным как база данных (и другие постоянные)
    1. — Сохранить в XML?
    2. — Отправлять по сети?
    3. — Наборы изменений напоминают концепцию базы данных, а что же касается транзакций?
  5. Является ли дружественным для предприятия (растяжимый/расширяемый/модульный)
    1. — Получаются, как лениво загруженные, инъекции?
  6. Возможности сценариев(скриптов)
    1. — Может быть сценарий, нетривиальная работа в чистых данных!
    2. — Может использоваться с другими языками JVM, кроме java, вроде groovy или scala, jython?
  7. Ограничения и оговорки
    1. — Нет динамических методов Java-объектов в Компоненте? Что касается объектов и систем (Processors(Обработка))
    2. — Общий способ управления и настройки Систем, свободно выбирать? Как подключиться к своим подпрограммам?
  8. Зависимости
    1. — Четкое разделение компонентов, так как никаких зависимостей вообще нет. Жесткая сердцевина, сценарий или инъекции которые могут нарушать все договоренности!
    2. — Разделение сущностей. Что относительно зависимостей сущностей? Пример: отношения родителя/потомка в JME spatial. Как структура рычагов работает?
    3. — Разделение Системы. Пример: какая-нибудь договорённость связанная с этим?

Детали объяснение: пункты

Дизайн

На этапе проектирования даже не знаю ни одной детали реализации, мы судим о концепциях дизайна и его Инфраструктуре!!!. Подробные оценки по реализации мы рассмотрим позже!
Это короткий контрольный список, который поможет вам открыть свой разум, прежде чем приступать к разработке ES. Он короткий и полезный; Раздел «Плюсы и Минусы» нужно просмотре с серьезным отношением!

Зачем, когда, и где нужна ES.

Зачем?

  1. BLOB также известный как Падение наследования: Состовной тип не может быть представлен как класс в java ООП!
  2. Устали от ООП. Составляйте как в старой школе программирования. Как художники.
  3. Многоразовый засчёт сборности (ну, это очень спорно, при сравнении с ООП !!)

Когда?

  1. Тщательное рассмотрены проблемы сложности и производительности.
  2. Вход и выход настроены правильно. Игровые ресурсы все в хорошем формате, вывод четко определен, рабочий процесс и подпрограммы исправлены. Видел в коммерческом движке 3D-игр.

Где?

  1. В основном для обработки/управления вашими данными и сущностями.
  2. Обычно в MMO, где используется BLOB.
  3. В среде для обработки пакетов/кэшей, устройств. GPU, и другие.

Почему нет?

  1. Легко понять это неправильно, потому что вы обычно приходите к этому из мира ООП (конечно, потому что вы разработчик Java).
  2. Будучи неправильно сделанной может требовать слишком много времени исполнения, что недопустимо!
  3. Это не доказанная технология (вот почему мы здесь)
  4. У него плохие проблемы
  5. Только для определенных случаев (не всегда)
  6. Нет хорошей поддержки в IDE, GUI в Java или JME3 в настоящее время

Когда нет?

  1. Есть ограничение по времени и это ваша первая попытка! (Может быть хорошо, если в ограниченное время, но только если уже готовый произведенный режим ES)
  2. Маленькая игра, простой игровой процесс…

Плюсы — Минусы?

Здесь я перечислил плюсы и недостатки КОП и чистых данных ES.

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

Плюсы:

  1. Нет BLOB анти-шаблонов, не глубокое наследование считают плохим последствием

Читайте: GameObjects1

Много хороших вещей вы получите, если сделаете «правильно»!

  1. Просто, интуитивно понятно
  2. Передача информации стала простой
  3. Вы видите, что у вас есть → составляемость
  4. Многоразовость вместе со сборностью
  5. Пакетная/последовательная обработка/кэширование, в современных CPU, GPU
  6. … еще десять

Сущность/Компонент Игровой Дизайн: A Primer

Минусы:

«Проблема» здесь означает «проблему», раскрывающую не такую уж и плохую ситуацию!
  1. Нет ООП: сделать КОП «правильно» означает забыть о почти всех вещах ООП: чистые данные, Класс становятся Типом, без наследования, инкапсуляции… и.т.д., не лучшее из обоих миров!
  2. Дилемма разделения: То же самое с проблемой ООП Классифицировать: как разделить, как изменить данные при изменении в разделах?
  3. Дублированный компонент: тот же корень, что и путаница в разбиении компонентов, но, эта проблема о том, как мы можем сделать более одного компонента в виде объекта для сущности… Пример: автомобиль с 4 колесами, компонент будет с 1-ним колесом, 2-мя колесами или одним Списком WheelComponent …?
  4. Задача передискретизации данных в игре, данные, такие как текстуры, текст, 3D-модели, всё… должны быть созданы: сделаны, снова преобразованы в набор с существующей моделью данных — это компонент в ES.
  5. Проблема с изменением мышления: каждый раз придется перекодировать несколько раз, чтобы реализовать ES, в начальном, разобранном на части и собранном уровне.
  6. Проблема с плоской таблицей: поскольку по своей природе ES является большой таблицей, с набором компонентов являющихся строками. Это так же эффективно даже меньше, чем большая таблица, которая формирует проблему с плоской таблицей, как видно из многих индексированных баз данных. Дерево, Граф и другая структура данных почти сразу же нарушат договоренности ES!
  7. Проблема наблюдений: Так как процесс обновления подавляет методы слушателей, ES значительно ограничивает методы наблюдения.
  8. Проблема безопасности: нет инкапсуляции, нет никакого private POJO означает отсутствие власти Java в защите данных, много дыр в безопасности! Реализация ES и КОП забывают совсем о защите от опасностей, поскольку Компонент заключил контракт на обработку Processor, но не скрывает своего содержимого.
  9. Масштаб: теоретически ES должен хорошо масштабироваться .. !!! Но прочтите это внимательно или будете введены в заблуждение, так как корпоративная система нуждается в гораздо большем, чем просто способ для организации ваших данных!
Поскольку многим людям интересны больше минусы ES, я подробно все перечислил здесь. Узнав приемлемые решения этого от других авторов, я удалю или помечу решённую проблему! [Мир! :p]

ES считается хорошим дизайном для приложений реального времени?

Конечно, у ES есть свои возможности!!!!

Но по какой-то причине его дизайн считается хорошим для приложений реального времени, таких как «общие» видеоигры или «общие» симуляции; Особенно распространен в мире MMO.

Ниже приводится краткое описание «почему» по мнению дизайнера архитектуры программного обеспечения, объясннение на основе его заимствованных идей: [Это сильно отличается от того, что вы читали, потому что он не встраивает какие-либо детали реализации !!!]

  1. Разъединенность: каждая из частей может работать вместе с остальными, не зная друг о друге.
  2. Многоразовый: можно легко использовать снова в другом месте.
  3. Компонуемый: каждая часть может работать вместе с другими

Имеют фундаментальные отношения с разъединенностью.

  1. Примитивная единица: каждая часть из состоит простейшей формы, которая содержит, собственное выполнение.

Имеют фундаментальные отношения с разъединенностью.

(*) Это дает преимущества в разработке:

  1. Делать это в одном месте только при выполнении реализации (кодинг, конфиги…),.
  2. Интуитивно понятное и легкое в разработке (составьте сущность и перетаскивайте в неё компоненты)
  3. Распределённость игровых ресурсов
  4. Код повторного использования данных, расположен в существующем компоненте
  5. Модульность тестирования
  6. [Больше]

  1. Данные, которые решают: данные решают каждый результат, деятельность программного обеспечения
  2. Всё данные: все части в программной системе — это Данные
  3. Существование хранилища: существует место, где хранятся все данные, и один способ для их получения

(*) Они открывают мир сложного геймплея и все больше распространяются, как например в MMO. Изменение всего одного из данных может привести к изменению игрового процесса;


  1. Однородные данные: данные обрабатываются одинаково
  2. Регулярная рабочая нагрузка: программное обеспечение, которое работает по регулярном темпе, представляет собой компромиссный баланс между производительностью и сложностью
  3. Простой поток данных: поток данных легко наблюдать, проверять, запускать, манипулировать. Нужно главным образом для регулярной рабочей нагрузки!

(*) Это приводит к большому простому, но эффективному алгоритму, позволяющему получить высокую производительность во время выполнения, для такого программного обеспечения, как «общие» видеоигры, которые запускаются на консолях, GPU, CPU, который включает в себя и части одной и той же модели с кешем и пакеты инструкций, определяющими работу программы… Обратите внимание на проблемное место CPU-GPU и между различными процессорами, платформа — это самая большая головная боль игрового дизайнера за последние десятилетия — с обычной рабочей нагрузкой это просто; пусть игра проходит гладко и стабильно, а результат будет в приятном визуальном представлении.

ES считают плохой дизайн в …?

Из @pspeed:

Это плохой выбор дизайна, где:
   - Используется не так много сущностей и/или поведение настолько четко определено, что вы просто реализуете его в одном или двух классах. Такие штуки как карточные игры, различные головоломки и.т.д.
   - Игра настолько проста, что она просто реализована как control JME и несколько состояний приложения. Вы могли бы использовать ES здесь, но в этом нет необходимости.
   - Игровая логика почти все время использует все объекты. (Мне в голову снова приходят карточные игры и игры-головоломки.) Это обычно подразумевает, что есть всего несколько сущностей.
   - Команда, выполняющая работу, имеет трудности с пониманием ES. Для меня это огромная проблема. Иногда наш выбор технологий продиктован не тем, что может быть технически лучшим... но тем что технически, лучше всего подходит к навыкам команды. Например, если ваш художник знает только Sketchup, то Blender, вероятно, не самый правильный инструмент, даже если он превосходит по многим параметрам.

Узнать о проблемах:

Даже если все сделано правильно, ES также содержит в себе проблемы, которые были замечены его авторами (это означает, что это раздражающие вещи)!

Почему в этом разделе есть вещи из раздела «Минусы», но рассматриваются иначе?

В разделе «Минусы» перечислены проблемы которые должна быть связана с проблемами, которые могут вызывать ошибки, или связанны с пределом дизайна, это может быть исправлено в реализации или нет, не имеет значения!

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

Обмен информацией:

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

- Прямая связь с использованием динамических вызовов и функций
- Косвенная связь с использованием передачи сообщений

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

Как указано в ссылке [6] Читать: componentbasedprogramming.pdf


Сценарий(Script)

«Проблема со сценарием» происходит по той же причине что и «проблемой с обменом информацией», вперемешку с проблемой «чистые данные или нет». Когда компонент трудно проверить, его внешние связи трудно определить, а его свойства получаются не изменяемыми, как вы можете реализовать его в сценарии?

Читайте: Сценарии со Структурой Системы Сущностей Artemis

Почти до конца, и назад к решению полузадач, в место чистых данных ES, если они действительно нуждаются в написании сценариев.


Произвольная рутина и запросы

Обнаружение внутри диапазона с большим количеством сущностей

Подходы к внедрению


ООП для КОП, или что то еще

Точка зрения @atomix:

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

BLOB это не проблема при тщательно разработанном программном обеспечении, так же, как и при разбивке ваших компонентов… Проблемы с глубоким наследованием или даже проблемы с несколькими наследствами невозможно достичь в инди-проекте, и даже если они достигнуты это, всегда поддерживать проще, чем перепроектировать 3D-модель для изменения Экспортно конвейера(пайплайна)!!!

Также запутанные связи между наследованием формируют природу программирования и универсальную материю. :p

НО У них есть поддержка IDE, профайлер, проверенные технологии, и многое другое … Мы говорим не о парадигме поддержки IDE с простым текстовым редактором, таблицей и черной магией, мы говорим подробнее о том, что нужно что бы компания одобрит ваш план?

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

  1. Фреймворк Smart bean: попробуйте Spring, EJB. Для Enterprise, если вы знакомы с EJB и Spring, вы не будете делать ставку на доморощенный ES, не так ли?
  2. Фреймворк Actor: попробуйте AKKA
  3. Если вы видите java как провальную, попробуйте может Scala потянет…
Итак, мой последний совет: если вы не делаете MMO то Взгляните на другие альтернативные технологии. !!!!
  1. Взгляните на ссылку [7] и Почему я переключился с компонентной архитектуры игрового движка на функциональное реактивное программирование, парень предлагает перейти на функциональное реактивное программирование: p
  2. Попробуйте Scala и AKKA и узнайте больше о параллелизме, не используйте плоскую таблиу!!!

Изменение мышления

Я думаю, что это должно быть на другой странице или даже в книге! :p

Эта глава посвящена людям, которые действительно хотят переключиться на эту новую парадигму после всех предупреждений и осмысления. Итак, эта глава будет главным образом отвечать на один БОЛЬШОЙ вопрос:

Что нужно изменить, чтобы адаптироваться к этой новой парадигме?

С чем мы столкнемся


Что должно изменится


Моделирование объектов в ООП в сравнении с моделированием объектов в КОП


Управление командой


Java проекты Системы Сущностей

Некоторые проекты с открытым исходным кодом где используется Система Сущностей:

Artemis: Главное

GoogleCode: artemis-framework

Website: Gamadu.com

Wiki: Структура Системы Сущностей Artemis

Обзор: ЗДЕСЬ! Artemis, потому что я не могу связаться с автором Artemis в данный момент, поэтому у меня будет краткий обзор его с некоторыми примерами из моего опыта работы над ним и основанных на его исходном коде!

Spartan: [используется для Slick. заброшен]

GoogleCode: spartanframework


JME интеграция

Zay-ES : @pspeed

Пост: Мои ES в Contrib: Zay-ES

Форум: zay-es

Wiki: Система Сущностей Zay-ES

Ссылки: Zay-ES Ссылки (много символов, потому что форум является немым)

Беседа:

EntityMonkey : @zzuegg

Post: EntityMonkey, простая Система Сущностей для JME

Private : @Empire phoenix

Беседа:

Реализация и сфера каждого проекта:

Сравнение будет сосредоточено на этих нижеследующих пунктах, по которым можно будет оценить сферу применения и статус каждого проекта

  1. Начальная философия
  2. Чистые данные или нет?
  3. Многопоточность, возможности параллелизма включены или нет?
  4. Обмен информацией: передача сообщений о событиях включены или нет?
  5. Является ли как база данных (и другие постоянные) дружественным или нет?
  6. Является ли для предприятия (расширяемым / расширяемым / модулизуемым) дружественным или нет?
  7. Возможности сценариев?
  8. Ограничения и оговорки
  9. Зависимости
  10. Текущий статус: Долгосрочный, стабильный, есть сообщество?

Таблица сравнения находится в документе Google: Помогите мне заполнить его !!!!

Сравнение Систем сущностей

Исследования и статьи

Ссылки на статьи, исследования и документы, которые вы должны прочитать:

Start of the wave(Начало волны)

Sploreg ES in JME introduction in indiedb(Sploreg ES в JME введение в indiedb)

Worth to read, pspeed conversation with Michael Leahy, also lead another ES project TyphonRT(Стоит прочитать, pspeed разговор с Michael Leahy, также возглавляющий еще один ES проект TyphonRT)

Наша ссылки на wiki

[4] Система Сущностей Введение

Beside of BLOB anti pattern, explain why ES suite as data in modern GPU, CPU!(Помимо BLOB-анти-шаблонов, объяснение, почему ES-комплект как данные в современном GPU, CPU!)

Worth to read, paper of another C++ ES leader of cistron project cistron(Стоит прочитать, документ другого лидера C ++ ES cistron project cistron)

Stack over flow topic, links, texts and especially interesting recommendation to switch form CBSE , COP to functional programming!(Переполнение стека, ссылки, тексты и особенно интересные рекомендации по переключению формы CBSE, КОП на функциональное программирование!)

Link to other entitiy system approaches in its own wikidot!(Ссылка на другие подходы системы сущностей в своем собственном викидоте!)

[9] Интересно написанно в GDD о ES и событиях в игровом движке. И некоторые проблемы с реализацией, рабочего процесса

Компоненты Системы (GDD#1.1)

[Еще?]


Переведено для jmonkeyengine.ru, оригинал
Автор перевода: Andry

Добавить комментарий

jMonkeyEngine.ru © 2017. Все права сохранены.