Вопросы от людей, которые хотят программировать игры, приходят все чаще, а это значит, что пора писать пост. Не то, чтобы у меня был грандиозный опыт разработки игр, но вполне себе неплохой опыт есть. Ну и толпы желающих помочь новичкам не наблюдается.
Итак, для начала нам надо понять, как именно происходит разработка игр. И познакомиться с общей ситуацией в индустрии...
-Алёна, давай ближе к делу! Лесом ситуацию в индустрии, программить уже давай!
Но мои собеседники, как правило, хотят уже прямо сейчас приступить к написанию кода и слушать всякие занудствования не готовы. Поэтому начнем с конца.
-Я поставил себе Visual C++ 2010? Я все правильно сделал?
Если вы работаетет с Windows, то да, лучше Visual C++ и лучше версию поновее. Про разработку игр под Линукс я не в курсе...
-DirectX или OpenGL?
Это зависит... На Windows в основном используется DirectX. Но это вовсе не значит, что OpenGL никому не нужен. На консолях встречаются графические API, сильно похожие на OpenGL, ну и под Линуксом никакого DirectX нет.
-Так все-таки, DirectX или OpenGL?
Ставьте DirectX. :-)
Только DirectDraw смотреть не нужно, им никто не пользуется.
В DirectX есть очень хорошие хелпы и примеры, не игнорируйте их.
-У меня ничего не работает, ничего не компиляется!
Вы не одиноки. Поищите ваши ошибки Гуглом, наверняка найдете таких же несчастных.
Но будьте готовы к тому, что вы не найдете материалы, где бы вас провели за руку от начала и до конца.
-Да ну, там все по-английски...
Надо учить английский. На русский переведено мало и для работы этого недостаточно.
Как обычно, Google is your friend. Вот что выдает нам поиск по запросу game programming lectures.
Game Programming 2007
CSE 191: Video Game Programming Seminar
Обзор книг по программированию игр я делала здесь. И вот еще открытые исходники игр.
-Правда, что все игры разрабоатываются на С++?
Игры разрабатываются не только на С++. Активно используются также:
Python, Lua - Для скриптования игровых движков. Также для скриптования могут использоваться языки, специфичные для данного движка. Например, UnrealScript.
C# - утилиты. Очень любим, потому что С++ программистам с ним легко разобраться.
C#, Java - серверная часть MMO.
Java - используется на мобильных платформах
HLSL - используется для программирования шейдеров
Знание С++ не то чтобы обязательно, но он в разработке игр используется очень активно и с ним жизнь упрощается.
-Что такое игровой движок? У меня уже есть DirectX. Это что, не движок?
DirectX работает на уровне "нарисовать треугольник". Игровой движок поднимает вас на уровень выше, здесь будут "объект с трехмерной моделью и поведением", "вода" и т.п.
Игровые движки бывают разные. Например, может быть только графический движок, но без физики. Вы тогда можете писать физику сами или подключить какой-нибудь движок физики. Также отдельно может идти AI движок.
Вам не обязательно нужен движок. Для небольшой игры разделение на движок-скриптование зачастую не имеет смысла. Если хочется поменьше разбираться как оно внутри устроено, а хочется чтобы уже была игра, имеет смысл поработать с готовыми бесплатными движками. Также имеет смысл посмотреть их код. Ну и исходники игр.
Примеры бесплатных движков:
OGRE (Altren в комментариях настаивает, что в OGRE только графика и ничего другого там искать не надо), Irrlicht - игровые движки, графика там в основном, насколько я помню
ODE - движок физики
Игра - это не только DirectX, не только графика. Если вас интересует устройство на работу в качестве разработчика игр, то посмотрите вакансии игровых контор, посмотрите чего они хотят и вам станет понятнее чего учить (Epic games, id Software).
Вот примеры специализаций игровых программистов, с описанием чего надо знать по каждой специализации. Это роли могут различаться, всё-таки всё сильно зависит от конкретной платформы и компании.
Graphics programmer - программист графики. Здесь нужно знание математики (векторы, матрицы, кватернионы). Понимание того, как работают видеокарты, шейдеры.
Physics programmer - программист физики. Нужны довольно специфичные знания физики, ну и математика тоже.
AI programmer - программист искусственного интеллекта. Алгоритмы на графах (A*, Дийкстра), конечные автоматы...
Gameplay programmer, game mechanics programmers - программист игровой механики. Эта роль вызывает больше всего непонимания. Это те программисты, которые пишут в игре всё остальное. Изменение параметров при попадании одного юнита в другого, отображение этого всего в интерфейсе, подгрузка следующего уровня. Куча вот таких мелочей.
Interface programmer - разработчик интерфейсов.
Network programmer - сетевой программист. Нужны стандартные знания по разработке сетевого кода.
Tools Programmer - разработчик утилит. При разработке игры используют дополнительные программы, которые иногда пишутся самостоятельно, иногда покупаются вместе с движком. Пример игровой утилиты - редактор уровней.
Также бывают нужны инженеры для поддержка автосборки, программисты аудио, специалисты для работы с базами данных.
Для начала не пытайтесь написать игру с нуля. Модифицируйте чужой код, пишите моды.
Потом напишите небольшую игру от начала и до конца. Графику либо нарисуйте тестовую, либо найдете в интернете, есть сайты где модели раздаются бесплатно под некоммерческие проекты.
-Да, у меня есть отличная идея MMORPG!
Возьмите любую MMORPG, откройте кредитсы и посмотрите на список людей, которые работали над этим проектом. Далеко не все они страдали там фигней, уверяю вас. Разработка MMORPG - многомиллионный проект с количеством людей, несколько больше одного.Для начала напишите паззл небольшой, напишите арканоид.
-Алён, ты что, шутишь?
ОК, пусть это будет RPG, без MMO. Один, маленький уровень, как можно меньше деталей. Попробуйте получить минимальную играбельную версию.
-Алёна, у меня еще куча вопросов!
Постараюсь ответить. Но не могу обещать, что отвечу на все :-).
Ахинею про то, о чем не знаю, писать не буду. Спрашивайте в комментариях.
Ссылки по теме:
AIGameDev
Вопросы по программированию ИИ в играх
Quaternions and spherical trigonometry
3 дня назад
Atom feed
74 коммент.:
В принципе всё как и везде - от простого к сложному :) В качестве компилятора Intel C++ не рекомендуете? А, и ещё есть Bullet Physics для физики, с виду ничего так.
fuwaneko
В качестве компилятора Intel C++ не рекомендуете?
Я не знаю мест, где он используется для разработки игр. То есть, если думать об устройстве на работу, то лучше VC++.
А, и ещё есть Bullet Physics для физики, с виду ничего так.
Слышала положительные отзывы. Не работала.
Жажду почитать про ситуацию в индустрии :)
> Python, Lua - Для скриптования игровых движков. Также для скриптования могут использоваться языки, специфичные для данного движка. Например, UnrealScript.
пайтон активно используется и для разработки самих игр, а для скриптов наверное чаще всего используют lua
> пайтон активно используется и для разработки самих игр
Не то, чтобы очень активно. EVE Online разве что целиком на Python, и то его за это все ругают, мол тормозит и память жрёт. Я правда проблем с ним не замечал. К тому же Python плохо подходит для встраивания. А вот Lua создавалась для этой цели, неудивительно, что её используют в over9000 проектов.
fuwaneko
Не то, чтобы очень активно. EVE Online разве что целиком на Python,
AFAIR, у них сервер на Питоне, клиент на С++.
К тому же Python плохо подходит для встраивания.
BigWorld в качестве скриптового языка использует Питон. Правда, я не знаю, тяжело им было его встраивать или нет.
> Не то, чтобы очень активно. EVE Online разве что целиком на Python, и то его за это все ругают, мол тормозит и память жрёт.
Сайт у них похоже что сделан на asp, хотя это не факт, может и серверная часть работает на пайтоне. Ну в принципе нельзя забывать еще что пайтон язык скриптовый но благодаря компиляции в байт код "на лету" (по аналогу с джавой, если не ошибаюсь) он не уступает другим серверным языкам. Да, и количество библиотек для него поражает, на любой вкус =)
Большинство "гениальных" задумок заваливалось через месяц, после написания каркаса физического движка, всяческих полезных классов и прочего. В основном-из за отсутствия какого либо диз.дока, детального описания игрового движка, всех его подсистем (физики, света и тд).
С чего обычно начинается создание такого описания, на какой глубине детализации оно заканчивается?
Основной цикл игры (void Update(float dt);). Как чаще всего взаимодействуют в нем подсистемы, какие существуют хитрости для обеспечения стабильности fps?
Потоки. Как разработчики (и вы лично, конечно) относятся к многопоточности в играх, Где чаще всего она применяется, какие специфические проблемы может вызвать?
Std, библиотеки Qt и т.д. Используются ли стандартные классы\контейнеры и прочее при создании игр? Какие велосипеды создаются чаще всего? Есть ли какие нибудь советы по увеличению производительности, или тут-все как в обычных приложениях?
Алена, а что Вы думаете об XNA? Вы его даже не упомянули. Насколько он распространен? Как там с производительностью? А то в майкрософт его так нахваливают, так нахваливают...
Алена, я хочу спросить:
1. Как в этой стране обстоит ситуация с игростроем? Буквально в двух словах, при смерти или активно развивается?
2. У меня иногда появляется мысль на секунду, что хорошо было бы устроится в крупную игродельную фирму. Но потом представляю, что мелкому программисту придется заниматься второстепенной работой и это будет не намного увлекательнее чем писать систему для какой-нибудь госорганизации. В общем, что тебе интереснее: делать большую игру крупным коллективом или маленькую в одиночку?
А что можете посоветовать почитать, про проектирование (архитектуру) игр? Просто как-то не очень получается, все хорошо спроектировать. К примеру абстрагировать друг от друга физику, отрисовку объектов и т.п.
И по поводу: "Модифицируйте чужой код, пишите моды."
Какие игры можете посоветовать для этого?
Читаю вас по rss - вспомнил себя 4 года назад, когда сам такие вопросы задавал:) Читал много книг по С++, графике, больше трех лет проработал в области вебдева и вообще с самыми разнообразными проектами. И вот теперь, наконец-то, плюнув на все, вспомнив свою старую мечту, начинаю делать игры в своей крошечной компании (для айфонов).
Так что могу дать совет новичкам - готовьтесь, что сразу "делать игры" может быть и не получится:)
ps. Ваш блог классный, читаю с удовольствием.
Ну в принципе нельзя забывать еще что пайтон язык скриптовый
Питон не скриптовый язык. Уже просто потому, что слово "скриптовый" ничего не означает. Вы наверное имели в виду интерпретируемый. Это, всё же, разные вещи.
но благодаря компиляции в байт код "на лету" (по аналогу с джавой, если не ошибаюсь)
Ошибаетесь. В де-факто стандартном интерпретаторе CPython нет JIT. Есть отдельные разработки PyPy и Unladen Swallow, но они на практике пока ещё не распространены по разным причинам.
он не уступает другим серверным языкам
Что такое "серверные языки"? Код на серверной части можно писать практически на чём угодно. Если говорить о скорости, то Питон далеко не самый быстрый: медленней Java, C#, C++. Его используют за простоту разработки и поддержки там, где его скорости хватает. А хватает её в большинстве случаев, потому что серверный код чаще всего IO bound, а не CPU bound.
Я позволю себе не согласиться насчет компилятора. Все таки самый масовый в геймдеве компилятор на даныый момент - 4-ая серия GCC. Особенно учитывая, что на него уже почти полностью переползла Сонька и что он является основным компилятором под iPhone/Bada/...
> А вот Lua создавалась для этой цели
Для этой цели создавались Squirrel и AngelScript. У Lua были совершенно другие и местами очень русурсоемкие задачи.
> Как разработчики (и вы лично, конечно) относятся к многопоточности в играх
Лично я - положительно. Но сложность системы и ее отладки вырастает в разы. Поэтому поначалу лучше их не трогать
> Какие игры можете посоветовать для этого?
Unreal. На удивление ровная архитектура, не вызавающее желание выйти в окно/убить разработчиков. Найдете много чего полезного. + большое комьнити не оставит в беде
> AFAIR, у них сервер на Питоне, клиент на С++.
Все у них на питоне. Графический движок м.б. на C++, вся клиентская логика, весь гуй - все на питоне. Причем на stackless python.
night rain
Большинство "гениальных" задумок заваливалось через месяц, после написания каркаса физического движка, всяческих полезных классов и прочего. В основном-из за отсутствия какого либо диз.дока, детального описания игрового движка, всех его подсистем (физики, света и тд).
Я не думаю, что из-за диздока. Просто диздок позволяет понять, не теряя много времени, что мы взялись за задачу, которая нам явно не по плечу. Если человек сразу пытается кодить, то это понимание приходит позже и времени теряется больше.
С чего обычно начинается создание такого описания, на какой глубине детализации оно заканчивается?
Жанр, системные требования. Чего будет делать, чего не будем делать (воды не будет, летающих юнитов не будет, лифтов не будет). Дальше детализируем - сколько уровней, какие юниты, какой интерфейс... Тут лучше всего готовый диздок найти и посмотреть. Важна не детализация, важно чтобы люди понимали чего они вообще делать собираются. Детали могут меняться. Диздок продолжают править в течение всего процесса работы.
Основной цикл игры (void Update(float dt);). Как чаще всего взаимодействуют в нем подсистемы,
Ничего себе вопрос. Все сильно зависит от конкретного проекта, в любом случае описание на небольшую книгу получится :-).
какие существуют хитрости для обеспечения стабильности fps?
Так сложилось, что мне не приходилось стабилизировать fps.
Потоки. Как разработчики (и вы лично, конечно) относятся к многопоточности в играх,
Я плохо отношусь, потому что сложность возрастает. В играх сложности и без того хватает.
Где чаще всего она применяется, какие специфические проблемы может вызвать?
Применяется в сетевом коде. На PS3 из-за особенностей архитектуры. Я параллелила системы частиц - они хорошо распараллеливаются.
Std, библиотеки Qt и т.д. Используются ли стандартные классы\контейнеры и прочее при создании игр?
Используется STL, иногда свои аналоги STL, широко известный пример - EASTL. Общей нелюбовью пользуется boost (согласно легендам - медленно), RTTI (по той же причине). Есть случаи отказа от исключений.
Какие велосипеды создаются чаще всего?
Не работала с велосипедистами, к счастью :-)
Есть ли какие нибудь советы по увеличению производительности, или тут-все как в обычных приложениях?
Берем профайлер, находим узкое место, оптимизируем. Повторяем.
Андрей
Все у них на питоне. Графический движок м.б. на C++,
Вы путаетесь в показаниях! :-)
Я с ними общалась некоторое время назад и они были заинтересованы в С++ программистах. В вакансиях у них тоже С++ присутствует. То есть что-то на С++ написано.
Анонимный
Алена, а что Вы думаете об XNA? Вы его даже не упомянули. Насколько он распространен? Как там с производительностью? А то в майкрософт его так нахваливают, так нахваливают...
Не упомянула, потому что никогда с ним не работала. Отзывы, которые о нем слышала, были положительные.
Fil
1. Как в этой стране обстоит ситуация с игростроем? Буквально в двух словах, при смерти или активно развивается?
Пациент скорее мертв, чем жив.
В общем, что тебе интереснее: делать большую игру крупным коллективом или маленькую в одиночку?
Важен не размер коллектива а то, кто эти люди. И что это за проект.
Анонимный
А что можете посоветовать почитать, про проектирование (архитектуру) игр?
Книги, про которые я слышала хорошие отзывы, сама не читала:
Game Engine Architecture. Вот тут с мира по нитке собирали из нее куски.
3D Game Engine Architecture
Game Engine Gems, Volume One. На подходе вторая часть.
И по поводу: "Модифицируйте чужой код, пишите моды."
Какие игры можете посоветовать для этого?
Ссылка на исходники игр у меня в посте есть. Открытые движки тоже имеет смысл посмотреть.
Еще недавно я писала про Alien Swarm, можно его глянуть, мне он понравился, приятный такой.
Про Unreal уже написали...
А что бы ты посоветовала почитать про серверную часть программирования. Я как бы php-шник, но вообще фиолетово на каком яп. может есть какой движок, который можно поковырять. здесь важно, качественная литература и best practices.
из опыта понимаю, что желательно знать возможности back end, поэтому хотелось бы литературу с кратким описанием по данной части.
isagalaev комментирует...
Спасибо больше за ответ. Ваш блог я тоже читаю, жду с нетерпением буквально каждый пост по рсс.
> Питон не скриптовый язык. Уже просто потому, что слово "скриптовый" ничего не означает. Вы наверное имели в виду интерпретируемый. Это, всё же, разные вещи.
Да, тут я ошибся.
> Ошибаетесь. В де-факто стандартном интерпретаторе CPython нет JIT. Есть отдельные разработки PyPy и Unladen Swallow, но они на практике пока ещё не распространены по разным причинам.
CPython — наиболее распространённая, эталонная реализация языка программирования Python. CPython является интерпретатором байт-кода, написан на C. (Wikipedia)
Насколько мне известно при первом запуске приложения на пайтоне создается pyc файл (байт-код), который затем интерпрерируется. В джаве ситуация похожая, только прежде необходимо скомпилировать исходник.
> Что такое "серверные языки"? Код на серверной части можно писать практически на чём угодно...
Я имел ввиду языки для веб разработки. На C++ сложновато и опасно писать для веба. C# не нужен ибо Windows да и на джаве написать простейшее веб приложение думаю будет сложнее чем используя тот же Django. Думаю что языки Ruby, Perl и PHP сильно отстают по скорости.
Прежде всего стоит не программировать, а думать.
Например, попробовать реализовать ключевые моменты игры на бумаге или вообще в словах. Описать, чего же хочется.
Потом выбираем движок\существующую игру. На движке писать легче, чем без движка. Мод для игры писать легче, чем свою игру. Принцип прост. К тому же, чтобы написать ту же графику, нужно знать что к чему и как должно работать; если человек знает, у него не возникнет самого вопроса «Что мне делать?».
Вообще, в одиночной работе может получиться именно то, чего хотел автор. И это — самое страшное. Например, есть такая игра «Alida». Автор писал её 5 лет. И он написал, что хотел - точный клон Myst I.Она требовала Quicktime VR, разрешение экрана 640x480 и Windows 95. А на дворе был уже 2004й. И оставались считанные месяцы до выхода Myst V в полном 3D.
Та же World of Goo выросла из маленького прототипа Tower of Goo с рудиментарной физикой и довольно простой графикой. Прототип был сделан за неделю, если я не ошибаюсь.
> Для начала не пытайтесь написать игру с нуля. Модифицируйте чужой код, пишите моды.
А что насчёт участия в каком-либо опенсорсном проекте? Хоть OpenTTD, хоть тот-же UFO:AI?
Их участники всегда заинтересованы в новых людях и головах, и обычно с радостью дают советы по тому — как это сделать.
Есть еще такой жанр игр как Визуальные Новеллы. Картинки с текстом сменяют друг друга, периодически нужно делать выбор. Если знаний в программировании ноль, можно начать с этого.
Для них есть отличный бесплатный движок http://renpy.org
Добитый стажерами на работе приступил к написанию статьи о том, как надо и как не надо писать код на C++.
Если вам она вдруг понравится, поучаствуете в ее пиаре?
AmdY
А что бы ты посоветовала почитать про серверную часть программирования.
Я читала Networking and Online Games, мне понравилось, но на Амазоне его почему-то ругают.
Также читала двухтомник Massively Multiplayer Game Development, мне он не понравился, но на Амазоне его почему-то хвалят.
kildor
А что насчёт участия в каком-либо опенсорсном проекте? Хоть OpenTTD, хоть тот-же UFO:AI?
Все-таки прежде чем туда лезть, надо хоть что-то уметь.
Programmist
Добитый стажерами на работе приступил к написанию статьи о том, как надо и как не надо писать код на C++.
Если вам она вдруг понравится, поучаствуете в ее пиаре?
Да, легко!
Начинание, конечно, эпическое. Но не уверен в полезности.
На действительно интересные вопросы все-равно ответить не выйдет: NDA, вымученные решения, которыми жалко делиться, либо просто хак-затычки, о которых рассказывать стыдно.
А все вопросы вроде "с чего начать?" практической пользы не несут, увы (:
Дарк
На действительно интересные вопросы все-равно ответить не выйдет: NDA,
К вещам, закрытым NDA, есть нездоровый интерес, почему-то считается, что если оно закрыто, то там есть некая ТАЙНА, без которой написать игру нельзя. Что в целом не так, информация закрывается по совершенно различным причинам.
Например, коммерческие игровые движки несколько лучше некоммерческих по набору фич, сильно лучше по поддержке, но основное, чем они берут - это маркетинг.
Короче говоря, вся информация по написанию игр есть в открытых источниках. Не всегда бесплатных, правда.
вымученные решения, которыми жалко делиться,
Ээээ... я привыкла к тому, что в программерских коммьюнити все наоборот делаться так, что мало не покажется, даже когда никто не просит :-). У меня решений, которыми мне поделиться жалко, нет.
либо просто хак-затычки, о которых рассказывать стыдно.
Возможно, но и такими решениями народ периодически делится.
А все вопросы вроде "с чего начать?" практической пользы не несут, увы (:
Это ответы на все те вопросы, с которыми ко мне часто обращаются. То есть кому-то это нужно.
> Насколько мне известно при первом запуске приложения на пайтоне создается pyc файл (байт-код), который затем интерпрерируется. В джаве ситуация похожая, только прежде необходимо скомпилировать исходник.
.pyc — это всего лишь более эффективный способ хранения рапарсенного исходника. Скорости исполнения он не добавляет. Когда я говорю про JIT, которого в CPython нет, я имею в виду динамическую компиляцию "горячих" веток исполнения кода на лету в машинный код. Вот это серьёзно ускоряет работу. К слову, именно из-за этого javascript'овые движки стали за последние пару лет примерно на порядок быстрее.
> На C++ сложновато и опасно писать для веба
Больша́я часть разработчиков Яндекса не согласится по крайней мере со вторым пунктом :-). Сложно — пожалуй. Но зато с большим выигрышем в скорости исполнения, поэтому иногда это вполне оправдано.
> C# не нужен ибо Windows
Сервера CrimeCraft и ARENA Online написаны на C#: http://www.dtf.ru/articles/read.php?id=50054
> да и на джаве написать простейшее веб приложение думаю будет сложнее чем используя тот же Django
Штука в том, что не все пишут простейшие приложения. На Java написано очень много веба.
Не подумайте, что я очень пропагандирую Java :-), я просто констатирую, что она имеет полное право называться серверным языком. Причём, пожалуй, именно она исторически больше всех это право и имеет.
> Думаю что языки Ruby, Perl и PHP сильно отстают по скорости.
Перл в среднем слегка побыстрее Питона, кстати.
Используйте OpenGL он кросс платформенный. а не эту поделку под виндовоз по названием DirectX
> AFAIR, у них сервер на Питоне, клиент на С++.
Небольшие куски клиента на C++, но большая часть кода — Python. Если покопаться в бинарниках клиента, то это очень хорошо видно. Поэтому и ругают, что тормозной клиент у них. Недавно писали в своём блоге, что Python очень крутой и позволил им с помощью метаклассов легко сделать нагрузочный клиент (без графики, UI и т.п.) для тестирования сервера. Сомнительная польза, честно говоря, но проекты вроде PyGame или Ren'Py существуют. Да и в целом язык общего назначения, why not?
>> А вот Lua создавалась для этой цели
> Для этой цели создавались Squirrel и AngelScript. У Lua были совершенно другие и местами очень русурсоемкие задачи.
У них на сайте прямым текстом написано про embeddable scripting. Возможно изначально цели и были другие, но отрицать, что сейчас это в первую очередь встраиваемый скриптовый язык нельзя.
Тут ещё про XNA спрашивали. Я пробовал — милая вещица, но книг хороших нет вообще, а документация в стиле Microsoft: «Reference мы вам дали, дальше додумывайте сами». Однако есть XNA Creators Club, там полно хороших примеров и живой форум. В общем-то игры на нём выходят, но в основном это конечно indie-проекты по технологиям на уровне Shatter или World of Goo. Да, ещё под Windows Phone 7 это официальный игровой фреймворк.
А можно поподробнее что в boost'е медленным считается?
>Используйте OpenGL он кросс >платформенный. а не эту поделку под >виндовоз по названием DirectX
Сначала школу закончи, да проведи пару лет в индустрии, прежде чем таки советы давать.
Всего лишь векторы, матрицы, кватернионы, а аналитическая геометрия, дифференциальная геометрия, дифференциальные уравнения. А вообще можно по подробнее о математике: какие разделы использутся для прорграммирования 3д графики.
Вы назвали векторы, матрицы, кватернионы, но наверняка это не все. Что еще точно пригодится и может пригодится.
Анонимный
Вы назвали векторы, матрицы, кватернионы, но наверняка это не все. Что еще точно пригодится и может пригодится.
Мне больше ничего не нужно было, никаких дифференциальных уравнений.
Как пользователь OGRE замечу, что это чисто графический движок и желательно убрать слова о том что он игровой - это сильно сбивает с толку пользователей, регулярно вопрошающих на форуме OGRE, а где-же физика, сеть, AI и т.д.
> лучше Visual C++ и лучше версию поновее
Ставьте VS 2005 + MSDN + Visual Assist. Более новые версии студии сильнее тормозят.
> Ставьте DirectX.
Если ничего не будет портироваться на другие системы.
И по движкам - для простых 2д игр рекомундую HGE.
> Поищите ваши ошибки Гуглом
и активно пользуйтесь поиском по форуму движка.
VS 2005 не работает с последним DirectX SDK (там где есть DirectX 11).
Только 2008 и 2010 поддерживаются.
Gleb Vinogradov
VS 2005 не работает с последним DirectX SDK (там где есть DirectX 11).
А почему? DirectX - это же заголовки да библиотеки. Что именно там не срастается?
Только DirectDraw смотреть не нужно, им никто не пользуется.
А чем сейчас пользуются для 2D?
Alena: А почему? DirectX - это же заголовки да библиотеки. Что именно там не срастается?
Как написано:
Beginning with the June 2010 release, the DirectX SDK supports Visual Studio 2010. The June 2010 release continues to support Visual Studio 2008 Service Pack 1. The DirectX SDK no longer supports Visual Studio 2005; the February 2010 release was the last release to support Visual Studio 2005.
Как есть:
В SDK лежат примеры, с Solution от 2008 и 2010 студии.
М.б. если поковыряться, то можно и с 2005 все запустить. С 2010м же работа идет в один-два клика.
Игры в 3д? Если вы один, то забудьте. Больше чем рендеринга мешей вам не добиться. Если у вас есть небольшая команда, которые знают что делают, то попробовать стоит, а может что и выгорит. Можете даже Unreal Engine 3 взять, он халявный, если игру не будете продавать. Но практика показывает что indie-игр в 3д практически нет, а те что есть просто ужасны. Хорошенькая игра Nimbus, но если бы она была в 2д, я не думаю что она сильно бы проиграла в привлекательности.
Из этого я делаю вывод: Что лучше взять готовую систему (не граф. движок, а полную систему) в плоскости. В этом случае даже в одиночку можно сделать хороший проект, который вас прорекламирует.
Что входит в готовую систему? Сам вывод, т.е. графический движок. Для 2д достаточно вывод спрайтов, поддержка режимов смешивания и поддержка поверхностей, в этом случае можно добиться высоких результатов. Чего не рекомендуется это брать чистые интерфейсы - Direct3D, Direct2D и т.д. Работа увеличивается в разы не давая быстрого результата и раннего прототипирования (пользуйтесь тем что есть, не изобретайте велосипед, дабы сейчас есть очень хорошие вещи в свободном доступе).
Звуковой движок. Такие есть в сети, типа bass или fmod. Достаточно простого воспроизведения, хотя эти библиотеки дают огромные возможности (их которых вам понадобится 5%).
Сетевой движок - если нужен мультиплеер. Не занимался - не подскажу (но не берите чистых интерфейсов, толку будет мало). Сразу говорю - забудьте о приставке ММО! Все просто помешались на них. Проектов таких в сети вагон и маленькая тележка, только толку от них ноль, как и народу в них.
Физический движок - если будет физика в игре. Не в многих играх нужна честная физика, можете сделать быстрый самопал, сэкономите время и силы.
Логический движок - основа игры. Вот над чем реально стоит подумать. Прочитайте первые два предложения из определения слова Игра.Какие действия уже есть у вас? Как вы их будете компоновать? Как они будут влиять на игрока? Здесь стоит определиться с инструментарием. На чем будете писать, на чем удобнее? Может на флеше или на С++? Допустим С++, при правильном проектировании можно сделать и без графического движка, его можно прикрутить позднее (отладка будет тяжела, да и следить за процессом будет непривычно в консоли). Надо решить что будет входить в логический движок, какие инструменты: камера нужна? Какое поле? Как это будет хранится? Какие будут объекты? Как они будут хранится? Как они будут взаимодействовать друг с другом? Продумать игровой цикл (интро->меню<->игра и т.д.).
Это всё можно собрать в кучу и доделать то чего не хватает, либо искать полный набор типа Game Maker. Ещё очень актуальны сейчас флеш игры (AS3).
Кстати, я занимаюсь многими вещами, но у всех них есть общая черта. Автор сначала накидывает эскиз-идею, потом же дорабатывает настолько детально насколько нужно. Посмотрите быстрые видео о рисований. Если процесс программирования визуализировать, то получится, я считаю, очень похожее занятие. Так вот, вопрос всем: Какая хрен разница чем рисовать, если вы ничем не умеете? Да, карандашом научится рисовать - расплюнуть! Но научиться рисовать, хотя бы хорошо, дорого стоит.
Советую абстрагироваться от конкретного языка и мыслить идеей, а не реализацией (конечно от особенностей языка никуда не убежать, но всё же, цель надо чётко видеть и знать как её решить). Напишите программу в псевдо-коде (да даже в html'е), это даст понять, что куда, как будто пишете книжку, потом переводите компу чтобы он её визуализировал. Жаль совет не мой, а Дональда Кнута...
Первый коммент:
//Только DirectDraw смотреть не нужно, им никто не пользуется.
//А чем сейчас пользуются для 2D?
Для 2D есть хороший движок HGE. Также есть хорошая замена DirectDraw - Direct2D.
Короче почитал я комменты и понял что все начинают и с того что и я лет эдак десять назад. Ищут самый лучший компилятор, самый лучший 4D граф. движок, и т.д. Всё о чём здесь было сказано относиться к созданию ПРОГРАММЫ, но не ИГРЫ. Да можно рассуждать какой компилятор лучше, и может быть даже вы такой выберете, но напишете ли вы игру? Нет. Хороший пример, есть игровая система Game Maker, простая в освоении. Что нам скажет по ней профессиональный программер? Что она тормозная, слишком проста и вообще для детей. Однако, не притязательный человек вам покажет вот это. Как минимум 4 нижних игры сделаны на нём, остальные флеш. Они понятные, увлекательные, быстрые (некоторые из них были на дисках разных журналах, по моему, Игромания). Конечные проекты, которые продаются. В основе, сама идея и минимум технологий.
Когда же пройдёт этот коммент...
Литература: советую сайтик pmg.org.ru. Там много интересного, старенькое, но зато на русском и по делу.
По геймдизайну и архитектуре игры... Тут ваще кисло. Можете попробовать: gamedezigner.ru
Для понимания архитектуры игры сюды. Темка хорошая, но оставляет больше вопросов, чем ответов, хотя какой-никакой старт даст. Остальное на нашем геймдеве, за редким исключением, - мусор не имеющий никакого применения. Настоятельно рекомендую выучить технический англ. и заглянуть на ai-junkie (по ИИ) и gamedev.net. И далее по тексту, читать иностранных разработчиков, они как правило, пишут понятно и по существу. Но по логике пока нет никаких работ, только отдельные советы. А каких-то работ по "что составляет игру? Какие элементы? И как они влияют на игрока?" Пока нет.
P.S.: И помните, сам инструмент гораздо проще изучить, чем создать на нём что-то стоящее. Так может перестать обсуждать инструмент и перекинутся на предмет создания?
Хотел покороче, но не получилось. Вроде столько умных людей, умные алгоритмы, а как дело до продукта доходит, то тут тухло. Nival и ещё пару компаний, всё. А большинство просто не выдерживает никакой критики. Хочется чтобы наши программеры не только хвалились, что они пишут самый лучший в мире код, но и обгоняли по продукту китайцев и индейцев.
Ang3L
Когда же пройдёт этот коммент...
Комментарии со ссылками обычно падают в премодерацию. Так что они ВСЕ прошли. :-)
Я их, пожалуй, поудаляю...
Raider
А чем сейчас пользуются для 2D?
Direct3D, рендеринг в ортогональной проекции текстурированных квадратов.
Oliora
А можно поподробнее что в boost'е медленным считается?
Весь boost целиком.
Хорошая книга для начинающих в программировании графики - вторая книга Фрэнка Луна:
Frank Luna, Introduction to 3D game programming with DirectX 9.0c: A shader approach
Есть на гуглокнигах. На английском. Раньше был авторский сайт с примерами и дополнениями к книге, но сейчас я его не смог найти...
Собственно, собрав примеры этой книги воедино, можно получить небольшой графический движок. С кучей недостатков, естественно.
Но, например, кое-что там много правильнее, чем в том же Иррлихьте.
В Иррлихьте, имхо, вообще многое сделано плохо.
Ну и справка по DirectX - одна из лучших справок к программным продуктам вообще.
На мой взгляд, лучше начинать с DirectX. Все-таки, OpenGL - это набор функций, никакого ООП.
Книги и справку по OGL можно найти на оф.сайте.
Ситуация под Линукс проста. ОпенГЛ плюс одна из сред программирования: Code::Blocks, Eclipse или, возможно, NetBeans. Всякие KDevelop созданы немножко для другого, хотя можно и такие использовать. Компилятор, само собой, g++.
Отличия от программирования под Win лишь в частностях.
Кроме Огра и Иррлихьта еще есть бесплатный движок OpenSceneGraph.
Поиск по геймдев.ру также весьма полезен.
**Хорошая книга для начинающих в программировании графики - вторая книга Фрэнка Луна:
Frank Luna, Introduction to 3D game programming with DirectX 9.0c: A shader approach**
Я же уже написал. Она находится вот тут. На русском, хорошем, не машинным переводом, с исходниками. Ссылки целые, проверил. Ещё там много хороших статей по другим темам, по ИИ, поиску пути (по моему, всё на русском).
Вот, вспомнил ещё. Ещё есть хороший курсы от 3D Buzz (видео, но на англ. языке. Есть сообщение, что на Ютубе есть на русском). Ребята в основном работают профессионально с 3д графикой, но так же есть уроки и по созданию игр. На родном сайте есть начальный, бесплатный, курс по созданию консольной игры. Это единственный курс который чисто по созданию игры, архитектура и т.д. На рутрекере лежит вот тут (англ.). Так же есть ещё курс по XNA. С рутрекера, здесь(англ.). Что мне нравится в этих видео, белых пятен в знаниях не остаётся, парни подробно рассказывают обо всех аспектах создания игры. От самого инструмента (с++, с#), его использования, до аспектов игры и до полного её создания. Т.е. от А до Я. Не думайте что они там создают Rage 2, но понять что такое игра и как её создать, они вам дадут. Особого знания разговорного англ. не требуется, хотя бы посмотрите что за код пишут, но желательно.
Как классно звучит - программирование игр. Я поклонник делфи, но что я не писал игры на с! У меня на первом курсе было здание по курсовому проекту - написать программу игрушку теннис. С ним я справился в полной мере, но я тогда был начинающим программистом, да и сейчас сказать, что сильный программист не скажу. Но кое-что умею. Если вам интересно, что же вышла за игрушка то наберите в гугл abatvsurin + теннис.
Перейти на мой блог
2 Алёна:
>под Линуксом никакого DirectX нет.
В Linux-е есть Wine, реализующий многие виндовые API, в том числе DirectX. Правда, пока не вся функциональность реализована :(.
>Используется STL,
STL-контейнеры плохо подходят для серьёзных задач. Хотя могут уберечь новичков от утечек и порчи памяти.
>>1. Как в этой стране обстоит ситуация с игростроем? Буквально в двух словах, при смерти или активно развивается?
>Пациент скорее мертв, чем жив.
Доктор сказал в морг :). Не знаю, как в России обстоят дела с разработкой коробочных игр (говорят, кисло), но разработка shareware-ных (см. Alawar, Nevosoft), социальных и мобильных игр идёт полным ходом.
>>А чем сейчас пользуются для 2D?
>Direct3D, рендеринг в ортогональной проекции текстурированных квадратов.
По терминологии:
1. Проекция не «ортогональная», а «ортографическая» (orthographic).
2. Не «квадраты», а «quad-ы» или «прямоугольники».
Ну и замечу, что 2D-графику можно с таким же успехом реализовать с помощью OpenGL.
2 stasmyagkov:
>Также есть хорошая замена DirectDraw - Direct2D.
Нет, Direct2D -- это аналог GDI и GDI+, то есть rendering 2D-фигур, в том числе текста. А DirectDraw -- это простенький API для прямого доступа к видео-памяти в полно-экранном режиме (+ мало востребованная мелочёвка, например blit-ы), ему замена не нужна.
2 marked-spb:
>Ну и справка по DirectX - одна из лучших справок к программным продуктам вообще.
Да обычная справка, ничего выдающегося, по-моему. (я про справку Direct3D 8/9) Вот примеры программ в DirectX SDK -- да, хорошие.
>На мой взгляд, лучше начинать с DirectX.
А я наоборот советую новичкам начать с OpenGL. По нескольким причинам:
1. Базовая часть OpenGL (fixed function pipeline, которая без shader-ов) никогда не переделывалась. Новая функциональность добавляется через расширения (extensions). Поэтому книги по OpenGL, даже давно написанные, не устаревают. Сейчас новичкам доступно много хороших актуальных книг по OpenGL на русском языке.
С Direct3D ситуация другая: каждые 3 года Microsoft делает новый вариант Direct3D, который бывает похож на предшественника (8 и 9), а бывает не похож (9 и 10). Книго-писателям тяжело угнаться за Microsoft, поэтому книг по Direct3D 10/11 на русском языке очень мало (я знаю всего одну). Зато в продаже до сих пор есть книги по Direct3D 7, только они не нужны никому, потому что Direct3D 8 удобнее, богаче функциональностью, и реализован во всех живых Windows.
2. OpenGL позволяет рисовать примитивы (точки, отрезки прямых, треугольники) без создания vertex buffer-а, достаточно просто вызовов функций glBegin/glVertex*/glEnd (так называемый «immediate rendering»). Это удобно, и вполне подходит для многих случаев (например, 2D-графика, GUI). Но это неоптимально. Если надо рисовать много примитивов, то лучше это делать через vertex buffer. Это неудобно, зато быстро работает.
Ближайшая аналогия: в 90-ые годы почти весь код игры писался на высоко-уровневых языках C/C++ (удобно), и лишь небольшая часть кода, критичная по скорости, писалась на ассемблере (неудобно, зато быстро работает).
В отличие от OpenGL, Direct3D 8/9/10/11 принуждает программиста рисовать примитивы через vertex buffer. (Методы DrawPrimitiveUP/DrawIndexedPrimitiveUP из Direct3D 8/9 не в счёт, в Direct3D 10/11 их вообще нет.) Следуя аналогии, это примерно то же самое, что писать весь код игры на ассемблере. То есть Direct3D-шный подход (рисовать всё через vertex buffer-ы) недружелюбен к новичкам. А профессиональным игроделам всё равно, они на зарплате сидят.
3. Используя Direct3D 8/9, программист вынужден обрабатывать «потерю устройства» (device lost). Потеря эта происходит, например, когда игра работает в полно-экранном режиме (а это почти всегда так), и пользователь переключается на другую программу.
Обработка потери устройства -- дело муторное. Надо Reset-ать device, предварительно освободив (методом Release) D3DPOOL_DEFAULT-ресурсы (например, динамические (D3DUSAGE_DYNAMIC) vertex buffer-ы). Всё это лишняя головная боль на ровном месте, от которой пользователи OpenGL всегда были избавлены.
----------------
Если новичок осилил базовый уровень OpenGL и всё ещё хочет делать игры, то вот тогда уже можно посмотреть в сторону Direct3D.
>Все-таки, OpenGL - это набор функций, никакого ООП.
Да, OpenGL сделан не в объектно-ориентированном (ОО) стиле. И это хорошо. Кстати, используемые на практике варианты Direct3D (Direct3D 7 Immediate Mode, Direct3D 8/9/10/11) тоже сделаны не в ОО-стиле. (Мы ведь не приравниваем понятия «ОО-стиль» и «COM-интерфейсы», правда?)
А высоко-уровневые 3D API, сделанные в ОО-стиле, вымерли за ненадобностью. (см. Microsoft Direct3D 7 Retained Mode, Apple QuickDraw 3D)
>Eclipse
Не надо :). Безбожно тормозит и жрёт память вагонами (на проектах крупнее, чем hello-world). Java всё-таки.
P.S.
----------------
Ваш код HTML не может быть принят: Must be at most 4,096 characters
----------------
Вот именно поэтому пришлось разбить на 2 сообщения. Чёртов Blogger.
Ang3L:
> Я же уже написал. Она находится вот тут. На русском, хорошем, не машинным переводом, с исходниками.
Там находится _первая_ книга Фрэнка Луна. Она без приписки "A shader approach" в названии. Да, она на русском, но она морально устарела.
Я же говорю про _вторую_ его книгу. В ней все примеры с использованием шейдеров. Причем, все очень доступно и понятно, по причине чего я ее и рекомендую.
Пётр Седов:
> Да обычная справка, ничего выдающегося, по-моему.
Не скажите, в ней задокументировано практически все, что есть в наличии, с примерами. К тому же прекрасно работает поиск. Тот же MSDN с ней не сравнится.
> А я наоборот советую новичкам начать с OpenGL. По нескольким причинам:
> 1. Базовая часть OpenGL (fixed function pipeline, которая без shader-ов) никогда не переделывалась.
Именно поэтому я советую начинать с DirectX. Как раз чтобы сразу приучаться использовать шейдеры.
> Сейчас новичкам доступно много хороших актуальных книг по OpenGL на русском языке.
К сожалению, хорошие и актуальные книги по OGL я нашел тоже лишь на оф. сайте, и они были на английском...
> а бывает не похож (9 и 10). Книго-писателям тяжело угнаться за Microsoft, поэтому книг по Direct3D 10/11 на русском языке очень мало (я знаю всего одну).
На самом деле, DX10 в достаточной степени похож на DX9. У меня не возникло с ним проблем в свое время. А хороших книг действительно крайне мало. А если Вы имеете в виду книгу Попова по DX10, то это, вообще говоря, вольный перевод вступления к справке из DX SDK.
> 2. OpenGL позволяет рисовать примитивы (точки, отрезки прямых, треугольники) без создания vertex buffer-а
...
Direct3D 8/9/10/11 принуждает программиста рисовать примитивы через vertex buffer.
У меня с этим проблем не возникало никогда. В любом случае, даже если начать с прямой отрисовки, потом придется пользоваться буфером.
> А профессиональным игроделам всё равно, они на зарплате сидят.
Думаю, каждый новичок должен хотя бы попытаться получить достаточные знания для того, чтобы стать профессиональным игроделом. И OpenGL, да еще и без шейдеров, тут не сильно поможет...
> 3. Используя Direct3D 8/9, программист вынужден обрабатывать «потерю устройства» (device lost).
> Всё это лишняя головная боль на ровном месте
Обработка пишется в несколько строчек, кстати. Ничего сложного. В книге Фрэнка Луна это есть. А DX10 и выше не требуют обработки потери устройства.
>(Мы ведь не приравниваем понятия «ОО-стиль» и «COM-интерфейсы», правда?)
"Стиль" не приравниваем. Но DX - объектно-ориентированная библиотека, пусть и в "стиле COM". Там во главу угла ставятся объекты, а не функции. И это как раз хорошо и удобно. И нужно к этому привыкать как можно раньше.
>>Eclipse
> Не надо :)
Лично я его не использую как раз по причине Java. Тем не менее, его используют многие серьезные конторы. Его главный плюс - огромная функциональность.
Непонятно почему эклипс вызывает такое раздражение. Это же в сущности ядро для RCP-приложений, и все :)
Ну и по IDE по совместительству. Очень даже неплохая, надо сказать. четвертый год пишу в ней.
Если грамотно подобрать плагины, то можно писать код на любых языках и под любые фреймворки и платформы.
насчёт "жив, мёртв" в недалёкой РБ есть компания wargaming.
их World Of Tanks набрал уже 1 млн пользователей.
не знаю насчёт много это или мало. но для команды в 100-200 человек, по-моему невероятно клёво.
вакансии у них открыты. я знаю о необходимости C++ и Python программистов. зарплаты более-менее адекватные для РБ.
2 Пётр Седов:
Я, (новичок в использовании OpenGL/DirectX), начинал с OpenGL - просто потому, что рядом был товарищ с каким-никаким опытом OpenGL, и можно было спросить. Потом из-за проблем с совместимостью пересел на DirectX 9 - и стало мне счастье:
1. Вместо необходимости _в правильном порядке_ вызывать всякие функции деинициализации - вызов Release. Удобно инкапсулировать DirectX-ресурсы в своих объектах.
2. Отладочные средства (утечки ресурсов, к примеру, ловятся с ходу).
В общем, спроектирован он позже и лучше, и OpenGL после него напоминает времена, когда я писал на бейсике на Львiве - с операторами PSET и LINE.
Так что по мне - лучше начинать с DirectX, способствует выработке правильного стиля (инкапсуляция, своевременное устранение ошибок [утечки памяти]).
Но большой разницы нет.
2 marked-spb, aamonster:
Ответил в другом месте:
http://www.sql.ru/forum/actualthread.aspx?tid=824699
(Потому что здесь ну очень неудобно обсуждать:
* Из-за ограничения «Must be at most 4,096 characters», приходится разбивать большое сообщение на несколько мелких.
* Нет tag-ов для C++-кода.
* Картинку не приложить.
* Из-за пре-модерации, сообщения появляются с задержкой.
)
Если что, там необязательно заводить account, чтобы писать сообщения.
Осенью 2010 года посетил курсы при игоровой компании и пришёл к выводу что хромает проектирование (до них полагал что вот выучу функции DirectX/OpenGL и игры начну штамповать). Что бы посоветовали?
Анонимный
Осенью 2010 года посетил курсы при игоровой компании и пришёл к выводу что хромает проектирование (до них полагал что вот выучу функции DirectX/OpenGL и игры начну штамповать). Что бы посоветовали?
Народ советует Game Engine Architecture. Я сама ее не читала.
Ну и старые добрые "Паттерны проектирования".
На мой взгляд, лучше все же начать с OpenGL. С точки зрения архитектуры он куда более продуман, чем DX, а по возможностям OpenGL 4.1 не уступает DX 11. В качестве учебников могу посоветовать arcsynthesis.org/gltut/ и steps3d.narod.ru.
Хорошая информация. Теперь хоть имею представление, что к чему.
Если не сложно может кто-то посоветовать с чего начать, что прочитать, чтобы сделать тот же пазл ?
Добавлю ещё, классические уроки по OpenGL:
nehe.gamedev.net
С наилуччими пожелалами!
DeskTank.com
Признаюсь честно, все комментарии я не прочитал, но лично я работал на Unity 3d. Все было хорошо, пока я не обнаружил, что вся внутрянка писаться должна на c#. Вот тут то и началась вся волокита. Помимо того, что я уже на тот момент смотрел ролики с https://www.youtube.com/channel/UCSQwsP1Y3ctN8rH_GEo0pYw, мне пришлось искать книжки(Шилдт, Буч) и уроки (собственно вот: https://www.youtube.com/playlist?list=PLvItDmb0sZw8gJ0TgeSKeqLzIywwLGnS9)по шарпам. И вот тогда, когда я провел недели за просмотрами и за книгами. начало получаться сделать какую-то кривую физику. Потом глубже и глуюже.... короче, это не шахматы. Тут думать надо. Но обязательно книги. Без них будет тупо писание чужого кода, потому что своего не наработал. Так что Видео - это дополнение
АЛЕНА ЗДРАВСТВУЙТЕ
Я ХОЧУ ЗАДАТЬ ВОПРОС. А ГДЕ ПРОЧИТАТЬ ОТВЕТ И ОТВЕТИТЕ ЛИ ВЫ
ВОПРОС ОТ ЧАЙНИКА НО ВОПРОС ОЧЕНЬ "ХИТРЫЙ"
Анонимный
АЛЕНА ЗДРАВСТВУЙТЕ
Я ХОЧУ ЗАДАТЬ ВОПРОС. А ГДЕ ПРОЧИТАТЬ ОТВЕТ И ОТВЕТИТЕ ЛИ ВЫ
ВОПРОС ОТ ЧАЙНИКА НО ВОПРОС ОЧЕНЬ "ХИТРЫЙ"
Здравствуйте. Мой актуальный e-mail адрес есть в профиле. Я отвечаю на письма, когда есть время.
Отправить комментарий