www.mudconnector.su

Национальный мадконнектор.
Текущее время: Вт сен 28, 2021 11:40 pm

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Ср дек 03, 2014 11:48 pm 
Не в сети

Зарегистрирован: Пн май 27, 2013 4:34 pm
Сообщений: 105
Kadvar писал(а):
Потому, что производительность... потом "делайте что хотите".
Обратите внимание, авторы апача пишут в текстовые файлы. Есть chainsaw итд итп.
Есть много готовых проверенных решений.

Даже не знаю, что ответить. Уверен что производительности хватит. Учитывая что в базу будут только писать,
и изредка читать. Я буду пробовать все таки с базой. Если не взлетит сделаю в файл.
А пример с апачем неудачен - так как там ограниченное количество событий требуется логировать. Для их случая
достаточно и файлов и не требуется по ним собирать статистику.

KadVar писал(а):
Путь к трудноуловимым и очень фатальным багам.
Возможностей должно быть ровно столько, сколько нужно. Не более.

У билдера и будет ровно столько сколько можно ему делать. Просто я хотел сказать что скрипт
дает на много больше возможностей для описания данных, чем обычные данные в xml например.

KadVar писал(а):
Вы я вижу тоже. Вопрос всё тот-же, что конкретно будет исполняться параллельно ?
Неужели "всё" ?


Конечно же не все. Тут нужно будет подумать, поэкспериментировать. В отдельных потоках отдельные зоны например делать,
отдельным потоком бой, отдельно - ии мобов не в бою, магазины (изменение ассортимента например) и т. д.
Бой не имеет смысла делать в параллельных потоках - больше проблем будет. Но для боя свой
отдельный поток стоит сделать - лагов меньше. Тут нужно все расписывать что и как будет работать - что параллельно, а что нет.
Это будет видно уже в процессе разработки.

KadVar писал(а):
Можно кусочек кода написать ? Пример ?
Я честно говоря не очень понимаю как вы собрались конкретно работать.
И второй сразу кусочек, не с поднятием меча, а скажем со стрельбой из лука, один стреляет из лука,
у него должен быть лук и стрела, второй "кастует файрболл" и если он успеет первым может повредится
лук, а может стрела, а если вторым - только лук (стрела уже "ушла".


поток 1
arrow = get_arrow()
bow = get_bow()
target = find_target()
bow.shoot(arrow, target)

поток 2
target = find_target()
cast_spell('fireball', target)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Чт дек 04, 2014 4:07 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1415
ArtistSpb писал(а):
Kadvar писал(а):
Потому, что производительность... потом "делайте что хотите".
Обратите внимание, авторы апача пишут в текстовые файлы. Есть chainsaw итд итп.
Есть много готовых проверенных решений.

Даже не знаю, что ответить. Уверен что производительности хватит. Учитывая что в базу будут только писать,
и изредка читать. Я буду пробовать все таки с базой. Если не взлетит сделаю в файл.
А пример с апачем неудачен - так как там ограниченное количество событий требуется логировать. Для их случая
достаточно и файлов и не требуется по ним собирать статистику.

Вы эээ... "в себе" ?
Это в апаче не требуется статистику собирать и анализировать :))) ????
Вы можете закрывать глаза на чужие продуманные решения и вводить DB ради DB,
дело ваше, лично я не вижу никакого смысла логировать непосредственно в базу.
От этого КУЧА проблем может быть различных, а толку абсолютно никакого.
Если вы хотите анализировать логи, то для этого есть готовые инструменты,
не подойдут - надо будет свой написать...


ArtistSpb писал(а):
KadVar писал(а):
Вы я вижу тоже. Вопрос всё тот-же, что конкретно будет исполняться параллельно ?
Неужели "всё" ?


Конечно же не все. Тут нужно будет подумать, поэкспериментировать. В отдельных потоках отдельные зоны например делать,
отдельным потоком бой, отдельно - ии мобов не в бою, магазины (изменение ассортимента например) и т. д.
Бой не имеет смысла делать в параллельных потоках - больше проблем будет. Но для боя свой
отдельный поток стоит сделать - лагов меньше. Тут нужно все расписывать что и как будет работать - что параллельно, а что нет.
Это будет видно уже в процессе разработки.

Это ключевой вопрос. Без ответа на него всё остальное "абстрактное умствование".

ArtistSpb писал(а):
KadVar писал(а):
Можно кусочек кода написать ? Пример ?
Я честно говоря не очень понимаю как вы собрались конкретно работать.
И второй сразу кусочек, не с поднятием меча, а скажем со стрельбой из лука, один стреляет из лука,
у него должен быть лук и стрела, второй "кастует файрболл" и если он успеет первым может повредится
лук, а может стрела, а если вторым - только лук (стрела уже "ушла".


поток 1
arrow = get_arrow()
bow = get_bow()
target = find_target()
bow.shoot(arrow, target)

поток 2
target = find_target()
cast_spell('fireball', target)

[/quote]
Что будет если cast_spell исполнится после get_arrow ?
Оно "упадет" ?
Я не увидел ни одной проверки в вашем коде, вообще ни одной...
Если в arrow возвращается null, то что произойдет в bow.shoot ?
Конкретизировать код на предмет проверок можно ?
Если вы ничего нигде не проверяете, то бесспорно синхронизация
вам не нужна... но работать... не будет...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Пт дек 05, 2014 7:23 pm 
Не в сети

Зарегистрирован: Пн авг 17, 2009 9:35 am
Сообщений: 26
KadVar писал(а):
ArtistSpb писал(а):

поток 1
arrow = get_arrow()
bow = get_bow()
target = find_target()
bow.shoot(arrow, target)

поток 2
target = find_target()
cast_spell('fireball', target)


Что будет если cast_spell исполнится после get_arrow ?
Оно "упадет" ?
Я не увидел ни одной проверки в вашем коде, вообще ни одной...
Если в arrow возвращается null, то что произойдет в bow.shoot ?
Конкретизировать код на предмет проверок можно ?
Если вы ничего нигде не проверяете, то бесспорно синхронизация
вам не нужна... но работать... не будет...


Я мало что знаю об организации многопоточных (а тем более - многопроцессных) приложений, однако замечу, что по логике вещей такая ситуация, как в этом псевдокоде, просто не должна возникать. В отдельную обработку выделяется все, происходящее в какой-то области. Области между собой взаимодействуют только способами, заведомо исключающими возможность конфликта.
Например, отдельно выделяется обработка всего, что происходит в одной зону с игроками. Между собой игроки в разных зонах могут взаимодействовать, скажем, только в плане чата и торговли на игровом аукционе, транзакации в которых, по идее, таких коллизий вызвать не могут.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Пн дек 08, 2014 12:04 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1415
У вас правильные мысли. Именно поэтому я спрашивал уже неоднократно где, как и зачем будет
что-то "многопоточно". При схеме 1 зона - 1 поток подобные коллизии возникать действительно не будут.
Но сам пример был нужен, чтобы человек понял, в чём конкретно проблема с синхронизацией, и что БД
ему поможет не очень-то.
Он пока не понял (судя по примеру без каких-либо условий-ветвлений".

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Чт дек 11, 2014 3:13 pm 
Не в сети

Зарегистрирован: Пн авг 17, 2009 9:35 am
Сообщений: 26
KadVar писал(а):
Именно поэтому я спрашивал уже неоднократно где, как и зачем будет
что-то "многопоточно".


Так я сразу написал, что и где. В отдельные процессы/потоки выделяются вещи, которые чисто логическим можно разделить, не порождая коллизий. Служебные сервисы, вроде сервера логина, манипуляций с перераспределением статов или параметров аккаунта (которые проводятся без залогинивания в конкретного персонажа), обработки чат-каналов со всеми их игнорами и т.п. Что касается именно игры, то процесс/поток выделяется для инстансов, которые просто по определению отделены от остального мира и не взаимодействуют с ним.
Также можно выделить обработку зон, в которых нет игроков, всякие служебные телодвижения. Они должны иметь меньший приоритет, чем непосредственно игровой процесс. Насчет выделения таким образом простых зон - не думаю, что в этом есть смысл. Сколько ни думал над балансом мадов, каждый раз приходил к выводу, что без инстансов и выделения в качестве оных всех более-менее серьезных зон, никакого баланса не получится. Ход рассуждений могу изложить в отдельной теме.
Что касается магии перемещений, вроде того же суммона, то тут, видимо, надо продумывать логику заранее. Вот у нас объект "персонаж" находится в зоне А и обрабатывается ее процессом, вот событие "удачный суммон в зону Б", посылает сигнал процессу А, тот корректно завершает обработку, и передает персонажа процессу зоны Б. Как-то так. Прочие же взаимодействия такого плана, при введении оных, должны проходить проверку на потенциальную возможность создания коллизий, скорей всего еще на этапе обдумывания, а стоит ли это делать, и как именно, если стоит. Это уже у имплементора конкретного мада голова должна болеть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Чт дек 11, 2014 3:56 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1415
Sventovit писал(а):
Служебные сервисы, вроде сервера логина, манипуляций с перераспределением статов или параметров аккаунта (которые проводятся без залогинивания в конкретного персонажа), обработки чат-каналов со всеми их игнорами и т.п.

А какой в этом глубинный смысл ?
Что хорошего в этой области вы получите от многопоточности ?
Эти части редко требуют много ресурсов, зачем их выделять отдельно ?

Sventovit писал(а):
Что касается магии перемещений, вроде того же суммона, то тут, видимо, надо продумывать логику заранее. Вот у нас объект "персонаж" находится в зоне А и обрабатывается ее процессом, вот событие "удачный суммон в зону Б", посылает сигнал процессу А, тот корректно завершает обработку, и передает персонажа процессу зоны Б. Как-то так. Прочие же взаимодействия такого плана, при введении оных, должны проходить проверку на потенциальную возможность создания коллизий, скорей всего еще на этапе обдумывания, а стоит ли это делать, и как именно, если стоит. Это уже у имплементора конкретного мада голова должна болеть.


Вы правильно всё пишете, но очень обще.
Проблемы с многопоточностью ВСЕГДА в частностях.
Частного случая того, как вы будете это разруливать я так и не получил.
Мне в общем-то и не надо, я лишь хотел акцентировать внимание на том, что это немаловажная
часть механизма, при "забивании" на которую неизбежны крайне неприятные проблемы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Чт дек 11, 2014 5:04 pm 
Не в сети

Зарегистрирован: Пт сен 04, 2009 10:17 pm
Сообщений: 214
KadVar писал(а):
Эти части редко требуют много ресурсов, зачем их выделять отдельно ?


А, есть внутриигровая статистика по тому, сколько занимают памяти и на сколько процентов загружают процессор по отдельности: мобы/объекты/игроки/триггеры? Или может кто встречал такие данные в сети?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Чт дек 11, 2014 5:13 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1415
Pacifist писал(а):
KadVar писал(а):
Эти части редко требуют много ресурсов, зачем их выделять отдельно ?


А, есть внутриигровая статистика по тому, сколько занимают памяти и на сколько процентов загружают процессор по отдельности: мобы/объекты/игроки/триггеры? Или может кто встречал такие данные в сети?


Какое их количество ?
С онлайном >100 человек циркуль работал и на p2 по-моему... не помню уж сколько было памяти.
В текстовом виде всё вместе - десятки мегабайт...
Не то экономите.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Чт дек 11, 2014 10:00 pm 
Не в сети

Зарегистрирован: Пт сен 04, 2009 10:17 pm
Сообщений: 214
KadVar писал(а):
Pacifist писал(а):
KadVar писал(а):
Эти части редко требуют много ресурсов, зачем их выделять отдельно ?


А, есть внутриигровая статистика по тому, сколько занимают памяти и на сколько процентов загружают процессор по отдельности: мобы/объекты/игроки/триггеры? Или может кто встречал такие данные в сети?


Какое их количество ?
С онлайном >100 человек циркуль работал и на p2 по-моему... не помню уж сколько было памяти.
В текстовом виде всё вместе - десятки мегабайт...
Не то экономите.


Я имел ввиду какую процентную нагрузку на движок дают те или иные компоненты игры. Например, игроки съедают 60% памяти, мобы 30%, объекты 10% и т.д.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Пт дек 12, 2014 1:52 am 
Не в сети

Зарегистрирован: Пн май 27, 2013 4:34 pm
Сообщений: 105
KadVar писал(а):
Вы эээ... "в себе" ?
Это в апаче не требуется статистику собирать и анализировать :))) ????
Вы можете закрывать глаза на чужие продуманные решения и вводить DB ради DB,
дело ваше, лично я не вижу никакого смысла логировать непосредственно в базу.
От этого КУЧА проблем может быть различных, а толку абсолютно никакого.
Если вы хотите анализировать логи, то для этого есть готовые инструменты,
не подойдут - надо будет свой написать...


И какого рода статистику в работе апача вы собираете ?
И про какие такие продуманные решения вы говорите ?
DB для статистики - это уже готовое решение, для которого не нужно ничего больше писать
и это не менее популярное решение, чем файл. Парсер/анализатор в наличии бери и пользуйся.

Sventovit писал(а):
Что будет если cast_spell исполнится после get_arrow ?
Оно "упадет" ?
Я не увидел ни одной проверки в вашем коде, вообще ни одной...
Если в arrow возвращается null, то что произойдет в bow.shoot ?
Конкретизировать код на предмет проверок можно ?


Код синхронизации находится на уровне доступа к тому или иному объекту.
Если в одном потоке с объектом в этот момент идет работа, то другой поток в этот момент приостанавливается (если ему нужен
тот же самый объект), пока первый не освободит его. И если это сделать, то все будет работать как надо и ничего падать не будет.
Вопрос в другом, насколько реализуемо это решение. Тут нужно разбираться.

KadVar писал(а):
Именно поэтому я спрашивал уже неоднократно где, как и зачем будет
что-то "многопоточно".


Многопоточность требуется из-за условия - билдеры пишут скрипты зон. Для изоляции скриптов друг от друга,
чтобы одни скрипты не влияли на другие скрипты. Если нет многопоточности, то достаточно одного плохого скрипта,
который повесит весь сервер. Такой подход позволит отсеивать плохие скрипты в полуавтоматическом/автоматическом режиме.
А синхронизация нужна, так как скрипты в разных потоках могут работать с одними и теми же объектами мира.
Несомненно, тут нужно думать сколько нужно потоков и что они будут делать.

KadVar писал(а):
Я имел ввиду какую процентную нагрузку на движок дают те или иные компоненты игры. Например, игроки съедают 60% памяти, мобы 30%, объекты 10% и т.д.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron