Курилка программистов

[Dennis_Chikin 3 663]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Expropriator 2 119]

 

 

  Malandrinus писал(а):

VOSTOK GAMES

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

[Malandrinus 615]

 

 

  _Призрак_ писал(а):

в Survarium отсутствуют боты в принципе

А не приходит такое соображение, что они там отсутствуют просто потому, что их нормально не сделать или сделать сложно? Ведь делают те же люди, что делали сталкира. Причём делают на постоянной основе, а не по вечерам ковыряются. Казалось бы, уж они то должны были за много лет запилить то, что не удалось в x-ray. И насчёт того, что "делать с нуля". Это серьёзно?! Это же разрабы сталкира почти в полном составе, включая Ясенева, который как раз и отвечал за весь AI (т.е. по сути почти весь xrGame). О работе с нуля здесь даже речи идти не может, всё уже есть. Если до сих пор не сделали, значит на то есть какие-то иные причины.

 

  Цитата

X-Ray уже есть боты (пусть даже в синглплеере) + весь синглплеер сделан по типу напоминающему клиент-серверное приложение

 

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

 

 

  Дизель писал(а):

кто то еще там работает до сих пор? Пилить, заранее мертвый проект,

Не мне судить насчёт "заранее мёртвый", но фирма вроде есть и работает. Вот анонс же свежий.

[SkyLoader 53]

 

 

  Malandrinus писал(а):

.NET ? Мне собственно было интересно, какой вообще фреймворк.

.NET, да. Может быть ты имеешь ввиду, какие компоненты используются? Юзаю Devexpress из последних версий (15.2, кажется). Разрабы метро юзали для своего сдк Devexpress 2008, я решил по-новее взять.

 

 

 

  _Призрак_ писал(а):

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

Это самое меньшее из зол. Вернее самое первое, что требуется сделать. Основная проблема то в синхронизации и большом количестве отсылаемых пакетов.

 

 

 

  _Призрак_ писал(а):

А в Survarium отсутствуют боты в принципе. Вообще. Им все нужно делать с нуля - архитектуру, поведение и т.д.

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

 

 

 

  Malandrinus писал(а):

Если до сих пор не сделали, значит на то есть какие-то иные причины.

Какая-то причина уже как года 4. Возможно, это же причина послужила закрытию второго сталкира.

[Malandrinus 615]

 

 

  SkyLoader писал(а):

.NET, да.

Это ведь означает managed код. Или я что-то не понимаю? Как это всё совмещается с чисто С++ кодом игры?

[User_X.A.R26 261]

  Malandrinus писал(а):

Как это всё совмещается с чисто С++ кодом игры?

Это всё легко сделать, если использовать C++/CLI

Изменено 27 Августа 2016 пользователем User_X.A.R26

[Malandrinus 615]

 

 

  User_X.A.R26 писал(а):

C++/CLI

а как там с шаблонами C++ ? Движок их использует весьма интенсивно. Собственно вся игровая логика в xrGame строится на них. Плюс на шаблонах вся скриптовая система. Наверное можно это всё выкинуть, но тогда от игры останется голый рендер.

[_Призрак_ 11]

 

 

  Malandrinus писал(а):

А не приходит такое соображение, что они там отсутствуют просто потому, что их нормально не сделать или сделать сложно?

Приходит, но все же я бы попросил бы определение "нормально сделанных ботов".

​

 

  SkyLoader писал(а):

Это самое меньшее из зол. Вернее самое первое, что требуется сделать. Основная проблема то в синхронизации и большом количестве отсылаемых пакетов.

Тут я могу поспорить. Да, можно просто сказать что количество пакетов будет большим, но мы можем посчитать насколько. Каждого НПС можно представить как игрока, за которого играет компьютер. Соответсвенно большое число пакетов = (число ботов + игроков) * среднее число отправляемых пакетов в секунду. Итого если мы имеем кооперативное прохождение (сколько это человек? 2-4?), мы можем без проблему заполнить карту еще 30 ботами (а скорее всего и большим числом) без проблем с сетью. К тому же, насколько я знаю, в планах ребят которые делают кооп (или было в планах) - введение системы алайфа в мультиплеер. У нас есть сервер который обсчитывает всех(?) ботов в онлайне, но каждому клиенту отправляет информацию только о НПС в радиусе алайфа. Сколько у нас на пике ботов может быть в радусе алайфа (возьмем стандартный в 150м)? 20? 30? Не думаю больше. Вот и вся проблема большого числа пакетов. Поправьте если я не прав.

 

 

 

  Malandrinus писал(а):

Во-первых, в сингле множество действий происходит напрямую в обход серверной архитектуры

Какие? Просто если мы говорим про диалоги/передача предметов, то это не является большой проблемой для исправления.

 

 

 

  Malandrinus писал(а):

Здесь начинают гадить задержки сети.

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

[abramcumner 1 205]

  Malandrinus писал(а):

И насчёт того, что "делать с нуля". Это серьёзно?! Это же разрабы сталкира почти в полном составе, включая Ясенева, который как раз и отвечал за весь AI (т.е. по сути почти весь xrGame). О работе с нуля здесь даже речи идти не может, всё уже есть. Если до сих пор не сделали, значит на то есть какие-то иные причины.

Сурвариум именно что "делают с нуля". Посмотри исходники xray 2.0. По слухам сурвариум построен на них.

[User_X.A.R26 261]

  Malandrinus писал(а):

а как там с шаблонами C++ ?

C++/CLI - просто прилепленные к "классическому" С++ расширения для работы с .NET типа всяких там управляемых классов и etc

Изменено 27 Августа 2016 пользователем User_X.A.R26

[Malandrinus 615]

  _Призрак_ писал(а):

я бы попросил бы определение "нормально сделанных ботов".

 

Хотя бы как в сингле сталкира.

 

 

  Цитата

предсказывание траектории движения и т.д. Тоже самое включаем для мобов и все, проблема решена.

 

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

 

Совсем другое дело монстр, который: во-первых маневрирует куда быстрее человека, во-вторых его атаки не удалённые, а близкие и основаны на физическом контакте (т.е. это не абстрактное "я в тебя выстрелил, умри", а вполне конкретное движение из конкретной точки в определённую сторону), в-третьих монстров обычно больше, нежели людей (и все они близко к игроку). Здесь уже будет совершенно очевидно, что сеть лагает со всеми вытекающими: внезапные телепортации, хиты из ниоткуда и т.п.

 

Но вообще мне нравится это "проблема решена". пыс делали годами, ВГ делали, а воз и ныне там. А здесь раз - и проблема решена =)

 

 

  abramcumner писал(а):

Сурвариум именно что "делают с нуля". Посмотри исходники xray 2.0. По слухам сурвариум построен на них.

 

Исходники xray 2.0 - это конечно ни о чём. Но даже если это то, с чего начали сурвариум, и что с того? Я исхожу из того, что там присутствую все ключевые люди, которые отвечали за AI сталкира. Те, что делали рендер, свалили в 4A и, кстати, за пару лет сделали свою игру со своим рендером и своим ai (и вполне очевидно, что даже если делали с нуля, то знали что делать). При таком раскладе я вижу только одну прчину, почему до сих пор ВГ не сделали кооператив с мобами - потому что это таки сложно.

 

@User_X.A.R26,

ну вот я попробовал простой файл с шаблонами скомпилить в проекте C++/CLI. Не вышло, вылезла куча ошибок. Фичи C++11 не переваривает точно. Уж не знаю, как можно весь движок сталкира пересобрать под этим. Разве только поудалять большую часть кода на шаблонах. Ну может я что-то не понимаю. Давно с .NET не работал, так что наверное отстал от жизни.

[User_X.A.R26 261]

 

 

  Malandrinus писал(а):

вылезла куча ошибок

Попробуй поиграться с настройками проекта. Возможно у тебя включен только "управляемый режим"

---

  Malandrinus писал(а):

Фичи C++11 не переваривает точно

С++11 должен тянуть... Хотя наверное от версии студии\компиляторов\тулсета зависит

Изменено 27 Августа 2016 пользователем User_X.A.R26

[Malandrinus 615]

@User_X.A.R26,

Я понял проблему. Нельзя аргументом шаблона сделать слово "event", видимо ключевое слово. Переименовал - собралось.

 

 

 

 

Здесь ранее заходила речь о передаче внутриигровых сообщений через нетпакеты. Вопрос стоял так: "какая альтернатива?" Вот набросал черновой вариант системы асинхронной передачи сообщений. В архиве по ссылке заголовок с классом и служебными макросами. 

  Пример использования. (Показать)

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

struct some_event { int a; }; struct event2 { float f; event2& set(float f_) { f = f_; return *this; } }; struct empty_event {};

struct some_event {
    int a;
};
struct event2 {
    float f;
    event2& set(float f_) { f = f_; return *this; }
};
struct empty_event {};

Далее создаём очередь сообщений:

#include "events_queue.h" EVENT_QUEUE_BEGIN(my_queue) message<some_event>, message<event2>, notification<empty_event> EVENT_QUEUE_END(queue)

#include "events_queue.h"

EVENT_QUEUE_BEGIN(my_queue)
    message<some_event>,
    message<event2>,
    notification<empty_event>
EVENT_QUEUE_END(queue)

Здесь my_queue - это тип объявленного класса (просто любой вменяемый уникальный идентификатор. В дальнейшем не потребуется), а queue - имя переменной, по которой в дальнейшем будем обращаться к очереди. Шаблон message задаёт событие с передачей аргументов. В этом случае обработчик такого события обязан иметь вид:

void class_type::fun(const event_type& e)

void class_type::fun(const event_type& e)

В случае notification соответственно обработчик должен быть без аргументов:

void class_type::fun(void)

void class_type::fun(void)

Теперь допустим, у нас есть несколько классов, методы которых мы хотим подписать на соответствующие события:

class C { public:     void fun(const some_event& e) { // этот метод подпишем на some_event         int a = e.a;     } }; class C2 { public:     void fun2(const event2& e) { // этот подпишем на event2         float f = e.f;     }     void fun3() { // empty_event     } };

class C {
public:
    void fun(const some_event& e) { // этот метод подпишем на some_event
        int a = e.a;
    }
};
class C2 {
public:
    void fun2(const event2& e) { // этот подпишем на event2
        float f = e.f;
    }
    void fun3() { // empty_event
    }
};

Теперь выполняем типовые действия с очередью сообщений:

C c; C2 c2; // подписали методы на события queue.subscribe(&c, &C::fun); // здесь использовали уточнение типа события. Это в данном случае несколько избыточно, // поскольку тип события неявно следует из типа подписанного метода "void C::fun(const some_event& e)" queue.subscribe<event2>(&c2, &C2::fun2); // однако имеет смысл всегда указывать тип события, чтобы не допускать ошибок //queue.subscribe<some_event>(&b, &C::fun); // <== ошибка: тип указателя на объект не соответствует типу указателя на метод //queue.subscribe<event2>(&c, &C::fun); // <== ошибка: тип сообщения не соответствует типу обработчика // а вот здесь тип сообщения обязателен, поскольку обработчик не имеет аргумента и может быть подписан на любое notification событие queue.subscribe<empty_event>(&c2, &C2::fun3); // теперь посылаем сообщения (т.е. помешаем их в очередь) some_event e1; e1.a = 1; queue.defer(e1); e1.a = 2; queue.defer(e1); event2 e2; e2.f = 1.234f; queue.defer(e2); queue.defer(event2().set(567.89f)); // для инициализации аргументов события можно было бы использовать и конструктор. // в случае сообщения без аргументов надо явно указывать его тип queue.defer<empty_event>(); // теперь в другом месте (обычно в глобальном колбеке на фрейм этого или других потоков), вызываем так queue.process_deferred(); // соответственно здесь в порядке посылки сработают подписанные колбеки. //Также допустимо и синхронное использование (просто вызвать здесь и сейчас все подписанные колбеки нужного события) queue.call<empty_event>(); event2 e3; e3.f = 3.45f; queue.call<event2>(e3); // наконец отписать обработчики от события можно так queue.unsubscribe(&c2, &C2::fun2); queue.unsubscribe(&c, &C::fun); queue.unsubscribe<empty_event>(&c2, &C2::fun3); // аналогично подписыванию надо явно указать тип события

C c;
C2 c2;
// подписали методы на события
queue.subscribe(&c, &C::fun);
// здесь использовали уточнение типа события. Это в данном случае несколько избыточно, 
// поскольку тип события неявно следует из типа подписанного метода "void C::fun(const some_event& e)"
queue.subscribe<event2>(&c2, &C2::fun2);
// однако имеет смысл всегда указывать тип события, чтобы не допускать ошибок
//queue.subscribe<some_event>(&b, &C::fun); // <== ошибка: тип указателя на объект не соответствует типу указателя на метод
//queue.subscribe<event2>(&c, &C::fun); // <== ошибка: тип сообщения не соответствует типу обработчика

// а вот здесь тип сообщения обязателен, поскольку обработчик не имеет аргумента и может быть подписан на любое notification событие
queue.subscribe<empty_event>(&c2, &C2::fun3);

// теперь посылаем сообщения (т.е. помешаем их в очередь)
some_event e1;
e1.a = 1;
queue.defer(e1);

e1.a = 2;
queue.defer(e1);

event2 e2;
e2.f = 1.234f;
queue.defer(e2);

queue.defer(event2().set(567.89f)); // для инициализации аргументов события можно было бы использовать и конструктор.

// в случае сообщения без аргументов надо явно указывать его тип
queue.defer<empty_event>();

// теперь в другом месте (обычно в глобальном колбеке на фрейм этого или других потоков), вызываем так
queue.process_deferred();
// соответственно здесь в порядке посылки сработают подписанные колбеки.

//Также допустимо и синхронное использование (просто вызвать здесь и сейчас все подписанные колбеки нужного события)
queue.call<empty_event>();
event2 e3;
e3.f = 3.45f;
queue.call<event2>(e3);

// наконец отписать обработчики от события можно так
queue.unsubscribe(&c2, &C2::fun2);
queue.unsubscribe(&c, &C::fun);
queue.unsubscribe<empty_event>(&c2, &C2::fun3); // аналогично подписыванию надо явно указать тип события

 

 

 

  Ещё пара моментов. (Показать)

1. Для работы нужны fast delegates. В сталкире они уже присутствуют, но там что-то меняли с соглашениями вызовов. Вот заголовок, который я использовал.

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

3. Даже в таком виде в принципе можно использовать и заменить большую часть случаев использования нетпакетов.

4. В принципе можно развить и получить некоторые дополнительные выгоды. Например добавить возможность посылать сразу по нужному ID, чтобы из всех подписанных объектов сообщение было автоматически передано адресату.

 

 

Изменено 28 Августа 2016 пользователем Malandrinus

[User_X.A.R26 261]

@Malandrinus, вот и вот ещё кое-что, если интересно...

Изменено 28 Августа 2016 пользователем User_X.A.R26

[Malandrinus 615]

Насколько я понял, Microsoft так и не сделали редактора GUI для C++. И из набора доступных проектов в студии это тоже очевидно. Так что мой вопрос @SkyLoader-у по сути остаётся, что использовалось для GUI? C# ? А как тогда строится взаимодействие с запчастями от игры?

 

Впрочем, вопрос уже чисто теоретический. Лично я так делать бы не стал в любом случае. Взял бы любой из доступных для С++ фреймворков для окошек, скажем wxWidgets, поскольку я с ним знаком, и не парился бы.

Изменено 28 Августа 2016 пользователем Malandrinus

[SkyLoader 53]

 

 

  Malandrinus писал(а):

что использовалось для GUI? C# ?

Посмотри в исходниках ЧН или ЗП редактор погоды (src\editor\). Его я за основу брал. Там можно увидеть всё взаимодействие.

[User_X.A.R26 261]

 

 

  Malandrinus писал(а):

Microsoft так и не сделали редактора GUI для C++

 

  Malandrinus писал(а):

из набора доступных проектов в студии это тоже очевидно

Создай проект "VC++ для платформы CLR", добавь в него форму Windows Forms, открой и увидишь Дизайнер, аналогичный подобному в VC# и VB.

---

 

  Malandrinus писал(а):

что использовалось для GUI?

В оригинале, насколько я понимаю, где-то применяется C++ и MFC, ну а где-то как раз C++/CLI и Windows Forms (пример со вторым привёл комрад @SkyLoader постом ниже; там как раз используется C++/CLI)

[Expropriator 2 119]

Есть мысль как реализовать движение гусениц танка в Сталкере.

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

 

Движение будет правдоподобным от шейпов траков, толкающих меш танка. Как думаете, я ерунду толкую или дело?

 

Забыл, только про ограничение костей. Что же придумать? Надо как то сделать танк.

Изменено 29 Августа 2016 пользователем Дизель

[НаноБот 742]

@Дизель, у гусеницы порядка 98 траков, и того порядка 230 костей надо, а ограничение 64 кости, и легкими методами это число не поднять. Я думаю проще объединить траки в группы  костей, и таких групп порядка 6-8, и всё, анимация только одна, делаем методы задающие скорость анимации, в том числе отрицательную скорость, что бы задом на перед можно было отыгрывать.

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

Давно мечтаю как было в диздоках, вернуть БМП-2, как раз идея для проекта Oblivion Lost Remake 3.0.

Изменено 29 Августа 2016 пользователем НаноБот

[HellRatz 2 896]

  НаноБот писал(а):

а ограничение 64 кости, и легкими методами это число не поднять

ОГСЕшники убрали лимит на 64 кости (Или сколько там в ТЧ ограничение) в своем моде.

Изменено 29 Августа 2016 пользователем HellRatz

[НаноБот 742]

@HellRatz, в принципе можно и увеличить количество костей, например до 256. Но моя идей может быть реализована уже сейчас для проекта XRay-Extensions для ТЧ и ЗП. Надо только сделать соответствующий модель. Я так понимаю эти методы должны работать для костей не имеющих наследников. 

ЗЫ

Единственное, что гусеницы не будут прогибаться согласно прогибу катков, но это ерунда, будем считать что они в грунт проседают.

Изменено 29 Августа 2016 пользователем НаноБот