Известны ли случаи, чтобы фреймворк XNA зависал, особенно на слабых процессорах, или это баг в самой игре?

Rou1997: «В разных играх все же по-разному.»
Естественно. Со временем защита меняется. Но в саму игру не встраивается.

«Нет - это всего лишь игра, причем основанная на довольно высокоуровневом XNA, а он должен быть абстрагирован от "железа".»
Во-первых, тот же XNA требует и правильный рантайм, и различные фреймворки, и нормальные драйвера и т.п. А во-вторых, кто вам сказал, что проблема непосредственно в XNA? Думаете, там никаких библиотек сторонних не прикручено? Уверен, что прикручены, и далеко не одна. Вполне возможно, что проблема в одной из них.

«Какими?»
Уже не помню (ну и доступа к алаваровскому багтрекеру у меня уже нет). Игра не работала на WinXP 64 (проблемы именно с алаваровским движком). Авторы движка сказали «won't fix, ибо WinXP 64». Так игра и вышла в релиз.

«Тоже так думаю, для такой крупной фирмы это просто нерентабельно,»
Имейте в виду, что здесь как минимум две составляющие: непосредственно разработчики игры и Алавар (издатель). И чтобы выпустить исправление, нужно чтобы разработчики игры сделали фикс, чтобы издатель сделал полное тестирование (ибо исправление движка), затем обновить игру на своих сайтах, отправить исправленную версию партнёрам (BFG, Zylom и др.). Те, в свою очередь, также будут проводить полное тестирование и только тогда выкладывать новую версию. Вы же понимаете, что для исправления чрезвычайно редкого (!) бага в игре четырёхлетней давности, это как-то слишком? Я даже не уверен, что это реально баг (если несоответствие системным требованиям или какие-то косяки в системе). И вообще, с огромнейшей вероятностью, они его просто-напросто не смогут воспроизвести (или вы знаете ещё кого-то с такой проблемой?), а если невозможно воспроизвести, то и невозможно исправить.

«А когда меня спрашивают, то лучше Unity или UDK, XNA или UDK, то мне об этой слишком уж характерной особенности скромно умалчивать?»
Ещё раз: никакая это не особенность движка. С точно такими же симптомами может зависнуть игра на абсолютно любом движке. Более того, если у вас не хватает мощности для XNA, то о каких Unity и тем более Unreal Engine (уже давно все забыли про UDK) может идти речь? Ну, XNA уже давно нет смысла использовать, ибо он умер. А что выбрать из MonoGame, Unity и Unreal - тут зависит: а) от того, какую игру хотят сделать (выбор инструмента зависит от задачи) и б) от знаний/скиллов непосредственно разработчика (если человек свободно пишет на C#, то смысла садить его на С++ движок нет никакого). А в некоторых случаях сравнивать MonoGame и Unreal - вообще глупо, ибо минимальные системные требования у второго несравнимы с первым.

Известны ли случаи, чтобы фреймворк XNA зависал, особенно на слабых процессорах, или это баг в самой игре?

К системным требованиям присматриваться нужно. Не знаю, о какой игре вы ведёте речь, но нередко бывает так, что сделан отдельно движок и отдельно пишется логика игры, на скриптовых языках - то есть, разработчикам непосредственно в движок доступа нет (есть разработчики, использующие свой собственный движок, а есть и использующие чужие движки, но если это XNA, то, скорее всего, что-то самописное). И если движок не поддерживает систему (например, сам сталкивался с проблемами на 64-битной WinXP), то даже разработчики игры далеко не всегда могут помочь. Что касается их DRM, то там никакой глубокой интеграции нет (не было, по крайней мере) - просто обёртка.

Под XNA когда-то писал, проблем не замечал.

Что касается обращения к разработчикам, уверен, что это ни к чему не приведёт. Во-первых, вряд ли они смогут воспроизвести проблему, так как это явная несовместимость с чем-то в вашей системе (Алавар тестирует на достаточно большом парке машин и проверяют совместимость со множеством версий ОС - если бы была проблема на этом уровне, то её бы обнаружили; единственное - WinXP 64 не фиксят обычно). Во-вторых, разработчики могли давным-давно поменять движок и разбираться, что там за проблема, никто не будет. В-третьих, могут быть ограничения, наложенные договорами. В-четвёртых, даже если они знают, в чём проблема, никто не будет фиксить игру (а вам информацию об этом никто не даст, а даже если даст, то она вам не поможет).

Схожие симптомы в разных движках - не обращайте внимания, такие «зависания» будут вести себя схожим образом независимо от движка.

Можете перечислить компании или конкретных людей, создающих бюджетные хорошие игровые трейлеры?

Вы бы хоть примеры трейлеров привели, чтобы понять, какой уровень требуется. Например, вот простенькие недорогие https://marketplace.yoyogames.com/services/2387/tr...

Как справиться с исчезанием монитора из системы при выключении его питания?

burst: И мне интересно, как можно заставить современный монитор не сообщать системе о том, что он отключен.

Как справиться с исчезанием монитора из системы при выключении его питания?

Потому что а) это не традиционное поведение и б) это не удобно

Быстрое переключение между системами на домашне-рабочем десктопе?

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

Быстрое переключение между системами на домашне-рабочем десктопе?

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

Быстрое переключение между системами на домашне-рабочем десктопе?

CoLinux, как вижу, не поддерживает x64, а дополнительный системник+KVM в данный момент слишком избыточно.

Быстрое переключение между системами на домашне-рабочем десктопе?

Если бы у меня был мак, то, несомненно, я бы использовал Parallels. Есть ли что-то подобное для не маков? Или вы предлагаете Хакинтош сгородить?

Быстрое переключение между системами на домашне-рабочем десктопе?

Я не против виртуальной машины, если оверхед минимальный. Например, если я сейчас запускаю VirtualBox с Linux Mint, то очень хорошо заметно, что система подтормаживает (60 FPS и близко нет, окна рисуются не моментально и т.п.) - вот как раз такого хочется избежать.

Почему в битовых сдвигах остаётся минус?

«если я правильно понял знак хранится в первом бите»
нумерация начинается с нуля и идёт справа налево.

Стоит ли вообще изучать C++?

По поводу "я сама" - это, конечно, сильнейший аргумент ...

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

особенно "для всяких редакторов, конвертеров, парсеров и т.п."

«Особенно» - в контексте того, что это на порядок удобнее/быстрее, чем реализовывать на тех же плюсах.

Но это уже из области личных хобби...

Далеко не хобби. Профессиональная деятельность.

Стоит ли вообще изучать C++?

Олег Цилюрик: По поводу того, кто использует D - это вроде не секрет. Например, Facebook использует.
Sociomantic (больше 250 работников, 19 офисов по всему миру), Remedy Games (не знаю, нужно ли представлять создателей Max Payne?). Собственно, несколько примеров есть и в официальной вики. В конце-концов, официальный сайт также сделан на D.

Я сам занимаюсь геймдевом и также использую D, когда есть такая возможность - особенно для всяких редакторов, конвертеров, парсеров и т.п. Для непосредственно разработки игр также использую (в связке с SFML).

Не согласен на 100% с позицией beduin01 (но это и не моя специализация - не знаю ситуации в обсуждаемой области), однако с позиции заданного вопроса (стоит ли учить С++, внимание: для того, чтобы лучше понимать другие языки, а не для коммерческой разработки на нём) - несомненно, D весьма привлекательный вариант. Порог вхождения гораздо ниже, чем у плюсов (на уровне C#/Python примерно). Его я бы рекомендовал «пощупать» даже просто для себя, для личных проектов - опыт в любом случае не помешает.

Игровой движок для инди-студии и карьеры, что выбрать?

zac02:

просто непонятно причина, по которой упомянули сумму и сроки

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

что не требовало объяснений

Вы писали:

слышать "выдавалось примерно 3 FPS" - несколько странно. это российская компания? во первых уже хотя бы потому, что 3 фпса будут заметны сразу.

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

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

Именно - и сделать и издать. Игра начата, прошла Steam Greenlight, сейчас в раннем доступе. Осталось доделать, затем продвижение. Что вас смущает?

по моему этот человек, не желающий терять доверие какого то там издателя, немного не своим делом занялся. 60-70% вполне неплохой результат. и 10% от вас не стоили тех усилий, по увольнению, по найму человека из канады и как результат вас в послдедствии.

Ещё раз повторюсь: первый программист не имел достаточных знаний и умений, чтобы закончить игру. Он не смог сделать того, что нужно было и именно поэтому отношения с ним были прекращены. Когда программист находится по объявлению, то как-то нет возможности тщательно проверить его скиллы - всегда остаётся пространство для обмана/недоговорок и т.п. (что, конечно же, обусловлено попытками сэкономить на оплате профессионального программиста, но не в этом суть). Напоминаю, что это - ранний доступ, там самые базовые вещи игровой механики. При работе над основной частью игры всё стало бы только хуже. Перед людьми, уже заплатившими за игру, есть обязательства, были даны обещания по срокам апдейтов, релизов и т.п. Соответственно, когда программер начинает затягивать работу (беря большие сроки на элементарные задачи) - это в первую очередь «бьёт» по заказчику и выбора особого нет, приходится искать нового исполнителя (например, на исправление производительности светового движка второй программер попросил две недели). Сначала работа делается достаточно быстро и никаких проблем не возникает, но когда проект разрастается и из-за неверных решений становится трудным в поддержке, то начинающие программисты моментально теряют энтузиазм. Именно это и произошло. Два раза.
Сам же заказчик уже выпустил не одну игру и почти все из них были весьма успешными. И в течении нескольких лет он зарабатывал именно этим, но в силу некоторых обстоятельств, пришлось сделать паузу, а сейчас он опять занялся играми.
Есть другой программист, с которым он делал предыдущие игры и в данный момент также с ним делает игру. Просто проект, о котором речь - дополнительный, так как есть время и ресурсы на него. Более того, неделю назад он начал третью игру, наняв ещё одного программиста. Так что, определённо, он занимается своим делом.

всего пару сотен в 2д? игра сделанная не в конструкторе и световой движок вами переписан? за сутки. вероятно ничего сложного ни в самой игре ни в используемых алгоритмах нет. тогда фпсов мало.

У меня написано:

Я за день переписал световой движок, игра сразу стала выдавать пару сотен fps.

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

честно скажите - вы хвалитесь или поясняете ситуацию?

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

было же всего 3 программера

И что вас смущает в фразе «недостаточных скиллов программеров использовались сомнительные решения»? Подразумеваемое двух предыдущих поменяет смысл фразы?

есть куча алгоритмов по поискам пути (цель - те же вершины).

Безусловно. Я вроде и не говорил, что изобретаю свой собственный алгоритм.
У меня сейчас используется комбинированный поиск из A*, потенциальных полей и волнового алгоритма.

зачем было переписывать полностью? готовые решения не подходят?

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

P.S. Не вижу смысла продолжать этот разговор, тем более - здесь, потому предлагаю на этом закончить. Мои вопросы в данном сообщении являются риторическими, а потому отвечать на них не обязательно.

Игровой движок для инди-студии и карьеры, что выбрать?

zac02: Хорошо, немного подробнее расскажу о ситуации.
Я не имел в виду, что сумма огромная или что-то такое. Это не компания, а просто один человек из небогатой европейской страны, сам он художник и гейм-дизайнер (это хобби, а его постоянная работа с IT никак не связана), решивший выпустить игру, которая сейчас находится в раннем доступе в Стиме.

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

Через несколько месяцев его энтузиазм иссяк и он «слился». Последние его разработки были как раз связаны со световым движком и в Стиме оказалась та самая версия с 3 fps. Не представляю, зачем её залили в таком виде и проверяли ли вообще перед закачиванием (сейчас я тестирую своими силами перед отправкой издателю). Но факт такой. Для меня это тоже непривычно: после Алавара, Kongregate, BFG, Zylom и множества других крупных и небольших издателей, которые всегда проводят тщательное тестирование (хотя мелкие российские издатели довольно часто «халтурили», да и крупные бывало фейлили при релизе локализованных версий, но это скорее исключения). И обычно не было релиза, пока не будут закрыты все баги. С изданием в Early Access я до этого не сталкивался и огромный список критичных багов, на странице сообщества игры в Стиме, был для меня неожиданностью. Хотя большинство из них я пофиксил в первые же дни начала работы, ещё до заглядывания в Стим - настолько они очевидны были.

Насколько знаю, перед вторым программером рейтинг в Стиме был около 60-70% положительных отзывов и огромное количество установок. Не в курсе подробностей, но уже при мне, за прошлый месяц, с распродажной ценой около 6 центов, игра заработала несколько тысяч долларов.

В тот момент, когда я подключился к проекту, игру заминусовали до примерно 20-30% за кучу багов и тормоза. У человека обязательства перед издателем, он не хочет потерять его доверие, наработанное за несколько лет до этого. Неприятная ситуация.

Я за день переписал световой движок, игра сразу стала выдавать пару сотен fps. После сделал множество других фиксов и исправлений. Рейтинг через несколько недель восстановился, а сейчас составляет 80%. Ничего сверхнавороченного не было - игра 2d, вид сверху, помещения, толпы зомби, крафт и т.п. Но из-за недостаточных скиллов программеров использовались сомнительные решения, из-за которых возникали большие тормоза. В световом движке, например, один из источников тормозов - создание размытой тени (для ambient occlusion) через многократное рисование почти полностью прозрачного спрайта. Я использовал шейдеры, но тут же выяснилось, что не на всех машинах игроков они работают (отсутствует необходимый рантайм directx на некоторых версиях Windows). В итоге сделал два варианта: шейдеры по умолчанию, а у кого они не работают, всё рисуется программно, но с кучей оптимизаций (ну а сложные полноэкранные эффекты просто будут отсутствовать). Иногда чуть менее красиво, медленнее, но работает.

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

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

Игровой движок для инди-студии и карьеры, что выбрать?

zac02:

вы ведь в курсе, что асемблер быстрее?

Конечно в курсе. Я больше 7 лет исключительно на ассемблере писал.

а если на машинном коде писать сразу так вобще!

Что значит «так вобще»? Производительность возрастёт? Памяти меньше занимать будет?
Не смешите. Ассемблер, по сути, является «литературной» записью машинного кода.
Были времена, когда приходилось и напрямую машинный код писать/читать - но не вижу в этом ничего крутого.

держу пари, вы сами все возможности не знаете.

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

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

Производительность на мобильных устройствах весьма критична. И примеров миллионы. Прямо сейчас переписываю систему поиска оптимального пути/логики выбора целей/перемещения больших групп зомбей/и т.п. за двумя предыдущими программистами (на что заказчиком было потрачено пол года времени и несколько тысяч долларов). Когда игра попала ко мне, в неё было невозможно играть: на мощном десктопе (десктопе, а не тем более на каком-нибудь двухлетнем планшете!) выдавалось примерно 3 FPS (не только из-за поиска пути, там ещё много «творчества» было - очень медленный световой движок, например). По большей части производительность зависит от архитектуры/правильно выбранных алгоритмов, но для мобилок нередко приходится вообще по максимуму выжимать. Если вам нужен клон Angry Birds, Flappy Bird или 2048, то, конечно, вообще без разницы (только не понятно, зачем там вообще такие движки - хватит и какого-нибудь мелкого конструктора/движка). Однако, не только такие игры делаются, есть и посложнее. Если мне память не изменяет, за последние пять лет у меня такая простая игра была только одна. Игр, где вообще не требовалась производительность - тоже не особо много, на пальцах одной руки можно пересчитать. Все остальные так или иначе приходилось в значительной степени оптимизировать (в основном - под Android/iOS) - где-то по памяти/текстурам, где-то по CPU, где-то по работе с файлами, где-то ещё что-нибудь. Если вам не требовалась максимальная производительность, то это не значит, что это не потребуется никому и никогда.

для некоторых это проще, чем наследование, и темплейты классов и переменных, виртуальные функции и перегрузки (хотя для некоторых и нет). и такие вещи есть не только в уе.

Естественно для новичка проще. А для профи скорее будет ровно наоборот - проще написать строку кода.

как и я, автор, а так же 99.5% программистов, которые все таки довели свои проекты до конца. причем не на с++, а на каком нибудь "медленном" delphi,java,c#,(вставьте свой вариант).

Мой первоначальный посыл - чистый язык даёт больше возможностей, чем визуальная среда программирования. То, что c++ даёт максимальную производительность - это просто бонус (хотя в некоторых случаях он может быть критичным). Я не призывал не использовать blueprint или, тем более, писать всё исключительно на c++ (безотносительно движка). Я на c/c++ пишу настолько редко, насколько могу, но иногда всё же приходится брать и выносить критичный код в библиотеку и использовать её из скриптов/etc.
А почему я не сказал «да, делайте всё на blueprint» - перспектива. Если топикстартер будет заниматься серёзно разработкой игр (на что указывает «для инди-студии и карьеры», то рано или поздно придётся выйти за рамки «конструктора», а для UE в этом случае придётся использовать c++. И если человек абсолютно не знаком с ними, то получится большая проблема, так как хоть сколько-нибудь адекватно изучить «плюсы» за короткое время не получится. В аналогичной ситуации с шарпом разобраться будет намного проще.

Игровой движок для инди-студии и карьеры, что выбрать?

zac02:

многие люди не зная ни одного языка программирования отлично разрабатывают логику без использования с++ в уе.

Я не утверждал, что с помощью blueprint ничего невозможно сделать. А тем более, логику писать или механику, где не требуется максимальная производительность, - да пожалуйста. Речь шла об вообще всех возможностях, которые даёт с++. Хотя вы правы в том, что начинающим инди, чтобы «выдавать вполне годные инди поделки» вполне может хватать и исключительно blueprint'а.

Сидячий образ жизни кодера на самом деле ухудшает здоровье?

Дмитрий Макаров: Можно и быстрее бросить курить. У меня после более чем 12 лет стажа (насколько помню, в конце выходило чуть больше пачки в день) «ломка» была три дня. На четвёртый день проснулся и понял, что желания курить нет абсолютно - оно просто пропало и с тех пор (больше 10 лет) не появлялось.

Динамическая генерация 2d ландшафта, что почитать?

Типа того.
Спасибо, статью эту читал, как и статью по diamond-square.

Динамическая генерация 2d ландшафта, что почитать?

Да, с самим контуром поверхности понятно. Пока в мыслях только 1d Perlin для контура поверхности и 2d Perlin для пещер.