Снова о том, на чём писать игры

Здравствуйте. В этой небольшой статье хочу поднять до сих пор многих тревожащий вопрос: «На чём писать игры для незрячих?»
Многие уже поняли, что bgt — не самый лучший выбор. Нет поддержки потоков, что избавляет игрока от фееричных лагов в сетевых играх, 3D звук написан четырнадцатилетним школьником, а не профессионалами, ну и множество других мелких, но досадных упущений.
Итак, какие есть альтернативы?
Некоторые особо продвинутые разработчики взялись за широко известный Python. Подробно про преимущества и недостатки написать не могу, ибо сам с этим языком знаком только на уровне «hello world», но один обидный лаг все-таки вспомню: «Ни одна игрушка не запускается, если положить её по пути, содержащему русские символы».
Далее, кто-то давно предлагал вариацию языка basic под игры под названием blitz 3d. В общем-то неплохой вариант: все вычисления за разработчика делает движок, есть приемлемый 3d звук и даже сравнительно неплохая примитивная 3d графика. Но этот язык откровенно отказывается взаимодействовать с современными драйверами видеокарт, что перечёркивает все его преимущества. Потом предлагали на форуме ещё один мутаген от basic под названием blitz dart. Открыв туториалы по нему и увидев кучу не нужных игровому программисту математическо-физических расчётов, ужаснулся и закрыл сразу же.
В общем, мои изыскания остановились на библиотеке для всеми уважаемого c++ с ну очень скромным названием «Simple and Fast Multimedia Library» (SFML).
Функционал библиотеки не столь обширен, как, допустим, у того же openGL или boost, но sdk справляется с поставленной задачей: обрисовывать примитивную 2d графику (если вам нужно вывести логотип игры на экран), выводить 3d звук, кстати с обработкой движения и эффектом даплера для движущихся объектов, записывать звук, что будет полезно в сетевых играх, работать с сетью почти на уровне bgt, а не бустовских низкоуровневых сокетов и прерываний, открывать окошки, менять их размер, ну и конечно же взаимодействовать с клавиатурой, мышью и джойстиками на уровне, гораздо превышающем предложенное в bgt.
Я сам только поверхностно ознакомился с функционалом, но когда узнаю эту библиотеку со всех сторон, обязательно напишу туториал специально по ней. Но писать впустую не хочется, поэтому, кому интересно, отпишитесь в комментариях, чтобы я понимал, надо это людям или нет.
Всем спасибо, удачного кодинга.

Снова о том, на чём писать игры: 0 комментариев

  1. Ну меня bgt устраивает, с потоками соглашусь, но если писать оптимизированный код, то думаю проблем не должно быть, когда допишем игру, посмотрим, столкнёмся ли мы с лагами, думаю нет. Насчёт sound_pool, я давно написал свой, с правильными расчётами, другое дело что нет кроме pitch никаких эффектов, ну что есть хотя бы, всё равно можно 2d игру норм написать, 3d конечно нет, одна из причин почему мы отказались от 3D, вторая, это сложно играть направляя оружие во все стороны, иммею ввиду вверх и вниз под всеми градусами. Есть косяки в bgt, в том же network, пришлось переписывать немного, а так всё устраивает.

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

  3. Для даунов? А может тогда не надо?
    Как вариант заплатить специалистам, которые напишут код. Ну как-бы, если человек даун, то тут хоть как пиши, всё-равно не понятно будет.

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

  5. ага! буду писать! ибо посмотрев на остальные комментарии ужаснулся безграмотности. и вообще, надо написать что-нибудь на тему параллельного программирования и его преимуществ. а ещё на тему того, где все-таки обрабатывать миллионы объектов летящих пуль, чтобы все не лагало как в hvr.

  6. Хм, если отвечу жёстко, извините, строго по теме.
    Вы пишите:
    оптимизация кода невозможна когда каждая сетевая операция по типу send_reliable заставляет весь цикл ждать подтверждения от клиента.

    Вы это сами только что придумали?
    сервер отправляет сообщение-reliable, объект хост, ставит его в очередь, если очереди нет то отправляет, если есть то ждёт очереди, это происходит в отдельном потоке, какой цикл ждёт? может я вас не верно понял?
    к слову, если сервер отправил вам, как клиенту сообщение и ждёт от вас подтверждения, то отправив мне сообщение, я получу и отдам подтверждение о получении не дожидаясь вашего, вы мне мешать не будете.
    К тому же есть 100 каналов, хотя, о чём я, мы хотим же потоки, а то что это и есть потоки, а их мало? ну тогда дерзайте, пишите 100500 потоков у себя в игре.
    другое дело что unreliable перебьют reliable, их надо раскидывать по разным каналом, иначе потеряем пакеты, но вы это знать должны.

    Вы пишите:
    когда все объекты живут в одном потоке и обслуживаются последовательно.

    вот когда все объекты обслуживаются, тут и нужна оптимизация, вы выше писали что 1000000 объектов мол hvr тормозит, думаете потоки решат проблему?
    конечно нет, берём сервер 2 ядра, ну вы можете задействовать второе ядро создав второй поток, на выходе игра тормозит ровно в 2 раза меньше., в место 10 секунд лага получаем 5, хотите 4 ядра? окей 2,5 секунды, тоже существенный лаг, особенно почти постоянно, надо решать в коде как уменьшить нагрузку. А что будет если играть будут 100 человек одновременно?
    Только не надо говорить что можно создать 20 потоков а то и больше, эти потоки будут отжирать ресурсы друг от друга, собственно говоря, потоки нужны не для того чтобы уменьшать нагрузку, увеличивая производительность, как вы наверняка думаете, а для того, чтобы параллельно выполнять код, а это не то чтобы не одно и то же, а абсолютно разное.
    Да, сейчас bgt использует одно ядро, используя 4 ядра вы производительность увеличите, но как выше писал, лаги делим на 4, пишите оптимизацию, не хотите, ищите другой язык, у вас даже при распараллеливании будут проблемы те же самые.

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

    Хах, а кто ждёт? ваш код так ждёт? сервер передал на очередь и всё, выполняется дальше, выполняется именно так как вы описали, отправил трём сообщение, и идёт к четвёртому, 1 миллисекунда не пройдёт, потому что в host свои потоки, дальше проблема host-а, ушло не ушло, ну и проблемы того, у кого интернет плохой, что потоками в другом языке вы не решите.
    Так что аргумент не принят, bgt именно так и работает.

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

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

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

    Грамотный вы наш, ищите язык с потоками, пишите 1000000 объектов, потом поймёте что надо учитывать ресурсы памяти и процессора, и будете читать, учится, думать, Разрешите быть вторым, кто ждёт от вас этой статьи.
    1000000 пуль, это ужас, конечно там не столько, но вы написали медленный код, перепишите пули, сделайте их не объектами, если я правильно понимаю, что это вы hvr написали, ещё, не обслуживайте объекты все, а только те которые действительно надо обслуживать, и будет вам счастье.
    Ещё раз извините, просто Своими комментариями вы вынудили меня написать это.

  7. Кирилл, в HVR уже около месяцев нету лагов. Сервер стабильно работает 3, 5 дней. Возможно проработал бы и больше, но то мы перегрузим, то обновление выходит какое-нибудь.

  8. вас не должно волновать сколько потоков у процессора, поверьте, он умнее вас, и компилятор языка делали не тупые люди. просто это классика современного программирования: под каждого пользователя на сервере поток, под графику поток, под звук, под логику и под клавиатуру с мышью. так написана gta v, так написан microsoft office, так работают продукты компаниии new cloud technologies в которой работает мой сосед. хотите сказать что там идиоты сидят, которые не могут «оптимизировать» код и работать в одном потоке?! ну и конечно же в bgt меня бесит отсутсствие нормальных указателей. что это за бред что нельзя передать указатель ни на что кроме объекта? представьте что вам надо передать строку в 4096 байт (максимальная длина пакета bgt), вы будете его в функцию передавать целиком или передадите 2 байта указателя. а если таких строк надо передать 100 в секунду? вооот. оптимизация, и без потоков. но и этого в bgt нет.

  9. и да, я не разработчик hvr.

    и ещё один нюанс: где в bgt такая приятная для геймера вещь как вибрация джойстика, по другому обратная связь? её нет. где подключение библиотек, его нет. где нормальное наследование, где виртуальные методы, которые так упрощают код! где указатели на функцию, где лямбды? это вобще классная вещь. когда тебе нужно в поток передать функцию, которую ты можешь на месте определить, то есть в качестве аргумента другой функции передать последовательность налету собранных инструкций в зависимости от ситуации, и не надо эту функцию гдето определять, придумывать ей название, просто в скобочках написал кусок кода и передал его аргументом. ещё: где работа с web? где нормальная генерация http запросов? чтобы с возможностью следовать редиректам. где работа с ssl и другой защитой данных? где всё мировое сообщество, которое работает на улучшение языка, обновляя его каждые 2 года, создавая тысячи полезнейших инструментов. уж точно всего этого не найти в bgt. так что это точно не лучший язык.

  10. Тезис, который я оспариваю, что код невозможно оптимизировать, вот и в hvr оказывается лаги убрали, люди работают, говорю лишь то, что надо всё время искать быстрые алгоритмы, а потоки люди используют для распараллеливания задач, и для того, чтобы задействовать все ядра, последнее для bgt недоступно, увы, тут согласен.
    Я програмирую, и меня волнует как работает процессор, умнее он там меня в чём-то или нет, надо знать что для него проще что тяжелее, написать можно тем самым лучший алгоритм.
    Если пустить в один поток всё, что вы мне предложили, то основной поток игры перестанет отвечать, наверно часто встречались с тем, что вы запускаете программу, а screenreader вам произносит, мол эта программа не отвечает, после чего программа запускается, это как раз загрузка основного потока, нельзя в программе никуда нажать, теперь, если бы игры писали в одном потоке, то мы бы ждали пока всё загрузится, а если винда решит, что мол очень долго основной поток программы не реагирует, то просто предложит вам её закрыть, вот и распараллеливаем по разным потокам, но задействовать больше ресурсов чем есть у процессора по логики нельзя, поэтому что бы вы не писали, если оно тормозит на одном ядре, то будет тормозить на 4 ядрах максимум в 4 раза меньше.
    Про передачу строк по сети, передаю до 1,3 мегабайта, передаётся всё, не знаю делит ли сам объект host строку, но работает быстро, улетает при норм интернете за 0,2 секунды, я так карты передаю, которые клиент сохраняет себе, так что тут не согласен.
    В функции переменные итак передаются по указателю.
    Вобщем не понял, я чего нет в bgt, читайте bgt.chm там об этом написано.

  11. То есть мы сейчас о другом уже? Сразу скажу , я не говорил, что bgt это супер язык, которого достаточно, хоть os пиши, хоть драйвера, хоть любую игру, я говорил лишь, что мне его достаточно для написания игры, которую мы пишем.
    обратной связи нет, ок, мне не нужна, мне и джостик не нужен, в основном играют на клавиатуре и мыше, здесь для этого всё есть.
    Подключение dll есть, работает криво зачастую, да это плохо, bass.dll не смог заюзать, то работает то не работает, другие пару dll сам писал которые, удалось подрубить, делал графический интерфейс, просто для пробы, бросил, мне не нужен gui в игре, для зрячих не собираюсь писать, там конкуренция большая, и умнее разработчиков много, пусть пишут.
    Какое вам надо нормальное наследование, уточните? на мой взгляд, в bgt с наследованием всё отлично, да нет почти модификаторов, нет абстрактных классов, помоему без них можно обойтись, есть интерфейсы, можете их юзать, если вам нужна абстракция, есть полиморфизм, Переопределение методов, вызов метода из родителя, вот вам и вертуальные методы. что не так-то?
    Указатели на функцию, дескрипторы функций, ну есть это, я юзаю их, они тяжеловаты для понимания, после пару троек практических применений пишутся руками.
    В bgt нет потоков, зачем тут лямбды?
    С остальным так или иначе согласен, например, с перенаправлениями приходится управляться руками, по ssl вообще не работает, нашёл возможность брать прямые ссылки с яндекс диска, а там https, думаю написать dll, или придумать что-то другое для обновления игры. не всё гладко, язык не лучший, но прос и достаточно функционален, чтобы писать хорошие игры, в том числе онлайн.

  12. я на bgt 2 года писал. и файл chm я знаю почти наизусть блин! и по указателю передаются только объекты. часть 13 или 12 основного мануала. и карта это карта, а если вам нужно каждые 5 миллисекунд передавать строки такой же длинны в 1 метр в функцию. при запуске функции под неё выделяется память и все аргументы копируются. а теперь представьте что каждые 5 миллисекунд метр данных будет копироваться из участка в участок памяти.

  13. согласен что лямбды без потоков не особо нужны. но потоков то нету. и это минус. а вы сами играли когданибудь? вы знаете это ощущение когда джойстик на каждый выстрел вибрирует? это называется погружение, если добиться идеального звука и обратной связи игрока будет не вытащить из игры. вам не надо а аудитория хочет. и это есть везде кроме бгт. а про дескрипторы функций это вы верно сказали «сложно для понимания» а в c++ есть функция writer_callback() и ты даёшь на неё ссылку &writer_callback. или так auto write = &writer_callback. и все. или вот вам пожалуйста. передача объекту функции для работы с внешним миром при инициализации. есть та же функция что написал выше. мы создаём объект auto obj = new player(&writer_callback); а в конструктор объекта пишем. выглядит так
    public:
    player(std::function& write(void))
    : writer_callback_func = write
    {
    //constructor
    }

    помоему удобно и просто.
    вобщем я за c++ а вам удачи в написании игр без обратной связи, в одном потоке и с аудиторией не более 4000 игроков, да да ещё одно ограничение бгт.

  14. best_gamer,
    Да, проверил, они копируются, тогда пишите класс, оборачивайте string переопределяйте методы: присваивания и прочие, и будете работать как с string, но сможете передавать указателем, я просто не понимаю, куда гонять в играх метры текста.
    в языках типа delphi и java string является объектом, во многих других языках также, там есть указатели на них, в bgt нет. Плохой язык в топку? ну я и не спорил, про указатели погорячился, потому что в angel script оно есть, хотя тоже уже сомневаюсь.
    Я остаюсь при мнении, что на bgt можно писать крутые онлайн игры, не смотря на его урезанность, пишем на своих языках, я на bgt вы на любом другом. Я собственно вас поправил в плане алгоритмов, их надо оптимизировать, если писать с умом, то bgt игра будет быстрой.

  15. Нашёл ещё одно решение, это использовать массив, передавать его по указателю, то есть
    void work_large_string(string[]& str) {
    // тут работаем со строкой
    }
    будет принимать быстро.
    другое дело, что сама обработка строки будет может быть не быстрой, ну тут уже на любом языке, ведь работаем уже с данными в памяти, хотя тут может от частоты оперативки больше зависит, чем от языка программирования.
    Криво с массивом? да, но всё равно выход, нельзя писать в играх обработку сотен огромных строк в секунду, плохо это на любом языке, так для тестов только, а если понадобилось, то вполне себе можно и так.

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

  17. В HVR убрали утечку ресурсов. По факту, если все одновременно начнут создавать пули, сервер ляжет. Опять же, потому что нет тредов. Если начнет спавниться много объектов, сервер ляжет. Потому что серверу нужно раздавать команды клиентам, когда выставлено отправка с подтверждением, и опять же, потому что нет тредов. BGT не умеет работать с Unicode, что зачастую приводит к казусам в мультиязычных проектах. Да что там мультиязычные проекты! Если попытаться скопировать в Unicode-подобных приложениях и отправить в BGT, мы получим вопросики, потому что Ascii. Потому что выходим за 256 байт.

  18. Как создавали словари? по дескрипторам или нет? добавляли ли в словари значения? Хотелось бы конечно код. вообще, ассоциативные массивы медленные, они медленнее на любом языке обычных массивов, использовать их надо крайне осторожно, очистку garbage_collect хочу проверить. Давайте обсуждать это на форуме, лучше конечно куда-то в скайп, или в team talk.

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

  20. лагов в сетевых играх
    Какие лаги ты видел в STW, Redspot, HVR? Про UP согласен, но ведь он написан был не грамотно.
    3D звук написан четырнадцатилетним школьником, а не профессионалами.
    Во первых, 3D звук тот, что из коробки, написал разработчик BGT. Во вторых, у Сэма есть новая версия Sound_pool, да и наши его переписывали.
    но один обидный лаг все-таки вспомню: «Ни одна игрушка не запускается, если положить её по пути, содержащему русские символы».
    Такие знания объясняются вышенаписанным в статье:
    сам с этим языком знаком только на уровне «hello world»
    Кирилл, русские символы проблема второго Питона. А на третьем эта проблема решается. Да и на втором, если грамотно ее решить. Просто во втором по стандарту используется аски. В третьем уже юникод.
    О C++, биобла то хорошая, тока ты забыл упоминуть, что для работы нужно более менее хорошо знать C++.
    Вообще статья не полная. Если уж писать, так полностью. О Python, PureBasic, C#, C++.
    Многие скажут. «Так напиши». Писал. Тока ща на бг появился странный модератор, который ничего не пропускает. Написал админам, надеюсь все решится.
    А о sfml идея хорошая, но для слишком умных. Тот же C# по синтаксису почти как BGT, без сложных для понимания элементов, а библиотека 3Д звука Irklang вообще как sound_pool.

  21. Я сам программирую на python, правда игр раньше не писал. Но решил попробовать что-то простенькое без заморочек, написал сапера, с управлением с клавиатуры, и озвучиванием всех действий, как раз для незрячих, так как сам не зрячий. Собрал в exe, назвал русскими буквами сапер и саму программу, и папку где она лежит. Никаких проблем с вылетами или еще что, все нормально запускается и играет. И да, как сказал предыдущий комментатор, я пишу на python 3.

Добавить комментарий