Какой язык программирования выбрать для создания игр?

Какой язык программирования выбрать для создания игр? Си или Си++. Собираюсь писать, как сложные, так и легкие игры. Я имею в виду 3D или 2D графика. Ну и писать свои движки.

0

C#.

0

DwapDaBase,

Сообщение от DwapDaBase Ну и писать свои движки

Конечно же C++, ни о каком C# и речи не может быть.

Сообщение от DwapDaBase Собираюсь писать, как сложные, так и легкие игры.

Если Вы выберите движок, на котором собираетесь писать игры, то легче всего использовать управляемый язык программирования - C# или Java в приоритете будут.

0

Bretbas,почему именно C++???

0

Веселый, потому что, если ты хочешь создавать игровой движок, то должна быть максимальная производительность, а чтобы была максимальная производительность, тебе нужно будет лезть в самые ништяки указателей, смещений. Языки со сборщиком мусора не подойдут в этом случае. Придется все делать ручками. У таких языков, как C# и Java очень много чего скрыто за кулисами, то, что грузит непонятно из-за чего процессор. Если ты хочешь делать систему, на которой будут потом делать игры, тоесть игровой движок, то тебе будет важен каждый такт процессора, каждый цикл, который не будет нарушать целостности твоего кеша при переборе, каждый байтик, который ты занимаешь. C++ в этом случае самое лучше решение. Ну и ассемблер в некоторых местах конечно же.

Говорю по своему опыту.

0

Сообщение от Bretbas который не будет нарушать целостности твоего кеша при переборе, каждый байтик, который ты занимаешь.

Вот это ты уже перегнул. Такое - уже результат самой программы, а не выбранного языка. А так да, С++ для движка - сомое оно.

Но хочу заметить несколько моментов:
а) С++ такой быстрый и мощный не просто так, он потребует куда большей дисциплины и глубины познания языка;
б) Для написания собственного игрового движка нужно познаний немного больше, чем "какой язык выбрать";
в) Так же неплохо бы иметь обоснование того, зачем нужно писать с нуля, а не брать готовое (хотя бы самое простое);

Лично я бы порекомендовал не строить наполеоновские планы по написанию своего Unreal Engine 10 на коленке, а начать с чего-то попроще. Например написать какую-нибудь змейку или Flappy Bird на чистом GDI с применением управляемого языка (чтобы не отвлекаться на сложность С++ чьих плюсов в плане гибкости и производительности просто нет на таких скромных проектах) - C#\Java\Python\Ещё_чё_нить.

Так будет получен бесценный опыт и какое-никакое понимание что и как быть должно. Следующим этапом я бы порекомендовал попользоваться простыми open source движками, чтобы сориентироваться в том, что они дают и зачем. Чтобы для себя понять, что это такое. А там уже видно будет, нужно ли писать свой "движёк" или всё-таки написание игрушки в приоритете.

2

Сообщение от DwapDaBase Какой язык программирования выбрать для создания игр? Си или Си++.

Есть тут своя логика в этом выборе между С и C++. Если вам С++ кажется слишком большим по объёму для изучения, то возьмите пока C. Он очень маленький. Почти всё его описание изложено в небольшой книге от создателей языка: Язык программирования C. Брайан У. Керниган, Деннис М. Ритчи

В этой книге по OpenGL все примеры на чистом C: Anton's OpenGL 4 Tutorials
Исходники примеров: https://github.com/capnramses/... rials_book

По поводу ООП мне понравилось, как изложил мысль Otaka:

Сообщение от Otaka Согласен. Сначала учишься вообще программированию: переменные, условия, циклы, функции. Потом учишься загружать и выводить картиночки на экран и обрабатывать сообщения мыши. Все, больше ничего не нужно. По крайней мере, я все делал так. Если ты это все хорошо поймешь, то вопрос "что почитать?" не будет возникать у тебя. А когда ты достигнешь такого уровня, что просто нагромождение кода "переменныеУсловияЦиклыФункции" накапливаются в таком количестве, что тебе будет уже тяжело с ними справляться, то до тебя дойдет идея и волшебство ООП. И ты сможешь использовать классы/наследование там где это действительно нужно, а не потому что тебе сказали:"только лопухи пишут код процедурно, а не по оопшному".

0

Веселый, Usaga, 8Observer8, Помоему ТС, после наших ответов, уже все равно на GameDev

Добавлено через 14 минут

Сообщение от Usaga Вот это ты уже перегнул. Такое - уже результат самой программы, а не выбранного языка.

Я не могу утверждать с полной увереностью, так как пока что C# знаю не очень хорошо, но все таки там почти везде ссылки( кроме стандартных типов, структур и перечислений), а это автоматом говорит о том, что циклы, где идет какой-нибудь перебор ссылок, будет при каждой итерации иметь промах кеша... В C++ можно объекты расположить на стеке, и следовательно такие циклы, где будет проходить перебор этих объектов, будет более дружелюбным, чем в C#. Но может я чего не догоняю.

0

Bretbas, под "перебором объектов" обычно подразумевают некую коллекцию (от массива до дерева\списка). Где именно эта структура распологается роли не играет - для CPU память одна. Причём сама коллекция может хранить как указатели (ссылки в управляемых языках), так и сами объекты (в С++ и value types в C#).

Т.е. вероятность промаха кеша в С# такая же как и в C++ ибо это зависит только от используемой структуры данных, а не от конкретного ЯП.

0

Usaga, Ну к примеру в List<T>, если T будет ссылочный тип, то в C# этот контейнер будет содержать ссылки?

0

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

Добавлено через 1 минуту
В List<T> центральным местом выступает массив, который пересоздаётся с ростом коллекции. Но в своей основе это - всё равно обычный массив со всеми вытекающими отовсюду последствиями.

0

Usaga,

Сообщение от Usaga да, ссылки. А ссылки это что? Правильно - всегда валидные указатели.

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

0

Bretbas, ссылка - понятие из ЯП. Для CPU существуют только указатели. Ссылка - указатель, для которого тем или иным способом соблюдатются некоторые требования.

Для CPU "стёк" никак не отличается от любого другого участка памяти. В кеш попадают любые данные при первом же к ним обращении. Не важно, где они лежат.

Массивы в С++ действительно повзоляют хранить не только указатели, но и объекты целиком. В C# такое можно сделать только со структурами (это умышленное ограничение). Это и плюс и минус. Если объекты крохотные, а сам массив небольшой, то есть вероятность, что вся коллекция поместится в кеш, но без гарантий. Если класс крупный, то такая вероятность сильно снижается (не один этот массив нуждается в кешировании, а кеш не резиновый) + вероятность false sharing. В случае с указателями картина иная: при переборе вы, как правило, обращаетесь к определённым полям (а не целиком ко всему объекту), а так же есть надежда на то, что нужный объект найдётся раньше, чем придётся перебирать ВСЮ коллекцию (соответственно, всё тянуть в кеш не придётся).

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

0

Usaga,

Сообщение от Usaga ссылка - понятие из ЯП.

Я и не отрицаю того, что в C++ можно написать код, который тоже будет не дружелюбный к кешу, но

Сообщение от Usaga Массивы в С++ действительно повзоляют хранить не только указатели, но и объекты целиком.

В этом плюс большой плюс, так как еще раз повторюсь, такой момент позволяет писать код более дружелюбным к кешу, без промахов. В C# так нельзя сделать, кроме конечно же наследников ValueType.

Вообщем хрен с ним C# тоже крутой язык, сейчас его изучаю, и мне это нравится

0

Bretbas, ну, как бы никто вам не гарантирует, что весь массив поместится в кеш (что было бы классно). Плюс ко всему, при манипулации данными в таком массиве (добавление, удаление, перемещение) придётся тягать весь хранимый объект, а не указатель (4\8 байт), что немного компенсирует "профит" от лежания в кеше.

В общем, данный вопрос дискуссионный. Все профиты\недостатки следует оценивать только в контексте конкретной ситуации, а не радикально и категорично. Я об этом

1

Я начал писать свой 2D движок на базе архитектуры движка описанном в книге: Build your own 2D Game Engine. В этой книге используется JS в ООПешном стиле, поэтому легко переписывается на такие языки, как: C++, C#, Java, TypeScript и т.д.

Пишу две версии движка:

• TypeScript/WebGL, чтобы пользователь мог запустить игру в один клик, без скачивания, на любой платформе, где есть браузер с поддержкой WebGL
• C#/OpenGL/OpenTK, чтобы создавать PC версию для Windows и в будущем можно портировать на Android, так как в Xamarin встроен OpenTK

Ну, это всё так - для упражнений, чтобы знать, как оно работает на низком уровне. Для мобильных игр и игр с простой графикой для Desktop/тв-приставок лучше взять Unity+C#, а для игр сложной графикой: CryEngine/Lua/FlowGraph/C#/C++ или UnrealEngine/Blueprint/C++. Такое моё личное мнение.

0