1

Тема: Порадьте архітектуру ще одну.

Хаі. Значить з сервером все зрозуміло. А от дивіться які справи на клієнті. Так, як я використовую рушій, в нього свої методи для реалізації різних ігрових штук, наприклад, відмальовка GUI. Також на клєінті багацько різних скриптів. Наприклад, один скрипт відмальовує кнопку, і по натисканню на цю кнопку щось робиться, це все написано в одному скрипті. Інший скрипт може відповідати за щось інше, наприклад, він відкриває двері, коли персонаж підходить до них. Таких подій може бути ціла купа, і при виконанні кожної з них, або не кожної, мені треба відправити відповідні дані на сервер. І зрозуміло, що писати в кожному такому скрипті код методів, потрібних для відправки та прийняття повідомлення - дуже не розумно.
Якщо подивитись на це все діло зверху, то ми ясно побачимо, що самим легшим рішенням є - виділення коду, потрібного для спілкування з сервером, в окремий файл, а потім звертатись до нього з інших скриптів, таке собі централізоване управління. Ну, зі звертанням скриптім до того "клієнт-серверного" скрипта все ясно, можна просто зробити необхідний класс статичним, та легко звертатись до його методів із інших скриптів, але як бути зі зворотнім зв'язком? Наприклад, є скрипт, котрий містить два методі, перший метод відслідковує позицію персонажа, так якщо персонаж підходить до дверей, вони мають відчинитись, також ці двері мають відчинитись для всіх гравців, що знаходяться в тій локації, для цього ми звертаємось до "клієнт-серверного" класу, та за допомогою його метода відправляємо необхідні дані, але як інших клієнтів сповістити про подію відчинення дверей? Робити публичні змінні, котрі будуть містити посилання на всі скрипти, та залежно від повідомлення звертатись до необхідних скриптів? так це ж якось дуже важко та затратно, тоді прийдеться кожного разу, при створенні чергового функціоналу, додавати в "клієнт-серверний" скрипт змінну з посиланням, та дописувати новий блок в конструкцію switch, чи щось типу того. Кароч, як мона це все діло організувати з розумом, щоб було логічно, та легко піддавалось розширенню?

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

2

Re: Порадьте архітектуру ще одну.

Чому б не використати тип Dictionary<TKey, TValue> ?

3

Re: Порадьте архітектуру ще одну.

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

4

Re: Порадьте архітектуру ще одну.

koala написав:

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

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

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

5

Re: Порадьте архітектуру ще одну.

Oicumena написав:

Чому б не використати тип Dictionary<TKey, TValue> ?

тобто в повідомленні від сервера вказувати, якому скрипту та методу це повідомлення прийшло, а в дікшіонарі зберігати посилання на відповідні класси(скрипти), чи шо?

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

6

Re: Порадьте архітектуру ще одну.

Тоді успадковуйте персонажів і двері від спільного предка - наприклад, ActiveMapObject чи якось так - в якого і буде відповідний метод (оголосити свій стан іншим).

7

Re: Порадьте архітектуру ще одну.

koala написав:

Тоді успадковуйте персонажів і двері від спільного предка - наприклад, ActiveMapObject чи якось так - в якого і буде відповідний метод (оголосити свій стан іншим).

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

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

8

Re: Порадьте архітектуру ще одну.

Уявіть собі - у об'єктів на сервері і в клієнтах є дуже багато чого спільного. І можуть бути спільні (звісно, на рівні бібліотеки) методи.

9

Re: Порадьте архітектуру ще одну.

Ми це вже, здається, обговорювали...

10

Re: Порадьте архітектуру ще одну.

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

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

11

Re: Порадьте архітектуру ще одну.

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

12

Re: Порадьте архітектуру ще одну.

Oicumena написав:

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

то рушій, unity3D

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

13

Re: Порадьте архітектуру ще одну.

Я вже не бачу можливостей, як без коду вам пояснити. Давайте свого персонажа.

14

Re: Порадьте архітектуру ще одну.

Вже не треба, я вже допер. Сарітє суда. Існує скрипт А, котрий має метод, котрий викликається по натисканні кнопки, та метод, котрий виводить якесь повідомлення. Існує сервер-скрипт, котрий реалізовує взаємодію з сервером. По натисканню кнопки, метод скрипта А звертається до методу сервер-скрипта, передає йому дані, котрі складаються з классу LoginCommand, ключа та посилання на метод, котрий виводить повідомлення. А метод сервер-скрипта спочатку запихує ключ та посилання в Dictionary, потім відправляє клас LoginCommand на сервер, на сервері виконується метод  Execute класу LoginCommand, котрий повертає клас LoginResult, котрий відправляється назад клієнту разом з ключем. Коли ця штука приходить до клієнта, то я витягую з Dictionary необхідне посилання на метод використовуючи ключ, та викликаю той метод передаючи йому отримані дані. От, як вам таке? Алгоритм поки що не ідеальний, звичайно, бо той ключ мона і пихати в класи типу SomeCommand, а ще не зрозуміло, що передавати в метод скрипта А, чи класи типу SomeResult, чи вже в методі сервер-скрипта витягувати потрібні дані з того класу SomeResult і їх передавати в методи, посилання на котрі знаходяться в Dictionary. Ну таке кароч.

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

15

Re: Порадьте архітектуру ще одну.

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

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

16

Re: Порадьте архітектуру ще одну.

Good for you.

17

Re: Порадьте архітектуру ще одну.

koala написав:

Good for you.

чуйте, а як можна вирішити проблему з тим, що деякі методи приймають, а деякі не приймають аргументы? бо той Object[], то ж погано, має ж бути вже якесь адекватне рішення? і я тут подумав, навіщо той масив, можна ж просто передавати класи успадковані від IResult, тепер ніяких масивів не тре, тре тілько вирішити оту проблему, ну з методами без аргументів.

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

18

Re: Порадьте архітектуру ще одну.

на одному форумі дали таку відповідь

static void Test1()
        {
        }
 
        static void Test2(int a)
        {
        }
 
        static void Test3(int a, double b)
        {
            Console.WriteLine("{0} | {1}", a, b);
        }
 
        static void Main(string[] args)
        {
            Dictionary<string, Delegate> dic = new Dictionary<string, Delegate> {
                { "Мгла", new Action(Test1) },
                { "Мзда", new Action<int>(Test2) },
                { "Джигурда", new Action<int, double>(Test3) }
            };
            dic["Джигурда"].DynamicInvoke(1, 23.0);
            Console.ReadLine();
        }

все геніальне - просто.

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

19

Re: Порадьте архітектуру ще одну.

Знаєте що, koala, я відразу ото зрозумів, що паттерн Команда  не підійде, ну от скажіть, як можна давати доступ клієнту до паролів та логінів від бази даних? Я не хочу і не буду створювати на клієнті клас, котрий містить пароль та логін для доступу до БД. Це нерозумно, на мою думку.

All you want is a dingle,
What you envy's a schwang,
A thing through which you can tinkle,
Or play with, or simply let hang...

20

Re: Порадьте архітектуру ще одну.

А нащо з патерном "команда" давати доступ клієнту до паролів і логінів, я не розумію?