Разработка мощной игры на C#, .NET. Возможно-ли?

Здравствуйте. У меня есть хорошия идея проекта. Монетизированная онлайн игра с хорошей графикой. Идея оригинальна.

Собственно вопрос. Возможно-ли с помощью всех прелестей языка Си Шарп (.NET, WPF, WCF, WWF SilverLight ...+ использование DirectX и Direct 3D и OpenGL) написать полноценную монетизированную онлайн игру с хорошей графикой (на уровне NFS, GTA, Perfect World, HMM 5) ? Что для этого нужно?

Знания языка C# есть. Практика есть. Не знаю с чего начать, чтобы не тратить своё и чужое время впустую.

И какие основные моменты нужно знать в моём случае. В каких еще сферах пригодятся знания? Вообщем к чему быть готовым? Рад буду любому совету.

П.С. Надеюсь вы не поднимите мой ворпос на смех, т.к на начальном этапе каждый в чем-то некомпитентен как специалист.

Спасибо! С уважением, Александр !

1

Сообщение от aganesov Здравствуйте. У меня есть хорошия идея проекта. Монетизированная онлайн игра с хорошей графикой. Идея оригинальна. Собственно вопрос. Возможно-ли с помощью всех прелестей языка Си Шарп (.NET, WPF, WCF, WWF SilverLight ...+ использование DirectX и Direct 3D и OpenGL) написать полноценную монетизированную онлайн игру с хорошей графикой (на уровне NFS, GTA, Perfect World, HMM 5) ? Что для этого нужно? Знания языка C# есть. Практика есть. Не знаю с чего начать, чтобы не тратить своё и чужое время впустую. И какие основные моменты нужно знать в моём случае. В каких еще сферах пригодятся знания? Вообщем к чему быть готовым? Рад буду любому совету. П.С. Надеюсь вы не поднимите мой ворпос на смех, т.к на начальном этапе каждый в чем-то некомпитентен как специалист. Спасибо! С уважением, Александр !

На шарпе сделать хорошую и качественную игру вполне реально. Вывод графики все равно реализован на низком уровне, так что более низкая скорость работы NET особой роли не сыграет, а вот скорость разработки программы будет существенно выше. Для сравнения скрипты UDK (движка Unreal) выполняются в 20-30 раз медленнее, чем NET, но это не мешает ему быть движком ААА уровня. Правда вам наверно стоит вместо DirectX посмотреть в сторону графических движков или XNA, так как Managed версию DX Microsoft больше не поддерживает.

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

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

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

После того, как диздок будет написан, можно уже приступать непосредственно к разработке.

PS. Как всегда получилось немного сумбурно, так что прошу сильно не пинать.

12

Спасибо!! Очень грамотно и четко все расписано. Я понял много ньюансов из выше сказанного. Респект!

П.С. Жду еще комментариев и советов по теме

0

попробуйте Unity3d.
программирование в т.ч. на C#.
Правда, классический дебаг вы там не получите.
Зато очень много заготовок.

0

Сообщение от XAHOK Начинать работу следует с одного: с составления диздока.

В корне не согласен с этим. Разработка программы - не строительство дома. Программу можно перепланировать стопятьсот раз в любой момент. Более того, рефакторинг, скорее неотъёмная часть разработки, нежели неприятная неожиданность. К тому же, я считаю, что заранее нельзя предвидеть всех подводных камней, которые встретятся в процессе разработки.

0

Сообщение от NightmareZ В корне не согласен с этим. Разработка программы - не строительство дома. Программу можно перепланировать стопятьсот раз в любой момент. Более того, рефакторинг, скорее неотъёмная часть разработки, нежели неприятная неожиданность. К тому же, я считаю, что заранее нельзя предвидеть всех подводных камней, которые встретятся в процессе разработки.

Диздок - это макет игры, а не программы. А если команда не знает какую игру будут разрабатывать, то это абсурд. Каждый человек воспринимает информацию по своему и нужно объяснить всем механику игры, связать ее с сюжетом, на основе чего построить игровые уровни и т.д. Разработка самой игры - это уже второй этап. Но и там нужно начинать с планирования или играть в индусов. Планирование не отменяет рефакторинг, однако рефакторинг не должен приводить к кардинальным изменениям архитектуры программы, а значит в исходную разработанную архитектуру просто вносятся изменения.

Сообщение от NightmareZ Программу можно перепланировать стопятьсот раз в любой момент

Вы меня конечно извините, но если приходится 100500 раз перепланировать всю программу, то это означает, что накосячили с архитектурой. А это значит, что что-то не учли при планировании архитектуры или вообще не планировали.

0

Сообщение от XAHOK А если команда не знает какую игру будут разрабатывать, то это абсурд.

А я вот только на днях читал историю разработки Diablo II, и там... "У D2 не было конкретного дизайн-документа. Почти все придумывалось на ходу."
http://habrahabr.ru/post/143762/

Я ни для одной своей программы не писал никаких диздоков. Многие моменты придумываются именно в процессе разработки, а не предварительно на бумаге.

Сообщение от XAHOK Вы меня конечно извините, но если приходится 100500 раз перепланировать всю программу, то это означает, что накосячили с архитектурой. А это значит, что что-то не учли при планировании архитектуры или вообще не планировали.

Это называется "творческий процесс".

1

Сообщение от NightmareZ Я ни для одной своей программы не писал никаких диздоков

Добавлено через 1 час 10 минут

Сообщение от aganesov В каких еще сферах пригодятся знания? Вообщем к чему быть готовым?

Вы готовы делать игру совершенно один и делать это достаточно продолжительное время?

Знания (кроме программирования) пригодятся по моделированию, текстурированию, анимации
еще по тематике игры...это уже зависит от тематики....например если у Вас должен быть город
то это архитектура, если это город 18го века, то это еще и история и т.д. и т.п.

Еще из того к чему быть готовым...
Что идей полно, но тех кто готов это реализовывать и может, значительно меньше, а у них полно своих идей.
Поэтому никому Ваша игра изначально не нужна и делать её предстоит именно Вам в первую очередь, если Вы не миллионер
"монетизировать" слово красивое, но сейчас это лишь Ваши мечты, а в действительности монетизировать можно все,
но только малая часть получает прибыль превышающую затраты

Ну и последнее, но не по значимости...
Возможно всё, но не у всех хватает желания, упорства и терпения.

0

Сообщение от NightmareZ А я вот только на днях читал историю разработки Diablo II, и там... "У D2 не было конкретного дизайн-документа. Почти все придумывалось на ходу." http://habrahabr.ru/post/143762/ Я ни для одной своей программы не писал никаких диздоков. Многие моменты придумываются именно в процессе разработки, а не предварительно на бумаге. Это называется "творческий процесс".

Маленькая история из практики: для обработки журналов испытаний было написано ядро программы одним человеком, а два других разрабатывают модули. Причем оба приступили к своей работе когда ядро было готово примерно на 70%. Из документации только описание классов родителей для разработки модулей и архитектура их разделения. Когда работа была начата приходится постоянно отрывать первого от его основного проекта, т. к. архитектура взаимодействия подсистем на более глубоком уровне неизвестна и предложить уже готовое изменение в ядро практически невозможно и приходится все объяснять на словах.

История вторая: ушел один программист, который в одиночку вел проект. Даже минимальная документация отсутствует. Второй разработчик начинал это проект вместе с первым, но 5 лет уже им не занимался. Этот проект передается второму и ему приходится разбираться практически с 0 как же там все реализовано.

Так что если проект свой и для себя, то документация совсем необязательна и часто достаточно хорошо комментированного кода. Но если над одним проектом работает команда или происходит передача проекта другому разработчику, тот тут минимальный набор документации просто необходим, т. к. существенно экономит время. И это только для программистов, а если добавим сюда еще кучу народа других направлений? Так что диздок к игре обобщает результаты работы ВСЕЙ команды и позволяет количественно оценить объем работы как выполненный, так и требуемый. А так же снижает порог вхождения новых участников в разработку проекта. Ну и последнее назначение диздока - рекламный буклет для издателя))

PS. Как всегда сумбурно, но надеюсь более-менее понятно)

1

Сообщение от XAHOK PS. Как всегда сумбурно, но надеюсь более-менее понятно)

Ты сам себе противоречишь.

Так как

Сообщение от XAHOK минимальный набор документации

и диздок - это совершенно разные вещи. Диздок пишется перед разработкой. Документация появляется в процессе написания кода (часто автоматически из всяких штук типа xml-комментариев, как в шарпе, и прочих javadoc'ов).

Документация нужна. Диздок - не нужен.

0

Сообщение от NightmareZ минимальный набор документации и диздок - это совершенно разные вещи. Диздок пишется перед разработкой. Документация появляется в процессе написания кода (часто автоматически из всяких штук типа xml-комментариев, как в шарпе, и прочих javadoc'ов). Документация нужна. Диздок - не нужен.

Ну с этим можно поспорить. Разработка программы начинается с проектирования ее архитектуры, выделяются подсистемы и определяется их взаимодействие, формируются требования к функционалу, определяются средства разработки и вспомогательные библиотеки, проектируется структура данных системы. Все это можно держать в уме, но в реальности часть из задуманного все равно забудешь. И в этом случае нужна исходная документация, в которой описано ЧТО и КАК нужно делать. Второе назначение диздока - это оценка времени разработки программы, распределение работ между участниками проекта. Заказчика, даже если он твой непосредственный начальник, интересует сколько по времени займет разработка и сколько человек для этого нужно. Без предварительного планирования я лично не представляю как это можно сделать. Третье назначение вытекает из второго - оценка рисков проекта, связанных со срывом разработки одного из этапов (задолбало программиста и он решил уволиться, а значит все работы нужно распределить на оставшихся и оценить насколько задерживается релиз).

Так же посредством диздока тимлидер может выставить требования к разработке, оформлению кода, ввести правила именования, оформления исходных данных и прочее.

Так что с моей точки зрения для любого более-менее сложного проекта диздок нужен. А игры это скорее более, чем менее.

0

Сообщение от aganesov Собственно вопрос. Возможно-ли с помощью всех прелестей языка Си Шарп (.NET, WPF, WCF, WWF SilverLight ...+ использование DirectX и Direct 3D и OpenGL) написать полноценную монетизированную онлайн игру с хорошей графикой (на уровне NFS, GTA, Perfect World, HMM 5) ?

Нет, невозможно. С# очень медленный и годится только для офисных приложений или достаточно простых и нетребовательных игр. А XNA больше для студентов или любителей.
Написание движка с нуля очень затратное занятие, и если хочется использовать C#, то всяко лучше брать уже готовый движок, например Unity, где С# будет реализовывать высокоуровневую логику, а более ресурсоемкими задачами будет заниматься сам движок.

Сообщение от XAHOK Вывод графики все равно реализован на низком уровне, так что более низкая скорость работы NET особой роли не сыграет, а вот скорость разработки программы будет существенно выше. Для сравнения скрипты UDK (движка Unreal) выполняются в 20-30 раз медленнее, чем NET, но это не мешает ему быть движком ААА уровня.

Это всего лишь высокоуровневые скрипты... А если весь рендер и физику реализовать на C#, то будет просто ад. Насчет скорости разработки на шарпе - это стандартный миф. Вот Java пишется на Java, однако, Java разрабатывается очень медленно - в год по чайной ложке. Хорошие программные продукты наспех не делаются.

0

Сообщение от An1ka Нет, невозможно. С# очень медленный и годится только для офисных приложений или достаточно простых и нетребовательных игр. А XNA больше для студентов или любителей. Написание движка с нуля очень затратное занятие, и если хочется использовать C#, то всяко лучше брать уже готовый движок, например Unity, где С# будет реализовывать высокоуровневую логику, а более ресурсоемкими задачами будет заниматься сам движок.

C# всего в 1.5-2 раза медленнее C++, а C++ в 1.2 раза медленнее чистого C.
Никто не запрещает критические участки десктопных приложений реализовать на C++ или С, в частности, движок игры на решетке никто не пишет. И XNA тоже не более чем высокоуровневая обертка над DX. Да и есть еще MOGRE (обертка над огром), упомянутая вами Unity, Irrlight, NeoAxis (кстати написанный над XNA) и прочие.
Да и в целом интересно сколько по времени занимает подготовка сцены к рендеру, без учета затраченного времени на работу процедур граф библиотеки (DX,GL). Ваша и

Сообщение от An1ka Это всего лишь высокоуровневые скрипты... А если весь рендер и физику реализовать на C#, то будет просто ад.

Физику на ЦП по моему уже давно не считают, т.к. в плане производительности параллельных задач он существенно проигрывает GPU.

Сообщение от An1ka Вот Java пишется на Java, однако, Java разрабатывается очень медленно - в год по чайной ложке

Можете прокомментировать? Язык на языке писаться не может по определению. А компилятор, линковщик или интерпретатор можно написать на любом языке. Так что сравнение некорректно.
И для сравнения спецификация на C# выходит с такой же скоростью, как и спецификация на C++, а то 1 раз в 2-3 года. Дополнительных обновлений фреймворка выходит 1-2 за это время.

Сообщение от An1ka Насчет скорости разработки на шарпе - это стандартный миф.

Вы меня конечно извините, но это характерно только для программистов с большим опытом работы. Наибольшее время разработки занимает тестирование, багтрекинг и рефакторинг кода, а учитывая что особенности архитектуры платформы NET позволяют избежать многих ошибок у начинающих разработчиков, то это и есть подтверждение "Мифа".
Второй факт, подтверждающий "Миф" - это структурированность классов в библиотеках. На C++ хоть и существует возможность разделения кода по пространствам имен, но в библиотеках применять это как то не принято. Хорошую структурированность классов и методов на С++ я встречал только в библиотеках для CUDA. Из-за особенности NET начинающий разработчик может сам и без любых справочников найти требуемую библиотеку, используя

Сообщение от An1ka Хорошие программные продукты наспех не делаются.

Наспех и быстро это два совершенно разных понятия. Если на реализацию некоторого класса уходит в 1.2-1.5 раза меньше времени, то это быстрее, а если пишется ГК на костылях, то это наспех.

Добавлено через 36 минут
Сколько раз зарекался не писать в рабочее время. Дописываю мысли тут, отредактировать исходный пост уже нельзя.

Ваша и

Ваша идея, о пригодности C# только для офисных приложений, опровергается вами же при упоминании Unity.

Из-за особенности NET начинающий разработчик может сам и без любых справочников найти требуемую библиотеку, используя

Используя только здравую логику.

2