сетевой 2д шутр.
 

короч я начал делать сетевой 2д шутр незадолго до новогодних праздников.всё нормально.большая часть уже сделана, но у меня возник вопрос, какой из двух эффектов лучше.поэтому я сделал по три скрина каждого, закатал в архив и выложил сдесь.те, которые называются 1b,2b,3b. это с blur'ом, три других это с моим гораздо более примитивным эффектом.

http://narod.ru/disk/4720570000/%D1%...D1%8B.rar.html

ну, и раз я создал тему, то буду отписываться о процессе и выкладывать демки (если таковые будут) и скриншоты.

Re: сетевой 2д шутр.
 

однозначно b

Ответ: сетевой 2д шутр.
 

Мне тоже с блюром понравилось больше :)

Ответ: сетевой 2д шутр.
 

Да, с блюром было бы лучше.

З.Ы. Не рекомендовал бы юзать Блитзевское 2Д ввиду его черепашьей скорости. Но это дело каждого.

Ответ: сетевой 2д шутр.
 

ABTOMAT, я с тобой абсолютно согласен, но мне не хотелась юзать бмакс.

Народ, у меня ещё такой вопрос.для сетевой части я использую UDP протокол.меня устраивает, но хотелось бы узнать, какие могут быть подводные камни при его использовании?

Ответ: сетевой 2д шутр.
 

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

Ответ: сетевой 2д шутр.
 

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

Ответ: сетевой 2д шутр.
 

Ответ: сетевой 2д шутр.
 

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

и ещё такой вопрос, имеет ли смысл делать стрельбу отдельным TCP потоком?это будет проще для меня, да и повысит надёжность передачи столь важной инфы, как попадание, а трафа лишнего съедать должно немного.

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

Ответ: сетевой 2д шутр.
 

Проще заюзать подтверждение получения пакета на стрельбу (и др. важные вещи, например появление нового игрока и тд)
Работает в сотни раз быстрее, чем ТСР (проверено)

Ответ: сетевой 2д шутр.
 

Slepetc, я вижу, дело нормально идёт :) Ждём ещё новостей
tormoz, спасибо, я тоже возьму на заметку.

Ответ: сетевой 2д шутр.
 

Я вот тоже использую эти исходники (хотели с Slepetc сдеать игру вместе, но из-за разных взглядов разошлись). Раз блур наравится, не буду убирать (там он с осветлителем соединен, поэтому не смог убрать только блур). Я программист не очень, я дизайнер больше. Как бы, все что на скринах нарисовал я.
Вопрос: При создании сетевого шутера использовать udp без проверки пакетов, по системе per2per нормально? Так как бы инфы: место по x,y поворот по одной оси и стреляю или нет. (Единственное, у кого обсчет повреждений проводить не знаю. У того, кто стреляет или страдает? Или както синхронизироватся, но кто тогда эталон?) Максимум, еще 1 байт на тип пакета. Вот и все. Вместо проверки доставки, лучше колличество пакетов для 1 секунды увеличить. Так движение более плавным будет, а пропадение даж 15% пакетов-маловероятно (или я не прав?). Всеровно критичная инфа только при входе, и передаватся будет по http протоколу. Если и во время игры, то с подтверждением отправить. Всеравно такой инфы мало будет. Так и нагрузка на все небольшая и стабильно все(это я к теме о пер-ту-пер). Только хакнуть так игру легко, ибо весь обсчет у игрока. Если сервер-клиент использовать, то и инфы больше отправлять и принимать и считать больше одному человеку. Зато защита лучше.

Ответ: сетевой 2д шутр.
 

ага. рисунки, за которые мне стыдно рисовал ты, а код нагло украл у меня.

Ответ: сетевой 2д шутр.
 

Abiron
Я за сервер-клиентную архитектуру.
Ну... Всякое может произойти. Лушче уж проверять. А насчёт плавности движения - можно и нужно использовать иные способы. Например, если нет пакета от клиента, который летел до этого по прямой, то и продолжать заставлять его идти по прямой. Короче как-то предсказывать действия игрока если от него пакеты идут очень долго. Так во многих играх делают кстати. Наример, в том же Q3 бывает бежал, лаганёт- и ты оказываешься впереди как если бы бежал это время. Но если лаг уж совсем сильный - можно игрока и останавливать (как например в CS - тогда сразу видно, кто лагает)

З.Ы. О последнем посте. Давайте задушим флейм в самом зародыше.

Ответ: сетевой 2д шутр.
 

+ TCP как протокол более высокого уровня обладет рядом ненужных в данном случае функций - в частноси: накопление пакетов и склейка их дейтограмм в более большие.