Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.

Перейти к содержимому раздела

Blind games - Звуковые игры незрячим

Форум сайта "blind.games". Добро пожаловать.

Архивный режим

Форум переводится в архивный режим. Это значит, что все учетные записи, темы и сообщения остаются на момент 19.07.2018, а добавлять новые уже нельзя. То есть, закрыта регистрация, добавлен запрет на создание новых тем и ответы в существующих.
По всем вопросам, как и ранее, вы можете писать на support (собачка) blind (точка) games.

(Страница 14 из 14)

Страницы Назад 1 12 13 14

Чтобы отправить ответ, вы должны войти или зарегистрироваться

Topic RSS feed

Сообщений с 131 по 135 из 135

131

Re: BGT

Привет всем, а кто-нибудь знает, можно ли делать следующее:
допустим у нас есть 2 класса, класс питомца и класс человека/игрока, он является хозяином питомца, а питомец принадлежит игроку, конечно в объекте класса питомца можно хранить id игрока, а в объекте класса игрока хранить id питомца, но что если сделать это дескрипторами, то-есть в игроке хранить дескриптор, или массив дескрипторов на питомца/питомцев, а в питомце дескриптор на игрока, которому он принадлежит.
Выглядит гораздо удобнее чем получение идентификаторов, и искать потом нужный объект перебором всего массива и поиска совпадающих id-шников, а если у нас в массиве 10000 элементов? Но меня смущает то, что через дескриптор игрока можно получить доступ к дескриптору питомца, а через него можно сослаться на дескриптор игрока, который ссылается на питомца, и так до бесконечности, получается замкнутый круг, и я не знаю будет ли это работать без сбоев, нагрузки на процессор, переполнения памяти и т.д, если кто знает, напишите.

132

Re: BGT

чёрный сталкер пишет:

Привет всем, а кто-нибудь знает, можно ли делать следующее:
допустим у нас есть 2 класса, класс питомца и класс человека/игрока, он является хозяином питомца, а питомец принадлежит игроку,

Привет, я понимаю что игра сетевая, раз есть множество игроков, если так, то объекты (герои и питомцы) должны сохранятся и восстанавливаться? если это так, то тут надо выбирать способы взаимосвязи игроков и питомцев учитывая их сохранение.

чёрный сталкер пишет:

конечно в объекте класса питомца можно хранить id игрока, а в объекте класса игрока хранить id питомца, но что если сделать это дескрипторами, то-есть в игроке хранить дескриптор, или массив дескрипторов на питомца/питомцев, а в питомце дескриптор на игрока, которому он принадлежит.

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

чёрный сталкер пишет:

Выглядит гораздо удобнее чем получение идентификаторов, и искать потом нужный объект перебором всего массива и поиска совпадающих id-шников, а если у нас в массиве 10000 элементов?

Если удобнее дескрипторами, то делайте именно так, но по мне так можно сделать следующим образом:
есть массив игроков, есть массив питомцев, в игроке есть массив айдишников его питомцев, а у питомца есть поле айдишник игрока.
создали объект игрок, массив айдишников на питомцев пуст.
создали питомца добавили его в массив питомцев, взяли номер в массиве, добавили этот номер в массив питомцев в объекте игрок.
а питомцу добавили в поле айдишник игрока номер игрока в массиве.
при сохранении тут тоже надо будет питомцев игрока сохранять отдельно от питомцев другого игрока.
в таком алгоритме циклов по массиву програмировать не надо будет.
например:
пользователь вошёл в сеть, создали игрока, добавили его в конец массива, считываем всех его питомцев, которые хранились отдельно, можно привязать хранение питомцев к имени игрока.
создали всех питомцев, добавляя к ним номер игрока, а номер игрока это последний элемент массива, при добавлении питомцев в массив добавляем их номера в массив игрока
чтобы обратиться к питомцам проходимся циклом по массиву айдишников питомцев, который в игроке, берем из него номера питомцев в общем массиве питомцев, пусть у нас 5 питомцев а всего их 1000, мы будем проходить только по своим, работать будет быстро.
если кто то вышел из сети то его надо удалить из массива игроков, надо удалить и его питомцев из массива питомцев, номера сместятся если мы будем удалять элементы массива, поэтому тут лучше обнулять дескрипторы, то есть элемент массива остался, но там пусто.
следовательно, когда заходит игрок и создаются объекты он сам и его питомцы, то записывать их можно не в конец, а искать пустые ячейки, тут уже циклы будут большие, и может это всё как минимум не красиво, но бывают такие ситуации, когда это необходимо, и подругому никак.
резумируя, если делать айдишниками, то циклы проходят по своим питомцам, ведь массив айдишников своих питомцев невелик.
можно добавлять новые объекты в конец общих для игроков и питомцев массивы, в этом случае большие циклы не понадобятся., но массивы будут расти, на памяти это почти не скажется, пустые дескрипторы на объекты почти ничего не весят
когда объекты удаляем из общих массивов, то не удаляем элементы а обнуляем их, чтобы не было смещения по айдишникам.
можно объекты добавлять не в конец массива а искать пустые элементы, чтобы массив не рос, тут будут длинные циклы, если массив 10000 элементов, то это не плохо, будет работать быстро, ведь циклы добавления будут только при входе игрока, да и для компьютера 10000 это совсем мало
ещё раз повторюсь, бывает такой алгоритм необходим, я несколько задач решал именно так, но в вашем случае можно делать дескрипторами, и наверно это будет лучше

чёрный сталкер пишет:

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

будет работать без сбоев, без переполнения памяти без нагрузки на процессор, ведь по сути у игрока есть адрес в памяти на питомца или на адреса питомцев.
у питомца адрес на игрока.
да они замкнуты, но это значит только то, что они знают друг о друге.
мы можем обращаться к питомцу используя бесконечно дескрипторы игрок питомец игрок питомец и так далее, как бы закольцованность, но в памяти будет всё нормально, в памяти будут 2 объекта, у каждого объекта ссылка друг на друга и не более того.
если же мы используем не дескрипторы а объекты, то это будет именно та ситуация, когда будут бесконечно создаваться объекты друг в друге, вернее вы должны будете такой код написать, мол есть игрок, у него питомец, у питомца создать игрока по нашему подобию, внутри создать питомца по подобию нашего питомца, то есть код будет зациклен.
а может я ошибаюсь и зацикливания не будет, проверю обязательно.
многие програмисты создают мир, в мире создают объекты, в объекты передают дескриптор мира, чтобы объект мог обращаться к миру оценивая его и выполняя какое-то поведение исходя из состояния мира, и это нормально, дескрипторы рулят!
п.с. всё что я написал не претендует на истину, если я в чем-то ошибаюсь то поправьте

Хорошо(+) Плохо(-)

133

Re: BGT

Опишу вкратце, где мне пришлось использовать айдишники.
в сетевой игре есть массив игроков, у меня есть айдишники клиентов, мне надо связать клиента с его героем, можно хэш таблицу сделать, но мне не понравилось, что будет работать медленно, хотя щас я уже сомневаюсь, что это плохой вариант.
также можно, чтобы клиент сам помнил номер своего игрока, ну например, зашёл в сеть, создали героя, добавили в массив, допустим он получил индекс в массиве 8, отправляем клиенту номер 8, мол запомни, там твой игрок.
не понравилось тем, что эту восьмёрку надо туда сюда гонять по сети, ведь чтобы сделать шаг, клиент отправляет что мол я делаю шаг мой индекс 8, но самое страшное, если этот индекс выловить на клиенте недобрыми программами, и поменять её на 9, то можно с клиента рулить другим героем, и будет бардак.
в объекте network_host айдишники клиентов берутся без проблем, то есть я создал массив 10000 элементов типа герой, если у клиента айдишник 1, то я запишу его в массив под индексом 1, если индекс 9 то  аналогично.
чем это хорошо, клиенты получают айдишники по возрастающей, если я был клиентом 1, то пока работает сервер никто больше этот номер не получит, даже если я выйду из сети, правда когда я войду в сеть то получу тоже другой айдишник а не 1.
то есть пересещений айдишников не будет, однако может быть следующее, сервер работает долго и вдруг заходит клиент, которому присваивается номер 10000, это за пределами массива.
я вышел из ситуации так, берём остаток от деления айдишника на длину массива, и получаем всегда номер который будет в пределах массива игроков, ну например я 8 делим на 10000 получаем в остатке 8, а если я 10000 то делим и остаток получаем 0.
да если кто-то будет 10008, то я 8 потому что давно сижу в игре, и ему тоже надо занять индекс 8, тут я просто переподключаю его и он будет уже 10009, в остатке 9, и если и 9 занято то так до бесконечности переподключаем.
кажется что плохо, не эффективно, но это почти не реально получить совпадающие номера, ну даже если совпало, то не реально чтобы совпало ещё с долгоиграющим клиентом, ну если уж будет такое то массив можно увеличить до 100000. вообще не будет никогда совпадать.
остаток от деления это операция которая выполняется намного быстрее чем поиск значения по ключю в словаре, поэтому я использую сложный алгоритм который работает быстрее, а не простой используя словарь, но в работе медленнее.
п.с. внимание, если не знали, у network_host в методе get_peers() при определённой ситуации возвращается массив пиров, но массив не корректный, поэтому лично я реализовал свои методы хранения айдишников подключённых клиентов.

Хорошо(+) Плохо(-)

134

Re: BGT

Я вообще храню в объекте класса игрока id из network, и когда от клиента приходит запрос, например, проверить здоровье, я нахожу его перебором по id из network_event, получаю его индекс в массиве, и по нему получаю здоровье, которое отправляю обратно по этому id.

135 (Sat-10-17 22:19:42 отредактировано fenix)

Re: BGT

чёрный сталкер пишет:

Я вообще храню в объекте класса игрока id из network, и когда от клиента приходит запрос, например, проверить здоровье, я нахожу его перебором по id из network_event, получаю его индекс в массиве, и по нему получаю здоровье, которое отправляю обратно по этому id.

Если в сети 100 игроков, если в секунду 100 запросов, это ещё не предел, то получится 10000 переборов, ну вернее до 10000, находить можно раньше последнего элемента.
У меня поворот по одному градусу, каждый градус уходит на сервер, есть быстрые повороты, за 2 секунды  360 градусов.
В общем я отказался от циклов.
100000 пустых дескрипторов в памяти занимают около 22 мегабайта, сейчас это вообще ничто, я использую 10000, но если уж понадобится увеличу до 100000.
тоже храню peer_id в игроке, это для сравнения точно ли клиент и игрок родственники перед любым действием над игроком.

Хорошо(+) Плохо(-)

Сообщений с 131 по 135 из 135

Страницы Назад 1 12 13 14

Чтобы отправить ответ, вы должны войти или зарегистрироваться



Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.

Сгенерировано за 0.061 секунды (88% PHP — 12% БД) 12 запросов к базе данных