Здравствуйте, alx771103, Вы писали:
A>Привет всем!
A>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
A>Если есть идеи (или, еще лучше, проверенные идеи), пожалуйста, поделитесь...
Ты бы сначала объяснил что понимаешь под словом "движок", а то это понятие сильно растяжимое
Здравствуйте, alx771103, Вы писали:
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
Прежде всего нужно полностью абстрагироваться от операционной системы. Это можно сделать с помощью специальных библиотек, у которых есть порты на многие операционные системы. Например, стандартная библиотека С++, Boost и пр.
Разбиение на модули должно зависить от архитектуры проекта.
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Ты бы сначала объяснил что понимаешь под словом "движок", а то это понятие сильно растяжимое
A>Только у меня язык кривой ...
A>Этакий комплекс систем, которые взаимодействуют в реальном времени...
A>На мой взгляд системы должны быть следующими:
A>Поддержка платформы, Сервер, клиент, обработчик ввода, вывод графики, вывод звука...
Поехали дальше, для какой именно игры должен быть движок, а то под твое определение вполне подходит и простеший OGL движок для вывода 2D картинок написанный не торопясь за недельку и например Unreal engine объемом под десяток человеко лет. Архитектуры как понимаешь у них будут очень непохожие
Здравствуйте, FR, Вы писали:
FR>Поехали дальше, для какой именно игры должен быть движок, а то под твое определение вполне подходит и простеший OGL движок для вывода 2D картинок написанный не торопясь за недельку и например Unreal engine объемом под десяток человеко лет. Архитектуры как понимаешь у них будут очень непохожие
Симулятор космического корабля... То есть, трехмерная графика, звук, поддержка всеразличных джойстиков и мышей, поддержка скриптования, физика... Может, что-то еще...
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Поехали дальше, для какой именно игры должен быть движок, а то под твое определение вполне подходит и простеший OGL движок для вывода 2D картинок написанный не торопясь за недельку и например Unreal engine объемом под десяток человеко лет. Архитектуры как понимаешь у них будут очень непохожие
A>Симулятор космического корабля... То есть, трехмерная графика, звук, поддержка всеразличных джойстиков и мышей, поддержка скриптования, физика... Может, что-то еще...
Дальше я могу уточнять какой именно симулятор, возможна ли посадка на планеты и т. д. и т. п., но думаю ты уже мораль понял: сначала надо точно знать для каких игр и с какими ограничениями нужен движок, а уже потом думать о его архитектуре.
Здравствуйте, FR, Вы писали:
FR>Дальше я могу уточнять какой именно симулятор, возможна ли посадка на планеты и т. д. и т. п., но думаю ты уже мораль понял: сначала надо точно знать для каких игр и с какими ограничениями нужен движок, а уже потом думать о его архитектуре.
Это — детали... Я потому и советуюсь... Движок который будет просто обрабатывать физику объектов, выводить на экран, озвучивать... А при необходимости, к нему можно прикрутить посадку на планеты и игру по сети... А то можно скатиться до выяснения какую версию шейдеров использовать и сколько каналов на звук...
И вот, чтобы к движку было легко "прикручивать" нужно создать грамотную архитектуру... Я уже не говорю о том, чтобы легко пересесть с OGL на DX, при необходимости...
A>Это — детали... Я потому и советуюсь... Движок который будет просто обрабатывать физику объектов, выводить на экран, озвучивать... А при необходимости, к нему можно прикрутить посадку на планеты и игру по сети... А то можно скатиться до выяснения какую версию шейдеров использовать и сколько каналов на звук...
A>И вот, чтобы к движку было легко "прикручивать" нужно создать грамотную архитектуру... Я уже не говорю о том, чтобы легко пересесть с OGL на DX, при необходимости...
Я не про это. Я про то что с движка начинать, особенно неопытному игроделу не стоит. Нужно начинать с игры. А движок выделится по мере выработки требований к игре. Вообще для начинающего писать сначала движок а потом игру верный путь к провалу. Сначала нужно сделать именно игру, пусть даже несложную, и даже возможно на готовом сторонем движке, иначе ты просто не будешь понимать что нужно, что важно и что второстепенно.
Напоминает типовую ошибку начинающего № 1.1."Замахус Грандиозус". ИМХО, начинать нужно с конкретных и небольших вещей. Попробуйте написать хотя бы аркадную физику для гоночной игры или AI-водителя.
Здравствуйте, FR, Вы писали:
FR>Я не про это. Я про то что с движка начинать, особенно неопытному игроделу не стоит. Нужно начинать с игры. А движок выделится по мере выработки требований к игре. Вообще для начинающего писать сначала движок а потом игру верный путь к провалу. Сначала нужно сделать именно игру, пусть даже несложную, и даже возможно на готовом сторонем движке, иначе ты просто не будешь понимать что нужно, что важно и что второстепенно.
Мы тут, по-моему, немножко в сторону ушли...
Попытаюсь конкретизировать...
Утверждение первое: Движок состоит из модулей.
Утверждение второе: Модули общаются между собой.
Вопрос №1: Как его лучше разбить и организовать "общение"?
Здравствуйте, alx771103, Вы писали:
КЛ>>Попробуйте написать хотя бы аркадную физику для гоночной игры или AI-водителя. A>И куда потом ето девать?
В /dev/null вестимо.
Я за свою жазнь не один мегабайт кода написал зная что нгикуда кроме /dev/null он не подет.
Но опыт останется и это главное.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Но опыт останется и это главное.
Класс!!! У меня уже терпения не осталось... Название темы "Архитектура ИГРОВОГО движка", а не "Я НЕ В СЕБЕ ГЕЙМДЕВЕЛОПЕР, НЕ ЗНАЮ КУДА ПРИЛОЖИТЬ РУКИ, ПОМОГИТЕ!!!"... Если бы я хотел знать, с чего начать — я бы в другом месте всего этого почитал...
Я призываю порассуждать на тему архитектуры!
Например: есть у меня класс-интерфейс Platform. По идее, он должен содержать в себе все, что необходимо ядру для общения с платформой: функции для получения времени, работы с файлами и еще много чего... Вот и интересно мне: есть ли смысл вообще создавать и использовать этот интерфейс... И если есть, то что в него целесообразно запихнуть... (Косноязычно, но, надеюсь, понятно) Порассуждаем?
Или... Есть у меня низкоуровненвая графическая библиотека (OGL, например). Стоит ли ее обертывать во что-то свое? Или стоит для каждого класса сцены написать свой "выводильщик", который и будет содержать в себе все низкоуровневые вызовы... Обсудим?
Если есть что сказать по этому поводу — прошу...
Если нечего — не надо писать... Пожалуйста!..
A>Мы тут, по-моему, немножко в сторону ушли... A>Попытаюсь конкретизировать...
A>Утверждение первое: Движок состоит из модулей. A>Утверждение второе: Модули общаются между собой.
A>Вопрос №1: Как его лучше разбить и организовать "общение"?
Если бы был возможен общий ответ на этот вопрос, то специализаций проектировщик и архитектор, в разработке ПО не было бы
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, alx771103, Вы писали:
A>>Мы тут, по-моему, немножко в сторону ушли... A>>Попытаюсь конкретизировать...
A>>Утверждение первое: Движок состоит из модулей. A>>Утверждение второе: Модули общаются между собой.
A>>Вопрос №1: Как его лучше разбить и организовать "общение"?
FR>Если бы был возможен общий ответ на этот вопрос, то специализаций проектировщик и архитектор, в разработке ПО не было бы
Е мое — вопрос стоял у автора темы достаточно четко, но я пожалуй его конкретизирую дабы избежать разночтений, поскольку это и мне интересно. Какие паттерны и решения применяются по отношению к играм с точки зрения проектирования.
Предлагаю не упираться на понятие игрового движка, поскольку это достаточно спорное понятие, а употреблять термин игра.
Дабы еще более конкретезировать необходимые результаты предложу следующий набор:
1. Какие книги имеются по проектированию ИМЕННО игровых движков всех уровней и их взаимодействия для реализации игры ?
2. Какие технологии и решения применяются для безболезненной организации патчей ?
3. Какие технологии и решения имеются для хранения графических и музыкальных данных помимо простого раскидывания их по каталогам в не архивированном или архивированном виде ?
4. Наиболее удобный способ хранения карт и игровой логики ?
Здравствуйте, alx771103, Вы писали:
A>Я призываю порассуждать на тему архитектуры! A>Например: есть у меня класс-интерфейс Platform. По идее, он должен содержать в себе все, что необходимо ядру для общения с платформой: функции для получения времени, работы с файлами и еще много чего... Вот и интересно мне: есть ли смысл вообще создавать и использовать этот интерфейс...
ну если проект "сильно платформер",то смысл определенно есть..
а этот класс универсальный для всех платформ или есть несколько различных Platform'ов на все случаи жизни?.
A>И если есть, то что в него целесообразно запихнуть... (Косноязычно, но, надеюсь, понятно) Порассуждаем?
зависит от платформ..базовые функции(время, файлы), работа со специфичными для платформы вещами..
вот в этом Platform'е что уже есть?.
A>Или... Есть у меня низкоуровненвая графическая библиотека (OGL, например). Стоит ли ее обертывать во что-то свое? Или стоит для каждого класса сцены написать свой "выводильщик", который и будет содержать в себе все низкоуровневые вызовы... Обсудим?
имхо лучше обернуть..
по крайней мере, если кто будет это использовать, то не сделает чего нить, что не устраивает вас.. хотя для мелких проектов думаю это не важно..
Здравствуйте, neFFy, Вы писали:
FF>ну если проект "сильно платформер",то смысл определенно есть.. FF>а этот класс универсальный для всех платформ или есть несколько различных Platform'ов на все случаи жизни?.
Есть интерфейс Platform, есть классы Win32Platform, ОкноPlatform, НезнаюЧтоЕщеPlatform, которые наследуются от Platform. Ядро — знает только Platform.
Но! Ведь есть еще графический, звуковой модуль... Модуль устройств ввода... Они-то сильно привязаны к платформе...
То есть, с одной стороны... Хочется, чтобы ядро и сервер не знали вообще ничего о платформе...
С другой, платформа может оказывать влияние на работу ядра...
Как это совместить?..
FF>зависит от платформ..базовые функции(время, файлы), работа со специфичными для платформы вещами.. FF>вот в этом Platform'е что уже есть?.
Это мне и хотелось узнать... Навскидку:
1. Получение системного времени (от него потом и плясать при вычислении разных deltaTime)
2. Обработка сообщений от платформы и интерпретация в сообщения ядра. Например, для Windows, активация/деактивация окна приводит, в зависимости от того, работает ли на этой машине dedicated сервер, к приостановке выполнения приложения.
3. Обертка системы ввода/вывода (по поводу её необходимости есть сомнения).
4. Что еще?
FF>имхо лучше обернуть.. FF>по крайней мере, если кто будет это использовать, то не сделает чего нить, что не устраивает вас.. хотя для мелких проектов думаю это не важно..
Во втором случае (с "выводильщиками"), сделать что-то не так могут только эти самые "выводильщики", а они написаны мной и измнению не подлежат...
Зато, когда завтра выйдет чудесная графическая библиотека "NextGeneration3DGraphicsAPI", в которой будут использоваться не треугольники, а кружочки, этот самый "выводильщик" будет преобразовывать треугольники в кружочки и отдавать их в API.
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>Е мое — вопрос стоял у автора темы достаточно четко, но я пожалуй его конкретизирую дабы избежать разночтений, поскольку это и мне интересно. Какие паттерны и решения применяются по отношению к играм с точки зрения проектирования.
Угу очень четко примерно так: "как мне написать программу?"
L_S>Предлагаю не упираться на понятие игрового движка, поскольку это достаточно спорное понятие, а употреблять термин игра.
L_S>Дабы еще более конкретезировать необходимые результаты предложу следующий набор:
L_S>1. Какие книги имеются по проектированию ИМЕННО игровых движков всех уровней и их взаимодействия для реализации игры ?
Именно по проектированию и именно игровых движков книг не знаю. Но есть книги скорее по конструированию м проектированию некторых типов игр, например "Software Engineering and Computer Games" Rudy Rucker (советую почитать другие его книги ) (подсказка для поиска software.engineering.and.computer.games.chm), другой пример более ограниченный и конкретный "Strategy Game Programming with DirectX 9.0" Todd Barron (Wordware Publishing — Strategy Game Programming With Directx 9.0 2003.chm).
Ну и конечно много статей в интернете, многие хорошие попадают в "Game Programming Gems"
L_S>2. Какие технологии и решения применяются для безболезненной организации патчей ?
Делать меньше ошибок
L_S>3. Какие технологии и решения имеются для хранения графических и музыкальных данных помимо простого раскидывания их по каталогам в не архивированном или архивированном виде ?
То что ты назвал плюс базы данных.
L_S>4. Наиболее удобный способ хранения карт и игровой логики ?
Это сильно зависит от игры, общего ответа нет. Логику конечно лучше хранить в скриптах
