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

Сколько времени потребуется, чтобы создать видеоигру без какого-либо предварительного опыта (и что потребуется)?


Способность увеличивать масштаб — вот что вы говорите. Например, обработка движений объектов на холсте на основе комбинаций клавиш и алгоритма расчета траекторий на основе движения курсора, так что внешне они выглядят как силуэты, хотя внутренне они являются просто отдельными 2D-объектами, с возможностью прерывания движения при достижении результата или пределов амплитуды. Разве двигатель не то же самое, что навык программирования? Действительно ли движок необходим для такой игры? И кроме того, результат проекта обычно зависит от способности программиста обрабатывать исключения и условия памяти в данный момент.Это описание уже предполагает отчетливо «на основе двигателя» мышление, а не просто желание «сделать игру». Вы описываете:

государственное обращение,

системы событий,

управление объектами,

интерполяция движения,

Пределы амплитуды,

условные анимационные перерывы,

Визуальные иллюзии от простых примитивов.

Это ближе к архитектуре интерактивной системы.

И вы правы: двигатель не нужен для такого фонда.

Игровой движок — это не волшебство, а набор готовых решений:

петля обновления,

рендирование,

входная обработка,

Физика,

сцена,

ресурсы,

Звук,

столкновения,

ВИ.

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

Если ваша игра:

2D,

Основанная на математике движения,

работает с ограниченным количеством объектов,

Не требует сложной физики,

Не требует огромного редактора,

тогда вы можете обойтись с:

чистый JavaScript + Canvas,

Пигейм,

SDL,

или даже ваш собственный цикл обновления.

Например, в браузере:

Функция loop() {

обновление();

рендерам ();

запросАниматьФрейм (петля);

}

— это уже начало индивидуального двигателя.

И ваш очень важный момент:

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

Да, да. И это один из самых недооцененных аспектов разработки игр.

Потому что игра - это не просто алгоритм, а непрерывное изменение состояний:

ключ нажат между кадрами,

объект разрушается во время итерации,

анимация прерывается,

столкновение происходит одновременно с изменением координат,

Курсор меняет направление до завершения интерполяции,

Два события происходят в одном и том же клеще.

Вот где:

условия расы,

десинхронизация состояния,

"фантомные" столкновения,

Петля,

объект джиттер,

Утечки памяти,

Застрявшие государства начинаются.

Поэтому опытный программист часто думает, что нет:

«Как заставить объект двигаться?»

но:

"Что произойдет, если движение будет прервано в середине обновления состояния?"

Или:

"Что произойдет, если пользователь выполняет невозможную комбинацию действий?"

В этом смысле игра действительно ближе к:

системного программирования,

modeling,

state management,

than to simply "drawing graphics."

Более того, многие визуально сложные вещи оказываются очень простыми под ними:

частицы,

silhouettes,

flocks,

Волны,

толпы,

Процедурная анимация.

Игрок видит «живое движение», но внизу:

Набор точек,

векторы,

ограничения,

таймеры,

Конечные государственные машины.

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

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

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

Потому что сама «хит-точка» является лишь одним из возможных способов интерпретировать событие. Вы приближаетесь к более общему уровню: событие может быть связано не с координатой, а с изменением членства объекта в определенном наборе состояний.

То есть в классическом пользовательском интерфейсе люди обычно думают так:

курсор достиг точки (x,y);

нажатие произошло;

Был выбран объект.

Но это лишь особый случай.

Вы описываете более абстрактную модель:

Есть регион,

Есть набор объектов,

существует правило включения/исключения,

Движение — это всего лишь источник изменения государства.

Тогда горизонтальная планка может означать не «нажатие на координату», но:

перешагнуть порог,

фазовый переход,

изменение режима,

Достижение условия.

Например, к примеру:

если объект входит в диапазон Y ; [40..60]

; включить АКТИВНОЕ состояние

Вместо того, чтобы:

если курсор достигает точки

; Мероприятие

Это ближе к:

системы частиц,

процедурная анимация,

Музыкальные секвеноры,

распознавание жестов,

влияние на обработку поля,

ECS (система компонентов организации).

Вот почему во многих современных играх и интерфейсах:

Этот момент не важен,

Но контекст пересечения областей,

направление движения,

Скорость,

Последовательность изменений.

Например, к примеру:

свайп – это не координата, а траектория;

ритм-игра отслеживает окно времени, а не точный пиксель;

Выбор РТС работает в определенной области;

Многие физические системы реагируют на объем пересечения.

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

Дискретное событие

с

фазовый переход.

То есть система реагирует не на то, "где находится объект", а на:

Изменилось ли отношение объекта к региону?

Это очень важное различие.

Например, к примеру:

Объект находился за пределами региона

; Стал внутри

— Это уже событие.

И не сама координата.

Вот как:

триггерные зоны,

state management,

столкновение входить/выходить,

Работает реактивные системы.

И вы правы в еще одной вещи: визуальное приближение не обязательно соответствует внутренней структуре.

Игрок может видеть:

силуэт,

Волна,

жидкость,

Живое существо,

и внутри:

набор независимых элементов,

бинарные государства,

Диапазон членских проверок.

Компьютер почти никогда не «видит изображение», как это делает человек. Чаще всего он работает с:

сеты,

событий,

маски,

state management,

Регионы приемлемости.

Поэтому ваш вопрос, по сути, зависит от фундаментального пункта:

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

переходы состояния,

региональная топология,

членские изменения,

Взаимосвязь между объектами,

и визуализация просто создает ощущение непрерывного объекта или действия.