x - devlog :: Создание игр :: Форум :: Independent Games Developers Contests

Кратко:

Я начинаю пилить движок-эксперимент с кодовым названием x (читается «икс», не путать с DirectX, X11, OS X, XProger и «маленьким хэ»). В этой теме будет девлог с прогрессом, мыслями и, чем чёрт не шутит, может быть даже скриншотами.

Длинно:

Уже более полугода страдаю от проблемы, которую называю «ловушка движкописательства». Она заключается в том, что участвуя в джеме, вместо того, чтобы делать собственно игру (геймплей, графику, звуки, эффекты), я погружаюсь в допиливание движка-фреймворка (DEng): меняю API, что-то переписываю, читаю увлекательный Vulkan Specification и прочее. Из-за этого я уже в нескольких джемах (например, в Ludum Dare) ничего даже не сдавал.

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

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

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

x - это эксперимент по созданию максимально простой в использовании библиотеки-надстройки для быстрого прототипирования игр с возможностью в дальнейшем переписать отдельные критически важные части по-нормальному на основном движке или другой надстройке. Эксперимент может быть заброшен на полпути, выполнен частично или объявлен проваленным, но вообще очень хочу довести до рабочего состояния. У меня есть несколько идей, которые я хочу опробовать (в дальнейших постах расскажу о них), и пока непонятно какие из них реально удастся осуществить. План: к концу недели сделать простенькую технодемку (список, возможно, поменяется):
* Уровень с хождением по нему
* Меню настройки управления с сохранением между запусками
* Несколько различных материалов
* Динамическое освещение и тени
* Скелетная анимация
* Несколько проходов рендеринга
* Коллизии
* Звуковые эффекты или генерируемый в реалтайме звук
и на основе такой технодемки сделать какие-то выводы о скорости разработки подобной демки с нуля при помощи x, и вообще практичности идей.

Почему движок назван «x»? Я хочу называть все функции с однобуквенным префиксом, и среди всех латинских букв x лучше всего смотрится (xDrawText, xUseShader и т.д.), а для названия движка в целом я перебрал разные варианты (xEngine, ProtoX, JustX и т.д.) и просто x мне понравилось больше всего.

редакция от Doj, 31.01.2022 12:06

Инженер‑космогоник

Опубликовано 01.02.2022 19:06 (3 года назад) #

Удачи
Не пытайся все и сразу, лучше практично и не идеально, но работоспособно.

Опубликовано 02.02.2022 01:24 (3 года назад) #

Спасибо, практичность и работоспособность действительно в приоритете

Опубликовано 08.02.2022 16:11 (3 года назад) #

Уже более полугода страдаю от проблемы, которую называю «ловушка движкописательства». Она заключается в том, что участвуя в джеме, вместо того, чтобы делать собственно игру (геймплей, графику, звуки, эффекты), я погружаюсь в допиливание движка-фреймворка (DEng): меняю API, что-то переписываю, читаю увлекательный Vulkan Specification и прочее. Из-за этого я уже в нескольких джемах (например, в Ludum Dare) ничего даже не сдавал.

В этом же весь кайф. Я так написал DGLEengine и DGLE2 свои ))) Если хочешь делать игру, а не вот это все, то нужно сразу брать готовый движок. Но хочу, сказать, что в итоге, на поздних конкурсах, когда уже движок был в достаточной степени готов, я просто делал на нем игры и радовался победам )

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

Ну, в принципе, да, напрашивается решение сделать что-то под джем, но, я вот на своем движке всегда мог что-то быстро наговнякать, как пример, на гитхабе лежит шутан, написанный за несколько часов тупо plain текстом. Это перед выкладкой в гит я его еще причесал, но как артефакт -- посмотри, как оно может быть, вся игра Main.cpp. https://github.com/megaDRONe86/ClubN69
Интересно, что тебе мешает делать на своем движке так же?
А с другой стороны, если делать тулзы такие же удобные как в коммерческих движках, чтобы мышкой в редакторе накликивать себе игру, то это очень трудоемко и утомительно, я как ни собирался, так и не осилил это.

P.S.
У меня были потуги сделать примерно тоже самое, о чем ты говоришь, что-то убер легковестное и портируемое на все подряд с минимум кода и джентельменским набором фичей, но энтузиазм быстро закончился, так как, с работой, семьей и детьми, уже сложно таким заниматься. https://github.com/megaDRONe86/Anyon

Опубликовано 08.02.2022 21:43 (3 года назад) #

Интересно, что тебе мешает делать на своем движке так же?

Мешают два фактора.

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

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

https://github.com/megaDRONe86/Anyon

404. Видимо, приватный репозиторий.

редакция от Doj, 08.02.2022 22:03

Опубликовано 09.02.2022 09:52 (3 года назад) #

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

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

Второй организационный

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

404. Видимо, приватный репозиторий.

Да, скорее всего.

Опубликовано 14.02.2022 09:46 (3 года назад) #

del

редакция от mv2, 14.02.2022 09:51

Опубликовано 16.02.2022 19:09 (3 года назад) #

Вывод текста - xDrawText

Пользовательская история

Я скачал шрифт и хочу им отобразить Hello world на экране. С чёрной обводкой вокруг, чтобы текст не сливался с фоном. В будущем нужно будет перевести этот текст на русский язык.

Решение

xFont('font.ttf@16 outlined=3').Pos(10, 300).DrawText('Hello World!', []);

По TAB в примере переключается язык. Cлева можно увидеть программу целиком (без самого движка, конечно). В дальнейшем хочу попробовать все программы-примеры укладывать в экран 80x60, не знаю получится ли.

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

Опубликовано 16.02.2022 19:12 (3 года назад) #

Immediate rendering

В приведённом примере я не создаю никаких переменных для шрифта, а сразу же вызываю функцию рисования. В более «правильной» программе потребовалось бы объявить переменную типа TFont, в конструкторе сцены проинициализировать её, указать откуда грузить (из стрима с ассетом), передать опции — это уже 5-7 строк кода. Далее для каждой выводимой строки нужно было бы создать объект типа TTextLine, прибиндить её к шрифту, передать требуемый текст — ещё 6 строк кода. И только после этого вызвать функцию рисования текста. (И ещё не забыть вызвать деструкторы. Но это можно отложить на потом...)

Суммарно получится примерно 30 строк. Всё это нужно для производительности и локальности кода.

Проблемы:
1. Я не хочу писать служебный код и думать о нём при быстром прототипировании игр!
2. 30 строк кода пишутся в 30 раз медленнее, чем 1 строка кода.
3. Получившийся код будет размазан в 3-4 местах в программе (а именно: объявление переменных в классе, инициализация шрифта, инициализация строчки текста, собственно вывод текста, ах да ещё деструкторы) — это для меня ещё бо́льшая проблема даже, чем пункт 2, т.к. вынуждает скакать по программе.

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

Шрифты отлично вписываются в Immediate подход: их мало (едва ли больше 10) и они живут всё время работы программы, т.е. не нужно делать сложных эвристик для их менеджмента. Гораздо интереснее получится ли у меня провернуть нечто похожее с моделями, шейдерами, Frame Buffer'ами и прочим. Узнаем в последующие дни.

редакция от Doj, 16.02.2022 19:12

Опубликовано 16.02.2022 19:14 (3 года назад) #

Кодировка - UTF-8

Только UTF-8. Всегда и везде. Никаких однобайтовых кодировок. Никаких UTF-16 LE/BE. И уж тем более никаких WideChar.

Опубликовано 16.02.2022 19:19 (3 года назад) #

Переводы на другие языки - xLocalize

Пришло время поддержать Hello World не только на английском, но и на других языках:

xFont('font.ttf').Pos(10, 300).DrawText('hello_world', []);

Код настолько мало поменялся, что можно даже и не сразу заметить в чём именно. На самом деле это очень скучный пример. Рассмотрим более интересный: нужно локализовать строку «Съешь X мягких французских булок, да выпей Y чаёв.» (он есть на видео выше):

Buns := 3;

Teas := 1;

xFont('font.ttf').Pos(10, 300).DrawText('font.ttf', 'eat_buns_drink_teas', [Buns, Teas]);

Главное, что нужно понять: перевод — это функция. Функции для перевода у меня пишутся на Lua в отдельных файлах. Нужно в ассетах игры создать файл `ru_RU.lua`, который будет переводить строки на русский язык с примерно таким содержанием:

function hello_world()

  return "Привет, мир!"

end



local function plural(n)

    -- Эта функция возвращает форму множественности числа для числительного n

    -- В русском языке 3 формы множественности, так что функция возвращает 0..2



    local mod = math.fmod

    if mod(n, 10) == 1 and mod(n, 100) ~= 11 then

        return 0    -- единственное: "1 баг", "101 баг"

    elseif mod(n, 10) >= 2 and mod(n, 10) <= 4

      and (mod(n, 100) < 10 or mod(n, 100) >= 20)

      then

        return 1    -- "2 бага", "23 бага", "104 бага"

    else

        return 2    -- "5 багов", "11 багов", "12 багов"

    end

end



function eat_buns_drink_teas(buns, teas)

  local eat_buns = ""

  local separator = ", да "

  local drink_teas = ""

	

  if buns == 0 then

    eat_buns = "Не ешь булок"

    separator = ", только "

  elseif buns == 1 then

    eat_buns = "Съешь эту мягкую французскую булку"

  elseif buns == 2 then

    eat_buns = "Съешь ещё две мягких французских булки"

  elseif buns == 3 then

    eat_buns = "Съешь ещё три мягких французских булки"

  elseif buns == 4 then

     eat_buns = "Съешь ещё четыре мягких фарнцузских булки"

  elseif buns == 5 then

     eat_buns = "Съешь ещё пять мягких французских булок"

  else

     eat_buns = "Локализуй меня, французскую булочку, полностью"

  end

	

  local form = plural(teas)

  if teas == 0 then

    drink_teas = "чая не пей."

    if buns == 0 then

      separator = ", и "

    else

      separator = ", но "

    end

  elseif teas == 1 then

    drink_teas = "выпей чаю."

  elseif form == 0 then

    drink_teas = "выпей " .. teas .. " чай."

  elseif form == 1 then

    drink_teas = "выпей " .. teas .. " чая."

  else -- form == 2

    drink_teas = "выпей " .. teas .. " чаёв."

  end

		

  return eat_buns .. separator .. drink_teas

end

Думаю, идея этого скрипта ясна. Для перевода предназначена функция `xLocalize`: например, `xLocalize('eat_buns_drink_teas', [4, 5])` приведёт к вызову `eat_buns_drink_teas(4, 5)` в скрипте.

Движок `x`
1. при старте программы ищет в ассетах игры файлы вида `ru_RU.lua`, `en_US.lua`, `en_GB.lua`, `tlh_TLH.lua` и т.д. — таким образом формируется список доступных переводов
2. запрашивает у ОС (винды) текущую культуру (локаль), в моём случае получает `ru_RU` и выбирает `ru_RU.lua` как наиболее подходящий скрипт-переводчик. Может быть переопределено настройками.
3. перенаправляет все вызовы `xLocalize` в скрипт
4. если в текущей культуре нет определённого перевода, выведет в лог сообщение о недостаче, и в качестве Fall back'а запросит перевод у скрипта иерархически выше, например, у `en_US.lua`

Т.к. основное использование `xLocalize` — рендеринг текста для игрока, я решил сразу встроить её в `xDrawText`. Следующие две строки делают (почти) одно и то же:

xFont('font.ttf').DrawText(xLocalize('eat_buns_drink_teas', [Buns, Teas]), []);

xFont('font.ttf').DrawText('eat_buns_drink_teas', [Buns, Teas]);

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

На этом поддержка переводов текстов завершена. Осталось только надыбать переводы для самых типичных фраз в играх ("Новая игра", "Сохраниться", "Гейм овер", "ЛКМ", "Добро пожаловать в подводный уровень" и т.д.). Интересно есть ли где-то подобные переводы со свободной лицензией.

редакция от Doj, 16.02.2022 19:42

Опубликовано 16.02.2022 20:16 (3 года назад) #

Fluent Context

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

xDrawText(Eng.Width / 2, 50, 'hello_world', [],

          Font='font.ttf',

          Color='F90716',

          Angle=pi/4,

          Align='center');

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

xFont('font.ttf');

xColor('F90716');

xAngle(pi/4);

xAlign('center');

xDrawText(Eng.Width / 2, 50, 'hello_world', []);

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

xFont('default');

xColor($ffffffff);

xAngle(0);

xAlign('');

Это увеличивает размер кода в два раза. Кроме того, возможны ошибки, когда забыл что-то занулить.

Бороться с этим можно при помощи доп. функций xPush/xPop, xReset, автоматическим занулением переменных после их использования.

Я придумал нечто по-интереснее.

Fluent Context

Идея заключается в создании некоторого временного объекта TxContext, в который цепочкой методов (так называемый Fluent Interface) передаём нужные параметры, и дальше вызываем DrawText. Структура самоуничтожится в конце и не испортит глобальные переменные:

xPos(10, 300)

.AutoMove('down')

.Font('ZenKurenaido-Regular.ttf@20')

.DrawText('hello_world', [])

.DrawText('Language: ' + xLocalize('Language_name', []), [])

.DrawText('Time: ' + IntToStr(xMs) + 'ms', [])

.DrawText('FPS:  ' + IntToStr(xFPS), [])

.DrawText('eat_buns_drink_teas', [Buns, Teas]);

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

xFont('ZenKurenaido-Regular.ttf@20')

.ToGlobal; // сохраняем локальный контекст в xGlobalContext

  

// дальше шрифт можно явно не указывать

  

xPos(10, 300)

.AutoMove('down')

.DrawText('hello_world', [])

.DrawText('Language: ' + xLocalize('Language_name', []), [])

.DrawText('Time: ' + IntToStr(xMs) + 'ms', [])

.DrawText('FPS:  ' + IntToStr(xFPS), [])

.DrawText('eat_buns_drink_teas', [Buns, Teas]);

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

На сегодня пока всё, к тому же я упёрся в лимит сообщений на сайте. Далее уже буду переходить на 3д.

редакция от Doj, 16.02.2022 20:22

Опубликовано 17.02.2022 07:06 (3 года назад) #

Doj, в каком нить xFont("font@16") нет ничего плохого(только если это не конструктор), если под капотом он оперирует с хэшсетом, а не каждый раз ищет по строке хэндл шрифта с таким названием :). Но это в любом случае не особо эффективно.

Скажу свою точку зрения на этот счет:
Дрон под движкопейсательством понимает выдрачивание архитектуры, всяких абстракций, паттернов(вот как у тебя с xFont'ом return this), в таком случае это бесполезная хуйня, особенно если ты занимаешься этим из года в год. Но вот если движок делается ПАРАЛЛЕЛЬНО с игрой, то это очень даже ничего, потому что реализовывается минимальный сет необходимых функций, и его можно применить ещё где то.

Ну и глянуть какой нить DGLE1 - код под капотом говно, но наружу он экспортирует сравнительно приятный и простой интерфейс без выебонов, поэтому на нем игрушки делать легко и приятно было. И поэтому же взлетела псевдоприставка "PICO-8"

Вот например на куонкурс я пилил движок параллельно с игрой - принцип KISS, но с заделом на будущее. Исхи в комплект положил.

https://disk.yandex.ru/d/m2yemH3wx04NfQ

редакция от mv2, 17.02.2022 07:08

Опубликовано 17.02.2022 07:08 (3 года назад) #

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

редакция от mv2, 17.02.2022 07:09

Опубликовано 17.02.2022 09:42 (3 года назад) #

если под капотом он оперирует с хэшсетом, а не каждый раз ищет по строке хэндл шрифта с таким названием :). Но это в любом случае не особо эффективно.

Да, там хэштаблица (о чём я упоминал при описании Immediate rendering). Для прототипирования на конкурс это достаточно эффективно.

Дрон под движкопейсательством понимает выдрачивание архитектуры, всяких абстракций, паттернов(вот как у тебя с xFont'ом return this), в таком случае это бесполезная хуйня, особенно если ты занимаешься этим из года в год. Но вот если движок делается ПАРАЛЛЕЛЬНО с игрой, то это очень даже ничего, потому что реализовывается минимальный сет необходимых функций, и его можно применить ещё где то.

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

Вот например на куонкурс я пилил движок параллельно с игрой

А сама игра где? :)

Опубликовано 17.02.2022 10:53 (3 года назад) #

Ну раз тебя опыт других ничему не учит - пожалуйста, ебашь) Вон дрон когда то запилил дгле2, у него все торчало наружу - не было нормального ресурс менеджера, юниформы шейдеров тоже торчали наружу, - но на этом вроде и поезда сделали, и еще какие то игрушки были. Потом он переписал движок шоб было заебись, по итогу дальше ффп света и отрисовки треугольников не продвинулся. На гдру тоже мемные персонажи есть - варзис какой нить, тот тоже кроме пары моделек ничего не сделал за 6 лет.
Из моего примера - пилил движок года полтора назад с высоким уровнем абстракции, и сценграф туда крутой ебанул, и аниматоры, и кастомные рендер-пайплайны как в юнети, и мультирендер, и по итогу оно превратилось в кашу которую заморочно поддерживать) В нормальном энтерпрайс софте идут к УПРОЩЕНИЮ, а ты идешь к УСЛОЖНЕНИЮ))

Лучше не совсем аккуратно, но что-то релизнуть, чем вылизывать до дедовского маразма движок и ничего по концовке не сделать))

А сама игра где? :)

Ну основа шутана там как видишь есть :) У тебя же пока нихуя нет кроме хотелки сделать движок - а для чего хуй его знает))

редакция от mv2, 17.02.2022 10:57

Опубликовано 17.02.2022 14:16 (3 года назад) #

У тебя же пока нихуя нет кроме хотелки сделать движок

Неправда. Зайди в мой профиль, там 11 проектов на самописных движках (среди которых есть и DEng, и его предшественники). Также в профиле не учтён 170ый двухчасовой джем, на который я тоже делал игру на DEng'е. И это только на этом сайте.

Лучше не совсем аккуратно, но что-то релизнуть

Покажи какие игры ты релизнул. Практика -- лучшее подтверждение теории.

Опубликовано 18.02.2022 09:54 (3 года назад) #

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

Кстати, чтоб не было не нужных вопросов - шутан буду переписывать с нуля на делфях скорее всего вместе с двиглом, он дико тормозит на старом селероне и gf4mx. Упор идет в цпу скорее всего из независящих от меня причин(возможно тормозит GC, хотя аллоков в апдейте по минимуму, возможно JIT не работает на слишком старом проце). Оптимизация для старых видях - один из своеобразных челленджей, помогает мотивацией.

редакция от mv2, 18.02.2022 09:57

Опубликовано 18.02.2022 11:04 (3 года назад) #

Как видишь, стараюсь замахиваться на рыбу покрупнее.

Замахи -- моё почтение :)

Кстати, чтоб не было не нужных вопросов - шутан буду переписывать с нуля

А я считаю это очень правильным вопросом, и я не перестану его задавать. Ты мне даёшь советы: волшебный принцип KISS, который якобы решит все проблемы; забить на архитектуру; релизить что есть.

И я спрашиваю: тебя-то к чему эти советы привели? Почему потерял контроль над _собственным_ движком и выкидываешь то, что выше называл заделом на будущее и приводил в пример в качестве успеха, в мусорку? Где релизы?

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

редакция от Doj, 18.02.2022 11:23

Опубликовано 18.02.2022 13:09 (3 года назад) #

Doj написал:

Как видишь, стараюсь замахиваться на рыбу покрупнее.

Замахи -- моё почтение :)

Кстати, чтоб не было не нужных вопросов - шутан буду переписывать с нуля

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

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

Если всё равно не совсем понял - один из челленджей заставить классическую игру работать на классическом железе(иначе в чем смысл?), а я упёрся в ограничения .NET. Там опять же, либо JIT вообще не работает(проц не держит SSE2 толком, а игра таргетится на .NET 4 и ниже просто так не сменить), либо GC очень тормозит игру первые несколько минут(если пробовал играть в майнкрафт на железе уровне Pentium 4 в свое время - то поймешь, из-за отсутствия даже гипертрединга GC работает на одном ядре с игрой и отжирает все процессорное время).

Страница 1 из 3

Перейти на форум:

Конкурсы

Открытые конкурсы:

Активных нет

Недавние конкурсы:

Случайная игра

Мини-чат

Вам необходимо залогиниться.

Архив чата