Форумы:
Правила Форума

Поиск:

Фан проект игры sky2fly (Обсуждение закрыто)

20.03.13 19:55

#261

Пределалсъ немного

Сообщение отредактировано: 20.03.13 19:56

20.03.13 19:56

#262

норм

20.03.13 20:50

#263

20.03.13 20:57

#264

фак всё переделывать((

20.03.13 21:29

#265

ПОчему? =)

20.03.13 21:49

#266

В некоторых местах есть смазонсть и не чёткость

21.03.13 21:03

#267

Ну как кто так)

21.03.13 21:36

#268

Это уже в игре? Давай текстуры баркаса, и неба...

22.03.13 00:42

#269

Что ещё прикажешь?, прикинь я знаю ЯП C#, CC+ ,3d max, photoshop, ZBrush, Coat 3D, Deep paint, InDesign, и наверное я знаю на каком этапе мне надо будет рисовать текстуру ок? прошу не говори очевидные вещи!

22.03.13 12:28

#270

Ребят я на выходных еду в гости и не смогу работать над проектом 2 дня

22.03.13 15:11

#271

Жаль,а проект будет оффлайн и онлайн???

22.03.13 20:40

#272

оффлайн

22.03.13 20:42

#273

Спасибо за ответ ему)

22.03.13 21:00

#274

а ты мобов в игру добавил? ну этого

Цитата 19.10.12 17:50 #50
vitalik1994 [15]

гдето через месец вы все сможете по гамать против другдруг на карте по 26 чел

04.12.12 11:05 #58
vitalik1994 [15]

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

Жаль что не будет................ Может всё еще раз посмотриш и провериш?

22.03.13 21:09

#275

А ты можеш сделать игру на двох?
Игра для двух игроков

Рассмотрим простейший случай: игру для двоих игроков. Один компьютер будет "ведомым", другой "ведущим". Ведущий компьютер обсчитывает игровое пространство, управляет движением монстров (если они есть), обрабатывает столкновения и т.д. Для синхронизации игровых миров все события игрового пространства (перемещение объектов, взрывы мин, полеты торпед) передаются ведомому компьютеру, который отображает их на экране и отмечает на своей карте, при этом неявно предполагается, что обе карты (ведомого и ведущего компьютеров) полностью идентичны. Если же в игровом пространстве присутствуют случайные элементы (например, аптечки, расставленные в разных местах) они должны быть переданы ведомому компьютеру. Это достаточно сделать всего один раз - перед началом игры. При желании можно даже передать всю карту целиком (нужно учитывать, что ведущий компьютер может использовать дополнительные или "самопальные" миссии, которых нет у ведомого). Ведомый компьютер, в свою очередь, управляет локальным игроком, отслеживая нажатия клавиш, и отправляет эту информацию ведущему.
Три и более игроков

Играть вдвоем довольно скучно и в какой-то момент возникает желание взять третьего. А где трое, там и пятеро. Какие проблемы ждут нас на этом пути? Ведущий компьютер может обслуживать множество ведомых игроков, количество которых (в теории) ограничивается пропускной способностью канала и мощностью процессора. Найти мощный процессор - не проблема, а с учетом того, что мы передаем не сами перемещения, а изменения направления с лихвой хватит и хлипкого модемного канала. Камень преткновения в другом: задумаемся, что произойдет, если ведущий компьютер внезапно отвалится? (Разорвется соединения или его владелец просто устанет и отправится спать). В ситуации с двумя игроками никакой проблемы не возникает. Если один из игроков "исчезает", другой автоматически переходит в режим одиночной игры, но вот с тремя игроками такая стратегия уже не срабатывает. Получается, что один отдувается за всех! А оно ему надо?

Кто-то наверняка предложит установить выделенный сервер, только для трех-пяти игроков это будет слишком расточительным решением. Хорошо, поступим так: пусть все игроки устанавливают соединение не только с ведущим компьютером, но также и друг с другом, по очереди становясь то ведомыми, то ведущими. Тогда, если ведущий компьютер исчезнет, он просто-напросто будет выброшен из очереди и ничего катастрофического не произойдет!

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

Самоорганизующиеся системы с большим количеством игроков

Описанная выше схема страдает двумя серьезными недостатками. При большом количестве игроков объем трафика увеличивается настолько, что ни в какие каналы он уже не вмещается и все начинает дико тормозить, особенно в тот момент, когда игроки сойдутся в смертельном поединке. Правило "семеро одного не ждут" тут не срабатывает и динамика игры определяется самым медленным компьютером в сети - все остальные терпеливо ждут, пока придет подтверждение. Приходится усложнять протокол и запрашивать подтверждения только у того, "против кого мы дружим". Допустим, игрок А пускает в игрока Б торпеду, а игрок С за этим внимательно наблюдает - интересно же. Так вот, чтобы не допустить рассинхронизации компьютеры А и Б вынуждены обмениваться подтверждениями, а компьютер С может и отдохнуть.

Проблема большого количества соединений снимается путем создания своеобразного "поезда". Вместо того, чтобы рассылать данные всем узам, компьютер А посылает их компьютеру B, тот посылает их (вместе со своими перемещениями) компьютеру С и т.д. Естественно, чтобы восстановить цепочку в случае "падения" одного из узлов, компьютер А должен знать адреса компьютера С и D, чтобы при необходимости установить с ними соединение. На самом деле, структура сети не обязательно должна быть линейной (это самый худший вариант). Вот типичный случай из жизни: компьютеры А и C находятся в локальной сети, а компьютер B - где-то далеко в Интернете. За каким чертом мы будем гонять трафик через B, когда логичнее соединить компьютеры так: B -> A -> C. И это действительно можно сделать!
Протокол TCP/IP

Протокол TCP/IP обеспечивает обмен сообщениями между компьютерами с гарантированной доставкой данных. Он также делает такие приятные вещи, как упорядочивание пакетов. Главное преимущество TCP/IP в том, что он делает за вас большую часть работы, гарантируя доставку сообщений. Что означает гарантия доставки информации? Это значит, что если система сообщает вам о том, что отправила сообщение другому компьютеру, вы можете быть уверены, что данные действительно отправлены. Я знаю, что данная особенность кажется очевидной, но в мире сетевого программирования это не так.

Основной недостаток протокола TCP/IP — медленная передача данных. Это вызвано гарантируемой доставкой данных. Чтобы гарантировать доставку, система должна отправить информацию, получить ответ и проконтроллировать правильность передачи. Это отнимает драгоценное время и на сегодняшнем оборудовании задержки часто оказываются недопустимыми для игр.

Разработка сетевых игр - это захватывающее занятие, а сам игровой процесс отрывает хвост с головой, ведь это не с тупым компьютером сражаться, который только и умеет, что посылать монстров по прямой, тут сталкивается живой интеллект реальных игроков, от которых можно ожидать любых хитростей и тактических маневров! Естественно, в процессе написания игру необходимо тестировать, то есть, попросту говоря, играть. По сети. Ага! Какое там программирование!

Вот тут некоторые спорят - обязательно ли закладывать сетевые возможности на самой ранней стадии разработке программы или их можно добавить позднее? Однозначного ответа никто не дает. С одной стороны, в правильно спроектированной программе мультиплеер можно добавить когда угодно с минимальными переделками кода, однако - где вы видели правильно спроектированные программы? Поэтому, чем раньше вы возьметесь за поддержку сети - тем лучше.
Сообщение отредактировано: 22.03.13 21:11

22.03.13 21:15

#276

Если хочешь знать сама игра и есть локальный сервер и клиент они просто совмещены!

22.03.13 21:53

#277