Схематичні карти в рамках системи Entity System?

Я читав програми Entity System, зокрема Artemis. Я намагаюся вирішити, чи правильно це для мене. Я строго працюю над 2-піксельними арт-іграми на основі плиток, і не думаю, що вони коли-небудь будуть такими ресурсомісткими. Я завжди використовував стандартний ООП з великою кількістю спадку в минулому.

Моє розуміння системи Entity System прямо зараз (я не впевнений, чи зрозумів це повністю):

• Суб'єкти - це не що інше, як посвідчення особи
• Компоненти - це не що інше, як тупі дані, додані до пулу компонентів сутностей
• Системи - це функції оновлення, які приєднуються до світу для обробки кожної сутності, яка відповідає сигнатурі компонента Система

Якщо моє розуміння правильне, то у мене виникають досить багато проблем з концептуалізацією додавання табличних карт та AI поведінкових дерев у ці рамки. Я буду питати про AI в майбутньому.

Чи слід вбудовувати в цю рамку мапу плитки? Або його слід тримати окремо, щоб зробити його легко створювати за допомогою редактора кавових карт?

Якщо мапа плитки повинна бути вбудована в цю рамку, чи є кожна плитка різною сутністю? А карта-карта система? Або сама по собі карта макетів є єдиним цілим об'єктом із спадщиною, побудованим з неї?

Якщо карта карти розміщена в просторі, що було б найкращим способом виявлення зіткнень сутностей із зовнішньою картографічною плиткою?

Я розумію, що кілька варіантів, які я перерахував, можуть бути правильними, але якщо хтось робив це в минулому, вони могли б пролити трохи світла на мою розгубленість. Можливо, є ще одна альтернатива, про яку я не думав?

Дякую.

Я реалізував структуру компонентів сутності (подібно до Artemis) після того, як я вже був деякий час в розробці, але я не думаю, що я зробив би щось інакше, якби починався з порожнього аркуша.

У мене світ цілком відокремлений від сутності. Мені просто не було сенсу перетворювати світ у якусь сутність чи колекцію сутностей. Мій світ - 3D з кубиками, але я вважаю, що те саме стосується і плиток. Організації складають все інше у світі, але місцевість окрема. Однак, коли кубики виймаються, вони роблять нерестові "матеріальні" утворення.

Виявлення зіткнення не надто важко пов'язати. У вашому світі, ймовірно, isSolidAt(x,y)будуть використані методи типу, які використовує ваша система зіткнення. Чесність, я вже сьогодні це казав іншою відповіддю , робіть все, що має для вас найбільш сенс. Ви не порушуєте жодних правил, зробивши карту плитки відокремленою або зробивши її цілісною. Те, що можна обернути головою, - це найкраще. Для мене це утримувало світ окремим і робило все інше сутнісним.

Я додав мапу плитки як окремий компонент до сутності (з усіма плитками всередині), а також є окремий візуалізатор для карти плитки, тому я можу відобразити її в 3d або в 2d. Створити всі плитки як сутності можна, але дорого.

щось таке:

Entity e("map");
e.addComponent(new Tilemap("1.xml"));
e.addComponent(new TilemapRenderer2d(graphics));

tile map is something like that
class Tilemap
{
  array of tiles;
  getTileAtPosition(); 
  isWalkable ; etc;
}

class ITilemapRenderer
{}

class TilemapRenderer2d
{
draw() 
{ 
  foreach (tile in owner()->component()->tiles()) 
  {
    if (tile == ground) ground_sprite->draw() ....
  }
}

користь у відокремленні малюнка від логіки є базовою ідеєю шаблону MVC