|
|
|
|
Канал Игры Мечты: «Архитектура Игры» |
|
|
|
Jurec
 348 EGP
  
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
   |
|
я думаю позно, т.к. переучиватся не собираюсь. Да, может скорость в обмен на проблемы с ООП (особенно с метаклассами) и невразумительный синтаксис (}{& - ужос! begin end как-то роднее) не по мне. Но это не холивар, спокойней. Я понимаю С++, хоть и туго.
Так не оффтопим (эт я больше себе) - все на штурм клавы 
_________________
MOV topka, C++ |
|
|
|
AlexD
 383 EGP
Рейтинг канала: 2(10)
Репутация: 82
Сообщения: 1084
Откуда: Тюмень, Россия
Зарегистрирован: 25.04.2003
|
|
Эх блин... как же ты не вовремя.  С годик-полгодика назад я бы так засел за клаву.... Ие-е-е-е-х... 
А сейчас, блин, своя компания, только набираем обороты, работы не в проворот...  С одной стороны хорош, что все не стоит колом, с другой стороны - на хобби не хватает времени...
_________________
тетрагидрометаноптерина макарена
метилентетрагидрофолата макарена
ЭЭЭЭЭ МАКАРЕНА |
|
|
|
TpuCTaH
63 EGP
Рейтинг канала: 1(4)
Репутация: 8
Сообщения: 128
Откуда: Харьков
Зарегистрирован: 12.06.2006
|
|
Есть интересная система.
Есть базовый класс приложения назовем эго базовое состоЯние.
Стартовый екран - состоЯние
полет корабля - состоЯние
внутринности корабля - состояние
...
все состояния наследються от базового.
базовый содержит стек из обектов подчиненых класов
Верхний элемент стека ЯвлЯеться активным
в какомто состоянии space_fly описываеться ,например, при нажатии "P"
срабатывает метод который создает состояние pause и заносит эго в стек тем самым становясь активным а space_fly смещаеться ниже.
из паузы вызвали состояние настройки он сменил паузу став ативным
нажали отмена в настройках он себя вытащил из стека и убил пауза стала активной. нажали кнопочку вернуться в игру, пауза вытащила себя из стека и ликвидировалась. space_fly снова активен лити куда хочеш.
Гдето примерно так, хотя обяснить мне сложно есть документация но она на англицком
_________________
Если вы считаете, что C++ труден, попытайтесь выучить английский.(с)Bjarne Stroustrup
С++&&DirectX |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
в каком-то смысле игра действительно представляет собой машину состояний, это удобно на макроуровне, т.е. когда прога оперирует целыми подсистемами, вот щаз типа работает модуль "физика", значит у проги состояние "работаю физику"
но сильно увлекаться этим я б не советовал, потому как на "микроуровне", скажем в модуле ИИ машина состояний ничуть не лучше тупого скрипта, на одинаковые действия игрока, машина реагирует одинаково
это удобно для отлова багов, но играть в это уже не очень интересно
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
вот, по теме
Проектирование и архитектура игр
примерная цитата оттуда:
| Цитата: |
|
игра - это база данных реального времени с красивым интерфейсом
|
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Sh.Tac. : |
|
игра - это база данных реального времени с красивым интерфейсом
|
хе, ну если бы так всё просто было...
Так можно сказать, наверно только про ММОРПГ.. Да и то потому что там таки база данных используеться  . В остальном - всё не так.
Ну или под "красивым интерфейсом" имеется ввиду 99% игры. Взять хотя бы физ. движок - при чем тут база данных? Да не при чем.
_________________
MOV topka, C++ |
|
|
|
Protectorat
70 EGP
Рейтинг канала: 1(1)
Репутация: 15
Сообщения: 170
Откуда: Москва
Зарегистрирован: 13.10.2006
|
|
| Jurec : |
| Sh.Tac. : |
|
игра - это база данных реального времени с красивым интерфейсом
|
хе, ну если бы так всё просто было...
Так можно сказать, наверно только про ММОРПГ.. Да и то потому что там таки база данных используеться . В остальном - всё не так.
Ну или под "красивым интерфейсом" имеется ввиду 99% игры. Взять хотя бы физ. движок - при чем тут база данных? Да не при чем.
|
Ну если рассматривать в качестве примера data-driven архитектуру движка, то это как раз и получается база данных реального времени. А такие мелочи, как физический движок, здесь уже можно не принимать во внимание - всего лишь одна из "процедур", которая тоже выдает какие-то выходные данные, прежде обработав входные.
P.S. А красивым интерфейсом в данном случае выступают графический и звуковой движки.
P.P.S. Которые, кстати, тоже могут быть "маленькими базами данных", т.е. иметь data-driven архитектуру.
|
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Protectorat : |
|
Ну если рассматривать в качестве примера data-driven архитектуру движка, то это как раз и получается база данных реального времени.
|
Не База Данных. Ну малость не в том смыле. Это будет(и должен быть) менеджер данных... Ну в принципе, с некоторой натяжкой можно назвать базой данных, но..
Я к тому что нельзя говорить, что это "база данных". Ведь в этой "базе" происходят нехилые взаимодействия, всё постоянно меняеться.
Почему физ. движок - мелочь? Игровой движок, тогда - тоже всего лишь процедура? А что остаеться? А остаються просто структуры хранения данных. Впринципе - база данных. Т.е. сам движок не входит в определение "база данных реального времени с красивым интерфейсом".
З.Ы. Вообще перечитал всё... Ну впринципе, тут особо спорить то и не очем - в общем оба правы, каждый в своём..
_________________
MOV topka, C++ |
|
|
|
Protectorat
70 EGP
Рейтинг канала: 1(1)
Репутация: 15
Сообщения: 170
Откуда: Москва
Зарегистрирован: 13.10.2006
|
|
Не просто база данных, но СУБД. Возьмем к примеру СУБД типа Oracle. Такие СУБД включают в себя не только таблицы данных, но процедуры для работы с ними, которые можно добавлять и дописывать. Там тоже есть классы, методы. В принципе, на таких СУБД можно запросто написать игру (правда, пошаговую, из-за невысокой скорости работы), поэтому в книге и говорится об игре, как о "БД в РВ".
Я принимал участие в проектах, двжики которых с самого начала проектировались как data-driven, так что могу подробнее рассказать, если интересно. Правда, педагог из меня никакой, расскажу, как сумею
|
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Protectorat : |
|
Я принимал участие в проектах, двжики которых с самого начала проектировались как data-driven, так что могу подробнее рассказать, если интересно.
|
О! Напиши урок! А что? Неплохо бы было 
_________________
MOV topka, C++ |
|
|
|
Protectorat
70 EGP
Рейтинг канала: 1(1)
Репутация: 15
Сообщения: 170
Откуда: Москва
Зарегистрирован: 13.10.2006
|
|
| Jurec : |
| Protectorat : |
|
Я принимал участие в проектах, двжики которых с самого начала проектировались как data-driven, так что могу подробнее рассказать, если интересно.
|
О! Напиши урок! А что? Неплохо бы было
|
Урок написать не смогу - времени на это нет, к сожалению. Могу в форуме немного написать, что и как.
|
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Protectorat : |
|
Могу в форуме немного написать, что и как
|
Давай.
_________________
MOV topka, C++ |
|
|
|
Crimson
560 EGP
 
Рейтинг канала: 4(83)
Репутация: 130
Сообщения: 3041
Зарегистрирован: 03.09.2003
|
|
| Jurec : |
|
вот, aruslan, наверно, слишком крутой Гуру гамедёва, чтобы быть понятным для нас - простых смертных.
|
Он описывает всего лишь то, что архитектура проекта зависит в первую очередь от самого проекта. Там в самом начале сказано
| [00:23] <aruslan> : |
|
Петпрожекты не требуют мощных сложных комплексов паттернов. Это будет для них overkill.
|
В большом проекте движок затачивается под менеджмент команды людей. Это разделение кода на модули, которые можно разрулить по разным программерам - каждый из которых не должен разбираться в чужих модулях. Это разделение кода на модули, которые смогут тестировать тестеры.
Это дружественность движка к сценаристам, дизайнерам и прочим товарищам, которые вообще не будут разбираться в тонкостях его работы - для моделлера движок это просто программа в которой можно рендерить его модель. Соответсвенно движок должен сам импортировать модель или сам говорить моделлеру чего в модели не хватает для ее загрузки - дизайнер не будет сидеть с дебаггером и выяснять что движок валится если не находит какую-то текстуру.
Это попытка сделать движок достаточно гибким в тех местах, где может понадобиться доработка напильником, возможность добавить фичу по возможности малой кровью - и возможность убирать фичу так чтобы не угробить стабильность проекта. Естественно не любую фичу можно так вставить или убрать.
Архитектуры это просто общие правила, следуя которым пытаются найти компромиссы и избежать проблем. Рефакториг будет и так и так - если пытаться спланировать все сразу то его будет еще больше чем если делать все постепенно. Но если не планировать вообще, ничего хорошего тоже не получится.
Если ты делаешь игру в одиночку для себя - тебя вообще не должны волновать эти заморочки. Они для тебя лишние. Если ты собираешься писать коммерческий движок - посмотри как можно больше уже готовых. На то чтобы дойти до всего самостоятельно надо два пожизненных срока.
|
|
|
|
Launcher
|
|
| Crimson : |
Соответсвенно движок должен сам импортировать модель или сам говорить моделлеру чего в модели не хватает для ее загрузки - дизайнер не будет сидеть с дебаггером и выяснять что движок валится если не находит какую-то текстуру.
|
Нонсенс. Движок может только использовать модель или модифицировать ее в своем теле, но никогда моделлеры и дизайнеры не создают свои объекты в движке. Для дизайна и моделлинга используются всем известные пакеты типа 3дс, майя, фотошоп. Если движок не может воспринимать форматы этих пакетов, разработчики пишут конверторы или тулсет(собственно с которым уже работают сценаристы, мапперы и т.д и т.п.).
|
|
|
|
Crimson
560 EGP
Рейтинг канала: 4(83)
Репутация: 130
Сообщения: 3041
Зарегистрирован: 03.09.2003
|
|
Сам ты нонсенс
Я не предлагаю встраивать в движок редактор мешей. Я просто говорю о том, что если движок не может загрузить модель (что-то не то с геометрией, или там текстуру забыли куда надо положить) - он должен вежливо ругнуться по этому поводу, а не молча упасть где стоял.
|
|
|
|
Vitaliy
55 EGP
Репутация: 10
Сообщения: 43
Зарегистрирован: 04.02.2007
|
|
Я бы сделал так: создаём класс "обладатель модели" - содержит только модель и текстуры для прорисовки объекта. От него наследуем класс "космический объект" - имеет параметры скорости, размера (физическая модель), масса и тд. От этого класса наследуем класс "корабли" - тут мы добавляем специфические свойства кораблей - ускорение, ссылки на объекты оборудования и тд.
В общем программу нужно структурировать, структурировать и ещё раз структурировать.
|
|
|
|
Protectorat
70 EGP
Рейтинг канала: 1(1)
Репутация: 15
Сообщения: 170
Откуда: Москва
Зарегистрирован: 13.10.2006
|
|
| Vitaliy : |
|
Я бы сделал так: создаём класс "обладатель модели" - содержит только модель и текстуры для прорисовки объекта. От него наследуем класс "космический объект" - имеет параметры скорости, размера (физическая модель), масса и тд. От этого класса наследуем класс "корабли" - тут мы добавляем специфические свойства кораблей - ускорение, ссылки на объекты оборудования и тд.
|
Практически такая-же система используется в "PROTECTOR космическая боевая платформа" ( http://www.elite-games.ru/conference/viewtopic.php?t=38103 ) для кораблей
Должен заметить, не самый лучший вариант, но тоже имеет право на жизнь
|
|
|
|
Vitaliy
55 EGP
Репутация: 10
Сообщения: 43
Зарегистрирован: 04.02.2007
|
|
2Protectorat
Схема наследования - довольно неплохой метод (если представлять все космические объекты объектами в памяти, а не массивами данных). Не знаю как на счёт других языков и сред разработки, а в C# (.NET платформа) - первый вариант на много удобней и не менее скоростной, чем второй.
PS вышеописанная объектная модель - это чистая и непродуманная импровизация. Так что, естественно, есть варианты по-лучше.
|
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Архитектура Игры» |
|
|
