Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Что надо со стороны сервера.

Читайте также:
  1. А с другой стороны?
  2. БЫЛО ЛИ ЭТИЧЕСКИ ОТВЕТСТВЕННЫМ СО СТОРОНЫ АВРААМА СКРЫВАТЬ СВОЙ ЗАМЫСЕЛ ОТ САРРЫ, ЕЛИЗАРА И ИСААКА?
  3. Возможности и направления содействия маркетингу ОУ со стороны федеральных, региональных органов управления и общественных организаций
  4. Возможные альтернативы собственного производства или поставок со стороны
  5. Готовность видеть в других их лучшие стороны
  6. Две стороны требовательности
  7. И соедини пять покрывал особо и шесть покрывал особо; шестое покрывало сделай двойное с передней стороны скинии.

Основа - должно быть организовано что-то типа одно-двусвязанного списока ака list, динамический массив, возможно какая либо стековая система. Не суть важно. Что быстрее работает (хотя тогда конечно без динамического массива… гыгыгы… перераспределение памяти это…. gbpltw). Хотя и индексирование необходимо… блин. Лан не знаю что есть в джаве родного, но суть я думаю понятна.

 

Схема данных связанного списка выглядит так:

  1. Первое поле - поле состояние (State) – int/int8
  2. Имя игрока (ник) – string/String16(длина ника)
  3. Float X для интерполяции
  4. Float Y для интерполяции
  5. Float Z для интерполяции
  6. Float X для экстраполяции
  7. Float Y для экстраполяции
  8. Float Z для экстраполяции

 

Так же (SIC!) в процессе обмена данными необходима трансляция индекса записи. А так же реализация серверной операции удаления строки списка по индексу (вот и гвоздь в гроб стэка L).

 

 

Взаимодействие игрока с сервером подразумевает два состояния со стороны клиента:

1. Подключение к серверу

2. Взаимодействие с сервером

 

Подключение к серверу.

При подключении к серверу сервер должен посылать ник игрока, его координаты и состояние (State = 0) и так далее….

Но на самом деле, сейчас:

· Игрок подключается к серверу и говорит свой ник для серверного связанного списка.

· Сервер добавляет все данные игрока в новую строку связанного списка (координаты появления в тест-локации дам позже – зависит от локации, которую нарисует Флойд. В последствии будет зависеть предыдущей локации/местонахождения/состояния игрока и прочего).

· Сервер транслирует обратно игроку всю свою новую строчку списка – строчку этого же игрока (+ index в этом списке) с флагом состояния ноль (State=0).

· Cервер начинает трансляцию игроку всего своего списка – всех игроков (+ index в этом списке) с флагом состояния один (State=1) для каждой записи за исключением самого игрока.

· Сервер рассылает данные новой строки (+ index в серверном списке) из своего списка всем остальным игрокам с флагом состояния один (State 1)

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

На много хуже, если побежал 200-й игрок(сервер послал данные), а на клиента он с State=1 не был еще передан, и его просто не существует на сцене. Ошибка и вылет. Сам я собирался это реализовывать через «личный» стек(команд отправки) игрока. На каждого игрока по стеку. (А вообще разные велосипеды обдумывал.)

 

 


Дата добавления: 2015-08-09; просмотров: 69 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Отступление/пояснение.| Законы проведения возбуждения по нервным волокнам

mybiblioteka.su - 2015-2024 год. (0.007 сек.)