Нещодавно я зробив просту гру Space Invadors, використовуючи «сутність системи». Це закономірність, яка надзвичайно добре розділяє атрибути та поведінку. Мені знадобилося кілька ітерацій, щоб повністю зрозуміти це, але як тільки ви отримаєте кілька розроблених компонентів, це стає надзвичайно простим для складання нових об’єктів, використовуючи існуючі компоненти.
Ви повинні прочитати це:
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
Він часто оновлюється надзвичайно обізнаним хлопцем. Це також єдина дискусія щодо системної системи з конкретними прикладами коду.
Мої ітерації пройшли так:
Перша ітерація мала об'єкт "EntitySystem", як описав Адам; однак у моїх компонентів все ще були методи - мій компонент, що відводиться, мав метод paint (), а мій компонент позиції мав метод move () і т. д. Коли я почав витісняти сутності, я зрозумів, що мені потрібно почати передавати повідомлення між компоненти та замовлення виконання оновлень компонентів .... так само брудно.
Отже, я повернувся і перечитав блог T-машин. У нитках коментарів є багато інформації, і в них він дійсно підкреслює, що компоненти не мають поведінки - поведінка забезпечується системами сутностей. Таким чином, вам не потрібно передавати повідомлення між компонентами та замовляти оновлення компонентів, оскільки впорядкування визначається глобальним порядком виконання системи. Гаразд. Можливо, це занадто абстрактно.
У всякому разі для ітерації №2 це те, що я зібрав із блогу:
EntityManager - виступає як компонент "база даних", яку можна запитувати для об'єктів, що містять певні типи компонентів. Це навіть може бути підкріплено базою даних пам'яті для швидкого доступу ... Докладнішу інформацію див.
EntitySystem - кожна система по суті є лише методом, який працює на множині елементів. Кожна система використовуватиме компонент x, y і z сутності для завершення роботи. Таким чином, ви б запитали менеджера для об'єктів із компонентами x, y і z, а потім передаєте цей результат у систему.
Сутність - просто ідентифікатор, як довгий. Сутність - це те, що групує набір екземплярів компонентів разом у «сутність».
Компонент - набір полів .... немає поведінки! коли ви починаєте додавати поведінку, вона починає бруднитися ... навіть у простій грі Space Invadors.
Редагувати : до речі, "dt" - час дельта з часу останнього виклику основного циклу
Отже, моя основна петля загарбників:
Collection<Entity> entitiesWithGuns = manager.getEntitiesWith(Gun.class);
Collection<Entity> entitiesWithDamagable =
manager.getEntitiesWith(BulletDamagable.class);
Collection<Entity> entitiesWithInvadorDamagable = manager.getEntitiesWith(InvadorDamagable.class);
keyboardShipControllerSystem.update(entitiesWithGuns, dt);
touchInputSystem.update(entitiesWithGuns, dt);
Collection<Entity> entitiesWithInvadorMovement = manager.getEntitiesWith(InvadorMovement.class);
invadorMovementSystem.update(entitiesWithInvadorMovement);
Collection<Entity> entitiesWithVelocity = manager.getEntitiesWith(Velocity.class);
movementSystem.move(entitiesWithVelocity, dt);
gunSystem.update(entitiesWithGuns, System.currentTimeMillis());
Collection<Entity> entitiesWithPositionAndForm = manager.getEntitiesWith(Position.class, Form.class);
collisionSystem.checkCollisions(entitiesWithPositionAndForm);
Спочатку це виглядає трохи дивно, але неймовірно гнучко. Це також дуже просто оптимізувати; для різних типів компонентів ви можете мати різні резервні сховища даних для швидшого пошуку. Для класу "форма" ви можете мати його підкріпленим квадратом для швидкого доступу для виявлення зіткнень.
Ти мені подобаєшся; Я досвідчений розробник, але не мав досвіду писати ігри. Я провів деякий час на дослідженні моделей розробників, і цей потрапив мені в очі. Це жодним чином не єдиний спосіб робити речі, але я вважаю це дуже інтуїтивним та надійним. Я вважаю, що модель була офіційно обговорена в 6-й серії серії «Ігрові дорогоцінні програми» - http://www.amazon.com/Game-Programming-Gems/dp/1584500492 . Я сам не читав жодної книги, але чую, що вони фактично є посиланням для програмування ігор.