Решил заняться движкописанием и на этот раз серьёзно, вынеся всю игровую логику за его пределы.

Игра подключается так: создаётся игровой объект, например game, который содержит всю игровую механику и объекты. Скажем game.object, game.play, game.res..

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

Пока я нацелен иметь дело только с 2d, но как только отполирую все аспекты, возможно, займусь webgl.

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

engine.game = game;

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

game.object // должен быть хотя бы один игровой объект, например, кнопка

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

engine.create.button = {
action: action(), //действие кнопки
color: '#000',
position: {x: 100, y: 100},
size: {height: 10, width: 100}
text: '',
texture: 'game.res.img.button_run'
}

Абсолютно каждый элемент не обязателен, можно создать кнопку просто командой engine.create.button - при этом по умолчанию на экране появится кнопка в центре экрана с напдисью Button.

Самое интересное, что game.objects может содержать в себе список объектов, которые предстоит создавать, поэтому игрок может легко создать свои элементы управления.

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

game.object.player: {
attack: function(target) {
target.hp.current -= this.damage;
},

damage: 1,

hp: {current: 100, max: 100}
}

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

Скажем, в обычном случае нам бы пришлось делать что-то вроде

window.onkeydown = ..//сюда писать функцию, получать кейкод и прочий гемор, в итоге бы получился огромный список разнообразных действий, плохо структурируемый.

Мой движок позволяет обрабатывать события прямо внутри методов объектов.

player: {
attack: function(target) {
target.hp.current -= (engine.event.keydown == 'space') ? this.damage : 0;
}
}

Всё, движок заполнит engine.event.keydown во время события onkeydown нужной клавишей и если нажат не пробел вернёт undefined и выполнится вторая часть выражения.

И когда я говорил, что оптимизировал логику я в том числе имел ввиду подобные выражения, даже если отбитый ебанат и решили захуячить
target.hp.current -= (engine.event.keydown == 'space') ? 1 : 0;
target.hp.current -= (engine.event.keydown == 'space') ? 2 : 0;
target.hp.current -= (engine.event.keydown == 'space') ? 3 : 0;
target.hp.current -= (engine.event.keydown == 'space') ? 4 : 0;

вместо

if (engine.event.keydown == 'space') {
target.hp.current -= 1;
target.hp.current -= 2;
target.hp.current -= 3;
target.hp.current -= 4;
}

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

Например, в очереди попалось 6 одновременных присваиваний какому-то игровому объекту одного значения (не операция изменения, а именно присваивания), движок ещё во время формирования прослушивателей сократит число проверок до 1, что крайне позитивно сказывается на занимаемом процессорном времени.

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

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

Так вот как лучше всего расположить 4 пункта. Уверен я только в самом первом, а именно input. Причём я пока точно не знаю, может быть стоит первыми поставить отрисовку и звук, так как это самые медленные операции и если они начнутся выполняться сразу, я стараюсь писать неблокирующий код, то есть музыка не прерывает update или ввод, то есть по большому счёту неважно как они стоят, музыка не заиграет, пока не наступит нужное событие (сменится уровень или произойдёт какое-то действие, скажем в той же атаке будет

player {
attack: {
engine.play = game.res.audio.hit;
}
}

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

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

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

Как делать правильно, начать проигрывать (ололо) аудио и после отрисовывать или сначала отрисовать и после начать озвучку. Вот этот вопрос для меня ключевой с точки зрения производительности.

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

С другой стороны, когда на сцене около 50 источников звука, одновременное проигрывание audio несколько замедляет вывод графики. Я бы мог просто сравнивать счётчик отрисовок с количеством аудиоисточников, но не знаю куда внедрить эту проверку, так как цикл run это вершина айсберга (выше только Аллах).

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