1

Тема: Яким чином краще зпроектувати контроллер мобів на сервері?

Хай. От в мене є список з клієнтів

List<Client> clients;

Для того, аби відправити комусь якісь дані, потрібно мати доступ до цього списка. І мають бути моби, позиція котрих змінюється на сервері та відразу передається всім клієнтам. Як краще це все зпроектувати? Зробити клас Mob{}, змінювати в ньому позицію і прямо з цього класа відправляти всім клієнтам нову позицію? Тобто в цього класа має бути доступ до списка з клієнтами. І буде це виглядати якось так:

  • створюється купа класів Mob{}

  • при створенні кожному класу передається посилання на список з клієнтами

  • позиція починає змінюватись і кожен з класів Mob{} буде звертатись до списка з клієнтами

Чи може зробити список з мобів, а в класі Client зробити метод, котрий мав би доступ до списку мобів та "забирав" би нові позиції мобів і відправляв клієнту?
Також не забувайте, що нам десь потрібно зберігати всіх мобів, тому що коли персонаж заходить в гру, він має отримати список, котрий зкладається з даних - скільки мобів, які саме моби, в яких позиціях стоять. От.

2

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

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

Нехай клас Моб{} містить методи, пов’язані з мобами, клас Гра{} — список мобів і правила гри, клас Сервер{} створює гру, надає їй дані від клієнтів і відправляє клієнтам дані, отримані від гри.

3

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

FakiNyan написав:

Чи може зробити список з мобів, а в класі Client зробити метод, котрий мав би доступ до списку мобів та "забирав" би нові позиції мобів і відправляв клієнту?

Щось підказує що цей варіант складніший в реалізації але буде результативнішим . Написати клас моб , з загальними х-ками а наслідувати кожен різновид окремо , залежно від кількості різновиду кожному задати розташування  , а там з інтервалом відправляти позицію , а краще якщо моб статичний перевіряти кеш якщо його ніхто не вбив тоді не відправляти знову а просто проходити далі по списку мобів . якось так .

4

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

quez написав:

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

Нехай клас Моб{} містить методи, пов’язані з мобами, клас Гра{} — список мобів і правила гри, клас Сервер{} створює гру, надає їй дані від клієнтів і відправляє клієнтам дані, отримані від гри.

емм, а можна, Гра() буде методом в Сервері{}, і так, як список клієнтів  - це поле в Сервері{}, то Гра() буде мати доступ до них, і саме Гра() буде відправляти дані клієнтам?

5

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

FakiNyan написав:
quez написав:

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

Нехай клас Моб{} містить методи, пов’язані з мобами, клас Гра{} — список мобів і правила гри, клас Сервер{} створює гру, надає їй дані від клієнтів і відправляє клієнтам дані, отримані від гри.

емм, а можна, Гра() буде методом в Сервері{}, і так, як список клієнтів  - це поле в Сервері{}, то Гра() буде мати доступ до них, і саме Гра() буде відправляти дані клієнтам?

Заводити сутності чи ні — це вирішувати тільки вам. Але в класі гри можна було б зв’язати мобів, гравців і світ, а метод вийде неймовірно громіздким навіть для найпростішої гри.

6

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

quez написав:
FakiNyan написав:
quez написав:

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

Нехай клас Моб{} містить методи, пов’язані з мобами, клас Гра{} — список мобів і правила гри, клас Сервер{} створює гру, надає їй дані від клієнтів і відправляє клієнтам дані, отримані від гри.

емм, а можна, Гра() буде методом в Сервері{}, і так, як список клієнтів  - це поле в Сервері{}, то Гра() буде мати доступ до них, і саме Гра() буде відправляти дані клієнтам?

Заводити сутності чи ні — це вирішувати тільки вам. Але в класі гри можна було б зв’язати мобів, гравців і світ, а метод вийде неймовірно громіздким навіть для найпростішої гри.

ой, ну гаразд, якщо ви так кажете... Як мені назвати той клас?

7

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

quez написав:

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

Нехай клас Моб{} містить методи, пов’язані з мобами, клас Гра{} — список мобів і правила гри, клас Сервер{} створює гру, надає їй дані від клієнтів і відправляє клієнтам дані, отримані від гри.

Так. Виникла проблема. Як ви розумієте, моби можуть гавкати на гравців та завдавати їм шкоди, ну тобто атакувати. І тому моб має мати можливість в якийсь момент часу відправляти всім клієнтам інформацію про те, що він атакує якогось з персонажів. І Гра{} не буде постійно перевіряти, чи не хоче якийсь моб вдарити персонажа, ага? Тому Моб{} має мати доступ до списку клієнтів.

8

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

Тому Моб{} має мати доступ до списку клієнтів.

А також до списку інших мобів і взагалі до всього світу, принаймні в деякому радіусі.

І Гра{} не буде постійно перевіряти, чи не хоче якийсь моб вдарити персонажа, ага?

Чому? Головний ігровий цикл — опитати всіх учасників, провести обчислення, відповісти, повторити.

9

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

quez написав:

Тому Моб{} має мати доступ до списку клієнтів.

А також до списку інших мобів і взагалі до всього світу, принаймні в деякому радіусі.

І Гра{} не буде постійно перевіряти, чи не хоче якийсь моб вдарити персонажа, ага?

Чому? Головний ігровий цикл — опитати всіх учасників, провести обчислення, відповісти, повторити.

То у Моба{} має бути якесь поле типу bool і поле типу id, а Гра{} має опитувати кожного з Мобів{} і перевіряти, чи bool==true, і якщо тру, то відправляти клієнту з таким-то id дані, що типу моб вас вдарив?

10

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

Типу того, але мабуть краще не два поля, а функцію, яка дає ід того, кого стукнули.

11

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

quez написав:

Типу того, але мабуть краще не два поля, а функцію, яка дає ід того, кого стукнули.

Чуєте. Дивіться. З чого взагалі складається атака мобу? Нехай, персонаж проходить біля моба. Якщо він проходить дуже близько, то моб має побігти за цим персонажем аби вдарити його. При цьому атака зкладається з підготовки, та самої атаки. Наприклад, якщо цей моб, це людина або гуманоїд, то спочатку він має замахнутись рукою чи ногою, потім вдарити, і в момент удару персонаж має отримати пошкодження. Як це все влаштувати?
Я поки що думаю так:
На клієнті персонаж має навколо себе деяку сферу. Якщо в цю сферу потрапляє моб, то на сервер передається id персонажу та id мобу. Після цього ми звертаємося до Моба{} з цим id та встановлюємо поле атаки в true, а полю зid персонажа, котрого має вдарити моб, присвоюємо id персонажу. Після цього Гра{} проходить циклом по всім Мобам{}, бачить, що ось цей моб має вдарити цього персонажа. А що далі? Як ви розумієте, моб має підбігти до персонажа, замахнутись, та після цього вже має розрахуватись пошкодження, котре має отримати персонаж. Як це все правильно реалізувати?

12

Re: Яким чином краще зпроектувати контроллер мобів на сервері?

На сервері мають бути об'єкти: карта світу, персонажі, моби, нпс. З певною періодичністю, скажімо раз в 10 мс, сервер має перевіряти усі ці об'єкти, та змінювати їх стан. Приміром, якщо персонаж, завдяки командам з клієнта, наблизився до моба, то моб переходить у стан "помітив ворога" і "біжу в точку х,у", яка знаходиться в напрямку персонажа. Після того, як усі взаємодії прораховано, сервер надсилає клієнтові інформацію про зміни об'єктів у його радіусі видимості, а кліент починає малювати моба, що біжить до персонажа. За кілька таких ітерацій моб добіжить до персонажа, та почнеться бій.
Статті на тему: http://habrahabr.ru/company/mailru/blog/220359/ http://habrahabr.ru/company/mailru/blog/191378/

Подякували: FakiNyan1